The original 802.11 standard supported two authentication methods: open system and shared key. The publication of the 802.11r amendment added a third authentication method called FT Authentication. Now that support for 802.11r is available for both clients and WLAN infrastructure, we will explore the protocol exchange used to perform Over the Air FT (FastTransition) authentication. This article assumes a familiarity with 802.11 protocols, knowledge of 802.1x authentication, the four-way handshake, Pairwise Master Key (PMK) and Pairwise Transient Key (PTK).
Every 802.11 station joining a BSS (Basic Service Set) must first perform 802.11 authentication (this is not to be confused with 802.1x/EAP authentication which takes place following the station’s association). The IEEE 802.11-2012 Standard defines four different authentication methods:
OpenSystem – No Authentication, everyone is allowed.
SharedKey – Authenticates stations using WEP to demonstrate knowledge of a configured WEP key.
FastTransition(FT) – Introduced to the 802.11 standard by the 802.11r amendment. Authentication relies upon a key derived from previous authentication. Used to facilitate fast BSS transition for roaming 802.1x stations.
Simultaneous authentication of equals (SAE) – Introduced to the 802.11 standard by the802.11s amendment. Uses finite field cryptography to prove knowledge of a shared password. Based on the Diffie-Hellman key exchange.
This blog focuses on FT authentication and how the FT authentication differs from other Fast Secure Roaming Protocols. The screenshots and decodes shown are taken from a WLAN test environment where the FT authentication process could be captured and analysed.
Setup
This procedure in our test environment was performed using an iPhone roaming between Extreme Networks AP 7532 access points (APs) connected to an RFS4000 WLAN controller. All packets were captured using Savvius OmniPeek. For readability, all trace files have been filtered to only show the following frame types:- Authentication, Association Request, Association Response, Re-association Request, Re-association Response and 802.1x/EAP frames, as shown below.
Pre 802.11r Fast Roaming
PMK Caching, Pre-Authentication and Opportunistic Key Caching (OKC) are all fast secure roaming methods adopted prior to the publication of the 802.11r amendment. Each of these methods removed the need for an 802.1x client to perform a full 802.1x\EAP authentication when they roam between BSSs. This is achieved by the client and wireless infrastructure caching the Pairwise Master Key (PMK) from a previous association. After performing a successful Authentication and Reassociation, the client may then use its cached PMK to perform the four-way handshake. This process can be seen in the figure below. The packets show a client’s initial full authentication to a BSS followed by the client’s roam and Reassociation to the second AP.
Notice that following the client’s Reassociation, it proceeds straight to the four-way key exchange.
FT
FT protocols are part of the Reassociation service and only apply to a station that transitions between APs. FT protocol messages can be exchanged by one of two methods:
1. Over the Air – Communicated directly with the target AP using FT authentication.
2. Over the DS – Communicated with the target AP via the current AP.
In this blog, we will explore the Over the Air protocol exchange, which utilises FT Authentication. When Over the Air Reassociation is used, a roaming station only needs to perform Authentication and Reassociation, as the functions of the four-way handshake are incorporated into the FT Authentication and Reassociation frames. The packets below show the initial association by the client (Open System Authentication, Association, 802.1x EAP authentication and the four-way handshake) following by two FT roams (FT Authentication and Reassociation).
Notice the lack of a four-way handshake. This process is now embedded into the Authentication and Reassociation frames. The figure below compares pre-802.11r fast roaming to FT Roaming
FT Key Hierarchy
Before we explore the FT Authentication and Reassociation packets in more detail, we need to understand a bit of background on the FT Key Hierarchy.
For this explanation, we will assume a controller–based WLAN architecture, where the controller is the 802.1x authenticator. This environment matches our test environment and is shown in the figure below.
A three-level key hierarchy is used to support fast BSS transition consisting of the following keys:
PMK-R0 – First level key – Key is derived as a function of the Master Session Key (MSK)
PMK-R1 – Second level key – Key is derived mutually by holders of PMK-R0
PTK – Third level key – This key defines protection keys and is derived mutually by holders of the PMK-R1
The MSK is derived simultaneously by the Supplicant and Authentication Server via the 802.1x authentication process. Following a station’s initial full 802.1x authentication to an ESS, the MSK is passed from the Authentication Server to the Authenticator encrypted in the RADIUS shared secret. These two processes result in both Supplicant and Authenticator holding the MSK. Both Supplicant and Authenticator can subsequently derive the PMK-R0 and the Authenticator becomes a PMK-R0 holder (in our example shown above this is the WLAN controller).
The authenticator will use the PMK-R0 to derive a PMK-R1 for the individual AP the supplicant is associated to. Subsequently, the authenticator can then derive and send individual PMK-R1 keys to APs to which the supplicant may subsequently roam. The supplicant derives a PMK-R1 for the BSS to which to it will (re)associate from a standardised function utilising its cached copy of PMK-R0 and the BSSID.
Following this process, the supplicant will perform a four-way handshake with the initial AP to form a security association and derive the PTK. When roaming to a new AP, only FT Authentication and Reassociation is required to form the security association and derive the PTK.
Packet 1: Authentication Frame
The first Authentication frame is sent by the client to the AP, see decode below:
Notice the Authentication Algorithm is set to 2 – indicating that this is an FT Authentication and not Open System Authentication. In the Authentication Management Suite list of the RSN Information element, we can see that the client has chosen FT authentication (OUI 00-0F-AC-03). Also, in the RSN Information element, we find the PMKID list – which holds a list of IDs for the PMKs that the client believes to be valid for the destination AP. In the Fast BSS Transition (FTE) element, we see the SNonce (Supplicant Nonce) being transmitted along with a PMK-R0 key holder ID. In a non-FT roam, the SNonce would have been transmitted in the second packet of the four-way handshake.
Packet 2: Authentication Frame
The next FT Authentication frame is from the AP to the client and is shown below:
In the second FT Authentication frame, the ANonce is included in the Fast BSS Transaction element. This would have been communicated in the first EAPoL Key packet of the four-way handshake. The Fast BSS Transaction element also includes the PMK-R1 key holder ID.
At this point, both the supplicant (Client) and Authenticator (WLAN infrastructure) have the information needed to generate a Pairwise Transient Key (PTK):
PTK = SNonce + ANonce + SMAC (Supplicant MAC Address) + AMAC (Authenticator MAC) + PMK-R1
Packet 3: Reassociation Request Frame
Now let’s look at the Fast BSS Transition element (FTE) in the Reassociation Request frame:
The ANonce, SNonce, R0KH-ID and R1KH-ID are set to the values contained in the last Authentication frame. In this frame, a Message Integrity Code (MIC) is calculated using the newly derived PTK. The PTK is actually a concatenation of a number of session keys. One of these session keys, the Key Confirmation Key (KCK), is used along with the AES-128-CMAC algorithm to calculate the MIC
Packet 4: Reassociation Response Frame
The last frame in the four-way FT exchange is the Association Response frame. The FTE from the Association response frame is shown below:
The ANonce, SNonce, R0KH-ID and R1KH-ID are set to the values contained in the Association Request frame. This frame also includes a MIC calculated in the same way as the MIC in the Association request frames.
You will notice some key info is also transmitted in the optional parameters of this frame. This is the Group Temporal Key (GTK), used to protect broadcast and multicast frames. This Key is encrypted in another PTK session key called the Key Encryption Key (KEK).
The result of this process is that the supplicant’s authentication has been verified through its possession of a valid PMK and a new PTK has been derived on the supplicant and authenticator. The client has also been provided with the current GTK for the BSS.