Some of the major obstacles we face with 802.1X center around creating a smooth end user experience.  We, as integrators, have the distinct ability to make ‘whatever’ work- we find a way. But, what I hear most from my customers is “it has to be easy for the end user.”  (Sometimes they go on a little further, but I’ll leave it at that.)

Why does it matter?

Wireless, wireless, wireless. Although wired 1X is popular with our customer-base, the world isn’t quite flocking to it yet. However, 802.1X is certainly the best way to increase security and ease management of wireless networks. It’s standard, it’s flexible, it’s widely-supported by devices and endpoints and it eliminates the need for pre-shared keys or secondary passwords. It’s what most enterprises, government and educational organizations are implementing now, so it’s important.

What are some of the problems?

The end user will have some adjustments to make, and network admins and support desks aren’t always thrilled with the propect of re-training users for these expectations.

Well, sure you can! There is a little trick now, though.

As part of the move to the Microsoft NAP integration, they’ve broken out the wired and wireless supplicant management into two pieces. Until SP3, all 1X was handled in the Wireless Zero Configuration (WZCSVC) service. The wired 1X supplicant is handled now by a different service and must be manually started.

In Windows XP SP3, the supplicants are each handled separately by these services…
    •  Wireless 802.1X: WZCSVC service
    •  Wired 802.1X: Wired AutoConfig service (DOT3SVC)

Instead of duplicating a lott’a text, you can find detailed instructions for manual and pushed wired 1X configurations on Microsoft KB article 953650.

You can also learn more about Microsoft NAP integration in the Network Access Protection Q&A site.

# # #

Apple splits its 802.1X support into two pieces. There's basic support built into the iPhone 2.0 software, found in the Settings application's Wi-Fi section. Click Other. Click the None label next to Security, and the WPA Enterprise and WPA2Enterprise options appear. Select either, and the main login screen lets you enter the network's name (SSID), a user name, and a password. This basic method is limited to WPA Enterprise and WPA2 Enterprise, the two most common (and most secure) forms of 802.1X.

Most enterprises will want much more control over this process, and Apple provides the iPhone Configuration Utility, currently available in its most complete form only as a Mac OS X application, and in more limited forms as Web 2.0 applications for Windows and Mac OS X.

The utility serves two purposes: creating configuration profiles, including for multiple Wi-Fi networks and VPN connections; and allowing iPhones in an enterprise to run internally developed iPhone software. The Wi-Fi profiles allow you to create WEP or WPA/WPA2 802.1X configurations, and include support for choosing allowed EAP messaging types, configuring authentication elements associated with a given EAP type, and adding server certificates and names for better authentication control.

Once created, these profiles can be distributed throughout a company via email or as a direct download to the iPhone via an intranet Web server. Apple chose not to encrypt them, which means that certain information that's not secured--such as the shared secret for certain VPN connections--could be disclosed to someone who had access to the profile or could download it off the local network.

If you’re planning to, or are implementing wired 802.1X, wireless security and/or NAC, the contents of this blog may save you hours of time and trouble.

Throughout the implementations I’ve done, for both wired and wireless 802.1X, I’ve developed a procedure for implementing and testing 802.1X each step of the way. Following these steps my seem to be tedious and unnecessarily time-consuming. But, if  you’re just starting with 802.1X, I’m offering a way to implement it in phased pieces that will give you the information to test, confirm and troubleshoot at each step.

To be honest, I frequently skip these steps, but I’ve done many 802.1X implementations and can usually hit the bullseye the first time (unless there’s buggy software or firmware- you guys know who you are). But, if something doesn’t work, I start right back at Number 1 here and I follow this procedure.

1) Configure wired 802.1X
First setup the basic wired 802.1X. Ideally, start with a Windows test, using XP SP3 or a later server edition and PEAP. Provision RADIUS, I recommend Microsoft IAS because it’s well-documented and well supported. Even if you have other future plans, if you’re using Active Directory, start with IAS. You’ll need to setup a test RADIUS group and policy and link to AD. Get a test switch, add it as a RADIUS client, and configure it to talk to your RADIUS. Set up some ports for 1X and enable it on the switch. I recommend testing with PEAP as the authentication method and a Windows credential pass-thru. Note- you’ll need to create a server certificate to use PEAP- a self-signed Microsoft cert is fine.

If this simple configuration doesn’t work, you have some troubleshooting options. First, view the system events log in the RADIUS/AD server and look for informational events from IAS. If the authentication request is making it from the client -> switch -> RADIUS, you’ll see something here. The something you see should tell you if the EAP method is mismatched, or if the credentials were wrong, etc. Your second line of troubleshooting comes if you don’t see any RADIUS log activity. If that happens, throw on a packet capture utility like Wireshark. You want to search for 2 things. First look for conversations from your Test Switch to the RADIUS server (filter on IP or MACs). If you see something here, see where the conversation drops off. If that comes up empty, it means the conversation is terminated between the Test Switch and Test Client. I have some neat tricks for troubleshooting I’ll share with you later.

2) Add in Wireless
If you’re planning to implement 802.1X for wireless, now is the time to throw 802.11 in the mix. It’s harder to sniff wireless traffic for troubleshooting, which is why I recommend starting with wired 1X. Keep it simple, and then start layering. Once you have the wired 1X configured, all you need to do is get your AP ready and configure it just as you did your switch- add it as a RADIUS client and configure it to talk to RADIUS. For wireless, you’ll need to configure encryption also. Note, I recommend (for testing) to begin with your primary VLAN.

If your wireless 802.1X isn’t working, follow our troubleshooting above and re-check settings based on the RADIUS event log contents. If nothing is making it to RADIUS, then most likely something is misconfigured in your AP/Controller and the AP isn’t communicating with the RADIUS server. You know the rest of it’s working (RADIUS, AD, Client) so you can narrow your troubleshooting scope. Once that’s working you can stop if wireless is your goal, or keep going if you’re layering on more security.

3) Replace with Custom Pieces
If you’re planning to use a different RADIUS server or a different supplicant, now would be a good time to start swapping out our vanilla configuration with custom pieces. Replace 1 piece at a time and re-test.

4) Add in NAC or Endpoint Integrity
Most NAC or EI solutions will integrate with your 802.1X infrastructure (if you want them to) and can be ‘consulted’ prior to authenticating and opening the secured port. My suggestion is to always get 1X working 100% before you add any type of integrity or compliance testing.

If you follow these steps, you can turn a complex configuration into a set of simple baby-steps. It may sound stupid, but I promise it’ll work for you every time!

# # #

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 fact that they’re such common ‘buzz words’ in today’s IT world makes people hesitant to ask questions. You know we IT-folk don’t like admitting we don’t know everything about anything! However, these are rather simple concepts with extremely complicated components and 98% of the technology world doesn’t really know as much as they’d like to about NAC and 802.1X. You’re not alone.

And so, here’s a short technology primer for you, to give you a little insight into the IEEE 802.1X standard and where it falls into the NAC picture. I said I was going to keep this short, so hang with me here.

What is it?   802.1X is an IEEE standard for Port Access Control, also referred to as Port-Based Network Access Control, but that term gets a bit confusing, so I prefer the former. It actually started about 10 years ago, and has been edited and revised since then to add support for new technologies, including adding some specific attributes for wireless implementations.

What does it do?   With 802.1X you can have switch ports, by default, be closed, or shut off. These ports will then only be opened once a user attempts to connect to the network and has been successfully identified as someone who is allowed access. At this point, we would say that this legitimate user is ‘authenticated’. Until this happens, no standard network traffic passes through the 802.1X port- so whatever is trying to connect will not even get an IP address. No IP address = no network access.

Why would I use it?   In a wired environment, you can use 802.1X to extend some physical or layer 1-type security to the edge. In a fully 802.1X-enabled environment, imagine every edge port is off, and completely inaccessible, until an authorized user attempts to connect through it. It’s a great way to secure edge ports, as well as infrastructure connections. You can use 802.1X to authenticate your network devices to one another, or to the network, and pretty confidently eliminate any chances of gaining rogue devices.

Note that, in reality, 802.1X is not something you wake up one day and willie-nillie enable on every port. You’ll want to start with edge ports in public areas, such as conference rooms, then roll out the rest in phases.

In the wireless world, 802.1X is the chosen authentication method to provide enhanced key exchange and rotation for a more secure wireless experience. In fact, it’s been so widely adopted for this use, that it’s commonly mistaken for a wireless standard (802.11 instead of 802.1).

How does it work?   Without dragging up a bunch of terminology you’re probably not familiar with, let’s talk about a couple of basic concepts. 802.1X leverages (or can leverage) your existing infrastructure. If your switches are 802.1X-capable, then they’re ready to go. How do they know that user trying to connect is legitimate? Your 802.1X switches are talking to your RADIUS server, and your RADIUS server is talking to your Directory (AD, eDirectory, or other LDAP). All stuff you probably already have.

You do need something called a supplicant on the endpoint. A supplicant is just an 802.1X client- it’s built into the majority of newer operating systems, and you also have the option of 3rd party supplicants that can be delivered/installed just like any other client.

Doesn’t sound too glamorous does it?

You’re probably wondering “where’s all the magic?” Well, 802.1X’s special power lies in the Extensible Authentication Protocol or EAP. Earlier, I said until a port is opened, ‘no standard network traffic’ is allowed through. Well, obviously something is allowed through, or else there would never be a means to communicate- that something that’s allowed is EAP. EAP carries information between your endpoint, through the switch and to the RADIUS server.

What about VLANs?   You’ve probably heard we can provision dynamic VLANs using 802.1X and that’s certainly true. That VLAN assignment actually comes from your configurations in the RADIUS server. The RADIUS server sends back information that includes ‘other’ attributes, such as the VLAN and QoS assignments. With the new RFC standards and RADIUS attributes, we can do all sorts of neat-o things.

What you end up with is a pretty secure, and fairly flexible solution- possibly without having to purchase any additional equipment or software.

And what about NAC?  If you’re wondering how 802.1X and NAC fit together, it’s pretty simple. Most of today’s network-based NAC solutions can work in conjunction with 802.1X to provide a robust solution with Layer 2 and up protection. Other NAC vendors that don’t leverage 802.1X are using a variety of Access Control Lists, either on switches, routers, a NAC appliance, or at the host. If you’re using 802.1X with NAC, we’ll generally say it’s Layer 2 NAC (since 802.1X is a L2 standard) and if it’s IP/ACL-based, it’s Layer 3 NAC. Some solutions will let you use a mixture. [Note: Layer 2 is generally accepted as being the more secure solution, but some vendors will try to pour their layer 3 Kook-Aid down your throat.]

That’s all. I’ve certainly grossly over-simplified the implementation of 802.1X. You do have to properly configure the RADIUS server and setup the switches to communicate with it. The list of EAP methods available is an arm’s-lenght long and supplicants aren’t ever as clear-cut as we’d like them to be. However, omitting the technicalities of integration, I hope you now have a better idea of what 802.1X is, how it works, and why you’d use it.

If you’re a glutton for punishment, I do have a fairly lengthy presentation I put together with a technical dive into 802.1X. If you’re interested in seeing that, email with (form on left) or post a comment (below) and I’ll send it your way.

# # #

Folks, there are fundamental differences between names, which are public claims of identities, and authenticators, which are secrets used to prove identities, and I've written extensively about this before. An SSID is a network name, not -- I repeat, not -- a password. A wireless network has an SSID to distinguish it from other wireless networks in the vicinity. The SSID was never designed to be hidden, and therefore won't provide your network with any kind of protection if you try to hide it. It's a violation of the 802.11 specification to keep your SSID hidden; the 802.11i specification amendment (which defines WPA2, discussed later) even states that a computer can refuse to communicate with an access point that doesn't broadcast its SSID. And, even if you think your SSID is hidden, it really isn't. Let me explain.

All 802.11 wireless networks, regardless of the kind of operating system or encryption you might use, also emit unencrypted frames at times. One kind of unencrypted frame is an association frame. This is what a client computer, or "supplicant" in the 802.11 protocol vernacular, emits when it wants to join a wireless network. Contained within the frame, in clear text of course (since the frame is unencrypted), is the SSID of the network the supplicant wants to join.

Both Windows XP and Vista work best when your access points broadcast their SSIDs. XP really doesn't behave well at all with nonbroadcasting SSIDs. Vista has some added smarts to improve this a bit. Normally, Vista continually sends probe requests for nonbroadcasting networks. These probes are similar to unencrypted 802.11 association frames, and will generate clear-text responses from the access points if a nonbroadcasting network is present. You can reduce, but not entirely eliminate, these probes by configuring the wireless client to probe only for automatically-connected nonbroadcasting networks.

Both these behaviors make it very easy for an attacker to discover your SSID. The bad guy, perhaps a contractor or a guest in your facility, could run one of many wireless sniffer programs and simply capture the hundreds of association frames or probes that litter your air. No amount of "hiding" configured in your access points can prevent this kind of traffic interception.

So there you have it, simple SSID discovery. The old axiom remains true: security by obscurity is no security at all. Hiding an SSID will not hide a wireless network, so ignore any such advice -- and it's amazing how often I continue to see this. By the way, also ignore any advice that says to use MAC address filtering. It's amazingly trivial to spoof the MAC address of an allowed supplicant -- simply sniff the traffic, look at the MAC addresses, and use the neat little SMAC utility to change your MAC to one that's permitted.

Nonbroadcasting networks are not secure networks. The right way to secure a wireless network is to use protocols that are designed specifically to address wireless network threats. If you're still using WEP, either static or dynamic, I encourage you to move to WPA2 as soon as possible. For those of you at home running XP and have kept it updated, or if you're running Vista, then, you simply need to enable WPA2. We've got some additional guidance for home/small offices and for enterprise networks with certificate services or without. If you have hardware that's more than two years old and you can't upgrade it, check to see whether it supports WPA (an interim specification released before WPA2 was ratified). Both WPA and WPA2 are built on sound cryptographic principles, they're proven in the field, and they'll keep the bad guys out -- even when you're broadcasting your SSID to the world.