wpa_supplicant failure in "Server Fail Fallback" switch setup - rfc4137 EAP Peer State Machine in eap.c

[Shahid Mahmood]

Mahmood, Shahid (Shahid <mahmoods <at> avaya.com> writes:

> 
> 
> 
> Hello,
> We have a situation where a Juniper Networks switch is configured in a
?Server Fail Fallback? mode. See:
>
http://www.juniper.net/techpubs/en_US/junos12.2/topics/task/configuration/802-1x-server-fail-fallback-cli.html
> In this mode, the switch sends an ?EAP-Success? to the device in response
to just an ?EAP-Request-ID?, without going through the full cycle
authentication.
> Roughly, the transaction looks like this:
> 1) Switch: ===> EAP-Request-ID
> 2) Device:===> EAP-Response-ID
> 3) Switch: ===> EAP-Success
> 4) Device goes to a FAILURE state
> Notice there is no ?EAP-Request-MD5/TLS? coming in from the switch.
> ?
> The device, running a wpa_supplicant (0.5-10) lands here:
> -- eap.c: SM_STEP(EAP)
> {
> ?
> ??????????????????????????????? else if (sm->methodState != METHOD_CONT &&
> ??????????????????????????????????????????????? ((sm->rxFailure &&
> ??????????????????????????????????????????????? ?? sm->decision !=
DECISION_UNCOND_SUCC) ||
> ??????????????????????????????????????????????? ? (sm->rxSuccess &&
sm->decision == DECISION_FAIL &&
> ??????????????????????????????????????????????? ?? (sm->selectedMethod !=
EAP_TYPE_LEAP ||
> ??????????????????????????????????????????????? ??? sm->methodState !=
METHOD_MAY_CONT))) &&
> ??????????????????????????????????????????????? (sm->reqId == sm->lastId ||
> ??????????????????????????????????????????????? ?
eap_success_workaround(sm, sm->reqId, sm->lastId)))
> ==>???????????????????????????????????????? SM_ENTER(EAP, FAILURE);
> ..
> }
> At this point, sm->rxSuccess *is* true but sm->decision == DECISION_FAIL,
due to initial condition. This effectively decides the final state
transition, in this case, a FAILURE. rxReq is also false but ignored here.
> ?
> Although eap.c appears to correctly implement the intent of rfc4137
(specifically page 8 Figure 3: ?EAP Peer State Machine?) this obviously
contradicts the expectations from the switch folks.
> ?
> Questions:
> - Has anyone experienced this? If so, how was that handled?
> - Is this a limitation of rfc 4137 or the implementation? (or both).
> If answer is ?no? to all, I would like to know how this configuration can
be supported.
> ?
> Otherwise, I can share a patch for review, which addresses this scenario.
> ?
> Appreciate your time,
> ?


Here is a patch for review. This patch adds handling of "Server Fail
Fallback" configuration in the switch. Authentication happens without
involving RADIUS. wpa_supplicant is running in -D"wired" mode.

VERSION_STR "0.5.10":
---- patch starts --------
diff --git a/eap.c b/eap.c
index 8072d04..7cf3636
--- a/eap.c
+++ b/eap.c
@@ -648,6 +648,12 @@ SM_STEP(EAP)
                    (sm->reqId == sm->lastId ||
                     eap_success_workaround(sm, sm->reqId, sm->lastId)))
                        SM_ENTER(EAP, SUCCESS);
+/* >> AVAYA - Handle switch "Failover", when Success is sent without
authentication */
+               else if (sm->rxSuccess && !sm->rxFailure && !sm->rxReq &&
(sm->reqId == sm->lastId))
+               {
+                  SM_ENTER(EAP, SUCCESS);
+               }
+/* << AVAYA */
                else if (sm->methodState != METHOD_CONT &&
                         ((sm->rxFailure &&
                           sm->decision != DECISION_UNCOND_SUCC) ||
@@ -1191,7 +1197,6 @@ struct eap_sm * eap_sm_init(void *eapol_ctx, struct
eapol_callbacks *eapol_cb,
        sm->eapol_ctx = eapol_ctx;
        sm->eapol_cb = eapol_cb;
        sm->msg_ctx = msg_ctx;
-       sm->ClientTimeout = 60;

        os_memset(&tlsconf, 0, sizeof(tlsconf));
        tlsconf.opensc_engine_path = conf->opensc_engine_path;

------- patch ends -----------------

Regards,
Shahid Mahmood
Avaya Inc, Canada