802.1X Authentication

The IEEE 802.1X standard is a port based network access control (NAC) protocol which controls the user authentication and access to the network resources through the access port. As long as there is a user who is trying to access the network resources through the interface passes the 802.1X authentication, the interface turns to authorized state. Then the subsequent users who are trying to access the network resources through the interface do not need to perform 802.1X authentication.

As shown in Figure 1, the 802.1X authentication system is a typical Client/Server architecture which involves three parties: a Supplicant, an Authenticator and an Authentication server.

Figure 1. Diagram of the 802.1X Authentication System

•   Supplicant: The supplicant is the user device who wants to access the network sources through a switch. It is a client or a host that provides the user name and password to the authentication server to obtain network access rights.
•   Authenticator: The PICA8 Switch functions as the authenticator in the 802.1X protocol. As a NAC gateway device, PICA8 Switch transfers authentication information between the client and the authentication server, and controls network access and authorization of the client.
•   Authentication server: The authentication server often resides on the RADIUS server. The administrator configures the user's authentication and authorization information on the RADIUS server that is used to validate the client in the 802.1X authentication and determine whether the client can access the network resources.

Besides 802.1X authentication, PICOS also supports MAC Authentication Bypass (MAB) authentication function of NAC protocol. For details about MAB authentication and the comparison of these two authentication function, see MAC Authentication Bypass (MAB)  .

EAP Packet Exchange Process

In an 802.1X authentication system, the supplicant, authenticator and authentication server exchange authentication information using the Extensible Authentication Protocol (EAP) packet. The EAP packet exchange process is described as follows:

1.  The EAP packets transmitted between the authenticator and supplicant are encapsulated in EAPOL format and transmitted across the LAN.

2.  The authenticator and authentication server (a RADIUS server) exchange EAP packets in EAP relay mode. The authenticator encapsulates EAP packets in EAP over RADIUS (EAPOR) format and sends the packets to the RADIUS server for authentication. This authentication mode supports various EAP authentication methods, such as MD5- Challenge, EAP-TLS, and PEAP. However, the RADIUS server is required to support corresponding EAP authentication methods.

Authentication Trigger Mode

The 802.1X authentication process can be initiated by either the supplicant or authenticator in the following two types:

•      Triggered by the supplicant

The supplicant sends an EAPOL-Start packet to the authenticator to trigger authentication. The destination address of the packet is a multicast MAC address assigned by the IEEE 802.1X protocol: 01:80:C2:00:00:03.

•      Triggered by the authenticator

For supplicants that cannot send EAPOL-Start packets proactively, the authenticator supports proactive trigger of the 802.1X authentication.

The authenticator sends a multicast EAP-Request/Identity packet to the supplicant with the multicast MAC address 01:80:C2:00:00:03 to trigger 802.1X authentication every 30 seconds.

Authorization States of the Interface

The interface with 802.1X authentication enabled has two states: authorized and un-authorized state.

•      Authorized state: The port is in open state, allowing users to access network resources through this port.
•      Un-authorized state: The initial state of the port that enables 802.1X authentication. The port  is in the block state. The users are not allowed to access network resources through this port. The port will block all traffic that is not authenticated by the RADIUS server.

The user can configure the authorization state of an interface by using the set protocols dot1x interface <interface-name> port-control <auto | force-authorized | force-unauthorized> command to control whether an access user must be authenticated before accessing network resources. The interface supports the following authentication states:

•      Auto mode: This is the default setting. The interface is initially in un-authorized state which can send and receive EAPOL packets only. Users cannot access the network resources through this interface.

The authenticator co-works with the authentication server to perform authentication on the supplicant that needs to access the local area network, and controls the port authorization / un-authorization status according to the authentication result (Accept or Reject).

If the authentication fails, the authenticator will try the authentication process maximum of three times. If the authentication is not successful after trying three times, the switch will ignore any more request from the supplicant in the EAP_TIME_OUT time (60 seconds) which is called a quiet time.

After a user passes 802.1X authentication, the interface state turns to Authorized state. As long as there is a user who is trying to access the network resources through the interface passes the 802.1X authentication, the interface turns to authorized state. Then the subsequent users do not need to perform 802.1X authentication when accessing the network resources through this interface. 

•      Authorized-force mode: The interface is always in Authorized state and allows users to access network resources through this interface without authentication.
•      Unauthorized-force mode: The interface is always in Un-authorized state and does not allow users to access network resources.

MAC Authentication Bypass (MAB)

Not all the network devices support 802.1X, such as a printer, camera, or a wireless phone. Such devices lack the supplicant feature which is needed to pass on the 802.1X authentication credentials between the client and the authentication server.

In this case, you can use MAC Authentication Bypass (MAB) function to authenticate network devices. PICA8 switches not only support the port-based access authentication method, but also extends it to support the MAC-based access authentication method, the MAC Authentication Bypass (MAB) access control mode. The user can use the set protocols dot1x interface <interface-name> auth-mode <dot1x | mac-radius | dot1x-mac-radius> command to set the authentication mode of an interface.

When an interface enabled with MAB authentication learns a new MAC, PICOS will perform the MAB authentication process. The new MAC will be encapsulated as user name and password in EAPOR packet and send to the RADIUS server for MAB authentication. The MAB authentication process is similar to 802.1X authentication process. For details, see EAP Packet Exchange Process. The port will be opened to the user with this MAC only if it passes the MAB authentication.

When the MAC entry is aged or deleted, the user session with this source MAC will be disconnected. MAB authentication will be performed again if the user wants to access the network resources through this port.

The 802.1X authentication and MAB authentication are independent functions. You can enable only one of them, or enable both of them by using the set protocols dot1x interface <interface-name> auth-mode <dot1x | mac-radius | dot1x-mac-radius> command.

When both authentication modes are enabled, the MAB authentication will take precedence over 802.1X. If the MAB authentication passes, the system will not do 802.1X authentication, and the port will only be opened to the traffic with the authenticated source MAC address. However, if MAB authentication has failed, PICOS will then fallback to the 802.1X authentication process.

The below table compares the 802.1X and MAB authentication.

Change of Authorization (CoA)

Server initiated Change of Authorization allows the administrator to modify the authorization of the already authorized users through the CoA messages from the RADIUS server.

The RADIUS server sends CoA messages to the PICA8 switch when the authorization information of an authorized user is changed by the administrator. The switch performs new authorization of the client when it receives the CoA messages. For example, if the administrator configures to disable the host port on the RADIUS server, the RADIUS server will send a CoA-Request message with disable-host-port field to the RADIUS client to disable the port connected to the host.

CoA involves two parties: Dynamic Authorization Server (DAS) and Dynamic Authorization Client (DAC):

•   DAS: The component that resides on the NAS (switch) that processes and replies to the Change-of-Authorization (CoA) Request and Disconnect messages.
•   DAC: The component that sends CoA-Request and Disconnect messages to the Dynamic Authorization Server. This component often resides on the RADIUS server. For details, please refer to RFC5176.

CoA includes two message flows: Disconnect and Change-of-Authorization (CoA) process. Disconnect message terminates a user session immediately, CoA message modifies the user session authorization attributes.

Figure 2 illustrates a CoA message exchange between an 802.1X-enabled client, a switch operating as Authenticator (DAC), and a RADIUS server operating as an Authentication Server (DAS).

Figure 2. Message Exchange during CoA Process

1.  DAC sends a CoA-Request packet to DAS to request to change the user authorization information. The packet may include one of the three authorization attributes supported by PICOS: Reauthenticate, Bounce-host-port and Disable-host-port, as shown in Figure 3.

•   Reauthenticate: When receiving CoA-Request message with reauthenticate attribute, DAS sends an EAP Request message to the supplicant to initiate re-authentication. The authentication information of all the online supplicant will be sent to the authentication server for re-authentication. If the authentication information had not changed on the authentication server, the user is kept online; if the user's authentication information has been changed, the authentication of this user will be processed again.
•   Bounce-host-port: The CoA-Request message with bounce-host-port attribute brings the interface down and then up immediately.
•   Disable-host-port: The CoA-Request message with disable-host-port attribute brings the interface down. The interface cannot be used after this operation. If you want to enable this interface, use the set interface gigabit-ethernet <port> disable false command.

Figure 3. Reauthenticate Attribute in CoA-Request Message

2.  DAS changes the authorization information of the online user according to the authorization attribute in the CoA-Request packet.

3.  DAS replies with a CoA-ACK/NAK message. While sending the CoA-ACK/NAK, the source port in the CoA-Request packet is used as the destination port whereas the destination port of 3799 in the CoA-Request packet is used as the source port.

•   If the Client’s authorization information is successfully modified，DAS replies with a CoA-ACK message.
•   If the Client’s authorization information cannot be modified, DAS replies with a CoA-NAK message.

Re-authentication

To check the connection status of the client and ensure that only authorized users are allowed access to the network, the PICA8 switch can periodically re-authenticate all online 802.1X users that have been previously authenticated on their respective ports. The set protocols dot1x interface <interface-name> reauthentication disable <true | false> and set protocols dot1x interface <interface-name> reauth-period <reauth-period> command can be used to enable re-authentication function and set the re-authentication period. The default re-authentication period is 3600 seconds.

After the re-authentication is enabled, the switch periodically sends an EAP Request message to the supplicant to initiate re-authentication. The authentication information of all the connected supplicants will be sent to the authentication server for re-authentication. If the authentication information has not changed on the authentication server, the user is kept in authenticated state; if the user's authentication information has been changed, the authentication request of this user is processed again.

Guest VLAN

Guest VLAN function provides guest access to certain network resources. To access certain resources when the 802.1X authentication fails, user can enable the guest VLAN function. For example, you can obtain the client software, upgrade the client, or perform other user upgrade programs through guest VLAN even when the 802.1X authentication has failed.

On PICA8 Switch, you can configure a guest VLAN on a specific user port by using the set protocols dot1x interface <interface-name> guest-vlan <vlan-id> command. By default, there is no guest VLAN. If the 802.1X authentication has failed but the guest VLAN is configured, the user port will be added to the guest VLAN and the native VLAN ID will be changed to guest VLAN. The client can only access resources within the guest VLAN. If no guest VLAN is configured on the user port, the port will be kept in blocking state.

Dynamic VLAN

When a supplicant passes the 802.1X authentication, the authentication server delivers the dynamic VLAN information in the RADIUS Access Accept message if the dynamic VLAN function is configured on the server. Upon receiving the message from the authentication server, the PICA8 switch adds the port to the dynamic VLAN.

If the dynamic VLAN function is disabled on the switch, or if the authentication server does not deliver a dynamic VLAN, then the switch will adds the interface where the user resides to the default VLAN.

On PICA8 switch, you can enable the dynamic VLAN by using the set protocols dot1x interface <interface-name> dynamic-vlan-enable <true | false> command. By default, it is disabled.

To support dynamic VLAN, the authentication server needs to support the following three fields:

•   Tunnel Type: The protocol type used by the tunnel. The value of the tunnel type is 13 which indicates the VLAN protocol.
•   Tunnel Medium Type: Medium type used when creating the tunnel. The value is fixed as 802.
•   Tunnel Private Group ID: Set this to VLAN ID. The dynamic VLAN is delivered through this attribute.