802.11w. AKA PMF

802.11w purpose

802.11 includes 3 types of frames: data, control (RTS/CTS/ACK) and management. Typically, only the data frames are encrypted. The original reasoning was that management frames could be expected before association, and designing an encryption process for frames sent to devices that knew nothing of your encryption scheme did not strike the 802.11 designers as a logical requirement.
However, some 802.11 management frames include deauthentication and disassociation messages, that are sent to associated stations, and that can be spoofed, resulting in valid stations dropping from the cell due to mischievous devices impersonating the AP. To make things worse, other management frames contain key parameters, necessary for the station healthy life in the cell. Spoof the AP MAC address, send wrong values, and your nice station can get in trouble.
802.11w was published in 2009 to attempt to protect against this type of hacking.

802.11w process:

802.11w only applies to WLANs running Robust Security Networks (RSN), i.e. using AES/CCMP, WPA2, or WPA1/TKIP (this last one being in general deprecated, you want to stick to WPA2). When you enable  Protected Management Frames (PMF, AKA 802.11w) on such a WLAN, your AP goes through the same 4 way handshake, but also adds a hash, a signature, that will be present in several management frames while your station is associated. This hash is built from the WPA/WPA2 negotiation (this is why WPA2/AES-CCMP or TKIP is required). An attacker trying to spoof the AP MAC address will not have the secure hash, and will not be able to sign the management frame. Your PMF station ignores improperly signed management frames.

Management frames classes:
The "management frame" family is fairly large, and is organised in 3 classes. These classes match the state of the station receiving the frames:

1. Class 1 management frames include frames that can be received before authentication and association (beacon, probe responses, authentication request and response, 802.11h spectrum management frames). Those management frames are said to be "of class 1", and cannot be protected (as the receiving station is not associated yet, and therefore does not have any keying material yet).
2. Once the station authenticates, it can still receive class 1 frames, but can now also receive class 2 frames (i.e. management frames that cannot be received by non-authenticated stations, but that can be received by stations that are authenticated, but not associated yet). These class 2 frames include association request/responses, re-association request/response, and disassociation frames.
3. Once the station is associated, it can receive management frames of class 1 and 2, but also management frames of class 3 (management frames "that you need to be associated to receive them" :-)). These class 3 management frames include disassociation /de-authentication frames, and most unicast action frames (QoS, BSS transition, radio measurement, etc).

The IEEE (figure 10-6 in 802.11-2012) is a pretty clear representation of what state allows reception of which frame:

This frame class naming convention can be confusing, because 802.11w relates to the frame class to determine if (and in what case) it can be protected. The purpose is of course to protect type 3 management frames (as association is needed to get some keying material): disassociation, deauthentication and action frames. Notice that deauthentication can also be class 2. In that case, it is sent to an authenticated-but-not-associated station, is not signed, and therefore cannot be protected.

PMF vs MFP:
Do not confuse PMF Protected Management Frames (802.11w) with Cisco MFP (Management Frame Protection). Cisco MFP was developed in 2005, and has two modes:

• One 'infrastructure mode', where the APs sign their beacons and other broadcast management frames. Other APs can detect 'unsigned' broadcast management frames and report rogues to the WLC. This mode does not exist with 802.11w.
• One client mode, where the client participation is added. In this mode, the AP also signs management frames sent to the client (on top of the infrastructure part, that is also there). Cisco MFP was used as a basis for 802.11w development. You could say that 802.11w is somewhat like "Cisco MFP client part". On Cisco controllers, you can enable both PMF and MFP. Cisco client MFP requires your client to have CCXv5, in order to negotiate a signature process with the AP.

Protection negotiation:
Once 802.11w is enabled in the WLAN, the AP advertises (in beacons and probe responses) specific values for the RSN information element:

• Auth Key Management is set to SHA256 (instead of SHA1 with standard WPA2). The screenshot above has MFP set to Mandatory. If yous et 802.11w to "Optional", you will see both SHA256 and the standard OUI 00-0f-ac for AES/CCMP (WPA2).
• In the RSN Capabilities subelement, MFP cabale is set to 1, and MFP Required is also set to 1 if your WLAN is configured for 802.11w Mandatory (it would be set to 0 if the WLAN is set to 802.11w Optional).

Then, the process is a standard Open 802.11 authentication (authentication request / response). In the association request, the client mentions that it also supports 802.11w (if your client does not support 802.11w and your WLAN is set to 802.11w Mandatory, the client does not even try to associate. If the WLAN is set to 802.11w Optional, the client uses 802.11w if it it supports PMF, and standard WPA/WPA2 otherwise). This is what an association request (of a client supporting 802.11w looks like):

The client request SHA256 Key Management, and mentions that it supports PMF. The AP registers the client with its capabilities (as you know, the association response only contains, besides the AID, standard communication parameters, like supported rates and WMM information; no 802.11w-specific information is mentioned there).
The 4 way handshake is then very similar to the standard WPA2 4 way handshake. The only difference is that the station and AP use SHA256 instead of SHA1 (and the key is therefore longer)... and that the AP also needs to provide management frame protection for clients in the cell that support 802.11w. This means that you will have both a group temporal key (GTK), but also an Integrity group temporal key (IGTK), sent by the AP in EAPoL frame 3 to the 802.11 stations:

Management frames sent to groups of 802.11w stations are protected with this IGTK (used to generate a specific MIC). Note that these frames are not encrypted. This is why the 802.11w "tiny prints" (although they make it pretty clear) state that BIP (Broadcast/Multicast Integrity Protocol) provides message integrity and access control for group addressed Robust Management frames. In other words, the Message Integrity Check (MIC) ensures that you cannot spoof the sender MAC, or change the content without being noticed, but BIP does not encrypt the frame content.
Unicast Management frames also have this special MIC, but they are also encrypted, thus not only ensuring "message integrity and access control", but also "confidentiality". For example, below is  a standard Disassociation frame sent from an AP to a station in a WPA2 WLAN:

Nothing protects this frame. It clearly shows the source, destination, frame type and reason code. Any attacker could generate such a frame. In contrast, below is the same Disassociation frame, this time generated in a WLAN set for 802.11w, and sent to a 802.11w-enabled station:

You can still see the source, destination and frame type, but the content is encrypted with CCMP. You cannot see the reason code, and cannot see the MIC. An attacker would not be able to generate such a frame with a high chance of being successful. This process exists because the AP and the station exchanged encryption parameters both for the data frames, and for the unicast management frames (on top of using the 802.11w secured MIC).

802.11w is not the ultimate security for a WLAN
Just a quick word on this. You will read all over the Internet that "802.11w is not secure". Let's put things in perspective. 802.11w protects some management frames, that's all it does. There may be cases where either side (the AP or the station) may receive invalid frames, and may simply ignore the source. If you are clever (for example sourcing a frame from the broadcast address), you may get the cell in a configuration where traffic becomes difficult. In other words, adding the extra protection with 802.11w also adds some additional rejection mechanisms that can be exploited to make your wifi network unusable. 802.11w, or any other mechanism for that matter, cannot prevent that (it is also very easy to render a WPA2 cell unusable)... however, any additional security mechanism (including 802.11w) makes attackers' life harder.

802.11w Configuration:

Now this is the easy part. Set your WLAN to WPA1+WPA2. The set PMF to optinal (allowing both 802.11w and non-802.11w stations to associate) or Required (only 802.11w stations can associate).

   You will then see a "Comeback Timer" and SA Query Timeout parameters. These are often source of confusion. What happens if an attacker spoofs an AP MAC, and sends (invalid) management frames to a station? The station will ignore them. What happens if an attacker spoofs a 802.11w client MAC and sends (invalid) management frame to the AP? For example an association request (while the 802.11w station is already associated)? The AP has to think that the new association request is either wrong (spoofed frame by an attacker), or that the station did send a disassociation message before, that the AP missed (and the station is now re-associating). So the AP will respond with 2 messages:

• The first message is a response to this new association request, saying that the request is rejected, with a status code 30. This status code stands for "Association request rejected temporarily; Try again later". The AP also mentions when this "later" is going to be. This is the "comeback timer", a value ranging between 1 and 10 seconds (default 1 second, which is good in most cases). At this point, the station requesting the association has to wait a bit before sending a new association request. If the station is a valid client that really disassociated, then this delays a bit the association. But, if the association frame is spoofed (which is more likely to be the case), then this message has no impact on the legitimate, sill associated, valid 802.11w station.
• During the comeback interval, the AP wants to check if the 802.11w station is really still associated (and the new association request comes from an attacker), or if somehow, the AP managed to entirely miss that the station did disassociate at some point. So the AP is going to send to the 802.11w (that the AP believes to be still associated) a SA query message. This message basically says: "hey, you and I are still in a secured communication, right? We did the 4 way handshake thing, and negotiated security parameters that created a Secure Association (SA) between us? And er... you did not go away and did not tear down any of that, did you?" If the station is still associated properly (the new association request was coming from an attacker), it will respond, saying "yeah yeah, all good, I'm here" (all this exchange is encrypted of course). If the station is really gone... then it will not respond (as it deleted the SA upon sending the disassociation message, and is not associated anymore). So the AP has to wait for the station reply. If, after the SA Query timeout (200 milliseconds by default), no response is received from the client, then the AP understands that the client is really gone, deletes the SA, and is ready to receive the next association request and re-validate the client.

Down the same page, set the authentication form (PMF PSK or PMF 802.1X if you set 802.11w to Required, and 802.1X/PMF 802.1X or PSK/PMF PSK if yous et 802.11w to optional). Set the key value if using PSK.

Click Apply. Voila. To debug, use debug pmf events {enable | disable}.