Examining 802.1x and EAP

Enterprise Networks & Servers, May 2004 by Welcher, Peter J

Security has become a very active interest lately for schools, universities and enterprises. Many have been stunned and even overwhelmed with the waves of virus and worm attacks sweeping through their networks. Sometimes older network equipment can't handle the volume and kind of traffic these nasties send in their attempts to spread. Meanwhile, it seems like those lists of vulnerabilities in software and device code just keep growing. No, I'm not going to solve all that in this month's article!

In response to all this, Cisco has been marketing the Self-Defending Network. Part of that is Network Access Control with Trust Agent for checking that personal firewall and virus scanner are enabled, etc. This leverages the 802.1x authentication mechanism that has been out for a while, along with something we'll talk about called EAR The idea is to check not only identity (authentication), but compliance with security policies.

Meanwhile, security has been a concern on the wireless LAN (WLAN) front for a while now. WPA and 802.11i with AES encryption look like they've addressed most of the concerns in that arena. But these too use 802.1x and the EAP suite for authentication.

I've been presenting on these sorts of topics lately (WLAN Security and 802.1x). I see people scrambling to sort all this out. So it seems like a good idea to talk through the various things that together control access to the network, both wired and wireless. This article launches that discussion by taking a look at 802.1x and the EAP protocol family, which should be quite enough to fill one article.

What Is 802.1x?

The standard 802.1x is an IEEE standard for Port-Based Network Access Control. The document is readily available on IEEE's Web site (the URL can be found below). It is a modest 142 pages long.

From the introduction to the 802.1x standard document, with some omissions: "Port-based network access control makes use of the physical access characteristics of IEEE 802 LAN infrastructures in order to provide a means of authenticating and authorizing devices attached to a LAN port [...], and of preventing access to that port in cases in which the authentication and authorization process fails. [...] Examples of ports in which the use of authentication can be desirable include the Ports of MAC Bridges, [...], and associations between stations and access points in IEEE 802.11 Wireless LANs."

To say that briefly, 802.1x works at Layer 2 of the OSI model to authentication and authorize devices on LAN switches and wireless access points (WAPs). It does assume a point-to-point model. This means that it is not really intended for situations such as multiple PCs connecting to a switch via a hub or simple switch.

Terminology

802.1x does introduce some alternative terminology that we need to get used to. An authenticator helps authenticate what you connect to it. It does this via the authentication server. The supplicant is what is being authenticated. See Figure 1 if that's unclear.

The acronym EAP stands for "Extensible Authentication Protocol".

802.1x trivia item (for the next time you play): the Port Access Entity (PAE) is what executes the algorithms and follows the protocol(s). Each of the three items above has a PAE, but the PAE software does do different things on each of the three.

The 802.1x access control works on unaggregated physical ports at OSI Layer 2. It allows or denies access. The access control it exerts can govern bidirectional or inbound traffic.

On LAN media, 802.1x needs some way to communicate between the Supplicant and the Authenticator. This happens directly at Layer 2. The protocol used is EAPOL, which stands for EAP encapsulation over LANs. EAP is a separate protocol (or family of protocols) for authentication. We'll get to EAP in a moment.

Sometimes a good way to understand design choices is to think about alternatives. To me, ;; Cisco's User Registration Tool (URT) and VLAN Policy Server (VPS) are early attempts to figure out the best way to do this and solve a real customer need. They take the direct approach, whereby the supplicant does DHCP into a default VLAN, uses IP to authenticate, and then perhaps gets cut off or moved to another VLAN. If the supplicant's switch port shifts to another VLAN, then the user or software have to trigger a DHCP release/renew.

Doing all this is a bit clumsy and slow. It also allows anyone into your network temporarily while waiting for the authentication reply. This is enough opportunity that a hacker could use the access for denial of service attacks on DHCP or DNS servers, or traffic-based and other attacks on the network or network-attached computers.

Let's take a look at the EAPOL frame format. It is shown in Figure 2.

The packet type is as follows:

0 EAP Packet

1 EAPOL Start

2 EAPOL Logoff

3 EAPOL Key

4 EAPOL Encapsulated ASF Alert

The Key packet type is used for EAP variants that allow an encryption key. The packet body is then a Key Descriptor, with specified fields. We'll skip the details.

The ASF Alert EAP packet type allows for things like SNMP traps to be sent through a port where the authentication resulted in an unauthorized state. The standard notes that use in a shared environment is highly insecure unless the supplicant to authenticator traffic is a secure association, i.e. encrypted.