Subject: RE: Final editing changes to IKEv2

From: Yoav Nir <[email-masked]>
Date: Fri, 19 Mar 2004 07:59:16 +0200

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...
>
> Best regards,
> Pasi

---

From: Yoav Nir <[email-masked]>
Date: Fri, 19 Mar 2004 17:17:55 +0200

Well, at least in the case of non-KG EAP methods, the EAP state machine 
exports no key to the client, so there is no reason to delay the AUTH 
payload until after the EAP success message.

I've just looked in draft-ietf-eap-statemachine-02.pdf.  There is a 
strange inconsistency on page 11.  The key is exported in eapKeyData 
"when keying material becomes available".  However, the eapKeyAvailable 
is set to true only "in the SUCCESS state".  Why is it that the peer 
cannot use the eapKeyData if it is available before the success message 
arrived?

To sum up my objections, can we skip the extra roundtrip if the client 
either has no key (non-KG method) or already has the key (for KG 
methods) ?

On 19/03/2004, at 16:28, Jari Arkko wrote:

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Mar 2004 16:28:33 +0200

(EAP WG co-chair hat on)

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