Re: clarification on IKEv2 with EAP

[Yoav Nir <ynir@checkpoint.com>]

Using the CERT or shared secret that are used to authenticate the 
Responder.  This is meant to prove the identity of the Responder.

The AUTH in the last message is signed (if possible) by the generated 
key.  This is meant to prove that the Responder is known to the EAP 
server, rather than just mounting a MITM attack on unsuspecting 
Initiators.

On Mar 31, 2004, at 1:37 PM, David Mariblanca (ML/EEM) wrote:

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