With IEEE 802.1X port-based authentication, the devices in the network have specific roles as shown in the figure below.

Figure 1

IEEE 802.1X Device Roles

• Supplicant --Device (workstation) that requests access to the LAN and switch services and responds to requests from the router. The workstation must be running IEEE 802.1X-compliant client software such as that offered in the Microsoft Windows XP operating system. (The supplicant is sometimes called the client.)

Note	To resolve Windows XP network connectivity and IEEE 802.1X authentication issues, read the Microsoft Knowledge Base article at this URL: http://support.microsoft.com/kb/q303597/

• Authentication server --Device that performs the actual authentication of the supplicant. The authentication server validates the identity of the supplicant and notifies the router whether or not the supplicant is authorized to access the LAN and switch services. The Network Access Device (or ISR router in this instance) transparently passes the authentication messages between the supplicant and the authentication server, and the authentication process is carried out between the supplicant and the authentication server. The particular EAP method used will be decided between the supplicant and the authentication server (RADIUS server). The RADIUS security system with EAP extensions is available in Cisco Secure Access Control Server Version 3.0 or later. RADIUS operates in a client and server model in which secure authentication information is exchanged between the RADIUS server and one or more RADIUS clients.
• Authenticator (integrated services router ( ISR) or wireless access point)--Router that controls the physical access to the network based on the authentication status of the supplicant. The router acts as an intermediary between the supplicant and the authentication server, requesting identity information from the supplicant, verifying that information with the authentication server, and relaying a response to the supplicant. The router includes the RADIUS client, which is responsible for encapsulating and decapsulating the EAP frames and interacting with the authentication server.

When the authenticator receives EAPOL frames and relays them to the authentication server, the EAPOL is stripped and the remaining EAP frame is reencapsulated in the RADIUS format. The EAP frames are not modified during encapsulation, and the authentication server must support EAP within the native frame format. When the authenticator 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.

During IEEE 802.1X authentication, the router or the supplicant can initiate authentication. If you enable authentication on a port by using the dot1x port-control auto interface configuration command, the router initiates authentication when the link state changes from down to up or periodically if the port remains up and unauthenticated. The router sends an EAP-request/identity frame to the supplicant to request its identity. Upon receipt of the frame, the supplicant responds with an EAP-response/identity frame.

However, if during bootup, the supplicant does not receive an EAP-request/identity frame from the router, the supplicant can initiate authentication by sending an EAPOL-start frame, which prompts the router to request the supplicant's identity.

Note

If IEEE 802.1X authentication is not enabled or supported on the network access device, any EAPOL frames from the supplicant are dropped. If the supplicant does not receive an EAP-request/identity frame after three attempts to start authentication, the supplicant sends frames as if the port is in the authorized state. A port in the authorized state effectively means that the supplicant has been successfully authenticated. For more information, see the Ports in Authorized and Unauthorized States module.

When the supplicant supplies its identity, the router begins its role as the intermediary, passing EAP frames between the supplicant and the authentication server until authentication succeeds or fails. If the authentication succeeds, the router port becomes authorized. If the authentication fails, authentication can be retried, the port might be assigned to a VLAN that provides limited services, or network access is not granted. For more information, see the Ports in Authorized and Unauthorized States module.

The specific exchange of EAP frames depends on the authentication method being used. The figure below shows a message exchange initiated by the supplicant using the One-Time-Password (OTP) authentication method with a RADIUS server.

Figure 2

Message Exchange

To configure IEEE 802.1X port-based authentication, you must enable authentication, authorization, and accounting (AAA) and specify the authentication method list. A method list describes the sequence and authentication method to be queried to authenticate a user.

The AAA process begins with authentication. When IEEE 802.1X port-based authentication is enabled and the device attempting to authenticate is IEEE 802.1x-capable (meaning it supports the supplicant functionality) these events occur:

• If the supplicant identity is valid and the IEEE 802.1X authentication succeeds, the router grants the supplicant access to the network.

The router reauthenticates a supplicant when one of these situations occurs:

• Periodic reauthentication is enabled, and the reauthentication timer expires.

You can configure the reauthentication timer to use a router-specific value or to be based on values from the RADIUS server.

After IEEE 802.1X authentication using a RADIUS server is configured, the router uses timers based on the Session-Timeout RADIUS attribute (Attribute[27]) and the Termination-Action RADIUS attribute (Attribute [29]).

The Session-Timeout RADIUS attribute (Attribute[27]) specifies the time after which reauthentication occurs.

The Termination-Action RADIUS attribute (Attribute [29]) specifies the action to take during reauthentication. The actions can be Initialize or ReAuthenticate . When the Initialize action is set (the attribute value is DEFAULT ), the IEEE 802.1x session ends, and connectivity is lost during reauthentication. When the ReAuthenticate action is set (the attribute value is RADIUS-Request), the session is not affected during reauthentication.

• You manually reauthenticate the supplicant by entering the dot1x re-authenticate interfaceinterface-id privileged EXEC command.

Note	This section describes IEEE 802.1X security features available only on the switch ports in a Cisco ISR.

You can configure an IEEE 802.1X port for single-host or for multi-host mode. In single-host mode (see the figure IEEE 802.1X Device Roles in the Device Roles section of this module), only one supplicant can be authenticated by the IEEE 802.1X-enabled switch port. The router detects the supplicant by sending an EAPOL frame when the port link state changes to the up state. If a supplicant leaves or is replaced with another supplicant, the router changes the port link state to down, and the port returns to the unauthorized state.

In multi-host mode, you can attach multiple hosts to a single IEEE 802.1X-enabled port. In this mode, only one of the attached supplicants must be authorized for all supplicants to be granted network access. If the port becomes unauthorized (reauthentication fails or an EAPOL-logoff message is received), the router denies network access to all of the attached supplicants.

Note	Cisco 870 series platforms do not support single-host mode.

You can configure a guest VLAN for each IEEE 802.1X-capable switch port on the router to provide limited services to clients, such as downloading the IEEE 802.1X client. These clients might be upgrading their system for IEEE 802.1X authentication, and some hosts, such as Windows 98 systems, might not be IEEE 802.1X-capable.

When you enable a guest VLAN on an IEEE 802.1X port, the router assigns clients to a guest VLAN when the router does not receive a response to its EAP request/identity frame or when EAPOL packets are not sent by the client.

The router maintains the EAPOL packet history. If an EAPOL packet is detected on the interface during the lifetime of the link, the router determines that the device connected to that interface is an IEEE 802.1X-capable client, and the interface does not change to the guest VLAN state. EAPOL history is cleared if the interface link status goes down. If no EAPOL packet is detected on the interface, the interface changes to the guest VLAN state.

In Cisco IOS Release 12.4(11)T and later releases, if devices send EAPOL packets to the router during the lifetime of the link, the router does not allow clients that fail authentication access to the guest VLAN.

Note	If an EAPOL packet is detected after the interface has changed to the guest VLAN, the interface reverts to an unauthorized state, and IEEE 802.1X authentication restarts.

Any number of IEEE 802.1X-incapable clients are allowed access when the router port is moved to the guest VLAN. If an IEEE 802.1X-capable client joins the same port on which the guest VLAN is configured, the port is put into the unauthorized state in the user-configured access VLAN, and authentication is restarted.

Note	Guest VLANs are supported on IEEE 802.1X ports in single-host or multi-host mode.

Authentication manager uses a single session ID (referred to as a common session ID) for a client no matter which authentication method is used. This ID is used for all reporting purposes, such as the show commands and MIBs. The session ID appears with all per-session syslog messages.

The session ID includes:

• The IP address of the Network Access Device (NAD).
• A monotonically increasing unique 32 bit integer.
• The session start time stamp (a 32 bit integer).

This example shows how the session ID appears in the output of the show authentication command. The session ID in this example is 160000050000000B288508E5:

Switch# show authentication sessions

Interface MAC Address    Method Domain Status        Session ID
Fa4/0/4   0000.0000.0203 mab    DATA   Authz Success 160000050000000B288508E5

This is an example of how the session ID appears in the syslog output. The session ID in this example is also160000050000000B288508E5:

1w0d: %AUTHMGR-5-START: Starting 'mab' for client (0000.0000.0203) on Interface Fa4/0/4
AuditSessionID 160000050000000B288508E5
1w0d: %MAB-5-SUCCESS: Authentication successful for client (0000.0000.0203) on Interface
Fa4/0/4 AuditSessionID 160000050000000B288508E5
1w0d: %AUTHMGR-7-RESULT: Authentication result 'success' from 'mab' for client
(0000.0000.0203) on Interface Fa4/0/4 AuditSessionID 160000050000000B288508E5

The session ID is used by the NAD, the AAA server, and other report-analyzing applications to identify the client. The ID appears automatically. No configuration is required.

During IEEE 802.1X authentication, depending on the port state, the router can grant a supplicant access to the network. The port starts in the unauthorized state. While in this state, the port that is not configured as a voice VLAN port disallows all ingress traffic except for IEEE 802.1X authentication, CDP, and STP packets. When a supplicant is successfully authenticated, the port changes to the authorized state, allowing all traffic for the supplicant to flow normally. If the port is configured as a voice VLAN port, the port allows VoIP traffic and IEEE 802.1X protocol packets before the supplicant is successfully authenticated.

If a client that does not support IEEE 802.1X authentication connects to an unauthorized IEEE 802.1X port, the router requests the client's identity. In this situation, if 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 IEEE 802.1X-enabled supplicant connects to a port that is not running the IEEE 802.1X standard, the supplicant initiates the authentication process by sending the EAPOL-start frame. When no response is received, the supplicant sends the request for a fixed number of times. Because no response is received, the supplicant 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 IEEE 802.1X authentication and causes the port to change to the authorized state without any authentication exchange required. The port sends and receives normal traffic without IEEE 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 supplicant to authenticate. The router cannot provide authentication services to the supplicant through the port.
• auto --Enables IEEE 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 changes from down to up or when an EAPOL-start frame is received. The router requests the identity of the supplicant and begins relaying authentication messages between the supplicant and the authentication server. Each supplicant attempting to access the network is uniquely identified by the router by using the supplicant MAC address.

If the supplicant is successfully authenticated (receives an Accept frame from the authentication server), the port state changes to authorized, and all frames from the authenticated supplicant 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 router 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 supplicant logs off, it sends an EAPOL-logoff message, causing the router port to change to the unauthorized state.

If the link state of a port changes from up to down, or if an EAPOL-logoff frame is received, the port returns to the unauthorized state.

For information about configuring IEEE 802.1X port-based authentication, see the "Configuring IEEE 802.1X Authentication" section of the "Configuring IEEE 802.1X Port-Based Authentication" chapter in the Catalyst 3750 Switch Software Configuration Guide, 12.2(25)SEE.

Use the IEEE 802.1X--Conditional Logging feature for troubleshooting. When the Conditional Logging feature is enabled, the router generates debugging messages for packets entering or leaving the router on a specified interface; the router will not generate debugging output for packets entering or leaving through a different interface. You can specify the interfaces explicitly. For example, you may only want to see debugging messages for one interface or subinterface. You can also turn on debugging for all interfaces that meet specified condition. This feature is useful on dial access servers, which have a large number of ports.

Normally, the router will generate debugging messages for every interface, resulting in a large number of messages. The large number of messages consumes system resources, and can affect your ability to find the specific information you need. By limiting the number of debugging messages, you can receive messages related to only the ports you wish to troubleshoot.

For more information on Conditional Logging and enabling conditionally triggered debugging, see the "Enabling Conditionally Triggered Debugging" section of the "Troubleshooting and Fault Management" chapter in the Basic System Management Configuration Guide, Cisco IOS Release 15.0M.

Note

If you plan to implement system-wide accounting, you should also configure IEEE 802.1X accounting. Moreover, you need to inform the accounting server of the system reload event when the system is reloaded to ensure that the accounting server is aware that all outstanding IEEE 802.1X sessions on this system are closed.

Note	To enable IEEE 802.1X accounting, you must first configure IEEE 802.1X authentication and switch-to-RADIUS server communication.

IEEE 802.1X RADIUS accounting relays important events to the RADIUS server (such as the supplicant's connection session). This session is defined as the interval beginning when the supplicant is authorized to use the port and ending when the supplicant stops using the port.

Note

You must configure the IEEE 802.1X supplicant to send an EAP-logoff (Stop) message to the switch when the user logs off. If you do not configure the IEEE 802.1X supplicant, an EAP-logoff message is not sent to the switch and the accompanying accounting Stop message is not sent to the authentication server. See the Microsoft Knowledge Base article at the location: http://support.microsoft.com and set the SupplicantMode registry to 3 and the AuthMode registry to 1.

After the supplicant is authenticated, the switch sends accounting-request packets to the RADIUS server, which responds with accounting-response packets to acknowledge the receipt of the request.

A RADIUS accounting-request packet contains one or more Attribute-Value (AV) pairs to report various events and related information to the RADIUS server. The following events are tracked:

• User successfully authenticates.
• User logs off.
• Link-down occurs on an IEEE 802.1X port.
• Reauthentication succeeds.
• Reauthentication fails.

When the port state transitions between authorized and unauthorized, the RADIUS messages are transmitted to the RADIUS server.

The switch does not log any accounting information. Instead, it sends such information to the RADIUS server, which must be configured to log accounting messages.

This is the IEEE 802.1X RADIUS accounting process

1. A user connects to a port on the router.
2. Authentication is performed.
3. VLAN assignment is enabled, as appropriate, based on the RADIUS server configuration.
4. The router sends a start message to an accounting server.
5. Reauthentication is performed, as necessary.
6. The port sends an interim accounting update to the accounting server that is based on the result of reauthentication.
7. The user disconnects from the port.
8. The router sends a stop message to the accounting server.

The switch port does not log IEEE 802.1X accounting information. Instead, it sends this information to the RADIUS server, which must be configured to log accounting messages.

To configure IEEE 802.1X accounting, you need to do the following tasks:

• Enable accounting in your RADIUS server.
• Enable IEEE 802.1X accounting on your switch.
• Enable AAA accounting by using the aaa system accounting command.

Enabling AAA system accounting along with IEEE 802.1X accounting allows system reload events to be sent to the accounting RADIUS server for logging. When the accounting RADIUS server receives notice of a system reload event, the server can infer that all active IEEE 802.1X sessions are appropriately closed.

Because RADIUS uses the unreliable transport protocol User Datagram Protocol (UDP), accounting messages may be lost due to poor network conditions. If the switch does not receive the accounting response message from the RADIUS server after a configurable number of retransmissions of an accounting request, the following system message appears:

Accounting message %s for session %s failed to receive Accounting Response.

When the stop message is not transmitted successfully, a message like the following appears:

00:09:55: %RADIUS-3-NOACCOUNTINGRESPONSE: Accounting message Start for session 172.20.50.145 sam 11/06/03 07:01:16 11000002 failed to receive Accounting Response.

Note	Use the debug radius command or debug radius accounting command to enable the %RADIUS-3-NO ACCOUNTING RESPONSE message.

Use the show radius statisticscommand to display the number of RADIUS messages that do not receive the accounting response message.

For information about configuring IEEE 802.1X RADIUS accounting, see the "Enabling 802.1X Accounting" section of the "Configuring 802.1X Port-Based Authentication" chapter in the Catalyst 4500 Series Switch Cisco IOS Software Configuration Guide, 12.2(31)SGA.

The information sent to the RADIUS server is represented in the form of AV pairs. These AV pairs provide data for different applications. (For example, a billing application might require information that is in the Acct-Input-Octets or the Acct-Output-Octets attributes of a RADIUS packet.)

AV pairs are automatically sent by a router that is configured for IEEE 802.1X accounting. Three types of RADIUS accounting packets are sent by a router:

• START-sent when a new user session starts
• INTERIM-sent during an existing session for updates
• STOP-sent when a session terminates

The following table lists the AV pairs and when they are sent by the router:

You can configure the ISR to send Cisco vendor-specific attributes (VSAs) to the RADIUS server. The following table lists the available Cisco AV pairs.

Note	To enable VSAs to be sent in the accounting records you must configure the radius-server vsa send accounting command.

You can view the AV pairs that are being sent by the router by entering the debug radius accounting privileged EXEC command. For more information about this command, see the Cisco IOS Debug Command Reference. For more information about AV pairs, see RFC 3580, IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines .

• IEEE 802.1X must be enabled on the switch port.
• EAP support must be enabled on the RADIUS server.
• AAA authorization must be configured on the port for all network-related service requests.
• The port must be successfully authenticated.

• The switch port is always assigned to the configured access VLAN when any of the following conditions occurs:
  • No VLAN is supplied by the RADIUS server.
  • The VLAN information from the RADIUS server is not valid.
  • IEEE 802.1X authentication is disabled on the port.
  • The port is in the force authorized, force unauthorized, unauthorized, or shutdown state.

Note	An access VLAN is a VLAN assigned to an access port. All packets sent from or received on this port belong to this VLAN.

• Assignment to the configured access VLAN prevents ports from appearing unexpectedly in an inappropriate VLAN because of a configuration error. Examples of configuration errors include the following:
  • A nonexistent or malformed VLAN ID
  • Attempted assignment to a voice VLAN ID
• The IEEE 802.1X authentication with VLAN assignment feature is not supported on trunk ports, dynamic ports, or with dynamic-access port assignment through a VLAN Membership Policy Server (VMPS).
• If the multi-host mode is enabled on an IEEE 802.1X port, all hosts are placed in the same VLAN (specified by the RADIUS server) as the first authenticated host.
• If an IEEE 802.1X port is authenticated and put in the RADIUS server-assigned VLAN, any change to the port access VLAN configuration does not take effect.

Note	This section describes IEEE 802.1X security features available only on the switch ports in a Cisco ISR.

• Enable AAA authorization by using the network keyword to allow interface configuration from the RADIUS server. For detailed instructions, see the Configuring RADIUS Authorization for User Privileged Access and Network Services section of the Configuring Switch-Based Authentication chapter in the Catalyst 3750 Switch Software Configuration Guide, 12.2(25)SEE.
• Enable IEEE 802.1X authentication. For detailed instructions, see the Configuring RADIUS Login Authentication section of the Configuring Switch-Based Authentication chapter in the Catalyst 3750 Switch Software Configuration Guide, 12.2(25)SEE.

Note	The VLAN assignment feature is automatically enabled when you configure IEEE 802.1X authentication on an access port.

• Assign vendor-specific tunnel attributes in the RADIUS server. The RADIUS server must return these attributes to the router:
  • [64] Tunnel-Type = VLAN
  • [65] Tunnel-Medium-Type = 802
  • [81] Tunnel-Private-Group-ID = VLAN name or VLAN ID

Attribute [64] must contain the value "VLAN" (type 13). Attribute [65] must contain the value "802" (type 6). Attribute [81] specifies the VLAN name or VLAN ID assigned to the IEEE 802.1X-authenticated user.

For examples of tunnel attributes, see the Configuring the Switch to Use Vendor-Specific RADIUS Attributes section of the Configuring Switch-Based Authentication chapter in the Catalyst 3750 Switch Software Configuration Guide, 12.2(25)SEE.