Cisco® Identity-Based Networking Services (IBNS) provide a cost-effective identity-based network access control and policy enforcement solution, combining several Cisco products.
The Ethernet networks have been deployed without enforcing authentication and with open connectivity for many years; therefore, rolling out IEEE 802.1X will involve some level of complexity. In addition, the network administrators would need to have prior knowledge of the device capabilities before configuring the ports to which the clients are connected. That will introduce a major operational expense.
The Cisco identity enhancements bring an innovative and unique solution around these challenges. The solution includes a flexible rollout; while IEEE 802.1X secures the internal network by requiring employees to present valid credentials before accessing the network, some provision must be made for users without 802.1X supplicants. Flexible rollout mechanisms will provide IT managers with a flexible solution to grant access to partners, consultants, contractors, and guests to network resources over the same LAN connections as regular employees. In addition, multiple authentication methods can be configured for heterogeneous devices on the same switchport.
The access edge, where the end users get connected to the rest of the network, is one of the most vulnerable points when it comes to security. Cisco is offering IBNS to enable network security at the access edge, using network intelligence.
The identity enhancements also address the solution to the challenges faced while deploying IP telephony to expand secure authentication methods when connecting behind an IP phone.
Additionally, the Cisco identity enhancements address more flexible and stronger network resource access management by introducing comprehensive policy enforcement methods.
This paper outlines a framework based on the solution and benefits that Cisco Catalyst® 4500 and 6500 Series Switches offer to resolve customer access edge identity challenges.
With Cisco IBNS, these switches are capable of providing essential authentication flexibility when deploying authentication services at the access edge.
Security Deployment Considerations
In order to successfully deploy a secured IT infrastructure, we need to consider:
• Flexible authentication options: Include flexibility to authenticate using IEEE 802.1X, MAC Authentication Bypass (MAB), and/or web-based authentication (webauth).
• Open authentication: Includes flexibility to selectively open traffic through a Dot1X-enabled port.
• Host modes: Include single or multiple hosts, multiple domains (with Cisco or third-party IP phone support), and multiple authentication on the same switchport.
• Security policy enforcement: Includes downloadable access control lists (ACLs), per-user-based ACLs, filter-ID-based ACLs.
• IP telephony integration: Includes the security challenges in an IP telephony deployment and Cisco solutions to these challenges.
• Advanced extensions: Includes wake on LAN (WoL) and inaccessible authentication bypass (IAB).
Figure 1 shows the main components of IBNS, which includes the Authentication Server, Authenticator, and the Supplicant.
Figure 1. IBNS Components
The foundation of IBNS is IEEE 802.1X. It is a client-server-based link layer protocol used for transporting higher level protocols. This authentication method requires the user to have supplicant.
IEEE 802.1X works between the client (supplicant), the authenticator, and the authentication (RADIUS) server.
Cisco Catalyst 4500 and 6500 Series could play the role of an authenticator.
Until the client is authenticated, 802.1X access control only allows Extensible Authentication Protocol over LAN (EAPoL) traffic from the port to which the client is connected. After authentication is successful, normal traffic can pass through the port.
Figure 2 shows a simple EEE 802.1X setup.
Figure 2. IEEE 802.1X Components
From Cisco IOS® Software Release 12.2(50)SG and 12.2(33)SXI onward, all port-based authentications can be enabled using the "authentication" command under the interface configuration.
Note: By default, if customers are deploying IBNS, Cisco recommends to not deploy Port Security. The IEEE 802.1X has priority over Port Security. This means that Dot1X must authorize the port, typically before a MAC address can be learned, and then secured by Port Security. Only enable Port Security and Dot1X together if you absolutely must.
MAC Authentication Bypass (MAB)
The devices that cannot authenticate themselves using 802.1X but require network access can use MAB to authorize using 802.1X.
With this method, the MAC address of the connected devices is used to grant or deny network access. It uses MAC address as username and password.
It is used on ports where devices do not have 802.1X supplicant such as printers and fax machines.
Figure 3 shows that the MAC address of a non-supplicant PC and a printer are saved in an ACS authentication server's database to be used for MAB to grant network access.
Figure 3. Authentication using MAB
Below is an example of how MAC Authentication Bypass is configured on an interface:
To verify that the port has successfully authenticated using MAB or not, you may execute the following show command:
More commonly MAB is used as a fallback authentication method to Dot1X. In such a case a set of three EAPOLs is sent before transitioning from an 802.1X authentication method to MAB.
Webauth is an alternate method for 802.1X and MAB. It is used as either a standalone or fallback mechanism to authenticate unmanaged devices in the network. Contractors, partners, and guests require network access at the client's facilities; As such, a web-based portal application can be made available that identifies users prior to gaining access to the network.
Webauth does not require a supplicant. The end user initiates an HTTP connection by opening a web browser. The authenticator intercepts ingress HTTP packet from the host and sends an HTML login page. The user then keys in the credentials. HTTP response is parsed, and user credentials are validated with an ACS authentication server.
If authentication succeeds, the authenticator sends out a login success HTML page and applies the associated access policies.
Cisco's recommendation is to authenticate up to a maximum of 1000 clients using standalone webauth.
During the webauth process, the internal HTTP server of the switch hosts four HTML pages for delivery to the end user. They allow the HTTP server to notify the user of four different states of the authentication process: login (user is prompted for credentials), success (login succeeded), fail (login failed), and expire (login session expired due to excessive login failures).
Figure 4 shows a sample web browser that the users can see when authenticating using webauth.
Figure 4. Authentication using Webauth
When configured as a fallback mechanism, the following sample configuration could be used:
Figure 5 shows a sample configuration to set up the ACS for webauth.
Figure 5. Sample Configuration to Set Up ACS for Webauth
1. Click User Setup.
2. Select the group from the drop-down list of alternate groups.
3. Check Downloadable ACLs and assign an IP ACL specified in Shared Profile Component.
4. Check cisco-av-pair and specify the following in the box:
(This is an example of the proxy ACL; you can have any ACE that suites your network requirement.)
In Cisco IOS Software Release 12.2(52)SG and later releases, we are introducing web authentication syslog enhancements. The enhancements provide the inclusion of session IDs in syslog messages and the ability to filter debug messages by IP or MAC address.
Flexible Authentication (FlexAuth) Options
The Cisco Catalyst 4500 Series with Cisco IOS Software Release 12.2(50)SG and Cisco Catalyst 6500 Series with Cisco IOS Software Release 12.2(33)SXI support flexible authentication sequencing, in which the users have the flexibility to configure multiple authentication schemes (except open auth) in any order. It allows a fallback sequence (whether by default or defined by an admin) should one or more methods not be available as the hosts get connected to the switches.
FlexAuth supports a mechanism to fall back from one authentication method to another, while enabling the user to define the order of authentication. By default, the sequencing is locked to the following order: 802.1X, MAB, and then webauth.
Also, with FlexAuth, the priority can be used after authentication. As an example, consider a case in which the user specifies the order of authentication to be 802.1X and then MAB. Suppose the user defines the first priority to be 802.1X. If the supplicant is not able to answer any of the EAPoL requests, it will fall back to MAB. But it will not stop there since the first priority is configured to be 802.1X. It will keep trying and keep looking for the EAPoL packets from the host. So, after authentication, if it receives the EAPoL packets from the host, it will send an identity request (username and password) and get authenticated using 802.1X.
Upon reauthentication, the switch will try all the methods specified in the order command.
When the default order has been configured, the switch displays log messages similar to these:
With Cisco IOS Software Release 12.2(50)SG and 12.2(33)SXI, Cisco Catalyst 4500 and 6500 Series Switches offer an Open Auth option that allows multiple MAC addresses per port.
Using Open Auth method, the interface can be configured to allow unrestricted Layer 2 access to the network even before any authentication has succeeded. ACLs or VLAN configuration is used to restrict Layer 3 traffic. This feature is required for customers to easily deploy 802.1X and then move to the normal 802.1X framework.
This is useful for when a network administrator needs to deploy a network for the first time. Any traffic should be allowed to pass through the switch. This is to track all the MAC addresses used in the network and incorporate them in the ACS server.
This preauthentication open access is especially useful in a preboot execution environment (PXE), where accessing the network is needed to be able to download a bootable image containing an authentication client. The device then can get authenticated using the authentication methods mentioned prior to use the network resources.
Authentication Methods: Configuration Summary
Host Mode Configuration Options in Cisco Catalyst 4500 and 6500 Series
The host modes in a switch determine the number of hosts that can be authenticated on a given port. The new authentication framework allows different host classification modes to be configured on the switch.
The four main host modes that are offered are single host, multihost, multidomain, and multiauth.
This is the default host mode in identity. In this mode, only one user is allowed per port with only one MAC address. If the second MAC address is added to the network, a security violation will be generated that will put the port in the shutdown or errdisable state. To recover from the security violation, either a network administrator needs to do a manual shut/no_shut to bring up the interface or an errdisable recovery CLI needs to be configured to bring the port back up.
Multiple Host Mode
Multihost mode supports multiple hosts on the same port in a single domain. In this mode, multiple users could get connected to the switch through a hub; however, only one of the hosts will be authorized for all hosts on this port to be granted access to the network.
Also, a wireless access point could act as a client to the switch and serve as the first client to grant access to the clients attached to it.
As of Cisco IOS Software Release 12.2(50)SG, RADIUS assigned VLAN (dynamic VLAN assignment), guest VLAN, critical VLAN, and auth fail VLAN features are not supported.
Figure 6 shows that multiple client PCs behind an access point are connected to the same switchport in a single domain.
Figure 6. Multihost Mode
This feature is available in the Cisco Catalyst 4500 Series with Cisco IOS Software Release 12.2(50)SG and Cisco Catalyst 6500 Series with Cisco IOS Software Release 12.2(33)SXI and later releases.
Multiauth mode is a combination of all the host modes mentioned above. It could be used as a solution for virtual machines. In this mode, multiple users are allowed to authenticate behind the phone (phone is not mandatory) and one phone MAC address.
Multiauth should not be confused with multihost. As mentioned earlier, in multihost mode, once the first client is authenticated, the switch allows subsequent users on the same port to have access to the network.
In multiauth mode, multiple users behind a hub could be connected to a phone, and all the users behind the hub have to be authenticated individually.
At this time, any number of data domain users and only one voice user is allowed.
This mode could be used for a shared media in a conference room where there are few PCs to be authenticated and get access to the network.
Figure 7 shows multiple client PCs behind a hub which are on the same switchport, and each one of them have to be authenticated individually.
Figure 7. Multiauth Mode
Multiple Domain Authentication
The Cisco Catalyst 4500 Series with Cisco IOS Software Release 12.2(37)SG onward and Cisco Catalyst 6500 Series with Cisco IOS Software 12.2(33)SXI onward support multidomain authentication (MDA). This feature allows an IP phone (whether it is a Cisco or a third-party IP phone) and a host behind the IP phone to authenticate independently, using one of the three authentication mechanisms: 802.1X, MAB, or webauth (host only). Only two MAC addresses will be allowed per port, one in the data domain and one in the voice domain.
The administrator knows that this is a phone device and predefines the username and has to associate a Cisco attribute-value (AV) pair attribute in the ACS. Same cisco-av-pair device-traffic-class=voice could be configured in the user/group setup (at the user level or group level) for all IP phones, whether they are Cisco or third-party phones.
Figure 8 is a sample snapshot from the ACS.
Figure 8. Sample ACS Snapshot
After voice authentication, by looking at the attribute value, the switch will decide that this is a phone device. If the authentication is successful, the switch will put the device information into the voice domain.
If the phone is not authenticated successfully, then it will be in an unknown domain. In this case we cannot differentiate a phone from a PC. In such a case, a second device showing up in the unknown domain will trigger a security violation.
If there is a PC behind the IP phone, the PC can authenticate and pass traffic in access VLAN. The PC and phone authentication can be in any order.
Starting with Cisco IOS Software Release 12.2(52)SG, the Cisco Catalyst 4500 Series will support MDA with voice VLAN assignment. This feature enables dynamic voice VLAN assignment by a RADIUS server on switchports configured for MDA.
Cisco IP Phones
On linkup, the IP phone and the switch exchange Cisco Discovery Protocol packets to learn voice VLAN. The IP phone or switch initiates authentication. The IP phone gets authenticated and authorized in voice domain. The IP phone MAC address will then be installed in the voice VLAN. IP phone traffic will be switched in the designated voice VLAN.
Third-Party IP Phones
On linkup, the phone or switch initiates authentication. Primarily, after authentication the phone can exchange Dynamic Host Configuration Protocol (DHCP) packets with the DHCP server. The DHCP reply from the server carries DHCP option to instruct the phone to tag all the packets so the phone will start using the voice VLAN. In some situations protocols other than DHCP can be used to convey voice VLAN information, and these protocols can also transparently work in MDA mode.
Alternatively, third-party IP phones may also use Link Layer Discovery Protocol for Media Endpoint Devices (LLDP-MED) exchange to assign voice VLAN prior to authentication. Using LLDP-MED exchange has the advantage for the phone to learn how to tag its packets before authentication.
After the phone learns how to tag its packets, the switch will move the phone MAC address from access VLAN to voice VLAN. The phone traffic is now switched in voice VLAN.
Comprehensive Policy Enforcement Methods
Cisco identity enhancements address rich policy enforcement options such as VLAN policies (PVLAN, guest, auth fail), and ACL policies.
The next section covers the ACL option supported by Cisco Catalyst 4500 and 6500 Series Switches.
Downloadable ACL (dACL)
After the user is authenticated, you can specify the ACL either on Cisco Av-pair or a downloadable ACL.
After authentication, the ACS will push those ACLs to the switch. As soon as the switch downloads all the ACLs from the ACS, it will try to get an IP address for the host. After it gets the IP for the host (using either DHCP snooping or ARP snooping), it will associate the downloaded ACLs to that specific IP address and program it in TCAM. An IP device tracking table is used to map IP to host.
One default ACL must be configured on the port to use the downloaded ACLs. Downloaded ACLs will overwrite the default ACL. RADIUS VSA attributes must be globally configured on the switch to download ACLs:
radius-server vsa send authentication
Cisco Catalyst 4500 and 6500 Series Switches support ACLs greater than 4 kbyte in length.
Using this feature, an ACL configured on the RADIUS server using Cisco AV pairs will be dynamically applied on a port after a successful user or device authentication. This feature will be introduced in Cisco IOS Software Release 12.2(52)SG and later releases.
This enhancement allows ACL policy enforcement using a third-party AAA server in addition to the Cisco ACS server.
This feature enables an ACL configured on the switch and referenced by the RADIUS filter-ID attribute to be dynamically applied on a port in the inbound or outbound direction after a successful user or device authentication. This feature will be supported in Cisco IOS Software Release 12.2(52)SG and later releases.
This enhancement also allows ACL policy enforcement using a third-party AAA server in addition to the Cisco ACS server.
IP Telephony Integration
As described earlier, MDA allows for the secure deployment of IP telephony.
One of the challenges that customers face while deploying IP telephony is that an IP phone is both an endpoint requiring authentication and a device that allows hosts to connect through it to the corporate network, therefore requiring two separate domains (data and voice) on a single port. The Cisco Catalyst 4500 and 6500 Series Switches offer MDA to support this feature.
Also, in order to prevent potential security vulnerabilities, these switches support IBNS solutions to resolve the IP telephony integration challenges. The solutions include inactivity timers, and certain models of Cisco IP phones issue Cisco Discovery Protocol notifications and EAP logoffs when PCs disconnect from IP phones.
Proxy EAPoL Logoff
Customers who have logoff-capable phones would be able to use proxy EAPoL logoff as an option to prevent potential security vulnerabilities. When a Dot1X-enabled device plugged behind a phone is disconnected, the IP phone detects the link down event and informs the switch by sending an EAPoL-logoff message. This allows the 802.1X process on the switchport to be cleared. Therefore the session will be immediately cleared.
The caveat to this solution is that it only works for 802.1X devices behind the phone.
Figure 9 shows that when the PC behind the phone is unplugged, the logoff capable phone sends out an EAPoL-logoff message to the switch.
Figure 9. Proxy EAPoL Logoff Solution
To respond to the security violation challenges that customers experience while deploying IP telephony, Cisco has developed another solution that is supported on Cisco Catalyst 4500 and 6500 Series Switches. When a device that has been authenticated using MAB disconnects from a phone, and a second legitimate user or a hacker connects to the phone on the same switchport, a security violation could occur.
In this case, customers cannot use the EAPoL logoff solution since there is no EAPoL traffic originated from the client.
In earlier releases of Cisco IOS Software, there was only a reauthentication timer available to make sure the right user was connected. Now customers have the option of configuring an inactivity timer on the switch.
When the inactivity timer is specified on a port, it will start ticking when the user is authenticated and the switch begins to detect traffic to or from the authenticated devices. If no traffic is seen for that inactivity timer period, the timer expires, and the host session will be cleared so that the next user cannot connect through the same link without a reauthentication on that same interface.
If the switch detects the traffic coming from the host again, the inactivity timer will be restarted. This is a way of controlling unauthorized access.
By default, the inactivity timer is off.
The caveat to this solution is that there could be a window of vulnerability until the inactivity timer expires.
Figure 10 shows that when a PC behind the phone is unplugged, the configured inactivity timer on the Cisco catalyst switch expires, and the session is cleared,
Figure 10. Inactivity Timer Feature
Cisco Discovery Protocol Second-Port Status TLV
Another solution to the IP telephony deployment challenge is Cisco Discovery Protocol second-port status TLV. This feature adds support for processing Cisco Discovery Protocol packets sent from Cisco IP phones indicating the device behind the phone has been disconnected.
The Cisco Discovery Protocol second-port status TLV is the latest solution offered by Cisco IBNS, which is supported by Cisco Catalyst 4500 and 6500 Series Switches to solve the link state issue. Cisco Discovery Protocol sends a TLV message when a PC port status changes.
When the second port goes down, the session associated with it will be deleted.
No configuration is needed as long as the appropriate software is downloaded on the switch. It is supported on Cisco IOS Software Releases 12.2(50)SG and 12.2(33)SXI onward.
Figure 11 shows that when the PC behind the phone is unplugged, the phone sends a TLV message to the switch to relay the status of the port to the switch.
Figure 11. Cisco Discovery Protocol Second-Port Status TLV Feature
In addition to the features described above, Cisco Catalyst 4500 and 6500 Series Switches support the identity extensions to IEEE 802.1X port-based authentication. These extensions are unidirectional controlled port and inaccessible authentication bypass (IAB).
Unidirectional Controlled Port
In the networks where a remote management of the systems is needed to check if PCs have been powered down, the unidirectional controlled port feature plays an important role. This feature is also known as wake on LAN (WoL).
An uncontrolled port is used by 802.1X protocol to allow Extensible Authentication Protocol over LAN (EAPOL) frames to communicate credentials to determine if access should be allowed. A controlled port, in contrast, is a port that is open only when the device connected to the port has been authorized by 802.1X. The PC will be powered down if the switchport it is connected to is Dot1X-enabled. The status of the port at this state will be changed to "unauthenticated," and it will go to spanning tree blocking state. The unidirectional controlled port feature uses a specific Ethernet frame, called magic packet, to wake up the PC that has been powered down.
Unauthenticated ports can forward egress traffic while blocking the ingress traffic, hence the name unidirectional controlled port.
Inaccessible Authentication Bypass
Customers who require providing network access to the hosts when the RADIUS server is not reachable by the switch can assign the hosts to be connected to a port configured as a critical. Inaccessible authentication bypass is also called critical authentication.
Cisco Catalyst 4500 and 6500 Series Switches can grant network access to the hosts by putting the port in the critical-authentication state when the RADIUS server is unavailable. When a RADIUS server becomes available, all critical ports in critical-authentication state will be automatically reauthenticated.
The IBNS on Cisco Catalyst 4500 and 6500 Series Switches is a cost-effective identity solution that offers authentication, access control, and user policies to secure network resources.
A port must be configured to handle any type of access since the network administrator might not know what device is connected to the port ahead of time.
To meet customer security requirements, IBNS provides greater flexibility. With Cisco IBNS, the Cisco Catalyst 4500 and 6500 Series Switches are capable of overcoming today's security challenges to make customer deployments successful.