No matter how much time is spent preparing and securing networks, there is one vital component of a campus network that often goes unnoticed or unchecked. Many hours are spent deciding how to implement the switches, how to utilize VLANs, where to perform Layer 3 functionality, how to implement redundancy, how to implement a management scheme, which trunking (tagging) protocol to use, how to configure spanning-tree options such as portfast, and even whether to use 802.1u auto sensing for port speed and duplex or to manually set those parameters. In many networks, however, little time is spent deciding how to control what devices have access to the ports. Whether there are 500 or 50,000 access (user) ports, it's just not practical to think about how to control what or who can or cannot use a port. The IEEE 802.1X standard might just change that line of thinking.
The Problem with Ports
One of the most vulnerable components in the network is the wall outlet. Anyone who has access to the outlet can plug into that wall jack and, with the introduction of wireless networking, unauthorized users can access the network without even having to bring along their own cable. Several solutions exist to this problem, but few are manageable and easy to implement.
First, one could simply disable all the unused ports in the network. If there is a wall outlet that will not be used, it should simply be disabled. This is accomplished on a Catalyst switch by issuing the command set port disable mod/port for devices running the Catalyst Operating System (COS), or by accessing interface configuration mode on a Catalyst switch running Cisco IOS and issuing the command shutdown. Now, the port is completely secure. If someone wants to use the port, however, they must contact the administrator and have it turned back on. This solution can be a management nightmare, especially if there are many mobile users in your network. Plus, this does not prevent anyone from unplugging a device that is already connected to a working port and gaining access by using that port.
Another possible solution is to set up port security on all the ports. This involves registering the MAC address of the device(s) that will be using the port with the switch so that, if any unregistered MAC addresses were to plug into the port, the port would be unusable. Depending on the type of hardware and software, configuring the port to become suspended (unusable until the bad MAC address goes away), or disabled (unusable until the administrator re-enables the port) could be a possibility. This solution seems promising until you start registering MAC addresses. Each port on each switch must be configured to know which MAC addresses are allowed. This might involve manually entering the addresses or allowing them to be learned by the switch. In either case, if the MAC address changes or is moved to a different port, the administrator must reconfigure the switch.
Some of the other methods of controlling access include assigning any unused port to a VLAN that has been configured to be disabled or placing the port in a VLAN that does not have an IP address structure (no DHCP/BOOTP server or gateway). Although all these methods are effective, they lack the scalability or manageability needed in the modern campus network.
The IEEE 802.1X Standard
The IEEE 802.1X standard was approved in the summer of 2001 and provides a vendor-independent solution to port control. The 802.1X standard steps up where other methods have fallen short. The 802.1X or dot1x standard relies on the client to provide credentials in order to gain access to the network. How is that different from port security? The credentials are not based on a hardware address. Instead, they can be either a username/password combination or a certificate. This means that the credentials can be set on a device or user basis, unlike port security, because they always have the same MAC address. Next, the credentials are not verified by the switch but are sent to a Remote Authentication Dial-In User Service (RADIUS) server, which maintains a database of authentication information. This means that the authentication can be centralized and does not have to be configured on a port-by-port or switch-by-switch basis. Furthermore, RADIUS servers can be configured to use the same authentication databases as many popular OS databases, such as Windows 2000/NT Active Directory or Generic LDAP.
802.1X consists of three components for port control, which are as follows:
An 802.1X authenticator: This is the port on the switch that has services to offer to an end device, provided the device supplies the proper credentials.
An 802.1X supplicant: This is the end device; for example, a PC that connects to a switch that is requesting to use the services (port) of the device. The 802.1X supplicant must be able to respond to communicate.
An 802.1X authentication server: This is a RADIUS server that examines the credentials provided to the authenticator from the supplicant and provides the authentication service. The authentication server is responsible for letting the authenticator know if services should be granted.
The 802.1X authenticator operates as a go-between with the supplicant and the authentication server to provide services to the network. When a switch is configured as an authenticator, the ports of the switch must then be configured for authorization. In an authenticator-initiated port authorization, a client is powered up or plugs into the port, and the authenticator port sends an Extensible Authentication Protocol (EAP) PDU to the supplicant requesting the identification of the supplicant. At this point in the process, the port on the switch is connected from a physical standpoint; however, the 802.1X process has not authorized the port and no frames are passed from the port on the supplicant into the switching fabric. If the PC attached to the switch did not understand the EAP PDU that it was receiving from the switch, it would not be able to send an ID and the port would remain unauthorized. In this state, the port would never pass any user traffic and would be as good as disabled. If the client PC is running the 802.1X EAP, it would respond to the request with its configured ID. (This could be a username/password combination or a certificate.)
After the switch, the authenticator receives the ID from the PC (the supplicant). The switch then passes the ID information to an authentication server (RADIUS server) that can verify the identification information. The RADIUS server responds to the switch with either a success or failure message. If the response is a success, the port will be authorized and user traffic will be allowed to pass through the port like any switch port connected to an access device. If the response is a failure, the port will remain unauthorized and, therefore, unused. If there is no response from the server, the port will also remain unauthorized and will not pass any traffic. Figure 1 shows the exchange for an authenticator-initiated port authorization.
Many questions come to mind when looking at this configuration, such as, "How does the client know to respond?" "Won't the DHCP request time out before this occurs?" and What if my RAIDUS server is down?
First, if the client does not support the 802.1X protocol, it doesn't respond and will not be authorized. Clients that do not have the appropriate credentials or support the EAP are not able to access an 802.1X port. For this reason, the PCs connecting to 802.1X authenticators must support EAP. Currently, Windows XP and CE have 802.1X protocol support, but soon there will be third-party client packages available for many operating systems, including Windows 2000 and Windows 98. Also, many 802.1X clients are available for wireless adapters. As for DHCP, a port that supports 802.1X is not in a functional state until after the port is authorized. Because the port is not up yet, even though it is connected, it will not send a DHCP request once the port has been authorized; the protocol can be activated and a DHCP request will be sent out. Finally, if there is no response from a RADIUS server, the port will not be authorized. It is possible, however, to configure the switch to use multiple radius servers in the event that the server is unreachable.
Configuring 802.1X consists of configuring the three participants for operation. The RADIUS server (authentication server) and the client (supplicant) must be configured with the proper authentication identification, such as passwords and usernames or certificates and certificate authorities. Going to the Authentication tab for the Adapter properties enables a Windows XP client 802.1X. Then choose the authentication type and enter the required ID information. Third-party clients must also be configured to use the protocol for the adapters and with the appropriate ID information. This will, of course, vary depending on the 802.1X client software. The RADIUS server must be configured with the address of any device that will be requesting information; it must also be configured with a unique key that also must be configured on the switch. Finally, the RADIUS server will be configured with the username/password or certificate information. The switch must also be configured as the authenticator.
Configuring 802.1X on the Switch
Cisco Catalyst 5000/5500, 6000/6500, 4000, 2950, or 3550 switches can be configured as an authenticator, provided that they are running at the appropriate code level. For the Catalyst 5000/5500, 6000/6500, and 4000 running COS, version 6.2 or greater is required. The Catalyst 2950 requires Cisco IOS version 12.1(6) EA2 or greater, and the Catalyst 3550 requires Cisco IOS version 12.1(8) EA1 or greater.
The fist step to configuring the authenticator is to provide it with the address and key of the RADIUS server that will act as an authentication server. This is accomplished using the commands listed (this assumes that the switch is already configured with the appropriate IP addressing information):
For COS switches:
COSSwitch (enable) set radius server 192.168.101.98 primary COSSwitch (enable) set radius key ABC6108
For IOS switches:
IOSSwitch#conf t IOSSwitch (config)#aaa new-model IOSSwitch (config)#radius-server host 192.168.101.98 IOSSwitch (config)#radius-server key ABC6108
The next step in the process is to enable the 802.1X port authentication process. This step makes the switch an authenticator, allows it to send the EAP messages to the supplicant, proxy the information to the authentication (RADIUS) server(s) configured in Step 1, and act on the messages received from those servers to authorize ports. To configure the switch to act as an authenticator, use the following commands.
For COS switches:
COSSwitch (enable) set dot1x system-auth-control enable
For IOS switches:
IOSSwitch (config)#aaa authentication dot1x default group radius
The final step is to configure the ports on the authenticator for authorization. Ports can be in one of three authorization modes. The first mode, force-authorized, is the default mode. In this mode, a port is always authorized and does not require any messages from either the supplicant or the authentication server. Force-authorized mode is used when you do not want to run 802.1X on a particular port. This is typically the case when connecting to another switch, a router ,or a server, and also when connecting to clients that do not support 802.1X. The next mode, auto, is the normal 802.1X mode. A port in auto mode sends EAP packets to the supplicant and will not become authorized unless it receives a positive response from the authentication server. The final mode, force-unauthorized, prevents a port from becoming authorized even if the user has the appropriate credentials. This mode essentially disables the port from use by any user or device. To configure the ports, use the following commands.
For COS switches:
COSSwitch (enable) set port dot1x mod/port port-control
[auto | force-authorized | force-unauthorized]
For IOS switches:
IOSSwitch#conf t IOSSwitch (config)#interface fastethernet mod/port IOSSwitch (config-if)#dot1x port-control [auto | force-authorized | force-unauthorized]
After a port is configured in auto mode, no clients connected to that port will be allowed to pass user traffic until the port has been authorized by the authorization server. A major portion of the configuration involves the supplicant and the authentication server because so much of the authorization process takes place outside of the switch. A variety of devices and clients can act in these roles, so you have to check the individual vendor-configuration guides for details concerning those devices.
One of the major benefits of a centralized RADIUS server is that the IETF has provided extended TAG information that can be sent along with a RADIUS message. If you are running Catalyst OS 7.2 or greater, you can configure an 802.1X authenticated port and can also assign a VLAN based on the information returned by the RADIUS server. This means that clients can now be placed in a VLAN on a switch based on the credentials of the user and/or device accessing the network. Credentials are separate for different users; therefore, two users logging into the same device (at different times) can be assigned to different VLANs. VLAN assignment requires that the RADIUS server returns IETF attributes [64] Tunnel-Type, [65] Tunnel-Medium-Type, and [81] Tunnel-Private-Group-ID. These attributes must have the following TAGs and settings:
[64] Tunnel-Type, TAG 1=VLAN
[65] Tunnel-Medium-Type, TAG1=802
[81] Tunnel-Private-Group-ID, TAG1="vlan_name"
Attribute 81 returns the Group ID, and this must match the name of the VLAN in the local switch database exactly (the name is case sensitive). If the VLAN name is not found in the VLAN database of the local switch, the port will not be authorized. Currently, the 802.1X VLAN assignment is the only support on COS switches running IOS 7.2 or greater.
Summary
Campus networks have many features and parameters that must be managed by network administrators in order to facilitate a reliable and scalable network. Many times, the balancing of these parameters does not allow for a great level of control concerning who and what is plugged into the ports of the network devices. The IEEE 802.1X standard offers a standardized method for controlling port access in a central location on a user or device basis. 802.1X is one of many emerging standards that are helping facilitate the control of campus networks.
Copyright © 2000-2002 by Publications & Communications Inc. (PCI). All rights reserved.