Roaming with WPA3-SAE – Part 1

How does roaming with WPA3-SAE (WPA3-Personal) work? We have the SAE exchange that is done at the beginning of our wireless session to compute the PMK. But do we need this extra exchange when roaming, or is there some kind of a “shortcut”? When starting this blog-post I thought that this will be quite easy to figure out. But actually, there were some really unexpected results!

This part 1 looks into the roaming process without any fast roaming mechanisms enabled in a centralised environment.

The Lab-setup

All these tests were done in a lab-environment which consists of the following devices:

• Cisco Catalyst 9800-CL running version 17.9.1 and two Cisco c2802 APs
• Apple iPhone 13 running iOS 16.1
• Apple iPhone 7 running iOS 13.4.1
• Xiaomi Mi11 Lite 5G with Android 12
• Samsung Galaxy Tab S7 with Android 12
• Microsoft Surface 8 Pro with Windows 11

The first packet capture was done using the Catalyst 9800-CL which was configured with only WPA3-SAE, central authentication and no OKC:

The WLAN-Config

The Policy Profile

The roaming client

The client in these tests moves through the following states:

1. First Association to AP1
2. Roam to AP2
3. Reassociation to AP2
4. Roam back to AP1
5. Reassociation to AP1

The first connection

As expected the first connection consist of:

• 4 packets authentication with SAE (Simultaneous Authentication of Equals)
• 2 packets association request and response
• 4 packets handshake

Compared to WPA2-Personal, we have two more packets (not counting the acknowledgments), ten packets instead of eight.

The first roam

I did my first test with an iPhone 13 running iOS 16.1. When looking at the capture I knew that I need some more tests with different devices as the iOS roam was completely not what I expected.

Android, Windows 11

With central authentication, these devices roamed exactly as I was hoping for.

The client and controller already calculated the per session PMK and there is no need to repeat this process. The client starts the roam with an open authentication, and in the Reassociation Request the PMKID is sent in the RSN Information element. After this exchange the 4-way handshake is done and with eight packets there is no difference to a WPA2-Personal roam.

iOS

With my iOS device, the first roam was not what I was hoping for, but it was not unexpected. There was a new SAE exchange, a Reassociation and the 4-way handshake. Same as with the first association, we have ten packets in total for this roam.

The roam-back

Android, Windows 11

For these devices nothing unexpected happened. With the quite efficient first roam, this roam back was exactly how it should work:

iOS

And here it starts to get ugly. The client and the Access-Point first go through an open authentication. In the reassociation request the client sends a PMKID that is not known to the AP which sends back a reassociation response stating an invalid PMKID. After this, a new SAE-authentication, reassociation and 4-way handshake is done.

Instead of eight packets in WPA2-Personal (and WPA3-SAE with a “working” roam) we now have 14 packets with WPA3-Personal. In my tests, these roams took between 120 and 140 ms which means the latency budget for a voice call would be nearly completely taken by the roaming process.

This behaviour was the same for the iPhone with iOS 16.1 and the iPhone with iOS 13.4.1. I still have no idea why this roaming is that bad and some more investigation is needed (perhaps in Part 3 of this blog).

In the next part we’ll look into the roaming with WPA3-SAE and Fast Transition.