Re: Final editing changes to IKEv2

[Yoav Nir <ynir@netvision.net.il>]

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.