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

[Jari Arkko (jari.arkko]

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?

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

3) What's your preferred approach?

4) Other comments?

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?