But Wait, There's More!

That's just the beginning. An 802.1x infrastructure opens the door to do things that were never before possible in a legacy 802.11 environment.

First and foremost, users can now be individually identified and authenticated. In a legacy WEP environment, everybody shared the same WEP key. If a user authenticated, all you really knew about that user was that she knew the WEP key. However, that information didn't tell us that the user was Stephanie from Accounting. With 802.1x, an authenticated user is uniquely identified. This means that we now have centralized AAA support (authentication, authorization, and accounting). Since we know who is connecting, we can also enforce policy-based network access. For example, time/day restrictions can be created based on who you are. We could even do fancy things like per-user VLAN assignments.

Finally, 802.1x allows us to use enhanced authentication methods beyond usernames and passwords. This means that we have built-in support for future authentication systems. (DNA sample, anyone?)

EAP Authentication Methods

As we saw earlier in the chapter, 802.1x and EAP are only frameworks for how a secure authentication negotiation session takes place. Now we will dig deeper and look at some specific EAP methods. There are dozens of EAP methods available. We will look at a few of the most popular ones.

The EAP method you choose will determine the complexity of implementation as well as the strength of the encryption solution. Some methods are easier to install than others, while some methods provide better security than others. Keep in mind that your chosen EAP method must be supported across all components of an 802.lx system: the supplicant, authenticator, and authentication server.

MD5

The MD5 EAP method provides the lowest level of security possible and it is the easiest to implement. This method, formerly called CHAP in traditional PPP applications, is vulnerable to a number of attacks, including a relatively simple dictionary attack. Also, passwords must be stored in a readable form by the server (another security no-no).

Another problem is that it does not offer mutual authentication, leaving it vulnerable to man-in-the-middle attacks. Using one-way authentication, the AP authenticates the client, but the client does not authenticate the AP. In a traditional PPP context, this should be sufficient, given the relative complexity of impersonating a dial-up server. In other words, in a dial-up context, a certain amount of trust in implied because a client who dials a phone number has some assurance that the server on the other end of the phone is who they say they are, because you are the one who dialed the server.

It would take a substantial effort to break into the phone network, and redirect the phone call (say, with call forwarding). It's not an impossible attack, just somewhat difficult to pull off. Setting up a fake AP, on the other hand, is a much simpler proposition. Mutual authentication in a wireless context is clearly a necessity.

Further, unlike the other EAP methods we will look at, MD5 is the only one that does not support dynamic WEP/TKIP key generation. It has no mechanism to create per-session or per-user keys.

All of these issues mean that MD5 should never be used in a production environment. It is included for backwards compatibility and testing purposes only. In fact, some vendors will actually block MD5 authentication because it should not be relied upon for secure authentication.

LEAP

The Lightweight Extensible Authentication Protocol (LEAP) provides both mutual authentication and dynamic WEP rekeying. LEAP was designed as a pre-802.1x interim solution by Cisco during 2000. In the early days, before the widespread deployment of WPA, Cisco took an early lead in creating a scaleable, robust security solution to replace WEP and its vulnerabilities.

Unfortunately, this protocol was nonstandard and proprietary. Therefore, it was only supported in Cisco gear and not widely adopted by the industry. This was really good news and bad news at the time. The good news was that you could securely support a wireless network across a variety of platforms because Cisco supported client adapters on a wide variety of operating systems including Windows, Macintosh, and Linux. The bad news was that the solution only worked if your environment had Cisco equipment exclusively. You must be using Cisco client NICs, APs, and RADIUS servers for LEAP to work. With most companies reluctant to lock themselves into a single vendor solution, LEAP found only modest acceptance. This was especially true in mixed environments (such as hotspots) where vendor uniformity could not be ensured.

TLS

Transport Layer Security (TLS) represents the strongest possible security and the highest difficulty of implementation. TLS provides mutual authentication, as well as dynamic WEP rekeying. The protocol establishes an end-to-end encrypted tunnel for transferring the user's credentials using PKI. In other words, both the client and the server must use digital certificates in order to achieve a secure tunnel. Again, this is good news and bad news. While the PKI solution offers the highest level of security, deploying a full-blown PKI infrastructure is a significantly complicated undertaking.

The next two methods, TTLS and PEAP, are extensions to TLS. For these methods, the AP is authenticated by TLS, then the user is authenticated by another, tunneled protocol. In other words, TLS is used to establish a secure channel (using a server side certificate), then another EAP negotiation is established over the secure channel to authenticate the user.

TTLS

Tunneled Transport Layer Security (TTLS) supports mutual authentication and dynamic WEP re-keying. However, unlike TLS, TTLS only requires a certificate on the server side, not the client side. Clients can then authenticate using passwords. TTLS, therefore, is almost as secure as TLS, but much simpler to deploy.

PEAP

Protected EAP (PEAP) is very similar to TTLS. PEAP supports mutual authentication, and dynamic WEP rekeying and requires only server-side certificates. Because the client authentication is done over a secure channel, it can use another less secure method to authenticate the client. Logically, this is similar to the way a secure online transaction works using HTTPS. After all, HTTPS is just using HTTP (an insecure protocol) over SSL (a secure protocol). When you type https://www.somebank.com, you are using a server-side certificate to authenticate the server (and validate that the public key for that site is authentic), then using PKI to securely exchange keying material for a symmetrical key cipher.

PEAP works in a similar manner. You use the server certificate to authenticate the server and then you can plug in another EAP type to authenticate the client. Therefore, you could, in theory use PEAP together with MS-CHAP version 2.0 and it would be secure because the MS-CHAP conversation would occur inside the secured PEAP tunnel.