Re: Final editing changes to IKEv2

[Jari Arkko <jari.arkko@kolumbus.fi>]

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