Triple Authentication Technology White Paper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Contents

Overview·· 1

Introduction to triple authentication· 1

Typical networking with triple authentication· 1

Introduction to the technical support offered by triple authentication· 1

802.1X· 1

802.1X authentication system·· 2

802.1X packet exchange methods· 2

Packet formats· 3

802.1X authentication modes· 5

802.1X authentication initiation· 9

MAC authentication· 9

Format of the user account for MAC authentication· 10

Authentication method of MAC authentication· 11

Web authentication· 12

Web authentication system·· 12

Authentication methods for Web authentication· 14

Working mechanism of triple authentication· 16

Triggering method for triple authentication· 16

Authentication order of triple authentication· 16

Triple authentication support for authorization ISP domain· 17

ISP domain types· 17

Adding users to domains· 19

Principle of domain switchover 20

Triple authentication support for microsegment assignment 21

Triple authentication support for VSI assignment 21

Authorization VSI 21

Auth-fail VSI 21

Server unreachable critical VSI 22

Triple authentication support for VLAN assignment 22

Authorization VLAN· 22

Auth-fail VLAN· 22

Server unreachable critical VLAN· 22

Triple authentication support for re-authentication· 23

Typical applications· 23

 

Overview

Introduction to triple authentication

To meet customer requirements for authenticating different types of users on the same device port, the triple authentication method is introduced. As a hybrid authentication method, triple authentication enables a Layer 2 access port to perform 802.1X, MAC, and Web authentication. A terminal can access the network if it passes one type of authentication on that port, thereby enhancing the flexibility of the authentication environment deployment.

Typical networking with triple authentication

In diverse network environments with various terminal forms, different terminals support different access authentication methods. As shown in Figure 1, some terminals can only perform MAC authentication (e.g., printers); some terminals with installed 802.1X client software can conduct 802.1X authentication; some terminals only want to authenticate via web access. To flexibly adapt to the variety of authentication requirements in these network environments, it's necessary to deploy triple authentication on the ports of user access, allowing users to select any suitable authentication mechanism. Access can be achieved by successfully passing a single authentication method, eliminating the need for multiple authentications.

Figure 1 Typical application network diagram for triple authentication

 

Introduction to the technical support offered by triple authentication

802.1X

The 802.1X protocol is a Port-based Network Access Control Protocol that authenticates users and devices on local area network (LAN) access device ports to control user equipment's access to network resources.

802.1X authentication system

In the 802.1X system, there are three entities: the client, device, and authentication server, as shown in Figure 2.

Figure 2 802.1X architecture diagram

 

·     The client is a user terminal requesting access to the local area network (LAN), which is authenticated by the device within the LAN. The client must have client software installed that supports 802.1X authentication.

·     The device in the local area network (LAN) is a network device that controls client access. Located between the client and the authentication server, the device provides the client with a port (physical port or logical port) to access the LAN, and authenticates the connected client through interaction with the authentication server.

·     The authentication server is used for client authentication, authorization, and accounting, typically as a Remote Authentication Dial-In User Service (RADIUS) server. The authentication server qualifies the legitimacy of the client based on the client authentication information transmitted from the device and informs the device side of the result. The device then decides whether to allow client access. In some smaller network environments, the role of the authentication server can also be replaced by the device, which performs local client authentication, authorization, and accounting.

 

NOTE: The Lightweight Directory Access Protocol (LDAP) server can also be used for client authentication and authorization. However, the LDAP server cannot provide accounting services. The content related to remote authentication servers in this white paper will be introduced using the RADIUS server as an example.

 

802.1X packet exchange methods

The 802.1X system uses the Extensible Authentication Protocol (EAP) to facilitate the interaction of authentication information between the client, device, and authentication server. EAP is a client/server authentication framework that supports various authentication methods, such as MD5-Challenge, EAP-TLS (Extensible Authentication Protocol -Transport Layer Security), PEAP (Protected Extensible Authentication Protocol), and more. Between the client and the device, EAP messages are carried in data frames in the EAPoL (Extensible Authentication Protocol over LAN) encapsulation format. Between the device and the RADIUS server, the interaction of EAP messages has two processing mechanisms, EAP relay and EAP termination.

EAP relay

The device relays the received EAP messages, using the EAP over RADIUS (EAPOR) encapsulation format to carry them in RADIUS messages, which are transmitted to the RADIUS server.

Figure 3 Schematic diagram of EAP relay

 

Under this processing mechanism, the EAP authentication process takes place between the client and the RADIUS server. The RADIUS server acts as an EAP server to handle the client's EAP access-request, and the device serves merely as a relay, merely forwarding the EAP messages.

EAP termination

The device terminates the EAP authentication process, encapsulates the client authentication information received in EAP messages into a standard RADIUS message, and uses the PAP (Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol) methods for authentication with the server.

Figure 4 Schematic diagram of EAP termination

 

Comparison between EAP relay and EAP termination

Table 1 Comparison between EAP relay and EAP termination

Packet exchange method	Advantage	Limitations
EAP relay	·     Supports various EAP authentication methods. ·     The configuration and processing on the access device are simple.	Generally, a RADIUS server needs to support EAP-Message and Message-Authenticator attributes, as well as the EAP authentication method used by the client.
EAP termination	Works with any RADIUS server that supports PAP or CHAP authentication.	·     Supports only the following EAP authentication methods: ¡     MD5-Challenge EAP authentication. ¡     The username and password EAP authentication initiated by an iNode 802.1X client. ·     The processing is complex on the access device.

 

Packet formats

EAP

The format of EAP messages is shown in Figure 5.

Figure 5 EAP message format

 

·     Code: The type of the EAP message, including Request (1), Response (2), Success (3), and Failure (4).

·     Identifier: It is used to match the Request message and the Response message.

·     Length: The length of the EAP message, measured in bytes, includes the Code, Identifier, Length, and Data fields.

·     Data: The content of the EAP message. This field only exists when the EAP message type is Request or Response. It contains the request type (or the response type) and the type data. Type 1 (Identity) and type 4 (MD5-Challenge) are two examples for the type field.

EAPOL

EAPOL is an encapsulation technology defined by the 802.1X protocol to carry EAP messages, primarily used for transmitting EAP protocol messages between the client and the device in a local area network (LAN). The format of an EAPOL data packet is shown in Figure 6.

Figure 6 EAPOL data packet format

 

·     PAE Ethernet Type: This indicates the protocol type. The protocol type for EAPOL is 0x888E.

·     Protocol Version: Indicates the EAPOL protocol version number supported by the sender of the EAPOL data frame.

·     Type: Indicates the EAPOL data frames type. The EAPOL data frames type currently supported on the device can be found in Table 2.

Table 2 EAPOL data frames type

Type value	Data Frame Type	Description
0x00	EAP-Packet	The authentication information frame (I-frame) is used to carry EAP messages between the client and the device.
0x01	EAPOL-Start	The authentication initiating frame is used for the client to launch an access-request to the device side.
0x02	EAPOL-Logoff	The exit request frame is used for the client to initiate an offline request to the device end.

 

·     Length: This indicates the length of the data field, which is the length of the Packet Body field, measured in bytes. When the type of the EAPOL data frame is either EAPOL-Start or EAPOL-Logoff, this field value is 0, indicating that there is no Packet Body field following.

·     Packet Body: The content of the data field.

EAP over RADIUS

To support EAP authentication, RADIUS has added two attributes: EAP-Message (EAP message) and Message-Authenticator (message authentication code). In a packet containing the EAP-Message attribute, the Message-Authenticator attribute must also be included. For RADIUS packet format, see AAA configuration in Security Configuration Guide.

·     EAP-Message

As shown in Figure 7, the EAP-Message attribute is used to encapsulate EAP packets. The Value field can be up to 253 bytes long. If the EAP packet length is greater than 253 bytes, it can be fragmented and sequentially encapsulated in multiple EAP-Message attributes.

Figure 7 EAP-Message attribute format

 

·     Message-Authenticator

As shown in Figure 8, the Message-Authenticator attribute is used to verify the integrity of the RADIUS messages that carry the EAP-Message attribute during the EAP authentication process to prevent the messages from being tampered. If the integrity check value calculated by the receiver for the received RADIUS messages is inconsistent with the Value of the Message-Authenticator attribute carried in the message, the message will be considered invalid and discarded.

Figure 8 Message-Authenticator attribute format

 

802.1X authentication modes

Currently, the device supports two types of 802.1X authentication, remote authentication through a RADIUS server and local authentication on the access device.

Authentication via RADIUS server for 802.1X authentication

The device end supports interacting with the remote RADIUS server using either the EAP relay method or the EAP termination method. The following description of the 802.1X authentication process is based on the example of the client actively initiating authentication.

1.     EAP relay method

This method is stipulated by the IEEE 802.1X Standards, which carries EAP in other high level protocols, such as EAP over RADIUS, allowing EAP messages to traverse complex networks and reach the authentication server. In general, the RADIUS server needs to support EAP attributes: EAP-Message and Message-Authenticator.

As shown in Figure 9, take the MD5-Challenge type of EAP authentication as an example, the specific authentication process is as follows.

Figure 9 Authentication process of the IEEE 802.1X system using the EAP relay method

 

a.     When a user needs to access an external network, they open the 802.1X client program, enter their username and password, and initiate a connection request. At this point, the client program sends an access-request frame (EAPOL-Start) to the device, initiating an authentication process.

b.     Upon receiving the access-request frame from the device end, an Identity type request frame (EAP-Request/Identity) will be issued, asking the user's client program to transmit the entered username.

c.     The client program responds to the request sent by the device, transmitting user name information to the device via an Identity type response frame (EAP-Response/Identity).

d.     The device end encapsulates the EAP message from the response frame transmitted by the client within the RADIUS message (RADIUS Access-Request), and sends it to the authentication server for processing.

e.     Upon receiving the user information transmitted from the device, the RADIUS server compares this information with the user list in its database. It finds the corresponding password for the username, and uses a randomly generated MD5 Challenge to encrypt the password. Meanwhile, this MD5 Challenge is sent to the device via RADIUS Access-Challenge message.

f.     The device end forwards the MD5 Challenge sent by the RADIUS server to the client.

g.     Upon receiving the MD5 Challenge transmitted by the device, the client encrypts the password using this Challenge, generating an EAP-Response/MD5 Challenge message, and then transmits it back to the device.

h.     The device end encapsulates this EAP-Response/MD5 Challenge message in a RADIUS message (RADIUS Access-Request) and transmits it to the RADIUS server.

i.     The RADIUS server compares the received encrypted password info with the locally encrypted password info. If they match, it considers the user to be legitimate and transmits an authentication pass message (RADIUS Access-Accept) to the device end.

j.     Upon receiving an authentication pass message, the device transmits an authentication success frame (EAP-Success) to the client, changes the port state to authorized, and allows the user to access the network through the port.

k.     During the user's online period, the device side regularly monitors the user's online status by transmitting handshake messages to the client side.

l.     Upon receiving the handshake message, the client transmits a response message to the device, indicating that the user is still online. By default, if the device does not receive a response to its two handshake request messages, the device will take the user offline to prevent the device from being unaware of the user going offline due to an anomaly.

m.     The client can transmit (Tx) an EAPOL-Logoff frame to the device, actively requesting to go offline.

n.     The device changes the port state from an authorized state to an unauthorized state, and transmits an EAP-Failure message to the client.

 

NOTE: In the EAP relay mode, it's necessary to ensure a consistent EAP authentication method is selected on both the client and the RADIUS server. On the device, you simply need to activate the EAP relay mode via the dot1x authentication-method eap command.

 

2.     EAP termination method

This method terminates EAP messages at the device end and maps them into RADIUS messages, using the standard RADIUS protocol for authentication, authorization, and accounting. The device end can use the PAP or CHAP authentication methods with the RADIUS server. As shown in Figure 10, taking CHAP authentication as an example, the specific authentication process is as follows.

Figure 10 Authentication process of the EAP termination method in the IEEE 802.1X authentication system

 

a.     When the user needs to access the external network, they open the 802.1X client program, enter their username and password, and initiate a connection request. At this point, the client program sends an access-request frame (EAPOL-Start) to the device, beginning an authentication process.

b.     Upon receiving the access-request frame, the device initiates an Identity-class request frame (EAP-Request/Identity) asking the user's client program to transmit the entered username.

c.     The client program responds to the request issued by the device, transmitting the user name information to the device through a response frame of the Identity type (EAP-Response/Identity).

d.     Upon receiving the user information from the device side, an MD5 Challenge will be randomly generated and transmitted to the client side.

e.     After the client receives the MD5 Challenge transmitted from the device side, it uses this Challenge to password the password, creating an EAP-Response/MD5 Challenge packet, and then transmits it to the device side.

f.     The device and server use CHAP authentication, transmitting the CHAP-Response/MD5 Challenge message encapsulated in a RADIUS message (RADIUS Access-Request) to the RADIUS server.

g.     The RADIUS server compares the received encrypted password info with the password info in its database that has been encrypted. If they match, it considers the user to be a legitimate user and transmits an authentication pass message (RADIUS Access-Accept) to the device end.

h.     After the device receives the authentication pass message, it transmits an authentication success frame (EAP-Success) to the client, changes the port state to authorized, and allows the user to access the network through the port.

i.     The subsequent process is consistent with the EAP relay.

Compared to the authentication process of EAP relay, the difference with EAP termination is that the MD5 challenge used to encrypt user password information is generated by the device end. Then, the device end will transmit user names, the MD5 challenge, and the encrypted password information of clients to the RADIUS server for related authentication processing.

Authentication using a local method for 802.1X authentication

In smaller network environments, the role of the authentication server can be replaced by the device end, meaning that the device end provides local authentication for the client. When local authentication is used for 802.1X authentication, it's necessary to manually add the authenticated username and password on the device. After the user login, if the username and password match successfully, access to the network can be gained.

802.1X authentication initiation

The authentication process of 802.1X can be initiated by the client side, or it can be started from the access device side.

802.1X client as the initiator

·     Multicast trigger: The client actively transmits an EAPOL-Start message to the access device to trigger authentication, the destination address of this message is the multicast MAC address 01-80-C2-00-00-03.

·     Broadcast trigger: The client actively transmits an EAPOL-Start packet to the access device to trigger an access-request. The destination address of this packet is the broadcast MAC address. This method can solve the problem that some devices in the network do not support the above-mentioned multicast packet, resulting in the device's inability to receive the client's access-request.

 

NOTE: Currently, the iNode 802.1X client supports the broadcast trigger method.

 

Access device as the initiator

The access device can initiate 802.1X authentication to support clients that cannot actively transmit EAPOL-Start messages.

The access device supports the following modes:

·     Multicast trigger: The device actively multicasts an Identity type EAP-Request frame to the client at a certain time interval (configurable, default is 30 seconds) to trigger authentication.

·     Unicast trigger: When a device receives a message with an unknown source MAC (SMAC), it proactively unicasts an EAP-Request frame of Identity type to the SMAC address to trigger authentication. If the device does not receive a response from the client within the set duration, it resends the message.

MAC authentication

MAC authentication is an authentication method that controls user access to network resources based on Layer 2 port and MAC address, requiring no client software installation. After detecting a user’s MAC address for the first time on a port with MAC authentication enabled, the device initiates an authentication process for that user. During the authentication process, the user does not need to manually input a username or password. If the user successfully authenticates, the user is allowed to pass through the port to access network resources. Otherwise, the user’s MAC address is set to silent MAC. During the silent period, when a user packet arrives from this MAC address, the device discards it directly to prevent illegal MAC from re-authenticating in a short period.

Format of the user account for MAC authentication

The account format used by users for MAC authentication falls into the following categories:

·     MAC address account: The device uses the source MAC (SMAC) as the username and password for user authentication or uses the MAC address as the username and sets a password. Figure 11 illustrates the case of using the source MAC as the username and password for user authentication.

·     Fixed user account:

¡     Global user account: All MAC authentication users use one fixed username and password specified on the device in place of the user's MAC address as their identity information for authentication, as shown in Figure 12. Since multiple users can be authenticated on the same port, all MAC authentication users on the port use the same fixed username for authentication. Hence, the server only needs to configure one user account to meet authentication requirements for all authenticated users. This is suitable for a network environment where client access is relatively credible.

¡     MAC range-specific user account: MAC authentication also supports setting individual usernames and passwords for users within a specific MAC address range (for instance, setting individual usernames and passwords for specifically designated OUI's MAC addresses). It is essentially using a fixed username and password for users in the specified MAC address range. The server side needs to create corresponding accounts based on the device configuration. As shown in Figure 13.

Figure 11 MAC authentication using MAC address accounts

 

Figure 12 MAC Authentication using a global user account

 

Figure 13 MAC Authentication using MAC range-specific user accounts

 

Authentication method of MAC authentication

Currently, the device supports two types of MAC authentication: remote authentication through RADIUS server or LDAP server, and local authentication on the access device. The following introduces remote authentication with the RADIUS server as an example.

RADIUS server uses MAC authentication as a method of verification

When using RADIUS server authentication for MAC authentication, the device, acting as a RADIUS client, collaborates with the RADIUS server to complete the MAC authentication operation.

·     If a MAC address account is used, without a configured password, the device transmits the detected user MAC address as both the username and password to the RADIUS server for qualification. If a password is configured, the device sends the detected user MAC address as the username and the configured password as the password to the RADIUS server for qualification.

·     If a fixed username account is adopted, the device will use a fixed username and corresponding password designated for a user authenticated via a specified local MAC address as the username and password of the user awaiting authentication. This information is then transmitted to the RADIUS server for verification.

After the RADIUS server authenticates the user, the user who passes the authentication can access the network.

The device and the server authenticate using the PAP or CHAP method. As shown in Figure 14, taking CHAP authentication as an example, the detailed MAC authentication process is as follows.

Figure 14 MAC authentication process

1.     When the access device receives a packet (typically an ARP or DHCP broadcast packet) from the terminal with an unknown source MAC, it triggers MAC authentication.

2.     The device end uses a randomly generated MD5 Challenge to encrypt the user's MAC address and password, then encapsulates the processing result and MD5 Challenge in a RADIUS access-request message to transmit to the RADIUS server.

3.     The RADIUS server encrypts the corresponding user's MAC address and password in the local database using the received MD5 Challenge. If the value matches the device side, the server transmits an authentication pass message to the device.

4.     After receiving the authentication pass message, the device notifies the user of a successful login and allows the user to access the network through the port.

Perform MAC authentication using local authentication methods.

When choosing local authentication for MAC authentication, the user authentication is directly completed on the device. It requires the configuration of the local username and password on the device.

·     If a MAC address account is used, and no password is set, the device will match the detected user's MAC address as both the username and password with the locally configured ones. But if a password is set, the device will use the detected user's MAC address as the username, and the configured password to match with the locally set username and password.

·     If a fixed username account is used, the device matches a fixed username and corresponding password, used by a user authenticated by a pre-specified local MAC address, with the locally-configured username and password for the user to be authenticated.

Once the username and password match successfully, the user can access the network.

Web authentication

Web authentication is a method that verifies the legitimacy of a user's identity through a web page on a Layer 2 interface. When the Web authentication function is turned on at the Layer 2 interface of the access device, unauthenticated users are forced by the device to log in to a specific site while browsing. Users can freely access the Web resources on this site. However, to access Web resources outside this specific site, users must be authenticated on the access device. After authentication, they can access Web resources beyond the specific site.

Web authentication system

The typical network setup for Web authentication is as shown in Figure 15, and it consists of five basic elements: authentication client, access device, Web authentication Web server, Portal authentication server, and AAA authentication server.

Figure 15 Web Authentication System

 

Authentication client

The client system of the user terminal, which runs the HTTP/HTTPS protocol browser, initiates web authentication.

Access device

An access device provides access services. It provides the following features:

·     Before authentication, the access device redirects all user HTTP/HTTPS requests that do not comply with the free-rule to the authentication page.

·     During the authentication process, the access device interacts with the AAA server to accomplish the functions of identity authentication, authorization, and accounting.

·     Once a user passes the authentication, the access device allows the user to access the authorized network resources.

Web authentication Web server

Responsible for providing the authentication page and free Web resources to the authentication client, and for obtaining the user's name, password, and other authentication information. The Web authentication Web server consists of two types: the local Web server and the remote Web server. The local Web server is generally integrated into the access device, while the remote Web server is a Portal Web server.

Portal authentication server

Web authentication employs the Portal authentication server as the authentication server, which is used to interact with the access device, authenticating the authentication client's information.

AAA authentication server

Interacts with the access device to complete user authentication, authorization, and accounting. The currently supported AAA authentication servers include RADIUS server and LDAP server.

·     RADIUS can support authentication, authorization, and accounting for Web authentication users.

·     The LDAP server can support authentication for Web authentication users.

Authentication methods for Web authentication

CHAP/PAP authentication

The specific authentication process of Web authentication via CHAP/PAP methods is shown in Figure 16.

Figure 16 Process of web authentication (CHAP/PAP authentication methods)

 

1.     When a user first visits a Web resource, the HTTP/HTTPS request is passed through a Layer 2 interface with Web authentication function. If the content of the HTTP/HTTPS request is an authentication page or a Web resource in the free access address, the access device allows the HTTP/HTTPS request to pass. If the request is for another Web resource, the access device redirects the HTTP/HTTPS request to the authentication page, where the user enters their username and password to authenticate themselves.

2.     The Web server submits the information entered by the user to the Portal authentication server for verification.

3.     The Portal authentication server interacts with the access device using CHAP authentication. If PAP authentication is used, proceed directly to the next step. The choice of authentication interactive mode is determined by the Portal authentication server.

4.     The Portal authentication server assembles the username and password entered by the user into an access-request message, which is sent to the access device. At the same time, it initiates a timer to wait for the authentication response message.

5.     The access device interacts with the RADIUS server via RADIUS protocol messages, qualifying the user's identity.

6.     The access device transmits an authentication response message to the Portal authentication server, indicating either authentication success or failure.

7.     The H3C authentication server transmits an authentication success or fail message to the client, notifying the client of successful authentication (online) or failure.

8.     If the authentication is successful, the Portal authentication server will also transmit a validation response to the access device.

EAP authentication

The EAP authentication can only be used in conjunction with the iMC's Portal authentication server and iNode Portal client. Furthermore, this function is only supported by the remote Portal authentication server's Web authentication.

The traditional user identity verification method based on usernames and passwords has certain security issues and can't meet the network requirements for high reliability in user identity. On the other hand, the user identity verification method based on digital certificates is often used to establish more secure and reliable network access authentication mechanisms, as it can ensure the security and integrity of data during transmission.

EAP supports various digital certificate-based authentication methods (such as EAP-TLS). It can work in conjunction with Web authentication to provide users with digital certificate-based access authentication services.

Figure 17 Web authentication support for EAP

 

1.     The client initiates an EAP access-request, transmitting the EAP access-request message to the Portal server.

2.     The Portal authentication server transmits the Web authentication request packet to the access device, while simultaneously initiating a timing device to wait for the Web authentication response packet. This authentication request packet includes several EAP-Message attributes, which are used for the encapsulation of the EAP packets transmitted by the client.

3.     After receiving the Web access-request, the access device interacts with the RADIUS server to qualify the user's identity.

4.     The access device transmits a certificate request packet to the Portal authentication server, based on the response information from the RADIUS server. This packet also includes several EAP-Message attributes, carrying the certificate information of the RADIUS server.

5.     Upon receiving the certificate request message from the portal authentication server, it sends an EAP authentication response message to the client, directly transmitting the attribute value of the EAP-Message in the RADIUS server response message to the client.

6.     After verifying the legality of the RADIUS server's identity through a digital certificate, the client continues to initiate an EAP access request. The subsequent authentication process is similar to the interaction process of the first EAP access request message.

7.     Sync with step (2).

8.     Synchronize with step (3).

9.     Upon receiving the authentication pass response message transmitted by the RADIUS server, the access device transmits an authentication response message to the Portal authentication server. This message encapsulates the EAP authentication success or fail message in its EAP-Message attributes.

10.     The Portal authentication server notifies the client of a successful or failed online status based on the authentication result in the authentication response message.

11.     If the authentication is successful, the Portal authentication server will also transmit a validation response to the access device.

Working mechanism of triple authentication

Triggering method for triple authentication

When 802.1X authentication, MAC authentication, and Web authentication functions are enabled on a port simultaneously, different types of terminal packets can trigger different authentication processes.

·     There are two classes of terminal messages that can trigger 802.1X authentication.

¡     The terminal uses the system's built-in 802.1X client or third-party client software to transmit (Tx) EAP protocol messages.

¡     When the access device initiates the unicast trigger function, following the transmission of a packet with an unknown source MAC address by the terminal, the device actively unicasts an EAP-Request frame of Identity type to that MAC address to trigger 802.1X authentication.

·     Trigger MAC Authentication: The terminal transmits a packet with an unknown source MAC (typically an ARP or DHCP broadcast packet).

·     Triggering Web Authentication: The terminal transmits HTTP messages.

Authentication order of triple authentication

When multiple authentication methods are enabled on the same port, the specific authentication scenarios for the same terminal are as follows:

·     If a certain authentication method fails on the terminal, it will still attempt other methods of authentication in the specified order.

·     After the terminal successfully goes online through a certain authentication method, it will decide whether to try other types of authentication based on the currently passed authentication method.

Currently, the device supports two types of authentication sequences.

·     By default, the authentication sequence for a terminal is: 802.1X -> MAC authentication -> Web authentication.

·     The authentication order on the terminal can be changed to MAC authentication -> 802.1X -> Web authentication.

802.1X -> MAC authentication -> Web authentication

·     When the 802.1X unicast trigger function is activated, any terminal message from an unknown source MAC will first trigger 802.1X authentication.

¡     If the 802.1X authentication is successful, the terminal will not undergo any other form of authentication subsequently.

¡     If the 802.1X authentication fails, authentication will be carried out in other ways according to the Triggering method for triple authentication.

·     When the 802.1X unicast trigger function is in the off state, according to the Triggering method for triple authentication, different types of terminal messages can trigger different authentication processes.

¡     If the terminal triggers 802.1X authentication and successfully goes online, it will not undergo any other form of authentication subsequently.

¡     If the terminal does not trigger 802.1X or the 802.1X authentication fails, when the terminal triggers MAC authentication and successfully goes online, the terminal will subsequently not be able to trigger Web authentication, but it can still trigger 802.1X authentication through EAP protocol messages. If the terminal can later trigger 802.1X authentication and successfully go online, the 802.1X user authentication information generated on the port will replace the existing MAC authentication user information. Otherwise, the user will continue to stay online with MAC authentication and be allowed to trigger 802.1X authentication again, but cannot trigger Web authentication again.

¡     If the terminal does not trigger 802.1X and MAC authentication or both fail to pass, when the terminal triggers Web authentication and successfully goes online, the terminal will not undergo any other forms of authentication in the future.

MAC Authentication -> 802.1X -> Web Authentication

When the authentication order of a port is configured as MAC authentication, 802.1X authentication, and Web authentication, any terminal message with an unknown source MAC will first trigger MAC authentication.

·     If the MAC authentication is successful, the terminal cannot trigger Web authentication again, but it can still trigger 802.1X authentication through EAP protocol messages. If the terminal can subsequently trigger 802.1X authentication and successfully go online, the 802.1X authentication user information generated on the port will overwrite the existing MAC authentication user information. Otherwise, the user still maintains MAC authentication online, which allows 802.1X authentication to be triggered again, but it cannot trigger Web authentication again.

·     If MAC authentication fails, and the terminal can trigger and succeed in 802.1X authentication, then that terminal will not undergo any other types of authentication in the future.

·     If MAC authentication fails and does not trigger 802.1X or both MAC authentication and 802.1X fail, the terminal can trigger Web authentication and successfully go online. The terminal will not undergo any other form of authentication in the future.

Triple authentication support for authorization ISP domain

For wired 802.1X, MAC address, and Web authentication users, in order to implement flexible user access control, the device supports setting different types of ISP domains, allowing users at different stages to have different network access rights.

 

IMPORTANT: Configuring preauthentication domain, auth-fail domain, and critical domain and configuring guest VLAN/VSI, Auth-Fail VLAN/VSI, critical VLAN/VSI, and critical microsegment belong to two different configuration policies. Do not configure both types of policies for triple authentication.

 

ISP domain types

Preauthentication domain

The preauthentication domain refers to the ISP domain where 802.1X users, MAC address authenticated users, and Web authenticated users are located before entering the authentication process. When the preauthentication domain is configured on the interface, the authenticated users accessing on this interface will be granted the relevant authorization attributes configured in the designated preauthentication domain (currently including ACL, VLAN, VSI, and microsegment), and will gain corresponding network access permissions based on the authorization information. If this user subsequently authenticates successfully, they will be issued new authorization information by the AAA server.

Authentication domain

The authentication domain refers to the ISP domain used when a user goes online for authentication . Users complete the authentication process using the schemes configured in the domain.

RADIUS server unreachable critical domain

During the user authentication process, if all RADIUS servers under the authentication scheme are unreachable, the access-request message sent by the device cannot be responded to, thereby affecting the user's normal online status. By configuring a critical domain under the current authentication domain, users can "escape" from the current domain and go online in the new domain when this situation occurs. Usually, the escape behavior is only an emergency measure, so users can go online directly without needing to authenticate again.

In different networking environments, the handling policy varies when a user switches to critical domain due to RADIUS server being unreachable, and any server becomes reachable again.

·     If you want the user to re-authenticate, gain authorization, and undergo accounting, you can directly take them offline.

·     If you want users to stay online and avoid re-authentication, you can configure a recovery domain. When the RADIUS server is reachable again, users will move from the critical domain to the recovery domain.

·     To reauthenticate users in the original authentication domain without users being aware of the process, specify the reauthentication action.

RADIUS server recovery domain

The recovery domain refers to an ISP domain that users can join once the authentication server is restored. Whether the user joins this domain is determined by specific policy configurations. Currently, the recovery domain must have the same name as the authentication domain.

URL unreachable critical domain

During the user authentication process, if the Web server specified by the redirect URL issued by the RADIUS server is unreachable, the user cannot reach the specified Web page to complete the authentication, thus preventing them from going online. After configuring a critical domain for unreachable URLs, users can go online in the critical domain and access its resources when the redirect URL is unreachable. When the URL switches from being unreachable to reachable, users can go offline from the critical domain and trigger reauthentication to go online again.

This feature is only applicable to MAC authentication and Web authentication users.

Auth-fail domain

By default, users will be taken offline immediately if user authentication fails. However, if you want users to have the opportunity to try other authorization schemes after the initial authentication failure, you can keep them online and redirect them to try authorization within the configured auth-fail domain again.

The auth-fail online feature does not apply to users that fail authentication for one of the following reasons:

·     Authentication times out, for example, because no authentication servers respond.

·     The authentication ISP domain is in blocked state.

Auth-success domain

When a user within the authentication domain successfully logs on through either 802.1X authentication, MAC authentication, or Web authentication, the domain is referred to as the auth-success domain. The authentication server can then issue authorization attributes to grant user authorizations in this auth-success domain.

Adding users to domains

The timing for users to join the ISP domain varies under different authentication methods, as specifically shown in Table 3.

Table 3 Timing for user to join ISP domain under different authentication methods

Authentication Method	Preauthentication domain	Critical domain	Auth-fail/success domain
802.1X	·     Trigger authentication upon initial access. ¡     Protocol message triggers authentication: Upon receiving an EAP protocol message, join the preauthentication domain. ¡     The configuration is set up for unicast trigger authentication: It joins the preauthentication domain upon receiving a packet with an unknown source MAC. ·     Join when authentication fails and an auth-fail domain is not established. ·     Join when the server is unreachable and a critical domain is not configured.	After the access device detects "authentication server or URL unreachable", it will join.	Join after receiving the "authentication fail" result returned by the authentication server.
MAC authentication	There are two situations for the timing of user joining the domain before MAC authentication: ·     Join when authentication fails and no auth-fail domain is set up. ·     Join when the server is unreachable and no critical  domain is configured.
Web Authentication	After receiving a message with an unknown source MAC, it is added to the preauthentication domain.

 

Principle of domain switchover

When all types of ISP domains are set up, the switchover between ISP domains during the authentication process for triple authentication users is as shown in Figure 18.

 

NOTE: Upon accessing the network, the user initiates MAC authentication directly without immediately joining the preauthentication domain, for a detailed analysis of the switchover scenario depicted in Figure 18, please refer to the specific conditions detailed in Table 3.

 

Figure 18 Movement of users between different types of ISP domains

 

In the triple authentication scenario, three types of authentication methods will be initiated, but the user will ultimately access the network through only one authentication method. The identity with which the user joins the ISP domain, and the privilege level of the domain and authentication method, are related to the ISP.

Once a user is authenticated via 802.1X or MAC authentication and enters any ISP domain (preauthentication domain, auth-fail domain, critical domain, or auth-success domain), the Web authentication will not be triggered anymore. Therefore, the following domain switching principles only apply to scenarios involving 802.1X and MAC authentication.

·     Under the same access authentication method, the priority levels of the ISP domain from high to low are: Authentication successful domain -> Authentication server unreachable critical domain -> URL unreachable critical domain -> Auth-fail domain -> Preauthentication domain.

·     The privilege level of 802.1X authentication is higher than MAC authentication. This means that once a user passes the 802.1X authentication and comes online, MAC authentication will not be executed again. The 802.1X authentication user information generated on the port will override the existing MAC authentication user information.

·     The device will select the authentication domain based on the user's current state, ISP domain, and the priority level of the authentication method.

a.     Firstly, select the domain for the user to join based on the ISP domain's privilege level. For instance, if the user initially undergoes MAC authentication and fails, but has yet to proceed with 802.1X authentication, and at this moment both a fail authentications domain and a pre-authentication domain are configured, then the user will join the fail authentications domain using their MAC authentication identity.

b.     If the type of ISP domain is the same, the user type will be determined according to the privilege level of access methods. For instance, after a user's MAC authentication fails, they are added to the auth-fail domain. If the same user triggers 802.1X authentication and fails again, they will rejoin the auth-fail domain with the identity of an 802.1X user.

 

IMPORTANT: Pre-domain users of 802.1X will not replace MAC authentication preauthentication domain users. That is to say, when MAC authentication preauthentication domain users are online, triggering an 802.1X authentication through an EAP protocol message or an unknown source MAC message, they will not go online again under the identity of 802.1X preauthentication domain users.

 

When a user switches from a high privilege level domain to a low privilege level domain, the access authentication method remains unchanged. For example, if a MAC authentication user joins a failed domain and deletes the failed domain configuration, during re-authentication, if 802.1x authentication is triggered simultaneously, the user will only join the prior domain with MAC authentication identity even if MAC authentication fails.

Triple authentication support for microsegment assignment

 

Authorization microsegment

Microsegment can be used for refined access control based on user groups in the network. Once a user is authenticated by any method in the triple authentication scheme, if the remote authentication server assigns a microsegment to the user, the device filters the data flow of the user's port according to the authorized microsegment. The user can then access the network resources within the group where the microsegment is located.

Server unreachable critical microsegment

If the user fails to authenticate because all authentication servers are unreachable, the port will add the user to the configured Critical microsegment section.

This feature only supports 802.1X and MAC authentication.

Triple authentication support for VSI assignment

This feature only supports 802.1X and MAC authentication.

Authorization VSI

The remote authentication server/access device can issue an authorization VSI to the port where the user authenticated via remote/local is located. The port will then add the user to the corresponding authorized VSI.

Auth-fail VSI

After user authentication fails, the port adds the user who failed the authentication to the configured VSI for failed authentication (auth-fail VSI).

·     For 802.1X authenticated users, the auth-fail VSI is the 802.1X Auth-Fail VSI configured on the port.

·     For users with MAC authentication, the auth-fail VSI is the MAC authentication Guest VSI configured on the port.

If a user fails MAC authentication and then fails 802.1X authentication, the user will immediately exit the MAC authentication Guest VSI they had joined, and join the 802.1X Auth-Fail VSI configured on the port.

Server unreachable critical VSI

If a user fails to authenticate due to an unreachable server, the port will add the user to a pre-configured VSI for an inaccessible server (critical VSI).

·     For 802.1X authenticated users, the server unreachable critical VSI is the 802.1X Critical VSI is configured on the port.

·     For users undergoing MAC authentication, the server unreachable critical VSI is the Critical VSI configured for MAC authentication on the port.

If a user fails MAC authentication and then fails 802.1X authentication, they will immediately leave the Critical VSI joined through MAC authentication and join the 802.1X Critical VSI configured on the port.

Triple authentication support for VLAN assignment

Authorization VLAN

The remote authentication server or access device can issue an authorization VLAN to the port where the user authenticated remotely or locally is located. The port will then add the user to the corresponding authorization VLAN.

Auth-fail VLAN

After the user authentication fails, the port adds the user with failed authentication to the preconfigured VLAN for authentication failures (auth-fail VLAN).

·     For 802.1X authenticated users, the auth-fail VLAN is the 802.1X Auth-Fail VLAN configured on the port.

·     For Web authentication users, the auth-fail VLAN is the Web Auth-Fail VLAN configured on the port.

·     For users with MAC authentication, the auth-fail VLAN is the MAC authentication Guest VLAN configured on the port.

If a user fails the MAC authentication and subsequently fails the 802.1X authentication, the user will immediately leave the MAC authentication Guest VLAN they had joined, and join the 802.1X Auth-Fail VLAN configured on the port.

Server unreachable critical VLAN

If the user fails to authenticate due to the server being unreachable, the port will add the user to the configured VLAN for unreachable servers (critical VLAN).

·     For users authenticated through 802.1X, the server unreachable critical VLAN is the 802.1X Critical VLAN is configured on the port.

·     For Web authenticated users, the server unreachable critical VLAN is the Web Auth-Fail VLAN on the port.

·     For users using MAC authentication, the server unreachable critical VLAN is the MAC authentication Critical VLAN configured on the port.

The port supports the simultaneous configuration of multiple unattainable VLAN servers. The scenarios of users joining various VLANs due to authentication failure caused by unreachable servers are as follows:

·     If the user does not undergo 802.1X authentication, the user will be added to the critical VLAN of the server where the last authentication failed.

·     If a user fails at Web authentication or MAC authentication and subsequently fails at 802.1X authentication, the user will immediately exit the Web Auth-Fail VLAN or the MAC authentication Critical VLAN they joined and will join the 802.1X Critical VLAN configured on the port.

Triple authentication support for re-authentication

Re-authentication refers to the device periodically initiating authentication for online authorized users on the port to monitor the changes in user connection state, ensure the normal online status of users, and promptly update the authorization attributes (such as ACL, VLAN, etc.) issued by the server.

The re-authentication method differs for users within different authentication domains.

·     Users within the authentication critical domain and the auth-success domain still undergo re-authentication in the same way as their initial access authentication. For example, users who joined the critical domain through MAC authentication can only re-authenticate with MAC authentication.

·     Users within the preauthentication domain and the auth-fail domain trigger authentication as new online users, and the final online user type is determined based on the authentication result. Web authentication users in the preauthentication domain and the auth-fail domain do not support re-authentication.

Typical applications

As shown in Figure 19, the user accesses the network through Device (the access device). It requires unified authentication for all users on the Layer 2 port of the Device. As long as the user passes any of the 802.1X authentication, MAC address authentication, or Web authentication, they can access the network.

Figure 19 Typical network grouping with triple authentication