LAN Security – Identity Based Networking Services

Identity Based Networking Services (IBNS) provides identity-based network access control and policy enforcement at the switch port level. The IBNS solution extends network access security based on the 802.1x technology, Extensible Authentication Protocol (EAP) technologies, and the Remote Authentication Dial-In User (RADIUS) security server service.

Cisco IBNS offers scalable and flexible access control and policy enforcement services and capabilities at the network edge (i.e. at switch access ports) by providing the following:

• Per-user or per-service authentication services
• Policies mapped to network identity
• Port-based network access control based on authentication and authorization policies
• Additional policy enforcement based on access level

When the Cisco Access Control Server (ACS) is used as the authentication server in IBNS, the following features are available for network security administrators:

• Time and day restrictions
• NAS restrictions
• MAC address filtering
• Per-user and per-group VLAN assignments
• Per-user and per-group ACL assignments

IEEE 802.1x Overview

IEEE 802.1x is a protocol standard framework for both wired and wireless Local Area Networks that authenticates users or network devices and provides policy enforcement services at the port level in order to provide secure network access control. 802.1x is an IEEE standard for access control and authentication that provides a means for authenticating users who want to gain access to the network and placing them into a pre-determined VLAN, effectively granting them certain access rights to the network.

The 802.1x protocol provides the definition to encapsulate the transport of EAP messages at the Data Link Layer over any PPP or IEEE 802 media (e.g. Ethernet, FDDI, or Token Ring) through the implementation of a port-based network access control to a network device. EAP messages are communicated between an end device, referred to as a supplicant, and an authenticator, which can be either a switch or a wireless access point. The authenticator relays the EAP messages to the authentication server (e.g. a Cisco ACS server) via the RADIUS server protocol.

There are three primary components (or roles) in the 802.1x authentication process, as follows:

1. Supplicant or client
2. Authenticator
3. Authentication server

An IEEE 802.1x supplicant or client is simply an 802.1x-compliant device, such as a workstation, a laptop, or even an IP phone, with software that supports the 802.1x and EAP protocols. The supplicant sends an authentication request to the access LAN via the connected authenticator device (e.g. the access switch) using EAP.

An 802.1x authenticator is a device that enforces physical access control to the network based on the authentication status (i.e. permit or deny) of the supplicant. An example of an authenticator would be the switch illustrated in Figure 6-12 below. The authenticator acts as a proxy and relays information between the supplicant and the authentication server.

The authenticator receives the identity information from the supplicant via EAP over LAN (EAPOL) frames, which are verified and then encapsulated into RADIUS protocol format before being forwarded to the authentication server. It is important to remember that the EAP frames are not modified or examined during the encapsulation process, which means that the authentication server must support EAP within the native frame format. When the authenticator receives frames from the authentication server, the RADIUS header is removed, leaving only the EAP frame, which is then encapsulated in the 802.1x format. These frames are then sent back to the supplicant or client.

The authentication server is the database policy software, such as Cisco Secure ACS, that supports the RADIUS server protocol and performs authentication of the supplicant that is relayed by the authenticator via the RADIUS client-server model.

The authentication server validates the identity of the client and notifies the authenticator whether the client is allowed or denied access to the network. Based on the response from the authentication server, the authenticator relays this information back to the supplicant. It is important to remember that during the entire authentication process, the authentication server remains transparent to the client because the supplicant is communicating only to the authenticator. The RADIUS protocol with EAP extensions is the only supported authentication server; in other words, you cannot use TACACS+ or Kerberos as the authentication server.

NOTE: TACACS+ and Kerberos are authentication servers. Going into detail on the different types of authentication servers is beyond the scope of the SWITCH exam requirements.

Extensible Authentication Protocol Packet Format

802.1x authentication is initiated when the link transitions from a state of down to up. Either the switch or the client (supplicant) can initiate authentication. EAPOL is the encapsulation technique used to carry EAP frames between the supplicant and the authenticator. The frames have a destination MAC of 01-80-C3-00-00-03 whether the packet is to the supplicant or the switch. EAPOL is wrapped in an Ethernet frame as illustrated below in Figure 6-11:

Fig. 6-11.  EAPOL Frame Format

While delving into all the different fields illustrated in Figure 6-11 is beyond the scope of the SWITCH exam requirements, Table 6-3 below lists and describes common values that may be contained in the Packet Type field:

Table 6-3.  EAP Packet Types

The Extensible Authentication Protocol Message Exchange

The EAP message exchange is illustrated below in Figure 6-12:

 
Fig. 6-12.  EAP Message Exchange

The following sequence of steps reference the message exchange illustrated in Figure 6-12:

1. The client or supplicant sends the authenticator an EAPOL frame to start the authentication process.
2. The switch responds to the EAPOL frame by sending the supplicant a login request, asking for the correct credentials (e.g. username and password pair) to gain network access.
3. The supplicant provides the credentials to the authenticator.
4. The authentication encapsulates the received credentials in RADIUS format and relays them to the RADIUS authentication server.
5. When the RADIUS server receives the authentication request, it checks its database, which can be either internal or external, and then sends a response back.
6. This response is relayed by the authenticator to the supplicant.
7. The supplicant provides the requested information.
8. The authenticator relays this information to the RADIUS server.
9. Assuming that the check is successful, and the credentials match and have been validated, the supplicant receives a permit access message.  VLAN assignment is added to the access-accept packet from the RADIUS server.
10. This information is relayed by the authenticator to the supplicant.

The port then transitions to an authorized state and the supplicant is allowed to send packets on to the network. When the supplicant logs off the network, the port transitions to the unauthorized state and the login and authentication process will start over when the supplicant logs back on. If the credentials are incorrect, the supplicant can also receive a deny message and will not be allowed access to the LAN, and will be blocked at the port level. The authorized and unauthorized port states are described later in this chapter.

Configuring 802.1x Port-Based Authentication

Configuring basic 802.1x port-based authentication is a relatively straightforward process that is comprised of the following five basic steps:

1. Globally enable AAA services on the switch by issuing the aaa new-model global configuration command. AAA must be enabled before a switch can be configured for 802.1x port-based authentication services;
2. Create or use the default 802.1x authentication method list and specify RADIUS server information by issuing the aaa authentication dot1x [method-list|default] group [name|radius] global configuration command;
3. Configure RADIUS server parameters (e.g. keys and ports) via the radius-server host global configuration command for an individual server or the aaa group server radius global configuration command for a RADIUS server group;
4. Globally enable IEEE 802.1x authentication on the switch using the dot1x system-auth-control global configuration command; and
5. Enable 802.1x port-based authentication on desired switch ports by issuing the dot1x port-control{auto|force-authorized |force-unauthorized} interface configuration command.

When 802.1x is enabled on the authenticator, there are two port states in which the physical ports on the authenticator may be: authorized or unauthorized. Initially, all 802.1x-enabled ports start in an unauthorized state. In this state, no traffic is allowed through the port except for 802.1x message exchange packets.

If a non-802.1x connects to an unauthorized port, the authenticator has no way of knowing that the client does not support 802.1x and so it sends the client a login request asking it for identity credentials. However, because the client does not support 802.1x, it is unable to interpret the received packet and so it does not respond to the authenticator’s request.

Based on this, the authenticator denies all packets on that port and the switch port remains in the unauthorized state. Administrators control the port authorization state by using the dot1x port-control interface configuration command and one of the following keywords:

• The force-authorized keyword—disables 802.1x and causes the port to transition to the authorized state without any authentication exchange required. The port transmits and receives normal traffic without 802.1x-based authentication of the client. This is the default option.
• The force-unauthorized keyword—causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. In other words, the switch cannot provide authentication services to the client through the interface.
• The auto keyword—enables 802.1x authentication and forces the switch port to begin in the unauthorized state, allowing only EAPOL frames to be sent and received. The authentication process begins when the link state of the port transitions from down to up, or when an EAPOL-start frame is received. The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. Each client attempting to access the network is uniquely identified by the switch by using the client’s MAC address. This is the recommended mode when enabling 802.1x security.

The following output demonstrates the configuration of 802.1x port-based authentication on the FastEthernet0/23 and FastEthernet0/24 interfaces of a Cisco Catalyst switch. A RADIUS server with the IP address 10.1.1.254 and secret key switchauth will be configured to authentication 802.1x users. This RADIUS server will use UDP port 1812 for authentication services:

VTP-Server-1(config)#dot1x system-auth-control

NOTE: It is important to remember to configure the switch port as a static access port before enabling 802.1x port-based authentication; otherwise, the error message illustrated in the following output will be printed on the switch console:

Verifying 802.1x Port-Based Authentication

To view the 802.1x configuration of an interface, administrators should issue the show dot1x interface [name]command. The output of this command is shown as follows:

For troubleshooting, you can use the show dot1x statistics interface [name] command to view 802.1x statistics on a per-interface basis as shown in the following output:

802.1x Multiple Hosts Authentication

In most implementations, a single network host is connected to each individual switch port. This allows 802.1x to be configured on each switch port to support that individual host. However, in some networks, it is possible that multiple hosts may be connected to the same switch port, such as via a hub, for example.

To allow for 802.1x authentication in such situations, the 802.1x multiple hosts feature allows multiple users to gain access to a single authenticated 802.1x port. An initial user is required to go through normal authentication to ‘open’ up the link. Once authenticated, other users on the same link can gain access to the network without going through authentication.

Multiple hosts mode is enabled using the dot1x host-mode multi-host interface configuration command in addition to the five configuration steps listed at the beginning of this section. The following output illustrates how to enable this feature:

VTP-Server-1(config)#dot1x system-auth-control

VTP-Server-1(config-if-range)#dot1x host-mode multi-host