Are you worried about the security of your 802.11b wireless local area network (WLAN) because you're using plain-old wired equivalent privacy (WEP)? If you're still relying on WEP alone, you should be nervous: venerable and well-known vulnerabilities in WEP make it simple for eavesdroppers to crack your WEP keys simply by capturing a few hours' worth of WLAN packets and brute-forcing the flawed encryption used by WEP.

But there's hope! Wi-Fi protected access (WPA) adds new authentication mechanisms and improved encryption key generation to 802.11b, and WLAN products supporting WPA have become readily available. Better still, Linux tools are available for WPA supplicants (client systems), authenticators (access points) and servers (RADIUS authentication servers).

In the next couple of columns, I describe WPA and its component protocols, how they interoperate and how to build a Linux-based WLAN authentication server using the FreeRADIUS server-software package.

So, what's wrong with 802.11b security in the first place? In a nutshell, 802.11b's WEP protocol has two fatal flaws. First, cryptographic-implementation flaws make it impossible to achieve encryption key strength effectively higher than 40 bits, even if your gear supports higher key lengths. Second, a weakness in WEP's encryption key derivation implementation makes it possible for an attacker to derive a WEP-protected network's WEP secret key—the encryption key used by all clients on the entire WLAN—after capturing a sufficient number of packets.

The pending 802.11i protocol will provide a complete, robust security framework for WLANs. Even after it's finalized, however, it will be some time before this protocol is available widely in commercial products or free software packages.

Enter WPA. WPA adds two crucial components of 802.11i to 802.11b. First, it adds the 802.1x authentication protocol, which provides flexible and powerful authentication capabilities. Second, it adds the TKIP protocol, which provides mechanisms for assigning unique WEP keys to each WLAN client and then dynamically re-negotiating them, such that WEP's key derivation vulnerability effectively is mitigated.

Figure 1. WPA Topology

Figure 1 shows how the various pieces of a WPA system interact. First, we have a WLAN-enabled client system, whose WPA client software is called a supplicant. The client/supplicant connects to a wireless access point (AP), which serves as an authenticator, effectively proxying authentication between the supplicant and a back-end authentication server. In Figure 1, this back-end server is portrayed as a RADIUS server, but TACACS also can be used.

Besides proxying authentication between supplicant and server, the AP/authenticator also feeds data from the authentication server through the Temporal Key Integrity Protocol (TKIP) to obtain a WEP session key. It then pushes the key back to the supplicant. The supplicant periodically is prompted to re-authenticate itself, at which time its WEP key is replaced by a new one.

The authentication (RADIUS) server is optional. Another option is to use pre-shared key (PSK) mode, in which shared keys unique to each WPA supplicant system manually are entered into the AP and used for authentication in lieu of RADIUS. This is better than WEP by itself, because this shared key is not used as an encryption key itself. Rather, it is used to seed TKIP transactions, which in turn provide dynamic WEP keys.

WPA already is supported by a wide variety of new commercial WLAN adapters and access points. It's even been back-ported to some older 802.11b products, thanks to firmware upgrades. In the Linux world, it's supported on the client side by wpa_supplicant (hostap.epitest.fi/wpa_supplicant), on Linux access points by hostapd (hostap.epitest.fi/hostapd) and on the authentication server side by FreeRADIUS (www.freeradius.org).

Before we narrow our focus to building a WPA-ready FreeRADIUS server, which mainly will be covered in my next column, let's look more closely at the authentication and encryption portions of WPA.

Are you following me? Because WPA actually is a bit more complicated than Figure 1 implies. To review: in WPA, your client system (supplicant) must authenticate itself to the network before being allowed to connect, at which point it's provided with a session encryption key that changes periodically.

The reason this gets complicated is the 802.1x protocol used for WPA authentication allows for a variety of methods to authenticate supplicants, which is a good thing. By using a modular, extensible authentication mechanism, the odds are reduced that WPA—or 802.1x or 802.11i—will be made obsolete as particular authentication protocols go in and out of favor. 802.1x's modularity and extensibility is provided, appropriately enough, by the Extensible Authentication Protocol (EAP), of which a number of variants exist. Let's talk about a few of the most popular ones.

So Many Protocols!

One of the reasons I'm devoting an entire column to describing how WPA works, rather than simply diving into how to configure FreeRADIUS for WPA, is the myriad protocols and sub-protocols that comprise WPA can be confusing. If you're having trouble keeping all this straight, maybe Figure 2 can help; it shows WPA's protocols in hierarchical form.

Figure 2. WPA Protocols

EAP-MD5 uses a simple MD5-hash-based credentials exchange. The supplicant provides a username and MD5-hashed password to the server, and the server compares these to its own database. Unfortunately, an eavesdropper can capture the hash transmitted by a WPA supplicant and run an off-line dictionary attack against the hash to deduce the password used to create it. Also, although EAP-MD5 authenticates the supplicant to the server, it doesn't do anything to authenticate the server to the user, for example, with server certificates, à la SSL. EAP-MD5 therefore is a poor choice for 802.1x authentication in WPA contexts.

EAP-TLS uses the TLS encryption protocol, a descendant of SSL, as a basis for authentication. On the one hand, this is a strong authentication method: it requires both the authentication server and its users to have digital certificates, which are the basis of authentication transactions. Issuing digital certificates to a large number of users and managing those certificates, however, can be complex and time consuming. Consider, for example, the time required to revoke certificates of people who leave your organization. Also, EAP-TLS generally requires a complete public key infrastructure (PKI) environment, which few small-to-medium organizations are comfortable supporting. Also, when authentication is initiated, user names are transmitted in clear text, a small but noteworthy exposure.

PEAP (Protected EAP) was developed primarily by Microsoft as a means of using TLS encryption to protect weaker but simpler authentication methods, such as MD5 and MS-CHAP. With PEAP, an encrypted channel is established between supplicants and the server before any credentials are exchanged. This is consistent with the way most Web applications use TLS. That is, they use TLS to establish an encrypted tunnel over which simple user name-password authentications safely can be performed, without going so far as to use TLS's more secure but more complicated client-certificate authentication mechanism. The main disadvantage of PEAP is its Microsoft-centricity. Although some free software tools do support PEAP, many people see no incentive for Microsoft to ensure interoperability with other vendors' WPA products or platforms.

EAP-TTLS is, essentially, a non-Microsoft-driven alternative to PEAP. It involves establishing an encrypted TLS tunnel over which either TLS-based or other (weaker) forms of authentication are conducted. Its main advantage over PEAP is being less subject to the whims of one large corporation. It also presently supports a slightly wider range of authentication methods, although PEAP is designed to support more methods than have been implemented thus far. Lacking Microsoft's muscle, some people see EAP-TTLS as not having as much momentum as PEAP.

Other EAP variants include EAP-SIM, Microsoft's EAP-MSCHAPv2 and Cisco's Lightweight EAP (LEAP).

At this point, you might be wondering, “Hey, isn't RADIUS an authentication protocol too? How does that fit in?” RADIUS is the protocol your authenticator (AP) speaks to your authentication server. In the context of 802.1x and WPA, you can think of RADIUS as the transport over which your authenticator forwards EAP messages to your server. Put another way, your end-user's supplicant speaks EAP to your authenticator; your authenticator forwards those messages within RADIUS packets sent to your server.

There's still another protocol at play here, playing a similar role in supplicant-authenticator communications: EAPOL, or EAP Over LANs. This protocol is completely transparent, however, because it's built in to supplicant and authenticator software and requires no configuration of its own. Therefore, there's nothing specific you need to know or understand about EAPOL unless you write WPA software.

From the time a supplicant initiates its connection attempt to the AP, your AP allows only EAP traffic. Only after authentication has completed successfully, based on the server's response, is your supplicant system given a DHCP lease and permitted to connect completely to the WLAN. Another consequence of successful authentication, however, is the assigning of a WEP key to the supplicant.

If a supplicant is authenticated by way of EAP-TLS or some other encrypted version of EAP, that authentication traffic also is encrypted. But the wireless LAN frames themselves are not; that can't happen until WEP is enabled on the connection between the supplicant system and the access point. As it happens, from the implementor's standpoint, this is the simplest part of WPA. Upon successful authentication, the server, authenticator and supplicant use the Temporal Key Integrity Protocol (TKIP) to negotiate and transmit WEP keys securely for use between the authenticator and the supplicant system. This process largely is transparent: you do not need to configure anything on the server or supplicant for this to work. However, most access points, including hostapd on Linux, can be configured with custom settings for things such as WEP-re-keying interval.

The other thing to remember about TKIP is, as I mentioned earlier, the server is optional. If you've configured your supplicants and authenticator to use pre-shared key (PSK) mode, TKIP still is used to key and re-key WEP encryption dynamically between your supplicant and access point.

That's WPA in a nutshell. Next time, we'll apply these concepts of using FreeRADIUS to create a Linux-based authentication server for WPA. If you can't wait until then to get started, check out the on-line Resources for more information. Be safe!

Resources for this article: /article/8070.