[PATCH] wpa_supplicant failure in "Server Fail Fallback"
j at w1.fi
Sun Feb 1 12:32:03 EST 2015
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
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
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
Jouni Malinen PGP id EFC895FA
More information about the HostAP