802.1x defines three components to the authentication conversation, which are all shown in Figure 6-6. 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.
Figure 6-6. 802.1x architecture
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. A derivation of EAP is used by the authenticator to pass challenges and responses back and forth. From the supplicant to the authenticator (the "front end"), the protocol is EAP over LANs (EAPOL) or EAP over wireless (EAPOW). On the "back end," the protocol used is RADIUS. Some documentation may refer to it as "EAP over RADIUS." 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.
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.
6.2.2 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 a wired Ethernet, so the MAC header consists of the destination MAC address and the source MAC address. On a wireless network, the MAC header would be the 24- to 30-byte header described in Chapter 3.
Ethernet Type
As with any other Ethernet frame, the Ethernet Type field contains the two-byte type code assigned to EAPOL: 88-8e.
Version
At this point, only Version 1 is standardized.
Packet Type
EAPOL is an extension of EAP. In addition to the EAP messages described in the previous section, EAPOL adds some messages to adapt EAP to the port-based LAN environment. Table 6-1 lists the packet types and their descriptions.
Table 6-1. 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.
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 Key frames, and one alert in EAPOL-Encapsulated-ASF-Alert frames.
Figure 6-7. EAPOL frame format
6.2.2.1 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.
6.2.3 Sample 802.1x Exchange
EAPOL exchanges look almost exactly like EAP exchanges. The main difference is that supplicants can issue EAPOL-Start frames to trigger the EAP exchange, and they can use EAPOL-Logoff messages to deauthorize the port when the station is done using the network. The examples in this section assume that a RADIUS server is used as the back-end authentication server, and therefore they show the authenticator performing
translation from EAP on the front end to RADIUS on the back end. EAP authentication in RADIUS packets is specified in RFC 2869.
The most common case, successful authentication, is shown in Figure 6-8. In the
beginning, the port is unauthorized, so access to the network is blocked. The steps in this typical EAPOL exchange are:
1. The supplicant starts the 802.1x exchange with an EAPOL-Start message.
2. The "normal" EAP exchange begins. The authenticator (network switch) issues an EAP-Request/Identity frame.
3. The supplicant replies with an EAP-Response/Identity frame, which is passed on to the RADIUS server as a Radius-Access-Request packet.
4. The RADIUS server replies with a Radius-Access-Challenge packet, which is passed on to the supplicant as an EAP-Request of the appropriate authentication type containing any relevant challenge information.
5. The supplicant gathers the reply from the user and sends an EAP-Response in return. The response is translated by the authenticator into a Radius-Access-Request with the response to the challenge as a data field.
6. The RADIUS server grants access with a Radius-Access-Accept packet, so the authenticator issues an EAP-Success frame. The port is authorized, and the user
can begin accessing the network. DHCP configuration may take place at this point.
7. When the supplicant is done accessing the network, it sends an EAPOL-Logoff message to put the port back into an authorized station.
Figure 6-8. Typical EAPOL exchange
Exchanges similar to Figure 6-8 may be used at any point. It is not necessary for the user to begin an EAPOL exchange with the EAPOL-Start message. At any point, the
authenticator can begin an EAPOL exchange by issuing an EAP-Request/Identity frame to refresh the authentication data.