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

RE: clarification on IKEv2 with EAP




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 ? What happens when the user authentication is not based in passwords ? 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 ? Or only in the cases where the EAP message is not protected by itself, the AUTH has to be used ?

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

-----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.
> 
>