PMF - Protected Management Frames
IEEE 802.11w-2009 (merged into 802.11-2012, now part of IEEE 802.11-2020) adds cryptographic protection to a subset of management frames - preventing deauth/disassoc spoofing, the backbone of every deauth flood and evil twin attack. WPA3 makes PMF mandatory.
The Problem PMF Solves
Before 802.11w, Deauthentication and Disassociation frames were transmitted in cleartext with no integrity protection. Any device with a packet injector could forge them with a spoofed BSSID and force every client off the network - no credentials required. MDK3 and aireplay-ng have been doing this since 2006.
Attacker spoofs AP BSSID, sends broadcast Deauth (Reason Code 6 or 7) at high rate. Clients disconnect immediately - no way to verify frame authenticity. Repeats indefinitely, preventing re-association.
Attacker deauths clients from legitimate AP, sets up rogue AP with same SSID. Clients reconnect to attacker. HTTP traffic captured; HTTPS requires additional downgrade. EAP-TLS prevents this via server cert validation.
Unicast Deauth/Disassoc frames encrypted under PTK. Spoofed frames fail MIC verification - client ignores them silently. Broadcast frames protected by IGTK + BIP integrity. Attacker without PTK cannot forge valid management frames.
Robust Management Frames - Protected by 802.11w
Not all management frames are protected - only "robust" ones, defined by IEEE 802.11-2020 Section 4.10.6. Non-robust frames (Beacon, Probe Req/Resp, Auth, Assoc Req/Resp) remain unprotected by design.
Beacon frames are NOT protected by PMF. An attacker can still inject fake Beacons (e.g., to cause CSA chaos or SSID confusion). BSS Coloring and WPA3-SAE help with some of these scenarios but Beacon protection remains an open problem in the standard as of 802.11-2020.
RSN IE Negotiation - MFPC and MFPR Bits
PMF capability and requirement are negotiated via the RSN Capabilities field (2 bytes) in the RSN Information Element. The AP advertises support in Beacon and Probe Response frames; the client responds in Association Request.
| Configuration | MFPC (bit 7) | MFPR (bit 6) | Behaviour | Use case |
|---|---|---|---|---|
| PMF Disabled | 0 | 0 | No management frame protection. All mgmt frames in cleartext. | Legacy WPA2 networks - vulnerable to deauth flood |
| PMF Optional (capable) | 1 | 0 | PMF-capable clients use protection; non-PMF clients still allowed. Mixed mode. | WPA2 migration - supports both PMF and legacy clients |
| PMF Required (mandatory) | 1 | 1 | MFPR=1 forces all clients to use PMF. Non-PMF clients rejected (Status Code 30). | WPA3 (mandatory), high-security WPA2 deployments |
If an AP has MFPR=1 and a client attempts to associate without PMF support, the AP rejects with Status Code 30: Robust Management Frame Policy Violation. In WPA3-only networks, this is the expected rejection for legacy WPA2-only clients. You will see this in Assoc Response frames in PCAP - frames are not encrypted so the status code is visible.
The fastest way to confirm 802.11w is active in a PCAP: look for the Group Management Cipher Suite field in the RSN IE (OUI 00-0F-AC, Suite type 06 = BIP-CMAC-128). Its presence means the AP is protecting broadcast/multicast management frames. Absent means 802.11w is off regardless of MFPC/MFPR bits.
Protection Mechanisms - Unicast vs Broadcast
Unicast Deauth, Disassoc, and robust Action frames are encrypted using the Pairwise Transient Key - the same key protecting data frames. The Frame Control Protected Frame bit (bit 6) is set to 1.
Broadcast/multicast management frames cannot be encrypted (every client must read them) but are integrity-protected. The IGTK (Integrity Group Temporal Key) + BIP (Broadcast/Multicast Integrity Protocol) appends a Management MIC Element (MME) to the frame body.
SA Query - Security Association Teardown Protection
When a client loses its keys (driver crash, device reboot) and sends an unprotected Association Request to re-join, the AP has a valid SA on file for that client. The AP cannot immediately accept - that would allow an attacker to hijack a session. SA Query is the verification mechanism.
SA Query frames appear as Action frames (frame type 0, subtype 13). Category = 8 (SA Query). Action = 0 (Request) or 1 (Response). Transaction ID is a random 2-byte value - request and response carry the same value. If you see SA Query Requests without matching Responses, a client is being disconnected and cannot re-authenticate - potential PMF compatibility issue.
WPA3 and PMF Requirement
Identifying PMF in a PCAP
wlan.fc.type == 0 && wlan.fc.subtype == 12 && wlan.fc.protected == 0 Catches unprotected Deauth frames. On a PMF=required SSID, every frame this filter returns is a spoofed/rogue frame and should be investigated.
In Wi-Fi 7 deployments using mixed WPA2/WPA3 transition mode, Android devices on certain builds fail to complete association on PMF-required SSIDs due to a mismatch between the device's reported RSN IE in the Assoc Request and the AP's MFPR requirement - the device indicates MFPC=0 despite advertising WPA3 support in the beacon scan. This failure is silent at the UI layer (user sees "connected" briefly then drops) and invisible above L2. The only diagnostic is the Assoc Response Status Code 30 in the PCAP. This is documented as the PMF Compatibility Gap - one of three failure modes analysed in ongoing IEEE 802.11 ARP/PMF research.