Does your phone/tablet support 802.11k/v/r/u/w? Can you help complete the list?

I am trying to contribute to this page. I have quite a few devices in my lab, but need help.
Do you have a Cisco WLC/AP, and a BYOD that is not in the list?
Can you set the WLAN to 802.11r (FT) and try to associate? If it works, can you send to me the association request/response?
Can you do the same for 802.11k/v?
The rest (802.11u / 802.11w) can easily be checked from the WiFi Alliance website (check here). 802.11w is Protected Management Frame, and 11u is Passpoint...
Thanks!

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

802.11r

802.11r purpose

802.11r (AKA Fast Transition) is an IEEE 802.11 amendment published in 2008. The problem they were trying to solve at that time was as follows: when you roam from one cell to the other, you waste time. This is because your device stays associated to the current cell until the signal becomes too poor to be usable and then (only then):

• Leaves the channel to scan and discover other channels where the SSID is available (this scanning process wastes times, in a configuration where your communication is already bad)
• Once a new AP is chosen, the device needs to authenticate to that new AP, the disassociate from the old AP, then associate to the new AP. 

In a voice call, where every millisecond counts, this can take too long (you need to re-enter a 4 way WPA2 handshake, and maybe even get back to the RADIUS, before have a key that you can use). This process can be disruptive. The other bad news is that you have no idea on whether the new AP can continue your call or not (it may be completely overloaded already).

So 802.11r was designed to allow your device to run the next AP discovery process before leaving the previous cell, including negotiating the key with the new AP, and checking that the new AP can provide the same QoS services as the older one... and only then, once everything is ready, the device would make the short jump to the next AP. 802.11r can save a lot of time. In the illustration below, I roamed back and forth between two APs (WPA2/PSK). In the first case, 802.11r is not enabled.

Each blue diamond is the time elapsed between the last voice packet in the previous cell, and the first voice packet in the next cell. Depending on the scanning structure of the phone, you can see that I sometimes get to the next AP in a few tens of milliseconds, but sometimes performances are poor.
In the second example below, I enabled 802.11r on my APs, and performances are much better (careful, scale above is in seconds, because I get some long intervals, while the scale below is in MILLIseconds)..

802.11r process

802.11r is an extension to 802.11i. In other words, you can enable 802.11r only for your WPA2/CCKM WLANs (not WPAv1, not WPA2/TKIP, not for Open or WEP). At that time, the AP displays in its beacons and the Probe responses the FT information in 2 fields:

• The Mobility domain contains a hash value that is shared by all APs in the same 802.11r domain (i.e. between which 802.11r fast roaming is possible). In Cisco autonomous APs, this hash is derived from the IP address of your WDS. In a controller system, It is derived from the mobility group value.
• The Mobility domain section also mentions if QoS reservation (resource request protocol) is supported. Very few systems implement RRP, because it removes the intelligence from the client. It is usually better and more efficient to let the client assess the next cell load through QBSS IE information and decide of the best course of action, rather than constraining the client to negotiate QoS parameters.
• The Mobility domain section also mentions if negotiation with the next AP has to happen over the air, or over the DS (more on this below).   
• The RSN (Robust Security Network) field displays that Key management includes FT (with PSK or 802.1x, depending on how your clients authenticate).

Note: on Cisco controllers, (8.0 and later), you can enable "hybrid" WLANs, where you turn on either FT, WPA2/CCKM, or both. In this last case, you would see both FT and PSK (or 802.1x) key management:

Over the DS vs Over the Air:
Negotiation with the next AP can happen over the air, or over the DS. With "over the air", the client gets to the edge of the first cell, scans, finds another AP, and negotiates directly with this next AP the next key (and possibly QoS parameters). The advantage of this method is that communication is direct (no delay by going through the DS, not need for AP to AP wired communication protocol). The downside is that the client needs to leave its active channel to negotiate on another channel. Most BYODs send a frame to their current AP, telling them that they "go to sleep" (Null frame with Power Management set to 1, while in fact they go negotiate on another channel), then return to the active channel to "empty their and the AP buffer" (Null frame with Power management set to 0) before jumping out to the next AP.
The over the air process is direct, but may be disrupting in a location where the device is already at the edge of the cell (low data rate, lots of retries). To avoid that the negotiation also forces the device to go off channel for a while, the Over the DS method can be enabled. In this case, the device stays on the current channel (no need to pretend to sleep and leave the channel), and asks the current AP to negotiate with the next AP (your client still has to discover the next AP first, i.e. scan). This process saves time and increases efficiency, provided that both APs have a way to communicate. In a controller-based network, no problem. The unknown is in the efficiency (what is faster: direct negotiation, or going through the current AP, the WLC, then the next AP, with all the switches or routers that may be on the way?). The only answer is to test (or know your network, if APs are on the same switch and the WLC is close, DS is great. Add routers and switches, and the needle switches toward Over the air).

Key negotiation:
The major difference between 802.11r and standard WPA2/CCMP lies in the key negotiation. With standard WPA2/CCMP, the client and the RADIUS server generate a Master Session Key (MSK), which first 256 bits are used as the Pairwise Master Key, from which individual encryption keys (TK, temporal keys) are derived for individual frame encryption. With PSK (no RADIUS), the PSK is the MSK. The PMK is valid for the duration of the session, and roaming usually means renegotiating a new PMK (I am ignoring PMK caching various forms).
With 802.11r, the PMK derived from the MSK is in fact called PMK-R0. That key is kept where the authentication occurred (WLC, or first AP in an autonomous network). A second PMK is generated from the PMK-0; it is called PMK-R1. That PMK is the one used to derive the TK on the first AP. When the client negotiates with the next AP, the "domain ID" field and a PMK-R0 identifier tell if the next AP is in the same 802.11r domain as the previous AP, i.e. if the next AP also has access to the same PMK-R0. If domain is the same, then the client agrees with the next AP to generate a new PMK-R1 (from the same PMK-R0 in the central repository). The next PMK-R1 is passed to the next AP, and everything is ready.
In other words, client and next AP just need to know that they are in the same domain, and agree on the next PMK-R1 index. Then the client generates the new PMK-R1 on its side, while the next AP gets the same PMK-R1 from the wired side (WLC or WDS). No need for the client to perform authentication again.
During the 4 way handshake (FT style), the PMK-R0 and R1s are mentioned as part of the exchange (frame 2 of the 4 way handshake, sent from the AP, below):

The domain and PMK-R0 identifiers are enough to ensure that the device is in the same domain from one AP to the next, and the rest negotiates the PMK-R1 details.

The downside of this method is that non-802.11r client do not understand the "FT" key management method in the beacons and probe responses, and also do not understand the domain and key index in the 4 way handshakes. In short, they can't associate to WLANs set for 802.11r. This is the reason for the "hybrid" mode, where you configure both WPA2 and FT. non-802.11r associate using WPA2, while clients that support 802.11r use the more efficient FT method.
There are still some old clients that panic when seeing "FT" mentioned in the beacons/probe responses, even if WPA2 is there. This is because (poor programming) they do not recognize this security parameter, and refuse to associate, even if they do recognize WPA2. These older and poorly developed drivers tend to go away with newer devices and OS updates, but make sure to test 802.11r in your network before deploying it completely.

802.11r Configuration:

This is the easy part. In your WLAN, start by setting security to WPA+WPA2, then check Fast Transition (FT).  Default negotiation is over the Air, check Over the DS otherwise.
Clients can negotiate keys with the next AP, and then never jump there. The reassociation timeout determines the duration for which the newly negotiated key is valid. By default, if the client does not make the jump within 20 seconds, the next AP cancels the PMK-R1, considering that the client went elsewhere.

At the bottom of the screen, check FT 802.1X or FT PSK to enable 802.1X or PSK for 802.11r clients, and optionally also check 802.1X or PSK for the WPA2 clients (thus making the WLAN 'hybrid').
Of course, mode has to be the same for both (802.1X and FT 802.1X, OR PSK and FT PSK).

Click Apply. Done.
Use show wlan wlan-id and show client detailed to check your config. You cannot change the domain ID without changing WLC mobility configuration. Use debug ft keys {enable | disable} to follow the FT dialog from the WLC CLI.

CCIEW v3, what to expect

CCIE W v3 came out a few weeks ago. What should you expect?

AireOS:

The new version of the exam is based on AireOS 8.0 (previous version, v2, was based on 7.0). It is therefore fair game to expect to see "some of the new stuff" that appeared between 7.0 and 8.0, such as mDNS, IPv6 (for the infrastructure, IPv6 for clients was already in v2),  802.11ac, SSO, 802.11k/v/u/w/r, AVC, device Profiling, onboarding, RX_SOP, RF Profiling, but also all the enhancements that came into existing features, such as RADIUS DNS, QoS profiling from ISE (yes, ISE replaces ACS), wIPS, DNS-based ACLS, L2 ACLs, Min/Max power for TPC, and tons of changes on the Flex APs (local PEAP or TLS for example), not to mention new features on the MSE like Visitor Connect...
Okay, let's cut it short. It is not one of these updates where you think "I just need to brush up one one or two items, and I'll be good to go". You probably want to do a clean study of the entire WLC config guide 8.0. At the same time, the update from v1.0 to v2.0 also displayed a daunting list of changes, which is to be expected when an exam jumps across two major releases. Even if the list above looked scary to you, it is very likely that you have heard of, or worked with, quite a few of the items  in that list (unless your boss really thinks that 7.0 is the best code on earth). And if you have not heard of some of the items in the list, it is likely that they are not fundamental (doesn't mean that you won't get them in the lab, but they are likely not to be the core of your exam). The logic of any exam is always: make sure that the candidate knows the core of the body of knowledge (for example, it would be funny if the CCIE R&S exam did not test routing or VLANs). Once this is taken care of, the expert exam tends to test tinier items. The less items on that 'non-core' list, the more in depth you can expect tests on these "tinier items" to be. Similarly,  a longer list means that you are unlikely to be tested very deeply on many of these tinier items. Why not? Because despite Non Disclosure Agreements that people sign when taking the exam, people still talk, and it would not take long before forums would display "they only test items A and B". So, a longer list means that you are likely to get more items (and different items in each exam set). As the exam duration is still the same, each item is tested less in depth. It is still likely to be an expert level, but there is "expert" and "crazy expert". More items pushes the bar from "crazy" to just "expert", knowing your stuff well should be enough.

IOS-XE:

That's another scarecrow. As Converged Access is in the lab, you are likely to get 3650/3850 Switches and/or 5760s (maybe, maybe not, but likely). Are you expected to be a guru on these platforms? My bet is "probably not". As these beasts are on the blueprint, you need to know how to configure them for the classic functions that a wireless guy can expect from these boxes (WLAN, MC, MA, PoP, PoA, etc). However, these devices embark the IOS, and can do much, much more than wireless. A wireless guy is of course expected to know basic routing, but it is very unlikely that you may need to configure insane Wired-only functions. If you are comfortable running basic configurations in the GUI, you probably know most of what you need to know to survive this part. Add knowledge of what CLI configuration is done when you configure this or that in the GUI (in other words, survive the CLI), and you should be very close to where you need to be to enjoy the CA section in the exam. A common misconception about this version of the exam is that you need IOS-XE as deep as AireOS.

MSE/ISE/PI:

MSE is in the exam, with new functions. If you get a chance to read on what you can configure, you will soon discover that, just like in v2.0, the scope of what can be asked is limited. Rent and MSE for a day or 2, and you should know enough to be comfortable with any question. The same goes for PI. I often ask myself: what can they ask in PI that you could not find with a few clicks? Learning the interface is not hard... and all you need to know is the interface (there are very few features that you will find only in PI, and not in the WLC, that you would care about as a Wireless engineer).
ISE is just like ACS: scary because it is an entire world. Here again (and just like ACS), you are the wireless guy, so there should not be any feature that is so deep that you would need an ISE expert to help you. Knowing how to create standard policies is what ISE is about in the Wireless IE.

Troubleshooting/Diagnostic section:

This is new to this version of the exam, and aligns with similar sections of the other IE tracks. Google around, and you will find tons of examples of such diagnostic questions for the various tracks. The format is simple: you get a troubleshooting ticket, in the form of a collection of messages exchanged between people. Your job is to find the root cause of the problem. There is no direct interaction with a device (no typing and sweating through debug commands that you have to type). The goal is to read the exchange, to understand what is reported to be wrong. Then, navigate through the various exchanges to find the piece of information that would tell you what happened. Mmm... not clear? Maybe an example would help. Suppose you get a report from a customer saying that they cannot associate to the SSID (made up example, this is VERY unlikely to be what you will get in the real exam). What I would do here is wonder if no-one can associate, or just that one customer. And also I would want to know what the WLAN config is. You browse through the dialog and find that everyone else associates fine (hint, user config problem), further down, you find the spot where the config of the WLAN is described. It is WPA2/PSK. Okay, my next move would be to try to find the client config, or a sort of capture of the association exchange. And if you find that somewhere, and get a WLC message that complains about wrong key, bingo, the user has the wrong key configured, that's the problem. The real exam cases (you may get several cases, depending on each case difficulty) are probably a bit less "CCNA-level", but the logic is the same: browse through the docs to understand what the problem is, and try to spot information that shows the cause of the problem, and voila.

Conclusion: try or wait?

Most candidate wisely wait a few weeks when a  new exam comes out, so as not to be the first ones to crash test the new exam. Then, training organisations start publishing training material and the seats for the exam become hard to get... a major difficulty for this version will be for training companies to tell you exactly how much ISE, and how much IOS-XE, are required. A safe approach is to train you on almost everything (so as not to miss anything, and also not to disclose directly what they may have learned from other candidates on the exam specifics). If you have a chance to train on IOS-XE devices, and get your lab setup with what you will get in the lab, my advice would be not to wait, and give the exam a try. You may fail (but hey, maybe pass the first time, first-time passers are not unheard-of jewels anymore), but you will learn a lot on the exam logic, structure, and also on the depth to be expected to each section. In other words, you will learn how the game is played. This will help you tremendously pass the next time...