If there was ever a network security standard destined for widespread adoption, IEEE 802.1X would seem to be it. Published in 2001, and later revised in 2004, 802.1X is a specification for port level access control based on the authentication of network users and systems, essentially denying unknown users and untrusted systems access to internal LAN networks and resources. 802.1X thus solves a widely known problem that network administrators face as organizations open up their internal LANs to guests, contractors, and employee-owned systems through an expanding number of network access points.

IEEE 802.1X is widely supported by the vendor community with features available in virtually every relevant enterprise-class network hardware and directory server implementation for the past several years. While 802.1X has been widely deployed for wireless gateway access controls, the number of actual wired 802.1X deployments, for which it was originally intended, remains relatively small, however. Data from leading analyst organizations indicate that only a few percent of enterprises have rolled out 802.1X wired for their network authentication and access control framework. Annual predictions for widespread adoption of 802.1X are now becoming reminiscent of annual predictions for "The year of PKI" (public key infrastructure) from 1995 to about 2002, at which point people got tired of waiting. Something appears to be seriously amiss in user land. Where are all the wired 802.1X deployments?

First, Some Background
Formally known as the "IEEE Standard for Local and Metropolitan Area Networks - Port Based Network Access Control", 802.1X-2004 specifies three things: a model for authorization, a communications channel for authentication, and an enforcement point. 802.1X participants can play one of two roles, that of an "authenticator" that guards entry to the network, or that of a client, the "supplicant," that is trying to gain access to the network. Think of the authenticator as an all-or-nothing on-off switch. Until the port is "authorized" it is "closed" and only accepts local authentication handshakes with a supplicant. Once the port is authorized it is "opened" so that all traffic can flow.

It is important to recognize that 802.1X defines how to carry authentication information back and forth but does not specify the actual authentication mechanisms. In other words, it is not a complete authentication scheme in and of itself, but relies on other standards to specify how users actually get authenticated. Leveraging work done for other protocols such as PPP, 802.1X uses the Extensible Authentication Protocol (EAP), the model for which can be found in IETF RFC3579. So, 802.1X actually defines just the "EAP over LAN" (EAPOL) frames that carry EAP messages between the supplicant and authenticator. It also recommends, but does not mandate, use of a back-end AAA protocol, such as RADIUS, for communicating with an authentication service. This back-end authentication server may or may not be on the same platform as the authenticator, but usually isn't. Conveniently, RADIUS can carry EAP frames as attribute values, and so for practical purposes 802.1X specifies how to take EAP request frames from the client, send them along to the authentication server, and get back response frames to pass along to the client.

In virtually all cases, though, the actual authentication exchange happens between the client and the AAA server. When all goes as planned, the server tells the authenticator when the exchange is done. It tells the authenticator whether the user is acceptable or not, and depending on the outcome, some attributes for the session, such as the VLAN or port ACLs.

Expected Benefits of 802.1X
802.1X can provide a cost-effective way to implement role-based network segmentation, allowing, for example, guests and contractors access to only a limited portion of the network, whereas employees can access all internal applications and servers. Typically, the network access restrictions (policies) are enforced through VLAN steering. This may be ideal for a guest network service, but more than a small number of different roles will require corresponding VLANs and will quickly make the roll-out much more complicated and costly to manage going forward. Successful 802.1X deployments have generally focused on primarily a guest versus employee delineation to keep the project manageable. If more complicated roles are required, other role-based access control systems have a much greater chance of succeeding and greater overall return on investment.

Another primary driver of 802.1X implementations is the need to prevent unauthorized systems from spreading malware throughout the internal network. Indeed, a recently published case study from a leading analyst organization cited one company's 802.1X implementation after a copier repairman connected his laptop to an available port and infected the entire network with the Blaster worm. Forcing an unauthorized user into a guest VLAN would at least contain the outbreak, even if nothing in 802.1X specifically addresses malware threats. This may or may not be a desirable approach since the entire guest VLAN could quickly be infected. This is an issue also with many of the network access control (NAC) appliances that rely on VLAN quarantine for non-compliant endpoints. Superior solutions exist that block user traffic right at the access port, eliminating the need for multi-user VLANs, and preventing the spread of malware between systems completely.

The Challenges to 802.1X Success
As we have seen though, few organizations are able to achieve these realistic 802.1X capabilities. There are a number of interoperability, scalability and management challenges that need to be addressed. Organizations that elect to deploy 802.1X should be prepared with a 'Plan B' since many early adopters of wired 802.1X have been unable to overcome the interoperability challenges.

The primary interoperability issues come from the multiple moving parts that all have to come together for a user to be properly authenticated and then to enforce the access decision at the policy enforcement point (PEP), generally an access layer switch. It's impossible and unhelpful to point fingers at why interoperability challenges persist despite a well-backed standard. As is typical with standards-driven products, the theoretical specifications never seem to fully anticipate the practical realities of real world implementations.

Most organizations considering 802.1X will consider using the 802.1X supplicant (client) available from Microsoft, which is bundled with Windows 2000 and later operating systems. Getting the Microsoft supplicant to work with the majority of the switching vendors is still proving to be a challenge for many enterprises and requires careful interoperability testing. The OpenSEA (Open Secure Edge Access) open source 802.1X client initiative has not been widely promoted outside the vendor community, and it will take time before it is widely adopted by enterprises. It's really going to take time and more mature commercial products from Microsoft and Cisco that users can count on. The limited customer demand for 802.1X, though, may be stifling high priority investments in those efforts from the vendor community. Cisco, for example, is currently promoting its NAC framework more heavily than 802.1X as a solution for network authentication and access policy enforcement, so the focus may not be on making 802.1X seamless with other supplicants right now, which presumably reflects market demand.

Configuring the Microsoft 802.1X supplicant properly also takes some effort. It has to be enabled per interface, the EAP type has to be specified, and other confusing options like "authenticate as computer when user is not logged in" need to be properly set. There are subtle but significant differences between the Windows 2000, XP, and Vista supplicants. On Vista, the 802.1X service is not started by default but is on earlier platforms. Furthermore, Microsoft endpoints need to access the network during boot or to be remotely managed, and this requires configuring the ability for the computer itself to authenticate using the supplicant and authorize the port when there is no user present. Third-party supplicants may support more features, but still need to be installed and managed.

The 802.1X supplicant also has to be properly configured to authenticate users with the back-end AAA authentication server, typically using RADIUS. Configuring the Microsoft supplicant to work with a RADIUS-configured Windows Sever/Active Directory probably improves your chances of getting the interoperability right, but that may not be possible in all environments. To make matters worse, there is no standard for EAP, the protocol for the authentication exchange between supplicants and authentication servers, although vendors have agreed among themselves to support certain EAP types. Unfortunately, not all supplicants support all vendor EAP types.

For the organizations that manage to overcome the myriad of interoperability issues, there are still manageability and scalability considerations that must be addressed. Just needing to configure every client supplicant properly will pose challenges for IT staff in larger deployments.

Furthermore, the 802.1X authorization model is rather limited and does not accommodate many use cases without proprietary extensions. In particular, vendor-specific extensions are often used to handle IP phones with integral switches so that PCs can be connected through them to share an access port or for devices that are not 802.1X enabled. There are no standard ways to accommodate IP phones, nor are there standard attributes for port-based ACLs, making it difficult to mix switches from more than one vendor for other than basic 802.1X.

What Should Customers Do?
802.1X promises to deliver a very cost-effective way of building straight-forward role-based network access policies, likely suitable for at least guest access networks, if not more comprehensive role-based policy schemes. The main thing it has going for it is its nearly universal inclusion in basic network infrastructure from desktops, to enterprise networking gear, to directory servers, if you can get it all working together.

The primary reason why there are fewer 802.1X deployments than expected by now is that most enterprises are looking for more risk protection for their internal LAN from unmanaged endpoints as well as remote and unknown users. Any NAC product offers a wide-range of additional client-side compliance checks prior to making an admission decision and sending a user to an appropriate VLAN. Many of them are also designed to check for malware emanating from the suspicious client to further protect the network, or are designed to work closely with systems that can. And many organizations have more complex role-based policies that are driven by their risk management and compliance objectives than 802.1X was designed for. Many of these more complete LAN security solutions are actually much more plug-and-play as well, sitting in-line in the network, operating without the need for a pre-installed/configured client, and quickly integrating with any back-end directory server. Until 802.1X becomes equally efficient to deploy and manage, actual implementations will continue to be difficult to find. ENS