Securing Multiple Device Auth on 802.1X

Part II of the Clearing Up 802.1X Series
Securing Multiple Device Authentication on 802.1X

VLANs and Multiple Device Authentication
I always say the road to insecurity is paved with good intentions, and implementations of 802.1X are some of the best examples. I find folks tend to be so excited if-and-when they get 802.1X working, that they don’t bother to put it through the ringer and see what’s actually happening on the switch once it’s working.

When implementing multiple device authentication on a single port with 802.1X, there are *lots* of considerations, but one major one I see from a security perspective.

I’m giving an example of issues and best practices with multiple device authentication using a VoIP scenario because it’s the most common use of multi auth, and probably the single largest vulnerability point because of accessibility to phones in an organization.

A VoIP Example
Let’s imagine a VoIP phone with the standard PC data pass-thru on the back… most VoIP phones have this and it’s the best way to make use of data drops when you have a converged network.

*click image to enlarge

If you’re reading this blog, you should immediately know what this means. If not, I’ll try to talk it through. In enterprise environments with VoIP, we use a protocol called LLDP-MED and/or DHCP scopes to tell VoIP phones where they should be on the network, and let the infrastructure identify them as phones.

So, a phone will hop on the network, get it’s DHCP information and then be told to go to it’s Voice VLAN (let’s say VLAN 200 is Voice). During this process, the phone is actually communicating initially on the default Data VLAN  (let’s say VLAN 1) to get the scope information.

In this configuration, the Switch Port (shown above) will be untagged for the Data VLAN 1 and tagged for the Voice VLAN 200, to allow the phone and PC to access the data network and then the phone to access it’s Voice network.

The Issue
With an 802.1X-enabled port, the phone will actually authenticate (however it does that, either Mac-auth or 802.1X) on VLAN 1 (our default data VLAN)… then once it receives its scope parameters, it will move to VLAN 200.

On most switches, when it does this, it leaves VLAN 1 ‘open’ and authenticated. So, it would be easy for a malicious user or guest to easily access our data VLAN from anywhere they can find a phone, even though we have port security turned on.

The Resolution
There are a couple of solutions here, but they all require planning and perhaps a bit of ‘creative’ routing or network segregation.

1. One resolution is to create a trash or ‘black hole’ VLAN as I call it. This would be a VLAN to nowhere… and that would be the configured default untagged VLAN on the switch ports (either all of them, or the ones exposed to this environment).

If you go this route, there are a couple of things to address- you’ll need to create a path for your phones to be able to access their DHCP server so they can receive scope info and get on the appropriate VLAN to operate. You also have to think about your migration path from an unauthenticated to authenticated network. Generally we recommend customers moving to 1X to use null VLAN assignments to activate whatever current VLAN is untagged on the port (to accommodate current network design). If the port is untagged for a black hole VLAN, you’ll need to actually push ‘real’ authenticated VLAN assignments down (from RADIUS or your NAC solution) for every user.

2. A Second idea would be to use either the guest VLAN or a quarantine VLAN as the default untagged VLAN on the edge ports. This would give some immediate but limited connectivity.

Again here, we have a few issues. Currently, most switches do not support unauthenticated devices and authenticated devices on the same port, meaning the guests would have to be *somehow* authenticated- perhaps with Web-auth on a true Guest VLAN (versus the 1X-specified ‘unauth’ VLAN). (There are also some tricky things you can do with a good RADIUS server to get around this.)

If you think this sounds a little confusing- you’re right. There are lots of terms in 1X that may ‘seem’ to intuitively mean one thing but have a very specific meaning within the confines of 1X. The unauth-VLAN is one of those terms.

And, of course, with a quarantine or guest VLAN we have the same requirement to allow the phones access to resources they may need.

The Conclusion
Multiple device authentication can be tricky to secure, but it’s certainly possible with the current 802.1X version. I always suggest beating the ever-loving crap out of 1X configurations in a lab before deploying. Try things, allow authentication, the use your switch ‘show’ commands to watch the port behaviour and see what’s actually authenticating, what’s ‘open’ and what residual effects may cause issues in security.

The Future
Of course, the ease of multi-device authentication and the security of it all will greatly increase with the 802.1X-REV. I certainly don’t want to dimish the importance of the new 1X revision- the MACSEc (802.1AE) and key exchange (802.1af) rolled into the revision will bring about great new horizons!

# # #