802.11w-2009 – Protected Management Frames (PMF): Overview And Lab Tests

Introduction

The goal of the 802.11w amendment, which was ratified in 2009 and consolidated in the IEEE Std 802.11-2012, was to introduce a way to secure management frames against attacks.

The best known attacks this amendment should eliminate are the “deauthentication” and “disassociation” attacks, which can be used for multiple reasons:

•  L2 DoS attack of a unique client, a BSS or even every single STA that is in the reachable perimeter of the attacker
•  Forcing clients to authenticate and associate again:
  • can be used to get the SSID from a hidden network by capturing the association request
  • can be used to capture the 4 way handshake, which, in combination with the PSK, enables the attacker to decrypt the L2 frames.
  • can be used for a man in the middle attack by forcing the clients off of the current AP and onto a rogue AP

These attacks are done by the attacker sending out deauthentication or disassociation frames to clients with a faked transmitter address that matches the BSSID of the AP the client is currently connected to (and/or sending out the same frames with the faked client MAC address as the transmitter address to the AP).

You might wonder, why I am writing a blogpost about an amendment that was ratified almost a decade ago… The reason is: it is more relevant than ever! WPA3 is coming, and one of the main bullets for a STA to get the “Wi-Fi CERTIFIED WPA3” is “Require use of Protected Management Frames(PMF)”. So when we want to implement “real WPA3” in the future, we will inevitable face this topic one way or another.

Different Flavours of PMF

The securing of the management frames is done during the 4 way handshake, so PMF is only possible in encrypted networks (PSK or 802.1X).

There are 3 flavours of PMF configurable:

• None: either not configured/enabled, or not supported
• Capable/Optional: SSID supports PMF, but lets the client decide if he wants to use it or not
• Required/Mandatory: SSID supports PMF, and clients can only connect to the SSID if they support PMF aswell

You can check the RSN IE in the Beacon Frames of a network to identify which one of those is configured. In this example, PMF is configured as an option (bit set at “capable”), but is not mandatory (bit not set at “required”):

The cipher suite “BIP” (Broadcast/Multicast Integrity Protocol; AKM Suite 6) is part of the 802.11w extension aswell, and is used to protect multicast and broadcast management frames.

Lab Test

In my lab, I set up an SSID that is PMF-“capable”, and connected 2 clients: one of them supports PMF, the other one doesn’t.
First, I sent deauthentication frames from my AP to the clients, which based on the APs event log still worked:

When you compare the 2 deauthication frames, you can see that both are marked as “Deauthentication” (subtype 0x000c). But the frame sent to the non-PMF-client is all in cleartext…:

…while the frame sent to the PMF-client is encrypted:

For the second test, I tried to simulate an attack by sending out deauthentication frames using aireplay-ng, and it sent out both deauthentication frames in cleartext:

Due to the  “Protected Management Frame” function in place, I was only able to deauthenticate the client not using PMF.

Conclusion

In my opinion, keeping your encrypted WLANs “PMF-free” makes no sense, and you should test and enable the “optional” flavour of PMF if you have not done it yet. It is also a good way to get an overview of your clients’ PMF-capabilities by tracking their association details.

Additionally, I would only recommend to enable “mandatory” if a) you know all your clients and you are sure about their PMF capabilities, or b) you have 2 SSIDs (one for PMF capable clients, and one fallback for “legacy” devices).

If you have any questions or different views about this topic, please let me know.
Cheers, Renzo