Table Of Contents
Network Virtualization—Access Control Design Guide
Lightweight Access Point Deployment with the Cisco WLAN Controller
802.1x Authentication Failure VLAN (Wired)
Auth-Fail-VLAN Operational Overview
Auth-Fail-VLAN Summary and Recommendations
Clientless-Based Authentication
802.1x Guest-VLAN Functionality
802.1x Guest-VLAN Configuration
Guest-VLAN and WoL Interaction
Interaction with VoIP Deployments
MAC Authentication Bypass Operational Overview
MAC Authentication Bypass Configuration and Verification
MAC Authentication Bypass Feature Interaction
MAC Authentication Bypass Opportunities and Benefits
Network Access Profile Matching and Potential Value
Fallback Technique for New/Re-imaged Machines with WZCSVC
MAC Authentication Bypass Limitations and Challenges
Fallback Technique for Re-imaged Machines with CSSC
Lack of Existing Identity Store
MAC Authentication Bypass Policy Assignment
MAC Authentication Bypass Summary
Network Virtualization—Access Control Design Guide
This document provides design guidance for enterprises that want to provide Internet and limited corporate access for their guests and partners. Several solutions for guest and partner access challenges are proposed and analyzed in this document, at both the architectural and functional levels. For related information, see the following documents:
•
Network Virtualization—Guest and Partner Access Deployment Guide— http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/GuestAcc.html
•
•
•
Contents
Introduction
The term network virtualization refers to the creation of logical isolated network partitions overlaid on top of a common physical infrastructure (see Figure 1). Each partition is logically isolated from the others, and must behave and appear as a fully dedicated network to provide privacy, security, and an independent set of policies, service levels, and even routing decisions.
Figure 1 Network Virtualization
Network virtualization provides multiple solutions to business problems and drivers that range from simple to complex. Simple scenarios include enterprises that want to provide Internet access to visitors (guest access). The stringent requirement in this case is to allow visitors external Internet access, while simultaneously preventing any possibility of unauthorized connection to the enterprise internal resources and services. This can be achieved by dedicating a logical "virtual network" to handle the entire guest communication path. Internet access can also be combined with connectivity to a subset of the enterprise internal resources, as is typical in partner access deployments.
Another simple driver for network virtualization is the creation of a logical partition dedicated to the machines that have been quarantined as a result of a Network Admission Control (NAC) posture validation. In this case, it is essential to guarantee isolation of these devices in a remediation segment of the network, where only access to remediation servers is possible until the process of cleaning and patching the machine is successfully completed.
Complex scenarios include enterprise IT departments acting as a service provider, offering access to the enterprise network to many different "customers" that need logical isolation between them. In the future, users belonging to the same logical partitions will be able to communicate with each other and to share dedicated network resources. However, some direct inter-communication between groups may be prohibited. Typical deployment scenarios in this category include retail stores (for example, Best Buy, Albertson's, Wal-Mart, and so on) that provide on-location network access for kiosks or hotspot providers.
The architecture of an end-to-end network virtualization solution targeted to satisfy the requirements listed above can be separated in the following three logical functional areas:
•
•
•
Each area performs several functions and must interface with the other functional areas to provide the end-to-end solution (see Figure 2). This design guide focuses on the access control functional area to securely grant and control authorized access into any internal network system, while providing optional access to guests or partners.
Figure 2 Network Virtualization—Three Functional Areas
The access control functional area identifies the users or devices logging into the network so they can be successfully assigned to the corresponding groups. An identity is an indicator of a client in a trusted domain. In this architecture, it is used as a pointer to a set of rights or permissions to allow for client differentiation. The model described in this document demonstrates how to use identities as not only a security mechanism, but also how to use identity to provide permissions to service within a domain. Although network services are arbitrary, this represents a linkage to path isolation techniques to provide a holistic form of differentiation between various types of clients. Access control also promotes authentication: the process of establishing and confirming the identity of the client requesting services. Authentication is crucial for network-based security benefits, and to establish corresponding authorization as well.
When identified, the endpoints must be authorized onto the network. To achieve this, the enterprise LAN edge port on which an endpoint connects is activated and configured with certain characteristics and policies. Examples of authorization include the configuration of the VLAN membership of a port based on the results of an authentication process, and the dynamic configuration of port ACLs based on the authentication.
Note
When an endpoint is authorized on the network, it can be associated to a specific group that typically corresponds to a separate partition or domain. Thus, the authorization method ultimately determines the mapping of the endpoint to an end-to-end virtual network. For example, when a VLAN is part of a virtual network, a user authorized onto that VLAN is therefore authorized onto the virtual network.
The main authentication scenarios for the enterprise are as follows:
•
•
The current state of the technology provides broad support for VLAN assignment as an authorization alternative. In the cases where policy changes based on authentication are required and only VLAN assignment authorization is available, a static assignment of a policy to a VLAN provides the required linkage between the user authorization and the necessary policy. In effect, the policy is applied to the VLAN because users are subject to the policy when authorized onto the VLAN. The primary use of VLAN assignment promotes differentiation, and is critical to linkages to path isolation techniques. In essence, VLANs may be mapped into separate policy domains, which define the correct entrance criteria into the path isolation architecture alternatives.
Various access control technologies are discussed in this document: 802.1x, Guest-VLAN, Auth-Failed VLAN, MAC-Authentication Bypass (MAB), and so on. Note the following two important points:
•
•
–
–
–
Technology Scope
The client-based framework focuses on 802.1x only as the access control method to provide holistic control over client access to the network. 802.1x always assumes a supplicant at the edge. 802.1x can give customers ubiquitous, port-based access control and provides them with the ability to manage access control on multiple levels for wired and wireless integration purposes. In support of network virtualization, 802.1x can also allow customers to leverage the notion of an authenticated identity with granular policy controls. Although out of this document scope, 802.1x can also provide auditing/accounting measures to network visibility and automate encryption techniques for end stations (wireless only today).
Upon evaluation of 802.1x, a customer must take Guest-VLAN interoperability into account. This design guide discusses recent changes in this arena. It also addresses the Auth-Fail-VLAN to provide wired topologies a method to provide clients network access that is illegitimate and be otherwise failed on any connection attempt into the networked system. The Auth-Fail-VLAN is positioned here as a means to provide access for the 802.1x-enabled partner or guest. It is not positioned as a de facto recommendation for any 802.1x deployment. This design guide also introduces other clientless methods of access control to provide access as well. This form of access control is device-specific in nature, and is discussed in the wired context only. This functionality is MAC-Auth-Bypass. In all cases, Windows Active Directory was used as the backend identity store as the verified directory infrastructure.
This document does not discuss the following technology areas:
•
•
•
•
•
•
•
•
•
•
•
Product Scope
The 802.1x supplicants discussed in both the wired and wireless contexts are the Cisco Secure Services Client (CSSC) version 4.0.5 and the embedded supplicant available in Windows XP SP2. The switches and corresponding Cisco IOS revisions examined as part of the demonstrated architecture are as follows:
•
•
•
Wireless was also tested in the scope of access control. To achieve this, a Cisco Wireless LAN Controller (WLC) 4402 version 3.2.150.6 was tested with Cisco 1240 access points. As the backend authentication server, the CiscoSecure ACS Appliance 1112 version 4.0 was tested.
No other supplicants, network infrastructure devices, or authentication servers or directory infrastructures were tested as part of this architecture and cannot be validated as working components of the solution at this time.
Client-Based Authentication
802.1x offers an efficient framework to a protected network for authenticating and administering user traffic. Together with technology extensions and supplemental authentication techniques, 802.1x builds on access control to establish a technology solution that can improve the security of physical and logical access to LANs.
802.1x Framework
The use of 802 LANs in public and semi-public places has dramatically increased. There is now a desire to provide a mechanism to associate identities with the port of access to the LAN to establish authorized access. 802.1x ties the Extensible Authentication Protocol (EAP) to both the wired and wireless LAN media and supports multiple authentication methods. 802.1x defines a generic framework that is able to use different authentication mechanisms without implementing these mechanisms outside the backend authentication infrastructure and client devices. 802.1x specifies a protocol framework between devices desiring access to a LAN (supplicants) and devices providing access to a LAN (authenticators). Various credentials, such as token cards, Kerberos, one-time password, certificates, and public key authentication can be used with 802.1x. Primarily, 802.1x is an encapsulation definition for EAP over an IEEE 802 media. This is known as EAP over LAN, or EAPOL. EAPOL transports authentication messages (EAP) between supplicant (user/PC) and authenticator (switch or access point). 802.1x always assumes a secure connection, and the actual enforcement is done via MAC-based filtering and port-state monitoring.
Although 802.1x is the recommended method to deploy access control in an enterprise environment, it is not the specific focus in this paper. The business problems that network virtualization is aimed to solve in this phase include the following:
•
•
•
•
Hosted access and NAC remediation environments are not typically enabled for 802.1x at present. The need remains for some way to provide access to guest or partners when they are equipped with an unmanaged 802.1x supplicant. The 802.1x supplicant of the guest or partner may indeed be managed, but not by the IT staff that owns the network into which they plug. Thus, this design guide focuses only on what it takes to allow guest or partner online access in a virtualized environment when they are equipped with an 802.1x supplicant on the device.
Wireless Guest Access
Wireless users typically access the network differently than wired users. The paradigm of public access has extended to the enterprise. Mobility demands network connectivity. Enterprise guest access services are now a necessity in the corporate environment. The solution is made up of many components: access points, controllers, and management systems.
A detailed description and comparison of the various wireless deployment options is not within the scope of this document; a brief, high-level description of each scenario is provided in the following sections but only in the context of network access control. For more information on Cisco Integrated Wireless Networks, see the following URL: http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/ns337/networking_solutions_package.html.
A typical company security policy most likely requires the implementation of various types of authentication and encryption for various types of users. For example, open authentication and no encryption are the typical choices when providing guest access, whereas 802.1x authentication and strong encryption are usually adopted for internal employees. This is achieved by defining multiple service set identifiers (SSIDs) on each access point, with each SSID characterized by its own security policies.
End users associate with the closest access point by selecting a specific SSID to access the enterprise network. After this point, the WLAN Controller allows traffic to be logically separated from the traffic for users belonging to different groups. This is described in more detail in the following section.
Lightweight Access Point Deployment with the Cisco WLAN Controller
A WLAN controller system is used to create and enforce policies across many different lightweight access points in this architecture (see Figure 3). Security, mobility, quality of service (QoS), and other functions essential to WLAN operations can be efficiently managed across an entire wireless enterprise by centralizing intelligence within a controller system. Furthermore, by splitting functions between the access point and the controller, IT staff can simplify management, improve performance, and increase security of large wireless networks.
Figure 3 Cisco Wireless LAN Controller
LWAPP revolutionizes the way WLAN deployments are managed with the concept of split MAC, which means the ability to separate the real-time aspects of the 802.11 protocol from most of its management aspects. In particular, real-time frame exchange and certain real-time portions of MAC management are accomplished within the access point, while authentication, security management, and mobility are handled by WLAN controllers. The Cisco Centralized WLAN Solution, which uses LWAPP, is the first centralized WLAN system to use the split MAC.
From a traffic handling perspective, all data traffic originating from wireless clients associated to the distributed lightweight access points is encapsulated on the access points themselves and carried to a centralized wireless LAN controller, which aggregates the traffic and represents the single point of ingress and egress for IP traffic to and from the wired network. Traffic is tunneled from the access points to the centralized controller, leveraging LWAPP. The LWAPP tunnel is a Layer 2 tunnel (the original Ethernet frame is LWAPP-encapsulated), which carries both control and data traffic. Data traffic uses UDP port 12222, control traffic is encapsulated in UDP port 12223, and Radio Resource Manager uses ports 16666/16667. In addition, the control traffic is AES-encrypted, while the data is in the clear.
There is not a separate logical tunnel for each defined SSID; only a single logical tunnel is built between each access point and the centralized WLAN controller. This LWAPP tunnel is used to carry the data traffic for all the wireless clients associated to the access point, independently from the SSID they are using for this association.
Figure 4 shows the deployment of the lightweight architecture in an enterprise campus network where two categories of users (employees and guests) are defined as an example.
Figure 4 Lightweight Architecture Deployment
From the traffic isolation perspective, this scenario is very similar to the wired deployment in a traditional campus design. The reason is that traffic from various categories of users associating with their own SSID, after being aggregated to the main WLAN controller, is bridged to a corresponding VLAN and carried up to the first Layer 3 hop device.
Figure 5 shows how the use of VLANs allows maintaining separation between the guest traffic and the enterprise internal traffic in the Layer 2 domain, in a very similar way to the wired scenario for a traditional campus deployment (Layer 2 in the access).
Figure 5 Similarities Between Wired and Wireless Deployments
Several alternative designs can be deployed when positioning the WLAN controllers in the campus network. Cisco recommends placing the WLAN controllers in a centralized location (for example, a data center) to leverage the high availability and continuous monitoring characteristic of such an environment. (See Figure 6.)
Figure 6 Cisco Wireless LAN Controller Deployment in a Campus Network
For more information on the design and implementation of the Cisco Unified Wireless Network based on the unified wireless architecture, which includes products operation with LWAPP, see the Enterprise Mobility 3.0 Design Guide at the following URL: http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob30dg/emob30dg-Book.html.
802.1x Authentication Failure VLAN (Wired)
On a traditional 802.1x wired port, the switch does not provide access to the network until the supplicant connected to a port is authenticated, by verifying its identity information with an authentication server. There is no concept of an SSID for wired topologies today. For both media types, authentication failures work great in preventing rogue access to a network. This is a primary reason that some enterprises seek to enable 802.1x pervasively at the LAN edge. This default behavior is shown in Figure 7.
Figure 7 Typical 802.1x Authentication Failures
However, for wired topologies, there must be a way to deal with the fact that an 802.1x-enabled guest or partner can plug into the enterprise LAN via wired ports.
The Auth-Fail-VLAN can be configured for an 802.1x port to provide limited services to clients. These clients are 802.1x-compliant and cannot access another VLAN because they fail the authentication process. A restricted VLAN allows users without valid credentials in an authentication server (typically, visitors to an enterprise) to access a limited set of services. The administrator can control the services available to the restricted VLAN.
Note
With the Auth-Fail-VLAN feature, you can configure the VLAN on a per-port basis and is enabled (by default) after three 802.1x authentication attempts. The port is then enabled and port forwarding is allowed in a VLAN where the supplicant can access the network. The Auth-Fail-VLAN can be configured for an 802.1x port to provide limited services to clients that are 802.1x-compliant and cannot access another VLAN because they fail the authentication process.
There may be several reasons why a user fails the 802.1x authentication. In addition, refer to an over-arching security policy to evaluate the deployment of the Auth-Fail-VLAN. The Auth-Fail-VLAN ultimately grants access to a device or end user that fails authentication. Although this authentication failure event can be differentiated from authorized devices, there is no chance to differentiate an 802.1x-enabled guest or partner who needs some form of network access from a hacker or illegitimate user. The same principle exists in wireless topologies. If 802.11 opens with no authentication provided by a separate SSID, there is no way to keep an illegitimate user off the network. Wireless uses an SSID to differentiate the entire session. Wired can only use an actual authentication failure to attempt accomplish a similar task.
Auth-Fail-VLAN Operational Overview
The authenticator (access switch) counts the failed authentication attempts for a client. When this count exceeds the configured maximum number of authentication attempts (the default is 3), the port is deployed into the Auth-Fail-VLAN. After a port is moved to the Auth-Fail-VLAN, an EAP success message is sent to the client, as shown in Figure 8.
Figure 8 Auth-Fail-VLAN Operation
The behavior of the client from this point is affected by three variables: the specific 802.1x supplicant that is used (Microsoft or CSSC), the EAP protocol, and the specific switch platform acting as authenticator. These interdependencies are clarified in the following sections of this paper.
Any active VLAN can be configured as Auth-Fail-VLAN with the exception of an RSPAN VLAN, or a voice VLAN (VVID). In addition, the Auth-Fail-VLAN feature is not supported on internal VLANs (routed ports) or trunk ports; it is supported only on access ports.
Note
Auth-Fail-VLAN Configuration
Following are configuration samples that enable the Auth-Failed VLAN feature on IOS and CatOS authenticators:
•
interface FastEthernet0/1switchport access vlan 2switchport mode accessdot1x pae authenticatordot1x port-control autodot1x auth-fail vlan 5spanning-tree portfastspanning-tree bpduguard enable•
set vlan 2 2/1set port dot1x 2/1 port-control autoset port dot1x 2/1 auth-fail-vlan 5set spantree portfast 2/1 enableset spantree bpdu-guard 2/1 enable
Note
Auth-Fail-VLAN Verification
Reasons why a user may fail the 802.1x authentication, causing the switch port to be deployed in the Auth-Fail-VLAN, include the following:
•
–
Figure 9 Microsoft Supplicant CTL Example
In many situations, including guest access scenarios, the certificate authority (CA) that provided the certificate sent by the RADIUS server is most likely not part of the client CTL (especially in deployments where a private CA is used). As a consequence, the TLS handshake tried in the tunnel establishment phase fails. The client denies the authentication attempt by being unable to verify the backend server to establish an SSL tunnel between client and server. On ACS, the message appears as indicated in Figure 10.
Figure 10 Authentication Failure From Client
Note that by default, the Microsoft Supplicant (WZCSVC) and the Cisco Secure Services Client (CSSC) validates the server certificate by default when tunneled methods are configured. Older versions of the Meetinghouse AEGIS client did not trust a server certificate by default.
–
Figure 11 Conditional Trust for a Server Certificate
Note
When the popup is displayed, an end user can manually accept the certificate sent by the authentication server, and avoiding failing the authentication because of SSL handshake. The authentication at this point may still fail for one of the two reasons discussed in bullets two and three below.
•
Figure 12 CSSC Options for Authentication
The supplicant is configured to try an EAP type that is not supported by the RADIUS server.
CSSC Behavior
WZCSVC implements PEAPv0, whereas the CSSC client implements PEAPv1 ("Cisco PEAP"). This subtle difference does not change the overall behavior, as shown below. The behavior verified with CSSC for an authentication failure was far different than WZCSVC. CSSC does not work with the Auth-Fail-VLAN as of version 4.0(5). CSSC sends an EAPOL-Logoff frame as a result of an authentication failure event. Two default values in a standard deployment of CSSC 4.0(5) pertain to this: "Interactive Authentication Retries" and "Non-Interactive Authentication Retries" failures, which are shown in Figure 12.
Figure 13 CSSC Deployment Package
The screen shown in Figure 13 is from a CSSC deployment package. Creating a deployment package and changing the default mode of operation is the only way to change these values. "Interactive" means when the supplicant is not using any cached credentials and prompts the end user. "Non-interactive" means when the supplicant is using cached credentials for Single Sign On (SSO), or for machine authentication where the same Windows credentials are also sent to the RADIUS server for 802.1x authentication.
The values demonstrated above are when EAPOL-Logoffs are sent out. The value of these timers represents the number of EAP Failure messages that the supplicant can receive before sending an EAPOL-Logoff message to the switch. When considering the Auth-Fail-VLAN, it is important to correlate the value of the Auth-Fail-Max-attempts parameter that is configured on each switch port (using the dot1x auth-fail max-attempts command). This parameter dictates how many RADIUS Reject messages the switch must receive from the RADIUS server before sending an EAP Success to the supplicant. Its default value is 3, which essentially causes the switch to behave as shown in Figure 8. When receiving the third RADIUS Reject message from the AAA server, an EAP Success is sent to the client. As a consequence, the supplicant never sees more than two EAP Failure messages from the authenticator, which leads to the following two scenarios:
•
•
Figure 14 EAPOL-Logoff after Failure
Note
By default, when authentication fails without the Auth-Fail-VLAN, sending an EAPOL-Logoff does not matter, because the switch has a default held timer of 60 seconds anyway. However, the problem with the transmission of an EAPOL-Logoff frame in an Auth-Fail-VLAN scenario is that upon the first failure, there is practically no held timer, and the switch tries to authenticate the session again immediately. Furthermore, the EAPOL-Logoff frame sent by the supplicant is now processed normally by the switch. For IOS, this also resets the Auth-Fail count toward the deployment of the Auth-Fail-VLAN back to zero, and this process repeats again immediately. This is now a potential DoS attack on RADIUS. A single machine may be sitting idle and failing authentication repeatedly with no held state to protect or delay the event from occurring. However, if you modify the default deployment package, as described above, and increase the number of default retries for both the parameters above to something greater than 3, it can allow the Auth-Fail-VLAN to work. In addition, the default values of these are being changed to a number greater than three in the 4.1 release of CSSC code.
CSSC with Catalyst 6500
The sequence of events when a client fails the 802.1x authentication with the RADIUS server is displayed in the sniffer trace shown in Figure 15.
Figure 15 Auth-Fail-VLAN Deployment
The client receives two EAP Failures (frames 9 and 17), but after the third authentication failure, the switch is actually sending an EAP Success (frame 25).
At this point, the switch port is open and deployed to the Auth-Failed VLAN, so the client can pull an IP address from the DHCP server (frames 56-59) and achieve network connectivity.
From a user experience perspective, the supplicant appears to be still trying to connect, as displayed in Figure 16.
Figure 16 Supplicant GUI Upon Auth-Fail-VLAN Deployment
The reason for this behavior is that the supplicant still knows that it failed the inner authentication (inside the SSL tunnel), despite the fact that the switch sent an EAP Success outside of the tunnel.
After 30 seconds from receiving the first EAP-Success, the supplicant sends a new EAPOL-Start (frame 316) to try again to authenticate. The authenticator does not honor this frame, but simply discards it (because the port is in the Auth-Failed VLAN), and at this point the supplicant "gives up" and enters the connected and authenticated state, as shown in Figure 17.
Figure 17 Supplicant GUI After Timeout of Trying to Authenticate Again
Note
CSSC with Catalyst 3750 and Catalyst 4500
The sequence of events when the supplicant fails the 802.1x authentication with the AAA server is displayed in the sniffer trace shown in Figure 18.
Figure 18 Switch Honors EAPOL-Starts after Supplicant is Confused
The client receives two EAP Failures (frames 17 and 30), but after the third authentication failure, the switch is actually sending an EAP Success (frame 42).
At this point, the switch port is open and deployed to the Auth-Fail-VLAN, so the client can pull an IP address from the DHCP server (frames 44-47) and achieve network connectivity.
From a user experience perspective, the supplicant appears to be still trying to connect, as displayed in Figure 19.
Figure 19 Supplicant GUI Upon Auth-Fail-VLAN Deployment
The reason for this behavior is that the supplicant still knows that it failed the inner authentication (inside the SSL tunnel), despite the fact that the switch sent an EAP Success outside of the tunnel.
After 30 seconds from receiving the first EAP-Success, the supplicant sends a new EAPOL-Start (frame 162) to try again to authenticate. Differently from what is observed with the Catalyst 6500 platform, the Catalyst 3750 and 4500 actually honor the EAPOL Start message and initiate RADIUS communication with the RADIUS server (frames 165-307). The authentication keeps failing, so the authenticator keeps manufacturing indefinitely EAP-Success frames to be sent to the client (frame 308). There are two consequences for this behavior:
•
•
Figure 20 DoS Attack on RADIUS via Auth-Fail-VLAN
This is broken behavior (CSCsd42505). This will be developed in release 12.2(35)SE and 12.2(31)SGA, and will allow the 3750 and 4500 to behave like the 6500, silently discarding EAPOL Start messages received from the client when the switch port is deployed in the Auth-Fail-VLAN.
The impact of this behavior when deploying a large numbers of stations into the Auth-failed VLAN should be considered.
WZCSVC Behavior
The behavior of the WZCSVC supplicant that ships on Windows XP platforms is almost identical to the CSSC supplicant. (See Figure 21.) The behavior is also identical to that observed on CatOS with CSSC clients, with the only difference that the supplicant sends EAPOL-Start every 60 seconds (and not 30) after the switch port is deployed into the Auth-Failed VLAN (frames 135, 234, and 317 below). In addition, before giving up, it sends three EAPOL-Start messages (that are discarded by the switch), whereas only one EAPOL-Start was sent by CSSC.
Figure 21 Auth-Fail-VLAN Deployment with Confused WZCSVC Supplicant
After sending the third EAPOL-start without receiving response from the authenticator, the supplicants give up trying to authenticate and enter the "open" state. (See Figure 22.) WZCSVC has no control over the IP stack.
There is no direct indication to the end user that after sending the third EAPOL-Start, the supplicant is actually giving up the authentication attempts, because the network interface still says "Attempting to authenticate" or ultimately "connected".
Figure 22 Confused WZSCVC Supplicant
However, the client would be able to pull a network address from the pool corresponding to the auth-failed VLAN and to gain network connectivity.
In addition, if Active Directory (AD) is used as a backend database with the WZCSVC supplicant and the user is not found in AD, or the password sent is wrong, the supplicant may get stuck during the communication with the RADIUS server. The consequence is that the attempt does not even fail, preventing the deployment of the switch port into the Auth-Fail-VLAN. This implies that no network access at all can be provided in this scenario.
It was noticed that this supplicant does not return a failure response to the failure message of the server. For ACS, this prevents the EAP state machine from getting to the next stage of sending the final EAP-MSCHAP failure code and a RADIUS-Reject. As such, ACS does not send a RADIUS-Reject to the switch immediately. Nonetheless, it should result in a failure. Operationally, the first two authentication failures of each conversation result in a RADIUS challenge as opposed to a reject. Then, a reject is sent on the third unsuccessful attempt. With respect to the Auth-Fail-VLAN, this means an end user may actually have to fail nine times before the Auth-Fail-VLAN activates, because it is enabled upon the receipt of RADIUS-Rejects. In addition, note that the WZCSVC supplicant does not display meaningful messages such as "Account Expired", "Bad Logon Hours", and so on. The only failure scenarios that work with this supplicant are a bad password (where the user is otherwise known) or an expired password. This behavior occurs only with PEAP for machines and users who either blindly trust a server certificate from ACS, or who conditionally trust the server certificate and the credentials have actually been removed from a domain.
Auth-Fail-VLAN Summary and Recommendations
In the wired media for 802.1x, there exists a need to provide access to devices that fail authentication. This is the Auth-Fail-VLAN. This can also serve as a method to provide 802.1x-enabled guests and partners network access in a network virtualization architecture.
This is not a problem for wireless, because of culture, the secondary nature of the wireless media, and 802.11 station authentication. With 802.11 open, no authentication, and a broadcast SSID, the guest or partner problem can be solved easily without the need to attempt to provide access to devices that actually fail 802.1x authentication. It is typically not a problem for IPsec, PPP, or dial-up environments either. It is a problem for the wired media at the enterprise LAN edge, however. The Auth-Fail-VLAN can serve as a way to deal with the wired 802.1x-enabled entity that is unknown to the hosting enterprise.
However, there are some architectural problems with the Auth-Fail-VLAN as verified above. EAP is between a supplicant and an EAP-Server in the 802.1x framework. Although not precluded by the EAP architecture, Cisco switches today are not EAP-Servers, but authenticators only. Primarily, this means that they serve as an EAP transport via 802.1x and RADIUS, and rely on an authentication server to be an EAP-Server. Because switches operate in pass-through mode for EAP, attempting to modify the result of the authentication conversation from the authenticator alone can be challenging. Specifically, this is the operation of the authenticator sending an EAP-Success when it would otherwise send an EAPOL-Failure. The first issue is that the switch does not have visibility into what is actually going on, nor should it. Fundamentally, the switch is launching a man-in-the-middle attack on EAP.
For EAP methods that support mutual authentication, the supplicant authenticates the network as well as the network authenticating the supplicant. For these methods, if the authentication fails, it is reasonable to assume that the supplicant will not authorize its port to allow traffic anyway, nor should it. Testing has proven that the CSSC and WZCSVC supplicants do not exhibit the notion of a controlled port, however, although this could change in the future. For tunneled EAP methods, if the supplicant receives a failure inside a tunnel (that a switch can do nothing about) and a clear channel success as demonstrated above, this becomes a conflicting message. In the future, supplicants could be configured to treat this behavior as an invalid authentication attempt that should not be trusted or allowed. Verification testing has proven the current operation to work with most EAP methods, given these constraints. However, as demonstrated above, this does not work completely for tunneled methods such as PEAP or EAP-FAST. The verification demonstrates that in this scenario, supplicants get confused, and try to begin authentication over again, which results in a timeout condition.
Based on the series of issues discovered as part of the system verification, the code revisions tested on switches should not be recommended as part of a network virtualization solution. However, switches have already addressed most of the architectural issues with the behavior tested through CSCse71105 and CSCse58950. This changes the anatomy of the Auth-Fail-VLAN. There is no longer a transmission of an EAP-Success. Switches process failures rather normally. This new behavior is shown in Figure 23 (which begins at the end of a second consecutive failure).
Figure 23 Auth-Fail-VLAN—New Behavior
After a third consecutive failure, the port is enabled rather silently. There is no new CLI added for this change in functionality. At this point of enabling the port, any supplicant can choose to access the network or not (which is ultimately out of the control of a switch). This provides a predictable supplicant behavior, works with any EAP method, and provides a supplicant-agnostic solution. There remain systemic-level gaps (such as the agreement of end-to-end session state) but it should be deployable based on fixes to the DDTSs referenced above. In addition, not all customers run ACS or CSSC, so this should only impact internal deployments that attempt to get the Auth-Fail-VLAN to work. With CSSC, an end user also has the ability to temporarily stop the supplicant from the system tray anyway when they know they are traveling to a foreign network. This disables 802.1x on the supplicant, and it can be treated as a clientless session.
Clientless-Based Authentication
Currently, 802.1x is the recommended port-based authentication method at the access layer in enterprise networks. It has the following three primary components:
•
•
•
Typically, the authenticator tries to authenticate the host device running the supplicant software to the authentication server. With some operating systems, the 802.1x supplicant capability is enabled by default (for example, Windows XP), but not all devices have this supplicant capability embedded into their operating system. For example, most printers, IP phones, fax machines, and so on, do not have this capability but still need to be allowed into the network even without 802.1x authentication. A supplemental authentication technique should be employed as the basis of the non-responsive host issue with 802.1x. This solution-based feature set is MAC Authentication Bypass (MAB). In addition, exception lists on routers or switches are not scalable for large enterprises. Thus, a method is needed for supporting these hosts.
For network virtualization, access control must also focus on clients who do not possess 802.1x capability, or whose 802.1x capability may be temporarily suspended to support mobility into environments where the end user/client may not be otherwise known to the authentication infrastructure in advance. When 802.1x is implemented in such an environment, a customer typically needs the ability to dynamically provision individual MAC addresses (without impacting service availability) for network authentication of non-responsive devices such as printers, video conferencing units, satellite receivers, faxes, and so on. MAB is intended to control network access based on a MAC address. The goals of MAB are to provide network access control on a port basis, based on a MAC address, and to dynamically apply policy to a client session based on a MAC address.
The Guest-VLAN may also be used to provide access for clients incapable of 802.1x and where the client MAC address may be unknown in advance. Although originally designed as a deployment enabled for 802.1x supplicant functionality on end stations, the Guest-VLAN provides an option for mobile guest users as well.
In addition, this document reflects updates to changes in recent functionality across the Cisco Catalyst switching product line that may impact the related architecture to support network virtualization.
Static VLAN Configuration
In this approach, each switch port on the access layer switches in the campus needs to be manually assigned to a VLAN. There are multiple drawbacks to this approach, including the lack of mobility capabilities across the enterprise network and the lack of any mechanism to identify the user before allowing connectivity to the network. In a design supporting multiple user groups that need to remain isolated from each other, there is also the drawback of increased costs because each switch port is reserved for a specific user group, even when not used to capacity.
802.1x Guest-VLAN
For enterprises that are starting to deploy 802.1x in their networks, leveraging Guest-VLAN functionality is a key element in providing network access to clients that are not equipped with an 802.1x supplicant. The 802.1x Guest-VLAN functionality was initially deployed as a migration tool to allow enterprises to easily migrate client devices to support 802.1x, while still providing network connectivity.
Any VLAN can be configured as the Guest-VLAN, voice VLANs (VVID), and the VLAN used for Remote SPAN (RSPAN). The Guest-VLAN feature is currently supported across all Cisco Catalyst platforms (4500, 3750, 3560, 2950 running Cisco IOS, and 6500 running CatOS); it will be integrated into Cisco IOS software releases for Catalyst 6500 platforms in the near future.
802.1x Guest-VLAN Functionality
Figure 24 shows the functionality of the 802.1x Guest-VLAN feature.
Figure 24 Guest-VLAN Feature
Currently, when a switch port initially receives a link, an EAP-Identity-Request message is transmitted to actively look for an 802.1x supplicant. This happens regardless of whether the device that connected to the port is actually equipped with the supplicant.
Assuming that the user does not have the 802.1x capability on their machine, the request from the switch goes unanswered. After the expiration of a timer (tx-period), the switch sends a new EAP-Identity-Request frame. This behavior is dictated by the 802.1x specification. This process continues until the third request from the switch goes unanswered. The number of retries is determined by the value of the max-reauth-req parameter. After the maximum number of retries is exceeded, and if the switch port has been configured with the 802.1x Guest-VLAN functionality, the port is moved to the Guest-VLAN and the switch sends an EAP-Success message to the client. This message is ignored and discarded by the client.
From the perspective of the 802.1x process, the port has become authorized and the 802.1x state machine has entered the authenticated state; no further security or authentication mechanisms are applied (the 802.1x state machine stops running). It is basically as if the administrator has disabled 802.1x and hard-set the port into that specific VLAN.
802.1x Guest-VLAN Configuration
The behavior illustrated in Figure 24 is valid when using default values for the 802.1x parameters that affect Guest-VLAN functionality: max-reauth-req and tx-period.
The max-reauth-req parameter sets the maximum number of times that the switch retransmits an EAP-Identity-Request frame on the wire before receiving a response from the connected client. This value is set to two by default. This is why Figure 24 shows two retries (at Steps 3 and 4) after the initial EAP-Identity-Request frame sent at link-up. The commands used to change this parameter (in CatOS and IOS) are as follows:
•
cat6500> (enable) set dot1x max-reauth-req ?<max-reauth-req> maximum number of retries to supplicant (1..10)•
cat3750(config-if)#dot1x max-reauth-req ?<1-10> Enter a value between 1 and 10The tx-period parameter sets the number of seconds that the switch waits for a response to an EAP-Identity-Request frame from the client before retransmitting the request. The default value is 30 seconds and is configurable as follows:
•
cat6503> (enable) set dot1x tx-period ?<tx-period> tx period (1..65535 seconds)•
cat3750(config-if)#dot1x timeout tx-period ?<1-65535> Enter value between 1 and 65535The max-req parameter is part of the configurable 802.1x parameter in Cisco IOS. The max-req parameter is different from the max-reauth-req parameter and represents the maximum number of retries a switch performs for EAP-Request frames of types other than EAP-Identity-Request. Basically, this parameter refers to EAP-Data frames, which are the EAP frames exchanged after the supplicant has replied to the initial EAP-Identity-Request frame. For this reason, the max-req parameter is effective only when there is a valid 802.1x supplicant connected, and it does not apply to Guest-VLAN services.
The configurable values for the parameters shown in the preceding configuration example are consistent between the various Catalyst switch platforms, when running the following minimum Cisco IOS software releases (previous releases are characterized by platform-specific configurable values):
•
•
•
For a Catalyst 6500 running CatOS software, the situation is different; the main distinction is the fact that in CatOS releases earlier than 8.5, there is no max-reauth-req parameter. This implies that the same parameter described above (max-req) is used to tune both the number of retries for the EAP-Identity-Request and EAP-Data frames. Note also that the configurable values are consistent with the one detailed for Cisco IOS: max-reauth-req (and max-req) can vary from 1 to 10 and tx-period from 1 to 65535.
The overall configuration of the 802.1x Guest-VLAN is relatively simple but differs on switches running IOS and CatOS software releases, as follows:
•
interface FastEthernet0/1switchport access vlan 2switchport mode accessdot1x pae authenticatordot1x port-control autodot1x guest-vlan 10dot1x max-reauth-req 2dot1x timeout tx-period 30spanning-tree portfastspanning-tree bpduguard enable•
set vlan 2 2/1set port dot1x 2/1 port-control autoset port dot1x 2/1 guest-vlan 10set spantree portfast 2/1 enableset dot1x max-reauth-req 1set dot1x tx-period 30set spantree portfast 2/1 enableset spantree bpdu-guard 2/1 enable
Note
The following formula calculates the time interval before the Guest-VLAN is enabled:
[(max-reauth-req + 1) * tx-period]
The end station must then attempt to send traffic into the network, so the specific time to ultimately authenticate the end device varies. The operation of tweaked timers to timeout 802.1x quickly as indicated above is shown in Figure 25.
Figure 25 Guest-VLAN with Tweaked Timers
This configuration should be attempted only after considering the consequences that this can have on the regular functionality of 802.1x. Analyzing the integration issues between 802.1x and DHCP at startup time helps in understanding this.
If a user starts up a machine equipped with an 802.1x supplicant, two possible scenarios can occur in relation to the use of 802.1x machine authentication after connecting to a switch port configured for Guest-VLAN. A complete description of machine authentication is not within the scope of this document.
The following two scenarios are possible:
•
However, even assuming that the 802.1x supplicant is enabled to send EAPOL-Start frames, the DHCP and the 802.1x processes are completely asynchronous. Therefore, the machine can acquire an IP address from the DHCP pool associated to the Guest-VLAN even before sending the EAPOL-Start frame. In this case, the IP address must be released and renewed after the machine authentication process completes successfully, because the port can now be deployed in a different VLAN from the Guest-VLAN. In this case, things can break if the supplicant running on the machine is not able to trigger this DHCP renewal. The machine would not be able to get an IP address in the correct subnet.
Tests run with various supplicants showed that all of them are able to renew the IP address after the machine authentication process completes. However, this happens by default with CSSC but not with the Microsoft client. Windows XP requires the registry settings described previously or the machine does not send the EAPOL-Start and therefore is stuck in the Guest-VLAN. The same situation occurs when the user logs in through the Graphical Identification and Authentication (GINA) interface (which serves as the gateway for interactive logons).
•
In conclusion, it is possible to set the tx-period and max-reauth-req parameters to the minimum configurable values to reduce the time interval required for the deployment of a switch port in the Guest-VLAN. To avoid breaking the 802.1x functionality when using the Microsoft XP supplicant, Cisco recommends that you modify the default Windows registry values to allow the Microsoft supplicant to send EAPOL-Start frames. This is the default behavior for CSSC clients.
Wake-on-LAN Primer
Wake-On-LAN (WoL) is an industry standard, which is the result of the Intel-IBM Advanced Manageability Alliance. WoL creates a power management wake-up event. This is an advanced power management capability on many network interface cards (NICs) in the industry today. NICs that support WoL have an extra connector and cable to connect to the motherboard. After a machine goes into suspend mode, it can be automatically reactivated when data from the network is received by the NIC. This capability can be used to wake up a mail server machine to deliver mail, for software management pushes, to deploy patches overnight, and so on. By default, 802.1x and WoL are mutually exclusive, because of the architecture of 802.1x, as shown in Figure 26.
Figure 26 Standard 802.1x Operation
As indicated above, a switch exerts control over a virtual port in both directions. This is known as a bi-directional controlled port. This means only EAPOL should come into or go out of the switch port until authenticated. However, the operational direction of the controlled port can be changed per section 6.4(b) of the IEEE spec for 802.1x. Thus, in an effort to interoperate with WoL environments, most Cisco Catalyst switches provide unidirectional controlled port functionality as an optional configuration. WoL is a per-port feature. Operationally, the controlled port should then only operate in one direction. A WoL "magic packet" can now exit the network to wake a machine up if necessary. The machine still must 802.1x authenticate before successfully send traffic into the network. This corresponding configuration is as follows:
•
interface FastEthernet0/1switchport access vlan 2switchport mode accessdot1x pae authenticatordot1x port-control autodot1x control-direction inspanning-tree portfastspanning-tree bpduguard enable•
set vlan 2 2/1set port dot1x 2/1 port-control autoset port dot1x 2/2 port-control-direction inset spantree portfast 2/1 enableset spantree bpdu-guard 2/1 enableThe configuration above represents a weaker deployment of the technology because it allows outgoing traffic on a port before being secured by 802.1x, while still dropping all the incoming traffic on a port that has not yet authenticated. However, a subtle change is that spanning tree is now placed in a forwarding state for any ports that are not yet authorized.
Note
Minimum releases for the support of this per-port functionality on Catalyst switches are as follows:
•
•
•
•
•
A recommended best practice for any deployment of 802.1x, MAB, the Guest-VLAN, and WoL are to plan ahead of time. Test how specific Network Driver Interface Specification (NDIS) functionalities or configurations residing on end devices should impact link change.
Guest-VLAN and WoL Interaction
A switch port is down conditionally after a link-down event is processed by an authenticator as a machine goes to sleep. The link should then come back up on the port immediately. The link-up event is then processed on the port as well. If the Guest-VLAN is configured, a port is enabled into the Guest-VLAN soon after the original "go to sleep" event. This process is shown in Figure 27.
Figure 27 Machine Going Into Power Save Mode with the Guest-VLAN
As shown above, a machine that goes into power save mode with the Guest-VLAN also enabled bounces link state, and then is deployed into the Guest-VLAN. There may be differences between "hibernate" and "standby" settings on end stations, so specific functionality must be examined in detail to evaluate the impact 802.1x may have on the environment. In addition, it is critical to understand whether an EAPOL-Logoff is, or needs to be, sent by an 802.1x supplicant on the specific implementation when going to sleep.
The operational behavior above exists on ports with the following configurations:
•
interface FastEthernet0/1switchport access vlan 2switchport mode accessdot1x pae authenticatordot1x port-control autodot1x guest-vlan 22dot1x control-direction inspanning-tree portfastspanning-tree bpduguard enable•
id1-6503-1> (enable) set port dot1x 2/2 guest-vlan 605Port Control Direction set to IN on 2/2. Guest-VLAN can not be enabled.id1-6503-1> (enable) set port dot1x 2/2 port-control-direction inPort 2/2 is guest-vlan enabled, Port Control Direction can not be set to IN.
Note
For IOS-based switches, any combined deployment of WoL and the Guest-VLAN renders WoL specific functionality needless. Operationally, if the port is enabled into the Guest-VLAN already, a specific port configuration for the allowance of a unidirectional controlled port itself is not needed.
A best practice for a combined environment is to support WoL functionality from the Guest-VLAN itself, and not to bother configuring the unidirectional controlled port functionality. However, if the Guest-VLAN is being used as a means to provide third-party unauthenticated access, any WoL servers elsewhere in the network must be able to reach the Guest-VLAN. If the Guest-VLAN is configured as a separate VLAN from the access VLAN already configured on the port, this means that the WoL implementations may need to be re-configured to deploy 802.1x to reach the subnets associated to the Guest-VLAN deployed at the edge.
Network virtualization may also impact the operation of WoL functionality for PCs. For example, if the Guest-VLAN on a switch serves as entrance criteria to a separate VRF or VPN for guest access, this guest partition is not able to reach the rest of the enterprise network by design. However, this may conflict the requirement of a WoL server to be able to reach the Guest-VLAN, because it is safe to assume that the WoL server is privately owned and operated by enterprise IT staff. Thus, this needs to be planned for as part of the services edge design of a network virtualization architecture. See the Services Edge Design Guide for more details.
Interaction with VoIP Deployments
The integration of 802.1x and IP phones is based on the switch configuration of multi-VLAN access ports. Multi-VLAN ports belong to two VLANs: native VLAN (PVID) and auxiliary VLAN (VVID). This allows the separation of voice and data traffic and enables 802.1x authentication only on the PVID. Figure 28 shows the type of communication that occurs on these two VLANs.
Figure 28 Multi-VLAN Port
When 802.1x is enabled on a multi-VLAN access port, a supplicant must complete the authentication process before getting access to the data (native/PVID) VLAN. The IP phone can get access to the voice (auxiliary/VVID) VLAN after sending the appropriate Cisco Discovery Protocol (CDP) packets, regardless of the dot1x state of the port. The use of CDP with Cisco IP phones is typically required, given the lack of pervasive support for an embedded 802.1x supplicant. However, newer IP phones models have attained supplicant capability. In addition, multi-domain authentication (MDA) on switches provides a means to authenticate a phone and data client on the wire via 802.1x and/or MAB.
Note
The configuration commands for Cisco IOS and CatOS that are required to enable multi-VLAN functionality, in conjunction with 802.1x and Guest-VLAN functions, are as follows:
•
interface FastEthernet0/1switchport access vlan 2switchport mode accessswitchport voice vlan 2dot1x pae authenticatordot1x port-control autodot1x guest-vlan 10spanning-tree portfastspanning-tree bpduguard enable•
set vlan 2 2/1set port dot1x 2/1 port-control autoset port dot1x 2/1 guest-vlan 10set port auxiliaryvlan 2/1 2set spantree portfast 2/1 enableset spantree bpdu-guard 2/1 enableThe multi-VLAN and the Guest-VLAN features are not currently supported on Catalyst 6500 platforms running native Cisco IOS images. The Catalyst 6500 requires CatOS or Hybrid (CatOS and Cisco IOS). These features are supported on all other Catalyst platforms, beginning with the following minimum software releases:
•
•
•
•
•
This section describes the circumstances in which the Ethernet port on the IP phone can be shared between users equipped with 802.1x supplicants and users that do not have supplicants.
When accessing the network by connecting to the port on an IP phone, no link-down event occurs on the switch port when the PC is later removed. Therefore, the switch is unaware of this event, which poses security vulnerabilities.
Note
To determine the conditions under which the same IP phone PC port can be sequentially used by various categories of users (users equipped with an 802.1x supplicant and those who are not), two main aspects must be considered:
•
Note
http://www.cisco.com/en/US/products/hw/phones/ps379/prod_release_note09186a0080461f84.html.•
Scenario 1
The considerations in this scenario are valid for Cisco Catalyst switch platforms running Cisco IOS software versions previous to the following:
•
•
•
•
The same considerations are valid for the Catalyst 6500 running the following CatOS release (and newer):
•
As previously mentioned, when a user connects to the Ethernet port on a Cisco IP Phone, the switch port is unable to detect when the user later disconnects. The proxy EAPOL-Logoff capability is provided on Cisco IP phones to communicate to the 802.1x process that the user (who might have been previously authenticated) has left the port, so that the switch port can be moved from the authenticated to the unauthorized state.
In describing the interaction of the Guest-VLAN with an IP phone, it is essential to distinguish between the two cases where the Cisco IP Phone supports EAPOL-Logoff.
IP Phone That Supports EAPOL-Logoff
When an IP Phone is plugged into a switch port configured as shown in the preceding configuration example, the port is assigned to the Guest-VLAN (see Figure 29).
Note that the Cisco IP phone is not able to reply to the EAP messages originated from the switch given the lack of 802.1x supplicant.
Figure 29 IP Phone and the Guest-VLAN
The 802.1x state machine running on the switch port has now entered into the authenticated state. At this point, what happens depends on who is connecting to the Ethernet port on the IP phone. The port remains configured in the Guest-VLAN if one of the following two situations occurs:
•
Guest
