Introduction to NAC Authentication

Network Access Control (NAC) is a network access security function which controls the user authentication and access to the network resources through the access port.

As shown in Figure 1, the NAC authentication system is a typical Client/Server architecture which involves three components: Supplicant, Authenticator and AAA server.

Figure 1. Architecture of the NAC Authentication System

• Supplicant: The supplicant is the user device that wants access to the network resources through the 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 NAC authentication system. As an authentication gateway device, PICA8 Switch transfers authentication information between the client and the authentication server, and controls network access and authorization of the client.
• AAA server: The authentication server is the entity that validates authentication credentials provided by the supplicant. RADIUS is a commonly used authentication server. The administrator configures the user's authentication and authorization information on the AAA server that is used to validate the client in the NAC authentication process and determine whether the client can access the network resources.

Host Mode

Host Mode refers to whether a single or multiple clients are allowed access on a single switch port. PICOS NAC function is a combination of switch port and the client’s MAC address learned on that switch port to implement user access control. Each switch port can be configured to operate in either single or multiple host mode.

• single: Only one user is allowed access to the switch port, unless the user goes offline other users will not be allowed access to the network. The authentication process will be reinitiated if the port is bounced or client is changed.
• multiple: Multiple clients connect to the network through the same switch port. If a user goes offline, the network access rights of other users are not affected. At most 8 clients are allowed to be authenticated on a single switch port, the ninth will be added into the pending list.

You can set the host mode of the interface by using command set protocols dot1x interface <interface-name> host-mode <single | multiple>. The default host mode is single. Note that changing host mode from CLI will cause re-authentication for all connected users of the port.

Server Fail VLAN

The purpose of a server fail VLAN is to provide limited network connectivity to users in the event of AAA server failure or unreachability. After a RADIUS server is configured, the switch sends Test Radius Request message to the server to detect the reachability of the RADIUS server. If all the RADIUS servers are unreachable, the port connected to the client will be added to the server fail VLAN, and the packets from the client can be forwarded in server fail VLAN. The switch continues to send the detection packets every second for 3 times (can be set by CLI command) to check whether the server is reachable. If one of the RADIUS servers is reachable, the switch removes this client from the server fail VLAN and adds it back into the block VLAN, and the switch stops sending the detective packets.

Users can use the set protocols dot1x server-fail-vlan-id <vlan-id> command to specify a server fail VLAN, the run show dot1x server command can be used to show the reachability of each RADIUS servers configured on the switch, run show dot1x all command can be used to view the NAC configuration information, including the server fail VLAN.

For example,

admin@Xorplus# run show dot1x server
Server-IP         Status        Priority  Retry-Interval  Retry-Num   Detect-Interval   Consecutive-Detect-Num
----------------  ------------  --------  --------------  ---------   ---------------   ----------------
10.10.51.70       reachable     2          5   Sec(s)      5          5   Sec(s)         8


admin@Xorplus# run show dot1x all
Global-Info:
---------------------------------------------------------------------------------
NAS-IP           :  10.10.1.1
Block-VLAN         :  2
Block-VLAN-IP        :  172.16.1.1/24
WEB-AUTH-MODE           :  Remote
Server-Fail-VLAN      :  100
--------------------------------------------------------------------------------

Block VLAN and Dynamic VLAN

Block VLAN is a global configuration for NAC authentication. The port enabled with web authentication NAC feature will be added to the block VLAN automatically. Users in the block VLAN  have very limited access network resources before being authenticated successfully through the web authentication portal. Block VLAN is a mandatory prerequisite for web authentication. If block VLAN is not specified, the switch won’t allow the user to configure web authentication for any physical port.

The switch will move the clients from the block VLAN to an AAA server specified dynamic VLAN after successful authentication. If the RADIUS authentication server does not deliver a dynamic VLAN, then the client is moved to the native VLAN of the interface.

When configuring dynamic VLAN, you need to pay attention to the following points:

• On the switch, you need to use the set vlans vlan-id <vlan-id> command to create a dynamic VLAN in advance. And the link type of the port should be configured as trunk port.
• On the AAA server, you need to configure and deliver a dynamic VLAN. When configuring the dynamic VLAN, dynamic VLAN name is a string type, and its length must be less than or equal to 10 characters.
• Dynamic VLAN and block VLAN cannot be the same VLAN.

The L3 VLAN interface should be enabled on the block VLAN. The IP address of this VLAN-interface should be configured to establish a temporary connection between the user and the switch to complete the subsequent Web authentication process.

After creating a block VLAN, you can use the run show vlans command to view VLAN information.

Fallback to WEB Function

PICOS NAC function includes three authentication modes: 802.1X authentication, MAB authentication and Central Web Authentication (CWA). To use NAC to control users' network access rights, you must enable one or more authentication modes on a switch interface. Note that: CWA authentication process relies on MAB authentication. If you want to deploy CWA, you need to enable MAB authentication first.

PICOS supports fallback to WEB if 802.1X authentication fails. This function controls whether MAB authentication is performed when 802.1X authentication fails. Enabling or disabling fallback to WEB function leads to two different results.

1.  Fallback to WEB function is disabled. This is the default configuration.

• When both 802.1X authentication and MAB authentication modes are enabled, the 802.1X authentication will take precedence over MAB.

If the Supplicant supports 802.1X authentication, the system performs 802.1X authentication. If the Supplicant does not support 802.1X authentication, the system performs MAB authentication.

For the former case, irrespective of whether 802.1X authentication is successful or not, MAB authentication will not be performed. It’s important to note here that if the client sends in 802.1X credentials and the authentication fails for some reason, the switch will not initiate MAB authentication in case where both 802.1X and MAB are configured for the switch port.

If the 802.1X authentication fails, the switch will try the authentication process maximum of three times. If the authentication fails after trying three times, the switch will ignore any more request from the client in the EAP_TIME_OUT time (60 seconds) which is called a quiet time before the switch initiates re-authentication.

•  If all three modes are enabled, the system considers 802.1X authentication and MAB authentication as described above. If the 802.1X authentication is not supported and the MAB authentication fails, the system will perform the CWA authentication mode for the client.

2.  Fallback to WEB function is enabled.

• When both 802.1X authentication and MAB authentication modes are enabled, the 802.1X authentication will take precedence over MAB.

If the Supplicant supports 802.1X authentication, the system performs 802.1X authentication. If the Supplicant does not support 802.1X authentication, the system performs MAB authentication.

For the former case, if the 802.1X authentication fails, the system tries to perform MAB authentication. This is different from the scenarios when fallback to WEB function is disabled. Note that: It will not take dot1x authentication if already fallback to CWA until MAC ages out and learns again by cable plugging in/out or MAC address clearing.

• If all three modes are enabled, at first, the system considers 802.1X authentication and MAB authentication as described above. If the 802.1X authentication is not supported and the MAB authentication fails, the system will perform the CWA authentication mode for the client.

Comparison of the Three Authentication Modes

The application scenarios of the three authentication modes are different, the below table compares the three authentication modes.

802.1X Authentication

802.1X authentication is an authentication method that controls the network access rights of users based on the switch port and the MAC addresses of clients learned on that port. The Extensible Authentication Protocol (EAP) packet is used to exchange authentication information between the supplicant, authenticator and authentication server. This technology is mainly used in networks with high security requirements. 802.1X authentication requires 802.1X client software to be installed on the supplicant.

You can use the set protocols dot1x interface <interface-name> auth-mode 802.1x command to enable 802.1X authentication mode on an interface.

EAP Packet Exchange Process

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 the corresponding EAP authentication methods. The credentials can be based on username/password or the certificate-based. You need to follow the configuration guide in this document to employ 802.1X authentication based on the username/password. However, certificate-based authentication does not need to do any configuration on the switch. 

Authentication Trigger Types

The 802.1X authentication process can be initiated by either the client or the access device in the following two types:

• Triggered by the client

The client sends an EAPOL-Start packet to the access device 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 access device

For clients that cannot send EAPOL-Start packets proactively, the access device supports proactive trigger of the 802.1X authentication.

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

MAC Authentication Bypass (MAB) Authentication

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. You can use the set protocols dot1x interface <interface-name> auth-mode mac-radius command to enable MAB authentication mode on an interface.

When the interface enabled with MAB authentication learns the MAC address of the user, PICOS will perform the MAB authentication process. During the authentication process, the user is not required to manually enter a username or password. The user's MAC address will be encapsulated as the user-name and password in a RADIUS Access Request packet and sent to the AAA server. The port will be opened to the user with this MAC address only if MAB authentication is passed successfully. This technology is suitable for environments where the MAC address is fixed and the security requirements are not very high. At the same time, it can meet the authentication requirements of terminals such as printers that cannot install the 802.1X authentication client software.

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.

Central Web Authentication (CWA)

Introduction

Central Web Authentication (CWA) provides a means to enterprise network administrators to allow guests on the network some form of access to network resources, which is also referred to as Web authentication. This feature is particularly helpful because guest users usually do not have proper 802.1X or MAC Radius credentials saved on the authentication servers.

With Web authentication feature, PICA8 switches can now provide an additional feature to guest users to use their web browser to access a login page where they can provide either authentication credentials for guests or simply accept a use-policy to access the network. In centralized web authentication environment, the PICA8 switch works as a proxy between the authentication server and user. When the user connects to the network and tries to access a Web page, the user is redirected to the authentication page on the Web authentication server. Only after entering the correct username and password can the user successfully access the network resources.

You can use the set protocols dot1x interface <interface-name> auth-mode web command to enable WEB authentication mode on an interface.

Redirect URL

In the CWA authentication process, when the user connects to the network and tries to access a web page, the user is redirected to the authentication page on the web authentication server. Only after entering the correct username and password can the user successfully access the network resources.

The Redirect URL is a vendor-specific attribute (VSA) of type string defined on the AAA server. The attribute name is Pica8-Redirect-URL and the attribute ID number is 4 in the PICA8 RADIUS dictionary. To use the Redirect URL VSA the user has to import PICA8 RADIUS dictionary to AAA server. For details about how to import PICA8 RADIUS dictionary, please refer to the document How to Import PICA8 RADIUS Dictionary.

CWA Authentication Process

Figure 2 shows the CWA authentication process.

Figure 2. CWA authentication process

1. The client is connected to the switch port and its MAC address is learned by the switch. The switch sends an MAB Request message to the AAA server to initiate MAB authentication for the guest user. The message carries the MAC address of the client as the authentication username and password.
2. As the client's MAC address is an unregistered address on the AAA server, the MAB authentication fails. However, the AAA server is configured in such a way that an Access-Accept message is sent to the switch with a redirect URL for unregistered users.
3. The client interacts with the switch to obtain a temporary IP address from the DHCP server running in the block VLAN.
4. DNS resolution is done locally on DNS server running on the switch. Domain names such as www.example.com are resolved to the block VLAN interface IP address (e.g. 172.16.0.1) instead of its actual IP address. It’s important to note that both the DNS and DHCP server have the same IP address as the block VLAN interface IP address of 172.16.0.1.
5. The client and the switch perform a TCP three-way handshake to establish a TCP connection.
6. Then the client opens a web browser, initiates an HTTP access request.
7. The switch replies to the client with the redirect URL in the HTTP response. The Switch gets the IP address of CWA server ( is included in the re-directio URL) resolved by the configured DNS.
8. The client’s request is redirected to the redirect URL page on the AAA server that requires the client to enter the username and password.
9. After the client enters the correct username and password, login succeeds. AAA server sends a CoA bounce-port command to the switch.
10. The switch and AAA server perform MAB authentication on the client MAC address again. This time the client is a known client to the AAA server, so another Access-Accept message is sent along with a dynamic VLAN ID. The switch port is then put into the dynamic VLAN.
11. MAB authentication and Web authentication succeed. The user can access the Web resources normally.

RADIUS Accounting for 802.1X and MAB

Enterprises or carriers need to charge users who are accessing different enterprise or carrier services such as Internet to be able to accurately and effectively calculate billing information for their customers

When a user gets online, the switch will send accounting start message to the AAA server when authentication is passed and starts accounting; When the user gets offline by either MAC aged out or be deleted, the switch will send accounting stop packet to the AAA server to stop accounting. In the accounting stop packet, the attribute Acct-Session-Time carries the amount of time the user was online.

Users can use the set protocols dot1x aaa radius accounting disable <true | false> command to enable or disable accounting function for 802.1X and MAB.

AAA server records the packet consumption, you can use the command run show dot1x dynamic/downloadable filter to check the counter result. For example,

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 AAA server.

The AAA server sends CoA messages to the PICA8 switch when the authorization information of an authorized user is changed by the administrator. The switch initiates a new authorization of the client when it receives a CoA messages. For example, if the administrator configures to disable the host port on the AAA server, the AAA server will send a CoA-Request message with disable-host-port field to the switch to disable the port connecting 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 types of message flows: Disconnect and Change-of-Authorization (CoA) processes. Disconnect message terminates a user session immediately whereas CoA message modifies the user session authorization attributes.

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

Figure 3. Message Exchange during CoA Process

The AAA server sends a CoA-Request packet to the switch to request to change the user authorization attribute. The packet may include one of the four authorization attributes supported by PICOS: Disconnect, Re-authenticate, Bounce-host-port and Disable-host-port, as shown in Figure 3.

• Disconnect: When the switch receives the Disconnect message, it terminates the user session immediately.
• Re-authenticate: When the switch receives the re-authenticate CoA Request message from the AAA server, the switch sends an EAP Request message to the supplicant to initiate re-authentication.
• 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 CLI command.

Figure 4. Bounce-host-port Attribute in CoA-Request Message

1.  DAS performs the action according to the authorization attribute in the CoA-Request packet.

2.  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 DAS successfully applies the action in the CoA Request packet it will reply with a CoA-ACK message. DAS replies with a CoA-ACK message.
• If for some reason the DAS is unable to carry out the action requested in the CoA Request packet, the DAS replies with a CoA-NAK message.

Downloadable ACL

The downloadable ACL is a dynamic packet filtering function that is implemented by the AAA server and the firewall filter module of the switch. To use downloadable ACL, users have to configure the ACL name and the detailed ACL rules on the AAA server; the switch only has to enable 802.1X authentication or MAB authentication locally.

After the 802.1X authentication or MAB authentication has succeeded, the AAA server sends the ACL to the switch in the Access-Accept message. The switch parses the received downloadable ACL field and implements packet filtering through the packet matching rules and processing operations. The downloadable ACL is delivered to a specific MAB or 802.1X user and is delivered only when the respective authentications are passed successfully.

For downloadable ACL, PICA8 has defined two vendor-specific-attributes (VSAs) on the AAA server. First one is the Pica8-IP-Downloadable-ACL-Name, the attribute ID number is 3, and Pica8-IP-Downloadable-ACL-Rule, the attribute ID number is 2 in the PICA8 RADIUS dictionary. To use these VSAs the users have to import the PICA8 RADIUS dictionary to the AAA server. For details about how to import PICA8 RADIUS dictionary, please refer to the document How to Import PICA8 RADIUS Dictionary.

The values for Pica8-IP-Downloadable-ACL-Rule attribute are implemented based on the firewall filter module. The template of supported matching conditions/actions are as follows.

Template of Downloadable ACL:

and is the logical operator between the matching fields with the same sequence number, that is, to be considered to match a firewall filter rule and included in a class, the packets must match all of the matching fields with the same sequence number. NOTE that there is a drop rule for each firewall filter rule by default.

To reduce the size of Access-Accept message, PICOS supports parsing the abbreviation downloadable ACLs. The following table shows the supported abbreviation styles.

It is also supported to merge multiple from statements and action statements of the same sequence number into one single line.

 For example,

For the following downloadable ACL rules.

 The equivalent ACL rule to that is:

 or

 This equivalent ACL greatly reduces the size of the Access-Accept message.

The following image shows the format of the downloadable ACL in the Access-Accept message which is sent from the AAA server to the switch:

On the switch, you can use the run show dot1x interface command to view the detailed information about the downloadable ACL delivered by the interface.

For example,

admin@Xorplus# run show dot1x interface gigabit-ethernet ge-1/1/48
Interface ge-1/1/48:
============================================================
Client MAC                              : 00:00:00:11:11:11
Status                                      : authorized
Success Auth Method             : MAB
Last Success Time                   : Sun Mar 20 21:08:11 2022
Traffic Class                             : Other
Downloadable Filter Name     : pica-dacl-mab (active)
Downloadable Filter Rule       : sequence 1 from protocol icmp code 24
                                                 sequence 1 then action forward
                                                 sequence 2 from protocol icmp type 45
                                                 sequence 2 then action discard
============================================================
Client MAC                            : 22:11:11:11:11:11
Status                                    : unauthorized
============================================================

The employment of the downloadable ACL and the configuration examples on the ClearPass/Cisco ISE and the switch are detailed in the document Configuring Dynamic and Downloadable ACL for ClearPass and Configuring Dynamic and Downloadable ACL on Cisco ISE in Typical Configuration of NAC.

Dynamic ACL

The dynamic ACL is a dynamic packet filtering function that is implemented by the AAA server and the firewall filter module of the switch function. Instead of downloadable ACL getting the detailed ACL rules from the AAA server, the detailed rules of dynamic ACL should be preconfigured on the switch and the ACL should be applied just when the ACL name is received from AAA server. The name of the dynamic ACL is configured on the AAA server which uses the RADIUS standard attribute Filter-Id, an attribute defined by the RFC3576 standard and the attribute ID number is 11.

After the 802.1X authentication or MAB authentication has succeeded, the AAA server sends the ACL name to the switch in the Access-Accept message carried with Filter-Id field. The switch parses the received dynamic ACL field and implements packet filtering through the packet matching rules and processing operations. Each dynamic ACL is sent only with an Access-Accept message when any of MAB or 802.1X authentication has passed successfully on the AAA server for a specific client.

The switch delivers the ACL rule to match the packets and process the packets to implement packet filter rule. If the AAA server delivers a wrong ACL name, the switch prints a system log, and then drops the flow by using the default drop rule.

The following image shows the format of Filter-ID in the Access-Accept message which is sent from the AAA server to the switch:

On the switch, use the following commands to configure the NAC-based dynamic ACL rule.

set protocols dot1x filter <filter-name> sequence <sequence-number> from <filter-condition>

set protocols dot1x filter <filter-name> sequence <number> then action <discard | forward>

and is the logical operator between the matching fields with the same sequence number, that is, to be considered to match a firewall filter rule and included in a class, the packets must match all of the matching fields with the same sequence number. NOTE that there is a drop rule for each firewall filter rule by default.

On the switch, you can use the run show dot1x interface command to view the detailed information about the dynamic ACL applied to the interface.

For example,

admin@Xorplus# run show dot1x interface gigabit-ethernet ge-1/1/5

Interface ge-1/1/5:

=====================================================================

Client MAC                          : 08:9e:01:9e:cc:fe

Status                                  : authorized

Dynamic VLAN ID               : 200

Dynamic Filter Name           : f2

The employment of the dynamic ACL and the configuration examples on the ClearPass/Cisco ISE and the switch are detailed in the document Configuring Dynamic and Downloadable ACL for ClearPass and Configuring Dynamic and Downloadable ACL on Cisco ISE in Typical Configuration of NAC.

Response to session-timeout Attribute

If the returned access-accept RADIUS message carries the attribute session-timeout after MAB/802.1X authentication, the authenticated session will expire after a period of session-timeout and start a new authentication process.

• If the access-accept RADIUS message carried the timeout-session attribute and the timeout value is not equal to 0 (such as 30s), the switch will send request packet to the AAA server or the client every 30s for re-authentication.
• If the access-accept RADIUS message carried the timeout-session attribute but the timeout value is equal to 0, the switch does not send any re-authentication request packet to the AAA server or the client. No action is taken, it has the same effect as if the session timeout attribute was not used or the returned access accept packet did not had the timeout attribute.
• If the access-accept RADIUS message does not include the timeout-session attribute, the switch will send the re-authentication request packet to the AAA server or the client every 60 mins (default value) for re-authentication. The default 60 minutes re-authentication applies in situations where the MAC address does not age out for 60 minutes.

Vendor Specific Attribute (VSA)

Vendor Specific Attribute (VSA) is a vendor defined attribute in the vendor’s RADIUS dictionary. For the NAC function, PICOS defines four VSAs whereas the PICA8 vendor ID is 35098:

Pica8-AVPair, the attribute ID number is 1;

Pica8-IP-Downloadable-ACL-Rule, the attribute ID number is 2;

Pica8-IP-Downloadable-ACL-Name, the attribute ID number is 3;

Pica8-Redirect-URL, the attribute ID number is 4.

To use these VSAs, the users have to import the PICA8 RADIUS dictionary to AAA server. We describe how to import PICA8 RADIUS dictionary to ClearPass, Cisco ISE and FreeRadius below.

How to Import PICA8 RADIUS Dictionary to ClearPass

To import the PICA8 RADIUS dictionary file to ClearPass, perform the following tasks in CPPM on ClearPass.

1. Click on AdministrationàDictionariesà
2. Click on Import (top right corner).
3. Choose the PICA8 RADIUS dictionary file and click Import.
4. You can use the PICA8 RADIUS dictionary file attached below if you don’t have it.

5. Refer to the image below for reference.

How to Import PICA8 RADIUS Dictionary for Cisco ISE

We need to import the Pica8 radius dictionary file to ISE for Pica8 switches to work properly with ISE. Follow the steps below to import the dictionary file.

1. Click on Policy Elements -> Dictionaries -> System -> Radius -> RADIUS Vendors.
2. Click on Import and choose the Pica8 dictionary file, now click import to load the dictionary file.
3. You should be able to see Pica8 dictionary file in the list of vendor dictionaries after successful import.
4. You can also create your dictionary file here by clicking Add and adding attributes as mentioned in dictionary file.
5. Please note adding a dictionary file manually you need to enter the attributes as they are in the dictionary files. The two most important items are the VENDOR name and ID and Pica8-AVPair attribute. The VENDOR name must be set to Pica8 and the ID should be 35098.
6. The dictionary file for Cisco ISE is attached below:

    7. Refer to the image below for reference.

How to Import PICA8 RADIUS Dictionary to FreeRadius server

To import the Pica8 Radius dictionary to FreeRadius server, copy the file attached below to location /usr/share/freeradius/.