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.
)
Figure 1Many 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.