802.11i

---

Security is wireless networking's major weakness. Of course, vendors have not improved matters by shipping products with default security features set as "none." The 802.11i Task Group is hard at work on a specification that will dramatically enhance the security features provided in a WLAN system. It has been working on this specification for more than two years, but now the final specification seems to be at hand. After two years of rousing debate, the body responsible for the Wi-Fi standard is finally putting the finishing touches on its new security standard, IEEE 802.11i.

802.11i will address many of Wi-Fi's security issues. To accomplish this task, it is expected that since most 802.11 security mechanisms are seated in the Data Link Layer's MAC sublayer, the 802.11i Task Group will update the MAC, and that those updates will then apply to all 802.11 PHY standards-802.11a, 802.11b, and 802.11g.

802.11i focuses on several security enhancements to temporarily support Wired Equivalent Privacy (WEP). These enhancements are collectively known as the Temporal Key Integrity Protocol (TKIP). The security enhancements include an authentication protocol, key-hashing function, combined with a real message integrity check (to avert forgery), and dynamic key management (i.e. rekeying). The 802.11i Task Group also is taking the necessary steps to assure that TKIP is backward compatible with WEP.

This section will examine the key technical elements that have been defined by the 802.11i Task Group to date. While these elements might change, the information set forth herein should provide the reader with some insight into the security features that 802.11i promises.

Note 

I want to thank CMP Media LLP and Dennis Eaton, the author of "Diving into the 802.11i Spec: A Tutorial" (dated November 26, 2002), which was published on the CMP Media LLP's Comms-Design website, inasmuch as the author used the information gleaned from that article to write the following text.

For this discussion, we will divide the proposed 802.11i specification into three main sections, organized into two layers. On the lower level are improved encryption algorithms in the form of the temporal key integrity protocol (TKIP) and the counter mode with CBC-MAC protocol (CCMP). Both of these encryption protocols provide enhanced data integrity over WEP, with TKIP targeted at legacy equipment and CCMP targeted at future WLAN equipment.

Above TKIP and CCMP sits what is now referred to as "802.1X," a standard for port-based access control developed by a different body within the IEEE 802 organization. As used in 802.11i, 802.1X provides a framework for robust user authentication and encryption key distribution, both features originally missing from the original 802.11 standard.

These three security meastures work together to form an overall security system. However, to understand how all three of these methods fit together, the reader must first understand how they operate individually. So, let's take a look at each one in more detail. We will start with 802.1X.

802.1X. IEEE 802.1X is a standard for port-based network access control. It can be applied to both wired and wireless networks. Further, it provides a framework for the centralized authentication of users or stations, for encryption key distribution, and it can be used to restrict access to a network until the end-user is authenticated. 802.1X also is used in conjunction with one of a number of upper layer authentication protocols (discussed later), to perform verification of credentials and generation of encryption keys. Thus, the standard's flexibility allows for multiple authentication algorithms, and since it is an open standard, multiple vendors can offer innovative enhancements.

There are three primary roles played by enterprise equipment in an 802.1X system. The authenticator (in a wireless network, this is typically the access point) is the port that enforces the authentication process and routes the traffic to the appropriate entities on the network. The supplicant, which in a wireless network is usually the computing device, is the port requesting access to the network. The authentication server (AS) is a third entity that performs the actual authentication of the credentials supplied by the supplicant. The AS is typically a separate entity on the wired side of the network, but could also reside directly in the authenticator. The most common type of authentication server in use today to authorize remote users is RADIUS, although other authentication services could be used since a particular authentication server to be used is not specified in the 802.1X standard.

The Controlled/Uncontrolled Port Concept. An 802.1X operation can be understood using the concept of a controlled port and uncontrolled port. (See Fig. 6.16.)

Figure 6.16: 802.1X state before (left) and after (right) successful mutual authentication.

The controlled and uncontrolled ports are logical entities and are the same physical connection to the network, Whether a frame traveling through the access point (AP) is routed through the controlled or uncontrolled port is determined by the authentication state of the client device.

Prior to authentication by the AS, the AP will only allow the client to communicate with the AS. After successful authentication by the AS, the AP will also allow the client to access other services available on the network.

The actual authentication data exchanged is a function of the upper layer authentication protocol used (discussed below); the message protocol and routing of the messages is controlled by 802.1X.

It's important to note that a mutual authentication process is used, and both the network and the client are authenticated to each other. As part of the authentication process, the MAC level encryption keys used by the chosen encryption protocol will be generated. 802.1X is then used to plumb the encryption keys down to the MAC on both the AP and the client device.

In 802.1X-enabled WLAN systems, two sets of keys are generated, session keys (also referred to as pairwise keys) and group keys (also referred to as groupwise keys). Group keys are shared amongst all the clients connected to the same AP and are used for multicast traffic. Session keys are unique to each association between an individual client and the AP, and create a private virtual port between a client and the AP.

802.1X enhances the enterprise security model by providing the following improvements over standard WEP:

• It provides support for a centralized security management model.

• The primary encryption keys are unique to each station so the traffic on any single key is significantly reduced.

• When used with an AS, the encryption keys are generated dynamically and don't require a network administrator for configuration or intervention by the user (this is analogous to the use of dynamic IP addresses versus static IP addresses on the network).

• It provides support for strong upper layer authentication.

802.1X in a SOHO Network. In the home and small business environment most users are not expected to have a RADIUS server available for authentication. In this case, the 802.11i standard uses 802.1X in a pre-shared key configuration, however most of the previous concepts and operation remain the same.

When operating with AS support, a master key, called the pairwise master key (PMK), is generated via the exchange between the client and the AS. The PMK is used as source material for generation of the lower level keys used by the MAC layer encryption. When an AS is not present, the PMK is manually entered into each device in the WLAN and serves as a pre-shared key for authentication and source material of the lower level encryption keys. The user model is more analogous to standard WEP in this case, since it requires manual distribution and configuration of a shared secret; however, this should be adequate for most small deployments.

When used in pre-shared key mode, session keys are still provided and the improved encryption methods discussed below are fully supported. It's important to note that upper-layer authentication is not supported, and the security of the network is broken, if the shared key is ever compromised. In many small deployment scenarios, these tradeoffs are likely acceptable in exchange for ease of deployment and configuration of the Wi-Fi equipment.

Encryption. The 802.11i standard provides two improved encryption algorithms to replace WEP. TKIP and CCMP are set out in the standard. Furthermore, the standard is written in such a way that it is able to support the addition of new encryption protocols, should they be required in the future. Thus a WLAN is able to support the simultaneous use of more than one encryption protocol with the client and AP using the highest level of security that both can mutually support.

However, a true 802.11i system uses either the TKIP or CCMP protocol for all equipment-not both. A WLAN that supports the simultaneous use of WEP along with the CCMP or TKIP encryption protocols is called a "transitional network," and is assumed to be a temporary configuration for the purposes of converting all clients to a TKIP- or CCMP-based security solution.

Let's take a closer look at these two encryption algorithms. We'll start with TKIP.

TKIP: This encryption method was designed to address all the known attacks and deficiencies in the WEP algorithm, while still maintaining backward compatibility with legacy hardware. It was designed to be made available as a firmware or software upgrade to existing hardware, so that users would be able to upgrade their level of security without replacing existing equipment or purchasing new hardware. TKIP provides an upgrade path by offering an additional protocol or a wrapper around WEP.

TKIP is composed of the following elements:

• A message integrity code (MIC) provides a keyed cryptographic checksum, using the source and destination MAC addresses and the plaintext data of the 802.11 frame (or MAC service data unit (MSDU) in IEEE nomenclature). This protects against forgery attacks.

• Countermeasures to bound the probability of successful forgery and the amount of information that an attacker can learn about a particular key.

• A 48-bit IV and an IV sequence counter to address replay attacks. Fragmented packets (MAC protocol data units (MPDUs) in IEEE nomenclature) received out of order are dropped by the receiver.

• Per packet key mixing of the IV is used to break up the correlation used by weak key attacks.

The structure of a TKIP-encrypted MPDU is shown in Fig. 6.17. As mentioned previously, TKIP uses an extended 48-bit IV called the TKIP sequence counter (TSC). The use of a 48-bit TSC extends the life of the temporal key (discussed below) and eliminates the need to re-key the temporal key during a single association. Since the TSC is updated with each packet, 248 packets can be exchanged using a single temporal key before key reuse would occur. Under steady, heavy traffic conditions, it would take approximately 100 years for key reuse to occur.

Figure 6.17: MPDU format after TKIP encryption.

The TSC is constructed from the first and second bytes from the original WEP IV and the 4 bytes provided in the extended IV. TKIP extends the length of a WEP encrypted MPDU by 12 bytes-4 bytes for the extended IV information and 8 bytes for the MIC.

The TKIP encapsulation process is shown in Fig. 6.18. Temporal and MIC keys are used, which are derived from the PMK generated as part of the 802.1X exchange discussed previously.

Figure 6.18: This graphic depicts the TKIP encapsulation process.

The temporal key, transmitter address, and TSC combine in a two-phase key mixing function to generate a per packet key to be used to seed the WEP engine for encryption. The per packet key is 128 bits long, and is split into a 104-bit RC4 key and a 24-bit IV for presentation to the WEP engine.

The MIC is calculated over the source and destination MAC addresses and the MSDU plaintext, after being seeded by the MIC key and the TSC. By computing the MIC over the source and destination addresses, the packet data is keyed to the sender and receiver preventing attacks based on packet forgery.

The MIC function, nicknamed "Michael," is a one-way cryptographic hash function, not a simple CRC-32 as is used in computing the WEP integrity check vector (ICV). This makes it much more difficult for an attacker to successfully intercept and alter packets in a denial of service attack. If necessary, the MSDU is fragmented into MPDUs, incrementing the TSC for each fragment, before encryption by the WEP engine.

The decapsulation process is essentially the same as the process illustrated in Fig. 6.18 with the following exceptions. After recovery of the TSC from the received packet, the TSC is examined to ensure that the packet just received has a TSC value greater than the previously received packet. If it does not, the packet is discarded in order to prevent potential replay attacks.

Also, after the MIC value has been calculated based on the received and decrypted MSDU, the calculated MIC value is compared to the received MIC value. If the MIC values do not match, the MSDU is discarded and countermeasures are then invoked. These countermeasures consist primarily of rekeying the temporal key, while controlling the rate at which this happens and sending alerts to network administration for follow-up.

To summarize TKIP:

• It was designed as a wrapper around WEP, so as to mask WEP's weaknesses by preventing data forgery, replay attacks, encryption misuse, and key reuse.

• It can be implemented in software.

• It reuses existing WEP hardware.

• It runs WEP as a sub-component.

• It doesn't unduly degrade a system's performance.

• It uses the 128 bit encryption key, with the AP and client device using the same key (TKIP's per-packet key construction makes this kosher), along with two 64-bit data integrity keys-one for the AP and the other for the client device, so each can use different data integrity keys for transmit.

Thus TKIP can be used with legacy equipment. Although not as robust as CCMP, TKIP does allow network administrators to avoid incurring additional expense for new equipment, while significantly upping the security quotient of their existing WLAN.

CCMP: In addition to TKIP encryption, the 802.11i draft defines a new encryption method based on the advanced encryption standard (AES). AES-based encryption can be used in a number of different modes or algorithms. The mode that has been chosen for 802.11 is the counter mode with CBC-MAC (CCM). The counter mode delivers data privacy while the CBC-MAC delivers data integrity and authentication.

AES is a symmetric iterated block cipher, meaning that the same key is used for both encryption and decryption, multiple passes are made over the data for encryption, and the clear text is encrypted in discrete fixed length blocks. The AES standard uses 128-bit blocks for encryption. For 802.11, the encryption key length is also fixed at 128 bits. Unlike TKIP, CCMP is mandatory for anyone implementing 802.11i.

Figure 6.19: Format of a CCMP encrypted MPDU. The packet is expanded by 16 bytes over an unencrypted frame, and is identical to a TKIP frame, with the exception of the legacy WEP ICV included in a TKIP frame.

Like TKIP, CCMP also uses a 48-bit IV called a packet number (PN). The packet number is used along with other information to initialize the AES cipher for both the MIC calculation and the frame encryption. (Fig. 6.20 shows the CCMP encapsulation process.)

Figure 6.20: Diagram of the CCMP encapsulation process.

The AES encryption blocks in both the MIC calculation and the packet encryption use the same temporal encryption key (K in Fig. 6.20). As with TKIP, the temporal key is derived from the master key that was derived as part of the 802.1X exchange discussed previously.

The MIC calculation and encryption proceed along parallel paths as shown in Fig.6.20. The MIC calculation is seeded with an IV formed by a flag value, the PN, and other data pulled from the header of the frame. This IV is fed into an AES block and its output is XORed (to hide the plaintext process) with select elements from the frame header, which is then fed into the next AES block. This process continues over the remainder of the frame header and down the length of the packet data to compute a final 128-bit CBC-MAC value. The upper 64 bits of this MAC are extracted and used in the final MIC appended to the encrypted frame.

Note 

XOR is the common expression used for the "eXclusive OR" binary operation. (It is pronounced "Ex-Ore.") XOR is a fundamental binary operation frequently used in cryptographic algorithms. It operates on binary digits, bits, which take the value 0 or 1. A XOR B is equal to 0 if and only if A = B, i.e. 0 XOR 0 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1, 1 XOR 1 = 0. It's a very fast operation in computers, and it has the useful property that if A XOR B = C, then B XOR C = A as well as A XOR C = B. When viewed in terms of wireless LAN security, the usefulness of XORing becomes more apparent if you look at it as: plaintext XOR keystream = ciphertext. It is then obvious that ciphertext XOR keystream = plaintext, which thus implements a simple and robust reversible transformation of plaintext into cipher-text using a keystream-the fundamentals used in stream ciphers.

The encryption process is seeded by a counter preload also formed from the PN, a flag value, data from the frame header, and a counter value which is initialized to 1. This preload value is fed to the AES block and its output is XORed with 128 bits of clear text from the unencrypted frame. The counter value is incremented by one and this process is repeated for the next block of 128 bits of clear text. This process continues down the length of the frame until the entire frame has been encrypted. The final counter value is set to 0 and input to an AES block, whose output is XORed with the MIC value computed previously before appending to the end of the encrypted frame for transmission.

The CCMP decapsulation process is not shown but is essentially the reverse of the encapsulation process of Fig. 6.20. A final step is added to compare the value of the computed MIC to that received before the decrypted frame is passed on by the MAC.

To summarize CCMP:

• It provides a long-term security solution for Wi-Fi networks.

• It is based on AES in counter mode encryption with CBC-MAC data origin authenticity, otherwise known as CCM, which is authenticated encryption combining counter mode and CBC-MAC, using a single key (a 128 bit block cipher that was designed for IEEE 802.11i). This allows CCM to provide authenticity and privacy via a CBC-MAC of the plaintext, as appended to the plaintext, to form an encoded plaintext (the encoded plaintext is encrypted to CTR mode), although it can leave any number of initial blocks of the plaintext unencrypted.

• It needs only one fresh 128-bit key, and the same 128-bit Temporal key is used by both the AP and the client device (CBC-MAC IV, CTR constructions make this kosher); the key is configured by 802.1X. Furthermore CCM encrypts packet data payload and protects packet selected header fields from modification.

• It requires new hardware because of AES, e.g. new AP hardware and perhaps new client device hardware, especially for hand-held devices.

• It is a brand new protocol and thus offers few concessions to WEP.

• It protects MPDUs = fragments of 802.2 frames.

  DATA TRANSFER SUMMARY

  	WEP	TKIP	CCMP
  Cipher	RC4	RC4	AES
  Key Size	40 or 104 bits	128 bits encryption 64 bit authentication	128 bits
  Key Life	24-bit IV, wrap	48-bit IV	48-bit IV
  Packet Key Integrity	Concat	Mixing Function	Not Needed
  Data	CRC-32	Michael	CCM
  Header	None	Michael	CCM
  Replay	None	Use IV	Use IV
  Key Management	None	EAP-based	EAP-based

• It is intended only for packet environment.

• It does not attempt to accommodate streams.

Thus although for the most part CCMP requires the purchase of new equipment before it can be used, it does provide CCM, which offers wireless networks a provably secure mode of operation.

Authentication Protocols. Upper layer authentication (ULA) protocols are not specified in the 802.11i standard, but will be an integral part of the security system in the majority of deployments. The reason ULA protocols are not included in the 802.11i standard is because, as the name implies, they operate at higher layers of the OSI model and are therefore outside the scope of the 802.11 standards, which operate only at the OSI lower layers-the Physical Layer and the Data Link Layer's MAC sublayer.

There are a number of popular ULA protocols in use today, primarily in the enterprise environment where the network infrastructure is in place to support their use. The ULA protocols are used to provide a mutual authentication exchange between the client and an authentication server residing somewhere on the network, and to generate session keys to be used between the client and the AP over the wireless link.

The ULAs work in conjunction with 802.1X, where 802.1X is used to enforce their use and route the messages properly, and the ULA protocols define the actual authentication exchange that takes place. In most cases, a RADIUS server will be used for authentication since many companies already use RADIUS for their dial-up users.

Some of the more popular authentication protocols include: the extensible authentication protocol with transport layer security (EAP-TLS), the protected extensible authentication protocol (PEAP), the extensible authentication protocol with tunneled transport layer security (EAP-TTLS), and the lightweight extensible authentication protocol (LEAP).

EAP-TLS is a certificate-based authentication protocol and is supported natively in Windows XP. It requires initial configuration by a network administrator to establish the certificate(s) on the user's machine and the authentication server, but no user intervention is required thereafter. The certificates are digital signatures that are used in conjunction with public key encryption techniques to verify the identity of the client.

During an EAP-TLS exchange, the client and authentication server exchange credentials and random data in order to simultaneously synthesize the encryption keys at both ends of the link. Once this has been completed, the server sends the encryption keys to the AP through a secure RADIUS channel, and the AP exchanges messages with the client to plumb the encryption keys down to the MAC encryption layer.

PEAP is an IETF draft standard and can be used to provide a secure password based authentication mechanism. Although it has not been implemented in any products to date, this is likely to change in the near future.

In a PEAP exchange, only the authentication server is required to have a certificate. After the initial communication with the authentication server, the public key from the AS certificate is sent to the client computer. The client computer then generates a master encryption key, encrypting this key using the AS's public key and sending the encrypted key to the AS.

Now that the master key is on both ends of the channel, this key can be used as source material to establish a secure tunnel between the AS and the client, over which any subsequent authentication method can be used to authenticate the client computer to the AS. In many cases is it expected that this will be some form of a password-based authentication protocol.

EAP-TTLS is also an IETF draft standard and can be used to provide password-based authentication of the client computer. EAP-TTLS is very similar in operation to PEAP, and has been implemented in some RADIUS server and supplicant software designed for use in 802.11 WLAN networks.

LEAP is a proprietary standard developed by Cisco Systems, and was designed to be portable across a variety of wireless platforms. It has gained popularity due to the fact that it was the first, and for a long time the only, password-based authentication scheme. It also provides this support across several different client operating system platforms.

LEAP is based on a straightforward challenge-password hash exchange, where the authentication server issues a challenge to the client and then the client returns the password to the authentication server, after first hashing it with the challenge text sent by the AS.

Since 802.11i updates MAC, once it's ratified, the installed base should be able to upgrade existing access points with firmware upgrades. But note that the implementation of new encryption methods like the Advanced Encryption Standard (AES) might require new hardware.

There is no estimated timeline for the ratification of this specification. While it may be finalized sometime toward the end of 2003, don't count on it. For now, owners of WLANs can provide stronger forms of security that go well beyond WEP, by implementing proprietary security mechanisms available from access points vendors. The problem with this idea is that the network providers will probably need to deploy network cards and access points from the same vendor. Another approach is to set up an IPSec virtual private network (VPN) to run over the wireless LAN.

Note 

One of the mistakes that WLAN manufacturers might make when evaluating the individual security elements of 802.11i is to consider them as individual security silos. They mustn't. All of the 802.11i "pieces" work together to form an overall security system. Taken individually and out of the context of the overall system, any single "piece" could be shown to have security weaknesses.

---