What are 802.1X and NAC? What happens when you plug in a cable

The short answer: 802.1X is the IEEE standard that lets a switch or access point hold back a newly connected device's normal traffic until that device has authenticated to a server, usually a RADIUS server. NAC (network access control) is the system that takes the result of that authentication, adds other facts about the device such as its patch or antivirus state, and decides how much access the device gets.

So 802.1X is the mechanism a port uses to open or stay closed, and NAC is the policy that decides who gets in, how far, and when that should change. This post follows the packets from the moment a cable is plugged in to the moment the port opens.

SUPPLICANT             AUTHENTICATOR                AUTH SERVER 
                                                                
           EAPOL                         RADIUS                 
                                        udp/1812                
┌────────┐             ┌──────────────┐           ┌────────────┐
│ laptop │             │ switch       │           │ RADIUS   ● │
│        │─────────────│ EAPOL only   │───────────│            │
│ client │             │ unauthorized │           │            │
└────────┘             └──────────────┘           └────────────┘
link up: port starts unauthorized, only EAPOL may pass          
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                

What is 802.1X?

802.1X is an IEEE standard whose full name is Port-Based Network Access Control. The current edition, IEEE 802.1X-2020, was approved on 30 January 2020 and published on 28 February 2020. IEEE's summary says it lets an administrator restrict the use of IEEE 802 LAN service access points (ports) to secure communication between authenticated and authorized devices.

802.1X does not define how a device proves who it is. It carries EAP, the Extensible Authentication Protocol from RFC 3748, a framework that supports multiple authentication methods and runs directly over data link layers without requiring IP. That last part matters: a device that has just been plugged in has no IP address yet. EAP carried in Ethernet frames between the device and the switch is called EAPOL, EAP over LAN.

Who takes part in 802.1X, and what does each one do?

Three parties. RFC 3748 defines them in section 1.2:

In most deployments the switch runs as a pass-through authenticator. It does not check credentials itself; it relays EAP between the device and the server. RFC 3748 lists the benefit: switches and access points do not have to understand each authentication method. In pass-through mode the authenticator MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server (section 2.3). Moving from PEAP to EAP-TLS is a change on the server and the clients, not on the switches.

What happens, step by step, when a device plugs in?

The port starts unauthorized, EAP goes back and forth through the switch to the RADIUS server, and the port opens when the server sends Access-Accept. Here is the sequence on an access switch with 802.1X enabled. The commands and behaviour below are Cisco Catalyst's, from the IOS XE 17.9 configuration guide; other vendors name things differently, but the protocol sequence is the same.

1. Link up, port still closed

With authentication port-control auto, the port begins in the unauthorized state, allowing only EAPOL frames to be sent and received. The device's DHCP, ARP and everything else are dropped. Note the Catalyst default: ports are force-authorized, which disables 802.1X authentication. A port you forgot to configure is simply open.

2. The switch asks who you are

When the link comes up, the switch sends an EAP-Request/Identity frame and the device answers with an EAP-Response/Identity. If the device finishes booting without having seen that request, it sends EAPOL-Start, which prompts the switch to request the client's identity.

An EAP packet has one of four codes: 1 Request, 2 Response, 3 Success, 4 Failure (RFC 3748, section 2.2). EAP is a lock-step protocol which only supports a single packet in flight: the authenticator cannot send the next Request until it has a valid Response.

3. The switch wraps EAP in RADIUS

The switch puts the EAP-Response into an EAP-Message attribute and sends it to the RADIUS server in an Access-Request (RFC 3579). EAP-Message is attribute 79, and every RADIUS packet that carries one must also carry a Message-Authenticator (attribute 80), which protects it against spoofing. RADIUS uses UDP port 1812, and the switch and server authenticate each other with a shared secret that is never sent over the network.

RFC 3580 adds that, for 802.1X, the device's MAC address goes in Calling-Station-Id, in upper case with dashes, for example 00-10-A4-23-19-C0. In RADIUS logs, that is the value you search for to find which device came in on which port.

4. The server challenges, several times

A server that wants to authenticate with EAP MUST respond with an Access-Challenge packet containing EAP-Message attribute(s). The switch unwraps the EAP inside, sends it to the device as EAPOL, wraps the device's answer in a new Access-Request, and so on. Methods that send certificates have to fragment them; RFC 3748's example is a certificate chain of 14,960 octets, which would require ten round-trips to send with a 1496 octet EAP MTU.

5. Access-Accept, and the port opens

When the server answers Access-Accept, the switch sends EAP-Success to the device and the port changes to authorized, and all frames from the authenticated client are allowed through. An Access-Reject MUST result in the NAS denying access.

Access-Accept can also carry the access the device gets. The common example is a VLAN, set with three attributes from RFC 3580:

Tunnel-Type             = VLAN (13)
Tunnel-Medium-Type      = 802
Tunnel-Private-Group-ID = "20"

The VLAN ID is a value from 1 to 4094, sent as a string.

6. Reauthentication and logoff

The port goes back to unauthorized if the link goes down or an EAPOL-Logoff frame is received. With reauthentication on, the server can set the interval with Session-Timeout (attribute 27) and Termination-Action (attribute 29); with Termination-Action set to RADIUS-Request, the session is not affected during reauthentication.

How are EAP-TLS and PEAP different?

The difference is how the client proves itself. EAP-TLS uses a certificate on both sides. PEAP uses a certificate only on the server, builds a TLS tunnel with it, and then authenticates the client inside the tunnel, usually with a password.

EAP-TLS (RFC 5216, March 2008) provides certificate-based mutual authentication and key derivation. In the RFC's message flow the server sends its certificate and a certificate_request, and the client replies with its own certificate and a certificate_verify. Its EAP Type is 13. RFC 9190 (February 2022) covers EAP-TLS with TLS 1.3, which improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking.

PEAP (EAP Type 0x19, 25) is specified by Microsoft in MS-PEAP and runs in two phases. Phase 1 exists to authenticate the PEAP server and to establish a TLS session. Phase 2 starts a new EAP conversation inside that TLS session to authenticate the client; EAP-MSCHAPv2 is the usual inner method. Microsoft's stated reason for PEAP is to get the benefit of strong credentials without incurring the cost of an infrastructure required by a client public key infrastructure (PKI) deployment.

My view: where PEAP goes wrong is usually the client configuration, not the protocol. Phase 1 is what proves the server is the real one. If the supplicant is not set to check the server certificate against the right CA and the expected server name, phase 1 proves nothing, and phase 2, with the user's credentials, runs against whichever server answered. If you choose PEAP, push that setting through device policy rather than leaving users to accept a certificate prompt.

How do printers and other devices without a supplicant get on the network?

With MAB, MAC Authentication Bypass: the switch uses the device's MAC address as its identity.

On Catalyst, if 802.1X times out waiting for EAPOL and MAB is enabled, the switch waits for an Ethernet frame from the device, uses the MAC address of the client as its identity and includes this information in the RADIUS-access/request frame. If it sees an EAPOL packet while waiting, it stops MAB and starts 802.1X.

Cisco's MAB Deployment Guide makes three points worth knowing:

• It is slow to start. The wait before MAB is (max-reauth-req + 1) × tx-period. With Catalyst's defaults of a 30-second tx-period and max-reauth-req of 2, it takes 90 seconds by default for the port to start MAB. A device booting over PXE, or asking for DHCP early, can give up first.
• It is weak. In the guide's words, MAB is not a strong authentication method. MAB can be defeated by spoofing the MAC address of a valid device.
• The server has to tell it apart. MAB sends a PAP Access-Request with the MAC address as both username and password, and Catalyst sets Attribute 6 (Service-Type) to 10 (Call-Check). The RADIUS server should use that to keep MAB requests apart from user logins; otherwise anyone who types a MAC address into a username and password prompt may get in.

Because a MAC address is easy to copy, the access given to MAB devices should be as narrow as you can make it.

What is NAC, and how is it different from 802.1X?

NAC decides network access from several inputs together, not identity alone. 802.1X is one of the channels NAC uses to learn identity and to open or close a port.

The extra input is the device's posture. The IETF describes it in RFC 5209 (June 2008), the requirements document for NEA (Network Endpoint Assessment): a way to evaluate the posture of a system, during the request for access or at any time while connected, which is useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. The RFC's example of a posture attribute is the version of the operating system installed.

A typical sequence:

1. The device passes 802.1X and first gets limited access, for example only to the posture server and the servers used to fix problems.
2. An agent on the device reports its posture to the NAC server.
3. The NAC server decides whether the device meets the policy.
4. The NAC server tells the switch to change the existing session's access with a RADIUS CoA (Change of Authorization).

CoA is defined in RFC 5176. It reverses the usual RADIUS direction: the server sends the request to the switch, on UDP port 3799. A CoA-Request is used to change data filters for a session, for example with a new Filter-ID; a Disconnect-Request ends the session. Catalyst supports four actions for CoA: reauthenticate, terminate, port shutdown, and port bounce.

Posture has two limits. RFC 5209 itself says an endpoint that is deemed compliant may still be vulnerable to threats. And the system has to trust what the device reports: the NEA model does not explicitly specify how to detect or prevent lying endpoints. Some devices, such as printers, may be incapable of running the NEA Client software at all.

Can devices still connect if the RADIUS server is down?

It depends on the configuration. With nothing configured, a device that needs to authenticate cannot get in, because its port stays unauthorized.

Catalyst has a feature called inaccessible authentication bypass, also known as critical authentication. When the RADIUS server cannot be reached, the switch grants the client access to the network by putting the port in the critical-authentication state in a chosen VLAN. The same guide describes two related cases that are usually set up together: a guest VLAN for devices that never answer 802.1X, and a restricted VLAN for devices that answer but fail.

This is a choice between keeping people working and staying strict, and there is no single right answer. Make the choice before you go live, and run more than one RADIUS server.

What should you check before turning on 802.1X?

This is the list I would go through before enabling 802.1X on access switches, based on the behaviour above:

• Know that ports start as force-authorized, and which ports will move to auto.
• List the devices with no supplicant (printers, cameras, scanners) and decide which of them use MAB.
• Make the RADIUS server separate MAB from user logins with Service-Type, and keep MAB access narrow.
• Pick the EAP method. For PEAP, enforce server certificate validation on clients by policy.
• Tune tx-period and max-reauth-req for devices that boot quickly.
• Decide on guest VLAN, restricted VLAN and critical authentication in advance.
• Run a second RADIUS server, and use a different shared secret per device.
• Make sure you can search logs by Calling-Station-Id when someone reports they cannot connect.

Sources

• IEEE 802.1X-2020: Port-Based Network Access Control
• RFC 3748: Extensible Authentication Protocol (EAP)
• RFC 2865: Remote Authentication Dial In User Service (RADIUS)
• RFC 3579: RADIUS Support For EAP
• RFC 3580: IEEE 802.1X RADIUS Usage Guidelines
• RFC 5216: The EAP-TLS Authentication Protocol
• RFC 9190: EAP-TLS 1.3
• RFC 9427: TLS-Based EAP Types for Use with TLS 1.3
• Microsoft MS-PEAP: Overview
• RFC 5209: Network Endpoint Assessment (NEA) Requirements
• RFC 5176: Dynamic Authorization Extensions to RADIUS
• Cisco: Configuring IEEE 802.1x Port-Based Authentication (Catalyst 9300, IOS XE 17.9.x)
• Cisco: MAC Authentication Bypass Deployment Guide