Session-Timeout, RADIUS and PMK caching
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-01-2016 05:45 AM - edited 07-05-2021 06:11 AM
Hi everyone
I am currently preparing to WISECURE exam. Trying to understand everything behind WPA2 Authentication, Key Management, Encryption and Integrity. I think I've got the concept right and have the complete picture already. However, I wanted to confirm my understanding by re-creating few things in a lab and perform few captures.
Everything was ok, until I started to "play" with WLAN session-timeout value. In my understanding, this value tells STAs to go via full dot1x reauth. Also, if I am correct, Cisco has introduced PMK caching in 7.2 or later (don't know exactly) and this timer, in fact, says for how long PMKs have to be stored in WLC's memory.
I have changed this value to 300 seconds (from 1800 default), enabled debug on WLC and started packet capture on WIRE and OTA
WLC shows the following when station connects:
Disable re-auth, use PMK lifetime.
Station 3c:a9:f4:b1:d8:c4 setting dot1x reauth timeout = 300
Setting re-auth timeout to 300 seconds, got from WLAN config.
Station 3c:a9:f4:b1:d8:c4 setting dot1x reauth timeout = 300
Disabling re-auth since PMK lifetime can take care of same.
So, I assume session-timeout was previously responsible for full reauth, but now also tells WLC for how long to keep PMKs in a cache.
In fact, full-reauth is still performed after this timeout, so effectively session-timeout = PMK cache timeout.
Correct me if I am wrong here please?! Anything I need to know about PMK caching and session-timeout (802.1x full reauth)?
I have waited for 20 minutes to collect enough packets for analysis and when I stopped all captures I have noticed the following weird behavior that I don't understand.
Every 5 minutes my WLC generated a series of debug messages that looked very similar to initial authentication (including EAP/RADIUS).
However, I have seen scrambled results in Over the Air capture.
Initial authentication was ok, but all consequent were not shown.
I have found all my EAP packets in the Over-The-Air capture after I removed all EAP/EAPOL filters. Surprisingly, all these frames were encrypted?
Can anyone please confirm that WLC/APs use AES-CCMP to encrypt EAPOL frames when session timeout kicks in and refresh is required?
This is definitely not true when STA is roaming - everything is sent in a clear-text (i.e. EPOL frame structure can be recognized by Wireshark).
In my case Wireshark was unable to decode these packets as EAPOL and binary details were kind of random (i.e. encrypted) for me...
Much appreciate
Tim
P.S. After writing this post... this kind of became rational to me
- Labels:
-
Other Wireless Topics
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-01-2016 10:51 AM
This blog post by George nicely explain it
Also, have a look below document which describes client roaming scenarios with packet captures
HTH
Rasika
*** Pls rate all useful responses ***
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-01-2016 12:17 PM
Great thanks Rasika!
I will give it a read now. I always read your blog (in fact, anytime I google I end up on it). Nice work!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-02-2016 12:31 PM
Got through and done my own captures for CCKM and OKC.
Faced few weird issues while I was doing this.
Decided to test OKC first, as it's enabled by default in Windows.
Everything was working great - upon successful re-association client only had to do 4-way handshake. Debug output matches the one shown in technote you've attached. No extra configuration was required on W10 machine. Client was reported to be CCXv4 compliant by WLC.
I have then configured my WLAN with CCKM. My W10 client wasn't able to connect
Hmm.. How about CCXv4 then? WLAN is WPA2/AES/dot1x.
The technote says WPA2/AES requires CCXv5 - sounds strange to me. Wasn't CCKM introduced in CCXv2? If so, hasn't it to support WPA2 which was introduced in CCXv3?
Anyway, I have checked Intel PROSet and found that CCX and CCKM were disabled in it.
I enabled both, but CCKM wasn't in effect - debug reported that client is CCKM, but no roaming was occurring (my client was using association frames for some reason).
I've done some more reading and found my FlexConnect APs were not in the group. After adding both to the same group - CCKM has started to work properly and as in the attached technote.
I have then disabled CCKM on WLAN and Intel PROSet, but found that OKC doesn't work anymore. Even though client has been providing PMKID in RSN IE within Re-association frame, WLC was saying that it can't compute new PMKID.
Well... some time later I decided to disable CCX in Intel PROSet and that restored default Windows functionality (OKC).
Now, I understand George's words even better... without testing (with real packet capture) how your clients behave it is impossible to plan anything.
Also, he mentioned that AnyConnect ruins OKC and does not support CCKM in W7, even in the latest version (which I confirmed by reading Release Notes). We have just started discussions to deploy NAM module (because we use AC VPN, so it was logical step). It doesn't seem so anymore and I'll have to raise this concern with the team.
Having said that... I am still trying to understand what should be the best value for session-timeout on a corporate WLAN with voice services deployed (i.e. one WLAN for voice and data as we run Lync on top of data network)? In my understanding session-timeout is kind of top hierarchy timeout value for wireless clients - it will purge all cache for the client and will force full reauth. Well, 1800 seconds (default) doesn't seem like a best timeout in this case?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-03-2016 02:25 PM
Here's another perfect reading on the same subject (more deep and referencing standard)
https://www.cwnp.com/uploads/802-11_rsn_ft.pdf
