Subject: RE: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt

From: Jeff Parker <[email-masked]>
Date: Wed, 24 Apr 2002 11:40:41 -0400

Ran -
	I appreciate the force of your argument to document
rather than invent, and I may borrow some of your prose 
in the future.  I'm not suggesting we delay the document.  
	But I would think this is an appropriate place to
discuss potential vulnerabilities in the protocol.  We
have a few authentication types left, and someone could 
draft a newer protocol if there is a need.  
	But perhaps this line of questioning is misguided.  
Is this a threat you have evaluated, and decided we 
don't need to worry about this?  

- jeff parker

> On Wednesday, April 24, 2002, at 10:24 , Jeff Parker wrote:
> >
> > 	That is the standard, but Radia has an interesting point.
> > 	Doesn't the use of an area secret allow some replay attacks?
> 
> The objective is to document what ISPs have already widely deployed,
> not invent something new.  The other thing to keep in mind is that
> the ISPs merely want to have protection from eavesdropping on 
> cleartext
> IS-IS passwords.  The deployed approach totally solves that problem.
> 
> Note also that when I proposed something different than what 
> is deployed,
> there was overwhelming push-back from operators saying the above.
> 
> This thing was *deployed* several years ago.  We just need to document
> what has been deployed in an Informational RFC.
> 
> If folks want to do something different, then that should be
> a separate activity in a separate document and should NOT
> delay publication of the deployed mechanism.
> 
> Ran
> [email-masked]
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 24 Apr 2002 14:41:43 -0400

> in the future.  I'm not suggesting we delay the document.

	Thanks.

> draft a newer protocol if there is a need.

	Certainly someone could define a different approach
in a separate document if there were interest.  My main
concern is that we not gate publishing the current draft
on some new project.

	And it is well known that I believe that documents
discussing potential vulnerabilities of protocol X are
always in-scope for a working group focused on protocol X.
So if some folks wanted to write up a separate informational
document with a security analysis of I/IS-IS, that would be
all goodness in my book.

> don't need to worry about this?

	I'll answer this question, but maybe in a different way
than some expect.

	I've thought a lot about routing protocol security.  And
I think the next useful increment of security (beyond the simple
cryptographic authentication in the current draft) is probably
to go to a public-key approach.  At a high-level, routing
protocols already need to be able to handle duplicate
packets (i.e. replays) because packet/frame duplication
happens by accident (no malice) in the global Internet anyway.
So a robust IS-IS implementation probably won't be very badly
affected by packet replay.  For non-robust implementations,
any number of things could be a problem -- but that is an
implementation quality issue IMHO.

	For OSPF, RFC-2154 outlines the use of public-key digital
signatures to improve the protection beyond OSPF MD5.

	So my suggestion is that if folks want to go beyond the
current IS-IS cryptographic authentication, those folks should
look into a digital signature approach comparable to RFC-2154.

	Now my conversations with users/operators makes me believe
that operators are very unlikely to deploy anything other than
the currently deployed MD5 spec.  But a digital signature approach
to IS-IS would certainly make interesting research.

Cheers,

Ran
[email-masked]