I run into two fundamental problems when I start to talk to customers or audiences about Network Access Control and its related standards and protocols. What are they? Number 1, most folks have no clue what 802.1X actually is. Number 2, for the most part, they don’t really understand what NAC is either.
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.
# # #