Protected Management Frames (802.11w)

*2014-10-22 Update 1: Added Conclusion*

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_protectedDisassoc

 

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):

NoPMF

 

RSN element with optional PMF support:

PMF-Optional

RSN element with required/mandatory PMF support:

PMF-Mandatory

As there are three options, the possible outcome of AP and client settings is given in the following table.

PMF_connectionTable

 

 

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 Source Address (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.

PMF_AP-Scenario1

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.

 

PMF_AP-Scenario2

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 Source Address (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.

PMF_Client-Scenario1

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).

PMF_spoofedClientAttack

 

PMF_Client-Scenario2

 

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
  • AirTight
  • 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 726x
  • 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

Advertisements

17 thoughts on “Protected Management Frames (802.11w)

  1. 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.11n, 802.11ac or Passpoint aka HotSpot2.0 interoperability certification.
    ==============

    Actually, PMF is mandatory to pass 802.11ac and Passpoint Release 2 certification.
    For 802.11n, it’s still optional so far. (2015 Jan)

    Like

  2. “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.”

    Thank you for sharing this article. Could you please let me know which reference that shows 802.11 data header still remain unprotected? I cant find this conclusion in the references that you listed somehow.

    Like

      • Well, I guess it’s quite easy to explain and comes from my experience

        Radiotap is never encrypted as there is no way of encrypting basic stuff like the used MCS, NSS, Guard Interval and so on. Otherwise the radio receiver would not now how to read the packet at all.

        “Data” within Management Frames is always unencrypted as everybody can read e.g. the reason code for a disassociation. To be correct, there is no data field like in a Data Frame (Managementt, Control and Data are the possible options of a frame type).

        Like

  3. “RSN element with optional PMF suppor” shows the support for both SHA-1 and SHA-256, could you please let me know where can i find the reference as the certification lab confirms that only SHA-256 needs to be supported and SHA-1 should be removed from AKM list. It would be really helpful if you could provide some assistance on this. Thanks.

    Like

    • Hello Nithi,
      do you go for the WFA certification? They state that you either have only SHA-1 or SHA-1 + SHA-256 enabled for PMF “enabled”/optional. For PMF “required”/mandatory, only SHA-256 has to be enabled. Take a look the current test plan and the sniffer scripts of WFA.

      Regards,
      mtroi

      Liked by 1 person

      • Hi mtroi,
        Thanks for your response and Yes, we are doing the WFA certification. Our device is MFPC supported but MFPR is disabled ad sorry, the lab says only to support SHA-1 in our case. We have enabled both SHA-1 and SHA-256 on our device but the lab came back saying to disable SHA-256. We couldnt find any reference to state whether it has to support only SHA-1 and not SHA-256. Our developers are refusing to accept to disable SHA-256 as its providing strongest security. Sort of in a loop finding out the support and it was very promising to see your post/comment which stats both.
        WFA test plan stats when PMF enabled device shall advertise SHA-1 but it doesnt state that only SHA-1 has to be supported like it stats for PMF required case.
        So it would be very helpful if you could provide some reference where I can confirm „SHA-1 + SHA-256 enabled for PMF “enabled”/optional“ as its WFA lab asking to disable SHA-256.

        Liked by 1 person

      • Hi Nithi,
        please download the latest version of the PMF test plan (v1.4) and see TC 4.6. Maybe you need to disable SHA-256 for other test cases as the sniffer checks require it, but it seems to be OK if you want to support SHA-1 + SHA-256 at all. I won’t go into any further details as this is WFA member confidential.

        Yes, I’m with you that SHA-256 supports better security as SHA-1 is already broden (SHAttered). If the drivers don’t mess up, it’s best to enable both for downwards compatibility.

        regards,
        mtroi

        Liked by 1 person

  4. Hi mtroi,

    I have gone through the test plan and yes, it can be enabled if its configurable item.
    You are great, thanks a lot for your reference and support.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.