During WLPC_EU in Prague 2022 I attended Peter Mackenzie’s deep-dive “AP Packet Capture”.
During that, I discovered a strange association behavior for my Samsung S10 cell phone to a Mist AP.
Peter and I considered if it could be some kind of FILS authentication, but later testing rejects this.

BTW: this was one of my CWNE essays, the pdf is attached

Setup
WLAN on Mist AP is configured with WPA2-Enterprise (802.1X/EAP) authentication and Fast Roaming is set to Default (no roaming). And a configured Radius Authentication Server (JumpCloud).

Default behavior during association and re-association for WiFi clients on a WPA2-Enterprise WLAN without fast roaming features is to do a full 802.1X/EAP authentication each time it associate and roams (reassociate).
During testing with different types of clients, these always do full 802.1X/EAP authentication, both during association and re-association (roaming). I have tested several types of clients.

But one does it otherwise, Samsung S10 with Android version 12.

Testing
I replicated the network at work and did several types of operations on a network with two APs, called AP1 and AP2s. The frames are captured and shown with Wireshark, and the use of name in the source and destination columns. The client is called Samsung_S10.
There are mainly two types of behavior, one without hiccups and one with hiccups.


Result 1, Seamless associations without hiccups

Picture 1. Visualization for steps 1 to 4.

Picture 2. Packet capture for steps 1 to 4.

Explanation

• Step 1
  • Client associates to AP1 while it announces an earlier used PMKID (not seen in the capture), but AP1 don’t know the PMKID.
  • Full 802.1X/EAP-authentication is done, ending with the success frame 39.
  • 4-way handshake.
    • Since AP1 knows the newly derived PMK from this EAP-process, authenticator MAC, and supplicant MAC it makes a new PMKID, shown in message 1, frame 40.
    • The client responds with the previous and invalid PMKID from the not shown association frame in message 2, in the RSNIE element. This is a security feature according to the 802.11-2020 standard. The new PMKID for this association is the one in message 1.
• Step 2
  •  Client roams/reassociates to AP2. It announces a PMKID from an earlier association to AP2 (not shown). AP2 has this PMKID cached and it goes directly to 4-way handshake.
    In this case. the PMKID is equal in both the reassociation request, message 1, and 2 frames.
• Step 3
  • Client roams back to AP1. It announces the PMKID from the previous association to AP1, step 1. AP1 has this PMKID cashed and it goes directly to the 4-way handshake.
  • In this case, the PMKID is equal in both the reassociation request, message 1, and 2 frames.
• Step 4.
  • Client has been disassociated from the network for a period of time. It could be a short time or a day or two
  • Since the client associates (not re-associates) to the same AP (AP1) as it left, the PMKID is known by the client and AP1, and no 802.1X/EAP.
  • This happens when the client has been away for some seconds or a day. Also if the client has been associated to other network or been turned off in between
• Remarks
  • Step 2 and 3, where the 802.1A/EAP process is skipped, is what we know as PMK CachingStep 4, where the client associate (not re-associate) to the same AP as it left and skipped the 802.1X/EAP, is also PMK caching process.We are trained to believe PMK caching is only used during re-association or fast roam backBut according to 802.11-2020 standards, 12.6.10.3, “Cached PMKSAs and RSNA key management” this method can also be used during association for the lifetime of a PMKSA.
  • From my limited testing, it is only the Samsung S10 that uses this feature. It is the same behavior on a Cisco WLAN with the same setup.
    
    

Result 2, Seamless associations with hickups.
Under one condition there is an odd authentication behavior.

Picture 3. Visualization for steps 4 to 5.

Picture 4. Packet capture for steps 4 to 5.

Explanation

• Back at step 4.
  • The client has been disassociated and its NIC has been turned off. But since it associates to the same AP as it left, AP1 and both stations (client and AP1) have the cached PMKID it goes directly to the 4-way handshake
• Step 5
  • This is the odd situation. Normally we would have expected the client sends the PMKID from the previous association to this AP2, step 2. But it sends an unknown PMKID never used before. AP2 doesn’t know this PMKID and initiates a full 802.1X/EAP authentication.
    To shorten the picture the EAP-process is hidden (frame 76-99).
  • This happens also if the client disassociates at AP1 and associates later to AP2 and the client’s NIC has been turned off.

Conclusion
During testing on a WPA2-Enterprise (802.1X/EAP) WLAN with default setup on Mist APs, roaming not enabled, the Samsung S10 has another association behavior than all the other tested clients.
Most clients do full 802.1X/EAP-authentication during association and roaming (reassociation) between APs, while the Samsung S10 very often skips the 802.1X/EAP-authentication and goes directly to the 4-way handshake.

The re-association behavior is what we know as PMK Caching.
The association behavior is also PMK Caching and can be used in the lifetime of the PMKSA (PMK Security Association).

So it seems there are very few clients on the marked that supports PMK Caching, fewer than many would expect.

The odd behavior in step 5 seems to be a small bug in the Samsung operating system.

What is the benefit of PMK Caching during association and re-association
The main benefit of PMK Caching is to avoid the 801.1X/EAP process where the client talks to a Radius server. During my testing this takes 800ms.
Avoiding this, especially in crowded areas, would improve the performance of WiFi networks
FILS Authentication is a method to improve this behavior, but it is very seldom implemented

Attachment
The CWNE essay PDF-format