802.11r Fast-secure-roaming

• Mobility requires that client stations have the ability to transition from one access point to another while maintaining network connectivity for the upper-layer applications. This ability is known as roaming
• Ideally, all client stations should use WPA2-Enterprise level security when roaming between access points
• Due the multiple frame exchanges between the authentication server and the supplicant, an 802.1X/EAP authentication often takes 700 milliseconds (ms) or greater for the client to authenticate. VoWiFi requires a handoff of 150 ms or less to avoid a degradation of the quality of the call or, even worse, a loss of connection. Therefore, faster and secure roaming handoffs are required.
• The 802.11i security amendment, which is now part of the 802.11- 2007 standard, defines two fast secure roaming mechanisms called preauthentication and PMK caching. Most WLAN vendors currently use an enhanced method of FSR called opportunistic PMK caching.
• The reassociation service enables an established association between
• an access point (AP) and a client station (STA) to be transferred from one AP to another AP. Reassociation allows a client station to move from one basic service set (BSS) to another, and therefore a more technical term used for roaming is BSS transition .

Client Roaming Thresholds

• WLAN environments, client stations always initiate the roaming process known as reassociation. In simpler words, clients make the roaming decision and access points do not tell the client when to roam. What causes the client station to roam is a set of  proprietary rules determined by the manufacturer of the wireless card, usually defi ned by received signal strength indicator (RSSI) thresholds.

AP - to - AP Handoff

• The 802.11 - 2007 standard also does not defi ne AP - to - AP handoff communications. As the station roams, the original access point and the target access point should communicate with each other across the distribution system medium (DSM) and help provide a clean transition between the two Aps
• The AP - to - AP handoff communications involves two primary tasks:

1. The target AP informs the original AP that the client station is roaming.

2. The target AP requests the client ’ s buffered packets from the original AP.

Let ’ s discuss how roaming works with legacy autonomous APs

roaming occurs  after the client and the access point have exchanged reassociation frames, as described in the following steps:

1. In the first step, the client station sends a reassociation request frame to the target access point. The reassociation request frame includes the BSSID (MAC address) of the  access point to which it is currently connected (we will refer to this as the original AP).
2. The target access point then replies to the station with an ACK.
3. The target access point attempts to communicate with the original AP by using the distribution system (DS). The target access point attempts to notify the original AP about the roaming client to inform the original AP that the client is leaving the original BSS. The target AP also requests that the original AP forward any buffered data.  Please remember that these communications between the APs via the DSM are not defined by the 802.11 – 2007 standard and are proprietary.
4. If this communication is successful, the original access point will use the distribution system medium to forward any buffered data to the target access point .
5. The target access point then sends a reassociation response frame to the client via the wireless network.
6. The client sends an ACK to the target access point. The client has now joined the BSS of the target AP.
7. If the reassociation is not successful, the client will retain its connection to the original  AP and either will continue to communicate with the original AP or attempt to roam to another access point.

When autonomous APs are used, AP - to - AP roaming handoffs present two problems.

First, because the back - end communications are proprietary, different vendors ’ APs would

not effectively talk to each other.

The second problem with legacy autonomous AP - to - AP roaming handoffs was the

latency involved with forwarding the buffered packets between APs. The handoff times

with autonomous APs were very slow. In WLAN controller - based solutions, the roaming

handoff mechanisms occur within the WLAN controller. The client station packets are also

buffered on the centralized WLAN controller and do not have to be forwarded between

APs. Therefore, the roaming handoffs that occur within WLAN controllers are much faster

than roaming handoffs between legacy autonomous access points.

RSNA(robust security network).

• Keep in mind that a robust security network association (RSNA) requires two 802.11 stations (STAs) to establish procedures to authenticate and associate with each other as well as create dynamic encryption keys through the 4 - Way Handshake process.
• Every time a client roams, unique encryption keys must be generated using a 4 – Way Handshake process between the access point and the client STA. As you have already learned, either an 802.1X or PSK authentication process is needed to produce the pairwise master key (PMK) that seeds the 4 - Way Handshake.
• Therefore, every time a client roams, the client must reauthenticate. An 802.1X framework requires multiple EAPOL frames to  be exchanged between the supplicant and the authentication server (AS).
• If a client station  has to reauthenticate using 802.1X/EAP every time, the roaming process will be secure but the delay will be significant.
• A typical 802.1X/EAP roaming handoff can take 700 ms, which far exceeds the needed handoff time of 150 ms or less for VoWiFi. Secure roaming handoff times will be even worse if the RADIUS server resides across a WAN link. The 802.11i security amendment is now part of the 802.11 - 2007 standard and defi nes two fast secure roaming mechanisms called preauthentication and PMK caching.

PMKSA(pairwise master key security association)

• RSNAs can be broken down into several subtypes.
• PMKSA is the result of a successful IEEE 802.1X authentication exchange between a supplicant and authentication server (AS) or from a preshared key (PSK) authentication.
• PMK is the seeding material for the 4 – Way Handshake that creates the pairwise transient key (PTK), which is used for encryption and decryption of unicast traffic.
• Once the 4 - Way Handshake creates the fi nal encryption keys, a pairwise transient key security association (PTKSA) exists between the authenticator and the supplicant.
• RSN security can be identifi ed by a fi eld found in certain 802.11 management frames. This field is known as the robust security network information element (RSNIE),
• The RSN information element fi eld is found in four different 802.11 management frames: beacon management frames, probe response frames, association request frames, and reassociation request frames

RSN information element format:

• The pairwise master key identifi er (PMKID) is only found in the RSN information element in association request frames and reassociation request frames that are sent from a client station to an AP.
• Below fig shows a protocol analyzer capture of a reassociation request frame ’ s RSN information element and PMKID information. Remember that the  PMKID is a unique identifi er of an  individual PMKSA;
• however, you will learn that a client station may have established  multiple PMKSAs. Therefore, the PMKID Count field specifi es the number of PMKIDs in the PMKID List field.
• The PMKID list contains 0 or more PMKIDs that the STA believes to be valid for a destination AP.

Fig. Pairwise master key identifier (PMKID)

components of a PMKSA include the following:

PMK  The pairwise master key that was created.

PMKID The unique identifi er of the security association.

Authenticator MAC The MAC address of the authenticator.

Lifetime If the key lifetime is not otherwise specifi ed, then the PMK lifetime is infi nite.

AKMP The authentication and key management protocol.

Authorization Parameters Any parameters specifi ed by the authentication server or local

confi guration. This can include parameters such as the STA ’ s authorized SSID.

The PMK is the key that seeds the 4 - Way Handshake, whereas the PMKSA is composed of all the components just listed, including the PMK. You will see that the most important components of the PMKSA are the PMK, the PMKID, and the authenticator ’ s MAC address.

The 802.11 - 2007 standard states that a client station can establish a new PMKSA during the roaming process with one of four different methods:

• Complete 802.1X/EAP
• PSK authentication
• PMK caching
• Preauthentication

the below fig depicts the creation of a new PMKSA during reassociation using 802.1X/EAP.

• PMK #1 is installed on the original AP and the client station. PMK #1 is then used to seed the 4 - Way Handshake that is used to create the final keys used for encryption.
• The client roams to the target AP and reauthenticates with the RADIUS server. The new EAP exchange creates PMK #2 which is installed on the target AP and the client station.
• PMK #2 is then used to seed the 4 - Way Handshake that is used to create the final keys used for encryption in the new BSS
• each time the client roams to a new target AP, the client station must reauthenticate with the RADIUS server. Although a new PMKSA is established, the time needed to reauthenticate with the RADIUS server is significant
• the 802.11 - 2007 standard defines two fast secure roaming mechanisms called preauthentication and PMK caching.

802.1X/EAP and PMKSA

PMK Caching

• PMK caching is a used method by APs and client stations to maintain PMKSAs for a period of time while a client station roams to a target AP and establishes a new PMKSA.
• An authenticator and a client station can cache multiple PMKs.
• As shown in below fig, a client station will associate with an original AP and create an original PMK #1. The client will roam to a target AP and create a new PMK #2; however, the original AP and the client station will both cache PMK #1.

• Whenever a client station roams back to the original AP, the client station will send a reassociation request frame that lists multiple PMKIDs in the RSNIE. In other words, the client will be informing the AP about all of the client ’ s cached PMKs.
• The 802.11 - 2007 standard states, “ An AP whose Authenticator has retained the PMK for one or more of the PMKIDs can skip the IEEE 802.1X authentication and proceed with the 4 - Way Handshake. ”
• when the client roams back to the original AP, both devices still have the original cached PMK #1 and they can skip the 802.1X/EAP exchange. The client does not need to reauthenticate and create a new PMK because the original PMK still exists. The cached original PMK is then used to seed the 4 - Way Handshake.
• the roaming handoff is usually below 100 ms, which is fast enough for VoWiFi.
• This is great if a client station roams back to an AP where it shares a PMKSA, but how does this speed things up when the client station roams to a new AP? The short answer is there will not be a cached PMK on the target AP unless preauthentication has occurred.

Preauthentication:

• A client station can use preauthentication to establish a new PMKSA with an AP prior to roaming to a new target AP. Preauthentication allows a client station to initiate a new 802.1X/EAP exchange with a RADIUS server while associated with the original AP.
• The purpose of the new 802.1X/EAP authentication is to create a new PMKSA relationship with a new target AP where the client might roam.
• The above fig shows, the client station sends an EAPOL - Start frame through the original AP over the distribution system (DS).
• An entire 802.1X/EAP exchange occurs between the client station and the RADIUS server; however, the authenticator is the new target AP. Once the client has preauthenticated.
• new PMK #2 is created and cached on both the client station and the target AP. If the client station decides to roam to the target AP, the client does not need to reauthenticate and create a new PMK because a precreated cached PMK already exists.
• The client station roams to the target AP, and the 4 - Way Handshake is all that is needed.
• How do client stations know if they can even learn about APs with which they can preauthenticate? an AP can indicate to the client station that the AP is capable of  preauthentication in the RSN information element found sent in the AP ’ s probe response or beacon frames.

It should be noted that preauthentication does not scale very well because it requires all Aps to create PMKSAs with all clients that might potentially roam to each AP. Every single client station would need to preauthenticate with every single AP in advance. Preauthentication would therefore place a tremendous load on the backend RADIUS server. PMK caching and  preauthentication are simply not very scalable solutions, and therefore the 802.11r task group was formed to define more scalable fast secure transition methods between basic service sets. However, most WLAN vendors did not want to wait for the ratification of the 802.11r - 208 amendment, so they implemented a preview of 802.1r mechanisms called opportunistic key caching.

Opportunistic Key Caching (OKC)

• OKC allows for PMK caching between multiple APs that are under some sort of administrative control. A WLAN controller environment that centrally manages controller - based APs is the perfect environment for opportunistic key caching.
• OKC allows a client station the opportunity to take advantage of a single cached PMK shared among multiple access points.
• To understand OKC, let ’ s first discuss the formula for a pairwise master key identifier (PMKID). The 802.11 - 2007 standard defines a PMK identifier as follows:  

     PMKID = HMAC - SHA1 - 128(PMK, “ PMK Name ” || AA || SPA)

The AA is the authenticator ’ s MAC address, and the SPA is the supplicant ’ s MAC address. This formula shows that a hash function combines the PMK with the access point and client station MAC addresses to create the PMKID.

• A WLAN controller can be used to forward an original PMK and PMKID to multiple access points. Remember that the APs are managed by the WLAN controller and the client traffic is tunneled from the APs to the centralized WLAN controller

1. The client station uses full 802.1X/EAP authentication and an original PMK #1 and PMKID #1 are created for use by the original AP and the client station. The original AP and the client station perform a 4 - Way Handshake.
2. Although, PMK #1 was initially created for the original AP, it is cached on the WLAN controller. The WLAN controller forwards PMK #1 to the target access point.
3. The client station calculates a new PMKID #2 using the original PMK #1 + the target AP MAC address + the client MAC. The client sends a reassociation request frame to the target AP with PMKID #2 in the RSN information element.
4. The target AP looks at the MAC address of the client station that just sent the reassociation request and calculates PMKID #2 using the same formula.

Opportunistic PMK caching

5. Because the PMKID #2 found in the reassociation request frame matches the PMKID #2 calculated by the target AP, reauthentication is not needed. The AP and the client station are still using the original PMK to seed to 4-Way Handshake, however, they are both in possession of the newly calculated PMKID #2, which will allow for a unique security association between the two devices. The AP sends a reassociation response frame and then the 4 - Way Handshake is then used to create the final encryption keys shared between the target AP and the client station.

• OKC effectively eliminates the need for client preauthentication, and therefore a more scalable solution is provided
• OKC only requires one initial 802.1X/EAP exchange between the client and the authentication  server. Therefore, OKC reduces the load that is placed on the RADIUS server. Because only a single 802.1X/EAP exchange occurs, only one original PMK is created.
• The WLAN controller is the authenticator in an 802.1X/EAP solution, and therefore the PMK is cached back on the WLAN controller. How the cached PMK is distributed between the WLAN controller and the controller - based APs is up to the WLAN vendor.
• OKC will fail if the target AP does not have a newly calculated PMKID that matches the client station ’ s newly calculated PMKID that is sent in a reassociation request frame. In that case, the client station would initiate an 802.1X/EAP exchange and the whole process would start over.

Proprietary FSR

• WLAN vendor Cisco Systems has long offered a proprietary version of fast-securing roaming called Cisco Centralized Key Management (CCKM).

• CCKM falls within Cisco ’ s licensed CCX program that other vendors may license. The current implementation of CCKM requires Cisco - compatible hardware and works with EAP - LEAP, EAP - FAST, PEAPv1 (EAP-GTC), PEAPv0 (EAP-MSCHAPv2), and EAP – TLS.
• CCKM uses a Cisco access point or controller to cache security credentials and effectively takes the place of the RADIUS server when the client stations authenticate. Like all FSR solutions, CCKM shortens the roaming handoff delay.

Fast BSS Transition (FT)

References:

CWSP: 802.11 Fast-secure-roaming