eap Mailing List: RE: impacts of IKEv2 early use of keying material

[Joseph Salowey (jsalowey]

eap-admin [at] frascone.com wrote:
> In the last couple of days, there's been a discussion in the
> IPsec WG about the exact time when a key is available from
> EAP. It turns out that if the key is available at the client
> side only after EAP Success has been received, an additional
> roundtrip will be needed in IKEv2 when EAP is used. If the
> client can use the key after having sent its last response
> message, this roundtrip can be avoided. For a more in-depth
> view to the issue, see the end of this e-mail where I have
> copied some text from messages by Pasi, Hannes and Yoav Nir
> on the IPsec list.
> 
> It looks like RFC 2284bis, which just got approved, does
> not say anything about this. The state machine document,
> however, appears to set eapKeyAvailable only after EAP
> Success has been received. (The eapKeyData variable, however,
> is set immediately.)
> 
> The question for EAP WG is as follows:
> 
> 1) Is the above summary of the situation wrt 2284bis and     state
> machine correct? 
> 
[Joe] In section 4.2 of 2284bis it provides for lost success messages so it
seems that EAP-Success is not strictly required. 


> 2) If a change would be made in the state machine document
>     to make the key available sooner, would this cause any    
> problems to 
> 
>       o RFC 2284bis
>       o Other parts of the state machine
>       o 802.11 interfaces
>       o Something else
> 
[Joe] It could be possible for a method to be designed such that the client
doesn't know when the server is done.  In this case the keys will be made
available before the method is done.  In this case new keys would have to be
obtained for each round the client though it was done.  I don't think
current key deriving EAP methods exhibit this behavior, but It is not
eliminated by the 2284bis.

> 3) What's your preferred approach?
> 
[Joe]Allow the key to be available once the Peer thinks it has completed
successfully.   

> 4) Other comments?
> 
[Joe] There may be an additional problem.  There is nothing stopping a
method from exhibiting the following behavior:  the client thinks it is
done, but the server requires another message exchange.  In this case there
may be more than one AUTH message sent by the client.  Would this cause a
problem in IKEv2?  If it does then an additional constraint must be placed
on the EAP mechanisms used in IKE.  The client must know when the EAP
mechanism has completed and no more challenges will be issued from the
server (the client may not know what the actual sever decision is since that
will be communicated through other means).  I think most methods adhere to
this.

> I have sent an e-mail to the IPsec list stating that its
> desirable to not change 2284bis but changes to the state
> machine are in theory possible unless they impact something else.
> 
> I'll summarize the responses to the IPsec list.
> 
> --Jari
> 
> --------------Pasi said------------------
> 
> Having the responder send the AUTH payload and EAP-Success
> in the same message is OK. However, this does not solve the
> initiator's case. "As soon as it can" is still a bit
> ambigous, and in draft -12 the initiator sends the AUTH
> payload _before_ receiving EAP-Success. But EAP peer state
> machine currently "exports" the key only _after_ receiving
> EAP-Success. 
> 
> So it seems that we need to either slightly change how EAP
> works or add another roundtrip. Both options are certainly
> feasible, but IMHO the latter requires less work...
> 
> --------------Hannes said----------------
> 
> in the past people have worried a lot about the number of
> roundtrips. so far there was no protocol example where the
> keys have to be exported before receiving the eap-success
> message. ikev2, however, seems to be one.
> 
> to be more specific the following two variants are on the
> table (if we use eap-aka as an eap method within ikev2):
> 
> Variant I:
> 
> AUTH payload sent by the initiator before receiving the EAP
> success message.
> 
> 
>        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-Request/AKA-Challenge (AT_RAND,
> AT_AUTN, AT_MAC) }
> 
>         HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC),
> AUTH}     -->
> 
>                                    <--    HDR, SK {EAP-Success, AUTH,
>                                                    SAr2, TSi, TSr }
> 
> 
> Variant II:
> 
> AUTH payload sent by the initiator after receiving the EAP
> success message.
> consequence: one additional roundtrip
> 
>        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-Request/AKA-Challenge (AT_RAND,
> AT_AUTN, AT_MAC) }
> 
>         HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)}     -->
> 
>                                    <--    HDR, SK {EAP-Success, AUTH}
> 
>           HDR, SK { AUTH }  -->
> 
>                                      <--   HDR, SK { SAr2, TSi, TSr }
> 
> ------------Yoav Nir said------------------
> 
> How about this:  The client will send the AUTH payload as
> soon as it can, this can be before or after the EAP-success
> message, depending on protocol and implementation.
> 
> The server will cache the AUTH payload as soon as it is
> received.  It will only verify the client's AUTH and send the
> {AUTH, SAr2, TSi, TSr} when both conditions are met: (1) The
> EAP success has been received from the EAP state machine, and
> (2) The AUTH payload has been received from the peer.
> 
> If we go against draft-ietf-rfc2284bis-09 and use OTP or GTC
> to transfer cleartext passwords (which is OK because the
> channel is encrypted) there is no key and the client can send
> the AUTH payload in message #5, and the whole exchange can be
> done by message #6.  If some method generates a key, but the
> EAP state machine cannot figure it out before getting the
> success message, then there is no choice, and we need an
> extra roundtrip after the success message.
> 
> Does this sound reasonable?
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap