Subject: [eap] impacts of IKEv2 early use of keying material

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Mar 2004 22:45:05 +0200

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?

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 22 Mar 2004 09:11:56 -0800

[email-masked] wrote:
> 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. 

>       o Other parts of the state machine
[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.

> machine are in theory possible unless they impact something else.
> 
> 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...
> 
> 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:
> 
> 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.
>