For June, we have an 802.1X hat-trick to blame for my slack blogging habits. Over the past few weeks, I’ve had back-to-back 802.1X implementations, one wired, one wireless and one with both. Two government customers and one commercial, not in that order. And I even did one semi-training-slash-semi-implementation-quick-start for another customer.

It’s been fun, but 1X is always challenging. The variety of components, the nature of the interactions and the ‘newness’ of actual implementations make it difficult to work from any type of cookbook or implementation guide. There are just too many variables.

When will it be easier? I think as 1X is more widely implemented in the real world, customers will become more familiar with the concepts and integrators will have more experience to make it go smoothly. For now, everyone has to just take it one step at a time and address issues as they arise. And, for now, I’ll enjoy the job security that 1X offers ;)

Luckily, I’ve had the opportunity to work with a variety of customers and a variety of environments and equipment while hammering out 802.1X. The experience and exposure has certainly given me a unique insight into the issues, complications and solutions that come along with a 1X project.

At present, I think we’ve successfully configured 1X on about a dozen different types of equipment, both switches and wireless APs and controllers, from a variety of vendors. It may not sound like much, but in the world of 1X, that’s quite a variety when you consider each manufacturer has their own ‘system’ for configuring 1X and the commands and procedures can vary greatly even from product-to-product from the same vendor.

Is the 1X streak over? Not at all. We have several customers with NAC and 802.1X projects that we had to queue up for after June 30. I’ll keep you posted!

# # #

Understanding the difference between a NAC Client and an 802.1X Supplicant can save you much time, confusion and - yes - MONEY.

How does it save money? I figured most of you would glob on to that one first- hang on, I’ll get to it in a minute ;).

NAC Clients. Most network-based NAC vendors, such as Cisco, Juniper, StillSecure and ProCurve have some type of NAC Client or Endpoint Integrity Agent provided as part of their NAC solution. The NAC Client is a software agent that sits on the endpoint and collects statement of health or posture of the endpoint and communicates that back to whatever NAC controller you’re using. (Most of these guys offer some type of agent-less or transient-agent posture checking too, but this doesn’t apply here.)

The NAC Client may also provide additional security functions such as host enforcement or it may serve as an encryption termination point for IPSec tunnels created between the endpoint and a firewall, for example. I’m sure we’ll be seeing more and more bells and whistles added to the NAC Clients as time goes by.

802.1X Supplicant. An 802.1X supplicant is a different creature all together. First of all, it’s worth noting a supplicant can exist as a piece of software on an endpoint, or as part of an infrastructure device, including switches, APs and even printers. On an infrastructure device, the built-in supplicant lets us do things like authenticate switches to one another for maintaining integrity of network devices and prevent rogues from joining the network.

If the supplicant is on a PC or laptop, it may be built in to the operating system, or provided as a 3rd party software. The supplicant is what communicates through the switches to the RADIUS server for authentication and ‘speaks EAP’. EAP, the Extensible Authentication Protocol, is what makes 1X. Generally a supplicant’s only function in life is to speak EAP and get the device authenticated to the network.

What you may see from some vendors, such as Juniper, is an integrated NAC Client with a built-in Supplicant. Juniper’s Odyssey Client bundles both functions in to 1 agent.

Okay, so back to the money… Understanding what does what, and what comes from where is helpful when we start talking dollars. In many cases you’ll end up paying separately for the NAC Client licenses and the Supplicant licenses. You won’t have to pay for both if…

1. If the NAC Client and Supplicant are bundled
2. If you’re using the Supplicant integrated with the OS or 
3. If you’re using an open source Supplicant
4. If you’re not 802.1X with your NAC, and of course
5. If you’re not using NAC on top of 802.1X

Some vendors may offer a pricing advantage depending on what you’re planning to do. We started with two main Supplicants a few years ago- Meetinghouse’s Aegis and Funk’s Odyssey Access Client. What happened to those guys? Cisco bought Meetinghouse and now offers the Aegis client as an option with their solution and Juniper bought Funk and integrated the Odyssey Access Client directly into their endpoint integrity agent. Most likely they want to try and recoup some of the money from those acquisitions, so what that means for you is that you will likely pay money for products containing those technologies.

On the other hand, some of the home-grown technology from the NAC side may lessen the budget burden. Cisco’s endpoint integrity agent is actually included with their NAC solution, so they don’t charge any per-seat fee (unless you add 802.1X). Juniper’s is integrated, so you’re getting both functions regardless. You can probably spot companies that OEM another solution or another client if they charge for the NAC Client license… that’s not definite, but a good rule of thumb.

From a deployment perspective an bundled agent (NAC + 1X) is nice, since it means you only need to download 1 piece of ‘thing’ onto the endpoint. From a budget persepctive it can be good or bad- it really depends on how many licenses you need and how willing your vendor is to work with you on price.

# # #

The answer to this is usually “yes and no”. I know, helpful, right?

The first thing we have to understand before answering is- is this a completely light AP solution, or is it ‘semi-light’. These are my terms and each manufacturer has their own verbiage they’ll use, but the concepts are the same.

In a completely light AP product, the controller has the brains, and the APs are dumb. For all practical purposes here, the APs are just radio antennas. They know nothing, and every packet is sent back through the controller for processing. Generally a fully light AP will not even have an IP address.

With a semi-light AP product, the controller does most of the work (usually anything routed or not local) and the APs have enough sense to process local traffic.

Scenario. Imagine a controller at a central office, connected to a light AP at another location (across the WAN). If it’s a completely light AP, it will send every bit of traffic over the WAN, to the controller. Not a great idea if you have medium-heavy wireless usage and a small WAN pipe. You’ll find you can quickly eat your bandwidth with your wireless traffic. If it’s a semi-light solution, the AP can process local traffic, for example a wireless user that wants to send a print job locally.

Processing local requests at the AP cuts down on the amount of traffic that has to traverse the WAN and is generally the way to go if you want a single central controller and remote APs.

If you decide you just have to run a completely light AP solution across the WAN, be sure your pipe is big enough and your usage low enough to support that configuration. Note that ‘big enough’ and ‘low enough’ are always relative and you’ll need to do a little experimenting to get the right threshold for your environment.

# # #

If you have no clue what 802.1X is, read my recent technology primer first. If you’re already familiar with 1X, you’ve probably heard about some of the 802.1X additions- the 802.1AE (MACSec) and possibly 802.1af (the key agreement for MACSec)… but that’s just the tip of the iceberg, and what’s hiding underneath will knock your socks off!

We’re currently at the 802.1X-2004 edition, with the group working on the REV and hoping for an early-2009 release. When IEEE makes additions (such as AE and af) they’re just afterthoughts and changes tacked on to the end of the standard. But when they do a revision , as they are now, they’re opening up the whole can of worms and all parts of the standard are opened for evaluation and modification. Yee-haw!

So, what’s in this new revision and what can we expect from 802.1X-REV? That’s what I wanted to know, and I’m sure you’re curious too. I was lucky enough to catch a quick call with Paul Condon earlier this week and get some of the inside scoop. Paul is ProCurve Networking’s CTO, but more importantly for our purposes today, he’s the Vice -Chair of the IEEE 802.1 working group and is intimately involved in 1X and a variety of other networking, security and authentication standards.

1) Encryption & Key Exchange : The first goal in updating 802.1X was to add security with encryption, specifically on switch-to-switch links. Of course, with encryption comes the need for fast, secure key exchange, so we ended up with 802.1AE and 802.1af as answers to the first set of goals. The encryption will require hardware refreshes, and vendors are already gearing up for that. The benefits of encryption are pretty obvious, so I won’t bore you with that. There are some fun little gems hidden in the AE/af set though. Even without using the encryption piece, we’ll be able to use the key exchange as a means of quickly (in ~4-5 packets) authenticating (or re-authenticating) switches to one another after a reboot. It will be a critical piece for maintaining availability and integrity in the network. And w e can do this piece without a hardware upgrade, which is pretty nifty.

2) Same-Port Multiuser Support: Here’s where the 1X-REV sauce starts tasting really good. The new revision is leveraging some of its security updates to support multi-user modes on a single port. And no, not by using multi-tagged VLANs, this is way cooler than that. In theory, multiple PCs, phones or other connected devices can connect through a single port, which would essentially be running multiple instances of 802.1X, letting each communicate securely. It’ll be similar in practice to how wireless APs segregate and encrypt traffic between the AP and the endpoint. I’m sure at first we’ll see software-based endpoint encryption support and of course, move towards hardware encryption and see NICs with the capability baked in. That’s still down the road, but the road is getting shorter.

3) Network Advertisement/Selection : Now the 1X-REV sauce is the best you’ve ever had- you’re gonna want to put this stuff on everything ! :) The 3rd goal of the revision is to add support for network advertisements on the wired side- which would be a similar experience to selecting the wireless SSID from a list of ones available on your laptop. But, it’s happening on your wired switch. Wild, right? They’re going to leverage the EAPOL types here to communicate from client to network. Imagine the possibilities…

All these new functions and features give 802.1X numerous new use cases. I think you’ll see parts of these technologies leveraged in various parts of critical networks everywhere. Sponsor ballots come at the end of the year, and they’re hoping to see something solid and released in early 2009.

You can see why I’m excited. The 802.1X-REV may be the evil stepchild for a while, but it’s coming. When it does, it’s going to rock our little network worlds and flip our thinking about wired security and network segregation upside down.

Of course, you’ll be seeing more on this from me, so hang in there!

# # #

Last week I came down pretty hard on Air Defense (here and here) for phishing WAPs at the InfoSecWorld trade show. Well just to show you that sometimes people make mistakes and if you blog it, you may get it addressed, I wanted to share the following email that I received today. I have redacted out the names to protect the innocent and the guilty.

Alan,

Let me start by first apologizing for any inconvenience I might have caused you or any other vendor at InfoSec World. You can be assured that next time I will collect alarms in the privacy of my own home prior to going to a convention.  I setup a test box during the vendor setup on Monday, this is a tool we use to show some wireless attacks.  After about an hour I shut it off, I was using it to gather some historical data to show in Advance Forensic.  If I recall correctly it did run it for about 5-10 minutes the 2^nd day after the demo crashed and we lost the data I collected on Monday (plug was kicked out).  This was very brief and not intended to be harmful. 

The intent behind using the page with AirDefense was in case anyone who saw the page could at least ask us why it happened and we could apologize and explain that it was just temporary.  JOHN DOE, the gentlemen you spoke with, was not aware of my actions nor was anyone else from AirDefense. I did ask him to point you out so I could apologies and let you know it should no longer be a problem but he didn???t see you.   I unplugged the test box just in case it was still doing something behind the scenes.  Once again I do apologize for any issues I may have caused.  If you have any questions or comments please feel free to call.  Also thanks for making us aware that it may have still been phishing people off their APs.

Thanks,

So to this Air Defense engineer, I take you at your word and apology accepted.  I am glad to hear that Air Defense does not condone this as a legitimate trade show tactic. Go in peace and sin no more ;-)

Last week I came down pretty hard on Air Defense (here and here) for phishing WAPs at the InfoSecWorld trade show. Well just to show you that sometimes people make mistakes and if you blog it, you may get it addressed, I wanted to share the following email that I received today. I have redacted out the names to protect the innocent and the guilty.

Alan,

Let me start by first apologizing for any inconvenience I might have caused you or any other vendor at InfoSec World. You can be assured that next time I will collect alarms in the privacy of my own home prior to going to a convention.  I setup a test box during the vendor setup on Monday, this is a tool we use to show some wireless attacks.  After about an hour I shut it off, I was using it to gather some historical data to show in Advance Forensic.  If I recall correctly it did run it for about 5-10 minutes the 2^nd day after the demo crashed and we lost the data I collected on Monday (plug was kicked out).  This was very brief and not intended to be harmful. 

The intent behind using the page with AirDefense was in case anyone who saw the page could at least ask us why it happened and we could apologize and explain that it was just temporary.  JOHN DOE, the gentlemen you spoke with, was not aware of my actions nor was anyone else from AirDefense. I did ask him to point you out so I could apologies and let you know it should no longer be a problem but he didn’t see you.   I unplugged the test box just in case it was still doing something behind the scenes.  Once again I do apologize for any issues I may have caused.  If you have any questions or comments please feel free to call.  Also thanks for making us aware that it may have still been phishing people off their APs.

Thanks,

So to this Air Defense engineer, I take you at your word and apology accepted.  I am glad to hear that Air Defense does not condone this as a legitimate trade show tactic. Go in peace and sin no more ;-)