Because the work required establishing a PMK when 802.1X and RADIUS are used is significant, WPA2 provides for a way for the PMK to be cached for the client to use, if it should leave the access point and return before the PMK expires.
This is done using key caching. Key caching works because each PMK is given a label, called a PMKID, that represents the name of the RADIUS association and the PMK that was derived from it. The PMKID is specifically a 128-bit string, produced by the function
where AA is the BSSID Ethernet address, SPA is the Ethernet address of the client, and HMAC-SHA1-128 is the first 128 bits of the well-known SHA1-based HMAC function for producing a cryptographic one-way signature with the PMK as the key. The double-pipes ("∥") represent bitwise concatenation. The "PMK Name" ASCII string is used to prevent implementers from putting the wrong function results in the wrong places and having it work by accident.
From this, it is pretty clear to see that a client and access point can share the same PMKID only if they have the same PMK and are referring to each other.
When the client associates, it places into its Reassociation message's RSN information element (Table 5.16) the PMKID it may have remembered from a previous association to the access point. If the access point also remembers the previous association, and still has the PMK, then the access point will skip starting 802. IX and will proceed to sending the first message in the four-way handshake, basing it on the remembered PMK.
This caching behavior is not mandatory, in the sense that either side can forget about the PMK and the connection will still proceed. If the client does not request a PMKID, or the access point does not recognize or remember the PMKID, the access point will still send an EAP Request Identity message, and the 802.1X protocol will continue as if no caching had taken place.
No comments:
Post a Comment