IEEE 802.1x is a protocol standard framework for wired and wireless LANs that authenticates users or network devices and policy enforcement at the port level to provide secure network access control.
The IEEE 802.1x protocol provides the definition to encapsulate the transport of the EAP message at the MAC layer (data link Layer 2) over any PPP or IEEE 802 media through the implementation of a port-based network access control to a network device. The 802.1x standard describes how the EAP messages are communicated between a supplicant (end device) and an authenticator (switch or access point). The authenticator relays the EAP information to the authentication server (Cisco Secure ACS) via the RADIUS protocol.
IEEE 802.1x provides not only the capability to permit or deny network access, but also provides additional policy enforcement for services and resource access in conjunction with higher layer protocols.
Note
330RFC 3748 replaces RFC 2284.
The IEEE 802.1x standard, combined with the capability of network devices to communicate using existing protocols such as EAP and RADIUS, provides increased security and control of access to network segments and resources by associating the identity of a network-connected entity to a corresponding set of control policies.
There are three primary components (roles) in the IEEE 802.1x authentication process, as shown in Figure 11-2 and described in the list that follows:
Supplicant or client: The supplicant is an IEEE 802.1x-compliant client device such as a workstation, a laptop, or an IP Phone with software that supports the 802.1x and EAP protocols. The supplicant software may be integrated into the client, such as the Microsoft Windows XP operating system, or it can be included in the client device firmware or implemented as add-in software, such as the Meetinghouse AEGIS client. The supplicant client sends an authentication request to access the LAN via the connected authenticator (switch) using EAP, as shown in Figure 11-2.
Authenticator: The authenticator is a device (such as a Cisco Catalyst switch or a wireless access point) that enforces physical access control to the network, based on the authentication status of the supplicant. The authenticator acts as a proxy to relay information between the supplicant and the authentication server, as shown in Figure 11-2. The authenticator (switch) receives the identity information from the supplicant via EAP over LAN (EAPOL) frames, which is verified and then encapsulated into the RADIUS protocol format to be forwarded to the authentication server. The EAP frames are not modified or examined during encapsulation, and the authentication server must support EAP within the native frame format. When the switch receives frames from the authentication server, the RADIUS header is removed, leaving the EAP frame, which is then encapsulated in the IEEE 802.1x format and sent back to the client.
Authentication server: The authentication server is database policy software, such as the Cisco Secure ACS. The authentication server supports the RADIUS server protocol to perform the authentication of the supplicant that is relayed by the authenticator (switch) via the RADIUS client-server model. The authentication server validates the identity of the client and notifies the authenticator (switch) whether the client is allowed or denied access to the network. Based on the response from the authentication server, the authenticator relays the information back to the client. During the entire authentication process, the authentication server remains transparent to the client because the supplicant is communicating only to the authenticator, as shown in Figure 11-2. The RADIUS protocol with EAP extensions is the only supported authentication server.
Figure 11-2 illustrates how the port-based access control solution works and shows the high-level message exchange between these three components. These messages vary depending on the EAP method selected, which will be discussed in the next section.
To understand and simplify the fundamental architecture as depicted in Figure 11-2
The authenticator sends a login request to the client.
As illustrated in Step 5 of Figure 11-2, the authenticator acts on the basis of the response from the authentication server (RADIUS) to determine whether the client is granted access. This can be determined on the switch by the state of the port. The port starts in the unauthorized state. When in this state, no traffic is allowed through the port except for the 802.1x message exchange packets. When the client is successfully authenticated, the port changes into the authorized state (as shown in Step 6 of Figure 11-2), thereby allowing all traffic to flow through.
When a non-802.1x-compliant client connects to an unauthorized port, the switch has no way to assume that the client does not support 802.1x; hence, it sends the login request asking the client for identity credentials. Because the client does not support the 802.1x protocol, it is not able to interpret the request packet and does not respond. Therefore, the switch denies all the packets on that port, and the port remains in the unauthorized state.
Whereas when a 802.1x-compliant client connects to a port that is not running a 802.1x protocol, the client keeps sending the EAPoL start packet a few times and, eventually, because there is no response from the switch, the client begins sending packets assuming that 802.1x authentication is not required and continues sending the packets as if the port were in authorized state. The switch does not deny or block the access, because there is no 802.1x protocol running on that port.
Figure 11-3 shows the authentication process when the 802.1x port-based authentication is enabled and the supplicant client supports IEEE 802.1x-compliant client software.
[1] This occurs if the switch does not detect EAPOL packets from the client.
Note
The information in Figure 11-3 is taken from the "Configuring IEEE 802.1x Port-Based Authentication" section of the Catalyst 3560 Switch Software Configuration Guide, Rel. 12.2(25)SEE, at the following link: http://tinyurl.com/22zdyd.
As discussed earlier, the Cisco IBNS solution extends network access security, based on the 802.1x technology and the EAP. Although EAP is more often used for wireless LAN networks, it can also be used for wired networks.
Note
RFC 4017 describes the specification and the requirements for EAP methods used in wireless LAN authentication.
Several variations are available in EAP methods that can be used in the 802.1x solution to provide identity-based network access control. The following EAP methods are commonly used in identity-based network access control solutions:
EAP Message Digest 5 (EAP-MD5)
EAP Transport Level Security (EAP-TLS)
Protected EAP (PEAP)
Cisco Lightweight Extensible Authentication Protocol (Cisco-LEAP)
Chapter 12, "Wireless LAN (WLAN) Security," describes the various EAP methods in detail.