↓ Skip to main content
Le Site de François
  1. Index/

Port-based Network Access Control (IEEE 802.1X)

Security Networking Authentication Radius Eap Ieee Zero-Trust

IEEE 802.1X is a standard for Port-Based Network Access Control (PNAC) that prevents any device from sending or receiving traffic on a network port until it has successfully authenticated. Originally designed for wired Ethernet and ratified in 2001, it now equally underpins enterprise Wi-Fi (WPA-Enterprise/WPA3-Enterprise), where access points act as the port gatekeeper. The core premise is that physical access to a port — plugging in a cable or being in range of an access point — does not grant network access. The port is logically divided into two channels: the uncontrolled port, which passes only EAP authentication traffic (EAPOL frames), and the controlled port, which is fully blocked until authentication succeeds. Only after the authentication server approves the device does the switch or access point open the controlled port and allow normal traffic. This port-level gate is what separates 802.1X from higher-layer authentication: a device that fails 802.1X receives no IP address, cannot reach any network resource, and cannot even attempt an attack at layer 3.

The authentication architecture has three roles. The supplicant is the device seeking network access — a laptop, phone, IoT sensor, or server NIC — and runs 802.1X client software (wpa_supplicant on Linux, native on Windows and macOS). It initiates authentication by sending an EAPOL-Start frame or responding to the authenticator’s EAP-Request/Identity challenge. The authenticator is the network device that enforces access — a switch port or wireless access point — that physically sits between the supplicant and the rest of the network. It speaks EAPOL toward the supplicant and proxies the EAP messages to the authentication server encapsulated in RADIUS packets. On Linux, the authenticator role is implemented by hostapd: the same daemon handles both Wi-Fi access point operation (beacon broadcast, association, WPA/WPA2/WPA3 key exchange) and 802.1X port authentication toward a RADIUS server, making it the software that turns a Linux machine with a wireless NIC or a wired bridge into a full 802.1X authenticator. hostapd is configured via /etc/hostapd/hostapd.conf, where ieee8021x=1 enables 802.1X, auth_server_addr and auth_server_shared_secret point it at the RADIUS server, and wpa=2 with wpa_key_mgmt=WPA-EAP enables WPA2-Enterprise on a wireless interface. The authentication server — almost universally a RADIUS server (FreeRADIUS, Cisco ISE, Aruba ClearPass, Microsoft NPS) — receives the EAP exchange, validates the supplicant’s identity and credentials, and returns an Access-Accept or Access-Reject. On Access-Accept it also returns RADIUS attributes that the authenticator enforces: the VLAN to assign (Tunnel-Private-Group-ID), a downloadable ACL (Filter-Id), a session timeout, and — for MACsec deployments — the Connectivity Association Key material derived from the EAP session. The EAP method used determines the strength of authentication: EAP-TLS provides mutual certificate-based authentication (client certificate validates to a CA the RADIUS server trusts, server certificate validates to a CA the supplicant trusts) and is the strongest method; EAP-PEAP and EAP-TTLS tunnel weaker inner methods (MSCHAPv2, password) inside a TLS tunnel to the RADIUS server; EAP-MD5 provides no server authentication and should not be used.

802.1X is the network admission layer on which MACsec and zero-trust network access are built. When 802.1X authentication uses EAP-TLS, the TLS master secret is used to derive the CAK (Connectivity Association Key) that seeds MACsec’s MKA protocol, meaning that a successfully 802.1X-authenticated port automatically has a MACsec-encrypted channel established — authentication and encryption are a single unified operation. For cert-manager and SPIFFE/SPIRE users, 802.1X EAP-TLS is the network-admission analogue of mTLS at the transport layer: both rely on mutual X.509 certificate validation against a PKI, both gate access on identity rather than location, and both fit naturally into a posture where network admission requires a device certificate issued and rotated by the organisation’s CA. The break-glass consideration for 802.1X deployments is MAC Authentication Bypass (MAB): devices that cannot run a supplicant (printers, IP cameras, industrial controllers) authenticate using their MAC address, which the RADIUS server looks up in a device database. MAB is inherently weaker than EAP-TLS — MAC addresses are spoofable — and should be isolated to a restricted VLAN with firewall policy limiting what MAB-authenticated devices can reach. The PQC transition affects 802.1X through EAP-TLS: migrating to ML-DSA certificates in the RADIUS server and device PKI automatically propagates quantum-safe identity into every 802.1X-authenticated network admission decision.

Related

FIDO (Fast IDentity Online) / FIDO2

Security Authentication Cryptography Pki Webauthn Mfa Zero-Trust
FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.

MACsec (IEEE 802.1AE)

Security Networking Layer2 Ethernet Ieee Encryption
MACsec (MAC Security, IEEE 802.1AE) is an IEEE standard, first published in 2006 and supported in the Linux kernel since 4.6 (2016), that encrypts and authenticates Ethernet frames at layer 2 — hop by hop between directly connected devices. Its operating layer is what distinguishes it from IPsec (layer 3) and TLS (layer 4): MACsec wraps Ethernet frames, not IP packets or TCP streams, so it can protect every byte that traverses a link segment regardless of what protocol it carries. ARP replies, DHCP offers, LLDP frames, routing protocol adjacencies, and layer-2 broadcast traffic are all encrypted and authenticated alongside application data — something neither IPsec nor TLS can accomplish because both require an IP header to already be present and unenforced. The topology implication of this is that MACsec is link-local and hop-by-hop: it encrypts between two directly adjacent Ethernet peers (a host and a switch, or two switches), decrypts at each hop for forwarding decisions, and re-encrypts toward the next hop. It cannot stretch across a routed boundary; for that, IPsec is the right tool.

mTLS (Mutual TLS)

Security Cryptography Networking Tls Identity Zero-Trust Mtls
mTLS (Mutual TLS) is the configuration of TLS in which certificate-based authentication is required from both sides of the connection, not just the server. In standard TLS, only the server presents an X.509 certificate, which the client verifies to confirm it is talking to the intended host; the client is typically anonymous to the server, or authenticates separately via a password or session token at the application layer. In mTLS, the client also presents a certificate during the TLS handshake; the server verifies it against a trusted CA before completing the connection. The result is cryptographic proof of identity in both directions: the client knows it is talking to the legitimate server (as in standard TLS), and the server knows the exact identity of the connecting client — without any password, API key, or token exchanged in the application layer.