The need for secure network access has never been greater. In today's diverse workplaces, consultants, contractors, and even guests require access to network resources over the same LAN connections as regular employees, who may themselves bring unmanaged devices into the workplace. As data networks become increasingly indispensable in day-to-day business operations, the possibility that unauthorized people or devices will gain access to controlled or confidential information also increases.
The best and most secure solution to vulnerability at the access edge is to use the intelligence of the network. Cisco IOS® Software enables standards-based network access control at the access layer by using the IEEE 802.1X protocol to secure the physical ports where end users connect. IEEE 802.1X is an IEEE standard for media-level (Layer 2) access control, offering the capability to permit or deny network connectivity based on the identity of the end user or device.
This document focuses on deployment considerations specific to IEEE 802.1X.
IEEE 802.1X offers the following benefits on wired networks:
• Visibility: IEEE 802.1X provides greater visibility into the network since the authentication process provides a way to link a username with an IP address, MAC address, switch, and port. This visibility is useful for security audits, network forensics, network use statistics, and troubleshooting.
• Security: IEEE 802.1X is the strongest method for authentication and should be used for managed assets that support an IEEE 802.1X supplicant. IEEE 802.1X acts at Layer 2 in the network, allowing you to control network access at the access edge.
• Identity-based services: IEEE 802.1X enables you to use an authenticated identity to dynamically deliver customized services. For example, a user might be authorized for a specific VLAN or assigned a unique access list that grants appropriate access for that user.
• Transparency: In many cases, IEEE 802.1X can be deployed in a way that is transparent to the end user.
• User and device authentication: IEEE 802.1X can be used to authenticate devices and users.
Although IEEE 802.1X enables outstanding visibility and security, it has limitations that your design must address:
• Support for older endpoints: By default, IEEE 802.1X provides no network access to endpoints that cannot authenticate because they do not support IEEE 802.1X. An alternative mechanism such as MAC authentication bypass (MAB) or web authentication must be provided for older endpoints.
• Delay: By default, IEEE 802.1X allows no access before authentication. Endpoints that need immediate network access must be capable of performing IEEE 802.1X authentication at or near boot or link time, or some alternative mechanisms must be used to grant the necessary access in a timely manner.
2.2 Functional Overview
2.2.1 What Is IEEE 802.1X?
IEEE 802.1X enables port-based access control using authentication. An IEEE 802.1X-enabled port can be dynamically enabled or disabled based on the identity of the user or device that connects to it. Figure 1 illustrates the default behavior of an IEEE 802.1X-enabled port.
Figure 1. Default Network Access Before and After IEEE 802.1X
Prior to authentication, the endpoint's identity is unknown, and all traffic is blocked. After authentication, the endpoint's identity is known, and all traffic from that endpoint is allowed. The switch performs source MAC address filtering to help ensure that only the authenticated endpoint is allowed to send traffic.
2.2.1.1 Components
IEEE 802.1X defines three required components (shown in Figure 2):
• Supplicant: A supplicant is a client that runs on the endpoint and submits credentials for authentication. Supplicants can be software applications (such as Cisco® Secure Services Client [SSC]), or they can be embedded in the operating system (for example, Microsoft Windows) or hardware (for example, Intel vPro).
• Authenticator: The authenticator is the network access device that facilitates the authentication process by relaying the supplicant's credentials to the authentication server. The authenticator enforces both the locally configured network access policy and the dynamically assigned network access policy returned by the authentication server. In the context of this document, the authenticator is simply the access layer switch, and the two terms-"authenticator" and "switch"-are used interchangeably.
• Authentication server: This is the server that validates the supplicant's credentials and determines what network access the supplicant should receive. The effective industry standard is a RADIUS server, such as Cisco Secure Access Control Server (ACS). In this document, "RADIUS server" and "authentication server" are used interchangeably.
Figure 2. IEEE 802.1X Components
In addition to the required components, other components are almost always used in practice:
• Back-end identity databases: These databases are centralized identity stores that the authentication server can query to validate credentials. Typical back-end databases include Microsoft Active Directory, Novell eDirectory, and a Lightweight Directory Access Protocol (LDAP) server. By using existing back-end databases, the authentication server is relieved of the burden of internally maintaining credentials such as passwords.
• Public key infrastructure (PKI): PKI is the set of technologies and processes that enables the distribution and maintenance of digital certificates. Because IEEE 802.1X often uses client and server certificates in the authentication process, many of the system components may need to be integrated with PKI.
2.2.1.2 Protocols
IEEE 802.1X uses several protocols (Figure 3):
• Extensible Authentication Protocol (EAP): EAP specifies the message format and framework defined by RFC 4187 that provides a way for the supplicant and the authentication server to negotiate an authentication method (the EAP method).
• EAP method: This method defines the authentication method: that is, the credential type and how it will be submitted from the supplicant to the authentication server using the EAP framework. Common EAP methods used in IEEE 802.1X networks are Protected EAP Microsoft Challenge Handshake Authentication Protocol Version 2 (PEAP-MSCHAPv2) and EAP Transport Layer Security (EAP-TLS).
• EAP over LAN (EAPoL): EAPoL is an encapsulation defined by IEEE 802.1X for the transport of EAP from the supplicant to the switch over IEEE 802 wired networks. EAPoL is a Layer 2 protocol.
• RADIUS: RADIUS is the effective standard for communication between the switch and the authentication server. The switch extracts the EAP payload from the Layer 2 EAPoL frame and encapsulates the payload inside a Layer 4 RADIUS packet.
Figure 3. IEEE 802.1X Wire Protocols
2.2.1.3 High Level Functional Sequence
The high-level functional sequence in Figure 4 shows how the components and protocols of IEEE 802.1X work together. The message exchange is divided into four stages: session initiation, session authentication, session authorization, and session accounting. A fifth stage, session termination, is not shown. Each stage is described in the sections that follow.
Figure 4. High-Level IEEE 802.1X Sequence
2.2.2 Session Initiation
IEEE 802.1X authentication can be initiated by either the switch or the supplicant. From the switch's perspective, the authentication session begins when the switch detects link up on a port. The switch will initiate authentication by sending an EAP Request-Identity message to the supplicant. If the switch does not receive a response, the switch will retransmit the request at periodic intervals.
The supplicant can initiate authentication by sending an EAPoL Start frame. EAPoL Start frames enable supplicants to speed up the authenticate process without waiting for the next periodic EAP Request-Identity message from the switch. EAPoL Start messages are required in situations in which the supplicant is not ready to process an EAP Request message from the switch (for example, because the operating system is still booting) or in which there is no physical link state change on the switch (for example, because the supplicant is indirectly connected through an IP phone or hub).
Best Practice Recommendation: Help Ensure That Your Supplicants Send EAPoL Start Messages
Not all supplicants send EAPoL Start messages by default (the Microsoft Windows XP with Service Pack 2 [SP2] native supplicant is a common example), but most can and should be configured to do so for the proper operation of IEEE 802.1X in a real-world network.
2.2.3 Session Authentication
During this stage, the switch relays EAP messages between the supplicant and the authentication server, copying the EAP message in the EAPoL frame to an attribute-value pair in a RADIUS packet, and the reverse. In the first part of the exchange, the supplicant and the authentication server agree on an EAP method.
The rest of the exchange is defined by the specific EAP method. The EAP method defines the type of credential to be used to validate the supplicant's identity and the way that the credential will be submitted. Depending on the method, the supplicant may submit a password, certificate, token, or other credential, and that credential may be passed inside a TLS-encrypted tunnel, as a hash or some other protected form.
2.2.4 Session Authorization
If the supplicant submits a valid credential, the authentication server will return a RADIUS Access-Accept message with an encapsulated EAP Success message. This sequence indicates to the switch that the supplicant should be allowed access to the port. Optionally, the authentication server may include dynamic network access policy instructions (for example, a dynamic VLAN or access control list [ACL]) in the Access-Accept message. In the absence of dynamic policy instructions, the switch will simply open the port.
If the supplicant submits an invalid credential or is not allowed to access the network for policy reasons, the authentication server will return a RADIUS Access-Reject message with an encapsulated EAP Failure message. This message indicates to the switch that the supplicant should not be allowed access to the port. Depending on how the switch is configured, it may retry authentication, deploy the port to the Auth-Fail VLAN, or try an alternative authentication method.
2.2.5 Session Accounting
If the switch successfully applies the authorization policy, the switch sends a RADIUS Accounting-Request message to the authentication server with details about the authorized session. Accounting-Request messages are sent for both dynamically authorized sessions and locally authorized sessions (for example, guest VLANs and Auth-Fail VLANs). For more information about IEEE 802.1X accounting, see Section 2.3.14.
2.2.6 Session Termination
Session termination is an important part of the IEEE 802.1X authentication process. To help ensure the integrity of the authenticated session, sessions must be cleared when the authenticated endpoint disconnects from the network. Sessions that are not terminated immediately can lead to security violations and security holes. Ideally, session termination occurs as soon as the endpoint physically unplugs, but this is not always possible if the endpoint is connected indirectly (for example, through an IP phone or hub).
Multiple termination mechanisms may be needed to address all use cases. Table 1 summarizes the mechanisms and the appropriate applications.
Table 1. Termination Mechanisms and Use Cases
Use Case
Typical Termination Mechanisms
All endpoints directly connected
• Single endpoint per port
• No IP phones
Link down
Endpoints connected through IP phone
• At most, two endpoints per port (one phone and one data)
Cisco Discovery Protocol enhancement for second-port disconnect (Cisco phones)
Proxy EAPoL Logoff message and inactivity timer (phones other than Cisco phones)
Endpoints connected through a hub
• Physical hub
• Bridged virtual hubs
Inactivity timer
The following sections discuss in more detail the ways that an IEEE 802.1X session can be terminated.
2.2.6.1 Link Down
The most direct way to terminate an IEEE 802.1X session is to unplug the endpoint. When the link state of the port goes down, the switch completely clears the session. If the original endpoint (or a new endpoint) plugs in, the switch will restart authentication from the beginning.
2.2.6.2 EAPoL Logoff and Proxy EAPoL Logoff
The EAPoL Logoff message allows the supplicant to tell the switch to terminate the existing session. On receipt of an EAPoL Logoff message, the switch terminates the existing session. However, there are not many practical applications of this message, and many supplicants do not send EAPoL Logoff messages.
Although the EAPoL Logoff message itself does not have many applications, a proxy EAPoL Logoff message can be very useful. For example, an IP phone can transmit a proxy EAPoL Logoff message when the phone detects an IEEE 802.1X-authenticated endpoint that has unplugged from the phone. The phone substitutes the data endpoint's MAC address, so the proxy EAPoL Logoff message is indistinguishable from an actual EAPoL Logoff message from the data endpoint itself. The switch will immediately clear the session when it receives the Logoff message.
To support this feature, your phone must be capable of sending proxy EAPoL Logoff messages. All Cisco IP Phones and some third-party phones provide this capability. No special function is required from the switch because the EAPoL Logoff message is fully support in the IEEE standard.
Note: Although effective for IEEE 802.1X-authenticated endpoints, proxy EAPoL Logoff will not work for MAB or web authentication, because these authentication methods do not use EAP to authenticate.
2.2.6.3 Cisco Discovery Protocol Enhancement for Second-Port Disconnect
For IP telephony deployments with Cisco IP Phones, the best way to help ensure that all IEEE 802.1X sessions are properly terminated is to use the Cisco Discovery Protocol. Cisco IP Phones can send a Cisco Discovery Protocol message to the switch indicating that the link state for the data endpoint's port is down, allowing the switch to immediately clear the data endpoint's authenticated session.
Best Practice Recommendation: Use Cisco Discovery Protocol Enhancement for Second-Port Disconnect for IP Telephony Deployments
This feature works for all authentication methods, takes effect as soon as the endpoint disconnects, and requires no configuration. If you are using Cisco IP Phones and Cisco Catalyst® Family switches with the appropriate code release, this is the simplest and most effective solution. No other method works as well to terminate authenticated sessions of IP phones.
2.2.6.4 Inactivity Timer
When the inactivity timer is enabled, the switch monitors the activity from authenticated endpoints. When the inactivity timer expires, the switch removes the authenticated session.
The inactivity timer for IEEE 802.1X can be statically configured on the switch port, or it can be dynamically assigned using the RADIUS attribute Idle-Timeout (28). Cisco recommends setting the timer using the RADIUS attribute because this approach gives you control over what endpoints are subject to this timer and the length of the timer setting for each class of endpoints. For example, if your phones are capable of using proxy EAPoL Logoff, then you may not need to assign an inactivity timer for IEEE 802.1X-authenticated sessions. Likewise, endpoints that are known to be quiet for long periods of time can be assigned a longer inactivity timer setting than chatty endpoints.
The inactivity timer is an indirect mechanism that the switch uses to infer that an endpoint has disconnected. An expired inactivity timer cannot guarantee that an endpoint has disconnected. Therefore, a quiet endpoint that does not send traffic for long periods of time (for example, a network printer that services occasional requests but is otherwise silent) may have its session cleared even though it is still connected. That endpoint will then have to send traffic before it can be authenticated again and have access to the network.
2.2.6.5 RADIUS Change of Authorization
RADIUS change of authorization (CoA) allows a RADIUS server to dynamically instruct the switch to alter an existing session. Cisco Catalyst switches support four actions for CoA: reauthentication, termination, port shutdown, and port bounce. The reauthentication and termination actions will terminate the authenticated session in the same way as the reauthentication and session timeout actions discussed in Section 2.3.4.1. The port down and port bounce actions will clear the session immediately, since these actions result in link-down events.
2.3 Design Considerations
This section discusses a wide variety of design considerations that you should evaluate prior to deploying IEEE 802.1X.
2.3.1 Deployment Scenarios
When you deploy IEEE 802.1X, Cisco recommends a phased deployment model that gradually deploys identity-based access control to the network. The three scenarios for phased deployment are monitor mode, low-impact mode, and high-security mode. Each scenario identifies combinations of authentication and authorization techniques that work well together to achieve a particular set of use cases. By developing your IEEE 802.1X design in the context of a comprehensive deployment scenario, you can use well-understood blueprints to address common design challenges.
For more information about scenario-based deployments, see Section 4.
2.3.2 User and Machine Authentication
IEEE 802.1X can authenticate an endpoint based on user credentials or machine credentials or both. Deciding which type of authentication to support is an important step in the design process.
For endpoints that do not support any form of user login (for example, a printer), the choice is obvious. You must authenticate the printer's machine credentials or the printer will never connect to the network.
For endpoints that do support user login (for example, a corporate laptop computer), the choice is made more difficult by the fact that the endpoint may need network access long before a user logs in. If the endpoint does not have network access, then critical features such as Dynamic Host Configuration Protocol (DHCP), Network File System (NFS), and Microsoft Active Directory group policy objects (GPOs) will not behave correctly. By employing IEEE 802.1X with machine credentials, you can enable endpoints to gain access to the network without a user logged in.
Best Practice Recommendation: Enable Machine Authentication in Managed Desktop Environments
Managed desktop environments (such as Microsoft Active Directory) require that endpoints have access to the network very near initial boot time. By enabling machine authentication, you help ensure that endpoints have timely access in an IEEE 802.1X network.
Many organizations find that their visibility and access control objectives can be met by enabling machine authentication only. By enabling only machine authentication, you help ensure that only corporate assets are allowed onto the network. If your policy does not allow user credentials for IEEE 802.1X authentication, users cannot bring a laptop computer from home and connect it to the network with their user credentials. In organizations in which each employee has the exclusive use of a laptop computer, there is a one-to-one correspondence between the employee and the laptop, so there is typically no need to authenticate both on the network. Higher-layer authentications (such as when a user logs in to the Microsoft Active Directory domain) are still performed, offering additional levels of security for the user.
Enabling user authentication allows you to differentiate access for different users on the same machine. This differentiation may be desirable when there is no one-to-one correspondence between users and endpoints, or when you need the additional visibility of tracking users as they log on to a machine. If used, user authentication should always be enabled in addition to (not instead of) machine authentication.
2.3.3 EAP Methods
Within the framework provided by IEEE 802.1X and EAP, the endpoint and user must authenticate with the authentication server using a secure and reliable EAP method. The EAP method determines the type of credential that is used and how that credential is submitted.
Although there are many EAP methods defined or in draft form, this document focuses on two of the most commonly used EAP methods: EAP-TLS and PEAP-MSCHAPv2. The following section provides a detailed technical overview of these two EAP methods, starting with a description of the basic functions and ending with specific deployment considerations and recommendations for each method.
2.3.3.1 EAP-TLS
Basic Functions (EAP-TLS)
EAP-TLS is an IETF standard defined in RFC 2716. EAP-TLS addresses a number of weaknesses in other EAP protocols by using X.509 certificates for secure authentication. In addressing these weaknesses, however, EAP-TLS increases the complexity of deployment. Unlike PEAP-MSCHAPv2 (which requires only server-side certificates), EAP-TLS requires client-side and server-side certificates for mutual authentication.
Within IEEE 802.1X, the EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and encrypted key determination between a supplicant and an authentication server.
Figure 5 shows a high-level representation of the EAP-TLS process.
Figure 5. High-Level EAP-TLS Functions
After the server and supplicant agree to perform authentication using EAP-TLS, the server submits its certificate to the supplicant (step 1). In step 2, the supplicant validates the server's certificate. After the server's identity has been authenticated, the supplicant submits its certificate to the server (step 3). The server validates the supplicant's certificate, thus completing the process of mutual authentication (step 4).
Deployment Recommendations (EAP-TLS)
Certificate Requirements
One of the biggest challenges when deploying EAP-TLS is meeting the certificate requirements. EAP-TLS provides authentication through the exchange and verification of X.509 certificates. Therefore, installing the correct certificates on IEEE 802.1X supplicants and the authentication server is absolutely essential to a successful deployment.
Every end user and computer (including the authentication server) that participates in EAP-TLS must possess at least two certificates:
• Client certificate signed by the certificate authority (CA)
• Copy of the CA root certificate
The client certificate is like a passport that cannot be forged. A user (or computer) presents a client certificate as proof of identity. The client certificate is signed by the CA that issued it. Anyone in possession of a copy of that CA's root certificate can validate the signature on the client certificate. Thus, the CA is a trusted third party that allows entities to authenticate each other.
In an EAP-TLS exchange, the authentication server must have a copy of the root certificate for the CA that signed the supplicant's certificate. Conversely, the supplicant must have the root certificate for the CA that signed the authentication server's certificate.
Although the required certificates can be manually installed on each endpoint, manual certificate enrollment does not scale well.
Best Practice Recommendation: Automate the Certificate Enrollment Process
By using auto-enrollment capabilities in your PKI, you will greatly simplify the deployment of certificates.
In Microsoft environments, you can use Active Directory-based auto-enrollment mechanisms to simplify the deployment of PKI. The Active Directory default group policy automatically propagates the root CA certificate to the appropriate store of any device or user that joins the domain. Active Directory group policies can also be configured to auto-enroll machine and user client certificates and to renew all certificates in advance of expiration.
Note: User auto-enrollment is supported only on Microsoft Windows 2003 Server Enterprise Edition CAs. Microsoft Windows 2003 Server Standard Edition CAs cannot be used for user auto-enrollment. Machine auto-enrollment is supported on both editions. Because user auto-enrollment greatly simplifies PKI deployment, using a Microsoft Windows 2003 Server Enterprise Edition CA is the recommended best practice when deploying EAP-TLS in a Microsoft environment. For detailed information about configuring user certificate auto-enrollment in Microsoft Windows environments, see also http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx#EFD.
Cisco Unified Communications Manager offers another example of auto-enrollment. The Cisco Unified Communications Manager's CA proxy function (CAPF) is capable of auto-enrolling certificates for Cisco IP Phones that need to use IEEE 802.1X.
Initial Deployment
Machines or users attempting to connect to an IEEE 802.1X-protected network for the first time must have a valid certificate to gain full access to the network. Therefore, it is best to deploy certificates to all endpoints before enabling IEEE 802.1X in the network. After IEEE 802.1X is enabled and EAP-TLS is deployed, additional planning will be required for certificate enrollment, expiration and revocation.
After IEEE 802.1X has been enabled, new endpoints can acquire certificates in several ways. Organizations that prebuild images should build certificates into the image before deploying the endpoint. This approach greatly simplifies certificate deployment and is recommended for organizations that deploy endpoints in this way. Otherwise, you may want to offer sufficient network access to allow these endpoints to acquire a certificate, using a fallback authentication method such as MAB or web authentication, a fallback authorization approach such as a guest VLAN, or a deployment scenario such as low-impact mode.1
Certificate Expiration and Revocation
Certificates expire according to the date set by the CA that issued them. The duration of a certificate's lifetime should be configured in accordance with an organization's security policy. To prevent endpoints from losing network access, these certificates must be renewed prior to expiration. A best practice is to automate certificate renewal and to design your PKI to enable certificate renewal well in advance of the expiration date.
Certificates can be revoked for a number of reasons. For example, the certificate may have been compromised, or the person to whom the certificate was issued may have left the organization. These certificates will need to be revoked to prevent them from being used to gain unauthorized access to an organization's assets. Certificate revocation is achieved through a certificate revocation list (CRL). A CA periodically generates a CRL, which contains a list of all certificates that should no longer be trusted.
When certificates are revoked or expire without renewal, EAP-TLS will fail, and network access will be denied. Since network access is required to request a new certificate, these endpoints and users will be permanently denied access by default.
In the absence of a manual process, you may want to offer sufficient network access to allow failed endpoints to acquire a valid certificate. The available mechanisms in this use case include a fallback authentication method such as MAB or web authentication, a fallback authorization approach such as an Auth-Fail VLAN, or a deployment scenario such as low-impact mode, which can allow a certain amount of access regardless of the authentication state of the port.
2.3.3.2 PEAP-MSCHAPv2
Basic Functions (PEAP-MSCHAPv2)
PEAP was developed by Cisco, Microsoft, and RSA. PEAP is an EAP type that addresses security challenges by first creating a secure channel that is both encrypted and integrity protected with TLS. This tunnel is created using a valid server certificate that the authentication server sends to the supplicant at the beginning of the PEAP negotiation. Within this secure channel, a new EAP negotiation takes place to authenticate the client. This second EAP negotiation can be essentially any EAP type.
Because the TLS channel protects EAP negotiation and authentication for the network access attempt, password-based authentication protocols that are normally susceptible to an offline dictionary attack can be safely used for authentication. With the EAP messages wrapped in TLS, any EAP method running within PEAP has built-in support for key exchange, session resumption, fragmentation, and reassembly. Furthermore, since PEAP requires only a certificate on the authentication server, LAN clients can be securely authenticated without requiring every client to have its own certificate. This feature greatly reduces the burden of deploying and maintaining PKI.
MSCHAPv2 is commonly used as the second EAP type within a PEAP tunnel. MS-CHAPv2 is a password-based, challenge-response, mutual-authentication protocol that uses Message-Digest Algorithm 4 (MD4) and Data Encryption Standard (DES) to encrypt responses. The authenticator challenges a supplicant, and the supplicant can challenge the authentication server. If either challenge is not correctly answered, the connection can be rejected. Although MSCHAPv2 provides better protection than previous challenge-response authentication protocols, it is still susceptible to an offline dictionary attack. A malicious user can capture a successful MSCHAPv2 exchange and guess passwords until the correct one is determined. When MSCHAPv2 is used in combination with PEAP, however, the MSCHAPv2 exchange is protected with the strong security of the TLS channel. PEAP-MSCHAPv2 is used primarily in Microsoft Active Directory environments.
Figure 6 shows a high-level representation of the PEAP-MSCHAPv2 process.
Figure 6. High-Level PEAP-MSCHAPv2 Functions
After the server and supplicant agree to perform authentication using PEAP-MSCHAPv2, the server submits its certificate to the supplicant (step 1). The supplicant validates the server's certificate (step 2). After the server's identity has been authenticated, the supplicant builds a TLS-encrypted tunnel. Within that tunnel, the supplicant submits a username and password using MSCHAPv2 (step3). The server validates the supplicant's password, thus completing the process of mutual authentication (step 4).
Deployment Recommendations (PEAP-MSCHAPv2)
Credential Requirements
Like EAP-TLS, PEAP-MSCHAPv2 requires that the authentication server present a certificate to the supplicant. To validate the server certificate, the supplicant must have the root certificate for the CA that signed the authentication server's certificate. Unlike EAP-TLS, PEAP-MSCHAPv2 does not require that the supplicant have a certificate, because the supplicant establishes its identity inside the tunnel through MSCHAPv2. MSCHAPv2 authentication relies on a password, not a certificate.
Every endpoint and user that participates in PEAP-MSCHAPv2 must possess the following credentials:
• Root CA certificate for the CA that signed the authentication server's certificate
• MSCHAPv2 username and password
The authentication server must possess the following credentials:
• Server certificate signed by the root CA
• MSCHAPv2 password for every user and computer
For more information about certificate deployment and management, see Section 2.3.2.1.
Passwords
With PEAP-MSCHAPv2, clients use passwords to successfully complete the inner MSCHAPv2 challenge. If possible, reuse an existing password store. For example, in Microsoft Active Directory environments, the Active Directory passwords can be used for the MSCHAPv2 exchange. This approach is often referred to as single sign-on because the end user enters his or her password only once (in the Microsoft login window). The IEEE 802.1X supplicant reuses this password for MSCHAPv2 without having to query the user again. Reusing existing credentials also reduces administrative overhead because only one password repository needs to be managed.
Best Practice Recommendation: Enable Single Sign-On If Your Security Policy Allows It
Enabling the supplicant for single sign-on reduces administrative overhead and eliminates the need to modify the behavior of end users.
For machine authentication in Microsoft environments, machines need Active Directory passwords for the same reasons that users need Active Directory passwords. Active Directory automatically provisions machines with machine passwords suitable for MSCHAPv2 when the machine joins the domain. In most cases, no further action is required to provision the machine with suitable credentials.
Password aging is often enabled in Microsoft Active Directory as part of a broader Microsoft Windows security policy. To prevent network outages when Active Directory passwords expire, users can change passwords during PEAP authentication. When attempting PEAP-MSCHAPv2 authentication using an expired Active Directory password, users receive a dialog box prompting them to change their passwords during the first authentication after their passwords have expired. After the password is changed, the PEAP authentication session continues as usual.
Note: Expired machine passwords cannot be changed during the PEAP authentication process. Although users can update Microsoft Active Directory passwords during a PEAP-MSCHAPv2 authentication, machines cannot when running Microsoft Windows XP with SP2. Therefore, machines with expired passwords will fail authentication, and some other process must be employed to allow machines to update expired passwords. For example, if you are using PEAP with user and computer authentication, then the machine password will be reset when the user logs in. Other options are to configure longer password expiration times for machines or to consider use of an EAP method (such as EAP-TLS) that does not use passwords. For more information, see http://technet.microsoft.com/en-gb/library/cc512611.aspx.
2.3.3.3 Choosing an EAP Method
Different EAP methods offer differing levels of security and complexity. When deploying IEEE 802.1X, it is essential that you choose an EAP method that meets your organization's security policy and that the available infrastructure supports. Important factors to consider when selecting any EAP method include:
• Credential type and EAP method: The EAP type you use is in part determined by the type of credential you want to use. EAP-TLS requires the client to have a digital certificate. PEAP-MSCHAPv2 uses passwords.
Best Practice Recommendation: Reuse Existing Credentials
By reusing an existing credential system (for example, a wireless LAN [WLAN] or Microsoft Active Directory credential), you eliminate the need to create and maintain a new set of credentials for IEEE 802.1X.
• Security policy and EAP method: Some security policies require two-factor authentication, in which case a password-based EAP method like PEAP-MSCHAPv2 would not be appropriate.
• Mutual authentication and EAP method: To prevent supplicants from authenticating to untrusted authentication servers, choose an EAP method that offers mutual authentication. Mutual authentication forces the supplicant to validate the identity of the authentication server before submitting its credentials, reducing the likelihood of a man-in-the-middle attack.
Best Practice Recommendation: Choose an EAP Method with Mutual Authentication
PEAP-MSCHAPv2 and EAP-TLS offer mutual authentication. EAP-MD5 does not.
• PKI and EAP method: Each EAP method makes different demands on an organization's PKI. PKI refers to the infrastructure that creates, maintains, and revokes X.509 certificates for endpoints and users in the network. An organization's ability to support PKI can influence the choice of an EAP method. Of the two EAP methods discussed in this document, EAP-TLS requires the more complex PKI (client and server certificates); PEAP-MSCHAPv2 requires a less complex PKI (server certificates only).
Note: In some cases, the choice of a CA also affects the choice of a supplicant. For example, the native Microsoft Windows XP supplicant requires that the certificate presented by the RADIUS server include an enhanced key usage (EKU) field that is set to server authentication. Likewise, the Microsoft supplicant requires that client certificates have an EKU field set to client authentication. CAs that do not support the EKU field cannot be used with the Microsoft supplicant.
• Supplicant and EAP method: Not all supplicants support all EAP methods. When choosing a supplicant, be sure to verify that it supports the EAP method that you want to deploy.
• Authentication servers and EAP method: Not all authentication servers support all EAP methods. When choosing an authentication server, be sure to verify that it supports the EAP method that you want to deploy.
• Back-end data storage and EAP method: Not all back-end data stores support all EAP methods. When choosing a back-end data store, be sure to verify that it supports the EAP method that you want to deploy. Conversely, if you already have a back-end data store, be sure to choose an EAP method that can use it. For example, an EAP type (such as PEAP-MSCHAPv2) that uses MSCHAPv2 as the inner method can use Microsoft Active Directory as a back-end database, but not a generic LDAP server.
2.3.4 Supplicant Considerations
When choosing a supplicant, your goal should be to choose a supplicant (or supplicants) that provides the needed capabilities, reduces the administrative overhead, and can be easily deployed and maintained.
In Microsoft environments, the native supplicant is an attractive choice because it is preinstalled in the operating system. It supports both EAP-TLS and PEAP-MSCHAPv2. Starting in Microsoft Windows XP with SP3, two separate services are provided for wired and wireless supplicants. However, there are some limitations that you should evaluate:
• Functional limitations in Microsoft Windows XP with SP2: Prior to SP3, the wired supplicant had many functional limitations and could not be fully managed by GPOs.
• Upgrading from SP2: Because the implementation of the native supplicant changed significantly between Microsoft Windows XP SP2 and SP3 and Microsoft Vista, upgrading the OS can have unintended consequences for IEEE 802.1X. Whereas Microsoft Windows XP SP2 used the same service for wired and wireless, Microsoft Windows XP SP3 and Microsoft Vista have separate services, and the wired service is disabled by default. Because of this, IEEE 802.1X-authenticated endpoints that upgrade from SP2 to SP3 or Microsoft Vista can be disconnected from the wired network after the upgrade.2
• Single profile: The native supplicant allows only a single profile for user and machine authentication. For example, if you use EAP-TLS with soft certificates for machine authentication, you must also use EAP-TLS with soft certificates for user authentication.
Cisco SSC is another supplicant that works for Microsoft Windows XP and Vista endpoints. Cisco SSC is a full-featured supplicant with support for EAP-TLS, PEAP-MSCHAPv2, and many other EAP types. Cisco SSC supports multiple profiles for wired and wireless authentication, with independent parameters for machine and user authentication. It comes with a management utility that simplifies configuration and deployment. It also offers improved troubleshooting capabilities.
Mac OS X has a native supplicant that supports a broad range of EAP types for system authentication and user authentication.
Several open source supplicants are available for use in Microsoft Windows and Linux environments, including XSupplicant, Wi-Fi Protected Access (WPA), and SecureW2.
Although hardware-based supplicants are relatively new to wired deployments, a hardware-based supplicant, such as Intel vPro, may be required for certain use cases. Hardware-based supplicants can implement IEEE 802.1X even if the operating system is unable to perform authentication. This approach would be useful for endpoints in hibernate or standby mode that need to stay connected to the network (for example, to receive a wake-on-LAN packet) and endpoints that use the preboot execution environment (PXE) method to netboot an operating system.
2.3.5 Authentication Server Considerations
Many RADIUS servers can function as IEEE 802.1X authentication servers. First and foremost, you should choose a RADIUS server that can authenticate all your endpoints (IEEE 802.1X, MAB, and web authentication) against all your identity stores (Microsoft Active Directory, LDAP, etc.). Next, you should make sure that your RADIUS server supports the network access policies that you want to deploy. Last, your RADIUS server should be capable of monitoring, reporting, and troubleshooting.
Cisco Secure ACS 5.1 is a next-generation policy platform that provides RADIUS (and TACACS+) services. It provides a powerful, attribute-driven, rules-based policy model that addresses complex policy needs in a flexible manner. It has integrated advanced monitoring, reporting, and troubleshooting capabilities for excellent control and visibility, improved integration with external identity and policy databases (including databases accessible with Microsoft Active Directory and LDAP), and a distributed deployment model that enables large-scale deployments and provides a highly available solution.
In Microsoft environments, the Network Policy Server (NPS) on Microsoft Windows Server 2008 and the Internet Authentication Service (IAS) on Microsoft Windows Server 2003 can perform authentication for endpoints and users that are part of the Active Directory domain. However, NPS and IAS do not support complex policies models, nor can they query back-end databases for credential verification. Reporting and troubleshooting capabilities are limited.
Several open source RADIUS servers are available for use for IEEE 802.1X, including FreeRADIUS and OpenRADIUS.
2.3.6 Reauthentication
A previously authenticated endpoint that remains connected to the network usually does not need to be reauthenticated. After successful IEEE 802.1X authentication, the port remains open until the session is terminated, most typically by a physical link-down event. Since physical connectivity is continuously maintained, there is no question that the authenticated endpoint remains connected to the port. Under these circumstances, interrogating the endpoint's credentials again would serve no purpose.
In some situations, however, reauthentication can be used as, essentially, a IEEE 802.1X keepalive mechanism. For example, if an endpoint is connected to the port through an IP phone that is not capable of proxy EAPoL Logoff or Cisco Discovery Protocol enhancement for second-port disconnect, the switch will not know when to terminate the session. If the session is reauthenticated or reinitialized, the switch can confirm that the authenticated endpoint is still connected. Because authentication and authorization are tightly coupled in IEEE 802.1X, reauthentication can also be used as, essentially, a reauthorization technique. In the absence of explicit mechanisms to dynamically push policy updates to switches, reauthentication provides a mechanism by which the switch can pull the latest authorization policy (such as VLAN or ACL assignment) for authenticated endpoints.
The reauthentication timer for IEEE 802.1X can be statically configured on the switch port, or it can be dynamically assigned by sending the RADIUS attribute Session-Timeout (27) and RADIUS attribute Termination-Action (29) with a value of RADIUS-Request in the Access-Accept message from the RADIUS server. If you choose to enable reauthentication, Cisco recommends setting the timer through the RADIUS attribute because this approach gives you control over what endpoints are subject to this timer and the length of the timer for each class of endpoints. Network connectivity is maintained during the reauthentication process. If reauthentication is successful, the current session remains active. If reauthentication is not successful, the session is terminated.
The session timer can be also used to terminate an IEEE 802.1X session, regardless of whether the authenticated endpoint remains connected. The session timer uses the same RADIUS attribute Session-Timeout (27) as the server-based reauthentication timer already described, with the RADIUS attribute Termination-Action (29) set to Default. The switch will terminate the session after the number of seconds specified by the Session-Timeout attribute and immediately restart authentication by sending an EAP Identity-Request message exactly as if a new endpoint had plugged into the port. If the previous endpoint remains connected, network connectivity will be interrupted until the new authentication session is complete.
Best Practice Recommendation: Use Server-Based Reauthentication Timeouts, If at All
Depending on the length of the timers, periodic reauthentication may increase the authentication traffic load on the network infrastructure. More important, better ways are usually available to help ensure the proper termination of authenticated sessions (for example, link state, proxy EAPoL Logoff, Cisco Discovery Protocol enhancement for second-port disconnect, and inactivity timers). Therefore, you should configure the policy on your authentication, authorization, and accounting (AAA) server to dynamically assign reauthentication timers only to endpoints whose connectivity cannot be validated any other way.
Best Practice Recommendation: Do Not Assign Session or Reauthentication Timers to MAB Endpoints
Reauthentication and session timers also affect MAB sessions. Upon MAB reauthentication (RADIUS attribute Termination-Action (29) = "RADIUS-Request"), the switch does not relearn the MAC address of the connected endpoint; it simply sends the previously learned MAC address to the RADIUS server. Essentially, a null operation is performed. Upon MAB session timeout (RADIUS attribute Termination-Action (29) = "Default"), the switch will relearn the MAC address, but network connectivity will be disrupted until IEEE 802.1X times out and MAB succeeds. This process can result in significant network outage for MAB endpoints.
2.3.7 Open Access
By default, IEEE 802.1X drops all traffic prior to a successful IEEE 802.1X (or MAB) authentication or web authentication initialization. This approach is sometimes referred to as closed mode. Cisco switches can also be configured for open access, which allows all traffic while still performing IEEE 802.1X and MAB authentication.
Open access has many applications: for example, it can increase network visibility as part of a monitor-mode deployment scenario. It also can be combined with other features to provide incremental access control as part of a low-impact-mode deployment scenario. For more information about these deployment scenarios, see Section 4.
2.3.8 Multiple Endpoints per Port
By default, an IEEE 802.1X-enabled port allows only a single endpoint per port. Any additional MAC addresses seen on the port will cause a security violation.
Best Practice Recommendation: Configure the "Restrict" Security Violation Action
Cisco Catalyst switches can be configured to error-disable the port (shut down the port), drop all traffic from the new MAC address (restrict), or terminate the existing session and attempt to authenticate the new MAC address (replace). Restricting traffic from additional MAC addresses on the port usually achieves the desired behavior.
Frequently, the limitation of a single endpoint per port will not meet all the requirements of real-world networks. Cisco Catalyst switches allow you to address multiple use cases by modifying the default behavior. The host mode on a port determines the number and type of endpoints allowed on a port. The various host modes and their applications are discussed here.
Best Practice Recommendation: Use the Most Restrictive Host Mode That Addresses Your Use Cases
Limiting the number of MAC addresses allowed on the port helps ensure the validity of the authenticated session and discourages casual port piggybacking.
• Single-host mode: In single-host mode, only a single MAC or IP address can be authenticated (by any method) on a port. If a different MAC address is detected on the port after an endpoint has authenticated with IEEE 802.1X, MAB, or web authentication, a security violation will be triggered on the port. This is the default behavior.
• Multidomain authentication (MDA) host mode: MDA mode was specifically designed to address the requirements of IP telephony in an IEEE 802.1X environment. When MDA is configured, two endpoints are allowed on the port: one in the voice VLAN and one in the data VLAN. Additional MAC addresses will trigger a security violation.
• Multiple-authentication (multi-auth) host mode: If the port is configured for multi-auth mode, multiple endpoints can be authenticated in the data VLAN. Each new MAC address that appears on the port will be separately authenticated. Multi-auth mode can be used for bridged virtual environments and to support hubs.
• Multiple-host (multi-host) mode: Unlike multi-auth host mode, which authenticates every MAC address, multi-host mode authenticates the first MAC address and then allows an unlimited number of other MAC addresses. Because of the security implications of multi-host mode, multi-auth mode is typically a better choice.
2.3.9 Wake on LAN
Wake on LAN (WoL) is an industry-standard power management feature that allows you to remotely wake up a hibernating endpoint by sending a "magic packet" over the network. Most WoL endpoints flap the link when they go into hibernation or standby mode, thus clearing any existing IEEE 802.1X-authenticated session. By default, traffic through the unauthorized port will be blocked in both directions, and the magic packet will never reach the sleeping endpoint.
To support WoL in an IEEE 802.1X environment, you can configure a Cisco Catalyst switch to modify the control direction of the port, allowing traffic to the endpoint while still controlling traffic from the endpoint. This approach allows the hibernating endpoint to receive the WoL packet while still preventing the unauthorized endpoint from sending any traffic to the network. After it awakens, the endpoint can authenticate and gain full access to the network.
An alternative to modification of the control direction is to use a hardware supplicant that can perform IEEE 802.1X authentication even when the endpoint itself is sleeping.
When a port is configured for open access mode, magic packets are not blocked, even on unauthorized ports, so no special configuration for WoL endpoints is necessary.
2.3.10 Non-IEEE 802.1X-Capable Endpoints
If an endpoint without an IEEE 802.1X supplicant attempts to connect to a port that is enabled for IEEE 802.1X, it will be subjected to the default security policy: no access until authentication.
Although endpoints increasingly support IEEE 802.1X, there will always be endpoints that require network connectivity but do not nor cannot support IEEE 802.1X. Examples of such endpoints include network printers, badge readers, older servers, and PXE boot devices. Some provision must be made for these endpoints.
Cisco provides features to accommodate non-IEEE 802.1X endpoints, including MAB, web authentication, and the guest VLAN. These features provide fallback mechanisms when there is no IEEE 802.1X supplicant. After IEEE 802.1X times out on a port, the port can move to an authorized state if MAB or web authentication succeeds, or if the guest VLAN is configured. Judicious application of these features will be required for a successful IEEE 802.1X deployment. Figure 7 shows the interactions of these fallback mechanisms.
Figure 7. Fallback Mechanisms for Non-IEEE 802.1X Endpoints
MAB, web authentication, and the guest VLAN are fallback mechanisms: that is, they are deployed only after IEEE 802.1X authentication has timed out. If the endpoint's PXE process times out, or if DHCP gets deep into the exponential back-off process before the timeout occurs, the endpoint may not access the network even after the port has been opened. To the end user, it will appear as if network access has been denied. This problem can be alleviated by decreasing the IEEE 802.1X timeout value. See Section 2.3.11.1 for more information about relevant timers.
In addition to or instead of modifying the timer, you can use a low-impact deployment scenario that allows time-critical traffic such as DHCP traffic prior to authentication. See Section 4 for more information about deployment scenarios.
If your network has many non-IEEE 802.1X-capable endpoints that need instantaneous access to the network, a third option is to use the flexible authentication feature set that allows you to configure the order and priority of authentication methods. Instead of waiting for IEEE 802.1X to time out before performing MAB, you can configure the switch to perform MAB first and fallback to IEEE 802.1X only if MAB fails. See Section 4 for more information about flexible authentication.
2.3.11 IEEE 802.1X Endpoints with Invalid Credentials
IEEE 802.1X protects the network by preventing users and endpoints without valid credentials from gaining access to the access port. However, there may be situations in which legitimate users do not have valid credentials. For example, a partner may attempt to connect to the network for guest access. The partner's laptop computer may be configured for IEEE 802.1X, but the partner's credentials may be valid only on the partner's home network. IEEE 802.1X authentication therefore fails, preventing the partner from gaining guest access.
To provide for situations such as these, Cisco offers two options. The first is the Auth-Fail VLAN feature. When IEEE 802.1X authentication fails (as opposed to timing out because there is no supplicant on the endpoint), the port is moved to a configurable VLAN (the Auth-Fail VLAN) where restricted access can be enforced. Using the Auth-Fail VLAN, you can tailor network access for endpoints without valid credentials. For example, the Auth-Fail VLAN can be configured to permit access only to the Internet or to a CA for certificate renewal.
The second option is to fail over to a secondary form of authentication. Cisco Catalyst switches can be configured to attempt MAB or web authentication after IEEE 802.1X fails. Access to the network is granted based on the success or failure of the secondary authentication method.
All these failover authentication and authorization mechanisms assume that the supplicant will fail to open.
Figure 8 shows the interactions of these failover mechanisms.
Figure 8. Failover Mechanisms for Failed IEEE 802.1X Endpoints
Note: The Auth-Fail VLAN and failover authentication methods are optional. They should always be deployed in accordance with an organization's security policy.
2.3.12 Inaccessible Authentication Server
When the authentication server is unavailable, IEEE 802.1X will fail, and by default, all endpoints will be denied access. In a highly available enterprise campus environment, it is reasonable to expect that a switch will always be able to communicate with the authentication server, so the default behavior may be perfectly acceptable. However, there may be some use cases (for example, a branch office with occasional WAN outages) in which the switch cannot reach the authentication server, but endpoints should be allowed access to the network.
If the switch already knows that the authentication server has failed (either through a periodic probe or as the result of a previous authentication attempt), a port can be deployed in a configurable VLAN (sometimes called the critical VLAN) as soon as the link comes up. Since the switch has multiple mechanisms for learning that the AAA server has failed, this outcome is the most likely. If the switch determines that the authentication server has failed during IEEE 802.1X or MAB authentication (for example, if this is the first endpoint to connect to the switch after connectivity to the authentication server has been lost), then the port will be moved to the critical VLAN after the authentication times out. Previously authenticated endpoints will not be affected in any way; if a reauthentication timer expires when the authentication server is down, the reauthentication will be deferred until the switch determines that the authentication server has returned.
The critical VLAN can be any VLAN except the voice VLAN. If no VLAN is specified, the port will fail open to the switch data VLAN.
2.3.13 Timers and Variables
IEEE 802.1X relies on several timers and variables to control the timing of the authenticator function on the switch. This section describes the timers on the switch that are relevant to the IEEE 802.1X authentication process. Unless otherwise noted, these timers should be left at their default values.
2.3.13.1 The dot1x timeout tx-period and dot1x max-reauth-req Variables
This section discusses the timers that control the timeout and retry behavior of an IEEE 802.1X-enabled port in the absence of a supplicant.
At link up, the switch will send an EAP Request-Identity frame. It will wait for a period of time defined by the dot1x timeout tx-period variable and then send another Request-Identity frame. The number of times it will resend the Request-Identity frames is defined by the dot1x max-reauth-req variable.3
Figure 9 shows the functions of the tx-period timer and the max-reauth-req variable.
Figure 9. The tx-period and max-reauth-req Variables
The combination of tx-period and max-reauth-req is especially important to non-IEEE 802.1X-capable endpoints. Endpoints without a supplicant must wait until IEEE 802.1X times out before getting network access through a fallback mechanism. The total time it takes for IEEE 802.1X to time out is determined by the following formula:
Timeout = (max-reauth-req +1) * tx-period
Cisco Catalyst switches have default values of tx-period = 30 seconds and max-reauth-req = 2. Applying the preceding formula, it takes 90 seconds by default for an endpoint without a supplicant to get access through MAB, web authentication, or the guest VLAN. By modifying these two variables, you can decrease the total timeout to 2 seconds.
Because of the impact on endpoints without supplicants, most customers change the default values of tx-period and max-reauth-req to allow more rapid access to the network. When modifying these values, consider the following:
• A timer that is too short may subject IEEE 802.1X-capable endpoints to a fallback authentication or authorization technique. Although supplicants can send an EAPoL Start frame to restart IEEE 802.1X authentication after fallback has occurred, you may still be generating unnecessary control-plane traffic.
• If the endpoint has been authorized by a fallback method, then that endpoint may temporarily be adjacent to guest devices that have been similarly authorized. If your goal is to help ensure that your IEEE 802.1X-capable assets are always and exclusively on a trusted network, then you should make sure that the timer value is set long enough to give IEEE 802.1X-capable endpoints time to authenticate.
• A timer that is too long, however, can subject endpoints without supplicants to unnecessarily long delays in getting network access.
Best Practice Recommendation: Test tx-period and max-reauth-req in Your Network
Since the optimal value for the timeout will depend on the specifics of your network, Cisco recommends that you use the IEEE 802.1X deployment planning phase to test the value that you select. Pay particular attention to DHCP clients, PXE clients, and the specifics of your managed desktop infrastructure.
2.3.13.2 The authentication timer restart Timer
This section discusses the timer that controls when IEEE 802.1X restarts in the absence of an IEEE authentication attempt.
If IEEE 802.1X times out and a fallback mechanism has not been configured, or if the configured fallback mechanism was not successful (for example, MAB failed), the switch will wait a period of time defined by authentication timer restart, after which the authentication process will start over from the beginning (Figure 10).
Figure 10. The authentication timer restart Timer
The default authentication timer restart timer is 60 seconds. This timer usually does not need to be modified.
2.3.13.3 The dot1x timeout quiet-period Variable
This section discusses the timer that controls when IEEE 802.1X restarts after a failed IEEE authentication attempt.
If IEEE 802.1X fails and no failover mechanism is enabled (MAB, web authentication, or Auth-Fail VLAN), the switch will wait for a period of time known as the quiet period. Figure 11 shows the operation of the dot1x timeout quiet-period variable.
Figure 11. The dot1x timeout quiet-period Variable
Most customers typically do have a failover mechanism enabled, so the dot1x timeout quiet-period variable is rarely invoked.
The default quiet period is 60 seconds. The quiet period usually does not need to be modified.
2.3.13.4 The dot1x timeout supp-timeout and dot1x max-req Variables
This section discusses the timers that control the timeout and the retry behavior of an IEEE 802.1X-enabled port when a supplicant stops responding in the middle of authentication.
The supp-timeout and max-req variables are similar to tx-period and max-reauth-req except that they apply only after the supplicant has responded to the initial Request-Identity message. They are not commonly invoked, since they take effect only during rare events such as when a supplicant stops functioning during the authentication process or transmission fails on the wire (Figure 12).
Figure 12. The dot1x timeout supp-timeout and dot1x timeout max-req Variables
The default dot1x timeout supp-timeout value is 30 seconds. The default dot1x max-req value is 2. In practice, these values almost never need to be modified.
2.3.13.5 The dot1x timeout server-timeout Variable
The port-based configuration of dot1x timeout server-timeout can influence the RADIUS retransmission behavior of the switch when the authentication server stops responding. In Cisco Catalyst switches, however, retransmission to the server is best handled through the global RADIUS configuration. Therefore, the port-based dot1x timeout server-timeout configuration is redundant. The default value is 0 (which disables this timer in favor of the global RADIUS configuration) and should not be changed.
Best Practice Recommendation: Do Not Modify dot1x timeout server-timeout
Cisco does not recommend modifying the default value of dot1x timeout server-timeout. Instead, you should rely on the global RADIUS server timeout configuration to control retransmission to the authentication server.
2.3.14 RADIUS Accounting
RADIUS accounting is fully compatible with IEEE 802.1X and should be enabled as a best practice. RADIUS accounting provides detailed information about the authenticated session and enables you to correlate a username with MAC address, IP address, switch, port, and use statistics.
Table 2 shows relevant fields in a typical Accounting-Start message sent from the switch to the authentication server.
Table 2. Relevant Fields in a Typical Accounting-Start Message
RADIUS Attribute
Example Value
Significance
Acct-Session-Id (44)
00000122
Unique accounting identifier that makes start, interim-update, and stop records in a log file easy to match
Vendor-Specific (26) v=Cisco (9)
Cisco-AVPair: audit-session-id
0A640A0400000057193E518F
Unique session identifier derived by the switch from the switch's IP address, a session count, and the session start timestamp
User-Name (1)
SEP001E4AA900A8
Name of authenticated endpoint
Acct-Status-Type (40)
Start
Type of accounting message
NAS-Port-Type (61)
Ethernet
Type of port to which the authenticated endpoint is connected
NAS-Port (5)
50248
Numerical representation of the port to which the authenticated endpoint is connected
NAS-Port-Id (87)
FastEthernet2/48
Port to which the authenticated endpoint is connected, in human-readable format
Called-Station-Id (30)
00-1F-6C-3E-56-8F
MAC address of switch
Calling-Station-Id (31)
00-1E-4A-A9-00-A8
MAC address of authenticated endpoint
Service-Type (6)
Framed-User
Authentication type
• Framed-User (2) = IEEE 802.1X
• Call-Check (10) = MAB
• Outbound (5) = Wired web authentication
NAS-IP-Address (4)
10.100.10.4
IP address of the switch
If some information is not available at the time of the Accounting-Start message, or if information changes at some point, the switch will send an Interim-Update message with the new information. Table 3 shows relevant fields in an Interim-Update message after the authenticated endpoint has acquired an IP address (RADIUS attribute 8, Framed-IP-Address).
Table 3. Relevant Fields in an Interim-Update Message
RADIUS Attribute
Example Value
Significance
Acct-Session-Id (44)
00000122
Unique accounting identifier that makes start, interim-update, and stop records in a log file easy to match
Vendor-Specific (26) v=Cisco (9)
Cisco-AVPair: audit-session-id
0A640A0400000057193E518F
• Globally unique session identifier derived by the switch from the switch's IP address, a session count, and the session start timestamp
• Included in all RADIUS messages, making authentication and accounting records easier to match
Framed-IP-Address (8)
10.100.41.200
IP address of authenticated endpoint
User-Name (1)
SEP001E4AA900A8
Name of authenticated endpoint
Acct-Session-Time (46)
27
Duration of current session (in seconds)
Acct-Input-Octets (42)
2614
Input octets for this session
Acct-Output-Octets (43)
2469
Output octets for this session
Acct-Input-Packets (47)
7
Input packets for this session
Acct-Output-Packets (48)
18
Output packets for this session
Acct-Status-Type (40)
Interim-Update
Type of accounting message
NAS-Port-Type (61)
Ethernet
Port type to which authenticated endpoint is connected
NAS-Port (5)
50248
Port to which authenticated endpoint is connected
NAS-Port-Id (87)
FastEthernet2/48
Port to which authenticated endpoint is connected, in human-readable format
Called-Station-Id (30)
00-1F-6C-3E-56-8F
MAC address of switch
Calling-Station-Id (31)
00-1E-4A-A9-00-A8
MAC address of authenticated endpoint
Service-Type (6)
Framed-User
Authentication type
• Framed-User (2) = IEEE 802.1X
• Call-Check (10) = MAB
• Outbound (5) = Wired web authentication
NAS-IP-Address (4)
10.100.10.4
IP address of the switch
When a session is terminated, the switch sends an Accounting-Stop record. Table 4 shows relevant fields in an Accounting-Stop message when the authenticated endpoint disconnects from the port. Note that complete usage information (Acct-Session-Time, Acct-Output-Octets, Acct-Input-Octets etc.) is available.
Table 4. Relevant Fields in an Accounting-Stop Message
RADIUS Attribute
Example Value
Significance
Acct-Session-Id (44)
00000122
Unique accounting identifier that makes start, interim-update, and stop records in a log file easy to match
Vendor-Specific (26) v=Cisco (9)
Cisco-AVPair: audit-session-id
0A640A0400000057193E518F
• Globally unique session identifier derived by the switch from the switch's IP address, a session count, and the session start timestamp
• Included in all RADIUS messages, making authentication and accounting records easier to match
Framed-IP-Address (8)
10.100.41.200
IP address of authenticated endpoint
User-Name (1)
SEP001E4AA900A8
Name of authenticated endpoint
Acct-Terminate-Cause (49)
Lost-Carrier
Indicates why the session was terminated
Acct-Session-Time (46)
493992
Duration of current session (in seconds)
Acct-Input-Octets (42)
26644714
Input octets for this session
Acct-Output-Octets (43)
52824579
Output octets for this session
Acct-Input-Packets (47)
245767
Input packets for this session
Acct-Output-Packets (48)
590153
Output packets for this session
Acct-Status-Type (40)
Stop
Type of accounting message
NAS-Port-Type (61)
Ethernet
Port type to which authenticated endpoint is connected
NAS-Port (5)
50248
Port to which authenticated endpoint is connected
NAS-Port-Id (87)
FastEthernet2/48
Port to which authenticated endpoint is connected, in human-readable format
2.3.16 Cisco Catalyst Integrated Security Features
2.3.16.1 Port Security
In general, Cisco does not recommend enabling port security when IEEE 802.1X is also enabled. Since IEEE 802.1X enforces a single MAC address per port (or per VLAN when MDA is configured for IP telephony), port security is mainly redundant and may in some cases interfere with the expected operation of IEEE 802.1X.
2.3.16.2 DHCP Snooping
DHCP snooping is fully compatible with IEEE 802.1X and should be enabled as a best practice.
2.3.16.3 Dynamic ARP Inspection
Dynamic ARP inspection is fully compatible with IEEE 802.1X and should be enabled as a best practice.
2.3.16.4 IP Source Guard
IP source guard is compatible with IEEE 802.1X and should be enabled as a best practice.
2.4 Deployment Summary for IEEE 802.1X
Table 5 summarizes the major design decisions that need to be addressed prior to deploying IEEE 802.1X authentication.
Table 5. IEEE 802.1X Deployment Reference
Design Consideration
Relevant Section
Evaluate your IEEE 802.1X design as part of a larger deployment scenario.
2.3.1
Select EAP the methods that meet the requirements of your security policy and the capabilities of your infrastructure.
2.3.3.3
Reuse existing credentials.
2.3.3.3
Plan for credential distribution (pre- and post-IEEE 802.1X deployment), maintenance, expiration, and renewal.
2.3.3
Select a supplicant that provides the required capabilities.
2.3.4
Configure your supplicant to send EAPoL Start messages.
2.2.2
Select an authentication server that supports your EAP method and back-end databases while providing sufficient monitoring and troubleshooting capabilities.
2.3.5
Enable machine authentication.
2.3.2
Enable user authentication if required.
2.3.2
Disable reauthentication.
2.3.6
Decide how many endpoints per port you must support and configure the most restrictive host mode.
2.3.8
If your network includes WoL endpoints, use an open access-based deployment scenario, change the control direction to allow magic packets, or deploy a hardware-based supplicant to those endpoints.
2.3.9
Identify the session termination method for indirectly connected endpoints:
• Cisco Discovery Protocol enhancement for second-port disconnect (Cisco IP Phones)
• Proxy EAPoL Logoff (third-party IP phones)
• Inactivity timer with IP device tracking (physical or virtual hub)
2.2.6
Identify endpoints that may fail IEEE 802.1X authentication and, if your security policy permits, plan for supplementary access (MAB, web authentication, or Auth-Fail VLAN).
2.3.11
Enable RADIUS accounting.
2.3.14
Disable port security.
2.3.16.1
Identify endpoints without supplicants and provide a mechanism to grant them network access (MAB, web authentication, or guest VLAN).
2.3.10
Modify the tx-period and max-reauth-req values to allow endpoints without supplicants to get faster access to the network using a supplementary method.
2.3.13.1
3. Conclusion
IEEE 802.1X offers exceptional visibility and secure, identity-based access control at the network edge. With the appropriate design and well-chosen components, you can meet the needs of your security policy while reducing any negative effect on your infrastructure and end users.
3Note that Request-Identity frames are sent only in the session-initiation phase. During the subsequent authentication process, the retransmission of EAP Request frames is handled by a different variable: max-req, not max-reauth-req.
