Product Focus

Essential Wi-Fi

802.11 Security With 802.1x, RADIUS, and EAP
It has always been true that the pre-shared key (PSK) form of WPA is less secure than the enterprise form, but the enterprise form requires a RADIUS server, and the PSK form has been considered to be good enough for small installations. Perhaps not anymore. Recent news about new attacks against WEP and WPA has some network administrators re-examining the security of their wireless networks. If a move from WPA-PSK to WPA-Enterprise is in your future, this article will give you the basics of the authentication architecture with which you’re going to work

Why WPA-Enterprise
The PSK form of WPA uses a single passphrase as the primary authentication parameter. The passphrase is typed into the wireless client and any client that knows the passphrase can authenticate and get on the network. This is functionally similar to a WEP key, except that the encryption that goes on behind the scenes is much more robust and difficult to crack. But, similar to WEP, WPA’s passphrase has limitations. It doesn’t scale well to large installations and it represents a single point of failure for the network’s security.
The Enterprise form of WPA authenticates users against a RADIUS server. RADIUS is a generic authentication protocol that supports many different types of credentials. For example, a user might authenticate to a RADIUS server using a traditional username and password, some sort of biometric information, a SecurID token, or whatever other form of authentication the developer decided to write into the RADIUS server. With a RADIUS server, each user has his or her own credentials, allowing the security infrastructure to differentiate between individual clients. This means that the network administrator can choose to assign different access rights to different users, something that isn’t possible in WPA-PSK, when everyone is using the same credentials. Additionally, RADIUS servers can be integrated into pre-existing authentication frameworks. For example, it is common to integrate a RADIUS server with Windows Active Directory, allowing users to log into the wireless network using the same username and password that they use to log into their Windows desktop.
In short: compared to WPA-PSK, WPA-Enterprise allows the use of more robust forms of credentials, allows for more sophisticated management of user permissions, and is possible to integrate into existing authentication frameworks.

The RADIUS Architecture
RADIUS describes an architecture consisting of three entities: authentication server, supplicant, and authenticator. For the sake of this discussion the authentication server is the RADIUS server, which is installed on the wired network. The supplicant is the wireless client that is trying to get onto the wireless network. The authenticator is the access point. The supplicant (wireless client) will contact the authenticator (AP) to initiate the authentication process. The authenticator (AP) will get some credentials from the supplicant (wireless client) and will pass those credentials to the authentication server (RADIUS server). The authentication server (RADIUS server) will evaluate the credentials and indicate to the authenticator (AP) whether the supplicant (wireless client) is allowed to access the network, based on which the authenticator (AP) will either let the supplicant (wireless client) onto the network or not.
When these devices talk, they use a protocol called Extensible Authentication Protocol (EAP). EAP comes in many different “flavors,” called different EAP types. The key piece of information about EAP types that is relevant to this article is that both the supplicant and the authentication server have to be configured to use the same EAP type, or the authentication cannot occur. This can become an issue because most supplicant and authentication server software only supports a few EAP types. For example, the supplicant that comes built in to the Windows operating system only supports the EAP types EAP-TLS and PEAP. If the RADIUS server that you happen to be using doesn’t support one of these two EAP types, your Windows clients won’t be able to authenticate to it—at least, not with the supplicant software that comes installed with Windows.

How Incompatible EAP Types Can Occur
Different EAP types have different pros and cons, and a thorough analysis might lead you to prefer a particular EAP type that is not supported by your authentication server and/or your supplicant. On the supplicant side, this is relatively easy to fix, because you don’t have to use the supplicant that was provided with your operating system. Yes, Microsoft gave Windows users a supplicant that supports EAP-TLS and PEAP, but you’re perfectly free to go download the Funk Odyssey Access Client (or any of several other third-party supplicants), which will allow your machine to use just about any EAP type that exists! Also, the wireless client manager software that comes with some wireless cards can often act as a supplicant for additional EAP types above and beyond those supported natively by Windows.

Windows WiFi Client Software EAP Options

Intel WiFi Client Software EAP Options

Windows supports only PEAP and EAP-TLS by default, but the client manager software that comes with the Intel Centrino wireless chipset in this laptop adds support for TLS, TTLS, LEAP, and EAP-FAST. Also notice that the Windows supplicant doesn’t actually say “EAP-TLS”. Rather, it confusingly says, “Smart Card or Other Certificate.” This use of non-standard terminology could complicate configuration of the same EAP type in the RADIUS server, because it might not be obvious to the administrator what EAP type, “Smart Card or Other Certificate” is referring to. After all, EAP-TTLS and EAP-FAST also use certificates, and EAP-GTC uses smart cards.
On the server side, things are less flexible. RADIUS servers typically support specific EAP types, and the only option for supporting additional EAP types may be to switch to a different RADIUS server. At the very least, this would be a significant investment in money and time. For this reason, it is usually best to resolve EAP incompatibilities by installing a compatible supplicant on the clients. In most cases, however, the best course of action is to avoid incompatibilities altogether by only choosing an EAP type that you know is supported by both your RADIUS server and your client devices. Unfortunately, this can narrow your selection of EAP types down to just one or two, and sometimes might exclude an EAP type that you would like to use.

Summary and Conclusion
WPA-Enterprise has advantages over WPA-PSK, in terms of security, scalability, and manageability. Wireless clients and RADIUS servers often support more than one EAP type, but if they don’t have at least one EAP type that they share, the system won’t work. If you are already locked into a particular RADIUS server (often the case in large enterprises), you will likely be limited to EAP types that are supported by that server. Client-side incompatibility issues may be able to be resolved by installing a third-party supplicant on the client. On the other hand, if you have not yet selected a RADIUS server, it may be to your benefit to only consider ones that support EAP types that are natively supported by your client devices, so as to avoid the workload of installing custom software on all of the client devices.

 Technology and Engineering

Selecting An EAP Type
In this issue’s Essential Wi-Fi, we discussed a primary consideration in choosing an EAP type—that it must be supported by both the client and the RADIUS server. In this article, we’ll discuss the pros and cons of specific EAP types, giving you more information that can be used to select the EAP type for your wireless network.

Although each of the common EAP types will be covered, it should be acknowledged that WPA and WPA2 only support the following: EAP-TLS, EAP-TTLS (with MSCHAPv2), PEAPv0 (with EAP-MSCHAPv2), PEAPv1 (with EAP-GTC), and EAP-SIM. Other EAP types still exist and are still used in some cases, but best practice in 802.11 is to use only EAP types that are supported by WPA, because this decreases the likelihood of compatibility issues.

LEAP
LEAP was developed by Cisco Systems prior to the ratification of the IEEE 802.11i security standard. MacOS 10.3.x and higher support LEAP natively. Windows does not support LEAP natively, but Cisco’s client software utility acts as a LEAP supplicant, so clients using Cisco cards are fine. Windows clients using non-Cisco wireless cards may need to add third-party software in order to use LEAP. Because of this, LEAP is most commonly used in networks made up primarily or exclusively of Cisco devices.
LEAP uses usernames and passwords for authentication. It does not protect the credentials very strongly, and at least one exploit has been developed to crack LEAP. Cisco recommends that stronger EAP types, such as EAP-FAST, PEAP, or EAP-TLS be used instead of LEAP.

EAP-MD5
EAP-MD5 is the weakest of the EAP types. Like some other EAP types, it uses a username and password as credentials, but it passes them in cleartext across the network, making it a trivial matter to recover them. Additionally, EAP-MD5 is the only type of EAP that does not support dynamic key generation, making it incompatible with WPA/WPA2 Enterprise. Because of these factors, EAP-MD5 is not recommended under any circumstances, except when absolutely no other EAP types are available.

EAP-TLS
EAP-TLS is notable for being an IETF open standard, as opposed to other EAP types that were developed by vendors and that tend to be supported primarily on those vendors’ equipment. EAP-TLS is supported natively in Windows, MacOS, and most RADIUS servers.
EAP-TLS uses an authentication model derived from SSL. Like SSL, EAP-TLS uses client-side and server-side certificates to perform mutual authentication. This means that EAP-TLS is very secure. However, the administrative overhead of distributing and managing certificates is prohibitive for many, and a mismanaging certificates (for example, not revoking a certificate that has been compromised) can create security holes. For many administrators, other EAP types provide adequate security that is only slightly less than EAP-TLS, with a dramatically lower administrative overhead.

Creating a TLS User Profile

Intel’s wireless card manager software for Windows contains an EAP-TLS supplicant. Note that the dialog box is asking for which SSL certificate to use. Unfortunately, no certificates have been installed on this machine yet, and in order to use TLS, every client would need a certificate installed. This is why many network administrators choose not to use EAP-TLS.

EAP-TTLS
EAP-TTLS was developed by Funk Software (now Juniper Networks) and Certicom. It is based on EAP-TLS, but it removes the requirement to install client-side certificates, while maintaining much of the security of EAP-TLS. This means that a certificate only needs to be installed on the RADIUS server, not on every single wireless client, dramatically reducing the administrative overhead of EAP-TLS.
EAP-TTLS is supported widely, including on MacOS, but interestingly, not on Windows (perhaps because Microsoft developed PEAP to fill the same role).

PEAP
PEAP was developed by Cisco Systems, Microsoft, and RSA Security. It is natively supported under Windows, and is the most likely EAP type for a network with lots of Windows clients and an IIS RADIUS server to select. PEAP is also supported natively under MacOS. PEAP addresses the same need as EAP-TTLS—that is, to provide an authentication mechanism that is almost as secure as EAP-TLS without the administrative overhead of deploying client-side certificates.
Like TTLS, PEAP uses TLS (with an SSL certificate) to authenticate the server, then it sets up an encrypted tunnel within which a second type of EAP is used to authenticate the client device. These two authentications are referred to as the “inner” and the “outer” authentication method. This is relevant, because when you choose PEAP as your “outer” EAP type, you further need to choose the “inner” type that goes with it. The two “inner” EAP types that are supported by WPA are MSCHAPv2 and GTC. However, GTC was developed by Cisco, which prefers to promote LEAP and EAP-FAST, and so it is not widely implemented and is not natively supported by Windows. Therefore, although PEAP with GTC is supported by WPA, it is most likely that when people way “PEAP,” they are referring only to PEAP with MSCHAPv2.

Configuring PEAP and MS-CHAP

Configuring PEAP with MSCHAP-v2 in Intel’s wireless client utility.

Note that user credentials are a username and password. No client-side certificate is required, and the user can simply be prompted to enter his or her username and password on login.

EAP-FAST
EAP-FAST is proposed by Cisco as a replacement for LEAP. Its primary distinguishing characteristic is that the use of server-side security certificates is optional. EAP-FAST is natively supported by MacOS 10.4.8 or higher, but not in Windows, where Cisco’s client utility, or some other third-party utility, must act as the supplicant. EAP-FAST is somewhat less secure than EAP-PEAP or EAP-TTLS, and somewhat simpler to manage, since no SSL certificates need be used. Interestingly, EAP-FAST can optionally be used with SSL certificates, in which case it duplicates the functionality of EAP-TLS.

EAP-SIM
This EAP type is exclusively for the authentication of GSM (cellular) devices and is seldom used in 802.11 networks. It is, however, supported under the WPA and WPA2 standard.

Conclusion
A discussion of the merits of various EAP types can be academically interesting, but practically speaking, the decision of which EAP type to use is often more limited than the number of EAP types would suggest. WPA and WPA2 only support five EAP types: EAP-TLS, EAP-TTLS, PEAPv0/MSCHAPv2, PEAPv1/GTC, and EAP-SIM. EAP-TLS is usually rejected because of the difficulty of managing client-side SSL certificates. EAP-SIM is rejected because it is specifically for authenticating GSM cellular devices, which is hardly ever the case in enterprise networks. PEAPv1/GTC is specifically used for token-based authentication, such as SecurID cards. If you’re using SecurID or a similar token-based authentication, you’ll likely be using PEAPv1/GTC.
That leaves EAP-TTLS and PEAPv0/MSCHAPv2 as the remaining options. These EAP types use a standard username/password to authenticate (which is what many administrators prefer) and both of them are reasonably secure. The final choice of which one to use depends largely on the type of RADIUS server and client you’re using. Of the two, PEAP is more likely to be chosen, because Windows clients do not support TTLS natively, whereas a wide variety of devices support PEAP.

Ask the Expert

Cisco wireless LAN controllers use the numbers 1 through 5 to refer to the signal strength configuration for an access point. What do these number mean?

Each number represents a power level, starting with "1"=100mW. Each successive number means that the power level is reduced by roughly 50% (3 dB) so: "2"=50mW, "3"=25mW, "4"=12.5mW, "5"=6mW, "6"=3mW, "7"=1.5mW, "8"=~1mW. The configuration pull-down is shown to the right. It's important to remember the most powerful transmit power is not always the best choice. Whether you're using Cisco, Aruba, Colubris, Proxim or any other wireless network system the limiting factor is typically the weaker transmitter found on client devices. A typical Window's notebook computer with a built-in Wi-Fi adapter may have only a 30 mW transmit power output.

The maximum transmit power for the access points should generally not be greater than the maximum transmit power of the weakest client. An Unbalanced Power Effect (UPE) occurs when a client can hear a strong access point but the client doesn't have enough transmit power to get back to the access point. This is the situation that occurs when you see an SSID (on your notebook computer) with excellent signal strength (because the AP is strong) but you can't connect to it (because your transmit power is weaker.)


To Infinity... and Beyond!

New WEP and WPA exploits
A new record has been set in cracking WEP. Two German researches combined a variety of WEP-cracking techniques to extract a key in only 24,000 packets. Previous attacks required from 32,000 to 40,000 packets to be processed in order to gain a 50% likelihood of recovering the key. Although WEP has largely been abandoned in corporate circles, many retailers still use WEP with older credit-card processing equipment, which is expensive to replace and impossible to upgrade. Retailers who accept credit cards may not deploy new systems with WEP starting April 1, 2009 and must discontinue all use of WEP by June 30, 2010, according to new guidelines set by credit card processors.

Link to paper describing the WEP exploit (PDF):“Practical Attacks against WEP and WPA”

Advances have been made in attacking WPA as well, although they are not nearly as significant as attacks against WEP. The same research paper linked above describes a method for cracking TKIP encryption, but the method does not actually recover the encryption key, and only allows injection of single short packets into the data stream. Currently, the most viable WPA exploit uses a brute-force dictionary attack to attempt to learn the pre-shared key that is used in WPA-PSK. One way of avoiding this attack is to use WPA-Enterprise instead of WPA-PSK, but if you do choose to use WPA-PSK, make sure your passphrase is at least 20 characters long (longer passphrases make it harder to use a dictionary attack) and contains no words found in any dictionaries of any language. Additionally, switching from WPA with TKIP to WPA2 with AES will circumvent any exploits that attack the weaker TKIP encryption.

Web Searching: The Connect802 Web Presence

At Connect802 we're your PAGE ONE resource for wireless networking!

Connect802 has the experience, expertise, and resources to help you with your wireless network system. Use your favorite search engine and see what Connect802 is doing. Each month we give you some suggested search terms for you to explore. Here's this month's list. As you look down the search engine results you'll find Connect802 either at the top, or on the first page (true for Google and Excite, unknown for the rest).