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,  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.
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)  that demands mutual authentication between the client and the network. 802.1X works with EAP (Extensible Authentication Protocol)  to authenticate the client to the network and the network to the client, ensuring that both sides are communicating with recognized entities.
802.1X is designed to work over just about any kind of networkwired, wireless, barbed wire, even carrier pigeon  and bongo drum.  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.
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 :
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.  Although this hasn't been officially tested on wired networks, no problems have been reported .
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. 
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:
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:
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.  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.)
MAC filtering isn't much better. MAC addresses are also unencrypted and unsigned. Using a tool such as SMAC  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!
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:
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.  ) 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.
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.  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:
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,  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.
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.