Some Vendors such as Cisco extend the PMKID key caching mechanism to pro-actively cache the keys in a WiFi BSS network. This mechanism is also termed as proactive or opportunistic PMKID caching.

As a refresher, The PMKID Key caching as seen in the article <PMKID Key Caching> is to cache the Pairwise Master Key ID at the client side for a previous specific PMKSA association with an AP.

If the client roams back to the same AP,

1. The client can send the PMKID to the AP in the association request and
2. If the PMK Security Association (PMKSA) for that specific connection is still valid,
3. The client and the Access Point do not have to undergo a full EAP handshake and
4. Can directly jump to the EAPOL – 4 way handshke.

However, in PMKID caching, the PMKSA and the PMKID is different for different Client associations with different APs

OKC differs in the following way

1. A single PMK is maintained between different APs which are connected to a controller behind
2. The PMK1 and the pmkid1 computed between the client and AP1 are handed over to the other Access points by the controller
3. When an access point roams to a new Access Point AP2
   1. the client computes a new pmkid – pmkid2 based on
      1. pmkid1
      2. BSSID of AP2 – Authenticator Address (AA)
      3. Client MAC address – Supplicant Address (SPA)
4. The access point 2 obtains the PMK1 and the pmkid1 for AP1 from the controller and computes the pmkid2
5. If the pmkid2 sent by the client is acceptable to AP2 – the AP2 and the client skip the EAP – handshake and directly engage in a 4-way handshake

TKIP Encryption Mechanism