Potential Bug in 802.11 Open-Authentication State Machine

[Jinghao Shi]

Hi Jouni,

Thanks for the pointers. I did observed some peculiar behavior of the
assoc state machine. It's mostly at the client side (mac80211 MLME),
but I thought you may be interested as well.

In the experiment, the rate control policy was set to re-transmit the
packet at most once before reporting the packet as failed. This may
not be realistic in practice but helps reveal interesting behaviors
faster. The jamming policy I used was to jam the ack of the ASSOC_REQ
packet and it's retransmision, such that the client thinks the
ASSOC_REQ failed but the AP actually received the ASSOC_REQ packet.
That is:

 - ASSOC_REQ
 - ACK <--- jammed
 - ASSOC_REQ_RETRY <--- jammed
 - ASSOC_RESP
 - ACK
 - ...

I'm attaching the sniffer trace during this jamming session. From the
AP (hostapd)'s perspective, the client sends another ASSOC_REQ packet
after already acknowledging the ASSOC_RESP packet. And the EAPOL
handshake process seems confused too.

I'll ping the mac80211 mail list about why the client's behavior.
It'll be great if you can comment on the hostapd's logic in this
situation as well.

Thanks,
Jinghao



On Fri, Jan 13, 2017 at 5:14 PM, Jouni Malinen <j at w1.fi> wrote:
> On Fri, Jan 13, 2017 at 12:15:01PM -0500, Jinghao Shi wrote:
>> 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.
>
> While Authentication frame exchange is not applicable for that, you
> should be able to find difference in deployed AP implementations for
> association processing. I'd guess that number of APs do not really
> follow strictly the standard description on when the station becomes
> associated (when the AP receives the ACK frame to its Association
> Response frame with Status Code 0).. Not that this necessarily causes
> much issues in practice, but if you are looking for strict compliance
> with the standard, that would be one of the few cases where the ACK
> frame makes significant different for this type of management operation
> behavior.
>
>> Does this make sense? Is there any other aspects where you envision
>> such technique might be useful?
>
> I haven't really considered doing such testing by jamming frames over
> air. It's an interesting concept and can help with some testing cases.
> My main focus in testing protocol behavior is to use mac80211_hwsim and
> test builds that allow frame corruption or loss to be simulated.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repeated_assoc_req.pcap
Type: application/vnd.tcpdump.pcap
Size: 4193 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20170115/e6328338/attachment.pcap>