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

Re: Son-of-IKE Performance

I agree with Stephane. I think we need to debate the requirements draft
first. I think this group needs that done first so that the rat holes
(pre-shared key we do crawl into focus on the appropriate solution. In fact,
if there are any providers of VPN services out there on the list, the
requirements discussion would be a great time for their input.

With the requirements agreed upon, the debate on the solution should go must
faster.

My suggestion would be to debate the requirements draft first, get buy in
from the WG, then the IKEv2 candidates can present their solution. In fact,
I would have the requirements the only thing on the agenda. No point putting
the cart before the horse.

Scott
----- Original Message -----
From: "Stephane Beaulieu" <stephane@cisco.com>
To: "Steven M. Bellovin" <smb@research.att.com>; "Dan Harkins"
<dharkins@tibernian.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Monday, December 10, 2001 7:12 AM
Subject: 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
> >
> >
>
References: