IEEE's wireless security amendment adds stronger encryption, authentication, and key management strategies that go a long way toward guaranteeing data and system security. With the falling cost and power consumption of wireless LAN chipsets and software, wireless LANs are proliferating everywhere, from smartphones to the enterprise to the factory floor. However, with a wireless link come inevitable and necessary concerns about security. Without security, people can view your wireless traffic. Do you want your neighbor to know what Internet sites you're visiting? Do you keep bank statements on your home network? It's a good idea to protect this information.
Because the market will demand products that provide this security, it's also a good idea to understand IEEE's new 802.11i security standards for wireless LANs. In this article, I'll describe the main components of 802.11i.
Fixing WEP
Although the IEEE 802.11 standard upon which Wi-Fi wireless LAN networks are based addressed security somewhat with the Wired Equivalent Privacy (WEP) protocol in its first instantiation, WEP proved relatively easy to crack. Fortunately, the IEEE 802.11 group became aware of the issues with WEP early on and on June 24 of this year the IEEE Standards Association approved an amendment to the original IEEE 802.11 specification that addresses these issues. The culmination of three and a half years of work by the IEEE 802.11i Task Group, the amendment adds stronger encryption, authentication, and key management strategies that go a long way toward guaranteeing data and system security.
The IEEE 802.11i effort actually started with a task group intended to address both quality of service and security, namely IEEE 802.11e. However, it quickly became apparent that security needed special attention and so that group was split into IEEE 802.11e, which continues to work on quality of service, and IEEE 802.11i, which focused on security.
The resulting IEEE 802.11i amendment has many components, the most obvious of which are the two new data-confidentiality protocols, TKIP and CCMP. IEEE 802.11i also uses IEEE 802.1X's key-distribution system to control access to the network. Because IEEE 802.11 handles unicast and broadcast traffic differently, each traffic type has different security concerns. With several data-confidentiality protocols and the key distribution, IEEE 802.11i includes a negotiation process for selecting the correct confidentiality protocol and key system for each traffic type. Other features introduced include key caching and preauthentication.
WEP has many problems. One of the first papers to reveal WEP's issues came from within the IEEE 802.11i Task Group. In late 2000, Jesse Walker submitted his paper, "Unsafe at any key size; An analysis of the WEP encapsulation" to show that WEP had serious problems and that the Task Group needed to devise an alternative.1 Another paper demonstrated WEP's biggest shortcomings. "Weaknesses in the Key Scheduling Algorithm of RC4," Scott Fluhrer, Itsik Mantin, and Adi Shamir, made clear that the original WEP key can be obtained from a passive attack.2
The IEEE 802.11i Task Group debated if it should attempt to improve the situation with legacy products. At first, the way to improve security with legacy hardware wasn't evident, and it appeared that acknowledging the problem and starting over with a completely different cipher would have been the easiest solution. However, many of the same authors who documented the weaknesses of WEP didn't give up and contributed ideas for an alternative that could be run on legacy products. What they came up with was TKIP.
TKIP
The Temporal Key Integrity Protocol (TKIP) is a data-confidentiality protocol that was designed to improve the security of products that implemented WEP—in other words, legacy products. Among WEP's numerous flaws are its lack of a message integrity code and its insecure data-confidentiality protocol. To get around these limitations, TKIP uses a message integrity code called Michael. Basically, Michael enables devices to authenticate that the packets are coming from the claimed source. This authentication is especially important in a wireless technology where traffic can be easily injected.
TKIP uses a mixing function to defeat weak-key attacks, which enabled attackers to decrypt traffic. Since the decryption could be done passively, it meant that an attacker could watch WEP traffic from a distance, be undetected, and know the original traffic. TKIP fixes this situation by using a mixing function. The mixing function creates a per-frame key to avoid the weaknesses pointed out by Fluhrer, Mantin, and Shamir.2
CCMP
Although TKIP improves security especially for legacy hardware, a stronger alternative was needed for newer hardware. Many Task Group members wanted the alternative to be acceptable for Federal Information Processing Standards (FIPS) certification, even though it wasn't absolutely necessary. In early drafts, Task Group I included Advanced Encryption Standard-Offset Codebook (AES-OCB). Questions over intellectual property, however, made some members uncomfortable. So, the Task Group switched to the Counter-Mode/CBC-MAC Protocol (CCMP).
CCMP is a data-confidentiality protocol that handles packet authentication as well as encryption. For confidentiality, CCMP uses AES in counter mode. For authentication and integrity, CCMP uses Cipher Block Chaining Message Authentication Code (CBC-MAC). In IEEE 802.11i, CCMP uses a 128-bit key. The block size is 128 bits. The CBC-MAC size is 8 octets, and the nonce size is 48 bits. There are two bytes of IEEE 802.11 overhead. The CBC-MAC, the nonce, and the IEEE 802.11 overhead make the CCMP packet 16 octets larger than an unencrypted IEEE 802.11 packet. Although slightly slower, the larger packet is not a bad exchange for increased security.
CCMP protects some fields that aren't encrypted. The additional parts of the IEEE 802.11 frame that get protected are known as additional authentication data (AAD). AAD includes the packets source and destination and protects against attackers replaying packets to different destinations.
IEEE 802.1X
IEEE 802.1X provides a framework to authenticate and authorize devices connecting to a network. It prohibits access to the network until such devices pass authentication. IEEE 802.1X also provides a framework to transmit key information between authenticator and supplicant.
IEEE 802.1X has three main pieces as shown in Figure 1:
Figure 1: IEEE 802.1X use in IEEE 802.11i system
- Supplicant
- Authenticator
- Authentication server
For IEEE 802.11i, the access point takes the role of the authenticator and the client card the role of supplicant. (In systems using Independent Basic Service Set [IBSS], the client card takes the role of supplicant and authenticator.) The supplicant authenticates with the authentication server through the authenticator. In IEEE 802.1X, the authenticator enforces authentication. The authenticator doesn't need to do the authentication. Instead the authenticator exchanges the authentication traffic between the supplicant and the authentication server. Between the supplicant and the authenticator, the protocol is IEEE 802.1X. The protocol between the authenticator and authentication server isn't defined in IEEE 802.1X nor IEEE 802.11i. However, Radius is typically used between authenticator and authentication server.
The uncontrolled port is used to pass authentication traffic between the supplicant and the authentication server. Once the authentication server concludes authentication with the supplicant, the authentication server informs the authenticator of the successful authentication and passes established keying material to the authenticator. At this point, the supplicant and the authenticator share established key material through an EAPOL-key exchange. (EAPOL, the Extensible Authentication Protocol over LANs, comes from clause 4 of IEEE 802.1X-2001.) And if all exchanges have been successful, the authenticator allows traffic to flow through the controlled port, giving the client to access to the network.
Negotiation
Because IEEE 802.11i has more than one data-confidentiality protocol, IEEE 802.11i provides a way for the IEEE 802.11i client card and access point to negotiate which protocol to use during specific traffic circumstances and to discover any unknown security parameters. For instance, broadcast-key data-confidentiality protocol isn't negotiated. However, clients need to know that the protocol is in use. For instance, a client that's configured to run with CCMP may or may not be configured to associate with an access point that's using TKIP for its broadcast traffic. The access point advertises its parameters in beacons and will also reply to a probe request with a probe response containing the access point's security parameters. Some of the parameters that the access point advertises are:
- The group ciphersuite is the data-confidentiality protocol used to send broadcasts
- The pairwise ciphersuite list is a list of all data-confidentiality protocols allowed to be used for unicast traffic
- The authentication and key management suite advertises if preshared key or IEEE 802.1X is being used
Once the client knows these parameters, it chooses parameters and sends the choices in the associate request to the access point. The choices must match from the list of available options provided by the access point. Otherwise, the access point will deny the association by sending a association response failure. Up to this point, the negotiation isn't protected. But, the negotiation does get authenticated later during the EAPOL-key exchange. Key hierarchy
The next step is key exchange. The IEEE 802.11i EAPOL-key exchange uses a number of keys and has a key hierarchy to divide up initial key material into useful keys. The two key hierarchies are:
- Pairwise key hierarchy
- Group key hierarchy
Both hierarchies are shown in Figures 2 and 3. These keys get used in the EAPOL-key exchanges. IEEE 802.1X defines an RC4 EAPOL-key frame. However, IEEE 802.11i defines its own EAPOL-key exchanges. In the IEEE 802.11i specification, these exchanges are referred to as the 4-way handshake and the group key handshake.
Figure 2: Pairwise key hierarchy or 4-way handshake
Figure 3: Group key hierarchy or group key handshake
Pairwise key hierarchy
The starting point of the pairwise key hierarchy is the pairwise master key (PMK). If IEEE 802.1X is being used then the PMK comes from the authentication server. If preshared key is being used then the IEEE 802.11i gives a way for a password to be mapped into a PMK. A pseudorandom function gets run over the PMK and other parameters to create the pairwise transient key (PTK). Some of the other parameters are:
- The supplicant's MAC address
- The authenticator's MAC address
- A nonce from the supplicant
- A nonce from the authenticator
The PTK gets divided into three keys. The first key is the EAPOL-key confirmation key (KCK). The KCK is used by the EAPOL-key exchanges to provided data origin authenticity. The second key is the EAPOL-key encryption key (KEK). The KEK is used by the EAPOL-key exchanges to provide for confidentiality. The third key is the temporal key, which is used by the data-confidentiality protocols. Group key hierarchy
The starting point of the group key hierarchy is the group master key (GMK). The GMK is a random number. A pseudorandom function gets run over the GMK and some other parameters to create the group temporal key (GTK). Some of the parameters are the authenticator's MAC address and a nonce from the authenticator for GTK creation (GNonce).
EAPOL-key exchanges
Two main EAPOL-key exchanges are defined in IEEE 802.11i. The first is referred to as the 4-way handshake and the second is the group key handshake.
4-way handshake
The 4-way handshake does several things:
- Confirms the PMK between the supplicant and authenticator
- Establishes the temporal keys to be used by the data-confidentiality protocol
- Authenticates the security parameters that were negotiated
- Performs the first group key handshake
- Provides keying material to implement the group key handshake
Not surprisingly, the reason it's called the 4-way handshake is because four packets are exchanged between the supplicant and the authenticator. Here are the four packets involved: - 4-way handshake message 1
In the first message, the authenticator sends the supplicant a nonce. This is referred to as the ANonce. - 4-way handshake message 2
The supplicant creates its nonce. This is referred to as the SNonce. The supplicant can now calculate the PTK. In the second message, the supplicant sends the SNonce to the authenticator. The supplicant also sends the security parameters that it used during association. The entire message gets an authentication check using the KCK from the pairwise key hierarchy. The authenticator can then verify that the information, including the security parameters sent at association, are valid. - 4-way handshake message 3
In the third message, the authenticator sends the supplicant the security parameters that it's sending out in its beacons and probe responses. The authenticator also sends the GTK encrypted using the KEK. Again, the entire message gets an authentication check, which allows the supplicant to verify that the information, such as the authenticators security parameters, is valid. - 4-way handshake message 4
The fourth message indicates that the temporal keys are now in place to be used by the data-confidentiality protocols.
Group key handshake
The group key handshake updates the GTK. A 4-way handshake precedes the group key handshake. Also note that the 4-way handshake includes a group key handshake in the 4-way handshake message 3 and 4. - Group key handshake message 1
The authenticator sends the supplicant the GTK encrypted using the KEK. The entire message gets an authentication check.
The second message indicates that the temporal keys are now in place to be used by the data confidentiality protocol.
Key caching Wireless clients often roam back and forth between access points. This has a negative effect on the system performance. Key caching reduces the load on the authentication server and reduces the time required to get connected to the network. The basic concept behind key caching is for a client and access point to retain a security association when a client roams away from an access point. When the client roams back to the access point, the security association can then be restarted.
Figure 4: Key caching
To achieve key caching, IEEE 802.11i names the PMK security association as shown in Figure 4. When a client returns to an access point, the client sends the key name in the association request that it sends to the access point. The client can send more than one key name in the association request. If the access point sends a success in the association response, then the client and access point proceed directly to the 4-way handshake. The first message of the 4-way handshake will contain the name of the PMK security association. The 4-way handshake confirms that the client and access point have the same PMK security association.
Preauthentication
Up to this point, key caching only reduced the time to connect to the network when the client had previously been associated to the access point. A way was needed to establish a PMK security association when a client had not yet been associated to the access point. Preauthentication enables a client to establish a PMK security association to an access point with which the client has yet not been associated.
Figure 5: Preauthentication
The first time a client associates to the network, it must do a full authentication. However, if the client knows where it will be roaming, the client can preauthenticate to a new access point, as shown in Figure 5. Preauthentication mimics IEEE 802.1X. The client performs an authentication through the new access point, which acts as the authenticator. The preauthentication packets traverse through the existing access point to the new access point. Once the authentication is successful, the pre-authentication completes with a PMK security association established between the client and the new access point. Preauthentication then completes and doesn't perform the 4-way handshake. When the client roams to the new access point, it performs the same steps in key caching. The client sends the PMK security association name to the new access point in the association request. If the access point sends an association response with success, the client and access point proceed directly to the 4-way handshake.
Preauthentication provides a way to establish a PMK security association before a client associates. The advantage is that the client reduces the time that it's disconnected to the network. However, preauthentication has limitations. For instance, clients performing preauthentication will add a load to the authentication server. Also since preauthentication is done at the IEEE 802 layer, it doesn't work across IP subnets. These issues should be targets for future improvements.
WPA2
The Wi-Fi Alliance name for IEEE 802.11i certification testing is Wi-Fi Protected Access (WPA) 2 or WPA2. WPA2 resembles IEEE 802.11i but differs slightly to allow for interoperability concerns with WPA. WPA is the Wi-Fi Alliance's earlier certification, which was based on a draft of the IEEE 802.11i standard. If migration isn't a concern then WPA2 runs as defined by IEEE 802.11i. For instance, an access point and client card running only CCMP in WPA2 will be running IEEE 802.11i. However, an access point that allows CCMP and TKIP clients will be running a mixture of IEEE 802.11i and WPA. This enables the earlier WPA clients to associate to the new WPA2 access points. To users this is transparent. But developers will need to note the difference when designing to include earlier WPA systems.
Wi-Fi Alliance tests for interoperability. WPA2 testing, however, doesn't test all configurations of IEEE 802.11i. The actual tests depend on product classification. Home products aren't expected to have the same features as enterprise products.
Designing a system
You'll need to answer a number of questions before designing a system. The following are some questions and guidelines to help you start the process.
IBSS or ESS?
Independent Basic Service Set (IBSS) is a mode of operation that's suited to small and transient networks. If you're setting up an IBSS as a small and transient network then preshared key authentication should be sufficient. Extended Service Set (ESS) networks are better suited to IEEE 802.1X. Don't let the authentication server scare you. Authentication servers come in different sizes and support different authentication types.
Preshared key or IEEE 802.1X?
Preshared key can be done in IBSS or ESS. However, the network size and the network lifetime can guide your choice between preshared key or IEEE 802.1X. Small and transient networks point to preshared key. While large or permanent networks point to IEEE 802.1X.
If IEEE 802.1X, which EAP?
Selecting an authentication method can be complicated because you have find the right authentication protocol for your system's user database. Also you have to know what each protocol requires. For instance, EAP-TLS (Extensible Authentication Protocol-Transfer Layer Security) requires certificates. Some groups are creating tunneling protocols so choosing an EAP may eventually become easier. Another issue is whether your system will plug into an existing network. If you're designing a new system you have a freer hand. However, plugging into an existing network means it pays to investigate the options.
Which data-confidentiality protocol?
Which data-confidentiality protocols will be supported? WEP, TKIP, CCMP, or a combination? If you're designing a new system you'll want to balance designing in new hardware with the most secure data-confidentiality protocol against having to support existing products. Since a large number of products exist, it's important to identify the hardware you'll need to support.
A good thing
All in all, the IEEE 802.11i amendment is a step forward in wireless security. The amendment adds stronger encryption, authentication, and key management strategies that will make our wireless data and systems more secure.
David Halasz is a manager of software development at Cisco Systems. He worked for Aironet since 1995 and joined Cisco in 2000 when Cisco acquired Aironet. He earned his computer engineering degree at Case Western Reserve University in Cleveland, Ohio. David served as the chair of the IEEE 802.11i Task Group from its inception through the amendment's ratification in June of 2004.
Endnotes
- Walker, J. "Unsafe at any key size: an analysis of the WEP encapsulation," Tech. Rep. 00/362, IEEE 802.11 Committee, March 2000, DocumentHolder/0-362.zip, http://grouper.ieee.org/groups/802/11/Documents/
- Fluhrer, S., I. Martin, and A. Shamir. "Weaknesses in the key scheduling algorithm of RC4." Eighth Annual Workshop on Selected Areas in Cryptography, August 2001.
Copyright 2005 © CMP Media LLC
