802.11 WLAN Roaming and Fast Secure Roaming on CUWN

Jeal Jimenez · ‎09-02-2013

Introduction

This document describes the different types of wireless roaming and fast secure roaming methods available for 802.11 WLANs and supported on the CUWN.

The document is not meant to provide all the specifics about how each method works or how they are configured, but the main purpose is to understand the differences between all those techniques available, their advantages and limitations, and mainly understand the frames-exchange on each method, so it provides examples of WLC debugs and wireless packet captures taken to analyze and explain the events happening on each roaming method described.

Requirements

Cisco recommends that you have knowledge of these topics:

802.11 WLAN fundamentals.
802.11 WLAN security and 802.1X/EAP basics.

Background Information

Before getting into the different fast secure roaming methods available for WLANs, it is important to understand how the WLAN association process works, and how a regular roaming event happens when there is no security configured on the SSID.

When an 802.11 wireless client connects to an AP, before it can start passing traffic (wireless data frames), it first needs to pass the basic 802.11 Open System authentication process and then the association process, where the Open System authentication process is like "connecting the cable" on the AP that the client selected (this is very important to understand, as it is always the wireless client the one that selects the AP it preferred to connect with and based on multiple factors that can vary between vendors, so this is why the client starts this process sending the Authentication frame to the selected AP as you will see below; the AP can't ask a client to come and connect with it) and the association process is like "finishing the 802.11 layer-2 negotiation" that will bring up the link between the client and the AP, where the AP assigns an association ID to the client if successful and leaves it ready to start passing traffic or perform a higher level security method if configured on the SSID. The Open System authentication process consists of two management frames as well as the association process (authentication and association frames are wireless management frames, not data frames, which are basically the ones used for the connection process with the AP), and this is how it looks when capturing the wireless frames over the air for this process:

Note: If you want to learn about 802.11 wireless sniffing and about the filters/colors used on Wireshark for the captures shown on this document, please check our Cisco Support Community post called '802.11 Sniffer Capture Analysis':

https://supportforums.cisco.com/docs/DOC-24502

The wireless client starts with the Authentication frame, then the AP answers back with another Authentication frame, then client sends the Association Request frame, and AP ends answering back with the Association Response frame. As you can see from the DHCP packets, once we have passed the 802.11 Open System authentication and association process, the client can start passing data frames. In this case, we don't have any security method configured on the SSID, so the client immediately starts sending data frames (in this case DHCP) and they are not encrypted. As we will see later on this document, if we had security enabled on the SSID, we will see the higher level authentication and encryption handshake frames of the specific security method, just right after the Association Response and before sending any data frames of client traffic (like DHCP, ARP, applications' packets, etc., in which case will be encrypted), as data frames can only be sent until the client has been fully authenticated (and encryption keys have been negotiated) based on the security method configured.

The following are the messages you should see on the outputs of the WLC's debug client when the client starts a brand new association to the WLAN as per the captures shown above:

*apfMsConnTask_0: Jun 21 18:55:14.221: 00:40:96:b7:ab:5c Association received from mobile on BSSID 84:78:ac:f0:68:d0

*apfMsConnTask_0: Jun 21 18:55:14.222: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d0 (status 0) ApVapId 1 Slot 0

Note: The WLC debug used on the outputs shown on this document is the 'debug client', and the examples are only showing some relevant messages, not the entire output. For more details about this debug, please check the document called 'Understanding Debug Client on Wireless LAN Controllers (WLCs)':

http://www.cisco.com/en/US/products/hw/wireless/ps430/products_tech_note09186a008091b08b.shtml

So what should we see when the client roams? Client will always exchange four management frames when initiating a connection to an AP, either due to client starting an association or a roaming event (remember the client will always have just one connection established to just one AP at a time). The only difference in the frame exchange between a brand new connection to the WLAN infrastructure and a roaming event is that the "association" frames of a roaming event are called Reassociation frames, which indicate that the client is actually roaming from another AP and not starting a brand new association to the WLAN. These frames can contain different elements that will be used to negotiate the roaming event depending on the setup, but those details are out of the scope of this document; here, we are going to see how the frames exchange looks like:

The following are the messages from the debug:

*apfMsConnTask_2: Jun 21 19:02:19.709: 00:40:96:b7:ab:5c Reassociation received from mobile on BSSID 84:78:ac:f0:2a:90

*apfMsConnTask_2: Jun 21 19:02:19.710: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:90 (status 0) ApVapId 1 Slot 0

As you can see, the client successfully performed a roaming event after sending the Reassociation Request to the new AP and receiving the Reassociation Response from the AP, and since the client already had an IP address, the first data frames are for ARP packets.

If we are expecting a roaming event but the client sends an Association Request instead of a Reassociation Request (which we could confirm from some captures and debugs that will look as the ones explained at the beginning), then that means that the client is not really roaming but just starting a new association to the WLAN as if it got disconnected and is now trying to reconnect from scratch (this could happen due to multiple reasons, such as client moving away from the coverage areas and then finding an AP with enough signal quality to start an association, but this normally indicates a client issue where the client is not initiating a roaming event as it should due to drivers/firmware/software issues; you will probably need to check with the wireless client vendor why this is happening).

Roaming with higher level security

When the SSID is configured with layer-2 higher level security on top of basic 802.11 Open System authentication, then some more frames are required for the initial association and also when roaming. Here, we will discuss about the two most common security methods standardized and implemented for 802.11 WLANs: WPA/WPA2-PSK (authenticating clients with a Preshared-Key) and WPA/WPA2-EAP (authenticating clients with an 802.1X/EAP method to validate some more secure credentials -such as certificates, username/password, tokens, etc.- using an Authentication Server).

It is important to know that, even though these two methods (PSK and EAP) authenticate/validate the clients in a different way, both use basically the same WPA/WPA2 rules for the key management process. As a quick summary, whether the security is WPA/WPA2-PSK or WPA/WPA2-EAP, the process known as the WPA/WPA2 4-Way handshake will start the key negotiation between the WLC/AP and the client with an MSK (Master Session Key) as the original key material (once the client is validated with the specific authentication method used). So basically:

An MSK is derived from the EAP authentication phase when using 802.1X/EAP security or from the PSK when using WPA/WPA2-PSK as the security method.
From this MSK, the client and WLC/AP derive the PMK (Pairwise Master Key) and the WLC/AP also generates a GMK (Group Master Key).
Once these two Master Keys are ready, the client and the WLC/AP initiate the WPA/WPA2 4-Way handshake (which you will see later on some captures and debugs) using these Master Keys as the seeds to negotiate the actual encryption keys.
Those final encryption keys are known as the PTK (Pairwise Transient Key, derived from the PMK and used to encrypt unicast frames with this client) and as the GTK (Group Transient Key, derived from the GMK and used to encrypt multicast/broadcast on this SSID/AP).

WPA/WPA2-PSK

When doing WPA-PSK or WPA2-PSK (using either TKIP or AES for the encryption), the client will always have to go through the process known as the WPA 4-Way handshake, for both the initial association and also when roaming. As previously explained, this is basically the key management process for WPA/WPA2 to derive the encryption keys, but when doing PSK, it is also used to validate that the client has a valid Pre-Shared Key to join the WLAN. The following capture shows the initial association process when doing WPA or WPA2 with PSK:

As you can see, after the 802.11 Open System authentication and association process, we have four EAPOL frames, which are the ones of the WPA 4-Way handshake, initiated by the AP with message-1 and finished by the client with message-4. After a successful handshake, the client is able to start passing data frames (such as DHCP), which in this case are encrypted using the keys derived from the 4-Way handshake (this is why we can't see the actual content and type of traffic from the wireless captures).

The following are the messages you will see from the debugs:

*apfMsConnTask_0: Jun 21 19:30:05.172: 00:40:96:b7:ab:5c Association received from mobile on BSSID 84:78:ac:f0:68:d1
*apfMsConnTask_0: Jun 21 19:30:05.173: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d1 (status 0) ApVapId 2 Slot 0
*dot1xMsgTask: Jun 21 19:30:05.178: 00:40:96:b7:ab:5c Starting key exchange to mobile 00:40:96:b7:ab:5c, data packets will be dropped
*dot1xMsgTask: Jun 21 19:30:05.178: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c Received EAPOL-key in PTK_START state (message 2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.290: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.309: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.310: 00:40:96:b7:ab:5c Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile 00:40:96:b7:ab:5c

When roaming, the client will basically follow the same frames exchange, where the WPA 4-Way handshake is required to derive new encryption keys with the new AP (due to security reasons established by the standard and the fact that the new AP doesn't know the original keys). The only difference is that we have reassociation instead of association frames, as you can see from the captures:

We will see the same messages from the debugs, with the difference that the first packet from the client will be a Reassociation instead of an Association as explained previously.

WPA/WPA2-EAP

When using an 802.1X/EAP method to authenticate the clients on a secure SSID, there are even more frames required before the client can start passing traffic. These extra frames are the ones used to authenticate the client's credentials, and depending on the EAP method, they can be between 4 and 20+ frames, which go after the association/reassociation, but before the WPA/WPA2 4-Way handshake, as the authentication phase derives the Master Session Key used as the "seed" for the final encryption keys generated during the key management process (4-Way handshake). The following wireless capture shows an example of the frames exchanged over the air between the AP and the wireless client on an initial association when doing WPA with PEAPv0/EAP-MSCHAPv2:

Sometimes this exchange will show more or less frames depending on multiple factors: the EAP method, retransmission's due to problems or client behavior (such as the two Identity Requests on this example due to client sending an EAPOL Start after the AP sent the first Identity Request), or even if the client had already exchanged the certificate with the server. The fact is that, whenever the SSID is configured for an 802.1X/EAP method, then for sure we will have more frames (for the authentication), and hence, it will take more time for the client to finally start sending data frames.

The following is a summary of the debug messages:

*apfMsConnTask_0: Jun 21 23:41:19.092: 00:40:96:b7:ab:5c Association received from mobile on BSSID 84:78:ac:f0:68:d8

*apfMsConnTask_0: Jun 21 23:41:19.094: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d8 (status 0) ApVapId 9 Slot 0

*dot1xMsgTask: Jun 21 23:41:19.098: 00:40:96:b7:ab:5c Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c (EAP Id 1)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.226: 00:40:96:b7:ab:5c Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.227: 00:40:96:b7:ab:5c Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c (EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 5)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 5, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 6)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 6, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 8, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 9)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 9, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 10)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 10, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 11)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 11, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 13, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.472: 00:40:96:b7:ab:5c Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c Sending EAP-Success to mobile 00:40:96:b7:ab:5c (EAP Id 13)

*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c Starting key exchange to mobile 00:40:96:b7:ab:5c, data packets will be dropped
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c Received EAPOL-key in PTK_START state (message 2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile 00:40:96:b7:ab:5c

So when the wireless client performs a regular roaming here (the normal behavior, without implementing a "Fast Secure Roaming" method), the client will basically need to go through the exact same process, doing a full authentication against the Authentication Server as you can see from the captures, where the only difference is that the client uses a Reassociation Request to inform the new AP that it is actually roaming from another AP, but still having to go through full validation and new keys generation:

As you can see, even when there are less frames than in the first time authentication (which could happen due to multiple factors as mentioned before), by just roaming to a new AP the client still needs to go through the EAP authentication and the WPA key management processes in order to continue passing data frames (even if it was actively sending traffic before roaming). Therefore, if the client has an active application sensitive to delays (such as voice traffic applications, or apps sensitive to timeouts), then the user could perceive some problems when roaming (such as audio gaps or even applications' disconnects) depending on how long this process takes for the client to finally continue sending/receiving data frames (this delay could be longer depending on the RF environment, amount of clients, round-trip time between the WLC and LAPs and with the Authentication Server, etc.).

The following is a summary of the debug messages for this roaming event:

*apfMsConnTask_2: Jun 21 23:47:54.872: 00:40:96:b7:ab:5c Reassociation received from mobile on BSSID 84:78:ac:f0:2a:98
*apfMsConnTask_2: Jun 21 23:47:54.874: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:98 (status 0) ApVapId 9 Slot 0

*dot1xMsgTask: Jun 21 23:47:54.879: 00:40:96:b7:ab:5c Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c (EAP Id 1)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c dot1x - moving mobile 00:40:96:b7:ab:5c into Connecting state
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c (EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.956: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.957: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c Sending EAP-Success to mobile 00:40:96:b7:ab:5c (EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c Starting key exchange to mobile 00:40:96:b7:ab:5c, data packets will be dropped
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c Received EAPOL-key in PTK_START state (message 2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile 00:40:96:b7:ab:5c

Therefore, as this is just the way 802.1X/EAP and the WPA/WPA2 security framework work, in order to avoid the application/service impacting delays from a regular roaming event, multiple "Fast Secure Roaming" methods have been developed and implemented by the WiFi industry to "accelerate" the roaming process when using security on the WLAN/SSID, since it is by deploying high level security on the WLAN that the clients face some latency to continue passing traffic when roaming around between APs (due to the EAP authentication and key-management frames exchange required by the security setup as it has been explained so far).

It is important to understand that “Fast Secure Roaming” is just the term used by the industry making reference to the implementation of a method/scheme that can accelerate the roaming process when security is configured on the WLAN. The different “Fast Secure Roaming” methods/schemes available for WLANs and supported by the CUWN are explained in a similar way below to understand the differences.

Fast Secure Roaming with CCKM (Cisco Centralized Key Management)

CCKM was the first Fast Secure Roaming method developed and implemented on enterprise WLANs, created by Cisco as the solution to mitigate the delays explained so far when using 802.1X/EAP security on the WLAN. As this is a Cisco proprietary protocol, it is only supported by Cisco WLAN infrastructure devices and wireless clients (from multiple vendors) that are CCX compatible for CCKM.

CCKM can be implemented with basically all the different encryption methods available for WLANs, including WEP, TKIP, and AES. It is also supported with most of the 802.1X/EAP authentication methods used for WLANs, but this depends on the CCX version supported by the devices.

Note: For an overview on the feature content supported by the different versions of the Cisco Compatible Extension (CCX) specification (including EAP methods supported), you can check the following 'CCX Versions and Features' document, and then check what exact CCX version is supported by your wireless clients if they were CCX compatible, so you can confirm if the security method you want with CCKM can be implemented or not depending on your devices:

http://www.cisco.com/web/partners/pr46/pr147/program_additional_information_new_release_features.html

The following wireless capture shows an example of the frames exchanged on an initial association when doing CCKM with TKIP as the encryption and PEAPv0/EAP-MSCHAPv2 as the 802.1X/EAP method, which is basically the same exchange as if we were doing WPA/TKIP with PEAPv0/EAP-MSCHAPv2, but this time negotiating CCKM between the client and the infrastructure so they can use a different key hierarchy and caching methods to perform fast secure roaming when the client needs to roam:

The following is a summary of the debug messages:


*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c Association received from mobile on BSSID 84:78:ac:f0:68:d3
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c Processing WPA IE type 221, length 22 for mobile 00:40:96:b7:ab:5c
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c CCKM: Mobile is using CCKM
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c Setting active key cache index 8 ---> 8
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c unsetting PmkIdValidatedByAp
*apfMsConnTask_0: Jun 25 15:41:41.508: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d3 (status 0) ApVapId 4 Slot 0
*dot1xMsgTask: Jun 25 15:41:41.513: 00:40:96:b7:ab:5c Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c (EAP Id 1)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c (EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c Received EAP Response packet with mismatching id (currentid=2, eapid=1) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.596: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.596: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.627: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.627: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.630: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.630: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 5)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.657: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.657: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 5, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.659: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.659: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 6)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.680: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.680: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 6, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.687: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.687: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5 (EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.699: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.699: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.701: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.701: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.802: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.802: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 8, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.804: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.804: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 9)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.814: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.814: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 9, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.816: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.816: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 10)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.822: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.822: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 10, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.825: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.825: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 11)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.830: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.830: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 11, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.832: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.832: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.838: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.838: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 13, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.840: 00:40:96:b7:ab:5c Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c Creating a PKC PMKID Cache entry for station 00:40:96:b7:ab:5c (RSN 0)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c CCKM: Create a global PMK cache entry
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c unsetting PmkIdValidatedByAp
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c Sending EAP-Success to mobile 00:40:96:b7:ab:5c (EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c Starting key exchange to mobile 00:40:96:b7:ab:5c, data packets will be dropped
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c Received EAPOL-key in PTK_START state (message 2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c CCKM: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK (Version_1) information to mobility group
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK (Version_2) information to mobility group
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile 00:40:96:b7:ab:5c

So with CCKM, the initial association to the WLAN is similar than with regular WPA/WPA2, where a Master Session Key (also known here as the NSK -Network Session Key-) is mutually derived on the client and the RADIUS Server (which sends this master key to the WLC after a successful authentication, and will be cached as the basis for deriving all subsequent keys for the lifetime of the client's association with this WLAN). From here, the WLC and the client will derive the seed information that will be used for fast secure roaming based on CCKM, going through a 4-Way handshake similar to that of WPA/WPA2, in order to finally derive the unicast (PTK) and multicast/broadcast (GTK) encryption keys with the first AP.

The big difference is noticed when roaming; in this case, the CCKM client simply sends a single Reassociation Request frame to the AP/WLC (including a MIC and a sequentially incrementing Random Number), and has enough information (including the new AP’s MAC address -BSSID-) to derive the new PTK. With this Reassociation Request, the WLC and new AP also have enough information to derive the new PTK so they simply answer back with a Reassociation Response and the client is now ready to continue passing traffic as we can see from the captures:

The following is the summary of the WLC debugs for this roaming event:



*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c CCKM: Received REASSOC REQ IE

*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c Reassociation received from mobile on BSSID 84:78:ac:f0:2a:93

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c Processing WPA IE type 221, length 22 for mobile 00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c CCKM: Mobile is using CCKM

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c Setting active key cache index 0 ---> 8

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c unsetting PmkIdValidatedByAp

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c CCKM: Processing REASSOC REQ IE

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c CCKM: using HMAC MD5 to compute MIC

*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c CCKM: Received a valid REASSOC REQ IE

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c CCKM: Initializing PMK cache entry with a new PTK

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c Setting active key cache index 8 ---> 8

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c Setting active key cache index 8 ---> 8

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c Setting active key cache index 8 ---> 0

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c Creating a PKC PMKID Cache entry for station 00:40:96:b7:ab:5c (RSN 0) on BSSID 84:78:ac:f0:2a:93

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c CCKM: using HMAC MD5 to compute MIC

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c Including CCKM Response IE (length 62) in Assoc Resp to mobile

*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:93 (status 0) ApVapId 4 Slot 0

*dot1xMsgTask: Jun 25 15:43:33.757: 00:40:96:b7:ab:5c Skipping EAP-Success to mobile 00:40:96:b7:ab:5c

As you can see, we are definitely doing a fast secure roaming, avoiding the EAP authentication frames and even more 4-Way handshakes, as the new encryption keys are still derived but based on the CCKM negotiation scheme by just using the roaming Reassociation frames and the information previously cached on the client and the WLC.

FlexConnect with CCKM

When using CCKM on a FlexConnect setup, the behavior is exactly the same as explained above (doing fast secure roaming), as long as the APs where the client is roaming to belong to the same FlexConnect Group.
CCKM works this way using either Central or Local Authentication for the FlexConnect setup as long as the APs are in Connected mode (with either central or local switching).

Pros with CCKM

CCKM has been the fastest fast secure roaming method mostly deployed on enterprise WLANs. Clients don’t even need to go over a key management handshake to derive new keys when moving between APs, and never again doing a full 802.1X/EAP authentication with new APs during the client’s lifetime on this WLAN.
CCKM supports all of the encryption methods available within the 802.11 standard (WEP, TKIP, and AES), in addition to some legacy Cisco proprietary methods still used on legacy clients.

Cons with CCKM

It is a Cisco proprietary method, which limits the implementation and support to Cisco WLAN infrastructure and CCX wireless clients.
CCXv5 is not widely adopted yet, so CCKM with WPA2/AES is not supported by many CCX wireless clients yet (mainly because most of them already support CCKM with WPA/TKIP, which is still very secure).

Fast Secure Roaming with WPA2 PMKID caching (aka Sticky Key Caching - SKC)

WPA2 PMKID (Pairwise Master Key ID) caching or Sticky Key Caching (SKC) came as the first fast secure roaming method suggested by the 802.11 standard within the 802.11i security amendment, where the main purpose was to standardize a high level of security for WLANs, but added this fast secure roaming technique as an optional method that could be used by WPA2 devices to improve roaming when this security was implemented. This is possible because, every time a client is fully EAP authenticated, the client and Authentication Server derive a Master Session Key (MSK), which is used to derive the PMK (Pairwise Master Key) that is used as the seed for the WPA2 4-Way handshake to derive the final unicast encryption key (PTK – Pairwise Transient Key) that is going to be used for this session (until the client roams to another AP or session expires); hence, this method helps to avoid the EAP authentication phase when roaming, reutilizing the original PMK cached on the client and the AP, so the client only has to go through the WPA2 4-Way handshake to derive new encryption keys.

This method has not been widely deployed as the recommended 802.11 standard fast secure roaming method, mainly due to a couple of reasons:

This method is actually optional and hence not supported by all WPA2 devices, as the 802.11i purpose was not about fast secure roaming, and the IEEE was already working on another amendment to standardize fast secure roaming for WLANs (802.11r, which will be covered later on this document).
This method has a big limitation on its implementation: Wireless clients can only perform a fast secure roaming when roaming back to an AP where they had previously authenticated/connected.

With this method, the first association to any AP is just like a regular first-time authentication to the WLAN where the entire 802.1X/EAP authentication against the Authentication Server and the 4-Way handshake for key generation must happen before sending data frames as you can see from the captures:

The debugs show basically the same EAP authentication frames exchange than the rest of the methods on the first time authentication to the WLAN, adding just some outputs regarding the key caching techniques used here, so the following debug output is cut to show mainly the new information and not the entire EAP frames exchanged, as that is basically the same information exchanged all the time to authenticate the client against the Authentication Server as demonstrated so far (and correlated with the EAP authentication frames shown on the packet captures, so most of them were removed from the debugs output for simplicity):

*apfMsConnTask_0: Jun 22 00:23:15.097: ec:85:2f:15:39:32 Association received from mobile on BSSID 84:78:ac:f0:68:d2

*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32 Processing RSN IE type 48, length 20 for mobile ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32 Received RSN IE with 0 PMKIDs from mobile ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32 Setting active key cache index 8 ---> 8

*apfMsConnTask_0: Jun 22 00:23:15.099: ec:85:2f:15:39:32 Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d2 (status 0) ApVapId 3 Slot 0

*dot1xMsgTask: Jun 22 00:23:15.103: ec:85:2f:15:39:32 Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32 (EAP Id 1)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32 Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32 Received Identity Response (count=1) from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32 Processing Access-Challenge for mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32 Sending EAP Request from AAA to mobile ec:85:2f:15:39:32 (EAP Id 2)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32 Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32 Received EAP Response from mobile ec:85:2f:15:39:32 (EAP Id 2, EAP Type 25)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32 Processing Access-Accept for mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32 Creating a PKC PMKID Cache entry for station ec:85:2f:15:39:32 (RSN 2)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32 Setting active key cache index 8 ---> 8

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32 Setting active key cache index 8 ---> 0

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32 Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0 for station ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: New PMKID: (16)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:      [0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32 PMK sent to mobility group

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32 Sending EAP-Success to mobile ec:85:2f:15:39:32 (EAP Id 12)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275: Including PMKID in M1  (16)

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:      [0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275: ec:85:2f:15:39:32 Starting key exchange to mobile ec:85:2f:15:39:32, data packets will be dropped

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275: ec:85:2f:15:39:32 Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32  state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32 Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32 Received EAPOL-key in PTK_START state (message 2) from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32 PMK: Sending cache add

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.285: ec:85:2f:15:39:32 Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32  state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32 Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32 Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile ec:85:2f:15:39:32

So with this method, the AP and wireless client will cache the PMKs of the secure associations already established. Therefore, if the wireless client roams to a new AP where it has never associated, it will need to perform again a full EAP authentication, as you can see from the following wireless captures where the client roamed to a new AP:

However, if the wireless client roams back to an AP where it had previously associated/authenticated, then the client will send a Reassociation Request frame that lists multiple PMKIDs, basically informing the AP about all the PMKs it has cached from all the APs where it had previously authenticated. Therefore, since the client is roaming back to an AP that also has a PMK cached for this client, then the client doesn’t need to reauthenticate through EAP to derive a new PMK, but simply go through the WPA2 4-Way handshake to derive the new transient encryption keys:

Note: This capture is not showing the first 802.11 Open System authentication frame from the client, but not due to the method implemented as this frame is always required as it was explained earlier. This is just because that specific frame was not captured by the adapter or wireless packet capture software used to sniff the over the air frames for this example, but it was left like this on the example just for educational purposes, so you can be aware that there are always possibilities that this could happen when performing over the air packet captures (some frames could be missed by the capture, but were actually exchanged between the client and the AP; otherwise, the roaming would have never started on this example).

This is what can be seen on the WLC debugs for this fast secure roaming back:

*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32 Reassociation received from mobile on BSSID 84:78:ac:f0:68:d2

*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32 Processing RSN IE type 48, length 38 for mobile ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32 Received RSN IE with 1 PMKIDs from mobile ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 22 00:26:40.787: Received PMKID:  (16)

*apfMsConnTask_0: Jun 22 00:26:40.788:      [0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32 Searching for PMKID in MSCB PMKID cache for mobile ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32 Found an cache entry for BSSID 84:78:ac:f0:68:d2 in PMKID cache at index 0 of station ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32 Found a valid PMKID in the MSCB PMKID cache for mobile ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32 Setting active key cache index 1 ---> 0

*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32 Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d2 (status 0) ApVapId 3 Slot 0

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32 Initiating RSN with existing PMK to mobile ec:85:2f:15:39:32

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32 Skipping EAP-Success to mobile ec:85:2f:15:39:32

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32 Found an cache entry for BSSID 84:78:ac:f0:68:d2 in PMKID cache at index 0 of station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 22 00:26:40.795: Including PMKID in M1  (16)

*dot1xMsgTask: Jun 22 00:26:40.795:      [0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32 Starting key exchange to mobile ec:85:2f:15:39:32, data packets will be dropped

*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32 Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.811: ec:85:2f:15:39:32 Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32 Received EAPOL-key in PTK_START state (message 2) from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32 PMK: Sending cache add

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32 Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32 Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32 Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile ec:85:2f:15:39:32

FlexConnect with WPA2 PMKID Caching / Sticky Key Caching

When using this method on a FlexConnect setup, the behavior is exactly the same as explained above (doing fast secure roaming), and the APs where the client is roaming to don’t need to belong to the same FlexConnect Group.
This method works only if doing Central Authentication back to the WLC (with either central or local switching); it doesn’t work if doing Local Authentication on the FlexConnect setup (meaning that full 802.1X/EAP authentication must happen again). Hence, it is not supported when the FlexConnect APs are in Standalone mode.

Pros with WPA2 PMKID Caching / Sticky Key Caching

This method can be locally implemented by autonomous-independent APs, without the need of a centralized device managing the cached keys.

Cons with WPA2 PMKID Caching / Sticky Key Caching

As mentioned before, the main limitation of this method is that the client can only do a fast secure roaming when roaming back to an AP where it had previously associated/authenticated. If roaming to a new AP, the client has to do the full EAP authentication again as if there was not a fast secure roaming method implemented.
The wireless client and APs must remember all the PMKs derived on every new authentication, so this feature is normally limited to certain amount of PMKs that can be cached, and since this limit is not clearly defined by the standard, then vendors can define different limits on their SKC implementations. For example, the Cisco Wireless LAN Controllers can currently cache the PMKs of a client for up to eight APs, so if a client roams to more than eight APs per session, the oldest APs are removed from the cache list to store the newly cached entries.
This method is actually optional and hence still not supported by many WPA2 devices; therefore, and also due to the limitations mentioned before, this method has not been widely adopted and deployed.
SKC is not supported when doing intercontroller roaming (moving between APs managed by different WLCs, even if they are on the same mobility group).

Fast Secure Roaming with Proactive Key Caching - PKC (aka Opportunistic Key Caching - OKC)

Proactive Key Caching (PKC) or Opportunistic Key Caching (OKC) is basically an enhancement of the WPA2 PMKID caching method described previously, so this is why it is also named Proactive/Opportunistic PMKID Caching. Hence, it is important to note that this is not a fast secure roaming method defined by the 802.11 standard, so not supported by many devices.

This technique allows the wireless client and the WLAN infrastructure to cache only one PMK for the lifetime of the client's association with this WLAN (derived from the MSK after the initial 802.1X/EAP authentication with the Authentication Server), even when roaming around between multiple APs, as they all share the original PMK that is going to be used as the seed on all WPA2 4-way handshakes (still required, like in SKC, to generate new encryption keys every time the client reassociates with the APs). For the APs to share this one original PMK of the client’s session, they all need to be under some sort of administrative control, with a centralized device caching and distributing the original PMK for all the APs, as it happens on the CUWN, where the WLC is doing this job for all the LAPs under its control (and uses the mobility groups to handle this PMK between multiple WLCs); therefore, this is a limitation on autonomous APs’ environments.

With this method, just like in PMKID Caching (SKC), the first association to any AP is a regular first-time authentication to the WLAN where the entire 802.1X/EAP authentication against the Authentication Server and the 4-Way handshake for key generation must happen before sending data frames as you can see from the captures:

The debugs show basically the same EAP authentication frames exchange than the rest of the methods on the first time authentication to the WLAN (as noticed from the captures), adding just some outputs regarding the key caching techniques used by the WLC here, so the following debug output is also cut to show only the relevant information:

*apfMsConnTask_0: Jun 21 21:46:06.515: 00:40:96:b7:ab:5c Association received from mobile on BSSID 84:78:ac:f0:68:d2

*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c Processing RSN IE type 48, length 20 for mobile 00:40:96:b7:ab:5c

*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c Received RSN IE with 0 PMKIDs from mobile 00:40:96:b7:ab:5c

*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c Setting active key cache index 0 ---> 8

*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d2 (status 0) ApVapId 3 Slot 0

*dot1xMsgTask: Jun 21 21:46:06.522: 00:40:96:b7:ab:5c Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c (EAP Id 1)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c Received EAPOL START from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c (EAP Id 2)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c Processing Access-Challenge for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c (EAP Id 3)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c Received EAP Response from mobile 00:40:96:b7:ab:5c (EAP Id 3, EAP Type 25)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.843: 00:40:96:b7:ab:5c Processing Access-Accept for mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c Creating a PKC PMKID Cache entry for station 00:40:96:b7:ab:5c (RSN 2)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c Setting active key cache index 8 ---> 8

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c Setting active key cache index 8 ---> 0

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0 for station 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: New PMKID: (16)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:      [0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c PMK sent to mobility group

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c Sending EAP-Success to mobile 00:40:96:b7:ab:5c (EAP Id 13)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c Found an cache entry for BSSID 84:78:ac:f0:68:d2 in PMKID cache at index 0 of station 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: Including PMKID in M1  (16)

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:      [0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c Starting key exchange to mobile 00:40:96:b7:ab:5c, data packets will be dropped

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c Received EAPOL-key in PTK_START state (message 2) from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c PMK: Sending cache add

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.889: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.890: 00:40:96:b7:ab:5c Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile 00:40:96:b7:ab:5c

So with this method, the wireless client and the WLC (for all the managed APs) will cache the one original PMK of the secure association initially established. Basically, every time the wireless client connects to a specific AP, a PMKID is hashed based on the client’s MAC address, the AP’s MAC address (BSSID of the WLAN) and the PMK derived with that AP. Therefore, since PKC/OKC is caching the same original PMK for all the APs and the specific client, when this client (re)associates to another AP, the only value that will change to hash the new PMKID is the new AP’s MAC address. So when the client initiates a roam to a new AP sending the Reassociation Request frame (which should have a PMKID on the WPA2 RSN Information Element if it wants to inform the AP that a cached PMK is going to be used for fast secure roaming), as it already knows the MAC address of the BSSID (AP) it is roaming to, the client simply hashes the new PMKID that is used on this Reassociation Request. When the AP receives this request from the client, it also hashes the PMKID with the values it already has (the cached PMK, client’s MAC, and its own AP MAC), answering back with the successful Reassociation Response that confirms the PMKIDs matched and the cached PMK can be used as the seed to start a WPA2 4-Way handshake to derive the new encryption keys (skipping EAP):

In this capture, the Reassociation Request frame from the client is selected and expanded so you can see more details of the frame. You can see the MAC addresses information and also the RSN (Robust Security Network as per 802.11i – WPA2) Information Element, where some information about the WPA2 settings used for this association is shown (highlighted is the PMKID obtained from the hashed formula).

This is what can be seen on the WLC debugs for this fast secure roaming with OKC/PKC:

*apfMsConnTask_2: Jun 21 21:48:50.562: 00:40:96:b7:ab:5c Reassociation received from mobile on BSSID 84:78:ac:f0:2a:92

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Processing RSN IE type 48, length 38 for mobile 00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Received RSN IE with 1 PMKIDs from mobile 00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 21 21:48:50.563: Received PMKID:  (16)

*apfMsConnTask_2: Jun 21 21:48:50.563:      [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Searching for PMKID in MSCB PMKID cache for mobile 00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c No valid PMKID found in the MSCB PMKID cache for mobile 00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Trying to compute a PMKID from MSCB PMK cache for mobile 00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 21 21:48:50.563: CCKM: Find PMK in cache: BSSID =  (6)

*apfMsConnTask_2: Jun 21 21:48:50.563:      [0000] 84 78 ac f0 2a 90

*apfMsConnTask_2: Jun 21 21:48:50.563: CCKM: Find PMK in cache: realAA =  (6)

*apfMsConnTask_2: Jun 21 21:48:50.563:      [0000] 84 78 ac f0 2a 92

*apfMsConnTask_2: Jun 21 21:48:50.563: CCKM: Find PMK in cache: PMKID =  (16)

*apfMsConnTask_2: Jun 21 21:48:50.563:      [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9

*apfMsConnTask_2: Jun 21 21:48:50.563: CCKM: AA (6)

*apfMsConnTask_2: Jun 21 21:48:50.563:      [0000] 84 78 ac f0 2a 92

*apfMsConnTask_2: Jun 21 21:48:50.563: CCKM: SPA (6)

*apfMsConnTask_2: Jun 21 21:48:50.563:      [0000] 00 40 96 b7 ab 5c

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Adding BSSID 84:78:ac:f0:2a:92 to PMKID cache at index 0 for station 00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 21 21:48:50.563: New PMKID: (16)

*apfMsConnTask_2: Jun 21 21:48:50.563:      [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Computed a valid PMKID from MSCB PMK cache for mobile 00:40:96:b7:ab:5c

*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Setting active key cache index 0 ---> 0

*apfMsConnTask_2: Jun 21 21:48:50.564: 00:40:96:b7:ab:5c Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:92 (status 0) ApVapId 3 Slot 0

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c Initiating RSN with existing PMK to mobile 00:40:96:b7:ab:5c

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c Skipping EAP-Success to mobile 00:40:96:b7:ab:5c

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c Found an cache entry for BSSID 84:78:ac:f0:2a:92 in PMKID cache at index 0 of station 00:40:96:b7:ab:5c

*dot1xMsgTask: Jun 21 21:48:50.570: Including PMKID in M1  (16)

*dot1xMsgTask: Jun 21 21:48:50.570:      [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c Starting key exchange to mobile 00:40:96:b7:ab:5c, data packets will be dropped

*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c Received EAPOL-key in PTK_START state (message 2) from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c PMK: Sending cache add

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.590: 00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c

*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile 00:40:96:b7:ab:5c

As you can see at the beginning of the debugs, the PMKID must be computed after receiving the Reassociation Request from the client, but as it was explained before, this is easily done and just to validate the PMKID and confirm that the cached PMK can be used to go immediately with the WPA2 4-Way handshake doing the fast secure roaming (do not confuse the “CCKM” entry on the debugs, this is not doing CCKM but PKC/OKC as it has been explained; CCKM here is just a name used by the WLC for those outputs; like the name of a function handling the values to compute the PMKID).

FlexConnect with Proactive/Opportunistic Key Caching

When using this method on a FlexConnect setup, the behavior is exactly the same as explained above (doing fast secure roaming), and the APs where the client is roaming to don’t need to belong to the same FlexConnect Group.
This method works only if doing Central Authentication back to the WLC (with either central or local switching); it doesn’t work if doing Local Authentication on the FlexConnect setup (meaning that full 802.1X/EAP authentication must happen again). Hence, it is not supported when the FlexConnect APs are in Standalone mode.

Pros with WPA2 Proactive/Opportunistic Key Caching

The wireless client and the WLAN infrastructure don’t need to remember multiple PMKIDs, but simply cache the one original PMK from the initial authentication to the WLAN, and then just re-hash the proper PMKID (used on the Reassociation Request) required with each AP’s secure association to validate the fast secure roaming.
Here, the wireless client can perform a fast secure roaming to a new AP on the same WLAN/SSID, even if it has never associated with that AP (not the case in SKC). So as long as the client performs the initial full 802.1X/EAP authentication with one AP managed by the centralized deployment that handles the PMK cache for all the APs where the client can roam, then no more full authentications are required for the rest of the client’s lifetime on this WLAN.

Cons with WPA2 Proactive/Opportunistic Key Caching

This method can only be deployed on a centralized environment where all the APs are under some sort of administrative control (like a Wireless LAN Controller) in charge of caching and sharing the only one original PMK of the client’s session. Therefore, this is a limitation on autonomous APs’ environments.
The techniques applied on this method are not even suggested as optional on the 802.11 standard, so it is still not supported by many WPA2 devices that probably won’t even support it ever. Therefore, this method has not been widely adopted and deployed.

Fast Secure Roaming with 802.11r - Fast BSS Transition (FT)

The fast secure roaming technique based on the 802.11r amendment (officially named “Fast BSS Transition” by the 802.11 standard and known as FT) is the first method officially ratified (on 2008) by the IEEE for the 802.11 standard as the solution to do fast transitions between APs (BSSs), clearly defining the key hierarchy that should be used when handling and caching keys on a WLAN. However, its adoption has been slow, mainly due to the other solutions already available when fast transitions were actually required (like with VoWLAN implementations using one of the methods already explained so far), so there are just a few devices currently supporting some of the FT options (by 2013).

This technique is more complex to explain than the other methods, as it introduces new concepts and multiple layers of PMKs that are cached on different devices (each device with a different role), and providing even different options to fast roam. Therefore, and since this document is not meant to cover the inner details of 802.11r, a brief summary is provided about this method and the way it is implemented on each different option available.

First of all, 802.11r is different from SKC and PKC/OKC mainly because of the following:

Handshake messaging (i.e. PMKID, ANonce, and SNonce exchange) happens in 802.11 Authentication frames or in Action frames instead of Reassociation frames. Hence, unlike PMKID caching methods, we will avoid the separate 4-Way handshake phase which is carried after association message exchange, as the key handshake with the new AP starts even before the client fully roams/reassociates with this new AP.
It provides 2 ways of fast roaming handshake: over the AIR and over the DS (Distribution System).
802.11r has more layers of key hierarchy.
As this protocol avoids even the 4-Way handshake for the key management when roaming (generating new encryption keys -PTK and GTK- without the need of this handshake), it can be also applied for WPA2 setups with a PSK (and not only when 802.1X/EAP is used for the authentication), accelerating roaming even more for these setups, where no EAP or 4-Way handshake exchanges happen.

With this method, the wireless client performs just one initial full authentication against the WLAN infrastructure when connecting to the first AP, doing a fast secure roaming while moving between APs of the same FT mobility domain (one of the new concepts, which basically refers to the APs using the same SSID -aka ESS- and handling the same FT keys; similar to the other methods explained so far). The way the APs handle the FT mobility domain keys is normally based on a centralized setup (such as the WLC or mobility groups), but this method could be also implemented on autonomous APs environments.

The following is a summary of the key hierarchy:

An MSK (Master Session Key) is still derived on the client supplicant and the Authentication Server from the 802.1X/EAP authentication phase (transferred from the Authentication Server to the Authenticator -WLC- once the authentication is successful). This MSK, like in the other methods, is going to be used as the seed for the FT key hierarchy. When using WPA2-PSK instead of an EAP authentication method, the PSK is basically this MSK.
Then, a Pairwise Master Key R0 (PMK-R0) is derived from the MSK, being the first-level key of the FT key hierarchy. The key holders for this PMK-R0 are the WLC and the client.
A second-level key called Pairwise Master Key R1 (PMK-R1) is derived from the PMK-R0, and the key holders are the client and the APs managed by the WLC holding the PMK-R0.
The third and final level key of the FT key hierarchy is the PTK (Pairwise Transient Key), which is the final key used to encrypt the 802.11 unicast data frames (just like in the other methods using WPA/TKIP or WPA2/AES). This PTK is derived on FT from the PMK-R1, and the key holders are also the client and the APs managed by the WLC.

Note: Depending on the WLAN vendor and their implementation setups (such as Autonomous APs, FlexConnect, or Mesh), the WLAN infrastructure might transfer and handle the keys in a different way and even changing the roles of the key holders, but since that is out of the scope of this document, we will continue the examples based on the key hierarchy summary given above. The differences are actually not that relevant to understand the process, unless you actually need to analyze in depth the infrastructure devices (and their code) looking for a software issue.

Fast BSS Transition Over-the-Air

So with this method, just like in the other methods, the first association to any AP is a regular first-time authentication to the WLAN where the entire 802.1X/EAP authentication against the Authentication Server and the 4-Way handshake for key generation must happen before sending data frames as you can see from the captures:

The main differences are:

The Authentication Key Management negotiation is a bit different than regular WPA/WPA2, so some extra information is used to perform this negotiation during the association to a WLAN infrastructure supporting FT. As you can see from the captures, the Association Request frame from the client is selected and the AKM field of the RNS Information Element is highlighted to show that this client wants to do FT over 802.1X/EAP.
You can also see the Mobility Domain Information Element (part of FT), where the “FT Capability and Policy” field indicates if the Fast BSS Transition is going to be done Over-the-Air or Over-the-DS when fast roaming (indicating Over-the-Air in this capture).
Another information element is also added (Fast BSS Transition or FT IE, which we will see later on another capture) with information needed to perform the FT authentication sequence during an FT roaming.
The key generation is different due to the key hierarchy, so even though the FT 4-Way handshake looks similar to the WPA/WPA2 4-Way handshake, it is actually a bit different in content.

The debugs show basically the same EAP authentication frames exchange than the rest of the methods on the first time authentication to the WLAN (as noticed from the captures), adding just some outputs regarding the key caching techniques used by the WLC here, so the following debug output is also cut to show only the relevant information:

*apfMsConnTask_0: Jun 27 19:25:23.426: ec:85:2f:15:39:32 Association received from mobile on BSSID 84:78:ac:f0:68:d6

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32 Marking this mobile as TGr capable.

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32 Processing RSN IE type 48, length 20 for mobile ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 27 19:25:23.427: Sending assoc-resp station:ec:85:2f:15:39:32 AP:84:78:ac:f0:68:d0-00 thread:144be808

*apfMsConnTask_0: Jun 27 19:25:23.427: Adding MDIE, ID is:0xaaf0

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32 Including FT Mobility Domain IE (length 5) in Initial assoc Resp to mobile

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32 Sending R0KH-ID as:-84.30.6.-3

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32 Sending R1KH-ID as 3c:ce:73:d8:02:00

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32 Including FT IE (length 98) in Initial Assoc Resp to mobile

*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32 Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d6 (status 0) ApVapId 7 Slot 0

*dot1xMsgTask: Jun 27 19:25:23.432: ec:85:2f:15:39:32 Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32 (EAP Id 1)

*apfMsConnTask_0: Jun 27 19:25:23.436: ec:85:2f:15:39:32 Got action frame from this client.

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32 Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32 Received Identity Response (count=1) from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32 Processing Access-Challenge for mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32 Sending EAP Request from AAA to mobile ec:85:2f:15:39:32 (EAP Id 2)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32 Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32 Received EAP Response from mobile ec:85:2f:15:39:32 (EAP Id 2, EAP Type 25)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32 Processing Access-Accept for mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32 Creating a PKC PMKID Cache entry for station ec:85:2f:15:39:32 (RSN 2)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32 Resetting MSCB PMK Cache Entry 0 for station ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32 Setting active key cache index 8 ---> 8

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32 Setting active key cache index 8 ---> 0

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32 Adding BSSID 84:78:ac:f0:68:d6 to PMKID cache at index 0 for station ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: New PMKID: (16)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628:      [0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629: ec:85:2f:15:39:32 Created PMK Cache Entry for TGr AKM:802.1x ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629: ec:85:2f:15:39:32   R0KH-ID:172.30.6.253   R1KH-ID:3c:ce:73:d8:02:00  MSK Len:48 pmkValidTime:1807

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32 PMK sent to mobility group

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32 Sending EAP-Success to mobile ec:85:2f:15:39:32 (EAP Id 12)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32 Found an cache entry for BSSID 84:78:ac:f0:68:d6 in PMKID cache at index 0 of station ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: Including PMKID in M1  (16)

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630:      [0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32 Starting key exchange to mobile ec:85:2f:15:39:32, data packets will be dropped

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32 Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32 Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32 Received EAPOL-key in PTK_START state (message 2) from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32 Calculating PMKR0Name

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32 DOT11R: Sending cache add

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: Adding MDIE, ID is:0xaaf0

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32 Adding TIE for reassociation deadtime:20000 milliseconds

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32 Adding TIE for R0Key-Data valid time :1807

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.640: ec:85:2f:15:39:32 Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32 Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32 Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile ec:85:2f:15:39:32

Note: To debug this method and get the extra 802.11r/FT outputs shown here, an additional debug is enabled along with the 'debug client', which is the 'debug ft events enable'.

The following are the captures and debugs of an initial association to the WLAN when doing FT with WPA2-PSK (instead of an 802.1X/EAP method), where this time the Association Response frame from the AP is selected to show the Fast BSS Transition Information Element (highlighted), where you can see some of the key information needed to perform the FT 4-Way handshake that follows:

*apfMsConnTask_0: Jun 27 19:29:09.136: ec:85:2f:15:39:32 Association received from mobile on BSSID 84:78:ac:f0:68:d4

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32 Marking this mobile as TGr capable.

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32 Processing RSN IE type 48, length 20 for mobile ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 27 19:29:09.137: Sending assoc-resp station:ec:85:2f:15:39:32 AP:84:78:ac:f0:68:d0-00 thread:144be808

*apfMsConnTask_0: Jun 27 19:29:09.137: Adding MDIE, ID is:0xaaf0

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32 Including FT Mobility Domain IE (length 5) in Initial assoc Resp to mobile

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32 Sending R0KH-ID as:-84.30.6.-3

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32 Sending R1KH-ID as 3c:ce:73:d8:02:00

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32 Including FT IE (length 98) in Initial Assoc Resp to mobile

*apfMsConnTask_0: Jun 27 19:29:09.138: ec:85:2f:15:39:32 Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d4 (status 0) ApVapId 5 Slot 0

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32 Creating a PKC PMKID Cache entry for station ec:85:2f:15:39:32 (RSN 2)

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32 Resetting MSCB PMK Cache Entry 0 for station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32 Setting active key cache index 8 ---> 8

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32 Setting active key cache index 8 ---> 0

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32 Adding BSSID 84:78:ac:f0:68:d4 to PMKID cache at index 0 for station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: New PMKID: (16)

*dot1xMsgTask: Jun 27 19:29:09.142:      [0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32 Creating global PMK cache for this TGr client

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32 Created PMK Cache Entry for TGr AKM:PSK ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32   R0KH-ID:172.30.6.253   R1KH-ID:3c:ce:73:d8:02:00  MSK Len:48 pmkValidTime:1813

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32 Initiating RSN PSK to mobile ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32 Found an cache entry for BSSID 84:78:ac:f0:68:d4 in PMKID cache at index 0 of station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: Including PMKID in M1  (16)

*dot1xMsgTask: Jun 27 19:29:09.142:      [0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7

*dot1xMsgTask: Jun 27 19:29:09.143: ec:85:2f:15:39:32 Starting key exchange to mobile ec:85:2f:15:39:32, data packets will be dropped

*dot1xMsgTask: Jun 27 19:29:09.143: ec:85:2f:15:39:32 Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

*apfMsConnTask_0: Jun 27 19:29:09.144: ec:85:2f:15:39:32 Got action frame from this client.

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.152: ec:85:2f:15:39:32 Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32 Received EAPOL-key in PTK_START state (message 2) from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32 Calculating PMKR0Name

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: Adding MDIE, ID is:0xaaf0

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32 Adding TIE for reassociation deadtime:20000 milliseconds

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32 Adding TIE for R0Key-Data valid time :1813

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.154: ec:85:2f:15:39:32 Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32 Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32 Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile ec:85:2f:15:39:32

So with 802.11r, this initial association to the WLAN will be the basis to derive the base keys used by this technique, just like in the other fast secure roaming methods. The main differences come when the client starts roaming, where FT not only avoids 802.1X/EAP when this is used, but it actually performs a more efficient roaming method that combines the initial 802.11 Open System Authentication and Reassociation frames (which are always used and required when roaming between APs as you have noticed) to exchange FT information and derive new dynamic encryption keys in place of the 4-Way handshake.

The following capture shows the frames exchanged when doing Fast BSS Transition Over-the-Air using 802.1X/EAP security, where the Open System Authentication frame from the client to the AP is selected to see that we have the FT protocol Information Elements required for the client to start the FT key negotiation needed to derive the new PTK with the new AP (based on the PMK-R1); the field that shows the authentication algorithm is highlighted to see that this client is not really doing a simple Open System Authentication, but a Fast BSS Transition:

The following are the debug outputs from the WLC when this FT roaming event occurs using 802.1X/EAP:

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32 Doing preauth for this client over the Air

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32 Doing local roaming for destination address 84:78:ac:f0:2a:96

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32 Got 1 AKMs in RSNIE

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32 RSNIE AKM matches with PMK cache entry :0x3

*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32 Created a new preauth entry for AP:84:78:ac:f0:2a:96

*apfMsConnTask_2: Jun 27 19:25:48.751: Adding MDIE, ID is:0xaaf0

*apfMsConnTask_2: Jun 27 19:25:48.763: Processing assoc-req station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00 thread:144bef38

*apfMsConnTask_2: Jun 27 19:25:48.763: ec:85:2f:15:39:32 Reassociation received from mobile on BSSID 84:78:ac:f0:2a:96

*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32 Marking this mobile as TGr capable.

*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32 Processing RSN IE type 48, length 38 for mobile ec:85:2f:15:39:32

*apfMsConnTask_2: Jun 27 19:25:48.765: ec:85:2f:15:39:32 Roaming succeed for this client.

*apfMsConnTask_2: Jun 27 19:25:48.765: Sending assoc-resp station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00 thread:144bef38

*apfMsConnTask_2: Jun 27 19:25:48.766: Adding MDIE, ID is:0xaaf0

*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32 Including FT Mobility Domain IE (length 5) in reassociation assoc Resp to mobile

*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32 Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:96 (status 0) ApVapId 7 Slot 0

*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32 Finishing FT roaming for mobile ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32 Skipping EAP-Success to mobile ec:85:2f:15:39:32

The following is the capture when doing Fast BSS Transition Over-the-Air using WPA2-PSK security, where the final Reassociation Response frame from the AP to the client is selected in this case to see more details about this FT exchange:

The debug outputs when this FT roaming occurs using PSK are basically the same:

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32 Doing preauth for this client over the Air

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32 Doing local roaming for destination address 84:78:ac:f0:2a:94

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32 Got 1 AKMs in RSNIE

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32 RSNIE AKM matches with PMK cache entry :0x4

*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32 Created a new preauth entry for AP:84:78:ac:f0:2a:94

*apfMsConnTask_2: Jun 27 19:29:29.854: Adding MDIE, ID is:0xaaf0

*apfMsConnTask_2: Jun 27 19:29:29.867: Processing assoc-req station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00 thread:144bef38

*apfMsConnTask_2: Jun 27 19:29:29.867: ec:85:2f:15:39:32 Reassociation received from mobile on BSSID 84:78:ac:f0:2a:94

*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32 Marking this mobile as TGr capable.

*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32 Processing RSN IE type 48, length 38 for mobile ec:85:2f:15:39:32

*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32 Roaming succeed for this client.

*apfMsConnTask_2: Jun 27 19:29:29.869: Sending assoc-resp station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00 thread:144bef38

*apfMsConnTask_2: Jun 27 19:29:29.869: Adding MDIE, ID is:0xaaf0

*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32 Including FT Mobility Domain IE (length 5) in reassociation assoc Resp to mobile

*apfMsConnTask_2: Jun 27 19:29:29.870: ec:85:2f:15:39:32 Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:94 (status 0) ApVapId 5 Slot 0

*dot1xMsgTask: Jun 27 19:29:29.874: ec:85:2f:15:39:32 Finishing FT roaming for mobile ec:85:2f:15:39:32

As you can see from the captures, once Fast BSS Transition has been negotiated on the initial association to the WLAN, these four frames used and required for roaming (Open System Authentication from the client, Open System Authentication from the AP, Reassociation Request, and Reassociation Response) are basically used as an FT 4-Way handshake to derive the new PTK (unicast encryption key) and GTK (multicast/broadcast encryption key), substituting the 4-Way handshake that normally happens after these frames are exchanged, and where the FT content and key negotiation on these frames is basically the same whether you are using 802.1X/EAP or PSK as the security method (as you can see from the captures, an AKM field will be the main difference, confirming if the client is doing FT using PSK or 802.1X). Therefore, it is important to note that these frames will normally not have this type of security information for key negotiation, but only when doing FT roaming if 802.11r is implemented and negotiated between the client and the WLAN infrastructure on the initial association.

Fast BSS Transition Over-the-DS

As it was mentioned before, 802.11r allows another implementation of Fast BSS Transition, where the FT roaming is initiated by the client with the new roaming-to AP Over-the-DS (Distribution System) and not Over-the-Air as per the examples above. In this case, FT Action frames are used to initiate the key negotiation instead of the Open System Authentication frames.

Basically, once the client decides it might roam to a better AP, the client sends an FT Action Request frame to the original AP where it is currently connected before roaming, but indicating the BSSID (MAC address) of the target AP where it wants to FT roam. The original AP forwards this FT Action Request frame to the target AP using the Distribution System (over the wired infrastructure), and the target AP responds back to the client an FT Action Response frame (also over the DS, so sending it back to the original AP, so it can finally send it over the air to the client). Once this FT Action frames exchange is successful, the client finishes the FT roaming by sending the Reassociation Request to the target AP (this time over the air, just like a regular roaming), receiving a Reassociation Response from the new AP to confirm the roaming and final keys derivation.

In Summary, we still have four frames to negotiate Fast BSS Transition and derive new encryption keys, but here, the Open System Authentication frames are substituted with the FT Action Request/Response frames, which are exchanged with the target AP over the Distribution System using the current AP. This method is also valid for both security methods 802.1X/EAP and PSK, all supported by the Cisco Wireless LAN Controllers, but since this Over-the-DS transition is not really supported and implemented by most of the wireless clients in the WiFi industry (and since the frames exchange and debug outputs are basically the same with the only differences explained here), examples are not shown on this document; instead, the following image is used to visualize this Fast BSS Transition Over-the-DS:

FT Over-the-DS.png

FlexConnect with 802.11r

When using this method on a FlexConnect setup, the behavior is exactly the same as explained above (doing fast secure roaming), and the APs where the client is roaming to don’t need to belong to the same FlexConnect Group.
This method works only if doing Central Authentication back to the WLC (with either central or local switching); it doesn’t work if doing Local Authentication on the FlexConnect setup. Hence, it is not supported when the FlexConnect APs are in Standalone mode.

Pros with 802.11r

This method is the first one using a key hierarchy clearly defined by the IEEE on the 802.11 standard as an amendment (802.11r), so the implementation of these FT techniques should be more compatible between vendors and without different interpretations.
802.11r allows multiple different techniques that could be helpful depending on the needs (Over-the-Air and Over-the-DS, for 802.1x/EAP security and for PSK security).
Here, the wireless client can perform a fast secure roaming to a new AP on the same WLAN/SSID, even if it has never associated with that AP, and without the need of saving multiple PMKIDs.
This is the first fast secure roaming method that allows a faster roaming even when using PSK security, avoiding the 4-Way handshake that was always required when roaming between APs using WPA/WPA2 PSK. As it has been explained, the main purpose of the fast secure roaming methods was to avoid the 802.1X/EAP handshake when this security method was implemented, but here, the roaming event is accelerated even more avoiding the 4-Way handshake, even when using PSK.

Cons with 802.11r

By 2013, there are still just a very few amount of wireless client devices that actually support Fast BSS Transitions, and in most cases, they don't even support all of the techniques available on 802.11r.
Because of the fact that these implementations are just getting started, enough testing on real production environments have not been performed and debugged enough to start cleaning possible caveats that might appear.
When you configure a WLAN/SSID to do any of the FT methods, then only wireless clients that support 802.11r will be able to connect to this WLAN/SSID. The FT settings are not optional for the clients, so those wireless clients that don’t support 802.11r will need to connect using a separate WLAN/SSID where FT is not configured at all.

Conclusions

First of all, it is very important to understand that fast secure roaming methods were developed to accelerate the WLAN roaming process when moving between APs if the WLAN/SSID has security enabled. When no security is in place, there is really nothing that can be “accelerated”, as the client-AP will simply exchange the wireless management frames that are always required when roaming between APs before sending data frames (Open System Authentication from the client, Open System Authentication from the AP, Reassociation Request, and Reassociation Response), so this can’t be any faster. When having roaming issues without using security, then there is really nothing that should be configured to improve roaming, but actually just confirm if the WLAN/SSID setup and design are appropriate for the wireless client stations to roam accordingly between the AP’s coverage cells.
As it was explained, the main purpose of the fast secure roaming methods was to avoid the 802.1X/EAP handshake when this specific security method was implemented, so WLAN roaming events can’t really be faster either if other security methods are deployed. The only exception standardized nowadays is when 802.11r/FT is implemented with WPA2-PSK to accelerate roaming events even a bit more by just avoiding the 4-Way handshake as explained within the 802.11r section.
None of the fast secure roaming methods work in a FlexConnect setup when the APs are in Standalone mode.
All of the methods have their advantages and disadvantages as you can conclude from the explanations and the Pros/Cons sections, but in the end, you always have to check the following: Do my wireless client stations support the specific method that I want to implement? The Cisco WLAN infrastructure supports all of the methods available, so one must select the best method that is actually supported by the wireless clients that will connect to the specific WLAN/SSID. For example, in some deployments, one might create a WLAN/SSID with CCKM for Cisco wireless IP Phones (which support WPA2/AES with CCKM but not 802.11r yet), and then another WLAN/SSID with WPA2/AES doing 802.11r/FT for wireless clients that support this fast secure roaming method and probably not CCKM (or using OKC/PKC if this is what they support).
If the wireless clients don’t support any of the fast secure roaming methods available, then one might need to live with the fact that those clients will always have the delays explained on this document when roaming between APs on a WLAN/SSID using 802.1X/EAP security (which can cause disruptions on the clients’ apps/services depending on their behavior and sensitivity).
All methods, except SKC (WPA2 PMKID Caching), are supported for fast secure roaming between APs managed by different WLCs (intercontroller roaming), as long as they are on the same mobility group.

Rajan Parmar · ‎09-19-2013

- Oftentimes, it is said that a picture speaks a thousand words, but what if the picture itself is not clear?

- Thousands of words of this great article help to build that picture which must be clear to understand the basics of wireless so that roaming process, can further be understood.

- Very nice article with wireless facts mentioned in the order of sequence, in which they occur, with reference to examples so that one can map the theoretical concepts with practical scenarios.

Jeal Jimenez · ‎03-01-2016

Please check the official cisco.com document for the updated version:

802.11 WLAN Roaming and Fast-Secure Roaming on CUWN

http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html

Tymofii Dmytrenko · ‎12-03-2016

Great article.

May I make a comment re the following?

CCXv5 is not widely adopted yet, so CCKM with WPA2/AES is not supported by many CCX wireless clients yet (mainly because most of them already support CCKM with WPA/TKIP, which is still very secure)

This sounds controversial to official Cisco comments, where it's been said that CCKM was introduced in CCXv2, WPA2 was introduced in CCXv3. Does it mean that WPA2/AES support for CCKM was introduced in CCXv5? Where can I read about it?

I did a test yesterday with my CCXv4 client and WPA2/AES-CCMP with CCKM enabled and it was working fine! WLC debug outputs corresponded to this article and I only have reassociation packets OTA with not 4Way Handshake. So it is indeed working on CCXv4 with WPA2/AES. So... is this quoted comment above accurate? Or, maybe it has to be changed in the latest version of this officially published article?

Thank you

Tim

Jeal Jimenez · ‎12-07-2016

Thanks for the feedback Tim!

I honestly went straight to the "safe" place in this topic... Basically, as you know, things changed over time from CCX version to next version for the proper or full support of some features... For example, at the beginning CCKM was only supported with TKIP, then WPA2/AES support was added but not all the EAP methods supported it, then at another CCX version most of the well known/used EAP methods were finally supported with CCKM... So I didn't want to get into the CCX versioning details because this doc is not about CCX, so I went safe with the latest CCX version5 which was the latest that supports basically everything and that should be hopefully used by people still using CCX features, but I understand this could confuse.

In the end, my point was to explain that one disadvantage of CCKM is that you need to have, first a CCX client that supports CCKM, and then, make sure that the client is running a CCX version that supports what you want to use (CCKM, AES if you want, specific EAP method...). Therefore, and mainly since CCX program is frozen (hence many CCX docs are not available anymore), you just need to be aware of this limitation and really need to find out if your wireless client supports what you need, and if it does (for example, your CCXv4 client works fine with AES and the EAP method you want as in your test), then you can surely go for it and use it, but still, the best recommendation is to run the latest CCX version available for that client.

I can surely change the statement if this is confusing, just don't want to make it larger and confuse more... maybe just adjust a couple of words, so if you can share the Cisco docs that you say contradict this statement, I can do appropriate changes aligned to those docs to avoid confusion.

nikhilcherian · ‎09-24-2017

Nice explanation by sniffer captures & the debugs.

I see in many places, SKC,OKC, PMKID caching are used in similar manner. In the below link, which is little old one, it is mentioned that the "Even with Key Caching, a wireless station must authenticate with each AP it wishes to get service from. This introduces significant latency and overheads, which delay the hand-off process and can inhibit the ability to support real-time applications. In order to resolve this issue, PKC was introduced with WPA2."

https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/118833-wlc-design-ftrs-faq.html

Is PKC same as "Fast Secure Roaming with WPA2 PMKID caching" that you mentioned in the document or is it something different

Regards

Nikhil