[PATCH] wpa_supplicant failure in "Server Fail Fallback"

[Jouni Malinen]

On Thu, Apr 03, 2014 at 08:54:01PM +0000, Shahid Mahmood wrote:
> The following patch addresses the situation when wpa_supplicant goes into a
> failed state in a certain switch configuration.
> 
> Some switches, such as those from Juniper Networks, allow a so called
> "Server Fail Fallback" mode, in which case, if the RADIUS server is
> unreachable, the switch itself makes EAP-Success or EAP-Fail decisions.
> 
> 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
> 
> There is no ?EAP-Request-MD5/TLS? coming in from the switch. wpa_supplicant
> goes into FAILED state.

This does not really look like a valid EAP authentication session (and
same goes for the earlier email exchange regarding EAP-Success
immediately after EAPOL-Start, i.e., without EAP-Identity exchange).

> I checked the RFC 4137 and the behavior seems to reflect correctly what is
> mentioned in Fig 3 "EAP Peer State Machine". I have launched another probe
> into that direction. But with current state of the state machine in
> wpa_supplicant, thi type of switch configurations are impossible to support.
> I have also heard that Cisco switches can also support something like. I
> think it is reasonable to expect EAP clients (with wpa_supplicant) to
> respond in a meaningful way.
> 
> For that, I am proposing the following patch (which has been tested with
> this and other common scenarios):
> The wpa_suppicant version: 0.5.10, in "wired" mode.

I don't think that this would be acceptable. RFC 3748 is pretty clear on
the requirements:

   Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.  A peer EAP implementation
   receiving a Success or Failure packet where sending one is not
   explicitly permitted MUST silently discard it.  By default, an EAP
   peer MUST silently discard a "canned" Success packet (a Success
   packet sent immediately upon connection).  This ensures that a rogue
   authenticator will not be able to bypass mutual authentication by
   sending a Success packet prior to conclusion of the EAP method
   conversation.

In other words, at least the default behavior must remain to be
rejection of these sequences. That said, it is clear that many wired
switches use these forced authorized/unauthorized and
fallback-on-server-unavailable sequences. I'll add a configuration
parameter phase1="allow_canned_success=1" that can be used to configure
wpa_supplicant to accept these special cases as a valid EAP-Success or
EAP-Failure frame. This should be used only with wired IEEE 802.1X and
only in cases where the peer device does not need to authenticate the
switch/authenticator/authentication server.

-- 
Jouni Malinen                                            PGP id EFC895FA