Roaming with WPA3-SAE – Part 2

Part 1 of my “Roaming with WPA3-SAE” blog showed the roaming process in a centralized environment without any Fast Roaming mechanisms enabled.

In this second part I’ll look into the roaming process with “Fast BSS Transition (802.11r)” enabled in a centralized environment.

TLDR: From the moment the client and the controller derived the PMK-R0 from the SAE exchange, there is no difference to Fast Transition with 802.1X.

First we recapitulate what kind of keys are generated/used when FT is implemented in WPA2-Enterprise (802.1X) and which main elements are exchanged in the 4-Way Handshake.

The Keys in Fast BSS Transition

1. The client/supplicant authenticates through the Authenticator to the Authentication Server with the EAP. The Authenticator is the Controller, the Authentication Server is the RADIUS server. Both the Authentication Server and the Supplicant derive the Master Session Key (MSK) from the EAP process.
2. The Authentication Server sends the Master Session Key (MSK) to the Authenticator in the RADIUS Access-Accept message.
3. The Controller/Authenticator derives the PMK-R0 from the MSK and becomes the PMK-R0 Holder.
4. After the client derived the MSK, it derives the PMK-R0 from the MSK and also becomes the PMK-R0 Holder. In addition, the PMK-R1_AP1 is derived from the PMK-R0 and the client also becomes the PMK-R1 Holder for the session with AP1.
5. PMK-R1 for AP1 is derived from PMK-R0, AP1 becomes the PMK-R1_AP1 Holder.
6. Both AP1 and the Supplicant use PMK-R1 for the 4-Way Handshake
7. The PMK-R1_AP2 can be derived and AP2 becomes the PMK-R1_AP2 Holder.
8. When the client decides to roam to AP2, it derives PMK-R1_AP2 from PMK-R0 and uses this for the 4-Way Handshake with AP2.

With FT-SAE in WPA3, a similar key hierarchie is used. Only the PMK-R0 is not derived from a AAA-MSK, instead it is derived from the initial SAE handshake.

The Elements in the 4-Way Handshake

1. The Authenticator sends the ANonce
2. The Supplicant sends the SNonce and a MIC
3. The Authenticator sends a MIC and the encrypted GTK
4. The supplicant sends a MIC

The Lab setup

The components und roaming process in this Lab-setup is the same as in Part 1. Important to notice is that only FT-SAE was enabled, no transition mode:

The first connection

iOS/Android

The first connection is quite similar to the first connection without FT.

1. The Authentication with the SAE Handshake is done, this is the base for the PMK.
2. The Association Request includes the RSNIE wih an AKM value of 9, “FT using SAE (SHA256)”. In addition a PMKID and the Mobility Domain IE is included in the Association Request.
3. The Association Response also includes the Mobility Domain IE. The Fast BSS Transition IE includes the PMKR0- and PMKR1-KeyHolder IDs. The MIC, ANonce and SNonce in the MIC Control Field are set to “0”.
4. The 4-Way key exchange is done and the keys are installed.

Windows 11

Windows 11 showed a very strange behaviour. Not only it didn’t connect to the SSID, these are the exchanged packets that I really didn’t expect:

1. It started with an open Authentication.
2. Neither the Association Request nor the Association Response included an RSNIE.
3. The Client sends an EAPoL Start message
4. The AP answers with Key-Exchange Message 1

After this, it got even more confusing:

1. Another open Authentication is done.
2. But this time the client sends a Reassociation Request and receives a Reassociation Response. Both don’t include an RSNIE.
3. Again, the Client sends an EAPoL Start messages, the AP sends Key-Exchange 1 messages.

Yes, this needs some more investigation.

The first roam

iOS/Android

The first roam shows the effectiveness of Fast BSS Transitioning, same as FT with 802.1X. We’ll see two Authentication-frames and two Reassociation-frames. These four frames include the complete 4-Way Handshake:

1. The Client starts with a Fast BSS Transition Authentication. This frame also includes the first key exchange. But with the supplicant starting the process, not the ANonce is sent, the Fast BSS Transition IE includes the SNonce. In addition to that the PMKID and the PMK-R0 key holder ID is sent.
2. The AP sends a Fast BSS Transition Authentication. The Fast BSS Transition IE includes both the SNonce and the APs ANonce. A MIC is not yet included. But the AP includes the two key holder IDs for PMK-R0 and PMK-R1 in addition to the PMKID.
3. Now the Client sends its Reassociation Request. In this frame the client sends its MIC to the AP.
4. The AP sends its Reassociation Response which includes the encrypted GTK and the AP’s MIC

This roam took exactly 11ms with Android and 7ms with iOS.

Windows 11

Well, Windows 11 didn’t connect. With that, there is also no roam.

Any more Problems with FT-SAE?

Based on feedback on Twitter, iOS 16 still has a problem with roaming after being connected for some time: