Securing Multiple Device Auth on 802.1X

2 Comments Written by jj on October 22, 2008 – 11:15 pm

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!

# # #

The Real Scoop on Multiple Device Auth with 802.1X

1 Comment Written by jj on October 22, 2008 – 11:12 pm

Part I of the Clearing Up 802.1X Series
Multiple Device Authentication and Mixed Authentication

Pure vs Applied 802.1X
There are a couple of issues mentioned in Mike’s and Richard’s posts  that I’d like to address with the current 802.1X standard (802.1X-2004) as it relates to multiple device authentication.

When I talk about 802.1X with people, I like to distinguish ‘pure’ 802.1X with ‘applied’ 802.1X- meaning, there is both the 802.1X that is a strict formalized standard, and then there is the reality of 802.1X and related standards that mix the ‘pure’ 1X with vendor interpretations and extensions. Below are some examples of use-cases of 802.1X that may operate outside the scope of the 1X current standards.

Applied 802.1X use cases…

• Mixed authentication methods on a port (MAC-auth, Web-auth, 802.1X)
• Multiple devices authenticating per port (VoIP, hubs)
• Authenticated and unauthenticated users on a single port (guest users)
• Device to device (infrastructure) authentication

Multiple Device Auth with 802.1X-Now
Specifically, when we look at multiple device auth on a single port with 802.1X, we’re pretty good with any solution if we’re using 802.1X to authenticate each device individually. Let’s say for example a VoIP phone, with a PC behind it, both using supplicants and 802.1X to authenticate. Pretty easy, straight-forward and very little variance from vendor to vendor.

But let’s say that (as in most organizations) not every device supports 802.1X, so we end up with VoIP phones that are not 1X-capable, and we’re using MAC-Auth for those, with 802.1X for the PCs connected through them… different story.

Mixed Authentication
Why? Because mixed authentication schemes are outside the scope of the pure IEEE standard for 802.1X. Most major switch vendors support this function (by allowing 802.1X mixed with MAC-auth or Web-auth), but they do so with their own implementation and interpretation. It doesn’t always work well, and this is universal for all vendors from what I’ve seen. (Some are more committed to addressing and fixing it than others, but it’s a global issue.)

I would say this would change, but with the expectations of 802.1X-REV coming early next year, vendors and IEEE may decide not to put more effort into a superseded technology. (I think there may be some interest in continuing development and support of 802.1X-2004 since the revision will require a hardware refresh to make use of MACSec/802.1AE).

:::Glossary:::

• 802.1X: Port Security Standard by IEEE (read overview on post here)
• 802.1X-2004: The current revision of IEEE 802.1X
• 802.1X-REV: The upcoming revision of IEEE 802.1X (due in 2009)
• MAC-Auth: Similar to 802.1X in function, but authenticates a device using its MAC address and a directory
• Web-Auth: Similar to 802.1X in function, but authenticates a user in a captive-portal format, using a web browser log-in and authentication usually locally or to a directory
• MACSec/802.1AE: Media Access Control Security, a 2006 standard for layer 2 encryption being rolled into the 802.1X-REV of 2009

:::Links:::

• Mike Fratto’s Post ‘New Protocols Secure Layer 2′
• Richard’s Post ‘Hop by Hop Encryption: Needed?’

:::Next:::

• Part II: Securing Multiple Device Auth on 802.1X

# # #