802.1X-2004 FORCE_AUTH supplicant behavior

[Phillips, Owain]

Hi All,

I am using 0.7.3 wpa_supplicant and have come across the following issue.

802.1x Wired Supplicant has credentials loaded for PEAP or EAP-TLS.
Access switch is NOT configured for PEAP of EAP-TLS (seen with 3Com Corebuilder, Enterasys C3 - Forced Auth).

The Authenticator responds to our EAPoL Start with an immediate EAP-Success.
This does NOT result in any event sent by the supplicant; it just spins running through sequence send EAPol Start, then receive EAP-Success.

My endpoint gets no event from the supplicant to kick the system on to start DHCP.

Looking more closely into the supplicant code I see in src/eap_peer/eap.c  a routine eap_success_workaround() that is used in eap_peer_sm_step_received() to determine if the EAP statemachine is pushed to SUCCESS or FAILURE state.

What we were seeing is the control taking one of two paths depending on the identifier in the EAP-Success. In eap_success_workaround()  the difference between the reqId and the lastId was used to determine if we were to kick the State Machine or not. As the lastId is always -1 (we haven't sent a EAP-Req only EAPoLstart - no identifier!!); depending on what id the authenticator placed into the EAP-Success (arbitrary value) we either kick the SM into FAILURE state or do nothing.

I have modified eap_success_workaround such that if lastId is ever -1; then we always respond such that the SM is kicked (to FAILURE ).
This means for these Forced Authenticated cases where we see EAPoL Start followed by an immediate EAP-Success. The supplicant will always send an event and NOT be silent.

This does not seem to break our configuration for EAP-TLS or PEAP; but I don't know if there are other side effects for other protocols. It means I get kicked to start DHCP as switch said EAP-Success (you have a network connection).

Is this a reasonable fix. 
How does wpa_supplicant normally cope with this FORCE_AUTH case?

I quote 802.1X-2004.....

8.2.4.11 FORCE_AUTH
....
The authPortStatus is set to Authorized, and a "canned" EAP Success packet (i.e., a message constructed by
the Authenticator rather than sent by the Authentication Server) is sent to the Supplicant. If an EAPOL-Start
message is received from the Supplicant, the state is re-entered and a further EAP Success message is sent.
The effect of this set of actions is to force the Port state to Authorized, and to reflect this state back to the
Supplicant if it should initiate authentication, thereby removing unnecessary delays before the Supplicant
assumes that it has been authenticated successfully.


Anyone got any advice?

Kind Regards,
Owain
?