Key Caching | 802.1X, EAP, and Centralized Authentication

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.

802.1X, EAP, and Centralized Authentication | Security for 802.11

Wi-Fi's self contained security mechanisms. With WPA2, the encryption and integrity protection of the data messages can be considered strong. But we've only seen preshared keys, or global passwords, as the method the network authenticates the user, and preshared keys are not strong enough for many needs.

The solution is to rely on the infrastructure provided by centralized authentication using a dedicated Authentication, Authorization, and Accounting (AAA) server. These servers maintain a list of users, and for each user, the server holds the authentication credentials required by the user to access the network. When the user does attempt to access the network, the user is required to exercise a series of steps from the authentication protocol demanded by the AAA server. The server drives its end of the protocol, challenging the user, by way of a piece of software called a supplicant that exists on the user's device, to prove that the user has the necessary credentials. The network exists as a pipe, relaying the protocol from the AAA server to the client. Once the user has either proven that she has the right credentials—she apparently is who she says she is—the AAA server will then tell the network that the user can come in.

The entire design of RADIUS was originally centered around providing password prompts for dial-up users on old modem banks. However, with the addition of the Extensible Authentication Protocol (EAP) framework on top of RADIUS, and built into every modern RADIUS server, more advanced and secure authentication protocols have been constructed. See Figure 1.

 
Figure 1: The Components of RADIUS Authentication over Wi-Fi

The concept behind EAP is to provide a generic framework where the RADIUS server and the client device can communicate to negotiate the security credentials that the network administrator requires, without having to concern or modify the underlying network access technology. To accomplish this last feat, the local access network must support 802.1X.