1X: Network Port Authentication

X Network Port Authentication

As LAN acceptance mushroomed in the 1990s, LAN ports popped up everywhere. Some types of organizations, such as universities, were further hampered by a need for openness. Network resources must be made available to a user community, but that community is fluid. Students are not like many network users. They frequently move from computer to computer and do not have a fixed network address; they may also graduate, transfer, enroll, leave campus, work on staff, or undergo any number of changes that may require changes in access privileges. Although network access must be extended to this fluid community, academic budgets are frequently tight, so it is important to prevent unauthorized use by outsiders.

In short, a generic network sign-on was required. Academic environments would not be the sole beneficiaries, however. Authentication to access network resources is common among Internet service providers, and corporations found the idea attractive because of the increasing flexibility of staffing plans.

Authentication to network devices at the link layer is not new. Network port authentication has been required by dial-up access servers for years. Most institutions already have a wide range of deployed infrastructure to support user authentication, such as RADIUS servers and LDAP directories. PPP over Ethernet (PPPoE) could conceivably be used to require user authentication to access an Ethernet, but it would add an unacceptable level of encapsulation overhead and complexity. Instead, the IEEE took the PPP authentication protocols and developed LAN-based versions. The resulting standard was 802.1X, "Port-Based Network Access Control."

802.1X Architecture and Nomenclature

802.1X defines three components to the authentication conversation, which are all shown in Figure 6-6 (a). The supplicant is the end user machine that seeks access to network resources. Network access is controlled by the authenticator; it serves the same role as the access server in a traditional dial-up network. Both the supplicant and the authenticator are referred to as Port Authentication Entities (PAEs) in the specification. The authenticator terminates only the link-layer authentication exchange. It does not maintain any user information. Any incoming requests are passed to an authentication server, such as a RADIUS server, for actual processing.

Ports on an 802.1X-capable device are in an authorized state, in which the port is enabled, or an unauthorized state, in which it is disabled. Even while in the unauthorized state, however, the specification allows DHCP and other initialization traffic if permitted by a network manager.

The authentication exchange is logically carried out between the supplicant and the authentication server, with the authenticator acting only as a bridge. Figure 6-6 (b) shows the logical protocol architecture. From the supplicant to the authenticator (the "front end"), the protocol is EAP over LANs (EAPOL), as defined by 802.1X. On the "back end," EAP is carried in RADIUS packets. Some documentation may refer to it as "EAP over RADIUS." The supplicant is carrying on an EAP exchange with a RADIUS server, even though the port is unauthorized and the supplicant is not using an IP address.

Figure 6-6 can be read as two different scenarios. In the enterprise scenario, the supplicant is a corporate host on the edge of the enterprise network, and the RADIUS server is located in the enterprise core. The figure also depicts an ISP using 802.1X to authenticate users, in which case the lefthand side of the figure is an ISP access area, and the righthand side is the ISP backbone.

Figure 6-6. 802.1X architecture

One of the advantages of using RADIUS is that it has a great deal of support for many different user databases. In addition to local databases, a RADIUS server can be used as a gateway to LDAP directories, Unix authentication such as NIS or PAM, Kerberos realms, Microsoft Windows user accounts, or even other RADIUS servers. RADIUS is quite flexible, and can be designed to accommodate a wide range of user databases, and can even serve to integrate several disparate user databases into a unified form. There are some restrictions when using RADIUS to provide authentication based on Windows domains or Active Directory that will be discussed in Chapter 22.

802.1X is a framework, not a complete specification in and of itself. The actual authentication mechanism is implemented by the authentication server. 802.1X supplies a mechanism for issuing challenges and confirming or denying access, but it does not pass judgment on the offered credentials. Changes to the authentication method do not require complex changes to the end user devices or the network infrastructure. The authentication server can be reconfigured to "plug in" a new authentication service without changes to the end user driver software or switch firmware.

802.1X frame filtering

802.1X prevents network access by unauthorized users by requiring authentication before allowing traffic to pass. Ports in the unauthorized state are usually restricted to sending authentication frames only, while traffic is dropped. The 802.1X standard has a formal discussion of how to accomplish this process. For the purposes of this book, however, it suffices to say that unauthorized ports will drop any non-EAPOL frames. Once the station has successfully authenticated, data frames are sent to the appropriate network.

EAPOL Encapsulation

The basic format of an EAPOL frame is shown in Figure 6-7. EAPOL encapsulation is now analyzed by many popular network analyzers, including Ethereal. The frame's components are:

MAC header

Figure 6-7 shows the encapsulation on both wired Ethernet and 802.11. The two MAC headers differ, although the payload of the 802.1X frame is identical.

Figure 6-7. EAPOL frame format

 

Ethernet Type

As with any other Ethernet frame, the Ethernet Type field contains the two-byte type code assigned to EAPOL: 88-8e.

Version

Version 1 was standardized in the 2001 version of 802.1X; version 2 was specified in 802.1X-2004. This chapter describes the 2001 version, which is much more commonly implemented.

Packet Type

EAPOL is an extension of EAP. In addition to the EAP messages that are described in the previous section, EAPOL adds some messages to adapt EAP to the port-based LAN environment. Table 6-2 lists the packet types and their descriptions.

Table 6-2. EAPOL message types

Packet type	Name	Description
0000 0000	EAP-Packet	Contains an encapsulated EAP frame. Most frames are EAP-Packet frames.
0000 0001	EAPOL-Start	Instead of waiting for a challenge from the authenticator, the supplicant can issue an EAPOL-Start frame. In response, the authenticator sends an EAP-Request/Identity frame.
0000 0010	EAPOL-Logoff	When a system is done using the network, it can issue an EAPOL-Logoff frame to return the port to an unauthorized state.
0000 0011	EAPOL-Key	EAPOL can be used to exchange cryptographic keying information.
0000 0100	EAPOL-Encapsulated-ASF-Alert	The Alerting Standards Forum (ASF) has defined a way of allowing alerts, such as SNMP traps, to be sent to an unauthorized port using this frame type.

 

Packet Body Length

This two-byte field is the length of the Packet Body field in bytes. It is set to 0 when no packet body is present.

Packet Body

This variable-length field is present in all EAPOL frames except the EAPOL-Start and EAPOL-Logoff messages. It encapsulates one EAP packet in EAP-Packet frames, one key descriptor in EAPOL-Key frames, and one alert in EAPOL-Encapsulated-ASF-Alert frames.

Addressing

In shared-media LANs such as Ethernet, supplicants send EAPOL messages to the group address of 01:80:C2:00:00:03. On 802.11 networks, ports do not exist as such, and EAPOL can proceed only after the association process has allowed both the supplicant (mobile wireless station) and the authenticator (access point) to exchange MAC addresses. In environments such as 802.11, EAPOL requests use station addresses.