No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

S600-E V200R013C00 Configuration Guide - User Access and Authentication

This document describes the configurations of User Access and Authentication Configuration, including AAA, NAC, and Policy Association.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Understanding 802.1X Authentication

Understanding 802.1X Authentication

Overview of 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 2-1, the 802.1X authentication system uses a standard client/server architecture with three components: client, access device, and authentication server.

Figure 2-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.

802.1X Authentication Protocol

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 2-2  EAP packet
Table 2-2  Fields in an EAP packet

Field

Bytes

Description

Code 1 Indicates the type of an EAP data packet. The options are as follows:
  • 1: Request
  • 2: Response
  • 3: Success
  • 4: Failure
ID 1 Is used to match a Response packet with the corresponding Request packet.
Length 2 Indicates the length of an EAP data packet, including the Code, ID, Length, and Data fields. Bytes outside the range of the Length field are treated as padding at the data link layer and ignored on reception.
Data Zero or multiple bytes The format of the Data field is determined by the Code field.
  • When the value of the Code field is 1 or 2, the EAP data packet is a Request or Response packet, and the Data field contains the Type and Type Data fields, as shown in the preceding figure. The Type field is one byte long and indicates the type of the Request or Response packet. The Type Data field is multiple bytes long and its value is determined by the Type field.
  • When the value of the Code field is 3 or 4, the EAP data packet is a Success or Failure packet and does not have the Data field.
Table 2-3  Common values of the Type field

Type Field Value

Packet Type

Description

1 Identity Requests or returns the user name information entered by a user.
2 Notification Transmits notification information about some events, such as password expiry and account locking. It is an optional message.
3 NAK Indicates negative acknowledgment and is used only in a Response packet. For example, if the access device uses an authentication method not supported by the client to initiate a request, the client can send a Response/NAK packet to notify the access device of the authentication methods supported by the client.
4 MD5-Challenge Indicates that the authentication method is MD5-Challenge.
5 OTP Indicates that the authentication method is One-Time Password (OTP). For example, during e-banking payment, the system sends a one-time password through an SMS message.
6 GTC Indicates that the authentication method is Generic Token Card (GTC). A GTC is similar to an OTP except that a GTC usually corresponds to an actual device. For example, many banks in China provide a dynamic token for users who apply for e-banking. This token is a GTC.
13 EAP-TLS Indicates that the authentication method is EAP-TLS.
21 EAP-TTLS Indicates that the authentication method is EAP-TTLS.
25 EAP-PEAP Indicates that the authentication method is EAP-PEAP.
254 Expanded Types Indicates an expanded type, which can be customized by vendors.
255 Experimental use Indicates a type for experimental use.
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 2-3  EAPoL packet
Table 2-4  Fields in an EAPoL packet

Field

Bytes

Description

PAE Ethernet Type 2 Indicates the protocol type. The value is fixed at 0x888E.
Protocol Version 1 Indicates the protocol version number supported by the EAPoL packet sender.
  • 0x01: 802.1X-2001
  • 0x02: 802.1X-2004
  • 0x03: 802.1X-2010
Type 1 Indicates the type of an EAPoL data packet:
  • 00: EAP-Packet, which is an authentication packet that carries authentication information.
  • 01: EAPoL-Start, which an authentication start packet sent by a client.
  • 02: EAPoL-Logoff, which is a logout request packet sent by a client.
  • 03: EAPoL-Key, which carries key information.

Note that the EAPoL-Start, EAPoL-Logoff, and EAPoL-Key packets are transmitted only between the client and access device.

Length 2 Indicates the data length, that is, the length of the Packet Body field, in bytes. The value 0 indicates that the Packet Body field does not exist. For the EAPoL-Start and EAPoL-Logoff packets, the values of the Length field are both 0.
Packet Body 2 Indicates the data content.
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 2-4  EAPoR packet
Table 2-5  Fields in an EAPoR packet

Field

Bytes

Description

Code 1 Indicates the type of a RADIUS packet.
Identifier 1 Is used to match a Response packet with the corresponding Request packet, and to detect the Request packet retransmitted within a certain period. After the client sends a Request packet, the authentication server sends a Response packet with the same Identifier value as the Request packet.
Length 2 Indicates the length of a RADIUS packet. Bytes outside the range of the Length field are treated as padding and ignored on reception. If the length of a received packet is less than the Length value, the packet is discarded.
Response Authenticator 16 Is used to verify the Response packet sent by the RADIUS server and encrypt the user password.
Attributes Variable length

Indicates the packet content body, which carries authentication, authorization, and accounting information and provides configuration details of the Request and Response packets. The Attributes field may contain multiple attributes, each of which consists of Type, Length, and Value.

  • Type: indicates the attribute type. The length is one byte and the value ranges from 1 to 255.
  • Length: indicates the length of an attribute, including Type, Length, and Value. The length is measured in bytes.
  • Value: indicates the attribute information. The format and content are dependent on Type and Length. The maximum length is 253 bytes.
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.

802.1X Authentication Process

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, 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 2-5 and Figure 2-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 2-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 2-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.

802.1X Authorization

Authentication checks whether the identity of the user who attempts to access the network is valid. Authorization specifies the network access rights that the authorized user can have, that is, the resources that the authorized user can access. VLANs, ACLs, and UCLs are often used for authorization. RADIUS authorization is used as an example. For details about other authorization methods and more authorization parameters, see Authorization Scheme.

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.

802.1X Re-authentication

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 2-6 lists the re-authentication modes for 802.1X-authenticated users.

Table 2-6  Re-authentication modes for 802.1X-authenticated users
Configuration Completed On To Configuration Command
Access device Perform periodic re-authentication for 802.1X-authenticated users.

dot1x reauthenticate

dot1x timer reauthenticate-period reauthenticate-period-value

Perform one-time re-authentication for a user with the specified MAC address. dot1x reauthenticate mac-address mac-address
RADIUS server Deliver 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 1, indicating that the user is re-authenticated when the online duration timer expires. N/A
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 2-7 lists the methods of configuring re-authentication modes for users in abnormal authentication state.

Table 2-7  Methods of configuring re-authentication for users in abnormal authentication state
User State Configuration Command
RADIUS server in Down state authentication event authen-server-up action re-authen: Enables user re-authentication when the RADIUS server is Up.
Authentication failure authentication timer re-authen authen-fail re-authen-time: Enables periodic re-authentication for users who fail to be authenticated.
Pre-connection authentication timer re-authen pre-authen re-authen-time: Enables periodic re-authentication for users in pre-connection state.

Logout of 802.1X-authenticated Users

When users go offline but the access device and RADIUS server do not detect the offline events, the following problems may occur:
  • The RADIUS server still performs accounting for the users, causing incorrect accounting.
  • Unauthorized users may spoof IP addresses and MAC addresses of authorized users to access the network.
  • If there are many offline users, these users are still counted as access users of the device. As a result, other users may fail to access the network.

The access device needs to detect user logout immediately, delete the user entry, and instruct the RADIUS server to stop accounting.

A user may log out in the following scenarios: The user proactively logs out on the client, the access device controls user logout, and the RADIUS server logs out the user.

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 2-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 2-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.

802.1X Timers

802.1X relies on several timers to control the number of packet retransmission times and timeout interval. This section outlines the timers on the device that are relevant to the 802.1X authentication process.

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 2-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 2-9  Timeout timer for EAP-Request/Identity packets when MAC address bypass authentication is not configured

Figure 2-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 2-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 2-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 2-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 2-12  Quiet timer
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100066170

Views: 23145

Downloads: 6

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next