On 1/31/2008 6:23 AM, Yoshihiro Ohba wrote:
On Wed, Jan 30, 2008 at 10:53:25PM -0800, Lakshminath Dondeti wrote:
... hence the
authenticator initiation of the ERP exchange may require the
authenticator to send both the EAP-Request/Identity and EAP-Initiate/
Re-auth-Start messages.
Yes.
Have existing EAP peer implementations been validated to work under
these assumptions? i.e. will they break? Will they see "unexpected"
EAP messages or content, and reject or discard the response?
Kedar noted from his implementation experience and it worked with
hostap/wpa_supplicant.
Shouldn't compliant implementations discard EAP messages with unknown codes?
I am rather concerned with authenticator behavior. Since EAP is
designed as a lock-step protocol which only supports a single packet
in flight, allowing two outstanding requests breaks one basic design
principle of EAP. In order to allow two outstanding requests, I would
expect significant modifications to EAP state machines described in
RFC 4137, and such modifications should be described in ERP document.
Hi Yoshi,
We have had these discussions in the WG. The consensus was that there
may be a notion of an ERP state machine and it interacts with the EAP
state machine.
regards,
Lakshminath
Yoshihiro Ohba
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf