A week ago I passed the CWSP-test. My knowledge is mostly from reading study guides, configuration guides, blogs and go through some online practice test. But I admit that the best way to remember the theory is to see whats actually happens with a packet capture. My last blog was on how to do packet capture and using display-filter in Wireshark.

Now its time to have a look a Fast Secure Roaming (FSR) in a network with 802.1X/EAP-authentication
When I was writing this blog I leared a LOT, so some chapters has been rewritten more than once.
Its very briefly, mostly like a “note to self” (wifi-joke). And OK to share
The goal is to see what happens during roaming, not how fast each roaming method are.

My network looks like this

Test methodology
My methodology was to have two APs, each connected to SW2 with 15m cat6-cabel. One AP (called original AP) at my office floor and the other AP (called target AP) outside in the hallway behind an elevator shaft. The APs was tuned to lowest possible Tx-power and static channel setting (channel 52 & 56).
I use Airtool on a MacPro to capture the wireless packets.

1. Start Airtool on the channel corresponding the AP at my office
2. Associate the test clients to the test-SSID. The APs lamp should turn to blue
3. Stop Airtool. The capture files saves at the desktop
4. Start Airtool on the channel corresponding to the AP out in the hallway
5. Switch places for the two APs and wait until the target AP lamp lights blue (client associate)
6. Stop Airtool
7. Merge the two files together in Wireshark
8. Remarks
   1. If I a want a capture for wired traffic between AP and WLC, or towards Radius-server, it´s possible to use SPAN-function on SW1
   2. Since I have to have two separate captures from Airtool some packets will be lost. I also use a Windows client with ComView for Wifi and a D-Link DWA-182 c2 USB-adapter on the original APs channel so I could see the frame at that channel continously
   3. You should mark each AP with which channel number  it´s on, otherwise you have to use application like WiFi Explorer for MAC, InSSIDer for Windows or WiFi Analyzer for Android to find out which channel is where
   4. If you test with both client in the same capture it´s advantageous to check connection status at the WLC (Monitor/Clients) to make sure both clients are associated/reassociated before you stop Airtool-capture

 

Whats the secret ingredient in Fast Secure Roaming (FSR)
The 802.11-standard defines a robust security network (RSN) and robust security network association (RSNA). A RSNA requires two 802.11-stations to establish procedures to authenticate and associate with each other as well to create dynamic encryption keys, the 4-way handshake. The 802.11-standard defines several RSNAs. The one that are interested is this article is the Pairwise Master Key Security Association (PMKSA). This PMKSA is the result after a successful 802.1X/EAP authentication exchange between the client (supplicant) and the authentication server. When the PMKSA is established the Pairwise Master Key (PMK), which is the seeding material for the 4-way handshake, is created on both client (supplicant) and authentication server (AS)

A unique identifier is created for each PMKSA, the pairwise master key identifier (PMKID). The PMKID is found in association request frame and reassociation request frames, and in FT action frames. A client can have established multiple PMKSAs, so a PMKID Count field specifies the number of PMKIDs. These two field are inside the RSN informations element

The PMKID is a hash function that combines the PMK, the clients MAC-address and the APs MAC-address (BSSID)

When Cisco wireless controllers (WLC) are configured to use 802.1X/EAP-authentication it will use a fast secure roaming mechanism called Opportunistic Key Caching (OKC). What happens during roaming when OKC is used

(very short from Sybex CWSP Study Guide)

1. Client associate and full 802.1X/EAP authentication. PMKSA#1 and PMKID#1 are created on client and original AP
2. The original AP caches PMK#1 and forwards PMK#1 to target AP
3. The client calculates a new PMKID#2 using original PMK#1, own MAC-address and target AP MAC-address. The client sends reassociation request to target AP with PMKID#2 in RSN information element
4.  The target AP calculate its own PMKID#2 based on PMK#1 and the MAC-addresses. If those two PMKIDs matches, the target AP sends a reassociation response frame back  to the client
5. Because the two PMKID#2 matches, both target AP and client have the same PMK (established in point 1), and reauthentication (802.1X/EAP) is not needed. This PMK, together with MAC-addresses and nonce, create new dynamic crypto keys (the 4-way handshake)

 

Testing
I tested two client devices towards different configuration of WLAN. The client devices is:

• Samsung A5 cellphone (Android). It has support for Opportunistic Key Caching (OKC), but not 802.11r (Fast BSS transition, FT)
• iPAD2 (iOS 11.2.5). Not support for OKC and have support for  802.11r

Next I will comments shortly each setup

Wlan with 802.1X/EAP, WPA2/AES and AP in local mode
The WLC will use OKC as it´s key caching method

• Samsung A5
  • Samsung A5 supports OKC
  • Open authentication/association to original AP, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming, the client sends PKMID in its reassociation request to target AP
  • Authenticator (target AP or WLC) calculate its own PMKID, those two matches and the original PMK will be used to seed 4-way handshake
  • Target AP send reassociation response to client
    • Whether the PMK already are at the AP or just on the WLC haven´t I found any unambiguously information about. It´s vendor proprietary
    • Cli-command debug client <Mac-adress> on controller give a lot of information
  • Since PMK is available 802.1X/EAP is not needed and from reassociation response directly to 4-way handshake.

• iPAD
  • iPAD don´t support OKC
  • Associate to original AP with open authentication/association, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming, the iPad dosn´t send PKMID in its reassociation request because the iPAD don´t support OKC
  • Full 802.1X/EAP reauthentication and 4-way handshake on target AP.
  • This is not fast roaming

This capture shows a standard 802.1X/EAP-authentication. Open authentication request/response, association request/response, EAP-authentication and the 4-way handshake

And here we have roaming with OKC. Open authentication request/response, reassociation request with PMKID in RSN information element (see packet detail), reassociation response and the 4-way handshake

Wlan with 802.11r (Fast BSS Transition FT) over the air enabled. AP in local mode
The WLC will use only 802.11r (Fast BSS Transition, FT)  because FT is set to enabled, not adaptive 

Is this mode the beacons and probe response frames will carry the AKM-suite = 3, inside RSN information element, and a Mobility Domain information element (MDIE). AKM-suite 3 is FT over IEEE802.1X. Client that don´t support FT will not understand this and will not associate to the AP/BSS

• Samsung A5
  • Samsung A5 dosn´t support FT, so it should not associate to network
  • Even that these client don´t support FT it will regularly send probe request frames with open SSID, so the SSID with FT will answer with its probe response
  • This probe response carry AKM-suite 3 (FT over IEEE802.1X) in RSN information element and Mobility Domain information element
  • Since client don´t support FT nothing more happens. No authentication/ association

• iPAD
  • iPAD support FT
  • Associate to original AP with open authentication request/response and FT association request/response, full 802.1X/EAP-autentication and 4-way handshake
  • The difference between open authentication/association response/request and FT authentication/association response/request is that FT-frames also carry  AKM-suite 3, mobility domain information element and Fast BSS Transition information element (FTIE)
  • During roaming four frame is enough to both reassociate and create dynamic keys; the FT authentication request, FT authentication response, the FT reassociation request  and FT reassociation response. Those frames carry all necessary information, especially inside Fast BSS Transition (FTIE) information element (nonce, key holder id (RxKH-ID),  to create dynamic keys
  • Since dynamic keys are created during these four frame 4-way handshake in not needed

Here is first the managements frames during initial association. Packet detail from association response with both Mobility Domain IE and Fast BSS Transition IE. EAP and 4-way handshake frames are left out

And the from the reassociation to target AP. FT-authentication and FT-reassociations frames, all containing Mobility Domain IE and Fast BSS Transition IE. No 4-way handshake

Wlan with 802.11r (FT over the air) enabled with adaptive 802.11r. AP in local mode
Because some client dosn´t support 802.11r,fast BSS transition (FT), Cisco has developed a method where client that support FT and client that dosn´t can associate to the same Wlan/SSID. It´s called adaptive 802.11r. This is supported with WLC running AireOS 8.3 or higher.
Client supporting FT will use FT during roaming, while client not supporting FT will use OKC during roaming

So how is it possible for clients thats support FT and client that don´t support FT to associate to the same WLAN/SSID?
With adaptive FT configured at WLAN beacons and probe response frames from the AP will carry AKM-suite WPA in the RSN information element. Thats equal to 802.1X with OKC (opportunistic key caching) in our network. This gives the non-FT client opportunity to associate with OKC
But those beacons and probe response frames also carry Mobility Domain information element. The presence of mobility domain information element tells FT-capable clients thats they could use 802.11r/FT when they associate/roam

Here is some packet detail from a probe response with adaptive 802.11r/FT enabled. In RSN information element AKM-suite is WPA and the presence of Mobility Domain IE

• Samsung A5
  • Samsung A5 dosn´t support 802.11r, so it uses OKC.
  • Same method as Wlan with 802.1X/EAP, WPA2/AES and AP in local mode
    • Open authentication/association to original AP, full 802.1X/EAP-autentication and 4-way handshake
    • During roaming, the client sends PKMID in its reassociation request to target AP
    • Authenticator (target AP or WLC) calculate its own PMKID, those two matches and the original PMK will be used to seed 4-way handshake
    • Target AP sends reassociation response to client
    • Since PMK is available 802.1X/EAP is not needed and from reassociation response directly to 4-way handshake.
• iPAD
  • IPAD supports 802.11r
  • Same method as Wlan with 802.11r (Fast BSS Transition FT) over the air enabled. AP in local mode
    • Associate to original AP with open authentication request/response and FT association request/response, full 802.1X/EAP-autentication and 4-way handshake
    • During roaming four frame is enough to both reassociate and create dynamic keys. The FT authentication request/, FT authentication response, the FT reassociation request  and FT reassociation response. Those frames carry all necessary information, especially inside Fast BSS Transition (FTIE) information element (nonce, key holder id (RxKH-ID),  to create dynamic keys
    • Since dynamic keys are created during these four frame 4-way handshake in not needed

 

Accesspoint in flex connect, 802.11r adaptive mode
If we use the access point in flexconnect mode it´s important to also configure flexconnectgroups. I have only tested with 802.11r adaptive mode, so that both clients can associate to the same wlan and successfully connect

Without putting AP in flexconnectgroup

• Samsung A5
  • Samsung A5 dosn´t support 802.11r, so it uses OKC.
  • Same method as Wlan with 802.1X/EAP, WPA2/AES and AP in local mode
    • Open authentication/association to original AP, full 802.1X/EAP-autentication and 4-way handshake
    • During roaming, the client sends PKMID in its reassociation request
    • Authenticator calculate its own PMKID, those two matches and the original
    • Since PMK is available 802.1X/EAP is not needed and from reassociation response directly to 4-way handshake.

• iPAD
  • Fast Secure Roaming (802.11r) is not supported in flex connect mode without flexconnectgroups
  • Associate to original AP with open authentication/association, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming, the iPad dosn´t send PKMID in its reassociation request because the iPAD don´t support OKC
  • Full 802.1X/EAP reauthentication and 4-way handshake on target AP.

Putting AP in flexconnectgroup

• Samsung A5
  • Samsung A5 dosn´t support 802.11r, so it uses OKC.
  • Open authentication/association to original AP, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming, the client sends PKMID in its reassociation request
  • Authenticator calculate its own PMKID, those two matches and the original
  • Since PMK is available 802.1X/EAP is not needed and from reassociation response directly to 4-way handshake.

• iPAD
  • Fast Secure Roaming(802.11r)  is supported at access point in  flex connect mode with flexconnectgroups
  • IPAD supports 802.11r
  • Associate to original AP with open authentication and FT association, full 802.1X/EAP-autentication and 4-way handshake
  • During roaming four frame is enough to both associate and create dynamic keys.The FT authentication both ways, the FT reassociation request  and FT reassociation response. Those frames carry all necessary information inside especially Fast BSS Transition (FTIE) information element to create dynamic keys (nonce, key holder id (RxKH-ID)
  • Since dynamic keys are created during these four frame 4-way handshake in not needed

 

Wiresharkfilters
I have used Wireshark as my protocol analyzer and have captured both wireless frames with Airtool and wired frames using SPAN-functions
Handy Wiresharkfilter are this one

• wlan.addr == <MAC-address to client>
• (wlan.fc.type == 0) &&! (wlan.fc.type_subtype == 8) ; all management frames except beacons
• eth.type == 0x0800. ; use it to filter out ethernet-frames (wired frames)
• wlan.tag.number == 55.   Find all frames containing Fast BSS Transition IE
• wlan.rsn.akms.type == 3.  Find all frames containing AKM-suite 3 (FT)

 

Summary
This is a summary on how my client behaved under different FSR-mechanisms

	802.1X/EAP	802.11r	802.11r adaptive	802.11r adaptive	802.11r adaptive
AP mode	Local mode	Local mode	Local mode	Flexconnect without flexconnect-groups	Flexconnect with flexconnect-groups
Samsung A5	OKC	not associate	OKC	OKC	OKC
iPAD	no fast roaming	FT	FT	no fast roaming	FT

Depending on how you configure your network clients behave differently. So its important to know your clients and as a wise man tells “Understand the protocols you work with” (Brian Long)

 

References

• Sybex CWSP Study guide
• Cisco Optimized WiFi Connectivity and Prioritized Business Apps
• Other Cisco configuration guides

Related Posts

Rasika Nayanajith (mrncciew.com) have several blogpost on the same themes