Using 802.1X for Network Protection

How do you get into your house or your car? Assuming that you aren't (a) attempting to break into your own house or (b) too cool to use your own car's doors, ^[3] you calmly approach the door, fumble around for your keys, unlock and open the door, and finally enter. Your key authenticates you to your house by identifying you as a member of the set of all those who possess the same key. The lock enforces the authentication. (Actually, it isn't true authentication in the sense we use it in computer security; knowing that someone is a member of a set isn't authentication, it's authorization. Your key authorizes you to enter the door. If auditing accompanies the entry, we know who used the key, and then we can say we have authentication.) What about the other direction? How does your house authenticate itself to you? Presuming you don't routinely forget which house is yours, you visually compare its location and appearance with that of neighboring houses. Because houses rarely change locations or appearances on their own, the house that matches your memoryyour stored version of its identifying authenticatorsis yours.

^[3] That is, you have so far successfully managed to avoid acquiring any obnoxious Dukes of Hazzard habits.

802.1X is very much the same. It's a port-based access control method defined by the IEEE (Institute of Electrical and Electronic Engineers) ^[4] that demands mutual authentication between the client and the network. 802.1X works with EAP (Extensible Authentication Protocol) ^[5] to authenticate the client to the network and the network to the client, ensuring that both sides are communicating with recognized entities.

^[4] "Port-based network access control" (http://standards.ieee.org/getieee802/download/802.1X-2001.pdf).

^[5] "Extensible authentication protocol" (ftp://ftp.rfc-editor.org/in-notes/rfc3748.txt).

802.1X operation

802.1X is designed to work over just about any kind of networkwired, wireless, barbed wire, even carrier pigeon ^[6] and bongo drum. ^[7] 802.1X does require a supporting infrastructure: namely, clients that support 802.1X, LAN switches, and wireless access points that can participate in 802.1X, a RADIUS server, and an account database of some kind.

^[6] See "A standard for the transmission of IP datagrams on avian carriers" (ftp://ftp.rfc-editor.org/in-notes/rfc1149.txt) and "IP over avian carriers with quality of service" (ftp://ftp.rfc-editor.org/in-notes/rfc2549.txt).

^[7] "The bongo project: TCP/IP via primitive communication" (http://eagle.auc.ca/~dreid/).

A client, called a supplicant , makes an initial connection to an authenticator, a LAN switch or a wireless access point. The authenticator is configured to require 802.1X from all supplicants and ignores any incoming connection that doesn't conform. The authenticator asks the supplicant for its identity which it forwards to the authentication server (RADIUS).

RADIUS follows whatever mechanism it needs to authenticate the incoming client. Generally this involves setting up an EAP conversation between the supplicant and the authentication server (the authenticator is just a passthrough device here) and establishing an authentication method inside the EAP conversation. Note that EAP itself doesn't define any kind of security on its ownthe authentication protocols used must incorporate their own security. Windows supports two different EAP methods :

• EAP-TLS. The authentication server sets up a TLS (SSL) session with the supplicant. The server sends its digital certificate to the supplicant, which the supplicant validates. The supplicant then sends its digital certificate to the authentication server, which the server validates . Thus we have mutual authenticationso long as each side trusts the other's certificate and the certificate is valid, authentication succeeds.

• Protected EAP (PEAP). PEAP begins like EAP; the authentication server sets up a TLS session with the supplicant and sends its digital certificate to the supplicant for validation. If the supplicant trusts the certificate, it uses one of a variety of methods to authenticate itself to the server. Right now the only supplicant-side authentication method available in Windows is MS-CHAPv2, which permits the supplicant to use traditional accounts ( user or computer IDs and passwords) to authenticate. This is called PEAP-EAP-MS-CHAPv2. Note that PEAP-EAP-TLS is also a configurable option, although there is really no reason to choose this. It establishes a completely separate second TLS session inside the first; this doubling of TLS sessions is slower than pure EAP-TLS.

After RADIUS has authenticated the supplicant, the supplicant is allowed to communicate on the network behind the authenticator (remember, this is the LAN switch or the wireless access point). Although an authenticator has one physical network port, think of it as having two "virtual ports." Traffic from authenticated supplicants passes over the controlled port ; this port blocks traffic from unauthenticated supplicants. During the authentication process the authenticator must communicate with the RADIUS server, of course; this occurs over the uncontrolled port . After a supplicant authenticates, the controlled port is transitioned into a connected state for that supplicant.

Using 802.1X for Wired Security

For 802.1X to be effective in wired networks, a fairly up-to-date infrastructure is necessary. All of the switches in your networkor at least those that clients and servers connect tomust support 802.1X. Each switch requires a digital certificate, which it uses when authenticating to clients. That itself could be a pretty expensive proposition if you use certificates from public authorities, so save yourself some money and build a Windows enterprise certificate authority. All of your domain-joined computers automatically trust enterprise CAs and the certificates they issue.

All of your clients need an 802.1X-capable IP stack. Fortunately this is built in to Windows XP; this alone could be a sufficient enough reason for you to start upgrading your environment. The stack has been tested and approved for 802.1X use on wired networks and has been deployed by some customers now. If you can't upgrade to Windows XP yet, there's an option: Microsoft has released an 802.1X stack for Windows 2000. ^[8] Although this hasn't been officially tested on wired networks, no problems have been reported .

^[8] http://www.microsoft.com/windows2000/server/evaluation/news/ bulletins /8021xclient.asp.

What about network devices that can't participate in 802.1X? Things such as printers or network storage devices or that old DOS PC running some ancient, creaky, totally unsupportable yet mission-critical application? Remember, your reason for implementing 802.1X in the first place is to make sure that only authorized devices can communicate. Now you need to create an exception. Before you do, however, does your security policy allow that? Check first. You also need to create exceptions for bootstrapping new systems (perhaps on a physically isolated segment that's exempt from 802.1X). Note that requiring 802.1X eliminates your ability to use PXE boot in your network.

802.1X on Wired Networks Is Insufficient

802.1X is the perfect foundation for wireless security, which we'll explore in just a moment. But for wired securitywhat we've been discussing so farthere are some significant drawbacks. Working with nonparticipating devices, as we discussed above, is one. Lack of manageability is another: in AD group policy, several GPOs exist for you to manage 802.1X on wireless networks. These GPOs don't exist for wired interfaces, and there are no published APIs for managing wired 802.1X client computers. Some architectural reasons prevent adding GPOs to Windows 2000 and Windows XP for wired 802.1X. Because of this lack of centralized management capability, large-scale 802.1X deployment is infeasible.

Finally, there's a major weakness in the protocol: it authenticates only at the establishment of a connection. After a supplicant authenticates and the switch port opens, further communications between the supplicant and the switch aren't authenticated. This creates a situation in which it's possible for an attacker to join the network. ^[9]

^[9] Thanks to Svyatoslav Pidgorny, Microsoft MVP for security, for bringing this to our attention.

Setting up the attack does require physical access to the network. An attacker needs to disconnect a computer (called the "victim") from its 802.1X-protected network switch port, connect a hub to the port, connect the victim computer to the hub, and connect an attack computer ("shadow") to the hub. This is trivially easy if the attacker is physically inside your facility and if your Ethernet jacks are accessible. The attacker configures the shadow computer's MAC and IP addresses to be the same as those on the victim computera little network sniffing quickly reveals this. The attacker's computer also has a firewall configured to drop all inbound traffic that isn't a reply to communications that it initiated.

After the victim computer has authenticated and the switch port is open, the attacker can connect to resources on the protected network. This is because there is no per-packet authentication of the traffic after the port is open. Because the shadow computer has the same MAC and IP as the victim computer, from the point of view of the switch it appears only as if there's a single computer connected to the port.

Note that the attacker can communicate only over stateless protocols such as ICMP or UDP. So the attacker could ping computers on the network and receive a DHCP lease (it would receive the same IP as the victim). But the attacker can't communicate over TCP to the networkthe victim computer resets any connections initiated by the shadow host. Here's the sequence:

1.	The shadow computer sends a SYN packet to a server on the protected network.
2.	The server returns a SYN-ACK, which both the shadow and the victim receive.
3.	The victim computer isn't expecting this SYN-ACK so it returns a RST to the server.
4.	The server returns a RST-ACK (acknowledging the received RST and sending its own), which both the shadow and the victim receive.
5.	The shadow isn't expecting this RST-ACK but it will abide and terminate the connection.

There's one very interesting exception to the rule. If the victim computer is running a firewall that drops unsolicited inbound SYN-ACKs, which most do, the victim won't process the received SYN-ACK in step 2 and therefore won't send the RST to the server. The rest of the above sequence won't happen and the shadow computer can have complete access to the protected network. This is the only instance we know of where a personal firewall on a computer can reduce the security of the rest of the network! Of course, this is no reason not to deploy personal firewalls; their benefits strongly outweigh the likelihood of this attack actually happening.

So What Should You Do?

Do not stop reading. Wireless networks do not have the problem described above: because 802.1X in conjunction with EAP (described in the next section) create mutually authenticated sessions with per-supplicant encryption keys, the "shadow computer" attack won't work. The shadow is unable to connect to the access point where the victim computer is already connected; furthermore, the shadow is unable to acquire the encryption key that the victim is using. So in a way, with pure 802.1X/EAP, wireless is actually more secure than wired. Keep reading to learn more about how 802.1X works for wireless networks. For wired networks, we strongly encourage IPsec rather than 802.1X. We explain IPsec later in this chapter.

Using 802.1X for Wireless Security

What are the problems with wireless security? You mean aside from the fact that the security in most wireless networks that exist right now is rather weak? There are many:

• Shared encryption keys. All stations and all access points use the same encryption key, which is rarely, if ever, changed. This amounts to nothing more than a widely known shared secret, and if one thing's true about shared secrets it's this: they don't remain secret for very long.

• Short encryption keys. The keys simply aren't long enough. Even a 128-bit RC4 WEP key is vulnerable to some rather interesting and increasingly simple bit-flipping and statistical attacks that reveal the key given enough collected data. ^[10]

  ^[10] "Security of the WEP algorithm" by Nikita Borisov, Ian Goldberg, and David Wagner (http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html).

• Incomplete authentication. Of course, it's important for a network to know who's connecting to it, but it's equally important to know that you are connecting to the correct authorized network. WEP lacks any kind of mutual authentication, so you really have no idea whether you're connecting to the real network or something spoofing the network.

• Unauthenticated join/depart requests . Stations send certain messages to access points when they want to join the wireless network (association messages) and when they want to depart (disassociation messages). These messages are unsigned and unencrypted, so they can be forged.

• Unauthorized access. And, of course, there's the problem of unauthorized use of the network and monitoring the communications over the air.

So what's the right way to build a secure wireless network? Unfortunately, many popular ways are actually very wrong.

The Wrong Way to Secure a Wireless Network

The popular ways to secure a wireless networkdisabling SSID broadcasting, implementing MAC filtering, or deploying a VPNjust happen to all be wrong. Let's examine why.

Disabling SSID broadcasting is a popular recommendation. It's popular because it's been repeated so often it must therefore be true, right? Thing is, it's actually not secure at all. ^[11] Remember the bit above about association and disassociation messages? Even if you've disabled SSID broadcasting, whenever a station wants to join a wireless network, the association message containsin clear text!the SSID of the requested network. This is valuable information for an attacker because once s/he discovers the SSID then s/he can get right on the network if this is your only protection. SSIDs are network names much in the same way that subnet masks are network identifiers. They are not meant to be passwords; don't treat them as such. (Indeed, the 802.11 specification requires that SSIDs always be broadcast.)

^[11] This is an example of "security theater": Recommendations that are appealing because it seems like you're doing something , but in reality provide no security at all. Security theater is very dangerous because it gives you a false sense of security and lulls you into thinking you're safe when in fact you're very exposed.

MAC filtering isn't much better. MAC addresses are also unencrypted and unsigned. Using a tool such as SMAC ^[12] you can alter the MAC address of any interface in your computer. An interesting denial-of-service attack involves spoofing the MAC of an access point, boosting your own transmit power, and sending forged disassociation messages to all clients. Simply, MAC addresses are unreliable identifiers and shouldn't be trusted. Also, think about the tedium of updating an access point each time someone gets a new computer (which of course has a different MAC address). There isn't a lot of career progression for those whose job it is to program access points!

^[12] http://www.klcconsulting.net/smac/.

It's a little more subtle why VPNs aren't suitable for wireless security. In a way, they actually do the jobeach user receives a dedicated encrypted session and there's good user authentication. But although VPNs are very appropriate for remote access, they're less appropriate for wireless.

For example, roaming becomes a nontransparent task: each time a user moves from one access point to another, the VPN session drops and the user must re-authenticate. Also think about just how many VPN servers you might need. If you have 10,000 clients all operating at 11 Mbps (or 54 Mbps if you're using 802.11a or g)and this is not beyond the realm of possibilityhow many VPN servers will you need to handle that traffic, all day long for every user? Finally, VPNs lack one other critical feature: the ability to perform machine logons to the domain. Domain-joined computers log on to the domain when they are wired to the network: this is how machine group policies apply. You want the same thing to happen in wireless, too, and you won't get this if you use VPNs for wireless security: there is no computer logon in this case, and all that time you spent crafting computer policies and startup scripts goes to waste.

The Right Way to Secure a Wireless Network

802.1X, either alone or with WPA (WiFi Protected Access), is the proper way to secure a wireless network. To achieve strong and effective wireless security it's necessary to fulfill certain requirements:

• Mutual authentication. Both the wireless client and the network authenticate themselves to each other. Mutual authentication is critical: it stops man-in-the-middle attacks, thwarts attempts at setting up rogue authentication servers, and helps ensure that keys generated by the authentication server are transferred to the correct access points.

• Key uniqueness and regeneration. Each associated station should receive its own encryption key not shared with any other device except the access point. Furthermore, keys should be regenerated periodically or when stations roam among access points. The periodic rate depends upon how fast clients generate data. Once upon a time we'd have recommended every 60 minutes for 802.11b networks or every 15 minutes for 802.11a or g networks. But a recent article ^[13] has us rethinking that. With modern cracking tools, you can break a WEP key with as few as 500,000 frames. At 11 mbps, a station can generate 500,000 1500-byte frames in 8 minutes 40 seconds; at 54 mbps, a station can generate 500,000 1500-byte frames in 1 minute 46 seconds. These are theoretical maximums, of course, but they illustrate how quickly an attacker can accumulate enough information to break even one station's key. It seems to us that key lifetimes now should be 8 minutes for 802.11b and 90 seconds for 802.11a and g.

  ^[13] "WEP dead again, part 1" by Michael Ossman (http://securityfocus.com/infocus/1814).

• User authentication. To ensure that only authorized users access the network.

• Antispoofing mechanisms. To stop packet spoofing and disassociation attacks.

802.1X/EAP provides the first three, which happen to be the most critical. The beauty here is that wireless stations (and the people using them) receive the same benefits they get now in wired networks: the computer logs on to the domain and computer group policies apply, then the user logs on to the domain and user group policies apply. The experience is the same regardless of the underlying physical infrastructure, which is what you want. Why should people have to change the way they interact with computers just because the physical layer changes? Why should you lose critical security functionality (computer group policies) just because the physical layer changes?

When a computer boots, it first performs a standard 802.11 association to the access point. Because the AP requires 802.1X authentication, however, it disallows communications beyond itself and instructs the station to begin the authentication sequence. The RADIUS server authenticates to the station and the station authenticates with the computer accountthus satisfying the first requirement. In the very last step of this process, the station generates its individual WEP encryption key; the RADIUS server generates the same key and delivers it to the access point. (This is on a wire, of course, and the key is encrypted with the RADIUS shared secret. ^[14] ) At no time does any key material pass through the air. Now the second requirement is satisfied. Finally the user logs on as normal, thus satisfying the third requirement. Access points that participate in 802.1X won't communicate with stations or users that are incapable of authenticating.

^[14] It's actually EAP, not 802.1X, that generates and rotates per-station WEP keys.

Figure 10-1. 802.1X over 802.11.

Wi-Fi Protected Accessthe Future of Wireless Security

The one requirement not satisfied with pure 802.1X/EAP is protection from spoofing and disassociation denial-of-service attacks. Although the likelihood of such attacks is fairly low, the threat is growing. WPA (Wi-Fi protected access, from the Wi-Fi Alliance) mitigates this threat. ^[15] WPA still uses 802.1X and EAP for authentication but specifies the use of TKIP (Temporal Key Integrity Protocol) for key management. TKIP has several advantages over EAP-enhanced WEP:

^[15] WPA was meant to be an interim standard, an improvement over WEP until IEEE finalized their 802.11i wireless security standard. As of this writing, 802.11i had been approved only a few months earlier, and supporting hardware was just beginning to appear. WPA hardware is widely available and Windows XP supports it. WPA will most likely enjoy a longer lifetime than originally envisioned .

• A longer key. RC4 keys are 296 bits long, composed of a 128-bit key, a 128-bit initialization vector, and the 40-bit MAC. Cracking a 296-bit key is substantially more difficult than cracking a 128-bit key.

• More frequent key rotation. TKIP rotates keys every frame rather than at a set time interval. As you might imagine, this could put something of a performance drain on stations and access points, so TKIP also allows the choice of AES ^[16] rather than RC4 as the encryption algorithm. AES is much faster at key generation. Even with AES, however, the performance of older computers will suffer, so for a while you might have to live with a mix of WPA on new machines and 802.1X+EAP on older computers.

  ^[16] "Advanced Encryption Standard (AES) ciphersuites for transport layer security (TLS)" (ftp://ftp.rfc-editor.org/in-notes/rfc3268.txt).

• A frame counter. A monotonically increasing frame counter, part of the encrypted payload, prevents replay attacks simply by dropping all out-of-order or previously-seen frames.

• A signed message-integrity check field. Called "Michael," this is an additional eight bytes added to the encrypted portion of every wireless frame. Michael acts as a digital signature for the entire frame (something that WEP and 802.1X/EAP lack); if a frame is modified in any way, the digital signature becomes invalid and the frame is dropped.

TKIP's inclusion of Michael is the big improvement. WPA solves the last in our list of requirements for strong and effective wireless security. Whenever possible, deploy WPA whenever you can. Soon you'll be able to deploy WPA2, ^[17] WPA's follow-on. WPA2 is the Wi-Fi Alliance's commercial name for IEEE's 802.11i new wireless security standard. WPA2 hardware is available now; WPA2 support in Windows XP and Windows Server 2003 should be out by the time you read this.

^[17] More at http://www.wi-fi.org/OpenSection/protected_access.asp.

One other point about WPA: one of the criticisms of 802.1X+EAP was its requirement of a RADIUS server, regardless of the size of the wireless network. For many small businesses and home offices, this is difficult to accommodate. So WPA (and WPA2, too) support preshared authentication keys (called WPA-PSK). Each station and access point is programmed with this key, which serves only to authenticate stations and access points to each other. WPA-PSK still generates per-frame encryption keys for all over-the-air traffic. The question, then, is at which point do you move from WPA-PSK to WPA-RADIUS? Our gut says 20 stations is the decision point. With fewer than 20 stations, manually managing the authentication key is possible and not all that time-consuming; change the key once every other month or so. With more than 20 stations, it becomes more time-consuming to manage the keys than to deploy a RADIUS server and not worry about key management at all.