Key Caching | 802.1X, EAP, and Centralized Authentication

Because the work required establishing a PMK when 802.1X and RADIUS are used is significant, WPA2 provides for a way for the PMK to be cached for the client to use, if it should leave the access point and return before the PMK expires.

This is done using key caching. Key caching works because each PMK is given a label, called a PMKID, that represents the name of the RADIUS association and the PMK that was derived from it. The PMKID is specifically a 128-bit string, produced by the function

where AA is the BSSID Ethernet address, SPA is the Ethernet address of the client, and HMAC-SHA1-128 is the first 128 bits of the well-known SHA1-based HMAC function for producing a cryptographic one-way signature with the PMK as the key. The double-pipes ("∥") represent bitwise concatenation. The "PMK Name" ASCII string is used to prevent implementers from putting the wrong function results in the wrong places and having it work by accident.

From this, it is pretty clear to see that a client and access point can share the same PMKID only if they have the same PMK and are referring to each other.

When the client associates, it places into its Reassociation message's RSN information element (Table 5.16) the PMKID it may have remembered from a previous association to the access point. If the access point also remembers the previous association, and still has the PMK, then the access point will skip starting 802. IX and will proceed to sending the first message in the four-way handshake, basing it on the remembered PMK.

This caching behavior is not mandatory, in the sense that either side can forget about the PMK and the connection will still proceed. If the client does not request a PMKID, or the access point does not recognize or remember the PMKID, the access point will still send an EAP Request Identity message, and the 802.1X protocol will continue as if no caching had taken place.

802.1X | Wi-Fi Radio Types

802.1X, also known as EAPOL, for EAP over LAN, is a basic protocol supported by enterprise-grade Wi-Fi networks, as well as modern wired Ethernet switches and other network technologies. The idea behind 802.1X is to allow the user's device to connect to the network as if the RADIUS server and advanced authentication systems did not exist, but to then block the network link for the device for all other protocols except 802. IX, until authentication is complete. The network's only requirements are twofold: prevent all data traffic from or to the client except for EAPOL (using Ethernet protocol 0×888E) from passing; and taking the EAPOL frames, removing the EAP messages embedded within, and tunneling those over the RADIUS protocol to the AAA server.

The job of the network, then, is rather simple. However, the sheer number of protocols can make the process seem complex. We'll go through the details slowly. The important thing to keep in mind is that 802.1X is purely a way of opening what acts like a direct link between the AAA server and the client device, to allow the user to be authenticated by whatever means the AAA server and client deem necessary. The protocols are all layered, allowing the highest-level security protocols to ride on increasingly more specific frames that each act as blank envelopes for its contents.

Once the AAA server and the client have successfully authenticated, the AAA server will use its RADIUS link to inform the network that the client can pass. The network will tear down its EAPOL-only firewall, allowing generic data traffic to pass. In the same message that the AAA server tells the network to allow the client (an EAP Success), it also passes the PMK—the master key that the client also has and will be used for encryption—to the network, which can then drop into the four-way handshake to derive the PTK and start the encrypted channel. This PMK exchange goes in an encrypted portion of the EAP response from the RADIUS server, and is removed when the EAP Success is forwarded over the air. The encryption is rather simple, and is based on the shared password that the RADIUS server and controller or access point have. Along with the PMK comes a session lifetime. The RADIUS server tells the controller or access point how long the authentication, and subsequent use of the keys derived from it, is valid. Once that time expires, both the access point and the client are required to erase any knowledge of the key, and the client must reauthenticate using EAP to get a new one and continue using the network.

For network administrators, it is important to keep in mind that the EAP traffic in EAPOL is not encrypted. Because the AAA server and the client have not agreed on the keys yet, all of the traffic between the client and the RADIUS server can be seen by passive observers. This necessarily limits the EAP methods—the specific types of authentication—that can be used. For example, in the early days of 802.1X, an EAP method known as EAP-MD5 was used, where the user typed a password (or the client used the user's computer account password), which was then hashed with the MD5 one-way cryptographic hash algorithm, and then sent across the network. Now, MD5 is flawed, but is still secure enough that an attacker would have a very hard time reverse-engineering the password from the hash of it. However, the attacker wouldn't need to do this, as he could just replay the same MD5 hashed version himself, as if he were the original user, and gain access to the network. For this reason, no modern wireless device supports EAP-MD5 for wireless authentication.

What is Authentication in 802.1X?

Let's first define exactly what authentication is, and what the technology expects out of the authentication process. We've mentioned credentials immediately preceding this section. An authentication credential is something that one party to communication has that the other parties can use to verify whether the user is really who he claims he is and is authorized to join the network.

In the preshared key case, the authentication credential is just the preshared key, a global password that every user shares. This is not very good, because every user appears identical, and there is no way for users to know that their networks are also authentic. Authentication should be a two-way street, and it is important for the clients to know that the network they are connecting to is not a fraud. With preshared keys, anyone with the key can set up a fraudulent rogue access point, install the key, and appear to be real to the users, just as they can arbitrarily decrypt over-the-air traffic.

Normal computer account security, such as what is provided by email servers, enterprise personal computers, and Active Directory (AD) networks, generally uses the notion that a user has a unique, secret password. When the user wants to access the network, or the machine, or the email account, she enters her password. If this password matches, then the user is allowed in. Otherwise, he or she is not.

(In fact, to prevent the system administrators from having access to the user's password, which the user might use in other systems and might not want to share, these systems will record a cryptographically hashed version of the password. This version, such as the MD5-hashed one mentioned in the next section, prevents anyone looking at it from knowing what the original password is, yet at the same time allows the user to type their password at any time, which leads to a new MD5-hashed string that will be identical to the one recorded by the system if and only if the passwords are identical.)

This identifies the user, but what about the network, which can't type a password to prove itself to the user? More advanced authentication methods use public key cryptography to provide more than a password. The background is quite simple, however. Public key cryptography is based on the notion of a certificate. A certificate is a very small electronic document, of an exact and precise format, containing some basic information about the user, network, or system that the certificate represents. I might have a certificate that states that it is written for jepstein@somecompany.com, pretending for a moment that that is the name of my user account at some company. The network might have a certificate that states it is written for network.somecompany.com, using the DNS name of the server running the network. To ensure that the contents of the certificate are not downright lies made up in the moment, each certificate is signed using another certificate, that of a certificate authority who both parties need to trust in advance. Finally, each certificate includes some cryptographic material: a public key, that is shouted out in the certificate, and a private key, which the owner of the certificate keeps hidden and tells no one. This private key is like a very big, randomly generated password. The difference is that the private key can be used to encrypt data that the public key can decrypt, and the public key can be used to encrypt data that the private key can decrypt. This allows the holder of the certificate to prove his or her identity by encrypting something using his or her private key. It also allows anyone else in the world to send the holder of the certificate a private message that only the holder can decrypt.

Certificates are necessary for network authentication. When the user tries to authenticate to the network, the network will prove its identity by using its private key and certificate, and the client will accept it only if the network gives the right information based on that certificate. Certificates are also useful for user authentication, because the same properties work in reverse. The EAP method known as EAP-TLS requires client certificates. Most of the other Wi-Fi-appropriate EAP methods use only server certificates, and require client passwords instead.

To recap, authentication over Wi-Fi means that the user enters a password or sends his certificate to the AAA server, which proves his identity, while the network sends its certificate to the client, whose supplicant automatically verifies the network's identity—just like how web browsers using HTTPS verify the server's identity.

It is the EAP method's job to specify whether passwords or certificates are required, how they are sent, and what other information may be required. The EAP method also is required to allow the AAA server and the client to securely agree to a master key—the PMK—which is used long after authentication to encrypt the user's data. The EAP method also must ensure that the authentication process is secure even though it is sent over an open, unencrypted network, as you will see in the following section on 802.1X.

The administrator is allowed to control quite a bit about what types of authentication methods are supported. The AAA administrator (not, you may note, the networkadministrator, unless this is the same person) determines the EAP methods, and thus the certificate and authentication requirements. The AAA administrator also chooses how long a user can keep network access until he or she has to reauthenticate using EAP. The network administrator controls the encryption algorithm—whether to use WPA or WPA2. Together, the two administrators can use extensions to RADIUS to also introduce network access policies based on the results of the AAA authentication.

802.1X, EAP, and Centralized Authentication | Security for 802.11

Wi-Fi's self contained security mechanisms. With WPA2, the encryption and integrity protection of the data messages can be considered strong. But we've only seen preshared keys, or global passwords, as the method the network authenticates the user, and preshared keys are not strong enough for many needs.

The solution is to rely on the infrastructure provided by centralized authentication using a dedicated Authentication, Authorization, and Accounting (AAA) server. These servers maintain a list of users, and for each user, the server holds the authentication credentials required by the user to access the network. When the user does attempt to access the network, the user is required to exercise a series of steps from the authentication protocol demanded by the AAA server. The server drives its end of the protocol, challenging the user, by way of a piece of software called a supplicant that exists on the user's device, to prove that the user has the necessary credentials. The network exists as a pipe, relaying the protocol from the AAA server to the client. Once the user has either proven that she has the right credentials—she apparently is who she says she is—the AAA server will then tell the network that the user can come in.

The entire design of RADIUS was originally centered around providing password prompts for dial-up users on old modem banks. However, with the addition of the Extensible Authentication Protocol (EAP) framework on top of RADIUS, and built into every modern RADIUS server, more advanced and secure authentication protocols have been constructed. See Figure 1.

 
Figure 1: The Components of RADIUS Authentication over Wi-Fi

The concept behind EAP is to provide a generic framework where the RADIUS server and the client device can communicate to negotiate the security credentials that the network administrator requires, without having to concern or modify the underlying network access technology. To accomplish this last feat, the local access network must support 802.1X.

Wi-Fi Link Security

To summarize, 802.11 security is provided by three different grades of technology: the outdated and broken WEP, the transition-providing WPA, and the secure and modern WPA2.

WPA and WPA2 are both built on the same framework of 802. Hi, which provides a rich protocol for 802.11 clients and access points to communicate and negotiate which over-the-air encryption and integrity algorithms should be used.

Networks start off with a master key—either a preshared key, entered as text by the user into the access point and mobile device, or generated in real time by enterprise-grade authentication systems. This master key is then used to derive a per-connection key, called the PTK. The PTK is then used to encrypt and provide integrity protection for each frame, using either TKIP for WPA or AES for WPA2.

It bears repeating that preshared keys, for all grades of 802.11 security, have problems that cause both security and management headaches. The biggest security headache is that the privacy of the entire network is based on that PSK being kept private for eternity. If a PSK is ever found out by an attacker—even if that key has been retired or changed a long time ago—then the attacker can use that key to decrypt any recordings of traffic that were taken when the PSK had been in use. Furthermore, because preshared keys are text and are common for all devices, they are easy to share and impossible to revoke. Good users can be fooled into giving the PSK away, or bad users—such as employees who have left the organization—can continue to use the preshared keys as often as they desire.

These problems are solved, however, by moving away from preshared keys to using 802.1X and EAP. Recently, some vendors have been introducing the ability to create per-user preshared keys. The advantage of having per-user keys is that one user's access can be revoked without allowing that user to compromise the rest of the network. The problem with this scheme, however, is the continued lack of forward secrecy, meaning that a user who has his password stolen can still have decrypted every packet ever sent or will send using that key. For this reason, 802.1X is still recommended, using strong EAP methods that provide forward secrecy.

WPA2 and AES | Security for Wi-fi Radio

WPA2 introduces a new encryption algorithm, using the Advanced Encryption Standard (AES). This cipher was produced to be used as a standard algorithm wherever encryption is needed.

AES is a block cipher, unlike RC4. A block cipher takes blocks of messages—fixed chunks of bytes—and encrypts each block, producing a new block of the same size. These are nonlinear ciphers, and so the bit-flip attacks are significantly harder. AES was specifically designed and is believed to be practically impervious to those styles of attacks. With block ciphers, each block starts off independently, a bit of a downside compared to stream ciphers. To remove that independence, WPA2 also uses what is called Counter mode, a simple concept where later blocks are made to depend on previous blocks.

The MIC used is also based on AES, but is used as a cryptographic hash. This use is called cipher block chaining (CBC), and essentially uses the same concept of making later blocks depend on earlier ones, but only outputting the last block as the result. This small block (128 bits) is dependent on every bit of the input, and so works as a signature, or hash.

The overall algorithm used is known as Counter Mode with Cipher Block Chaining-Message Authentication Code (CCMP).

Table 1 shows the frame body used with WPA2. As with WPA, WPA2 has essentially the same expanded IV. Because WPA2 isn't using TKIP, the name has been changed to the packet number (PN), but serves the same purpose, starting at 0 and counting up. The PN is used for replay detection, as well as ensuring per-frame keying. The MIC is also eight bytes, but uses CBC-MAC rather than Michael. With new hardware, the last vestige of WEP can be dropped, and the old ICV is removed.

Table 1: 8.02.11 Fram Body with WPA2 

PN = IV	Data	MIC
8 bytes	n—8 bytes	8 bytes

Because the WPA2 MIC is considered to be cryptographically strong, the designers of WPA2 eliminated the countermeasures that WPA has. It is still true that no frame should come in with an invalid MIC; however, the administrator can be alerted to deal with it in his own time, as there are not any known exploits that can be successfully mounted against WPA2 using an invalid MIC to date.

WPA and TKIP | Security for 802.11

TKIP was designed to run on WEP hardware without slowing the hardware down significantly. To do this, TKIP is a preprocessing step before WEP encryption. RC4 is still the encryption algorithm, and the WEP CRC-32 could not be eliminated. However, TKIP adds features into the selection of the per-frame key, and introduces a new MIC to sit beside the CRC-32 and provide better integrity.

The first change is to expand the IV and key ID fields to eight bytes total (see Table 1). The expanded fields gives a six-byte IV, now called the TKIP sequence counter(TSC). The goal is to give plenty of room so that the TSC nearly never needs to wrap. Furthermore, if it does get close to wrapping, the client is required to renegotiate a new PTK. This prevents key reuse. Finally, the TSC is used to provide the replay protection missing in WEP. The TSC is required to go up by one for each message. Each side keeps the current TSC that it is sending with, and the one it last received successfully from the other side. If a frame comes in out of order—that is, if it is received with an old TSC—the receiver drops it. An attacker can no longer replay valid but old frames. And, of course, although it can try to invent new frames, even with higher TSCs, the receiver won't update the last good TSC unless the frame is decryptable, and it will not be because the attacker does not know the key.

Table 1: 8.02.11 Fram Body with WPA 

Expanded IV	Data	MIC	ICV
8 bytes	n - 8 bytes	8 bytes	4 bytes

The second change is to come up with a better way of producing the per-frame key. The per-frame key for TKIP uses a new algorithm that takes into account not only the now larger IV and the PTK, but the transmitter's address as well. This algorithm uses a cryptographic device known as an S-box to spread out the per-frame key in a more even, random-looking pattern. This helps avoid the problems with weak RC4 per-frame keys, which were specific WEP per-frame keys that caused RC4 to leak information. The result of this algorithm is a brand new per-frame key for each frame, which avoids many of the problems with WEP.

Unfortunately, the underlying encryption is still WEP, using a linear cipher vulnerable to bit flipping. To catch more of the bit flips, a new, cryptographically "better" MIC was needed. WPA uses Michael, a special MIC designed to help with TKIP without requiring excessive computation. It is not considered to be cryptographically secure in the same sense as is WPA2, but is considered to be significantly better than CRC-32, and thus can be used to build secure networks with some caveats. In this case, the designers were aware of this limitation up front, and designed Michael to be good enough to provide that transition from WEP to something more secure down the road (which became AES).

The Michael MIC is not just a function of the data of the packet. It also depends on the sender's address, the receiver's address, and the priority of the packet, as well as the PTK. Michael is designed to avoid the iterative guessing and bit flipping that WEP is vulnerable to. Furthermore, it is based on the entire frame, and not just individual fragments, and so avoids some fragmentation attacks that can be used against WEP. The result of Michael is the eight-byte MIC, which is placed at the end of the frame before it is sent for WEP encryption.

Because the designers know that Michael isn't enough, they also built in a provision for detecting when an attack is under way. Attackers try to modify frames and submit them, and see if the modified frames get mistaken as being authentic. Most of the time, they fail, and these modified frames are not decryptable. With WEP, a nondecryptable frame is silently dropped, with no harm. However, a frame with a bad MIC should never happen in a properly functioning system, and is a sign that the network is under attack. To help prevent these attacks from being successful, WPA adds the concept of countermeasures. If two frames with bad MICs (but good FCSs, so that we know they are not corrupted by radio effects) are received in a 60-second interval, the access point kicks all of the clients off and requires them to renegotiate new keys. This drastic step introduces a painful denial-of-service vulnerability into TKIP, but is necessary to prevent attackers from getting information easily. Of course, having countermeasures doesn't increase the robustness of the underlying algorithms, but kicking off all of the clients ensures that the attacker has to start from scratch with a new PTK.

Overall, TKIP was an acceptable bridge from WEP to WPA2. The designers rightfully recognize that TKIP is itself flawed, and is subject to a few vulnerabilities of its own. Besides the obvious denial-of-service attacks, TKIP also still allows for attacks that attempt to guess at certain parts of the particular messages and make some minor, but arbitrary, alterations to the packets successfully. Although workarounds exist for these types of attacks, TKIP will never be entirely hassle-free.

Therefore, I recommend that you migrate to WPA2 for every device on the network.