Cisco Unified Wireless LAN Security Fundamentals

This chapter is from the book 

Addressing the WLAN Security Challenges

The security challenges presented by 802.11 WLANs can seem daunting; however, do not despair, because there are solutions! Based on experience, WLAN deployments are usually more secure than their parallel, wired networks. Now that you've been introduced to the major vulnerabilities in 802.11 WLANs, this section takes a look at the solutions.

Table 4-1 documents a mapping between the major WLAN security challenges and the solutions.

Table 4-1. WLAN Security Challenges and Solutions

WLAN Security Challenge	WLAN Security Solution(s)
Vulnerabilities inherent to the radio transmission medium	Strong authentication and privacy
Vulnerabilities inherent to the standards definitions	Strong authentication and privacy, Management Frame Protection
Vulnerabilities inherent to mobility	Fast, secure roaming; secure management and policies
Misconfigured wireless devices and clients	Secure management and policies
Rogue access points and devices	Rogue AP management and wireless intrusion prevention systems, secure management and policies
Readily available profiling and attack tools	Secure management and policies

The sections that follow take a more in-depth look at the solutions.

Background on Strong Authentication and Privacy

If you think about the challenges presented by the radio transmission medium and the standards definition, the most logical and only practical mitigation strategies introduce strong authentication and data privacy through encryption. The need for strong authentication and data privacy extends to roaming clients, which must be reassociated and reauthenticated quickly while securely preserving data privacy. But what are the specific requirements for strong authentication and privacy? To answer that question, you need to consider how the 802.11 WEP-based security model is flawed.

How WEP Encryption Works

Previously, this chapter established that WEP is broken on the cryptographic front and shouldn't be used; however, it's useful to look briefly at how WEP works to establish some baseline knowledge for later in the chapter.

The WEP encryption is based on the symmetric RC4 cipher algorithm developed by Ron Rivest at RSA Security Inc. A symmetric cipher algorithm uses the same encryption key for encryption and decryption. Figure 4-1 illustrates the entire WEP processing model for a packet.

There are a couple of things to note about RC4 first. RC4 encrypts data one byte at a time. This is because RC4 is a stream cipher, as opposed to a block cipher, which operates on chunks of data. For each byte of data input into the encryption algorithm, an encrypted byte of data is output. Note also that the RC4 algorithm is reversible. Inputting plain text and the encryption key into the RC4 algorithm yields cipher text. Inputting the cipher text and the same encryption key into the RC4 algorithm yields the plain text.

Notice how the WEP key is prepended with an IV, or initialization vector, prior to being fed into the RC4 algorithm. The IV is a 24-bit value that is different per packet, ensuring a different encryption key per packet. Note that we said different instead of unique. You can never truly have a unique encryption key per packet in the WEP processing model because the WEP key portion is static and there are only 2²⁴ IVs available. Eventually, the IV space will be exhausted and the WEP processing model needs to start reusing IVs. Also, the encryption key per packet cannot be unique because there will be multiple client devices using the same connection. Each client has its own IV sequence, meaning that multiple clients could use the same IV.

The IV is not kept secret because the receiver needs to know which IV has been used to encrypt the packet in order to decrypt the packet. In fact, as Figure 4-1 shows, the IV is transmitted in the clear.

The combined IV and WEP key are fed into the RC4 algorithm. Specifically, the combined value is used to seed the RC4 key stream generator. The purpose of the key stream generator is to output a pseudorandom sequence of bytes, called the key stream, that are used to scramble the plain text. Remember though, that every time an identical IV and WEP key pair are input into the RC4 algorithm, the same key stream will be generated.

The plain text is a combination of the data in the MAC protocol data unit (MPDU), which is a chunk of data from a higher-layer application and a 4-byte Integrity Check Value (ICV). The ICV is a value computed over the MPDU data using the CRC-32 algorithm. The ICV is intended to provide protection against message tampering in transit. That's why the CRC-32 value is computed before encryption.

The combined data and ICV are then encrypted by the RC4 algorithm using the key stream. The encryption mechanism used by the RC4 algorithm is simply the bitwise exclusive OR (XOR) operation. The plain text is XORed with the key stream, and the result is considered the cipher text.

The cipher text is inserted into the data frame body along with the clear text IV and the key ID of the WEP key used for this particular packet. Remember that the 802.11 specification calls for up to four WEP keys, so the receiver needs to know which key to use for decryption. The MAC header is prepended to the data frame body, and the frame check sequence (FCS) is computed. Next, the entire frame is handed down the protocol stack to be transmitted by the radio.

When the frame is received on the receiving end, the process is essentially reversed. The IV is stripped out of the frame's data body, the key ID is used to select the correct WEP key, and the IV and WEP key are combined and fed into the key stream generator. The encrypted cipher text is extracted from the frame body and XORed with the key stream, yielding the plain text. The ICV is computed over the data portion and compared to the ICV computed by the sender. If it matches, the data in the frame has not been tampered with and it is accepted. If the ICV does not match, the frame is rejected because the system assumes that the data has been modified in transit.

So now that you understand the WEP processing model, the section that follows examines how the 802.11 specification uses WEP and why it's broken!

How WEP Is Broken

To determine why WEP isn't a good security solution, you need to look at some practical problems and then look at the cryptographic problems with WEP.

For now, ignore the cryptography and consider just the practical aspects of using static WEP for data privacy. Remember that WEP keys have the following properties:

• They are static: They can't be changed except by reconfiguring all access points and stations.
• They are shared: All access points and stations share the same WEP keys.

The static property of WEP keys creates a management headache when it comes to key distribution. It isn't much of a challenge to configure WEP keys in a small office or home network when there are only one or a few access points and a few end stations. If there are many access points and end stations, however, this is a major problem. Configuring WEP keys isn't just a problem when devices are initially provisioned; as you are about to learn, WEP keys should be frequently rotated to mitigate some cryptographic weaknesses.

Now, think about the shared key property. Basically, this means that every WLAN device on the network has the capability to decrypt any other device's encrypted frames. Maybe that doesn't matter in some deployments, but then again, it probably does in others. Do you want your colleagues decrypting and reading some of your email messages?

Those are just some of the practical problems intrinsic to the specification. There are some major cryptographic problems with WEP, too. As previously noted, as 802.11 WLAN technology started to take off, a lot of smart people in the cryptographic community took a good long look at WEP as a security mechanism and identified catastrophic flaws.

We'll keep it simple here and not go into all the details of birthday paradoxes, bit-flipping, and weak IVs. The reference material at the end of the chapter provides that information. In a nutshell, the big cryptographic problems center around several areas: IV choice, reuse, transparency, flaws in the integrity-checking mechanisms, and weak RC4 keys.

802.11 Authentication

In the base 802.11 specification, there are basically two kinds of authentication: open authentication and shared-key authentication. Figure 4-2 illustrates open authentication.

As you can see, open authentication is exactly that—completely open. It isn't designed to authenticate the end-user device in any way. As long as the association request includes a valid service set identifier (SSID) on the access point, the device is allowed access to the network. When open authentication is used with static WEP encryption, there is some access control because each end-user device needs to know the WEP key to transmit any data after associating with an access point.

You might ask, why would a standards body allow free and open access to the WLAN? Well, there are many applications where open access to the network satisfies business objectives. Many universities view the WLAN as an open resource and thus provide no authentication or access control. Open authentication is sometimes used for guest access solutions in enterprises and supplemented with some kind of portal-based access control. It's also used in most public hotspots, typically supplemented with the service providers' access and authentication framework layered on top of the 802.11 open authentication.

Now what about shared-key authentication? Figure 4-3 illustrates shared-key authentication.

As you can see from Figure 4-3, the authentication is provided by a challenge, challenge-response mechanism. The access point sends an arbitrary 128-bit value as challenge text to the station requesting access. The station encrypts the challenge text using the WEP key and sends this as the challenge response. If the WEP key is shared correctly between the AP and the end-user device, the AP should be able to decrypt the challenge response and compare it to the challenge text. If it matches, the station is allowed access. Simple enough.

If you take a closer look, however, there's a mutual authentication deficiency. The AP is authenticating the station, but what allows the station to trust that the challenge response is from the correct AP? The answer is...nothing! The station has no way of knowing whether the challenge text comes from a legitimate AP or an AP impersonator.

But it gets worse. An eavesdropper watching this transaction just saw a plain-text message (the challenge) and its corresponding cipher text (the challenge response). Now, if the eavesdropper takes the plain text and XORs it with the cipher text, she gets the key stream corresponding to that IV!

Unfortunately, the 802.11 specification allows for IV reuse, so if the vendor implementation is sloppy, the eavesdropper might be able to use the recovered material to authenticate herself and start sending packets into the network. Worse, the next time the eavesdropper sees a frame with that IV, she can use the recovered key stream to decrypt the cipher text by simply XORing the cipher text with the key stream. If she's patient, she can build enough of a key stream database to decrypt a lot of cipher text.

As you can see, shared-key authentication is worse than no authentication because it provides a false sense of security.

Oh, and maybe you noticed something else about both open and shared-key authentication. Curious? There is no user-based authentication. Device-based authentication, like 802.11 open and shared-key authentication, does not prevent unauthorized users from accessing networked resources from authorized machines. Think of the problem presented by lost or stolen assets!

Addressing the Strong Authentication and Privacy Challenges

After having reviewed the issues with the base 802.11 specification and WEP for authentication and privacy, a set of basic requirements for real authentication and privacy emerges:

• User-based authentication
• Mutual authentication
• Dynamic, per-session, and per-user cryptographic keys
• Larger IV space than 2²⁴
• Stronger cryptographic algorithms than RC4
• Backward compatibility with RC4-only-capable client devices
• Strong message integrity checks
• Scalability and manageability

These are the basic requirements for strong authentication and privacy addressed by the IEEE 802.11i task group charter. The work of the 802.11i task group resulted in a new 802.11 amendment that defines the following:

• Two types of networks: The Transition Security Network (TSN) and the Robust Security Network (RSN)
• New data privacy and integrity models: Temporal Key Integrity Protocol (TKIP) and CCMP
• An authentication framework based on IEEE 802.1X and EAP
• Dynamic cryptographic key management

TKIP includes techniques to protect cryptographic keys through key mixing and packet counters and a Message Integrity Check (MIC) algorithm. TKIP is designed to be backward compatible with legacy WEP equipment.

CCMP is an algorithm for data privacy and integrity based on the Advanced Encryption Standard (AES). CCMP is stronger than TKIP but is not backward compatible with legacy equipment that cannot support AES.

The IEEE 802.1X standard defines an algorithm for port-access control that requires client devices to authenticate before being given network access. The authentication is accomplished through the EAP and RADIUS protocols. The key management algorithm is designed to generate dynamic cryptographic keys to address the weaknesses in WEP.

An RSN is a network that allows only TKIP and/or CCMP. A TSN allows both RSN and WEP machines.

While the IEEE 802.11i task group was working on completing the 802.11i standard, the Wi-Fi Alliance adopted Wi-Fi Protected Access (WPA) as an industry standard. WPA was based on the parts of the 802.11i standard that were available and uncontroversial at the time. After 802.11i was ratified, though, the Wi-Fi Alliance adopted the full document as its WPA Version 2 standard.

In a nutshell, WPA includes TKIP, 802.1X authentication, and dynamic key management. WPAv2 adds CCMP. Both WPA and WPAv2 have the following modes:

• Personal mode: Allows pre-shared keys for authentication
• Enterprise mode: Requires 802.1X authentication

We will look at the enterprise mode here.

Cisco literature often uses a four-ingredient model, as illustrated by Figure 4-4, to abstract basic wireless security requirements:

• The authentication framework: The scaffolding necessary for the authentication and encryption algorithms
• The authentication algorithm: Provides a secure way of validating user credentials
• The data privacy algorithm: The cryptographic mechanism for obfuscating data in transmission
• The data integrity algorithm: Protects messages in transit from tampering

Authentication Framework

The authentication framework provides the scaffolding for the authentication and encryption algorithms and mechanisms by specifying the protocols and processes. In the raw 802.11 specification, the authentication framework is provided by the authentication management frame. This management frame facilitates the open and shared-key authentication algorithms, without doing the actual authentication.

802.11i specifies the use of the IEEE's 802.1X port-based access control specification for access control and the IETF's EAP authentication framework with RADIUS as the protocol for enterprise-grade wireless authentication.

EAP is an authentication framework defined in IETF RFC 3748 and RFC 3579 that is used to authenticate supplicants. After the supplicant is authenticated, the authenticator removes the port access restrictions and the authenticated device can begin transmitting and receiving data frames.

EAP, as defined in RFCs 2284 and 3579, is an authentication framework only. There are many different authentication algorithms based on the EAP framework, defined either in other RFCs or as proprietary protocols. The following section covers EAP types in more detail.

RADIUS is the protocol used to authenticate the supplicant. EAP over RADIUS messages, as defined in RFC 2869, transport the authentication messages between the authenticator and authorization server. In RADIUS terminology, the authenticator is the Network Access Server (NAS) or RADIUS client.

Figure 4-5 illustrates the 802.11i authentication framework.

Note that 802.1X authentication has three parties:

• Supplicant: The client device requesting access to network resources.
• Authenticator: The network unit that controls access to the network. It acts as an intermediary between the supplicant and the authentication server. In the CUWN, the WLAN controller is the authenticator.
• Authentication server: Grants or denies permission to the supplicant based on the authentication algorithm and user-based access credentials. The authentication server is the RADIUS server.

Initially, the wireless station (the supplicant) establishes data link layer connectivity through the standard 802.11 open authentication. Immediately then, the authenticator blocks further wireless station access to the network.

Next, the client typically issues an Extensible Authentication Protocol over LAN (EAPoL) start message to begin the authentication process. The authenticator, the WLC, responds with an EAPoL Identity request.

In the next phase, the device identity is authenticated through an exchange of EAP and RADIUS messages. We've deliberately abstracted this phase at this point because the mechanics vary by EAP algorithm. Suffice it to say, though, that in this phase, some type of mutual authentication is necessary to establish two-way trust. The network trusts the supplicant only after it is authenticated, and the supplicant can only trust the network after it authenticates the network in some way. The supplicant cannot implicitly trust the network because some attacker could be spoofing the network elements.

Assuming success in authentication, the key management phase follows. We'll look at key management in more detail in the context of data privacy. During key management, a dynamic encryption key is negotiated for the particular session.

Now finally, after full authentication and session key derivation, the authenticator lifts the 802.1X port restrictions and the supplicant is allowed access to the network.

Authentication Algorithm

Recall in the previous sections that the authentication framework includes the use of the EAP, but the authentication algorithm performs the actual authentication of devices based on some type of credentials. The authentication algorithm is defined by an EAP type, of which there are many. Neither 802.11i nor the Wi-Fi Alliance specifies an EAP type, but the Wi-Fi Alliance currently certifies interoperability with several EAP types as part of the WPA certification tests: EAP-TLS, EAP Tunneled Transport Layer Security (EAP-TTLS), Protected EAP (PEAP), and EAP Subscriber Identity Module (EAP-SIM). Additionally, there are Cisco-developed EAP types—Lightweight EAP (LEAP) and EAP with Flexible Authentication through Secure Tunneling (EAP-FAST)—that are widely adopted.

The sections that follow cover all of these EAP types, though some in greater detail than others, starting with the Cisco-developed EAP types.

LEAP

Prior to the ratification of 802.11i and the WPA certifications, Cisco introduced a proprietary EAP type called Lightweight Extensible Authentication Protocol (LEAP). Some literature refers to LEAP as Cisco-EAP.

Initially, LEAP support was limited to Cisco Aironet–branded client cards and supplicant software. Cisco drove wide adoption of LEAP into the market through the Cisco Compatible Extensions (CCX) program by making LEAP a mandatory part of the CCX version 2 specification.

Let's look at the choreography of LEAP in Figure 4-6 because it illustrates some important things.

As shown in Figure 4-6, LEAP has several important characteristics. It includes mutual authentication and is password based. It is also lightweight in the sense that all that is really needed to deploy LEAP is support for it on the three parties of the 802.1X authentication model.

But notice also in Figure 4-6 how there is nothing in LEAP's choreography to obfuscate the mutual challenge/challenge-response messages. In 2004, a tool called ASLEAP was released that exploited weaknesses in the hashing mechanisms in those challenge/challenge-response messages to recover user credentials. ASLEAP attacks can be mitigated with strong passwords, but that adds more management overhead and isn't totally effective.

So LEAP is now deprecated and should not be used. But the wide adoption of LEAP was a watershed industry development. LEAP was the first EAP type defined specifically for WLANs. It also provided a viable alternative to WEP at a time when this alternative was desperately needed and there was not a standards-based alternative. Most importantly, it proved the viability of 802.1X with EAP as an authentication framework for WLANs before standards ratification.

EAP-FAST

EAP-FAST is an acronym for EAP with Flexible Authentication through Secure Tunneling. Cisco has published the EAP-FAST specification as IETF RFC 4851.

EAP-FAST preserves the lightweight characteristic of LEAP but provides a mechanism to protect the exchange of credentials during authentication. EAP-FAST uses something called a Protected Access Credential (PAC) as a unique shared-secret between the supplicant and server. The PAC is used during the EAP-FAST algorithm to establish a TLS tunnel that protects the exchange of user authentication messages. The tunnel establishment is called the outer authentication; the user authentication inside the tunnel is called in the inner authentication.

Figure 4-7 illustrates the EAP-FAST choreography.

During EAP-FAST Phase 0, the PAC is provisioned on the supplicant using the Authenticated Diffie-Hellman Protocol. The supplicant can subsequently securely store the PAC, obviating Phase 0 for future authentications.

During Phase 1, the PAC is used for mutual device authentication that results in a session tunnel key. This session key is used to secure the authentication exchanges in Phase 2.

Finally, in Phase 2, the user authentication is performed in the TLS tunnel established during Phase 1.

Now, it's important to note that the devil is in the details of EAP-FAST implementation. When automatic PAC provisioning is enabled, an attacker can intercept the PAC and subsequently use that to compromise user credentials.

There is also a potential attack vector, where an attacker deploys a rogue AP offering service to clients. During Phase 1, the attacker rejects the PAC during Phase 1, triggering a return to the PAC-provisioning phase. Many supplicants are configured to prompt the user to accept a new PAC. If the target in this attack accepts the new PAC, the attacker can compromise user credentials when EAP-FAST moves to Phase 2 on the rogue network. Strong rogue AP management and proper supplicant configuration mitigate this attack.

The PAC is issued on a per-user and per-authentication server basis, so if a new user logs in to the network from a device, or if a device is logging in to a part of the network serviced by a different RADIUS server, a new PAC file must be provisioned. This does present some obvious challenges from a management perspective in light of the potential attack vectors just discussed.

EAP-FAST allows manual PAC provisioning and server certificate use during the PAC provisioning phase to mitigate the threats and management challenges.

PEAP

Protected EAP (PEAP) is similar to EAP-FAST in that it establishes a TLS tunnel to protect authentication messages; however, PEAP uses a server certificate for outer authentication and to negotiate the cryptographic keys necessary for the TLS tunnel. Figure 4-8 illustrates the choreography of PEAP.

PEAP inner authentication in the TLS tunnel comes in two flavors:

• PEAP-MSCHAPv2: PEAP-MSCHAPv2 is the most common version of PEAP, so common in fact that usually when people use the term PEAP, they are referring to this version of PEAP. PEAP-MSCHAPv2 uses the Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2) for the inner authentication method.
• PEAP-GTC: GTC is an acronym for Generic Token Card, which represents the inner authentication method, which uses hardware token cards to generate one-time passwords for users.

EAP-TLS

RFC 5216 defines EAP-TLS. Like PEAP, EAP-TLS uses certificate exchanges for outer authentication in establishing a TLS tunnel. But, as shown in Figure 4-9, EAP-TLS adds client-side authentication: The client device must present a certificate that is authenticated by the server.

The power of this mutual certificate exchange is that it mitigates theoretical man-in-the-middle attacks to which other authentication types might be vulnerable.

After the mutual exchange is completed, the inner authentication takes place, leading up to the keying phase.

EAP-TTLS

RFC 5281 defines EAP-TTLS as an authentication algorithm extending the functionality of EAP-TLS to a number of legacy inner authentication methods. It is listed here for completeness because the Wi-Fi Alliance includes EAP-TTLS in its WPA interoperability certifications.

EAP-SIM

RFC 4186 defines a protocol for authentication and session key derivation through Global System for Mobile Communications (GSM) Subscriber Identity Modules (SIM) infrastructure. The choreography of EAP-SIM is out of the scope of this book but is listed because it is included in the Wi-Fi Alliance WPA test suite.

Selecting an EAP Type

After all this discussion of EAP choreography, which EAP type should you use? The answer is, it depends.

One of the decision criteria is what EAP types are supported on your client devices. At the time of this writing, the latest versions of Microsoft Windows have native support for PEAP, EAP-TLS, LEAP, and EAP-FAST (with the appropriate patches). The latest versions of Mac OS have support for LEAP, PEAP, EAP-FAST, EAP-TLS, and EAP-TTLS.

If your device's OS does not support the EAP type you select, you'll have to install additional supplicant software. You might decide to do this anyway because add-on supplicants often have additional features you want. Sometimes add-on supplicants just work better than native OS supplicants.

The other major decision factor customers wrestle with is how much management overhead to incur. Each EAP type requires some setup and maintenance, and there are usually trade-offs between manageability and security.

For example, EAP-TLS is probably the most secure of the EAP types covered; however, it's also the most difficult to manage because it requires a PKI infrastructure and certificates on every client device. You might decide that a lighter-weight authentication algorithm such as PEAP or EAP-FAST is good enough.

Data Privacy and Integrity

The previous section looked at how the 802.11i and WPA standards address the problem of missing access control and authentication in WEP. This section looks at how the standard addresses encryption key management.

Remember that with WEP, there were two big problems with key management:

• A big management challenge distributing WEP keys.
• The keys are shared between all devices in the WLAN.

The 802.11i standard addresses these problems by calling out a mechanism for dynamic encryption key generation.

Before going into detail, consider the two kinds of keys:

• Master keys: Used to generate transient keys. The master key exists as long as a supplicant's authentication is valid, so it can exist across multiple 802.11 associations.
• Transient keys: Change with each session.

The two phases of the key management process are

• Master key establishment
• Key exchange

With master key establishment, the master key is shared between station and authenticator and is subsequently used to negotiate keys that are used to encrypt data. There are two types of master keys:

• Pairwise master key (PMK): Used for unicast traffic; there is a PMK instance for each supplicant.
• Group master key (GMK): Used for multicast and broadcast traffic; group keys are shared among all stations and the AP.

When using 802.1X/EAP authentications, the PMK is established following mutual authentication between the supplicant and authentication server. Figure 4-10 illustrates the key management phase.

In Figure 4-10, you can see that following mutual authentication, the PMK is established between the supplicant and the authentication server. The supplicant and the authentication server derive the PMK separately. The authentication server then hands the PMK to the authenticator. The 802.11i specification does not dictate how the PMK is passed to the authenticator, although it does recommend EAPoL; WPA on the other hand, specifies that this must be done through RADIUS.

After the PMK is handed off to the authenticator, the supplicant and authenticator negotiate a pairwise transient key (PTK) through a cryptographic four-way handshake. As you can see in Figure 4-10, the four-way handshake begins with the authenticator and supplicant each generating a cryptographic nonce value. In the first message then, the authenticator sends its nonce to the supplicant. As shown in Figure 4-11, the supplicant uses the two nonces and the PMK to generate the PTK.

In Figure 4-10, you can see that after generating the PTK, the supplicant sends a message back to the authenticator with its own nonce and a message integrity check (MIC) that proves the supplicant knows the PMK. After verifying the MIC, the authenticator generates the PTK using the methodology shown in Figure 4-11.

The authenticator will generate a group transient key (GTK) from the GMK if necessary. The GTK is used for encrypting multicast and broadcast traffic. Figure 4-12 illustrates the process for generating the GTK.

In the third message of the four-way handshake illustrated in Figure 4-11, the authenticator sends its nonce, a MIC based on the PMK, the receive sequence counter (RSC), and the GTK. The RSC is the current sequence counter for the GTK. The GTK requires a sequence counter to prevent an attacker from replaying a broadcast message. After the supplicant verifies the MIC, it installs the PTK and GTK. It then sends the confirmation message to the authenticator that includes a MIC. After the authenticator confirms the MIC, it installs the PTK and GTK. At this point, the wireless station can begin sending and receiving data. The data is encrypted with part of the PTK.

Take a moment to revisit the generation of the GTK. Figure 4-12 illustrates the process for generating the GTK from the GMK.

An obvious question is, where does the GMK come from? The answer is that the authenticator generates the GMK. The authenticator then uses the GMK to generate the GTK. As you probably have deduced, all devices associated to an AP share the GTK. The GTK will be regenerated in the following situations:

• When a MIC failure occurs (more on that in the next section)
• When a client disassociates or is deauthenticated
• After a specified interval

When a new GTK is generated, it is sent in an encrypted message to each associated wireless station. This is a two-way handshake process, as illustrated in Figure 4-13.

You should have noticed in Figures 4-11 and 4-12 that there is both a pairwise and group key hierarchy and that this hierarchy is different for CCMP and TKIP. The sections that follow examine CCMP and TKIP in greater detail. For now, note that the PTK is made up of several keys:

• EAPoL Confirmation Key
• EAPoL Encryption Key
• Temporal Key

In the case of TKIP, the Temporal Key is actually a Temporal Encryption Key and the MICs from the four-way handshake. The Temporal Encryption Key is used in the data encryption and decryption. The EAPoL keys are used to secure transactions across the air whenever encryption keys need to be sent from the authenticator to the supplicant.

Temporal Key Integrity Protocol (TKIP)

At this point, you should understand how the standards bodies have addressed WEP deficiencies when it comes to authentication and key management. Now it's time to look at how the cryptographic flaws have been addressed. This section looks at TKIP in detail, while the next section examines CCMP.

Recall that the basic cryptographic problems with WEP centered on the following items:

• IV choice and reuse
• ICV flaws
• "Weak" RC4 keys

The design challenges before the standards bodies for TKIP were that TKIP had to "fix" the WEP cryptographic deficiencies and at the same time had to work with legacy 802.11 equipment. Basically, this meant that TKIP had to work within the mechanical framework of WEP using RC4.

The TKIP designers settled on a solution that involves three protocols to supplement WEP:

• Michael MIC
• TKIP Sequence Counter (TSC)
• Key-mixing algorithm

Michael MIC is a message integrity check mechanism to augment the WEP ICV. Remember that the WEP ICV failed to protect against bit-flipping. TKIP uses the Michael hashing algorithm instead that is not vulnerable to bit-flipping. Essentially, the Michael MIC is a hash value calculated from a 64-bit key derived from one-half of the lower-order 128 bits of the PTK (see Figures 4-11 and 4-12) and a padded MAC service data unit (MSDU) from the network layer. The padded MSDU is the MSDU with some additional fields, including the source and destination MAC addresses and some additional special octet values. This padded MSDU is used only for the Michael MIC calculation.

The Michael MIC was selected because it is computationally inexpensive. The 802.11i task group felt that this was important because the algorithm needed to run on legacy hardware with limited CPU horsepower. As such, Michael MIC is a trade-off between cryptographic strength and computational complexity. The 802.11i amendment itself calls Michael MIC "weak protection against active attacks."

So the 802.11i amendment calls out some countermeasures. Specifically, 802.11i requires that all Michael MIC failures be logged and that, in the event that two Michael MIC failures (on either the AP or the client) occur within one minute, both the station and AP are to disable all packet reception and transmission and the AP is to deauthenticate and disassociate all wireless clients. The ICV is always checked before the MIC to make it harder for an attacker to create deliberate MIC failures, which in itself could be a DoS attack.

The TKIP Sequence Counter (TSC) is used to strengthen the IV and prevent replay attacks on the system. The TSC is a 48-bit counter that starts at 0 and is incremented with each packet.

The TSC protects against replay attacks in two ways:

• Each device records the highest TSC value it has seen for a MAC address. If a packet arrives with a TSC value less than or equal to the current highest TSC value, the packet is discarded because the receiver assumes that the packet has been replayed.
• The TSC is used in the key-mixing algorithm for both encryption and decryption algorithms, so if the TSC is tampered with in transit, the ICV and MIC will fail and the packet will be discarded.

Figure 4-14 illustrates the TKIP packet format.

In Figure 4-14, you can see that the 48 bits of the TSC are split up into 6 bytes, TSC₀ through TSC₅. The low-order bytes, TSC₀ and TSC₁, are joined with a specially crafted byte to create a standard 24-bit IV that is designed to avoid FMS weak keys. Bytes TSC₂ through TSC₅ are placed in a new field called the Extended IV field. A bit is set in the Key ID byte to indicate that the Extended IV is in use. We will see shortly how all 6 bytes of the TSC are used in the key-mixing algorithm.

The TSC protects against IV reuse because a TSC is never repeated for a given key; when a new key is generated, the TSC is reset to 0. So even if an attacker were to retrieve a key stream for a packet, the key stream would be worthless.

The third protocol that TKIP introduces is a key-mixing algorithm that ensures a unique per-packet 128-bit WEP key generated from the Temporal Encryption Key (TEK). As shown in Figures 4-11 and 4-12, the TEK is the high-order 128-bits of the PTK.

Figure 4-15 illustrates the TKIP key-mixing algorithm.

In Phase 1, the most significant 32 bits of the TSC are "mixed" with the transmitter's 48-bit MAC address and the high-order 80 bits of the TEK. The output is an 80-bit TKIP Transmit Address and Key (TTAK).

The TTAK is "mixed" with the entire TEK and TSC in Phase 2. The output is a 128-bit WEP key that is used to seed the RC4 keystream generator. The first 24 bits of the 128-bit key are the IV constructed from the least significant TSC bytes and the specially crafted byte, as shown previously in Figure 4-14.

TKIP provides strong protection, but the 802.11i task group wanted to do better. Particularly important was to have a solution that satisfies the U.S. government FIPS-140-2 certification requirements and that calls for AES encryption. That solution is CCMP.

Counter/CBC-MAC Protocol (CCMP)

CCMP is the strongest confidentiality, integrity, and replay protection protocol suite available for WLAN security. It is based on AES and is the core of the 802.11i RSN and the WPAv2 specification. CCMP is thus the preferred solution if all the WLAN devices in the system can support it.

An in-depth discussion of AES is beyond the scope of this chapter. We will just look at it in the abstract as it is applied to CCMP. The Counter part of the CCMP name is from an AES counter mode that provides the data privacy. The CBC-MAC part of the name comes from the Cipher Block Chaining Message Authentication Code that is used as a message integrity check.

WEP and TKIP rely on the RC4 stream cipher for encryption. In contrast, AES is a block cipher. A block cipher operates on chunks of data as opposed to a stream of bytes.

Figure 4-16 illustrates how AES counter mode works to encrypt plain text.

The plain text is chopped into 128-bit chunks. A 128-bit counter is AES encrypted and then XORed with the first 128-bit chunk of plain text. The counter is then incremented and the process repeated on the next 128-bit chunk. The process is repeated until the entire plain text is exhausted. Then the 128-bit chunks of cipher text are concatenated to produce the full encrypted text.

Now, the decryption of this encrypted text is really simple. The decrypting entity chops up the encrypted text into 128-bit chunks. It then uses the same algorithm shown in Figure 4-16, starting with the same counter value. But instead of XORing the encrypted counters with plain text, the encrypted counters are XORed with the 128-bit chunks of cipher text. The output is the decrypted chunks of plain text. These chunks are then reassembled as the full plain-text message.

Figure 4-17 illustrates the AES CBC-MAC mode.

As you can see from Figure 4-17, the plain text is again broken into chunks. The first chunk is AES encrypted to produce a chunk of cipher text. This chunk of cipher text is then XORed with the next block of plain text and then AES encrypted. The process is then repeated until the plain-text chunks are exhausted. The final value is the MIC.

So now that you understand the mechanics of the CCM algorithm, the next step is to see how it is applied. Figure 4-18 shows the CCMP packet format.

What you'll notice is that this looks a lot like the TKIP packet format. Instead of the TSC, though, CCMP uses a 48-bit packet number (PN) that is split into two parts. The Extended IV bit is also set in the KeyID field.

The MIC is a 64-bit value computed with CBC-MAC mode. The plain-text input into the CBC-MAC mode is the plain-text data plus the parts of the MAC header that cannot be changed in the event of a retransmission. The parts of the MAC header included in the MIC calculation are called the Additional Authentication Data (AAD).

Figure 4-19 shows the CCMP encapsulation process.

You've already seen how the CCM algorithm encrypts the data using AES counter mode and computes the MIC through CBC-MAC. The encryption key input into the AES encryption algorithm is the CCMP Temporal Key derived from the PTK.

Remember that AES counter mode needs a counter value that is unique per packet. This counter value is the nonce shown in Figure 4-19. The nonce is assembled from the priority and source address fields from the MAC header and the packet number.

Figure 4-20 shows the CCMP decapsulation process.

When a packet is received, the receiver extracts the PN and compares it against the value it has stored. If the PN has increased, the receiver knows that the packet has not been replayed.

The receiver knows the CCMP Temporal Key and can compute the nonce from the MAC and CCMP headers. It can then run the AES counter mode algorithm to decrypt the cipher text. As we've already seen, AES counter mode decryption is essentially the same as AES counter mode encryption, except that the operations are performed on the cipher text.

The MIC is then computed and compared to the decrypted MIC value to verify that the packet has not been tampered with.

Alternative Approaches to Authentication and Data Privacy

There are, of course, alternative approaches to WPA/WPAv2 Enterprise. A full 802.1X/EAP authentication solution is overkill for most home and many small-office WLAN implementations. The IEEE standards and WFA committees recognized this from the beginning and so allow an implementation using pre-shared keys (PSK). In a PSK implementation, there is a shared secret—the pre-shared key (PSK)—between the wireless station and authenticator. This shared secret is used as a passphrase to negotiate per-session encryption keys with the authenticator, as described in the key management sections.

We'd be remiss if we didn't at least mention overlay options as an approach to securing WLANs. Overlays typically allow 802.11 open authentications to the wireless network and leverage back-end mechanisms for user authentication and data privacy and to protect networked resources. Some customers, usually universities, don't bother with user authentication and data privacy, treating the WLAN as a public resource.

Some WLAN implementers simply don't trust anything other than VPNs, or for some reason cannot or won't implement 802.1X authentication. Typically, VPN solutions treat the 802.11 network as completely untrusted, treating the WLAN as a logically separate entity from the rest of the network. Usually, the WLC is firewalled off from the rest of the network and the APs reside on their own VLAN infrastructure. Traffic aggregated at the controller is directed to the VPN concentrator. You can see how this creates a lot of complexity in the wired network, which is why VPN overlay solutions have mostly been deprecated in favor of the wireless standards-based approaches.

Another overlay variant is to use browser redirects for web authentication, either through the native capabilities on the controller or through an external web-authentication box. These architectures were discussed in the context of guest access.

Rogue Access Point Detection and Wireless Intrusion Prevention

Remember the earlier discussion of rogue access points and devices and the other potential vulnerabilities presented by readily available profiling and attack tools? A comprehensive wireless security approach usually requires some type of rogue device detection and wireless intrusion prevention system (WIPS).

The most crude detection technique is "sneaker net." An IT staffer laces up his or her "sneakers" and walks the campus with a WLAN sniffer or other reconnaissance tools, looking for unauthorized wireless devices and potential attackers. This isn't a bad approach for small deployments, where it's usually pretty effective and good exercise too!

However, sneaker net just doesn't scale to a large or geographically dispersed deployment. Furthermore, it's pretty easy to defeat and pretty low yield for the amount of effort. One large enterprise we frequently work with used sneaker net to find rogues. At first, the IT staff found the sneaker net technique pretty effective. But after a few months, they began to find the technique was pretty much good only as physical exercise. It was a lot of effort for a pretty low yield; they rarely found rogues but still suspected there were many of them out there connected to their network.

After reevaluating their approach, they decided to take advantage of embedded rogue detection and location capabilities in their Cisco WLAN. Sure enough, as soon as they began using the embedded tools, many rogues were identified and located. One of the employees guilty of rogue deployments confessed that he had figured out the IT staff's rogue hunting schedule and simply removed the rogue until the IT staffer walked by!

All modern WLAN vendors including Cisco implement over-the-air rogue detection and WIPS using the entire WLAN system. Typically this involves sampling the RF environment at the AP radio interfaces and applying higher-level forensic analysis at the WLC or management software. For WIPS, this involves comparing traffic patterns against signatures that profile known attacks. For rogue AP detection, this involves collecting 802.11 beacons from the environment and culling out the beacons that are sourced from devices not belonging to the WLAN system. Can you see the problem with this approach, though?

We've run a WLAN sniffer in the Cisco office in midtown Manhattan and identified upwards of 350 different WLAN networks by simply capturing beacons. Each of these networks is probably a legitimate network belonging to someone. The beacons are just propagating out of their coverage area. You should be able to see that separating real rogues from other legitimate 802.11 networks is nontrivial, especially if you're trying to make the classification manually.

Cisco has tools that give you pretty granular location of rogue APs, and this is pretty helpful in classifying true rogues. Cisco has also implemented algorithms for identifying rogue devices as connected to the wired network and tracing the rogue to an actual switchport. When you can determine that a rogue AP is connected to your network, you can be pretty certain that it is in fact a rogue AP.

After you classify an AP as a rogue, Cisco gives you tools to suppress the rogue. The most effective of these techniques allows you to shut off the switchport the rogue is connected to. Essentially, this renders most rogues useless. Cisco also has the ability to do over-the-air containment. When the WLAN system sees legitimate wireless clients connecting to a rogue, 802.11 deauthentication frames with the rogue MAC source spoofed are sent to the client.

The CUWN has two tiers of offerings. Figure 4-21 shows the base-level rogue AP and WIPS solution.

In this base solution, the APs sample the environment during normal operation. APs have on-board WIPS signatures that, when triggered, create alerts that get forwarded through the WLC to WCS, where logic and rules are applied.

As far as rogue AP detection is concerned, the WLC collects sampled data from the APs and identifies potential rogue devices. The WCS takes this information and applies classification logic. After it is classified, the network administrator can initiate rogue AP containment strategies.

Figure 4-22 shows the more sophisticated solution with Cisco Adaptive WIPS running on the Mobility Service Engine (MSE) platform.

This more advanced solution contains a superset of the base solution's functionality. There are more signatures and a more accurate and sophisticated classification engine running on the MSE. Also, this solution potentially uses dedicated monitor mode APs, dedicated to sampling the air, so there is significantly more data for the system to work with.

Further details on rogue AP management and WIPS are a chapter unto themselves. Furthermore, at the time of this writing, the details and nuances of both solutions were under analysis and discussion by the Cisco engineering teams, so any details we might include now might be obsolete when you read them. We suggest you work closely with your Cisco representatives for the details if you're interested in these topics.

Secure Management and Security Policies

It's always important to remember that any device in a network can be attacked. WLAN infrastructure devices are no different in this respect than routers and switches. It's always a good idea to follow sensible secure management practices.

A discussion on secure management practices is a chapter unto itself. We won't spend much time on it. Basically, you should try to follow these general security recommendations:

• Use centralized authentication and authorization (TACACS+ for example) for administrative device access if possible.
• Select secure management protocols such as SSH, HTTPS, and SNMPv3 over insecure protocols such as Telnet, HTTP, SNMPv1, and SNMPv2, if possible.
• When you can't use centralized authentication and authorization and/or secure management protocols, try to find other ways of securing access. For example, use obscure and strong passwords and SNMP community strings. You can also use access control lists (ACL) to restrict management access to specific hosts.
• Disable all unnecessary services on WLAN devices.
• Limit management connectivity to specific platforms using ACLs or an equivalent mechanism.

This is obviously not a comprehensive list, but you get the idea. There are some good papers referenced at the end of the chapter that will help you with secure management practices.

Protecting WLAN client devices is fundamentally a desktop management problem. The best thing you can do is make sure that your mobile users are running host-based security solutions like personal firewalls and maintaining current antivirus software. Furthermore, you can eliminate many of the problems related to misconfigured wireless clients by preprovisioning supplicant profiles for your end users. There's a little bit more work up front, but it's definitely worth it.

It's always a good idea to periodically audit your WLAN configurations to be sure that there aren't any unintentional security holes. Cisco offers tools to periodically check AP configurations and provide alerts when security policies are violated. The CUWN enforces security policies at the controllers, so policy monitoring and enforcement are de facto parts of the architecture.