PMK Cache / Static Key Caching

Everything is going mobile now, it was a time when man used building size machine for simple calculation. Now devices getting more compact and in the new Era of IoE we need mobility. 

With mobility we are also aiming for uninterrupted connectivity, normal data application still work well however issues are seen with time sensitive voice/vedio applications when client devices move from one AP to another. They work well with open authentication methods, however when it comes to security the clients need to authentication whenever they roam to new AP.

There are different methods in which we try to achieve security and un-interrupted services for the client devices. We use couple of caching mechanism in a way that once the client gets authenticated, they can regenerate the encryption keys doing the 4 way handshake without doing a complete authentication again. Following are couple of methods:

1. PMK Cache / Static Key Caching : In SKC, the client stores each Pairwise Master Key ID (PMKID) against a Pairwise Master Key Security Association (PMKSA). When a client finds an AP for which it has the PMKSA, it sends the PMKID in the association request to the AP. If the PMKSA is alive in the AP, the AP provides support for fast roaming. In SKC, full authentication is done on each new AP to which the client associates and the client must keep the PMKSA associated with all APs. For SKC, PMKSA is a per AP cache that the client stores and PMKSA is precalculated based on the BSSID of the new AP.







By default the Windows 7 machine have PMK caching enabled following is the snapshot on where you can confirm the setting.

SKC limitation on Cisco Wireless Infrastructure:

Restrictions for Sticky Key Caching
The controller supports SKC for up to eight APs per client. If a client roams to more than 8 APs per session, the old APs are removed to store the newly cached entries when the client roams. We recommend that you do not use SKC for large scale deployments.
SKC works only on WPA2-enabled WLANs.
SKC does not work across controllers in a mobility group.
SKC works only on local mode APs.



2. Pre-Authentication: Pre-authentication is a feature that allows a mobile device to authenticate with other Access  Points (APs) that it may roam to in the future. To achieve this, the  mobile station authentication frames are forwarded by the AP to the target AP, over the wired network. The first time a client associates to the network, the client must complete a full authentication. However, if the client knows where it will roam, the client can pre-authenticate to a new AP.


Pre-authentication is similar to IEEE 802.1X. The client performs an authentication through the new AP, which acts as the authenticator. The pre-authentication packets traverse through the existing AP to the new AP. Once the authentication is successful, the pre-authentication completes with a PMK security association established between the client and the new AP.






For pre-authentication to happen both client and AP have to support pre-authentication. That we can see in the beacon frame of the AP.


3. OKC(Opportunistic Key caching/Proactive Key Caching): Opportunistic Key Caching (OKC) is a similar technique, not defined by 802.11i, available for authentication between multiple APs in a network where those APs are under common administrative control. A deployment with multiple APs under the control of a single controller is one such example. Using OKC, a station roaming to any AP in the network will not have to complete a full authentication exchange, but will instead just perform the 4-way handshake to establish transient encryption keys. 

Although OKC is not a part of the 802.11i standard, several wireless vendors have adopted the technique and have achieved interoperability. Most notably, Microsoft has provided support for OKC in the Windows XP and Vista 802.1x supplicant.

The opportunistic PMK pre-caching technique works as follows: when a wireless station enters a mobility zone, it creates a new PMKSA (PMKSA_0) with the first access point after performing a full EAP authentication. The controller of the mobility zone retrieves the PMKSA_0 from the first access point and forwards it to other access points in the mobility zone. Each access point recieving the PMKSA_0 from the controller, uses it to derive a new PMKSA (PMKSA_i). These PMKSA_i are derived as follows. The PMKSA's PMK is the same as the original PMKSA_0 recieved from the controller. The PMKSA's PMKID (PMKID_i) is built as follows :

PMKID_i = HMAC-SHA1-128(PMKID_0, "PMK Name" | MAC_AP_i | MAC_STA) (1)

When the station moves to a new access point, it computes PMKID_i as specified in Eq.(1), then includes it in the (Re)Association Request message. If the access point is part of the same mobility zone, it will find a PMKSA that matches the PMKID_i presented by the station and use PMK_0 for the four-way handshake.

This way, a mobile station roaming between access points in the same mobility zone does need to perform a full EAP authentication each time it associates with a new access point. The same PMK will be used to create PMKSAs in all access points part of the same mobility zone.

A shortcoming of the opportunistic PMK pre-caching scheme is that it does not enable fast handoffs between mobility zones. When a station moves to a new mobility zone, a full EAP authentication must take place. This reduces the efficiency of the Opportunistic PMK pre-caching since its adoption does not completely eliminate lengthy handoffs.