For a long time in the 802.11 space it is possible to encrypt data transmissions, however we were lacking encryption of the management frames. The IEEE 802.11w amendment added this functionality to the 802.11 standard and since July 1st 2014, the Wi-Fi Alliance (WFA) made the support of Protected Management Frames (PMF) mandatory to pass 802.11ac or Passpoint aka HotSpot2.0 R2 interoperability certification. So we will see a much greater adoption of this feature in the near future. The time has come to go deep into this feature and show you what has changed, what to look for in packet captures and how to set up an example for yourself.
This post is more or less based on the slides I showed in my WLPC_EU presentation, I will link the video here as soon as it becomes available.
Protected Management Frames
From now on you can protect the following management frames:
- Disassociate
- Deauthenticate
- Action Frames: Block ACK Request/Response (AddBA), QoS Admission Control, Radio Measurement, Spectrum Management, Fast BSS Transition
- Channel Switch Announcement directed to a client (Unicast)
Management frames that are required before AP and client have exchanged the transmission keys via the 4 way handshake remain unprotected:
- Beacons
- Probes
- Authentication
- Association
- Announcement Traffic Indication Message
- Channel Switch Announcement as Broadcast
Although it is said that frame headers are protected, this is only true for a certain part of the header, Radiotap and 802.11 Data header still remain unprotected.
New Encryption Mechanisms
These are the mechanisms used to protect unicasts as well as multi-/broadcasts:
Unicast Management Frames:
- Use same PTK as for data frames
- Protect the previously unencrypted frame header via additional authentication data (AAD)
- Extended AES-CCM to handle unicast management frames
- Separate Receive Sequence Counter (RSC) for replay protection
Broad-/Multicasts Management Frames:
- Use new Integrity Group Temporal Key (IGTK) received during WPA key handshake
- New Algorithm: Broadcast Integrity Protocol (BIP)
- New Inforamtion Element: Management MIC IE with Sequence Number + Cryptographic Hash (AES128-CMAC based)
Here is an example for a protected and valid Disassociate with the protected flag set and a valid management sequence counter:
PMF in Information Element(s)
The support for 802.11w is signalized within theAuth Key Management (AKM) of the 802.11i Information Element called Robust Security Network (RSN) found in Beacons or Probes. Without any PMF support, the IE looks kind of like this (WPA2-only):
RSN element with optional PMF support:
RSN element with required/mandatory PMF support:
As there are three options, the possible outcome of AP and client settings is given in the following table.
AP Scenario 1 (No Attack)
A client might lose its encryption keys due to a card reset or reboot and needs to (re-)associate itself. Since he lost all his keys, he sends an unprotected Association Request Frame. The AP still has a valid association from the client with keys in his client table, so the AP will first of all reject the Association and tell the client to try again in “X” seconds. After that, the AP tries to find out if this is an attack and the actual client can still answer protected frames.
The mechanism for that check is the Security Association (SA) Query phase, which starts with a protected SA Query Request from the AP to the client. If the client is unable to answer them until the comeback timeout “X” expires, the AP will send out a protected Disassociate and discards the keys for the no longer valid association of the client. As of now, a new (unprotected) Association Request from the client will be accepted.
The protected Disassociation is sent out to prohibit that a client with a valid association, which might be unable to answer SA Query Request due to low SNR or blocked transmission opportunity, knows that his association is no longer valid.
AP Scenario 2 (Attack)
If an attacker tries to associate with a spoofed MAC of a connected client. The AP will again start the SA Query phase, which the actual client can answer by an SA Query Response, so the AP just ignores the spoofed Association Request from the attacker.
Client Scenario 1 (No Attack)
An AP might lose its encryption keys due to a card reset or reboot and as soon as a previously associated client sends an encrypted data frame, the AP will try to force a reassociation by sending an unprotected Disassociate frame to the client. The client still has a valid association with the AP including the keys, so he tries to figure out if this is an attack and the actual AP can still answer protected frames.
The mechanism for that check is again the Security Association (SA) Query, which starts with a protected SA Query Request in this case from the client to the AP. If the AP is unable to answer them until the SA Query timeout “X” expires, the client discards the keys for the no longer valid association to the AP. As of now, the client needs to send an unprotected Association Request for a new association to the AP.
Client Scenario 2 (Attack)
If an attacker tries to disassociate a client or multiple clients via Broadcast with a spoofed MAC of the AP. The client will again start the SA Query phase, which the actual AP can answer by an SA Query Response, so the client just ignores the spoofed Disassociation from the attacker.
An unprotected Disassociate without no given reason code will be ignored by a .11w client, so a valid reason code for an attack would be 6 or 7 (Class 2/3 frame received from nonauthenticated STA).
Hard-/Software Support
This feature is supported by the following enterprise APs (feel free to mention more AP vendors in your comment and I will add them):
- Aerohive/Extreme
- AirTight/mojo/Arista
- Aruba Networks
- Cisco Systems
- LANCOM Systems
- Motorola/Symbol
- Ruckus
- Xirrus
Client support (feel free to mention more client vendors in your comment and I will add them):
- Microsoft Windows since Windows 8
- Intel since 726x-series
- Qualcomm Atheros since AR5BxB92 “Merlin”
- Samsung Galasy S6
- Playstation 4
See also reference [1] or use the WFA certification search: http://goo.gl/3Gk5lG
Conclusion
We finally see some encryption for management frames, which has been desired for a longer time. With the requirement for WFA certification of PMF for 11n, 11ac and Passpoint, we should be able to set this feature to optional, the required/mandatory flag can only be used if the client support is assured. It may be a rare case, but some hackers use the disassociate attacks to move clients to their own AP, which can now be prevented. An attacker can still send channel switch announcements to steer clients to his AP and of course as soon as an attacker is connected to the network with PMF, he or she is able to perform attacks with protected frames as well. So the remaining disturbance of client connections/transmissions without a network connection are RF jamming and CTS control frames with long reservation times.
References
Cisco on 802.11w
Benjamin Bertka: 802.11w Security DoS Attacks and Vulnerability Cotrols
[1] Cisco’s Device Classification Guide
Updates
*2014-10-22 Update 1: Added Conclusion*
*2019-01-03 Update 2: Use the correct term “Security Association”*
WLAN by german engineering 