802.1x and NAC - Some thoughts

I spend the better part of a week getting 802.1x up and working for both wired/wireless utilizing Cisco ACS, 6500 switch and wireless lan controller plus I also have been working on a separate Cisco NAC Appliance deployment. After spending this much time on getting things working I thought I would review what I consider the benefits and downfalls of the solutions.

First, regarding Cisco NAC Appliance - the product works and is relatively easy to set up but is only full featured as a layer 2 solution right now, imho. The client is way behind where it should be and the layer 3 out of band solution is extremely lacking in the functionality that it really should have and that clients expect. If Cisco is able to make some of the improvements that they are talking about for the NAC Profiler + 802.1x infrastructure + ACS combo then it might be worth the effort but the price is still extremely high. The plus side is the integration with third party anti-virus solutions is excellent so posture and remediation should be leveraged with the product as you don't get that with a pure 802.1x deployment.

Second, Cisco ACS as a product is too long in the tooth and needs to be retooled. For those of us who have been around awhile ACS was what you used for dial up access, AD authentication integration (TACACS/Radius) and policy management for network devices. They are attempting to utilizing it as a policy management and framework engine and the interface and layout of the device is so circa 2000 it can't accommodate today's policy engine requirements. For example, even understanding how to get certificates loaded onto the platform and how they are being used is almost impossible to figure out and the limited logging and debug output is frustrating. Plus the additional burden of it being different depending on which OS solution you chose to deploy adds even more frustration into the mix. Building out Network Access Profiles isn't particularly intuitive or fun on the product either and many of the management functions are not in places you would think they should be. Also, you have to restart the ACS server way too many times for even the smallest changes, that really needs to get fixed.

Third, 802.1x wired solution is not the security be all that some seem to think it is. There are challenges with getting the solution to work correctly with IP handsets from different manufactures and the additional challenge of all the devices out there that do NOT have a supplicant built in and never will. This list includes network items like: printers, scanners, ip cameras, badge readers, environmental sensors, out of band console management, remote power devices, hvac controllers, lighting system controllers, projectors, AV systems and the list goes on and on. That being said, for end client machines, regardless of OS, 802.1x does have broad support and setting up supplicants to work properly is relatively easy and painless. The configuration for the switchport on the 6500 is pretty straightforward, a simple configuration like the following is all that is needed for 12.2.33SXI or newer code:
!
interface GigabitEthernet1/1
description - Standard 802.1x switchport
switchport
switchport access vlan 666
switchport mode access
switchport voice vlan 20
! - the next 4 lines are optional
authentication event fail action authorize vlan 666
authentication event server dead action authorize vlan 666
authentication event no-response action authorize vlan 666
authentication event server alive action reinitialize
authentication port-control auto
dot1x pae authenticator
! - the next line just changes the default value
dot1x timeout supp-timeout 10
auto qos voip trust
spanning-tree portfast edge
no shutdown
!

Assuming you have a guestnet vlan 666 or some sort of equivalent limited vlan roll you can make some very interesting default behaviors for 802.1x when there are foreign clients that connect to your network with no 802.1x supplicant. I set up the additional options to allow the radius server to tell the switch what vlan to put the port on depending on the logon credentials. The extremely useful part of this is that you can use the same principle to assign wireless vlan assignments while using a single SSID. You can even do the same default privilege configuration where if they fail to authenticate they are put in the guestnet vlan.

Fourth, you need a combination of switchport security, 802.1x and a well documented physical access policy to insure compliance to make the whole thing work. The reality of the matter is that folks who are trusted (have valid logon credentials) and want to do something malicious still can. I have been able to get several virtual machine combinations to bypass 802.1x and NAC deployments allowing non-approved client OS's full access to the network. I have also been able to completely lock out legitimate client machines due to poor timeout combinations between the 802.1x supplicant and the OS IP address request timers and the switchport. Then there is the issue of timing for logouts and host machines where their switchport does not go down on reboots allowing alternate OS's to be booted and gain access and not violate MAC based security either. The example, if the already authenticated client machine in the correct vlan is hard powered off but the hosts NIC adapter does not go "down" (several well known manufactures workstations do this) and the machine boots into a new OS (knoppix for instance) and comes back up with no supplicant and does a simple dhcp request it will get an IP address on the authenticated network and have the same MAC address as the trusted authenticated OS. Clearly not as secure as everyone thinks.

Fifth item is regarding wireless and the EAP authentication methods. In some ways the EAP methods for wired port aren't as much a concern. The end workstation has a direct (and likely unshared) connection to the switch that it is doing authentication. Wireless is a different situation where everyone is on the same share bandwidth spectrum and anyone can watch the traffic passing by on the "wire." Selection of the correct EAP method seems easy at first. Most folks seem to think that EAP-TLS is the best option since it requires certificates and you can combine it with end user credentials giving the combination of something you have (a certificate) and something you know (username and password). Getting EAP-TLS actually deployed and all the hosts and supplicants recognizing the certificate chains properly can be a much bigger project than people think. Especially because most of the folks who manage the certificate services are not in the networking group. In addition, there may be two sets of certificate services in use, public ones for websites, sslvpn termination and other public facing services and internal corporate certificate services (often Windows domain based.) Determining which one to use and how to load the trusted certificate authority on the device is a challenge.

Sixth, there may be some vendors that are worth looking at if you are serious about getting 802.1x up and running. The only vendor who had a great switchport authentication solution was Consentry Networks but they went the way of the dodo back in August of 2009. Since I consider Cisco ACS + Cisco switches to be a sub optimal solution (for now) given the complex scenarios a 802.1x wired/wireless deployment might require it looks like Avenda Systems might have the right solution. Their interface seems much better and the company founders came out of Cisco and Microsoft. Their solution addresses the right market and has the right bells and whistles at what appears to be the right price point too. I'll be trying it out some more in our lab and will do a post later with my thoughts about it.

Seventh, nothing seems to replace good IDS/IPS solutions for catching activity that seems out of place and alerting on it. In addition, Netflow/Sflow is really useful in understanding your network behavior and traffic patterns and really should be leveraged to understand when something is happening on your network that looks odd.

Finally, nothing replaces good HR/security policies and procedures. It isn't possible to do some of the exploits if your company really is careful about who has physical access to devices and actually follows controls for guests and contractors. Sounds silly but your employees are still your biggest strength and weakness in security. Training and rewarding behavior you want as a company goes a long way towards dealing with security concerns.
- Ed