Overview
IEEE 802.1X is an IEEE
standard for port-based network access control
(port as in NIC).
It provides authentication to devices attached to a LAN
port or preventing access from that port if authentication
fails.
It is used for closed
wireless access points too, that is it
is used for both wired and Wi-Fi connections.
802.1X is based on the EAP, the Extensible Authentication Protocol, RFC 3748. EAP allows both parties to negotiate which authentication protocols, common functions, and security mechanisms to use.
EAP provides a sort of plug-in architecture for security modules. EAP is an authentication framework, not a specific authentication mechanism. Such mechanisms are called EAP methods. There are currently about 40 different methods, including EAP-TLS (all vendors must support this), EAP-SIM, EAP-AKA, PEAP, LEAP (a popular Cisco proprietary mechanism that uses MSCHAP2, known to be weak), and EAP-TTLS.
802.1x Protocol Details
There are three actors in this protocol. The supplicant is the client attempting to connect to a network. This is extra software on a computer, or extra firmware built into a NIC.
The authenticator is generally built into a WAP or a switch. It controls the port (NIC), initially denying all except 802.1X authentication packets from the client/supplicant. When the supplicant is authenticated the authenticator exchanges a session key and (the encrypted) access to the LAN is allowed. When the session is over (the supplicant tells the authenticator, or a time-out occurs) the port is locked down again, awaiting the next authentication exchange.
The authenticator doesn’t actually know how to authenticate users, so the name is a misnomer. Instead the user IDs and credentials (usually passwords) are kept in an authentication server. This can be a Windows ADC, a Kerberos server, but most commonly a RADIUS server. Note that unless they are bundled together in one WAP or switch, the authenticator must authenticate and use encrypted data with this server.
Many different authentication methods are permitted by 802.1X. The idea is the authentication server (commonly a RADIUS server) supports some methods, the supplicant (client, e.g., Wi-Fi NIC) supports some. So both parties use the EAP framework to decide which one they both will use for the session.
When the supplicant comes online it finds access to the network
denied.
It sends 802.1X packets (the only type allowed through)
and establishes an association with the authenticator.
The authenticator requests the supplicant’s identity
(
).
The supplicant sends the identity to the authenticator, which
forwards it to the authentication (RADIUS) server
as an access request.
Note different identities may have different types of access allowed.
username:
Figure 1:
A state diagram showing the interactions between
IEEE 802.1X supplicant,
authenticator, and authentication server.
Now the authenticator simply forwards packets between the supplicant and authentication server, which negotiate an authentication method (using EAP; note a particular method may be pre-configured).
Once the authentication method is agreed upon it is used.
A simplistic example would be a
prompt and reply.
password:
If all goes well the authentication tells the authenticator
OK
.
Then the authenticator tells the supplicant.
Finally a random session key is generated and securely exchanged between the supplicant and authenticator. The authenticator now allows access to the network by the supplicant using the session key.
When done the supplicant sends a termination message to the authenticator, which responds by blocking the port. (Or a session might time out.)
Adoption of 802.1X has been slow and different vendors support different EAP methods and proprietary extensions, hampering inter-operation. The Open SEA (secure edge access) Alliance (openSEAalliance.org) is creating an open, non-vendor-specific reference implementation of 802.1X to address this issue. (When 802.11N final becomes common, so will 802.1X.)