[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Son-of-IKE Performance

Steve,

I think most people are quite comfortable with the security properties of
all the candidate proposals.  Once we nail down the exact requirements (i.e.
ID protection, PSK or NOT PSK, etc...), then the candidates who don't
conform to the requirements will likely tweak their submissions.

That part, oddly enough :) seems trivial.

The larger problem is identifying all the corner cases.  Rekeying, NAT
traversal, Legacy auth, SA negotiation, lifetime handling, specifying
selectors, retransmit handling, black hole detection / recovery, resource
handling, etc........

OK.  I admit, at this point, I could care less how the key is stretched.  I
have faith in the author(s) to adequately define this.  The manageability
issue bothers me though....  I think we need to start paying FAR MORE
attention to the details.


Stephane.



----- Original Message -----
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Dan Harkins" <dharkins@tibernian.com>
Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>; <ipsec@lists.tislabs.com>
Sent: Friday, December 07, 2001 8:54 PM
Subject: Re: Son-of-IKE Performance


> In message <200112072110.fB7L9uG01024@fatty.lounge.org>, Dan Harkins
writes:
> >  I am well aware it is possible to derive keys for many SAs out of
> >a mutually authenticated shared secret.
> >
> >  My point is that just saying "by obvious means" is not good enough.
> >After seeing how emminently reasonable people interpreted "by obvious
> >means" differently during implementation of RFC2409 I think it is
> >necessary to explain the means exactly.
> >
> >  My stretching wasn't the "obvious" one? Well there's another person
> >on this list who thought it was. Moreover, there is nothing in JFK
> >to say it was the incorrect way or that what means "obvious" to you
> >is the correct way. Do you see the problem?
>
> Dan -- if we were about to issue "Last Call" on JFK, I'd not only agree
> with you, I'd be leading the charge.  We're not nearly at that stage
> yet.  The purpose of the JFK draft was to describe a cryptographic
> protocol, not (yet) an implementation spec.  Clearly, there are many
> ways to derive the four needed keys from the one exchange; equally
> clearly, a final spec *must* specify exactly one, in very precise form.
> If and when the WG agrees on JFK, we'll happily fill in those details.
>
> But those details are not nearly as controversial as JFK vs. IKEv2 vs.
> SIGMA vs. XKASS, and not even as controversial as the requirements on
> which we'll base that choice.  This is, I think, obvious to everyone.
> Why are you beating on this point?  Is there anyone here, with the
> possible exception of you, who thinks that this is the crucial criterion
> on which the WG is going to decide among the different proposals?
>
> To my mind, the next interesting issue is what the SA description
> should look like.  I've heard many complaints that the current standard
> is a significant source of complexity and interoperability problems.
> In fact, I'd planned on writing a draft on that issue, but a number of
> things (including the events of September 11) interfered.
>
> (Inflammatory comments deleted.)
>
>
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at http://www.wilyhacker.com
>
>
Follow-Ups: References: