Potential Bug in 802.11 Open-Authentication State Machine

[Jouni Malinen]

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