Ever wondered how much time does an entire EAP-TLS protocol exchange take? How efficient is 802.11r in minimizing packet loss during roaming process? You might have already known 802.11r FT over-the-air takes only four frame exchanges between the client and the AP to complete roaming process. But how long does this process take? This post will answer these questions. 802.1X and 802.11r are complex enough to have deep dive blog posts. So, I will discuss only some basics to give context to this time analysis.
EAP-TLS is considered one of the most secure frameworks for authentication. The high security comes from the requirement of using client-side certificates and maintaining Public Key Infrastructure (PKI) which contains the certificates. An overview of frame exchanges are shown in the picture below
Once the client device (supplicant) goes through the open system authentication and association process, it initiates EAPOL start message. The use of EAPOL start message is optional. The access point (authenticator) sends an EAP Request message asking for the identity of supplicant. The supplicant can send a response with real or a dummy identity depending on the configuration. Authenticator will then initialize an Access Request to the Authentication Server with the identity provided by the supplicant. The authentication server presents the server certificate which the supplicant validates before presenting client certificate to the server. The supplicant may or may not choose to validate the server certificate but validation will provide mutual authentication thereby providing better security. After the supplicant provides its certificate, server validates it and sends an access accept or reject message depending on the authenticity of the client certificate. It must be noted that this is only an overview of the process when in reality there are numerous other handshake messages between supplicant and authentication server before the final access accept/reject message. The end result of a successful EAP-TLS exchange is a Master Session Key (MSK) which is used to generate Pairwise Master Key (PMK) which is in turn used to generate sessions keys through the four way handshake for encrypting packets between client and access point.
Fast BSS Transition (FT) uses the concept of key hierarchy to generate multiple keys that will help in efficient roaming. It uses a three level key hierarchy. The MSK from 802.1X EAP process is used to generate first level PMK which is called PMK-R0. PMK-R0 is used to generate second level keys PMK-R1 which generates Pairwise Transient Key (PTK) which is used for encryption between client and access point. Depending on the WLAN architecture, these keys are stored by different devices. I used Mist Systems infrastructure in this case. Mist architecture does not contain a centralized controller. So the PMK-R0 derived from MSK is stored in the access point the device initially connects to. PMK-R1 keys are generated for each access point in the network and transmitted over a secure channel. The following picture shows a summary of where keys are stored.
In summary for first connection, client device needs to go through open system authentication, association, 802.1X EAP process and 4-Way handshake before being able to successfully send its first data packet. The process is shown below
The device is authenticated during the first connection and so when roaming it should not have to go through the entire 802.1X process again to prove its identity. However, it would still have to go through open system authentication (2 frames), re-association (2 frames) and 4-way handshake (4 frames) procedures to be able to communicate on the new access point. That would be eight frames not including ACKs between the new AP and client device. FT defines two methods to enable enhanced roaming: Over-the-air Fast BSS Transition and Over-the-DS Fast BSS Transition
Mist infrastructure employs over-the-air mechanism by default. With this method, FT effectively combines the 4-way handshake functionality with open system authentication and re-association frames thereby reducing the number of frames by half. The roaming process is shown below:
For this study, I chose an android mobile device that authenticates and authorizes using the EAP-TLS framework. The authentication server is an ISE instance with an average of 25 milli seconds latency to the AP. To collect data for analysis, I performed seven iterations of roaming tests. Each iteration had one initial connection instance when the device goes through Authentication, Association, 802.1X EAP and 4-way handshake and at least one roaming instance when the device goes through authentication and re-association. The graph presented below shows the overall time from beginning of authentication to the end of 4-way handshake. Most iterations took less than one second to complete the connection process. However, there is an outlier which took 1.714 seconds for the process to complete. Accounting the outlier to WAN fluctuations and excluding it from calculations gives the average time to complete the initial connection process as 905.8405 milli seconds.
I was also interested in looking at how long only the 802.1X process took. The following shows the time taken from the first EAP-Request frame to ACK frame of EAP-Success. Excluding the outlier, the average time for 802.1X EAP process is 878.84313 milli seconds.
I was able to produce 14 roaming instances in the seven iterations. I considered the time between first authentication frame to the ACK of Re-association response as the time required for handoff between the APs. The average of all instances is 190.512 milli seconds which is about 21% of the total time taken for first connection.
A lot of factors including the delay between access point and authentication server, number of clients connected to access points, retransmissions, coverage overlap etc will impact these numbers. Every application is designed differently to handle traffic. Some of them might have higher timeout values while others could be very time sensitive. The goal of this study was to have an idea of time for initial connection and roaming handoffs and to be able to use this data to help determine application resiliency to these events. I hope this helps for other engineers in the community as well!
- CWSP Study Guide by David A Coleman, David A. Westcott and Bryan Harkins