分类： 系统运维
2008-03-20 09:11:13
Understanding 802.1X Port-Based Authentication
The IEEE 802.1X standard defines a client-server-based access control and authentication protocol t hat restricts unauthorized clients from connecting to a LAN through publicly accessible ports. The authentication server authenticates each client connected to a switch port before making available any services offered by the switch or the LAN.
Until the client is authenticated, 802.1X access control allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the client is connected. After authentication is successful, normal traffic can pass through the port.
These sections describe 802.1X port-based authentication:
•
•
•
•
• Using 802.1X with Port Security
•
•
•
With 802.1X port-based authentication, the devices in the network have specific roles as shown in .
Figure 9-1 802.1X Device Roles
•Client—the device (workstation) that requests access to the LAN and switch services and responds to requests from the switch.The workstation must be running 802.1X-compliant client software such as that offered in the Microsoft Windows XP operating system. (The client is the supplicant in the IEEE 802.1X specification.)
Note To resolve Windows XP network connectivity and 802.1X authentication issues, read the Microsoft Knowledge Base article at this URL:
•Authentication server—performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether or not the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. In this release, the Remote Authentication Dial-In User Service (RADIUS) security system with Extensible Authentication Protocol (EAP) extensions is the only supported authentication server; it is available in Cisco Secure Access Control Server version 3.0. RADIUS operates in a client/server model in which secure authentication information is exchanged between the RADIUS server and one or more RADIUS clients.
•Switch (edge switch or wireless access point)—controls the physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client and the authentication server, requesting identity information from the client, verifying that information with the authentication server, and relaying a response to the client. The switch includes the RADIUS client, which is responsible for encapsulating and decapsulating the EAP frames and interacting with the authentication server.
When the switch receives EAPOL frames and relays them to the authentication server, the Ethernet header is stripped and the remaining EAP frame is re-encapsulated in the RADIUS format. The EAP frames are not modified or examined during encapsulation, and the authentication server must support EAP within the native frame format. When the switch receives frames from the authentication server, the server's frame header is removed, leaving the EAP frame, which is then encapsulated for Ethernet and sent to the client.
The devices that can act as intermediaries include the Catalyst 3550 multilayer switch, the Catalyst 2950 switch, the Catalyst 2955 switch, or a wireless access point. These devices must be running software that supports the RADIUS client and 802.1X.
The switch or the client can initiate authentication. If you enable authentication on a port by using the dot1x port-control auto interface configuration command, the switch must initiate authentication when it determines that the port link state transitions from down to up. It then sends an EAP-request/identity frame to the client to request its identity (typically, the switch sends an initial identity/request frame followed by one or more requests for authentication information). Upon receipt of the frame, the client responds with an EAP-response/identity frame.
However, if during bootup, the client does not receive an EAP-request/identity frame from the switch, the client can initiate authentication by sending an EAPOL-start frame, which prompts the switch to request the client's identity.
Note If 802.1X is not enabled or supported on the network access device, any EAPOL frames from the client are dropped. If the client does not receive an EAP-request/identity frame after three attempts to start authentication, the client sends frames as if the port is in the authorized state. A port in the authorized state effectively means that the client has been successfully authenticated. For more information, see the .
When the client supplies its identity, the switch begins its role as the intermediary, passing EAP frames between the client and the authentication server until authentication succeeds or fails. If the authentication succeeds, the switch port becomes authorized. For more information, see the .
The specific exchange of EAP frames depends on the authentication method being used. shows a message exchange initiated by the client using the One-Time-Password (OTP) authentication method with a RADIUS server.
Figure 9-2 Message Exchange
The switch port state determines whether or not the client is granted access to the network. The port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic except for 802.1X protocol packets. When a client is successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to flow normally.
If a client that does not support 802.1X is connected to an unauthorized 802.1X port, the switch requests the client's identity. In this situation, the client does not respond to the request, the port remains in the unauthorized state, and the client is not granted access to the network.
In contrast, when an 802.1X-enabled client connects to a port that is not running the 802.1X protocol, the client initiates the authentication process by sending the EAPOL-start frame. When no response is received, the client sends the request for a fixed number of times. Because no response is received, the client begins sending frames as if the port is in the authorized state.
You control the port authorization state by using the dot1x port-control interface configuration command and these keywords:
•force-authorized—disables 802.1X authentication and causes the port to transition to the authorized state without any authentication exchange required. The port sends and receives normal traffic without 802.1X-based authentication of the client. This is the default setting.
•force-unauthorized—causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. The switch cannot provide authentication services to the client through the interface.
•auto—enables 802.1X authentication and causes the port to begin in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. 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.
If the client is successfully authenticated (receives an Accept frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are allowed through the port. If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can resend the request. If no response is received from the server after the specified number of attempts, authentication fails, and network access is not granted.
When a client logs off, it sends an EAPOL-logoff message, causing the switch port to transition to the unauthorized state.
If the link state of a port transitions from up to down, or if an EAPOL-logoff frame is received, the port returns to the unauthorized state.
Multiple VLAN access ports (MVAPs) are ports that belong to two VLANs. This configuration allows the separating of voice traffic and the data traffic onto different VLANs. A switch port configured with a voice VLAN has separate VLANs configured for carrying:
•The voice traffic to and from the IP phone.
•The data traffic to and from the workstation connected to the switch through the IP phone.
Thus, each port configured for voice VLAN is associated with a port VLAN identifier (PVID) which is the native VLAN of the port, and a voice VLAN identifier (VVID) that is used to configure the IP phone connected to the port.
When 802.1X is enabled on a port that has a voice VLAN, the VLAN remains down on the port (equivalent to an unauthenticated state) until a CDP message is received from an IP phone. The VLAN then becomes active, allowing the phone to work independently of 802.1X authentication. The VLAN becomes inactive on the port if the CDP entry times out or if it is cleared by using the cdp clear table privileged EXEC command.
A workstation connected to the port uses the PVID and is authenticated through 802.1X as usual. The IP phone has access to the VVID for its voice traffic irrespective of the authorized or unauthorized state of the port.
Only one client is allowed on the voice VLAN other workstations or IP phones are blocked. When you enable the multiple-hosts mode, when an 802.1X user is authenticated on the primary VLAN, additional clients on the voice VLAN are unrestricted after 802.1X authentication succeeds on the primary VLAN.
When 802.1X is enabled on a port, you cannot configure a port VLAN that is equal to a voice VLAN.
You can enable an 802.1X port for port security by using the dot1x multiple-hosts interface configuration command. You must also configure port security on the port by using the switchport port-security interface configuration command. With the multiple-hosts mode enabled, 802.1X authenticates the port, and port security manages network access for all MAC addresses, including that of the client. You can then limit the number or group of clients that can access the network through an 802.1X multiple-host port.
These are some examples of the interaction between 802.1X and port security on the switch:
•When a client is authenticated, and the port security table is not full, the client's MAC address is added to the port security list of secure hosts. The port then proceeds to come up normally.
When a client is authenticated and manually configured for port security, it is guaranteed an entry in the secure host table (unless port security static aging has been enabled).
A security violation occurs if the client is authenticated, but port security table is full. This can happen if the maximum number of secure hosts have been statically configured, or if the client ages out of the secure host table. If the client's address is aged out, its place in the secure host table can be taken by another host. In this case, you should enable periodic reauthentication with a shorter time period than the port security aging time.
The port security violation modes determine the action for security violations. See the "Security Violations" section on page 20-8 for more information.
•When the client logs off, the port transitions back to an unauthenticated state and all dynamic entries in the secure host table are cleared, including the entry for the client. Normal authentication then takes place.
•If the port is administratively shut down the port becomes unauthenticated and all dynamic entries are removed from the secure host table.
See the , and the "Configuring Port Security" section on page 20-7 for more information about enabling 802.1X and port security on your switch.
You can enable per-user ACLs to provide different levels of network access and service to an 802.1X-authenticated user. The per-user ACL attributes are retrieved from the RADIUS server and are applied for the duration of the user session.
The switch supports only one type of per-user ACL, router ACLs or port ACLs. Router ACLs apply to Layer 3 interfaces, and port ACLs apply to Layer 2 or Layer 3 interfaces. If one port is configured with a port-based ACL, the switch rejects any attempt to configure a router-based ACL. In contrast, if one port has a router-based ACL, the switch rejects any attempt to configure a port-based ACL. To avoid configuration conflicts, you should carefully plan the user profiles stored on the RADIUS server.
Only one 802.1X-authenticated user is supported on a port. If the multiple-hosts mode is enabled on the port, the per-user ACL attribute is disabled for the associated port.
QoS maps and VLAN maps are not supported for per-user ACLs.
RADIUS supports per-user attributes, including vendor-specific attributes. These vendor-specific attributes (VSAs) are in octet-string format and are passed to the switch during the authentication process. The VSAs used for per-user ACLs are inacl#<n> for ingress direction and outacl#<n> for egress direction. MAC ACLs are only supported in the ingress direction.
Use only extended ACL syntax style to define the per-user configuration stored on the RADIUS server. When the definitions are passed from the RADIUS server, they are created by using the extended naming convention. However, if you use the Filter-Id attribute, it can point to a standard ACL.
You can use the Filter-Id attribute to specify an inbound or outbound ACL that is already configured on the switch. The attribute contains the ACL number followed by .in or .out for ingress filtering or egress filtering. If the RADIUS server does not allow .in or .out syntax, the access list is applied to the outbound ACL by default. The switch supports IP standard and IP extended access lists, number 1 to 199 and 1300 to 2699.
See the for examples of vendor-specific attributes and "Configuring Network Security with ACLs" for more information about configuring ACLs.
To configure per-user ACLs, you need to:
•Enable AAA authentication
•Enable AAA authorization using the network and config-commands keywords to allow interface configuration from the RADIUS server
•Enable 802.1X
•Configure the user profile and VSAs on the RADIUS server
•Disable the 802.1X multiple-hosts mode on the port
You can use VLAN assignment to limit network access for certain users. With VLAN assignment, 802.1X-authenticated ports are assigned to a VLAN based on the username of the client connected to that port. The RADIUS server database maintains the username-to-VLAN mappings. After successful 802.1X authentication of the port, the RADIUS server sends the VLAN assignment to the user.
When configured on the switch and the RADIUS server, 802.1X with VLAN assignment has these characteristics:
•If no VLAN is supplied by the RADIUS server or AAA authorization is disabled, the port is configured in its access VLAN after successful authentication.
•If authorization is enabled but the VLAN information from the server is not valid, the port remains down in the unauthenticated state. This prevents ports from appearing unexpectedly in an inappropriate VLAN because of a configuration error.
Configuration errors could include specifying a VLAN for a routed port, a malformed VLAN ID, a non-existent or internal (routed port) VLAN id, or attempting assignment to a voice VLAN ID.
•If authorization is enabled and all information from the server is valid, the port is placed in the specified VLAN after successful authentication.
•If the multiple-hosts mode is enabled, all hosts are in the same VLAN as the first authenticated user.
•If 802.1X is disabled on the port, it is returned to the configured access VLAN.
To configure VLAN assignment you need to:
•Enable AAA
•Enable 802.1X
•Assign vendor-specific tunnel attributes in the RADIUS server. The RADIUS server must return these attributes to the switch:
–[64] Tunnel-Type = VLAN
–[65] Tunnel-Medium-Type = 802
–[81] Tunnel-Private-Group-ID = VLAN NAME
Attribute [64] must contain the value VLAN (type 13). Attribute [65] must contain the value 802 (type 6). Attribute [81] specifies the VLAN name assigned to the 802.1X-authenticated user.
See the for examples of vendor-specific attributes.
The 802.1X port-based authentication is supported in two topologies:
•Point-to-point
•Wireless LAN
In a point-to-point configuration (see ), only one client can be connected to the 802.1X-enabled switch port. The switch detects the client when the port link state changes to the up state. If a client leaves or is replaced with another client, the switch changes the port link state to down, and the port returns to the unauthorized state.
shows 802.1X port-based authentication in a wireless LAN. The 802.1X port is configured as a multiple-host port that becomes authorized as soon as one client is authenticated. When the port is authorized, all other hosts indirectly attached to the port are granted access to the network. If the port becomes unauthorized (re-authentication fails or an EAPOL-logoff message is received), the switch denies access to the network to all of the attached clients. In this topology, the wireless access point is responsible for authenticating the clients attached to it, and the wireless access point acts as a client to the switch.
Figure 9-3 Wireless LAN Example
