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

RE: clarification on IKEv2 with EAP




Hi, and thanks for the quick reply.
Yes, I was talking about the AUTH payloads generated after the EAP exchange.
I hadn't realize there was already a version 13, I was still using version 12. Anyway, the new one does not make things completely clear to me yet. I will give my interpretation of chapter 16 and please confirm if it is correct.
- The EAP payloads are sent in the IKEv2 messages without AUTH payloads. The AUTH payloads are sent only in the last two IKEv2 messages, and they correspond to the last two EAP messages, that is, AUTH in message 7 to EAP payload in message 5, and AUTH in message 8 to EAP payload in message 6
- Since the AUTH payloads correspond to the two last messages and they are only sent in the two last IKEv2 messages, if the EAP messages exchanged are more than showed in the diagram, the rest of the EAP messages before the last two ones are not authenticated with AUTH payloads, even in the EAP method had obtained previously the key material needed to generate the AUTH (and hence it could be possible to protect previous EAP messages).

Is this correct ?

BR,
David.
 

-----Original Message-----
From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com]
Sent: jueves, 01 de abril de 2004 12:07
To: David Mariblanca (ML/EEM); 'ipsec@lists.tislabs.com'
Subject: RE: clarification on IKEv2 with EAP


hi david,

> Hi again,
> I would like to raise other questions:
> - When generating the AUTH, one input is the "Key Pad for 
> IKEv2", which is supposed to be used in password based 
> authentications, correct ?

with eap authentication in ikev2 there are three AUTH payloads. the AUTH
payload in message 4 from the responder to the initiator is based on the
chosen IKEv2 authentication mechanism. i guess you are not talking about
this AUTH payload. 

for the AUTH payloads which are sent after the EAP protocol exchange
finished you use the key derived by the eap method. you can find a more
detailed description in section 2.16 of <draft-ietf-ipsec-ikev2-13.txt>.

> What happens when the user 
> authentication is not based in passwords ?

from this perspective, key derivation is independent of the credentials
(symmetric or asymmetric) used for authentication was based. 

 In that case, can 
> this string be omitted as input to the prf, or can be 
> assigned a fixed value instead ?
> - If the EAP method being used already provides a message 
> authentication mechanism, does the AUTH have to be computed 
> anyway ?

even if the EAP method provides mutual authentication and key derivation
(and many other security properties) you still have to exchange the AUTH
payloads between the IKEv2 peer to prevent a man-in-the-middle attack. for
more details please take a look at: 

   [EAPMITM]  Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle
              in Tunneled Authentication Protocols",
              http://eprint.iacr.org/2002/163, November 2002.

> Or only in the cases where the EAP message is not 
> protected by itself, the AUTH has to be used ?
the fact that some eap methods protect some of their payloads is independent
of this issue. 

> 
> Thanks for your time, but I foresee I may come back again 
> with more questions...
> Cheers,
> David.

ciao
hannes

> 
> -----Original Message-----
> From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com]
> Sent: miércoles, 31 de marzo de 2004 14:07
> To: David Mariblanca (ML/EEM); 'ipsec@lists.tislabs.com'
> Subject: RE: clarification on IKEv2 with EAP
> 
> 
> hi david, 
> 
> the AUTH payload in message 4 (from the responder to the 
> initiator) is not
> based on the keying material of an eap method authentication and key
> exchange run. hence, it most likely uses public key based 
> authentication. 
> 
> ciao
> hannes
> 
> 
> > -----Original Message-----
> > From: David Mariblanca (ML/EEM) 
[mailto:david.mariblanca@ericsson.com]
> Sent: Wednesday, March 31, 2004 12:37 PM
> To: 'ipsec@lists.tislabs.com'
> Subject: clarification on IKEv2 with EAP
> 
> 
> 
> Hi,
> I am reading the IKEv2 i-d and I have a question in chapter 
> 2.16, about the usage of EAP methods over IKEv2.
> The sequence diagram with the process is the following 
> (copied from the paper):
> 
>        Initiator                          Responder
>       -----------                        -----------
>        HDR, SAi1, KEi, Ni         -->
> 
>                                   <--    HDR, SAr1, KEr, Nr, [CERTREQ]
> 
>        HDR, SK {IDi, [CERTREQ,] [IDr,]
>                 SAi2, TSi, TSr}   -->
> 
>                                   <--    HDR, SK {IDr, [CERT,] AUTH,
>                                                 EAP }
> 
>        HDR, SK {EAP, AUTH}     -->
> 
>                                   <--    HDR, SK {EAP, AUTH,
>                                                   SAr2, TSi, TSr }
> 
> 
> As written in the paper, the initiator omits the AUTH payload 
> in message 3 when it wants to use EAP. Later on, it is 
> written that when the whole EAP message is finished, the 
> resultant shared secret (if exists) is used to generate the 
> AUTH in messages 5 and 6. My question is: what about AUTH in 
> message 4 ? How is it generated ?
> 
> Thanks and best regards,
> David.
> 
>