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

RE: Clarification of EAP authentication in IKEv2?



 
Hi Hannes,

Well, this is a modification of the protocol only if you 
assume that the first interpretation is the correct one
(public-key authentication of responder MUST be used). 
Otherwise, it's only a clarification of the document 
(and I think a clarification is needed even if the WG 
consensus is the first interpretation).

All EAP methods that are useful on, for instance, wireless 
LANs already provide mutual authentication and session key
generation. What do you mean by "fitting the minimal protocol
exchange"?

Best regards,
Pasi

> -----Original Message-----
> From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com]
> Sent: Thursday, December 18, 2003 3:07 PM
> To: Eronen Pasi (NRC/Helsinki); ipsec@lists.tislabs.com
> Subject: RE: Clarification of EAP authentication in IKEv2?
> 
> hi pasi, 
> 
> i remember some discussions in the past where we asked for
> minor modifications (e.g., user identity
> confidentiality). those modfications were rejected since it
> was already too late. this was more than 6 months ago.
> 
> now, you propose a modification which affects the core ikev2
> cryptography.  your proposal of moving the server-side
> authentication to a later stage in the protocol only works
> - if you have an eap method which exactly fits to the 
>   minimal protocol exchange shown in the draft and 
> - if you have this eap method offers the desired functionality 
>   (mutual authentication, session key generation)
> 
> if you additionally consider the possible implications to the 
> security properties do you think that it is a good idea to add 
> this new 'interpretiation'?
> 
> ciao
> hannes
> 
> btw, during our early pana work we noticed the above-describe
> circumstance which lead us to create pana differently instead
> of relying on ikev2 (since pana only relies on the session
> keys provided by the eap method in contrast to ikev2).
> 
> > -----Original Message-----
> > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> > Sent: Thursday, December 18, 2003 10:15 AM
> > To: ipsec@lists.tislabs.com
> > Subject: Clarification of EAP authentication in IKEv2?
> > 
> > 
> > (I'm sending this again, since for some reason my 
> > post on Tuesday didn't come through.)
> > 
> > 
> > Hi,
> > 
> > IKEv2-11, Section 2.16 says:
> > 
> >    In addition to authentication using public key signatures and
> >    shared secrets, IKE supports authentication using methods
> >    defined in RFC 2284 [EAP]. Typically, these methods are
> >    asymmetric (designed for a user authenticating to a server),
> >    and they may not be mutual. For this reason, these protocols
> >    are typically used to authenticate the initiator to the
> >    responder and are used in addition to a public key signature
> >    based authentication of the responder to the initiator.
> > 
> > Recently, some people have interpreted the last sentence as
> > "public key signature based authentication of the responder 
> > MUST be used".
> > 
> > Another possible interpretation is that _typically_ the responder 
> > is authenticated with public key signatures (for the reasons 
> > given earlier in the paragraph), but other alternatives (such 
> > as EAP method that provides mutual authentication, or even 
> > shared secret) may be possible in some circumstances.
> > 
> > Any comments?
> > 
> > Personally, I support the latter interpretation; since otherwise
> > only initiator authentication is extensible, not responder 
> > (and I think this would be an unnecessary limitation... after all,
> > if the point of EAP is to allow users to choose an authentication 
> > method that best suits their needs, why should this be limited 
> > to initiator authentication?). 
> > 
> > This could be perhaps clarified by adding the following 
> > paragraph below the sequence diagram:
> > 
> >    If the authentication of the responder is based solely on a
> >    mutually authenticating EAP method, the responder omits the
> >    AUTH payload from message 4. Alternatively, the responder 
> >    can be authenticated using either public key signatures or 
> >    a shared secret, in which case the AUTH payload in message 4 
> >    is calculated as described in Section 2.15.
> > 
> > Best regards,
> > Pasi		
> > 
>