Key Management
One of the big problems in 802.11 is the distribution of keys; it is difficult for an administrator to generate and manage them. If a laptop or card is lost, the security of the site can be compromised. Keys can be compromised during mass distribution, if they are posted on web pages or distributed on CDs or floppy disks. Finally, the security problems make a strong case for developing dynamic keys.
802.11i introduces key management schemes that allow for a separate authentication process to enable the distribution of keys. There are two main phases to this process:
Master key establishment
Key exchange
Master key establishment can occur either manually via configuration or dynamically via the 802.1x protocol using EAP. After master keys are established, two parties perform key exchange to generate the transient keys they will use for the session. Although the term "key exchange" is used in the specification and in the literature, in reality this is a negotiation phase in which no actual keys are exchanged.
Master Key Establishment
EAP over LAN (EAPOL) is the preferred method for establishing master keys. 802.1x is a transport protocol used to convey the EAPOL authentication messages between the station and authentication server (AS). (Chapter 7 describes the 802.1x protocol.) For ESSID networks, a station first listens for beacons or actively sends out probe requests to connect to a network. It then authenticates using open system authentication, which does not really do authentication. The station and AP then conduct mutual authentication using EAP, which is where the real authentication takes place.
The station and the AS negotiate and authenticate until both sides are convinced that they are talking to whom they expect and that each side knows the proper secrets. At this point, the AS sends an EAP success message.
The mutual authentication process generates a shared key between the AS and the station. After the key is established, the AS transfers this key to the AP via RADIUS. Thus, this master key is at that point shared between a station and an AP. It is known as the Pairwise Master Key (PMK). Note that the AP is not involved in the key negotiation, except as a conduit for messages. Only at the end, when the PMK is derived, does the AP receive delivery of the PMK from the AS. If a TKIP administrator does not want to use 802.1x, this key can be configured by hand on the client and AP. This is known as a Preshared Key (PSK). For the rest of this discussion, the term "PMK" will include 802.1x PMKs and configured PSKs. How the shared key got to the station and the AP makes no difference from here on. It is important to note that the security of the encryption algorithms depends on the security of the PMKs. If they are predictable or compromised, the rest of the encryption becomes vulnerable.
At this point, key management is ready to begin. First, however, you should understand the different types of keys in 802.11i.
Key Hierarchy
There are two types of keys in 802.11i:
Pairwise for unicast traffic
Group for multicast traffic
The main root pairwise key is the PMK, and the main multicast key is the Group Master Key (GMK). The PMK can have a long lifetime and last through multiple associations to an AP. The GMK is a bit more at risk because it is shared among an AP and all its stations. All of the stations know it and might generate many packets with it. Thus, a GMK can be configured to be changed every time a station is disassociated or at a regular interval. On Cisco APs, this time-based reconfiguration is called broadcast key rotation. These master keys are used to derive other keys that are described in the next two sections. Table 8-2 summarizes the different types of keys used in 802.11i.
Key | Sharing Scheme | Use | Origin |
|---|---|---|---|
Preshared Key (PSK) | AP and single station | Used in TKIP, WEP, or CCMP. | Configured |
Pairwise Master Key (PMK) | AP and single station | Used as long-term stored key to derive other keys. | EAP negotiation |
Pairwise Transient Key (PTK) | AP and single station | Used to derive other unicast keys. | Derived from PMK or PSK via 4-way handshake |
Group Transient Key (GTK) | AP to single station (ESS networks) OR Single station to multiple stations (IBSS networks) | Used to derive other broadcast/multicast keys. Used in multicast communication. | Derived from PMK or PSK via 4-way handshake; can be renegotiated via group key handshake. |
Temporal Key (TK) | AP and one or more stations | For TKIP, this is a combination of a Temporal Encryption Key (TEK) and a MIC Key. CCMP has only one key, called the Temporal Key. | Derived from PTK |
Temporal Encryption Key (TEK) | AP and one or more stations | In TKIP, this is the key used to encrypt packets. | Derived from PTK or GTK |
MIC (Michael) Key | AP and one or more stations | In TKIP, this is used to calculate the Michael Message Integrity Check. | Derived from PTK or GTK |
EAPOL Key Encryption Key (KEK) | AP and single station | Used in group key handshake to encrypt the new GTK. | Derived from PTK |
EAPOL Key Confirmation Key (KCK) | AP and single station | Used in group key handshake to provide integrity for the messages. | Derived from PTK |
Pairwise Key Hierarchy
The PMK is the root of all other pairwise keys used in 802.11i. A unique PMK exists between each station and its associated AP. The PMK forms the root of a key hierarchy, as illustrated in Figure 8-15.
Figure 8-15. 802.11i Pairwise Key Hierarchy
From the PMK, the station and AP derive three keys using a pseudorandom function. The pseudorandom function first generates an intermediate key, the PTK. It takes as input two nonces, or unique numbers, whose origin will be explained later in the section "The 4-Way Handshake." The PTK is then chopped up into three keys: the EAPOL KCK, the EAPOL KEK, and the TK. In TKIP, the TK is 256 bits; in CCMP, it is 128 bits. In the case of TKIP, the 256 bits are further partitioned into the TEK for the mixing function (128 bits), the Michael key for authenticator-to-station traffic (64 bits), and the Michael key for station-to-authenticator traffic (64 bits). In the case of CCMP, all 128 bits become the CCM key. The pseudorandom function in the pairwise key hierarchy (see Figure 8-15) is the industry-standard SHA-1 cryptographic hash. The Group Key hierarchy can also use SHA-1, but that is not mandated.
Group Key Hierarchy
In a similar fashion, the GMK can be used as the root for the GTK, as illustrated in Figure 8-16.
Figure 8-16. 802.11i Group Key Hierarchy
In contrast to the PMK, which is mutually derived, the AP generates the GMK. The AP uses the GMK to generate the GTK, which has a length up to 256 bits and is translated into the various temporal keys used for multicast packets. The GTK can be used with WEP, TKIP, or CCMP. Depending on the encryption protocol used for group communication, its length differs. For 40- or 104-bit WEP, the GTK is used to generate a 40- or 128-bit WEP key. For CCMP, it is used to generate the 128-bit TK. For TKIP, 256 bits are generated and further partitioned, as described earlier for the PTK. If not all the stations support the same encryption protocols, it is possible for a station and AP to support a weaker encryption protocol for group communication than for pairwise communication. For example, in an ESS containing TKIP and CCMP-capable stations, the CCMP-capable stations could use CCMP for communicating with the AP and use TKIP for group communications. TKIP would be the lowest common denominator.
Key Exchange
After master key establishment, both sides share a PMK and are ready to negotiate the transient keys they will use for this particular session. They do this via security handshakes known as the 4-way handshake and the group key handshake. Each has a particular purpose and is performed as necessary. After either of these handshakes occurs, the keys derived are stored and used for pairwise or group communication. These keys are kept as long as they are valid and then destroyed.
The 4-Way Handshake
After a successful EAP authentication and establishment of the PMKs (or if PSKs are being used), a station must use the 4-way handshake to establish the transient keys with the AP. The 4-way handshake is a four-packet exchange of EAPOL-Key messages. It ensures that both sides still share a current PMK to exchange nonces to be used in building the key hierarchy and to exchange the GTK. Figure 8-17 illustrates the 4-way handshake.
Figure 8-17. 4-Way Handshake
The 4-way handshake starts with the authenticator (the AP) generating a nonce value. This nonce serves as replay protection and must be a value not used before with this PMK. It sends this nonce value in Message 1. The supplicant (station) generates its own nonce and uses the two nonces along with the PMK to generate the PTK, as illustrated in Figure 8-15. The supplicant replies with its own nonce and proof of its PMK by including a MIC in Message 2. The authenticator now has both nonces and can generate the PTK. The authenticator verifies the MIC that the client puts in Message 2, along with a few other fields. If the verification is successful, the authenticator generates the GTK if necessary. It sends the GTK in Message 3, which also tells the supplicant to install the PTK and GTK. Message 3 includes the receive sequence counter (RSC), which is the current sequence number of the GTK, and allows the station to detect replayed broadcast messages. The supplicant verifies the MIC in Message 3, installs the keys, and sends Message 4, which is a confirmation. After the reception, the authenticator verifies the MIC and installs the same keys. At this point, both ends have the same pairwise and group keys and are sure that the other knows the PMK.
The nonces used in this exchange must be nonrepeating. The easiest way to do this is to have them increase. However, if the nonces are chosen randomly, there is more protection against a precomputed attack against the server or the client. The downside of this approach is having to remember all the previously used nonces to ensure that they are never reused. However, the record of nonces can be cleared when a new PMK is computed.
The Group Key Handshake
In a way similar to the 4-way handshake, the group key handshake facilitates provisioning of a new GTK. The authenticator uses this handshake if only the GTK, but not the PTK, needs changing. The authenticator initiates the group key handshake in the event of a Michael MIC failure in either direction, upon deauthentication or disassociation of a station, or at a specified interval. In addition, a station can request a renegotiation of the GTK, which the authenticator then initiates. The station initiates this request with a special EAPOL-Key packet.
The GTK is only a two-message EAPOL-Key exchange. It uses the EAPOL KEK and the EAPOL KCK that both sides derived from the PMK. Figure 8-18 shows the two-message group key handshake.
Figure 8-18. Group Key Handshake
The authenticator sends Message 1, which contains the new GTK, encrypted with the KEK. The message has a MIC, which uses the KCK, to prevent modification of the message in transit. It also has an increasing receive sequence counter to prevent replays. In response, the client sends Message 2 as a confirmation. Message 2 has little in it but the incremented receive sequence counter as confirmation and its own MIC to ensure that the message is valid. After each side has received the other's message, the group keys can be calculated as described in the "Group Key Hierarchy" section.
Security Associations
Security associations are a record of the policy and keys that one or more entities share. In 802.11i, a security association (SA) records the security parameters that a pair or group of stations and APs have negotiated or configured to communicate with each other. These parameters include the cipher suites chosen, MAC addresses of the parties sharing the SA, the keys they have negotiated, SSIDs, and the lifetime of the SA. 802.11i defines several types of security associations, which are illustrated in Figure 8-19.
Figure 8-19. Security Associations
PMKSA
The Pairwise Master Key Security Association (PMKSA) is created after a successful 802.1x negotiation as part of EAP, or when a Preshared Key (PSK) is configured. It ties the PMK to a lifetime, the authenticator MAC address, and other authorization information. A PMKSA can be stored for future contact with the same AP. If a station roams to another new AP, it will generate a new PMKSA for it, but when it roams back to the first AP, it can use its original PMKSA.
PTKSA
The Pairwise Transient Key Security Association (PTKSA) is created after the 4-way handshake completes. It is dependent on the PMKSA and is stored for as long as the PMKSA is valid or until the station is deauthenticated. The PTKSA includes the supplicant and authenticator MAC addresses, the pairwise cipher suite selected, and the PTK itself.
GTKSA
The Group Transient Key Security Association (GTKSA) is created during the 4-way handshake or updated during a group key handshake. It stores the GTK, the broadcast/multicast cipher suites, and for which direction the GTK is good. It might also store other authorization or capability parameters such as the SSID. GTKs are unidirectional and are used either for transmitting or receiving. In the case of an AP-based network (ESS), the GTKSA is used between an AP and its associated stations. In the case of an Ad-Hoc mode (IBSS), the GTKSA is used from one station to all other stations.
Security Association Destruction
Transient keys last only as long as a station is associated to an AP. When a station loses association or authentication with an AP, it deletes the transient security associations and all keys associated with them. The PMKSA can persist until it expires.
