There's a mobile version of our website.
What exactly is the difference between PKC and OKC?
Seems to be a lot of confusion out there. What are the cold hard facts?
The WLC FAQ says
"PKC is a feature enabled in Cisco 2006/410x/440x ..."
The Debug Guide says
"The WLC only supports OKC..."
Wireless LAN Controller (WLC) Design and Features FAQ
Q. What is PKC and how does it work with the Wireless LAN Controller (WLC)?
A. PKC stands for Proactive Key Caching. It was designed as an extension to the 802.11i IEEE standard. PKC is a feature enabled in Cisco 2006/410x/440x Series Controllers which permits properly equipped wireless clients to roam without full re-authentication with an AAA server.
WLC Debug and Show Commands
PMKID Caching Fails
Check if the client supports opportunistic key cache (OKC).
Note: OKC is not the same as proactive key cache (PKC) as specified in 802.11I. The WLC only supports OKC.
Here's a solid answer: http://www.cwnp.com/bbpress/topic.php?id=3127#post-12086
Another nuance to this is that the client must support OKC, in the form of a Reassociation Request with PMKID information. For example, the iPhone/iPad does not support Opportunistic Key Caching, which has implications for fast roaming on the Cisco infrastructure. This Aruba document that advertizes a special feature which allows them to work on their infrastructure. http://www.arubanetworks.com/pdf/technology/whitepapers/wp_iPad-in-Enterprise.pdf (p. 7) 8. Validate PMKID Should be Enabled for All Apple Clients Opportunistic key caching (OKC), also called proactive key caching, can be used to restore latency and overhead in the authentication process when roaming between APs. iPad, however, does not support OKC. Instead, Pairwise Master Key ID (PMKID) is used to facilitate fast, secure roaming. With validate PKMID enabled, the AP will check if the client supports OKC. If the client doesn’t support OKC (which iPad does not), the AP will start the authentication process in the absence of the PMKID.
Thankyou for the link, good stuff.
After re-reading the original poster's question it adds more confusion for me
Anyone want to try to explain the difference between PMK Caching and Opportunistic PMK Caching (aka Proactive Key Caching)?
The question implies that Opportunistic PMK Caching and Proactive Key Caching are the same thing.
Before I go any further I think I need to get the terminology straight; never an easy task in the wireless world
Is Opportunistic PMK Caching the same as OKC? And is this the same as PKC or not?
Thanks for your help!
Message was edited by: GRAEME DANIELSON - spelling
Proactive and Opportunistic Key Caching are one and the same. There's also pre-authentication, which is another sleight-of-handoff. 802.11r is the emerging roaming standard that will hopefully make all these nuances moot someday. The question is when will Apple step up and roam effectively using enterprise authentication?
BTW, that Aruba PMKID-validate feature does *not* keep non-OKC clients from having to undergo a full back-end authentication. They still have to do the full EAP/802.1X authentication. It just eliminates any confusion in the 802.1X state machine on the client and controller.
I would like to add to this and perhaps add some insight to your question. I know this thread is a bit old...
OKC / PKC are the same thing.
OKC / PKC-- When a supplicant does its first 802.1X authentication a PMK is created. This PMK is cached on the WLC for all the APs to use on that WLC to negate the need of the supplicant having to do a 802.X auth each time a supplicant roams from AP to AP.
A supplicant and 5 aps. The client roams to the first AP and does a full 802.1X auth. This PMK is then saved on the WLC and is reused for the others APs. The client roams to another AP, the same PMK is used, but a different PTK is generated.
So you can see the client ever hits the radius server 1 time.
With autonomous APs there is PMK caching ... Not supported on the WLCs as I understand but will mention anyway.
Works differently. The supplicant would 802.1X auth to each AP, but it will create a PMKSA (PMKID) for each ap. So should that supplicant roam back to that AP (reassociate) then it would negate the supplicant from having to do a full 802.1X to that specific AP.
A supplicant roams to 5 access points. For the first time when the client roams to each of the 5 APs the client will do a full 802.1X auth. So thats a total of 5 802.1X auths. Should that client roam back to the otehr APS. There is no full 802.1X auth. Because it is cached in the PMKID.
So you can see the client has to hit the radius server 5 times (atleast once) for each ap.
OKC/PKC needs to be supported by the client as well. 80211.r is a close reletiave to OKC. I understand Apple will support 802.11r in ios5. The WLC will support 802.11r fully in 7.2 code.
I hope this helps ...
I want to add, I am not sure if cisco supports PMK cache on autonmous access points. I heard yes and no so dont know for 100%.
We do know, Cisco supports CCKM. If you have an autonmous network and you use a WDS you can take advanctage of CCKM.
Thank you for the rating ... Im glad this helped!
I rated :-)
To add the precision. The autonomous access points support the PMK caching but not the opportunistic one.
Blackberries for example just simply remember the keys they were using with previously associated APs and will reuse those if roaming back to the APs. So it only provide smooth roaming to APs where you previously associated to.
WLc doesn't support that version.
Is the OKC an hardware feature ?
In fact we have Dell Laptops compliant CCX V4, but we have serious issues with fast-roaming.
We opened a case an Cisco said us:
W"hen the client roam between two AP he need to provide his PMKID to the new AP in order to have fast roaming without disconnect the client and repeat the dot1x process again .
We called the client that provide his PMKID to the new AP ( support for OPPORTUNISTIC KEY CACHING ) , but your client type is ( sticky key caching ) which mean that he “ stick “ the PMKID for himself and he will not provide it to another AP .so he will disconnect until he complete the dot1x process again and generate a new PMKID .
It’s your client nature it’s not related to the configuration on the client side , the WLC support only client which support OPPORTUNISTIC KEY CACHING and that is why you have some types of client that disconnect while are connecting to the wireless network .""
So is there a way to set up fast-roaming on this client ?
Thanks a lot,
I can't comment on your particular adapter but what is said is true.
The fact is that the WPA2 standard is vague about fast roaming.
The original implementation was caching keys of APs you associated with in the past. The new implementation that cisco is promoting with the WLC is a dynamic computation of what the key will be with the new AP (OKC) which has the great advantage to work for 100% of aps, not only the one you associated with in the past.
Surprisingly, clients like blackberries or Iphones (I don't know for IOS 5 though) don't support that either so no fast roaming there.
CCKM is a very strict way of roaming, very standardized, so if a clietn supports CCKM, that will always happen fine.
802.11r is coming to give a final and good way of fast roaming standardized for all clients. but for now, there are 2 implementations (incompatible between each other) of WPA2 fast roaming and if your clients don't do the right one ... bad luck.
Yup, you best way is to capture the association reassocation frames and collect radius logs and you can see what the client actually does.
Or if you use the new cisco anyconnect 3.x client with Win Xp it will support OKC. If you win 7, it does not and will do a full auth each roam.
Thanks for your replies, do you think that if we set up Open Authentification (WPA2-PSK), we could get better fast roaming (as for the moment, in EAP-FAST, we experience full auth each time the clients roam).
Thanks to you,
Full exchange of the keys will still occur but it's much much faster than eap authentication and you'll probably won't notice the roaming time so that can be a workaround for you indeed.
George and Nicolas, you two appear to be the wizards of roaming. I am new to roaming so thanks for all of your awesome and informative answers in the forums here, they have been helpful.
Is there a list of clients that support OKC/PKC and/or CCKM? That would be super helpful.
Also, I see that CCKM was added to CCX3.0 and later. On the internet, I can find whether chipsets support CCX. However I am unclear on the following: if a chipset supports CCX, does that mean any device using that chip automatically supports CCX?
Lastly, 802.11r was ratified in 2008 right? You guys have mentioned it coming soon. When? Whats the hold up?
Thanks for any/all help.
for CCKM, any client that supports ccx should be able to do it.
The WLC has had 802.11r support ready to go sine version 5.2. The hold up is the clients that will actually support it. For 802.11r to work the client needs to support it as well as the AP. kind of like beamforming s a part of the specs for 802.11n, not all implementations are the same, and if a piece is optional the manufacturer am not support it or nly partially support it.
Sent from Cisco Technical Support iPad App
Hi Joe and welcome to CSC...
Q: Is there a list of clients that support OKC/PKC and/or CCKM? That would be super helpful.
A:This is a tricky question. OKC/PKC you need to actually test a client to be 100% sure. As for CCKM the client needs t support CCX as you mentioned.
Q:Also, I see that CCKM was added to CCX3.0 and later. On the internet, I can find whether chipsets support CCX. However I am unclear on the following: if a chipset supports CCX, does that mean any device using that chip automatically supports CCX?
A: If the chips supports 3 or later then yes it should support CCKM. HOWEVER, this also depends on how the VENDOR implements it.
A:Lastly, 802.11r was ratified in 2008 right? You guys have mentioned it coming soon. When? Whats the hold up?
Q: Hooks are in the WLC, but clients dont support it yet
It is always best to test romaing never take a vendors word. By this I mean captures. IN FACT, if you use WIN7 for a wifi client it uses OKC. If you use Cisco anyconnect 3.x on that same WIN7 box, you lost ALL advance romaing. Even though the document state that it does. I asked Cisco and I was told they cant access the API in WIN7 to support OKC/PKC.
Does this help ?
Holy Cow! You and Steve are impressively responsive. Thanks!
Both of your answers are very informative. Not what I was hoping for, but great answers.
Is there anything to do to the WLC to enable .11r? I want to test it with some clients that might have support. A quick web search and you can find that the TI WL1271 and WL1273 chips both appear to support 802.11r. Those chips show up in the Motorla Droid and Droid X respecively.
Would I need to turn anything on to test if the devices actually support it?
No, there isnt anthing to turn on for "r". Although I think its not fully supported till 7.2 code, this is what was mentioned at Cisco Live in June.
But now you peeked my interest I may need to test this myself. Do you have the links you mentioned about the moto and driod?
Thanks for the rating ...
If you want to learn more about roaming, check out the CWSP book.
It cites WL12xx Driver and WL12xx Hardware which would include WL1271 and 1273. Halfway down it has:
Supported WPA/IEEE 802.11i/EAP/IEEE 802.1X features
Then for Droid references:
Turns out they both have WL1271A.
Lemme know if you test it out. I will have to track down a Droid before I can test.
The code 7.2 has been release in february, I still haven't had the oppurtunity to test 802.11r...
For the moment, my customers haven't migrated to 7.2 and I don't have 802.11r compatible client...
Has someone been able to test it ?
Thanks a lot,
Above you reference Win7 not allowing access to the API for OKC to third party devs. Do you know if Apple OSX allows third party devs access to the right APIs?
P.S. I haven't spent much time finding a Droid to test yet.
I've got 7.2 release installed onto WiSM2 and it doesn't look like there is an option anywhere to enable the 802.11r... I assume it's enabled by default...
Though in the release notes it states "In the 126.96.36.199 release, you can configure the controller to provide faster roaming to client models from vendors such as Apple and Motorola (Fusion 3.0) that support WPA2 PKC(SKC) roaming"
From the wording it reads as if it has to be enabled...
It would appear to be that way. I see that the CLI command "config wlan security wpa wpa2 cache sticky enable <wlan_ID>" is now available in 188.8.131.52. Unfortunately, that command is not listed in the WLC 7.2 Command Reference guide. To verify if it is enabled or not, from the CLI, run the "show wlan <wlan_ID>" command. Look for:
SKC Cache Support.......................... Disabled
This is the default state. I just enabled it on two SSIDs that we are putting almost ready to pilot. I'll see if that helps with the roaming, particularly for the Motorola scan guns, Windows 7, and Apple devices. Unfortunately, it does require using the CLI (so can't push it out with an NCS template) and it requires disabling the SSID before applying it. After applying I did see fewer drops when roaming with a Motorola MC9090G, though they didn't always match up (roams and drops). I'll try to remember to post again after we've had a chance to test some more.
NCS should have all the functions of WCS, so you should be able to build a CLI template that you could push to your WLC.
Sent from Cisco Technical Support iPhone App
True. I was meaning that the setting is not part of the WLAN template. You can definitely build the CLI template. Hopefully your SSID WLAN IDs match up between all of your controllers when doing that, or you'll need to build several templates.
Login to share your discussion activity with your friends on Facebook. You can control what you share and turn off sharing anytime.
Your Facebook friends can now see that you have started this discussion
Your Facebook friends can now see that you have commented on this discussion
Your Facebook friends can now see that you have read this discussion