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. Yoshihiro Ohba _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf