Fast BSS Transition (FT) is defined in the amendment 802.11r and is since 802.11-2012 a standard. 802.11r, together with 802.11k and 802.11v, are the three amendments that must make roaming better and more efficient. The difference between OKC and FT is that FT has a new key hierarchy, which will be discussed later in this blog. FT uses the benefit of mobility domains. Mobility domains are a group of BSS within the same ESS that supports FT, or this can also be multiple WLAN controllers. As with all the other key caching methods, the first time, the 802.1X/EAP exchange needs to be executed. This is the only time that this exchange finds place, and this is comparable to OKC. From this point on FT uses two methods for distributing the key, over-the-air or over-the-DS. Those two methods will be explained later. First we will dive into FT and the new key hierarchy.
Pairwise Master Key R0 (PMK-R0) is the first level key from the FT hierarchy and is derived from the MSK (master session key). The PMK-R0 is cached on the WLAN controller (or access point in a controller-less environment).
Pairwise Master Key R1 (PMK-R1) is the second level key. This key is derived from PMK-R0 and installed on the access point.
Pairwise Transient Key (PTK) is the third level key and used for the encryption/decryption. The PTK is derived from PMK-R1.
As mentioned, PMK-R0 is installed on the WLAN Controller or current access point, called R0 Key Holders (R0KH). PMK-R1 is installed on the access point and this is called the R1 Key Holder (R1KH). The clients are key holders for the PMK-S0 and PMK-S1 (S0KH and S1KH).
The key hierarchy without FT is MSK generated from 802.1X/EAP exchange, PMK derived from the MSK, and then the 4-way handshake that creates the PTK. Now, with FT the key hierarchy is a little bit different. 802.1X/EAP creates the MSK, the PMK-R0 is derived from the MSK, and the PMK-R0 is cached on the WLAN controller. After that the PMK-R1 is derived from PMK-R0 and sent to the access points and the access point caches the PMK-R1. The last step is that the PTK is derived from the PMK-R1. Those keys are also installed on the client.
In an environment with no controller, the PMK-R0 is derived from the MSK and installed on the current access point. The PMK-R1 is derived from PMK-R0 and distributed through a secure channel to the other access points.
With FT, the RSNIE is also changed. There are new fields that help with the roaming.
Mobility domain information element (MDIE) is for indicating the existence of the mobility domain and which method is used.
Mobility domain identifier (MDID) is a unique id of the mobility domain.\r\nFT capability and policy is the field that shows which method is used—over-the-air or over-the-DS.
Fast BSS transition information element (FTIE) holds the information that is needed for the FT authentication sequence and is similar to the information that is used with the 4-way handshake.
FT initial mobility domain association is the first time that a client enters the mobility domain. The open system authentication finds place and after that the 802.1X/EAP exchange happens, which is used to generate the MSK. In the authentication request/response the MDIE and the FTIE are included for knowing the method that is used. After that a special 4-way handshake finds place (FT 4-way handshake). This handshake is mostly the same, but have some FT information included.
M1: ANonce
M2: SNonce, MIC, RSNIE (with PMK-R1), MDIE, FTIE
M3: ANonce, MIC, Encrypted GTK, RSNIE (with PMK-R1), MDIE, FTIE
M4: MIC
As you can see, in the M2 and M3 there are some extra fields with the PMK-R1 name, MDIE, and FTIE.
Over-the-Air FT
With OKC you had the open system authentication and the 4-way handshake and it skipped the 802.1X/EAP exchange. With FT, when the client triggers a roaming, the process is as follows. The 4-way handshake is included in the open system authentication, so even 4 frames less than with OKC. The process, without the 4-way handshake takes less than 50ms.
FTAA stands for FT authentication algorithm.
Authentication request (FTAA, RSNIE [PMK-R0], MDIE, FTIE [SNonce, R0KH-ID])\r\nAuthentication response (FTAA, RSNIE [PMK-R0], MDIE, FTIE [ANonce, SNonce, R1KH-ID, R0KH-ID])
Reassociation request (RSNIE [PMK-R1], MDIE, FTIE [ANonce, SNonce, R1KH-ID, R0KH-ID])
Reassociation response (RSNIE [PMK-R1], MDIE, FTIE [ANonce, SNonce, R1KH-ID, R0KH-ID], GTK)
This process is called over-the-air because the client communicates directly with the new access point, through the air.
Over-the-DS FT
This process is over the DS, this requires FT action frames that complete the information through the DS, for example 802.3. The client communicates with the current access point and the current access point forward the traffic through the DS to the new access point. Those frames are called FT action request and FT action response. The Reassociation request and reassociation response are over the air from the new access point to the client.
Over the DS, through current access point.
FT action request (STA, New AP, RSNIE [PMK-R0], MDIE, FTIE [SNonce, R0KH-ID])
FT action response (STA, New AP, RSNIE [PMK-R0], MDIE, FTIE [ANonce, SNonce, R1KH-ID, R0KH-ID])
Over the air, from new access point to client.
Reassociation request (RSNIE [PMK-R1], MDIE, FTIE [ANonce, SNonce, R1KH-ID, R0KH-ID])
Reassociation response (RSNIE [PMK-R1], MDIE, FTIE [ANonce, SNonce, R1KH-ID, R0KH-ID], GTK)
In this blog, we mostly talked about FT in combination with 802.1X/EAP, but you can implement FT also in a PSK or SAE (with SHA-256) environment.
