This is part II in the series of technical foundation posts leading up to our December 11th TechChat “Networks That Know You: Cisco Identity-Based Networking Services”.
Chances are, you got authenticated today. If you withdrew money from an ATM, swiped your employee badge or joined a secure wireless network, then you provided a valid form of identification to prove who you were. Once authenticated, you were authorized for some kind of access: to your money, a building or a wireless network. The one time you might not have been authenticated was when you plugged into the wired Ethernet port in your cube. IEEE 802.1X, the protocol designed specifically to authenticate users and devices at the access edge, is not ubiquitous on wired switches. One of the reasons is that 802.1X requires a client, called a”supplicant,” to carry out the authentication. Without a supplicant, a device cannot get access. That’s not a flaw in 802.1X -it’s the purpose of 802.1X: keep unauthenticated devices off the network.So what can be done about legacy devices that do not support 802.1X? One option is to un-configure 802.1X on ports connected to devices that are not capable of 802.1X. Besides being a nightmare for the IT administrator (“œhey, what port was that printer on again?”), it is also not very secure: an intruder could simply unplug the non-802.1X-capable device and voila! -total access to the corporate network. Clearly, this is sub-optimal. Better solutions leverage the intelligence of the network to automate the process of getting non-802.1X-capable devices on the network. Until now, Cisco’s Identity-Based Networking Services (IBNS) has offered three solutions:1) Configure the switch to attempt 802.1X and, if there is no response, automatically enable the port into a special VLAN (the”Guest VLAN”) with configurable access to the corporate network. With this solution, you could at least use the same configuration on every port, thus lowering the administrative overhead. However, you still have a problem: non-802.1X capable managed assets (such as printers, IP cameras) would have exactly the same access as guests or even rogue devices. Guest VLAN alone cannot provide differentiated network access for different kinds of non-802.1X-capable devices.2) Configure the switch to learn the MAC address of the connected device and validate that against a corporate identity store after 802.1X times out. This technique is referred to as MAC Authentication Bypass (MAB). Devices with known MAC addresses can be granted access to the corporate network while unknown MAC addresses can be denied access or dropped into the Guest VLAN as a fallback. In addition, because the switch queries an external identity store, MAB results in a centralized record of every device that attempts to connect to the network (giving it more visibility than a pure Guest VLAN approach where the switch simply allows the device onto the network). Of course, MAB requires an up-to-date database of the MAC addresses of every managed device on the network-which, of course, every organization has-or do they?3) Configure the switch to provide a login web-page if the device does not respond to 802.1X requests. This is sometimes called Web-Auth or captive portal. This approach only works for devices with web browsers operated by users who can manually enter usernames and passwords. Web-Auth doesn’t do much good for printers. Fortunately, MAB and Web-Auth can be configured together so that devices that fail MAB can be offered Web-Auth as a final option. Organizations that have successfully deployed 802.1X on their wired networks have used one or more of these solutions to support non-802.1X-capable devices. However, even with these features, it is not always smooth sailing. For starters, have you been wondering how the switch determines there is no supplicant on the attached device? The answer is simple: the switch asks if there is a supplicant on the wire and then it waits. Only after a timeout can MAB and/or Guest VLAN or Web-Auth do their work. This may result in significant delays in network connectivity and thus impair productivity.To address these and other concerns, newly announced IBNS features will complement the existing solutions to smooth the deployment of 802.1X in wired networks. We’ll discuss these features in our IBNS Second Life Techchat on December 11.Written by Shelly Cadora, PhD* *Shelly will be one of our speakers during the December Cisco Live in Second Life TechChat. She is a technical marketing engineer for Identity-Based Networking solutions. She is a 10 year Cisco veteran with a CCIE in Routing and Switching (#16318). Prior to becoming involved with Identity and 802.1X, she was involved in the development of the ASA firewall and Cisco IP Telephony solutions.