Robust Security Network (RSN) Operations

In addition to defining TKIP and CCMP, 802.11i also defines a set of procedures that build what the standard calls Robust Security Networks (RSNs). These operations define how keys are derived and distributed.

802.11i Key Hierarchy

There are two types of keys used by link layer encryption protocols. Pairwise keys protect traffic between a station and the AP it is currently serving. Group keys protect broadcast or multicast traffic from an AP to its associated clients. Pairwise keys are ultimately derived from the authentication information discussed in the previous chapter; group keys are created randomly and distributed to each station at the whim of the access point.

Pairwise key hierarchy

Both TKIP and CCMP take a single master key and expand it into the different keys required for frame protection operations. By using key derivation, stations can refresh encryption keys without re-running the whole authentication process. The master key is the root secret that must be carefully protected because all keying material is derived from it. Part of the key hierarchy's purpose is to derive keys used to protect transmission of the temporal keys.

Keying starts with the master key. In the pairwise key hierarchy, which is shown in Figure 7-8, the master key is unsurprisingly called the pairwise master key (PMK), which is 256 bits long. The PMK must come from somewhere. In WPA-PSK, the pairwise master key is configured. In configurations using an authentication server, the master key is computed by the RADIUS server and sent to the access point in a Microsoft Point-to-Point Encryption (MPPE) vendor-specific RADIUS attribute.

Figure 7-8. Pairwise key hierarchies

To obtain the temporal keys described earlier in this chapter, the PMK is expanded through the use of a defined pseudorandom function.[*] To further randomize data, the expansion is based on the pre-master key, the MAC addresses of both the supplicant and authenticator, and two random nonce values transmitted as part of the four-way key exchange handshake.

[*] Many encryption protocols use pseudorandom functions to expand a small seed into a large amount of random data. TLS is perhaps the best known example.

Both TKIP and CCMP use the pseudorandom function expansion to expand the 256 bits into the pairwise transient key (PTK). In both the TKIP and CCMP hierarchy, the two chunks of 128 bits of the transient key are used for keys that protect the temporal keys during distribution.

Both key hierarchies start with two EAPOL keys, used to secure transmission of keying material using the EAPOL-Key message discussed in the previous chapter. Two 128-bit keys are used. The first, the EAPOL Key Confirmation Key (KCK), is used to compute message integrity checks on keying messages. The second, the EAPOL Key Encryption Key (KEK), is used to encrypt keying messages. Both will be discussed in the section on the four-way handshake.

TKIP's transient key consists of a total of 512 bits, with the additional 256 bits used as the 128-bit temporal key that is used in TKIP data processing, and the 128-bit key for the Michael integrity check. TKIP requires two additional keys because it uses traditional encryption and authentication schemes that strictly separate encryption from authentication. CCMP's transient key is only 384 bits because only a single 128-bit temporal key is used for authentication and encryption.

Group key hierarchy

Link layer security protocols use a different set of keys for broadcast and multicast transmissions. Every associated station will have a different pre-master key, and thus, there is no way to derive a key for use with multiple destinations from the disparate authentication exchanges. Instead, the authenticator maintains a group master key (GMK) as the basis for temporal keys. The group master key is expanded into the group key hierarchy shown in Figure 7-9 by the use of a pseudorandom function. No key encryption or key confirmation keys are generated because the key exchange uses the pairwise EAPOL keys for key distribution.

Figure 7-9. Group key hierarchy

Networks may update the group keys when stations leave the network, either because they are finished or are deauthenticated. In TKIP, countermeasures may also trigger the regeneration of the group keys.

802.11i Key Derivation and Distribution

Rather than simply taking the master secret and using it as the input to a cryptographic protocol, 802.11i specifies a mechanism to derive keys. To prevent replay attacks, the exchange makes use of random numbers, and requires a handshake. Pairwise and group keys are updated through separate handshakes, which are both shown in Figure 7-10.

Figure 7-10. Key exchange handshakes

 

Updating pairwise keys: the four-way handshake

Pairwise, or unicast, keys are distributed through a procedure known as the four-way handshake, shown in Figure 7-10. Both the supplicant and authenticator are in possession of a shared pairwise master key. The four-way handshake exchanges parameters used to derive the temporal keys, as well as confirm that both sides are ready to begin encrypted transmission. Messages in sequence are implicitly acknowledged by the next message.

1. The authenticator sends the supplicant a nonce, which is a random value that prevents replay attacks. There is no authentication of the message, but there is no danger from tampering. If the message is altered, the handshake fails and will be rerun.

   At this point, the supplicant can expand the pairwise master key into the full pairwise key hierarchy. Expansion requires the MAC addresses of the supplicant and authenticator, the pairwise master key, and the two nonces.

2. The supplicant sends a message that has the supplicant nonce and a copy of the security parameters from the initial association with the network. The whole message is authenticated by an integrity check code calculated using the EAPOL Key Confirmation Key.

   The authenticator receives the message and extracts the supplicant nonce, which allows the authenticator to derive the full pairwise key hierarchy. Part of the key hierarchy is the key used to "sign" the message. If the authenticator cannot validate the message, the handshake fails.

3. Keys are now in place on both sides of the handshake, but need to be confirmed. The Authenticator sends the supplicant a message indicating the sequence number for which the pairwise key will be added. It also includes the current group transient key to enable update of the group key. The group transient key is encrypted using the EAPOL Key Encryption Key, and the entire message is authenticated using the Key Confirmation Key.
4. The supplicant sends a final confirmation message to the authenticator to indicate that it has received the keying messages and the authenticator may start using the keys. The message is authenticated using the Key Confirmation Key.

Updating group keys: the group key handshake

The group key handshake is considerably simpler than the four-way handshake, in part because it uses part of the results from the four-way handshake. Because the group transient key is encrypted with the Key Encryption Key from the pairwise hierarchy, the group key handshake requires that a successful four-way handshake has already occurred. It consists of only two steps:

1. The authenticator sends the group transient key (GTK), encrypted with the Key Encryption Key from the pairwise key hierarchy. The message is also authenticated with a code calculated with the Key Confirmation Key.
2. The supplicant sends an acknowledgment message, indicating the authenticator should begin to use the new key for group frames. This message is also authenticated using the Key Confirmation Key.

Even though the group key handshake is updating a key used by several stations, the use of the Key Encryption Key to protect data means that the handshake is inherently pairwise. When the group key is updated, the group key exchange must be run once for each station.

Although group key updates are generally controlled by the authenticator, stations may request a group key update by sending an unsolicited confirmation message.

Mixing Encryption Types

To allow for migration between different encryption protocols, as well as to accommodate older devices incapable of anything stronger than WEP, 802.11i defines a trust hierarchy for encryption protocols. WEP with 40-bit keys is the weakest protocol, followed by WEP with 104-bit keys, TKIP, and CCMP.

As part of the initial association to the network, each station can negotiate the encryption protocols it uses for both unicast and group data. The only restriction is that the group key must use either the same strength or a weaker encryption protocol. Access points use the "lowest common denominator" for the group key. In a network where the least capable associated station is only able to run dynamic WEP, the group key will be dynamic WEP. Other stations may, however, use stronger unicast protection mechanisms. Many access points provide policy controls to set a minimum acceptable encryption strength, and may prevent stations from associating with weaker protocols than desired by the network administrators.

The standard allows for nearly any mixture of encryption methods, with the exception that a station using CCMP for group frames must only support CCMP for unicast frames. However, many drivers do not support every allowed mode. Most notably, drivers usually do not support the combination of CCMP for unicast data in combination with older RC4-based frame encryption for the group key.

Key Caching

Pairwise master keys are the foundation of 802.11i security. Generating them is quite an expensive operation if the pairwise master key is the result of an 802.1X exchange. Most EAP methods require multiple messages and a significant amount of computation per step. The 802.1X authentication process may take several seconds, during which the user is unable to send or receive data. Client systems located on the boundary between two access points may be particularly affected if the wireless interface bounces back and forth between two (or more) access points with equivalent signal strength.

Reducing the authentication overhead is the motivation for PMK caching, which is shown in Figure 7-11. Rather than require a station to perform the full 802.1X exchange every time it connects to an access point, it references an existing session by the pairwise master key security association identifier. If the access point has an existing association, it accepts the association and proceeds immediately to the four-way handshake. In the four-way handshake, both the supplicant and authenticator will prove to each other possession of the cached PMK.

Figure 7-11. PMK caching

Stations that do not have cached master keys must perform a full 802.1X authentication to generate them. One of the motivations for preauthentication, which is discussed in the next chapter, is that can be used to establish master keys on access points before the handoff occurs, so that a master key is waiting.