802.1X-2004 FORCE_AUTH supplicant behavior

[Shahid Mahmood]

Phillips, Owain <owain.phillips <at> siemens-enterprise.com> writes:

> 
> 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
> ?
> 

I have the same situation, with same results. I filed a bug on
'http://w1.fi/bugz/show_bug.cgi?id=482' but the site has disappeared. 
I got around this by modifying the eap_success_workaround() by injecting a
success of lastId == -1 && sm->rxSuccess && !sm->rxFailure.