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!

# # #

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

# # #

By this point everyone seems to refer to me as ‘The 1X geek’, probably because of my evangelical technical overviews and implementations of the standard. I s’pose because of this, in the past week several folks have asked me to check out recent articles by Mike Fratto (New Protocols Secure Layer 2, October 4) and follow up blog by Richard at Tao Security (Hop by Hop Encryption: Needed?) about 802.1X and the upcoming revision of the standard due in 2009.

I can tell you Mike always does his homework, and those of us interested in 1X get our technical details straight from the horse’s mouth, so to speak. Mike is no exception and I’m always comfortable referring readers to his blogs and articles for information.

To answer the questions I’ve received, I’ve put together a few bite-sized snippits of information on both the current 802.1X standard, its use with multiple device auth, its use with mixed authentication and the upcoming 802.1X-REV…

The Clearing Up 802.1X Series Begins…

• Part I: Pure vs Applied 802.1X,  Multiple Device Auth & Mixed Auth
• Part II: Securing Multiple Device Auth on 802.1X

 # # #

Unless you already knew me (pre-blogging) you probably don’t know I had one grandmother who went on to better places after our horrible struggle with Lou Gehrig’s Disease years ago. But that’s a whole ‘nuther discussion. What’s today about?

My second grandmother (and only living grandparent now) is suffering from another, more common, affliction - Alzheimer’s. In recognition of her great achievements, and in support of the other millions affected by this disease, we have gathered the troupes and are participating in the 2008 Memory Walk.

Our team of about a dozen family members and friends will pound the pavement this Saturday, October 4th in Cary, NC in an effort to do our part!

Now, I will shamelessly ask for your support!

If you feel so compelled and want to join us, or donate online, PLEASE DO! Here’s how…

• My Donation Page - JJ’s Memory Walk page
• Our Team Page - ’Forget-me-nots’ 

I have a dream, I have a goal and I think I have lots of really great readers who will throw in some love and donations. Even $1.00 or $5.00 is GREAT.

Granny Boop!

Here’s a photo of our Granny Boop with my cousin, Meredith, my Mom and me. (I think she looks mad because we took her chocolates away for the photo!)

Click Here to Donate
 

# # #

Coming…
Thursday, October 16th to
Raleigh, NC

Our company, Carolina Advanced Digital, is a Platium Sponsor of this year’s ISSA InfoSeCon 2008 in Raleigh, NC. Come see us, meet our new folks and hear my talk on ‘Network Security Stripped’.. it’s the only scheduled North Carolina presentation of this talk!

Also, don’t miss Raffy’s session on “Insider Threat, Governance, Risk, and Compliance (GRC), and Perimeter Threat” at the same event. Visit Raffy’s blog…

Registration is Open!
Online registration from $30/person
http://www.TriangleInfoSeCon.com

# # #

Next week, I’ll be unleashing “Network Security Stripped: From layered security to bare essentials” at the SecTor conference October 7-8 in Toronto.

It’s bound to be a great event- with keynotes by Johnny Long and Stepto (Stephen Tolouse) and sessions by the Hoff (with his Four Horsemen, My Little Pwnie Edition - don’t ask), HD Moore, Josh Perrymon, Bruce Potter and.. well you can read the whole roster of speakers yourself.

And I have to go first… why do I have to go first… ? *sigh  

SecTor
October 7-8, 2008
Toronto, ON
http://sector.ca
http://sector.ca/schedule.htm 

# # #

A flurry of conferences intertwined with customer emergencies have taken me ‘out of pocket’ for the past month or so.

You know it’s serious when I have to cancel my trip to INTEROP… I’m traumatized by that, btw.

What have I been doing? 

The Conferences… Well, after the ILTA Conference in Texas (the hotel was gorgeous, by the way), I returned on a Tuesday evening only to be diverted directly to a customer site for the remainder of the week. After that, a few con calls and customer meetings, followed by SCITDA in South Carolina where I delivered a ‘Network Security Trends’ talk and participated on a Security Panel (with McAfee, Juniper, Cisco and others) later in the conference.

The Other House… As soon as I returned from SCITDA, the next few days were spent over-seeing the replacement windows going into the rental property. A few windows here, some sheetrock there, more painting than I really cared to do… and we were in business.

It’s been an on-going project… Over the past year, the house has been completely repainted (inside and out), all the hardware (doorknobs, fixtures) as well as lighting and outlets/switches replaced.  The master bath was redone with new tile and a new vanity with custom bowl sink and faucet. In addition, the third-acre lot was mostly cleared- from ‘couldn’t-see-the-back-fence’ to ‘wow-there’s sun-light’.  The dark (ugly) wood floor-to-ceiling fireplace surround was removed and sheetrock put up. After a guy ran over (and crushed) the draining system, that had to be replaced also (I have a friend to thank for redoing that, I wouldn’t have known where to start). Oh and, last month the roof was redone too, making the windows the last major project for a while (I hope). The roof and windows were the only parts contracted out… if that gives you any idea as to the volume of work I’ve done on the house. Maybe I’ll share some before and after photos…

And now, I still have more customer projects to complete, more product evaluations and reviews to write and of course… more conferences coming up. Plus, I have a sink to fix and a water heater to drain… (uggg).

Next on the list is SecTor… more on that soon.

So, while I probably could have found 5-10 minutes to write something, the days have been long and tiring. The chances of an even mildly-coherent post were slim to none (at best).

# # #

Some of our other online friends at ILTA…

• Jenn Steele
  “Best Practices in Professional Development in Law Firms” panel, Mon
  “Business Continuity Technologies that Work for Law Firms of All Sizes and Shapes” panel, Mon
• David Hobbie
  “Matter Intelligence: Leveraging Information Over The Matter Life-Cycle” , Tues
• Doug Cornelius
  “Experience Management - Case Studies in Tackling a Difficult Challenge” panel, Mon
  “Wikis in Law Firms” panel, Mon
• Official ILTA 2008 Blog

If you’re at ILTA, please stop in and say hello! I’ll be arriving Sunday I believe, to attend the speakers meeting and floating around Monday.

# # #

What exactly am I yapping about? Well, today Tim at Network World posted a nice article on the growing adoption of 802.1X. Shortly after, Alan jumped in with his post on ‘Is 802.1X in Your Future?’. You can see my notes below, and I definitely recommend reading the original articles.

• Eins: Easier implementations

I certainly don’t think 802.1X is getting easier to implement. The problem with rolling out 802.1X successfully, is that it requires in depth knowledge of a) your current network, including all VLANs, routing and physical connections b) your planned network, and yes there is a migration period just like any other upgrade c) authentication, secure communication and/or certs and d) all things layer 2 and 3. With 1X, you’re segmenting, authenticating, routing and securing. If you don’t understand each and all pieces, then *fail 1X.

To make matters worse, most vendors don’t have a solution for ‘good’ central management of heterogeneous switch environments, making 802.1X still a very manual process, even if you understand the concepts. I don’t see this getting easier- it’s just becoming better-understood, which is all we can ask for at the moment.

• Zwei: 50% adoption of 802.1X

Asking a crowd of people if they plan to implement 802.1X by XX year is like asking a room of 6-year-olds “who’s wants to be a firefighter when you grow up?” They (most likely) have no concept of what’s involved with 802.1X, or the trials and tribulations associated with client and authentication configurations. Sure, it sounds good… but… really? After a half-day training, if you asked the same group, I wonder how many hands would go up.

• Drei: No supplicant needed

I have to disagree with the notion that Cisco and Juniper just want to ’sell more supplicants’. I mean, of course they do- but if the OS-integrated supplicants covered our needs, neither company would have invested ginormous amounts of money in their Meetinghouse and Funk acquisitions.

The truth is, many (or even most) organizations today do not need 3rd party supplicants, but they sure make life a lot easier, especially in the cases of multi-user profiles, multi-location profiles and environments where a shim is needed (such as the GINA shim for Novell clients). If you’re all Microsoft, you’ll get little benefit from a 3rd party supplicant- which is one of the reasons Tim and Joel have hit the nail on the head when they say Microsoft is ‘leading in NAC’… yes, because they make it easy and it works.

• Vier: Variance of switch vendor support

Okay Alan, I’m agreed here ~sorta. Switch vendors vary drastically in their support of 802.1X-ish-features. But, the real difference is not in the implementation of the standard-specified 802.1X functions. The differences come in the ‘off-RFC’ features, such as mixed authentication, null VLAN returns and MAC-auth. These items are not specified as part of the true 802.1X specs and RFCs, so vendors are left to ‘do as they please’ with these features. Because of that, you’ll see huge variances from vendor-to-vendor and even firmware-to-firmware. I know this because I’ve personally taken packet captures and reviewed them along with configurations in vendor labs with their dev teams. You’ll be hearing more about off-standard functions from me soon. This area of 802.1X demands a lot of attention and patience.

• Fünf: Switch upgrade required

Tim, I do want to point out that 802.1X has been around since about 2001 and has been supported in switches for several years. I have done a variety of 1X implementations, even on old crappy switches and wireless access points and they support 802.1X. In fact, I can’t say I’ve hit a customer that had to buy new switches for 1X. I have some Cisco users that need to upgrade firmware to take advantage of the newer 1X, Mac-Auth and Web-Auth support, but that’s the most extreme case so far. 

• Sechs: The REV is a’comin’

All these numbers, predictions and speculation will be tossed to the wind once the new 802.1X-REV is released. Its configuration and implementation will be so different from the 802.1X we know today that customers will have to re-learn the technology before making any decisions. The REV is expected out in early 2009. The good news may be that the new REV offers so many fun new features that the 802.1X adoption rates may actually be even higher with the new version. But for now, adoption statistics of current 1X into 2011 is really a moot point… it won’t be around.

So I have to disagree on a few points, but overall I agree (and I hope) 802.1X-adoption will continue to rise. If not, I need to start looking into other things… like reading up on my IDS management.. (oh wait- IDS is dead- nvm)

Don’t ask me why I went with German numbers today… there’s just not a good answer. Hopfully they’re all spelled correctly and I didn’t curse a goat or anything strange.

;)

# # #

Oh, who knows… but people have asked my opinion, so I’ll share my thoughts, musings and speculations with the masses.

You can find more information and read my initial reactions in Andrew’s write-up of the CRN release ProCurve’s Colubris Buy A ‘Great Move’

Background. ProCurve, HP’s networking division, has had great success in the layer 2 and 3 switching market, with particularly nice results in their 10GbE products and their new ‘core’ 8212 switch. They’ve even added several security offerings to the portfolio, including their NAC 800 appliance and NBAD and flow analysis product- Network Immunity Manager. But, there was no debating they’ve been lacking in their wireless offerings…

With a couple of standard single- and dual-radio heavy access points and the newer light-ap WESM (wireless edge services module) system- their wireless portfolio certainly hasn’t been the most well-rounded. ProCurve’s move to purchase a wireless vendor was surprising, but not shocking. While ProCurve has OEM’d and purchased technologies from other vendors, I think this marks their first-ever acquisition of another company.

The acquired. Colubris has a strong presence in areas with wireless overlays, such as medical and especially hospitality markets. In these environments, the wireless solution is simply layered over the wired infrastructure, usually completely segregated and certainly managed independently of other systems.

What will be interesting to see is the adjustment of the Colubris teams and partners from a technology ‘overlay’ to a technology ‘integration’. Joining wireless with the networking components and the integrated planning will be something new to all these folks. On the flip side, the ProCurve partners will all have much to learn in the way of Colubris’ product line, new 802.11n products and the planning and power accommodations for them all.

For customers. I’ve been in the channel for a loonnnng time. There are a few expectations and patterns when it comes to time lines and product line integration after an acquisition. When the deal is done and the ink has dried, we expect to see the acquired products (Colubris) being sold under the new brand (ProCurve), but usually with the same part numbers, in just a matter of days or weeks after the fat lady sings. *Note the press release wording “…has signed a definitive agreement to acquire Colubris …”  meaning there will be a period before it’s finalized.

Then there’s the adjustment and product integration period. Usually in 9-18 months, we see the new products either modified or integrated into the new brand. Understanding wireless and the current ProCurve modules, my guess is that the Colubris line will be integrated into the ProCurve portfolio, similarly to the current WESM modules. I seriously doubt the legacy products will be interoperable with the acquired lines- the time and money for R&D to pull that off would greatly outweigh the benefit of it. I would, however, expect ProCurve to have centralized management through their Mobility Manager (or similar) product by the time of portfolio integration.

Customers shouldn’t worry about their current ProCurve wireless purchases. I’m sure like any good manufacturer, when the time comes, ProCurve will offer its customers a nice trade-up program if they want to move from the legacy products to the new integrated Colubris line.

When? I don’t know… We’ll be looking for more information from ProCurve when the deal is done.

# # #