Tags
In this post we will see how 802.11r Over-the-Air Fast BSS Transition works. We will use same topology & base configuration used for the previous post.
First I have to disable “Over-the-DS” feature on the WLAN to force FT transition “Over-the-Air” as shown below.
wlan MRN-EAP 22 MRN-EAP
client vlan 22
security wpa akm ft dot1x
security dot1x authentication-list MRN-DOT1X
security ft
no security ft over-the-ds
no shutdown
When the client associate to LAP1, it will go through FT initial mobility domain association process (described in 802.11r FT association post). Here is the snapshot of that frame capture.In “Over-the-Air Fast BSS Transition” client will communicate with Target AP (LAP2 in my case) over the air. So you can capture these frame exchange if you sniff CH40 as LAP2 is set to that channel. So here is my capture looks like. As you can see in the time stamp (from frame 88 to frame 95) roaming complete within 14ms.
As you can see in the above, you can see only 4 frames like in Open System Authentication & even not includes any 4-Way Handshake messages 😯 . These are 4 frames exchange when this roam occurs,
1. Authentication Request
2. Authentication Response
3. Re-association Request
4. Re-association Response
Without 4-Way Handshake messages how client & AP derive PTK to encrypt traffic ? If you look at the detail of the above frames you will find the answer. In Over-the-Air Fast BSS Transition, these 4 frames include 4-Way Handshake information. This will effectively combines the initial Open System Authentication & Re-association frames with 4-Way Handshake frames. (so 4 less frames required to complete a roam).
Now let’s go into detail of each of these frames. First we will look at the “Beacon frame” to see “Over-the-Air” FT support advertising. As you can see below in RSN-IE its advertising 802.1X & FT over 802.1X capability & in MDIE “Over-the-DS” bit set to “0” indicating it is supporting “Over-the-Air” Fast BSS Transition.So let’s go to “Authentication Request” frame detail initiated by the client (iPhone5 in this case). As you can see, this frame contain RSNIE, MDIE, FTIE information elements. RSNIE includes PMKID count & PMKID list. FTIE includes SNonce, R0KH-ID.
Then target AP(LAP2) sends the “Authentication Response” frame to client. This frame also contain RSNIE, MDIE & FTIE. In FTIE includes ANonce, SNonce,R1KH-ID & R0KH-ID.
Then client sends the “Re-association Request” frame. This also contain RSNIE,MDIE & FTIE. FTIE includes MIC,Anonce, SNonce, R1KH-ID, R0KH-ID.
Finally AP sends “Re-association Response” frame. This frame contain RSNIE, MDIE,FTIE & GTK information.
Below diagram (page 270 of CWSP Official Study Guide) show the frame exchange of “Over-thee-air fast BSS transition” which described above.In the next post how “Over-the-DS fast BSS Transition” works.
References
1. Over-the-Air-FT (frame capture used for this post)
2. CWSP Official Study Guide – Chapter 7
3. 802.11r, 802.11k, and 802.11w Deployment Guide, Cisco IOS-XE Release3.3
Related Posts
1. CWSP-802.11 Roaming Basics
2. CWSP-802.11r Key Hierarchy
3. CWSP-802.11r FT Association
4. CWSP-802.11r Over-the-DS-FT
5. CWSP-4 Way Handshake
6. CWSP- RSN IE
Pingback: CWNA CWSP CWAP Study Resources | daleswifisec
Rasika, I really like your blog. However, I have to admit this series about FT provides very limited information and is in fact no better than CWNP white paper, which is also a little bit unclear. What I don’t really understand is how keying material is derived.
For example, if we don’t have FT – everything is clear. We have MSK, which becomes PMK, then PRF creates PTK using ANounce, SNounce, AA, SPA and PMK. Supplicant has everything required after Message 1 of 4Way Handshake. Authenticator has everything to derive PTK after Message 2. Authenticator shares KEK-encrypted GTK with Supplicant. Messages 2 through 4 are using MIC for Integrity protection (KCK). Clear!
However, when it comes to FT, my world has changed forever… I don’t really understand what is happening here. Few example questions
1) After successful dot1x authentication. Both WLC and STA have derived MSK, which is now PMK-R0 (is it?), STA derives PMK-R1, WLC derives unique PMK-R1s and distribute across all Lightweight APs (of the same FlexConnect Group I believe). Now… What is this PMK-R1 on a client/STA side? I have many PMKs for all APs, which one is on STA? Is it the one for the current AP? How does it derive it? What variables influence PMK-R1 creation?
2) What is PMKR1Name – is it the same as PMKID in previous terminology? Is it shared via RSN IE PMKID List (but different interpretation now)? It does make sense to me, but I am not sure… I expect it is also derived in a similar to OKC manner – i.e. hash on STA MAC, AP MAC, PMK-R0Name (i.e. Global PMKID)… again – can’t find these details anywhere.
3) When client roams… it sends SNonce, PMK-R0Name and R1KH-ID. It then receives ANonce, PMK-R1Name (is it for the new AP?), R1KH-ID and R0KH-ID. So, it has everything to construct the PTKSA (while AP has everything Authentication Request). How is this PTK constructed out of information provided above, i.e. PMK-R0Name, PMK-R1Name, R0KH-ID, R1KH-ID and both Nonces. Why do I need R0KH-ID for example, is it to create PMKID for new association (like with OKC)?
It was so much simpler with OKC and 4Way Handshake.
Do I really have to read through IEEE 802.11r to get the details or do you know any other articles with good examples that explain the logic behind FT AKM?
Even CCKM was simple
Appreciate it
Tim
Writing helps….
PMK-R0 and PMK-R1 – are clear
R0KH and R1KH – are clear
PTK is clear
Now, after writing my previous comment… I think FT is very close to OKC.
Basically, when client roams, it sends SNonce, PMKR0Name and R0KH-ID to identify the mobility domain to which it belongs. AP, derives ANonce; and then probably uses STA MAC, AP MAC, PMKR0Name and R0KH-ID to derive PMKR1Name (and finds it in its local keys DB). It then derives PTK using PMKR1Name, ANonce and SNonce. Finally AP responds with ANonce providing client with all information to derive PMKR1 and PTK.
Correct me if I am wrong, but does it mean encryption is in effect after FT Authentication frames have been exchanged, hence FT REAssociation Frames are encrypted?
It looks very very similar to OKC, just different key hierarchy and more complicated terminology.
Hi Tim,
I think IEEE standard is the ultimate source of truth.
My blog is based on my understanding of the topic. I am sure you have better understanding on this topic 🙂
HTH
Rasika
802.11r
Very nice website. Can you shred the light below question please?
1- If over the Air Roaming FT, after Re-association Response, there will be 4-ways handshake exchange between STA and AP, as normal WPA2 Pre-auth, PMKID or OKC ? [Except different ways to computing PMK / PTK / GTK]
2- if Over DS as packet capture filename: iphone5-EAP-FT-over-DS-ch36.pcap. After Re-association Req and Re-association Response, there is not any other frame, how AP and STA calculate PTK and GTK (as 4-ways handshakes)?
3- If over DS FT, after Re-association Response, there will ONLY 2 action Frames STA to AP and AP to STA ? as in LAP2-LAP1-Over-DS.pcap? In this case, No packet auth get to AAA server ?
4- If 802.11r with no 802.1x / no 802.11i no / AAA authentication, just WPA2-Pre-shared Key as PSK. STA roam from AP1 to AP2. there are only Re-association Req from STA and Re-association Response from AP. That is? Will there be any action frames as 2-?
Do you happen to have the packet trace for these tests that you can share?
Thanks.
1- If over the Air Roaming FT, after Re-association Response, there will be 4-ways handshake exchange between STA and AP, as normal WPA2 Pre-auth, PMKID or OKC ? [Except different ways to computing PMK / PTK / GTK]
A) yes, Before reassociation req and responds authentication req and authentication responds frames exchange with new AP.
In the authentication req : STA Send SNONCE + PMR_R0
once AP receive authentication req had all properties to generate PTK [ANONCE (AP Had) + SNONCE (STA send in auth req ) + STA MAC + AP MAC + PMK_R1 -> PTK)
In the authentication res : AP will send ANONCE + MIC + PMKR_1
Now STA Had all properties it will device PTK.
In the reassociation req : In the frame STA send all R0KHID /R1KHID / MIC To AP.
In the reassociation resp : AP will send GTK with MIC to STA.
In the above all frames check in Fast BSS Transition element.
4- If 802.11r with no 802.1x / no 802.11i no / AAA authentication, just WPA2-Pre-shared Key as PSK. STA roam from AP1 to AP2. there are only Re-association Req from STA and Re-association Response from AP. That is? Will there be any action frames as 2-?
A) Same as above for PSK also those 4 frames will exchange takes place.
Not aware about over the DS.
If Anything wrong please correct the Answer.
Hi Hari,
Once again thank you very much spending time to respond these queries. I rally appreciate it.
Regarding last query about over the DS, then it will be two Action Frames (instead of authentication frame) & then re-association request/re-association response frame.
This link shows those different FT mechanism with respect to Cisco hardware
Click to access b_802point11rkw_deployment_guide_cisco_ios_xe_release33_chapter_01.pdf
HTH
Rasika
Hi Rasika,
Thanks for your explanation. I have one question as below.
at fist initial mobility domain association process , what kind Auth. Algorithm will be used on client? Open System, right?
Thanks,
Albert
Hi Albert,
Yes, it use Open Auth for initial mobility association
HTH
Rasika
Hello,
Thank you so much for your great posts! They are really cool.
Currently I’m developing a tool to detect different kind of 802.11 extensions (r, v, k, w…). Could you please share your pcaps of the roaming? It would help me a lot!
BR,
Valentín
PS: Here is the tool if you want to have a look (not ready for production yet): https://github.com/vk496/wififi
Good work, if you look at references section, I have provided a link to download that pcap used in this post
Rasika
Oh, didn’t saw it. Thanks! Just implemented the roaming detection 🙂