[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: