Subject: RE: Final editing changes to IKEv2

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 19 Mar 2004 17:59:07 +0100

hi jari, 

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 }

you mention that 'Changing the protocol document is not a good idea'. which
protocol document do you mean?
a) draft-ietf-rfc2284bis-09.txt or 
b) draft-ietf-ipsec-ikev2-12.txt

are there modifications required to either (a) or (b)? i don't think so. 

is there something in the text of (a) which addresses our issue here? 
(b) is vague about when the auth payload has to be sent. hence it would only
be a clarification. 

hence, this issue seems to be more applicable to the state machine. pasi or
some other state machine authors might want to comment on this issue. 

i agree with yoav that responders should be prepared to handle both cases.
if the eap client is integrated into the ikev2 implementation then the
additional roundtrip can be avoided. your concern about the two different
eap client implementations might not be an issue in most cases (particularly
if i think about the non-standardized api which caused me some troubles -
but that's another story).      

ciao
hannes

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, March 19, 2004 3:29 PM
> To: Yoav Nir; Pasi Eronen
> Cc: [email-masked]
> Subject: Re: Final editing changes to IKEv2
> 
> 
> 
> (EAP WG co-chair hat on)
> 
> I think it would be good if we could avoid having two
> different EAP clients depending on whether EAP is used
> in IKEv2 or for, say, 802.11 authentication.
> 
> The behaviour of EAP is defined in
> draft-ietf-rfc2284bis-09.txt (recently approved by
> IESG) and draft-ietf-eap-statemachine-02.pdf (completed
> WG last call). As Pasi states, the client state machine
> currently exports keys only after having received the
> success packet.
> 
> Pasi, I think in this case this behaviour is only what
> the state machine says, not something that is required
> in the protocol document that IESG approved. Or?
> 
> Changing the protocol document is not a good idea, but
> is there a way to change the state machine so that it
> would provide the client side key sooner? Would this be
> possible without impacts to either the protocol definition
> or the interface towards methods or 802.11 state machines
> and protocols (which we spent a lot of time to get right)?
> 
> If yes, maybe we should consider what Yoav says below.
> If no, I think the right thing is to add the roundtrip
> and not create differently behaving EAP implementations
> depending on for what purpose they are...
> 
> --Jari
> 
> Yoav Nir wrote:
> > How about this:
> > 
> > The responder (gateway) sends the AUTH and the child-sa 
> response in a 
> > response message following the initiator (client) AUTH payload.
> > 
> > If the client has the EAP machine integrated, this is 
> before receiving 
> > the EAP success.  If it isn't then we may need an extra 
> round trip.  If 
> > the client can't tell that the EAP neg has ended until she gets the 
> > EAP-success (imagine a protocol where the server sends 
> several personal 
> > questions), then the extra round-trip in necessary.
> > 
> > I think in the general case the extra round trip will not 
> be necessary, 
> > but gateways will be required to support both cases.
> > 
> > Is this OK?
> > 
> > Yoav
> > 
> >>
> >> Hi,
> >>
> >> 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...
> 
> 
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 19 Mar 2004 20:30:44 +0200

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?

---

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

Hannes,

(I do worry about number of roundtrips.)

When I said that changing the protocol document would be
a bad idea, I was referring to draft-ietf-rfc2284bis-09.txt
which has already been approved by IESG; changes to draft-
ietf-eap-statemachine-02.pdf or draft-ietf-ipsec-ikev2-12.txt
would, however, still be possible, as long as they don't
break something else. And I do think making EAP behave the
same way in different contexts is valuable.

About the solution: I'm ready to go either way on this issue,
and of course if its possible we should use the smaller number
of roundtrips. But at this point I'd wait for Pasi, who is one of
the authors of the state machine document, to comment on whether
he thinks the change would have impacts elsewhere, e.g., 802.11
interface. Pasi?

I will also post a note of this discussion to the EAP WG mailing
list in case other folks wish to comment.

--Jari