Thursday, November 12, 2015

PMK Caching & Preauthentication

There are two old (but standard) methods of roaming as described in 802.11i. These are:
  • PMK Caching
  • Pre-authentication
PMK Caching (done only when security is 802.1x /WPA2-Enterprise)
  • This method is also called PMKID Caching or PMKSA Caching or Sticky Key Caching
  • In this method, PMKSA is cached by the AP and by the client. One should note that PMKSA is specific to a combination of AP and client. Hence, each AP will have separate PMKSA cached for each client (same is true for client). This demands for high memory at AP and client and hence a bottleneck for scalable roaming.
  • When a client needs to move to new AP, it first checks its cache for PMKSA for that AP. In case, the cache has PMKSA for that AP it will send re-association request to that AP with PMKID included in RSN information element. However, if there is no matching entry in the cache it will go for either full authentication or pre-authentication if it is enabled.
  • The other issue is that client needs to get authenticated with all access points before it has PMKSA cached for them.
Note: Client provides PMKID only when moving in same ESS i.e. from one BSSID to another inside same ESS. When moving to different ESS (different SSID) it does not include PMKID.

  • This method sits on top of PMK caching. i.e. PMKSA caching is enabled.
  • When a client decided to move to new AP and does not have PMKSA cached then its starts pre-authentication with new access point with out breaking association with current access point. In case both AP and client supports OKC then client should calculate PMKID for the new AP (even if was not authenticated with this AP) and send it using RSN IE.  
  • Pre-authentication starts with EAPOL-Start frame to current AP. However, pre-authentication frames have ether type (88-C7) as opposed on standard EAPOL frames (ether type is 88-8E).
  • Pre-authentication frame fields look like:
    • DA: BSSID of target AP
    • BSSID: BSSID of current AP
    • SA: Client source address.
  • Pre-authentication frames are destined to target AP but sent through current AP.
  • Using pre-authentication, client authenticates with target AP. Traget AP then caches PMKSA for this client. 
  • After pre-authentication stage is complete, the client directly send association request (authentication frames are skipped) with PMKID just established. This way the costly authentication process with new AP is complete with breaking existing data connection with current AP.
  • Pre-authentication is indicated by access point by RSN Capabilities in RSN IE.
  • Windows 7 Client supports pre-authentication
Both these methods needs authentication with RADIUS whenever a client moves to new AP which increase load on RADIUS server. Hence, both these methods are not scalable.

No comments:

Post a Comment