802.11w, also termed as Protected Management Frames (PMF) Service, defines encryption for management frames. Unencrypted management frames makes wireless connection vulnerable to DoS Attacks as well as they cannot protect important information exchanged using management frames from eavesdroppers.
For encrypting unicast management frames, AES-CCM encryption protocol is used and the same PTK which is derived during 4 Way Key handshake is used. However, broadcast/multicast management frames uses BIP encryption protocol which uses CMAC instead of CBC-MAC (used by AES-CCM) for computing MIC. For encryption, BIP uses IGTK which is generated similar to GTK and passed to stations during 4 Way Key handshake & Group key handshake. Since, PTK & GTK are not available before 4 Way Key handshake hence all management frames before this handshake (beacons, probe request/response, association request/response, and authentication frame) remain unencrypted. Moreover, PMF can be supported in either WPA2-Personal or Enterprise but not with open security model as there is no encryption in it.
Following frames can break the existing wireless connection (without PMF support) and will lead to Denial of Service attack.
- Sending Deauth or Disassoc notification to AP
- Sending (Re) Association request to AP.
- Sending Auth frame to AP.
- Sending Deauth or Disassoc notification to Station
- Sending Channel switch announcement to Station.
All these attacks can be prevented using protected management frames. Just to reiterate, (Re) Association request & Auth frame remain unprotected in PMF.
PMF Support Indication:
RSN Capabilities field inside RSN IE of the Beacon & Probe Response frames (from AP) & (Re) Association request (from station) indicates whether PMF is Unsupported, Optional or Mandatory.
Other changes in frame structure include new “Group Management Cipher Suite” for BIP protocol inside RSN IE & introduction of MIC IE. Please refer to other sources for detailed changes in the frame structures.
Prevention of Denial of Service Attacks
- Sending spoofed Deauth or Disassoc frames to AP
As Deauth & Disassoc are protected under PMF, any such spoofed frames will be simply ignored by the AP.
- Sending spoofed Auth or (Re) Association frames to AP
AP cannot simply reject these frames from the connected clients as clients on sudden reboot can send new association request. To handle such cases, AP temporarily rejects the association request by requesting station to comeback after certain time (association-comeback time) and triggers SA Query mechanism with the client. In case of client reboot, the client would not respond to SA query (which is also protected) whereas in case of Spoofed Auth or (Re) Association request client will respond to SA query. Based on the result of query mechanism, AP can allow the next Association request from the client.
- Sending spoofed Deauth or Disassoc frames to Station
Station cannot simply reject as theses frames can be sent by AP if AP has sudden rebooted and is not aware about the old association with the client. In this case, station triggers SA Query mechanism with the AP and based on its result it figures out whether new association with that AP is required or is it simply the case of spoofed Deauth or Disassoc frame.
Clients supporting PMF
Moto X, Samsung Galaxy Note 4 are some of the mobiles supporting 11w.
- Deauth Attack: Sending of Deauth frames to AP & Station simultaneously can be done using aireplay-ng http://www.aircrack-ng.org/doku.php?id=deauthentication