Potential Bug in 802.11 Open-Authentication State Machine

[Jinghao Shi]

+ my collaborators.

Hi Jouni,

Thanks very much for the clarification. The pointer to the 11.3.4.3
clause in the 802.11-2016 std is helpful (we're looking at
802.11-2012, which did not describe the process very clearly).

To give you some background, we're working on formal validation of
wireless protocol implementations. The approach is to utilize a
real-time reactive packet jammer (implemented on USRP) to drive the
protocol state machine into certain state to observe how the
implementation reacts. In this particular case, we used the jammer to
jam the ACK to AUTH_RESP packet and all following retransmissions of
the AUTH_RESP packet. We were trying to create a test-case where the
AP and the client disagree on the auth/assoc state. But apparently
this was taken into consideration in the protocol spec.

Does this make sense? Is there any other aspects where you envision
such technique might be useful?

Thanks,
Jinghao

On Fri, Jan 13, 2017 at 5:14 AM, Jouni Malinen <j at w1.fi> wrote:
> On Thu, Jan 12, 2017 at 03:49:30PM -0500, Jinghao Shi wrote:
>> From reading the code of hostapd. in
>> src/ap/ieee802_11.c:handle_auth_cb function,
>> it seems the success of the AUTH response packet is required for the AP to
>> consider the client as authenticated (if the AUTH response packet failed
>> (ok=0), the function will return immediately without setting the
>> WLAN_STA_AUTH flag of the sta), which makes sense.
>>
>> However, when open authentication is used, hostapd marks the client as
>> authenticated as soon as it receives the AUTH request packet (
>> src/ap/ieee802_11.c:handle_auth). Does this violate the authentication
>> protocol as the AUTH response packet may not be successful?
>
> I don't think so. If the station continues with association, it looks
> clear that it received the Authentication frame from the AP.
>
>> I guess the ultimate question is: *should the AP consider the client as
>> authenticated if the AUTH response packet failed?*
>
> This should be a bit more specific on what "failed" means here. In this
> scenario, the station did actually receive the frame and it was the ACK
> frame that was lost.
>
> IEEE Std 802.11-2016 describes this in 11.3.4.3
> (Authentication--destination STA) procedure step (f). Authentication
> state changes on the AP when requesting the Authentication frame to be
> sent; not when the non-AP STA sends an ACK frame for this. This is
> different from the association process where it is the ACK frame that
> changes the state, not the Association Response frame transmission. You
> can find that description in 11.3.5.3 (AP or PCP association receipt
> procedures) step (l).
>
> --
> Jouni Malinen                                            PGP id EFC895FA