Understanding 802.1X Authentication

Definition

802.1X defines a port-based network access control and authentication protocol that prevents unauthorized clients from connecting to a LAN through publicly accessible ports unless they are properly authenticated.

Benefits

• 802.1X is a Layer 2 protocol and does not involve Layer 3 processing. It does not require high performance of access devices, reducing network construction costs.
• Authentication packets and data packets are transmitted through different logical interfaces, improving network security.

802.1X Authentication System

As shown in Figure 1-1, the 802.1X authentication system uses a standard client/server architecture with three components: client, access device, and authentication server.

Figure 1-1 802.1X authentication system

• The client is usually a user terminal. The user triggers 802.1X authentication using client software. The client must support Extensible Authentication Protocol over LAN (EAPoL).
• The access device is usually a network device that supports the 802.1X protocol. It provides a port, either physical or logical, for the client to access the LAN.
• The authentication server, typically a RADIUS server, carries out authentication, authorization, and accounting on users.

Overview

In the 802.1X authentication system, the client, access device, and authentication server exchange information using the Extensible Authentication Protocol (EAP). EAP can run without an IP address over various bottom layers, including the data link layer and upper-layer protocols (such as UDP and TCP). This offers great flexibility to 802.1X authentication.

• The EAP packets transmitted between the client and access device are encapsulated in EAPoL format and transmitted across the LAN.
• You can determine to use either of the following authentication modes between the access device and authentication server based on the client support and network security requirements:
  • EAP termination mode: The access device terminates EAP packets and encapsulates them into RADIUS packets. The authentication server then uses the standard RADIUS protocol to implement authentication, authorization, and accounting.
  • EAP relay mode: The access device directly encapsulates the received EAP packets into RADIUS using EAP over RADIUS (EAPoR) packets, and then transmits these packets over a complex network to the authentication server.

EAP Packet

Figure 1-2 EAP packet

EAPoL Packet

EAPoL is a packet encapsulation format defined by the 802.1X protocol. EAPoL is mainly used to transmit EAP packets over a LAN between the client and access device. The following figure shows the format of an EAPoL packet.

Figure 1-3 EAPoL packet

EAPoR

To support EAP relay, the following attributes are added to the RADIUS protocol:

• EAP-Message: is used to encapsulate EAP packets.
• Message-Authenticator: is used to authenticate and verify authentication packets to protect against spoofing of invalid packets.

The following figure shows the format of an EAPoR packet.

Figure 1-4 EAPoR packet

Guidelines for Selecting Authentication Modes

• The EAP relay mode simplifies the processing on the access device and supports various authentication methods. However, the authentication server must support EAP and have high processing capability. The commonly used authentication modes include EAP-TLS, EAP-TTLS, and EAP-PEAP. EAP-TLS has the highest security because it requires a certificate to be loaded on both the client and authentication server. EAP-TTLS and EAP-PEAP are easier to deploy since the certificate needs to be loaded only on the authentication server, but not the client.
• The EAP termination mode is advantageous in that mainstream RADIUS servers support Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) authentication, eliminating the need for server upgrade. However, the workload on the access device is heavy because it needs to extract the client authentication information from the EAP packets sent by the client and encapsulate the information using the standard RADIUS protocol. In addition, the access device does not support other EAP authentication methods except MD5-Challenge. In CHAP authentication, passwords are transmitted in cipher text; in PAP authentication, passwords are transmitted in plain text. CHAP provides higher security and is recommended.

Triggering of 802.1X Authentication

802.1X authentication can be triggered in one of the following scenarios:

• A client sends an EAPoL-Start packet.
• A client sends a DHCP, ARP, DHCPv6, ND, or any packet.
• The device sends an EAP-Request/Identity packet.

Authentication Processes in EAP Relay and EAP Termination Modes

In the 802.1X authentication system, the access device exchanges information with the RADIUS server in EAP relay or EAP termination mode. Figure 1-5 and Figure 1-6 respectively show the 802.1X authentication processes in EAP relay and EAP termination modes. In both processes, authentication is initiated by the client.

Figure 1-5 Authentication process in EAP relay mode

1. To access an extranet, a user starts the 802.1X client program, enters the applied and registered user name and password, and initiates a connection request. At this time, the client sends an EAPoL-Start packet to the access device to start the authentication process.
2. After receiving the EAPoL-Start packet, the access device returns an EAP-Request/Identity packet to the client for its identity.
3. Upon receipt of the EAP-Request/Identity packet, the client sends an EAP-Response/Identity packet that contains the user name to the access device.
4. The access device encapsulates the EAP-Response/Identity packet into a RADIUS Access-Request packet and sends the RADIUS packet to the authentication server.
5. After receiving the user name forwarded by the access device, the RADIUS server searches the user name table in the database for the corresponding password, encrypts the password with a randomly generated MD5 challenge, and sends a RADIUS Access-Challenge packet containing the MD5 challenge to the access device.
6. The access device forwards the MD5 challenge sent by the RADIUS server to the client.
7. Upon receipt of the MD5 challenge, the client encrypts the password with the MD5 challenge, generates an EAP-Response/MD5-Challenge packet, and sends the packet to the access device.
8. The access device encapsulates the EAP-Response/MD5-Challenge packet into a RADIUS Access-Request packet and sends the RADIUS packet to the RADIUS server.
9. The RADIUS server compares the received encrypted password with the locally encrypted password. If the two passwords match, the user is considered to be valid and the RADIUS server sends a RADIUS Access-Accept packet (authentication is successful) to the access device.
10. After receiving the RADIUS Access-Accept packet, the access device sends an EAP-Success packet to the client, changes the port state to authorized, and allows the user to access the network through the port.
11. When the user is online, the access device periodically sends a handshake packet to the client to monitor the user.
12. After receiving a handshake packet, the client sends a response packet to the access device, indicating that the user is still online. By default, the access device disconnects the user if it does not receive any response from the client after sending two consecutive handshake packets. The handshake mechanism allows the access device to detect unexpected user disconnections.
13. To go offline, the client sends an EAPoL-Logoff packet to the access device.
14. The access device changes the port state from authorized to unauthorized and sends an EAP-Failure packet to the client.

Figure 1-6 Authentication process in EAP termination mode

In EAP termination mode, the MD5 challenge for encrypting the user password is randomly generated by the access device, instead of the authentication server in EAP relay mode. Besides, in EAP termination mode, the access device uses the CHAP protocol to encapsulate the user name, challenge, and password encrypted by the client into standard RADIUS packets and sends them to the authentication server for authentication. In EAP relay mode, in contrast, the access device is only responsible for encapsulating EAP packets into RADIUS packets and transparently transmitting them to the authentication server.

VLAN

To prevent unauthenticated users from accessing restricted network resources, the restricted network resources and unauthenticated users are allocated to different VLANs. After a user is authenticated, the authentication server returns an authorized VLAN to the user. The access device then changes the VLAN to which the user belongs to the authorized VLAN, with the interface configuration remaining unchanged. The authorized VLAN takes precedence over the VLAN configured on the interface. That is, the authorized VLAN takes effect after the authentication succeeds, and the configured VLAN takes effect after the user goes offline. When the RADIUS server assigns an authorized VLAN, the following standard RADIUS attributes must be used together:

• Tunnel-Type: This attribute must be set to VLAN or 13.
• Tunnel-Medium-Type: This attribute must be set to 802 or 6.
• Tunnel-Private-Group-ID: The value can be a VLAN ID or VLAN description.

ACL

After a user is authenticated, the authentication server assigns an ACL to the user. Then, the access device controls the user packets according to the ACL.

• If the user packets match the permit rule in the ACL, the packets are allowed to pass through.
• If the user packets match the deny rule in the ACL, the packets are discarded.

The RADIUS server can assign an ACL to a user in either of the following modes:

• Static ACL assignment: The RADIUS server uses the standard RADIUS attribute Filter-Id to assign an ACL ID to the user. In this mode, the ACL and corresponding rules are configured on the access device in advance.
• Dynamic ACL assignment: The RADIUS server uses the RADIUS attribute HW-Data-Filter extended by Huawei to assign an ACL ID and corresponding rules to the user. In this mode, the ACL ID and ACL rules are configured on the RADIUS server.

UCL

A User Control List (UCL) is a collection of network terminals such as PCs and smartphones. The administrator can add users having the same network access requirements to a UCL, and configure a network access policy for the UCL, greatly reducing the administrator's workload. The RADIUS server assigns a UCL to a specified user in either of the following modes:

• Assigns the UCL name through the standard RADIUS attribute Filter-Id.
• Assigns the UCL ID through the RADIUS attribute HW-UCL-Group extended by Huawei.

You must configure the UCL and its network access policy on the access device in advance regardless of the UCL authorization mode used.

Free Rule

A free rule allows users to obtain certain network access rights before they are authenticated, to meet basic network access requirements.

You can configure either a common free rule or an ACL-defined free rule. A common free rule is determined by parameters such as the IP address, MAC address, interface, and VLAN, while an ACL-defined free rule is determined by ACL rules. Both the rules can specify the destination IP address that users can access before being authenticated. An ACL-based free rule can also define the name of a destination domain that users can access before being authenticated.

Sometimes, defining a free rule by domain name is simpler and more convenient than defining a free rule by IP address. This is because a domain name is easier to remember. For example, some users who do not have an authentication account must first log in to the official website of a carrier and apply for a member account, or log in using a third-party account such as a Twitter or Facebook account. In this case, you can configure ACL-defined free rules to specify domain names of the websites that users can access before they are authenticated.

Re-authentication for 802.1X-authenticated Users

If the administrator modifies parameters such as access rights and authorization attributes of an online user on the authentication server, the user must be re-authenticated to ensure user validity. If re-authentication is configured for online 802.1X-authenticated users, the access device sends user authentication parameters (saved after users go online) to the authentication server for re-authentication. If the user authentication information on the authentication server remains unchanged, the user keeps online. If the information has been modified, the user is disconnected and needs to be re-authenticated. Table 1-5 lists the re-authentication modes for 802.1X-authenticated users.

Re-authentication for Users in Abnormal Authentication State

The access device records entries for users in pre-connection state (that is, users who have not been authenticated or have failed the authentication), and grants corresponding network access rights to the users. You can configure the access device to re-authenticate these users based on user entries, so that they can obtain normal network access rights in a timely manner.

If a user fails the re-authentication before the user entry aging time expires, the access device deletes the user entry and reclaims the granted network access rights. If a user is successfully re-authenticated before the user entry aging time expires, the access device adds a user-authenticated entry and grants corresponding network access rights to the user. Table 1-6 lists the methods of configuring re-authentication modes for users in abnormal authentication state.

A Client Logs Out

A user sends an EAPoL-Logoff packet through the client software to log out. Upon receipt of the packet, the access device returns an EAP-Failure packet to the client and changes the port status from authorized to unauthorized.

Figure 1-7 Client logout process

The Access Device Controls User Logout

The access device controls user logout in either of the following ways:

• Run the cut access-user command to force a user to go offline.
• Configure user detection to check whether a user is online. If the user does not respond within a specified period, the access device considers the user to be offline and deletes the user entry.

If an administrator detects that an unauthorized user is online or wants a user to go offline and then go online again during a test, the administrator can run the cut access-user command on the access device to force the user to go offline. For a user in normal access state, the access device checks the online status of the user through ARP probing. If the access device detects that the user goes offline, it logs the user out and deletes the user entry.

Figure 1-8 User logout detection process

Assume that the handshake period of a user is 3T, which can be set by running the authentication timer handshake-period handshake-period command. Here, T = handshake-period/3.

1. The user sends any packet to trigger 802.1X authentication, and the detection timer starts.
2. Within several T periods, the access device receives traffic from the client and the user keeps online.
3. The user sends the last packet. When the current T period expires, the access device determines that the user is online because traffic is still received from the client, and resets the detection timer.
4. The access device does not receive traffic from the client within a T period, and sends the first ARP request packet. The client does not respond.
5. The access device does not receive traffic from the client within another T period, and sends the second ARP request packet. The client does not respond.
6. The access device does not receive traffic from the client within a third T period. The access device determines that ARP probing fails and deletes the user entry.

The RADIUS Server Forces a User to Log Out

The RADIUS server forces a user to log out using either of the following methods:

• Sends a Disconnect Message (DM) to an access device to force a user to go offline.
• Uses the standard RADIUS attributes Session-Timeout and Termination-Action. The Session-Timeout attribute specifies the online duration timer of a user. The value of Termination-Action is set to 0, indicating that the user is disconnected by the RADIUS server when the online duration timer expires.

Timeout Timers for EAP-Request/Identity Packets

This section discusses the timers that control the timeout and retry behavior of an 802.1X-enabled interface for sending EAP-Request/Identity packets.

During 802.1X authentication, the device sends an EAP-Request/Identity packet for the user name. The device waits for a period of time defined by a timer, and then sends another EAP-Request/Identity packet if no response is received. The number of times it resends the EAP-Request/Identity packets is defined by the dot1x retry max-retry-value variable.

Figure 1-9 shows the operation of the timer when MAC address bypasss authentication is not configured. If EAP-Request/Identity packets time out, the device sends an EAP failure packet to the client and starts a failover mechanism (Portal authentication or granting specified access permissions) if configured. In this situation, the timer is defined by the dot1x timer tx-period tx-period command. The total time it takes for 802.1X to time out is determined by the following formula:

Timeout = (max-retry-value +1) x tx-period-value

Figure 1-9 Timeout timer for EAP-Request/Identity packets when MAC address bypass authentication is not configured

Figure 1-10 shows the operation of the timer when MAC address bypass authentication is configured. The device performs 802.1X authentication first and starts the timer defined by the dot1x timer mac-bypass-delay delay-time-value command. If 802.1X authentication is not successful before the timer expires, the device performs MAC address authentication for terminals. In this situation, the interval at which the device resends an EAP-Request/Identity packet is the integer of the result calculated as follows: delay-time-value/(max-retry-value+1).

Figure 1-10 Timeout timer for EAP-Request/Identity packets when MAC address bypass authentication is not configured

Timeout Timers for EAP-Request/MD5 Challenge Packets

This section discusses the timers that control the timeout and retry behavior of an 802.1X-enabled interface for sending EAP-Request/MD5 Challenge packets.

During 802.1X authentication, the device sends an EAP-Request/MD5 Challenge packet to request the client's password in ciphertext. It waits for a period of time defined by the client timeout timer, and then sends another EAP-Request/MD5 Challenge packet. The number of times it resends the EAP-Request/MD5 Challenge packets is defined by the dot1x retry max-retry-value variable. This prevents repeated retransmission of authentication requests, which occupies lots of resources.

As shown in Figure 1-11, EAP-Request/MD5 Challenge packets time out, and then the device sends an EAP Failure packet to the client and starts a failover mechanism (MAC address authentication, Portal authentication, or granting specified access permissions) if configured. The total time it takes for EAP-Request/MD5 Challenge packets to time out is determined by the following formula:

Timeout = (max-retry-value + 1) x client-timeout-value

Figure 1-11 Timeout timer for EAP-Request/MD5 Challenge packets

Quiet Timer

This section discusses the timer that controls when 802.1X restarts after the number of failed 802.1X authentication attempts within 60 seconds reaches the value specified by the dot1x quiet-times fail-times command.

If 802.1X fails and there are no failover mechanisms enabled, the device waits for a period of time known as the quiet-period (configured by the dot1x timer quiet-period quiet-period-value command). During this period of time, the device discards users' 802.1X authentication request packets, avoiding frequent authentication failures.

Figure 1-12 Quiet timer