[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 (son-of-ike) draft
On Tue, 20 Nov 2001, Ari Huttunen wrote:
> I read through some of this draft, and mainly I'd say it looks very
> good. At least when compared to the current RFCs. Comments follow.
>
> - If, as I understand, there is to be a 'selection' as to what will
> be the next IKE, what chance has anybody against a protocol that is
> named draft-ietf-ipsec-ikev2-00.txt?
>
> As to the specifics of this protocol, in my view IKEv2 should have
> these kinds of requirements:
>
> - IKEv2 must enable all traffic to be protected as well as possible.
> If there is no common authentication method, a method to do just
> encryption should be provided.
>
> - IKEv2 must be well defined. For example, this draft doesn't state
> clearly how the critical bit is to be used (for each payload), notifies
> are unclear and should be accompanied by a state machine.
> I.e. if a cert payload with critical bit contains a DSS-signature,
> is it critical that you know "cert payload", support DSS-signatures, or what?
>
> - I have a strong dislike for the current VID method. It fails to
> provide several key requirements:
I've also long hated the VID method. I prefer the Radius Vendor-Specific
Attribute method. Why not just have that concept? That reolves at least the
collision issue below, and probably all others. Make the payload contain ike
attribute after a header that CLEARLY defines the vendor.
> a) Some problems are best solved by having a new payload in the
> first message. Like in ESPUDP IKE negotiation we could have used
> such a payload, but it's not possible with VIDs. (The bad thing about
> this is that it's not easy to change the protocol structure when
> official numbers are assigned.)
> b) A VID does not define how the protocol is to be extended, it
> just says that after you see this, you can twist IKE as much
> as you want.
> c) A VID does nothing to prevent conflicts between two drafts that
> just happen to allocate the same private use number.
>
> Here's an alternative to VIDs that we could consider:
> - A new payload is defined that defines exactly what private use numbers
> an implementation uses and what they are used for. In this way the private
> use numbers are viewed as variables, i.e.
> #define PAYLOAD_TYPE_128 "draft-my-draft-whatever-00.txt:nonce-thingie"
> etc., or use an OID instead
> - The initiator sends that in the first message, and following that payload
> a payload of type 128 may occur in the same message. The responder sends
> them in the first reply.
> - Responder will map only private use attributes that don't conflict with
> the initiator's choices. So a draft will never say "payload number 128",
> it will say "private payload that maps to xxxx".
>
>
> - IKEv2 would be easier to test if a method to authenticate using preshared
> secrets was provided. Like, how about hmac-sha-1 signatures?
>
I believe 'testing' was the justification for pre-shared keys in the last
round and now we can't get rid of it and even have group-keys. Gah! What's so
hard about configuring an RSA key?
jan
> Ari
>
>
> Radia Perlman - Boston Center for Networking wrote:
> >
> > And to answer some of the recent email on the list...this
> > protocol does maintain the phase 1/phase 2 notion, but sets up
> > both phase 1 and phase 2 in a single 2-round-trip exchange.
> > After the initial exchange, additional SAs can be set up,
> > or the SA can be rekeyed, with a single round trip. And it
> > does identity hiding of both ends.
> >
> > Most of the work was in rewriting the three documents into
> > a single self-contained document, and cleaning up the "networking"
> > type issues and overly complex encodings such as
> > the SA payload.
> >
> > Radia
> > ------------- Begin Forwarded Message -------------
> >
> > To: ipsec@lists.tislabs.com
> > From: dharkins@tibernian.com
> > Subject: IKEv2 (son-of-ike) draft
> > MIME-Version: 1.0
> > Content-ID: <2377.1006067452.1@SailPix.com>
> >
> > This draft was submitted but hasn't shown up yet in the repository
> > (the I-D editor is, no doubt, swamped) so in the interest of giving
> > people more time to look at it prior to Salt Lake here's a link:
> >
> > http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt
> >
> > Please send comments to the list.
> >
> > Dan.
> >
> > ------------- End Forwarded Message -------------
>
> --
> "They that can give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety." - Benjamin Franklin
>
> Ari Huttunen phone: +358 9 2520 0700
> Software Architect fax : +358 9 2520 5001
>
> F-Secure Corporation http://www.F-Secure.com
>
> F(ully)-Secure products: Securing the Mobile Enterprise
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: