This whitepaper describes 802.1x and its role in pre-connect LAN Security. Following a brief overview of the technology, we give some pros and cons of an 802.1x deployment. We then describe a phased plan for LAN security that incorporates 802.1x as well as other user authentication alternatives and that can be used in the meantime, should 802.1x not be near-term feasible.
1 Introduction
User authentication is necessary for identity based access control, and 802.1x clearly promises to meet this need.
802.1x has been around for a number of years and has been proposed as the user authentication solution for both wired and wireless LANs. Formally known as the IEEE Standard for Local and metropolitan area networks – Port Based Access Control, IEEE Standard 802.1x-2004 was initially published in 2001 and later revised in 2004. Since then it has become available in virtually all shipping managed switches. Most switch products even offer the ability to configure the port VLAN based on the user identity, and some even support configuring port-based ACLs. Given its widespread availability, 802.1x would seem the obvious choice for implementing user based authentication in enterprise networks.
So why isn’t everyone using it?
1.1 802.1x in Plain English
First of all, we need some technical background. At its core, 802.1x is really quite simple, but this simplicity is not so obvious to someone who just picks up the IEEE standard. In common with many other standards, IEEE Standard 802.1x-2004 has its share of jargon and not particularly a “user friendly” read. So the following paragraphs describe all you need to know about 802.1x, in plain English.
802.1x 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.
1.2 Some Good Points
802.1x has a lot going for it. It is widely available, and permits things like re-authentication almost at any time, including changing the VLAN and other attributes.
Also, it was intended for entity authentication but can and has been readily extended to support other features, in particular, communicating pre-connect NAC posture attributes. All major NAC architectures, including Cisco’s CNAC, Trusted Computing Group’s TNC, and Microsoft’s NAP, support 802.1x both for carrying attributes between client and server and for enforcement based on the compliance result. For TNC, it is the only method defined as of this writing.
