By Lisa Phifer

September 05, 2003

The essential ingredient to keeping out the Wi-Fi riff-raff is denying them physical access (and permitting access to authorized users). That’s where port access control comes in.

Securing any kind of network involves allowing authorized parties to access traffic and networked resources (e.g., servers, hosts) while blocking outsiders. One essential ingredient in this recipe: permitting or denying physical attachment to the underlying communications medium.

In Ethernet LANs, this has long been accomplished by disabling unused RJ-45 jacks and latching Media Access Control (MAC) addresses to Ethernet switch ports. Early wireless LANs followed suit by using access control lists (ACLs) to permit associations by known MAC addresses while rejecting all others. MAC ACLs are quite easy to understand and configure. However, ACLs become difficult to manage in large/dynamic networks and are easily circumvented by network interface cards (NICs) with programmable addresses.

Fortunately, there is a better answer: the LAN Port Access Control framework defined by the IEEE 802.1X standard. This article explains the purpose of 802.1X and the role it can play in your network.

Why LAN Port Access?

MAC forgery is possible on wired and wireless LANs (WLANs), but the risk is greater on wireless. In a wired Ethernet, intruders can’t easily learn valid MAC addresses. An unsupervised visitor might look at a PC’s cable tag, plug his own laptop into the jack used by that PC, and reconfigure his NIC to impersonate the PC and gain access. But to pull this off, the intruder needs physical access to the facility and communications medium.

Related Articles

• Securing The Military’s PX WLANs
• Cavium Announces WLAN Security Chips
• Searching for Wi-Fi Security Solutions
• Setting Up a Secure Wireless Network

In a WLAN, eavesdroppers within several hundred feet of an access point can use freeware sniffers to capture traffic. Even when data is encrypted for privacy, eavesdroppers can record MAC addresses from frame headers. A patient intruder can wait until later to reconfigure his NIC to impersonate a legitimate wireless station. An impatient intruder can reconfigure his NIC right away, send a disassociate request to kick the legitimate station off the air, then immediately reassociate with the access point. Such attacks don’t require insider access to your facility — intruders can be located in nearby parking lots, public hallways, stairways, bathrooms, or adjacent offices.

More robust access control can benefit both wired and WLANs. Many companies also control access at the enterprise firewall or VPN gateway — for example, permitting packets from known source IPs or prompting user login before permitting sessions through the firewall/gateway. Higher-layer controls are indeed very useful, but insufficient when used alone. For example:

• If your DHCP server hands out IPs to any requesting station, a WLAN intruder doesn’t need to do anything extra to pass through an IP-based firewall filter.
• If you assign static IPs, a WLAN intruder can sniff traffic to learn a valid IP — or systematically guess addresses, starting with common private subnets like 192.168.0.0.
• If users are prompted for login/password without encryption, a WLAN intruder can sniff that exchange and use dictionary attack tools to obtain the user’s password from a captured password hash.
• Intruders can do damage without penetrating the firewall/gateway by launching attacks on access points, switches, and peer stations, attempting to break into those systems to steal stored data, or simply flooding the LAN with bogus traffic.

Combining LAN access control with higher-layer controls can mitigate these kinds of threats. If an intruder can’t send data through a LAN port, he can’t request an IP address from DHCP or systematically guess IPs. If he can’t receive data from an Ethernet port, he can’t sniff peer traffic or hashed passwords. Unfortunately, one can’t stop intruders from receiving or sending traffic over the air. However, port access control can stop intruders from sending traffic through the access point into adjacent networks.

How 802.1X Works

Think of 802.1X as an ON/OFF gate inside Ethernet switches and wireless access points. This gate starts in the OFF position, handling only 802.1X requests until a decision is made to grant the station access. At that point, the gate is thrown into the ON position so that all LAN traffic can be relayed between the station and the upstream network. Eventually, the station times out or disconnects, throwing the gate back into the OFF position.

802.1X defines a management protocol that stations use to request LAN port access. It uses the Extensible Authentication Protocol (EAP) originally defined for dial-up, but here sent over Ethernet LANs (EAPOL) or over wireless (EAPOW). The station must first physically connect to the communications medium — an Ethernet NIC plugs into a jack; a wireless NIC associates with an access point. The station then sends an “EAP Start” message. This kicks off a flurry of management messages that ends with “EAP Success” or “EAP Failure”

So far, 802.1X sounds pretty simple, but here’s where the real work happens. EAP is an envelope that can carry many different kinds of authentication — challenge/response, one time passwords, SecurID tokens, digital certificates, etc. What happens between “EAP Start” and “EAP Success” depends upon the type of authentication being used.

Knock, Knock, Who’s There?

Throughout most of the 802.1X exchange, the switch or access point (“the authenticator”) is just a middle man, relaying EAP messages between the station (“the supplicant”) and a RADIUS server (“the authentication server”). For example, the station is asked to supply its identity, which the authenticator relays inside a RADIUS Access-Request. Based on the station’s identity, the RADIUS server issues a RADIUS Access-Challenge, the content of which the authenticator relays to the station. And so on, until the RADIUS server makes a decision to accept or reject the access request.

This 802.1X framework consolidates decision-making at the RADIUS server, so that ACLs no longer have to be individually configured into every switch or access point. It also allows stations to identify themselves with credentials other than MAC address. For example, the station’s identity can be a Windows login, followed by a CHAP challenge/response to verify the station’s password. Or the station’s identity can be an X.500 Distinguished Name, bound to a digital certificate verified via public/private key cryptography. As we shall see, supporting a wide variety of authentication schemes proves to be both an asset and challenge for 802.1X deployment.

One More Thing: Here’s Your Key

In WLANs, an additional step follows EAP Success: an EAPOW Key exchange. This provides the access point and station with secret session keys to be used by Wired Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA) to encrypt traffic sent over the WLAN.The original 802.1X standard used a single EAPOW Key message for this purpose, but the new improved 802.1X (called 802.1aa) uses a four-way handshake to prevent man-in-the-middle attacks that might otherwise compromise these keys. After both ends of the wireless association — the station and the access point — have session keys, data sent over the air can be encrypted to prevent eavesdropping.

In fact, this relationship between 802.1X and data encryption turns out to be just as important to WLAN security as controlling access and authenticating stations. Exchanging session keys with 802.1X is much more resistant to WEP key cracking than using static, manually-configured shared WEP keys. The desire to use dynamic, automatically-generated per-session keys is a significant driver promoting 802.1X deployment, particularly in larger WLANs where managing static WEP keys is difficult anyway.

Drilling Down Into EAP

At this point, you should have a pretty good idea about where 802.1X fits into your network and what happens when a station tries to access a LAN using 802.1X. Deploying 802.1X port access control requires support on all three devices involved in this exchange: supplicant software on stations, authenticator support in access point firmware, and an 802.1X-compatible authentication server.

As you might guess, all three devices must support the same versions of 802.1X and the same authentication methods, and that’s where 802.1X deployment gets tricky. In particular, you’ll need to find products that support one or more EAP types — the variations of EAP that support different kinds of authentication.

In part two of this primer, we’ll drill down into available EAP types and learn how to choose compatible products to deploy 802.1X in your LAN.