How RADIUS Works: Network Authentication, Authorization, and Accounting

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) for users connecting to a network. When you connect to a corporate Wi-Fi network and enter your username and password, when you authenticate to a VPN, or when an ISP verifies your broadband credentials, RADIUS is almost certainly the protocol brokering that authentication. Defined in RFC 2865 (2000) with roots going back to 1991, RADIUS remains the most widely deployed AAA protocol in networking — handling billions of authentication requests daily across enterprise networks, ISPs, and wireless carriers worldwide.

The AAA Model

RADIUS implements the three pillars of network access control:

• Authentication — "Who are you?" The RADIUS server verifies the user's identity, typically by checking credentials against a backend user store such as LDAP, Active Directory, or a local database.
• Authorization — "What are you allowed to do?" After authentication, the server returns attributes that define what the user can access: VLAN assignment, bandwidth limits, IP address pool, session timeout, and access control lists.
• Accounting — "What did you do?" Network devices send accounting records to the RADIUS server recording session start/stop times, data transferred, and connection details. This data is used for billing (ISPs), compliance auditing, and troubleshooting.

The key insight is centralization. Without RADIUS, every network switch, wireless access point, and VPN concentrator would need its own user database. With RADIUS, all authentication decisions are made by a central server (or cluster of servers), and network devices simply act as relays between the user and the RADIUS server.

RADIUS Architecture

RADIUS uses a client-server model with three actors:

• Supplicant — The end user or device requesting network access. This could be a laptop connecting to Wi-Fi, a user logging into a VPN client, or a router authenticating to its management plane.
• Network Access Server (NAS) — The network device that receives the access request and relays it to the RADIUS server. Also called the "RADIUS client" or "authenticator." Examples: wireless access points, VPN gateways, switches with 802.1X, DSL access concentrators (DSLAMs).
• RADIUS Server — The central authentication server that processes access requests and returns accept/reject decisions. Examples: FreeRADIUS, Microsoft NPS (Network Policy Server), Cisco ISE, Aruba ClearPass.

RADIUS Packet Types

RADIUS communication uses UDP (port 1812 for authentication, port 1813 for accounting). The protocol defines several packet types:

Authentication Packets

• Access-Request (code 1) — Sent by the NAS to the RADIUS server when a user attempts to connect. Contains the username, password (encrypted), NAS identifier, and other attributes describing the connection attempt.
• Access-Accept (code 2) — Sent by the server when authentication succeeds. Contains authorization attributes (VLAN, session timeout, ACLs) that the NAS should apply to the user's session.
• Access-Reject (code 3) — Sent by the server when authentication fails. May contain a Reply-Message attribute with a human-readable rejection reason.
• Access-Challenge (code 11) — Sent by the server when additional information is needed. This is the mechanism behind multi-step authentication — the server challenges the user for a one-time password, a PIN, or to complete an EAP exchange.

Accounting Packets

• Accounting-Request (code 4) — Sent by the NAS to report session events. The Acct-Status-Type attribute distinguishes between Start (session began), Stop (session ended), and Interim-Update (periodic status report).
• Accounting-Response (code 5) — Server acknowledgment of an accounting request.

The Shared Secret

RADIUS uses a shared secret — a pre-configured password known to both the NAS and the RADIUS server — to authenticate communication between them and to encrypt sensitive attributes. This is separate from the user's password.

The shared secret serves two purposes:

1. Password encryption — The user's password in an Access-Request is XORed with an MD5 hash derived from the shared secret and the request authenticator (a random 16-byte value). This is not strong encryption by modern standards.
2. Response authentication — The server computes a Response Authenticator by hashing the response packet content with the shared secret. The NAS verifies this hash to ensure the response came from the legitimate RADIUS server and was not tampered with.

The shared secret model has known weaknesses. If the shared secret is weak (short or predictable), an attacker who captures RADIUS packets can perform offline dictionary attacks to recover it. Once the shared secret is compromised, the attacker can decrypt user passwords and forge RADIUS responses. This is why strong, randomly generated shared secrets (at least 16 characters) are essential, and why modern deployments increasingly use TLS-based alternatives (RADIUS over TLS, or RadSec).

Attribute-Value Pairs

RADIUS packets carry data in Attribute-Value Pairs (AVPs). Each attribute has a type number, length, and value. Standard attributes are defined in RFC 2865 and RFC 2866, with many vendor-specific extensions. Important attributes include:

• User-Name (1) — The username being authenticated.
• User-Password (2) — The encrypted user password (for PAP authentication).
• NAS-IP-Address (4) — The IP address of the NAS sending the request.
• NAS-Port (5) — The physical port on the NAS where the user is connected.
• Service-Type (6) — The type of service requested (Login, Framed, Administrative, etc.).
• Framed-IP-Address (8) — The IP address to assign to the user (returned in Access-Accept).
• Filter-Id (11) — Name of a filter list (ACL) to apply to the user's session.
• Reply-Message (18) — Text to display to the user (e.g., "Password expires in 3 days").
• Session-Timeout (27) — Maximum session duration in seconds.
• Tunnel-Type (64), Tunnel-Medium-Type (65), Tunnel-Private-Group-Id (81) — Used together to assign the user to a specific VLAN.
• EAP-Message (79) — Carries EAP packets within RADIUS for 802.1X authentication.
• Vendor-Specific (26) — A container for vendor-defined attributes. Each vendor has an IANA-assigned Enterprise Number, and vendor-specific attributes are structured as sub-TLVs within this attribute.

EAP: Extensible Authentication Protocol

For modern network authentication, simple username/password (PAP/CHAP) is insufficient. EAP (RFC 3748) is a framework that runs within RADIUS, enabling sophisticated authentication methods without changing the RADIUS protocol itself. EAP packets are encapsulated in RADIUS Access-Request and Access-Challenge messages using the EAP-Message attribute.

Common EAP methods include:

• EAP-TLS — Mutual TLS authentication using client and server certificates. The strongest EAP method — no passwords involved. The client presents a certificate, and the server verifies it against a trusted CA. Requires PKI infrastructure for issuing client certificates.
• EAP-TTLS — Tunneled TLS. The server authenticates with a certificate (establishing a TLS tunnel), then the client authenticates inside the tunnel using a simpler method like PAP or MSCHAPv2. Avoids the need for client certificates while still protecting the inner authentication.
• PEAP (Protected EAP) — Similar to EAP-TTLS: establishes a TLS tunnel first, then runs an inner EAP method (typically EAP-MSCHAPv2). Developed by Microsoft, Cisco, and RSA. The most common EAP method in enterprise Wi-Fi deployments.
• EAP-FAST — Cisco's alternative to PEAP that uses Protected Access Credentials (PACs) instead of server certificates for faster tunnel establishment.
• EAP-SIM / EAP-AKA — Used in cellular networks to authenticate using the SIM card's cryptographic keys. EAP-AKA' (prime) is used in 5G networks.

802.1X Integration

The most important use of RADIUS today is IEEE 802.1X port-based network access control. 802.1X is the framework; RADIUS is the backend. Together they control access to wired and wireless networks.

In an 802.1X deployment:

1. The supplicant (client device) connects to the network. The switch or access point blocks all traffic except EAP/802.1X frames.
2. The authenticator (switch/AP) initiates EAP by sending an EAP-Request/Identity message.
3. The supplicant responds with its identity (username or machine name).
4. The authenticator encapsulates the EAP response in a RADIUS Access-Request and forwards it to the RADIUS server.
5. The RADIUS server and supplicant exchange EAP messages (via the authenticator) to complete authentication — potentially involving multiple Access-Challenge/Request round trips for methods like PEAP.
6. On success, the RADIUS server sends an Access-Accept with VLAN assignment and other authorization attributes. The authenticator opens the port and applies the authorized configuration.
7. On failure, the RADIUS server sends an Access-Reject. The authenticator keeps the port blocked or places the device in a restricted guest VLAN.

This architecture means the authenticator never sees the user's credentials — it simply tunnels EAP packets between the supplicant and the RADIUS server. This is a crucial security property: a compromised access point cannot steal user passwords.

RADIUS Proxy and Roaming

RADIUS supports proxy chains where a RADIUS server forwards requests to another RADIUS server. This is essential for several use cases:

• eduroam — The global academic Wi-Fi roaming consortium. When a student from MIT visits Oxford and connects to "eduroam," the local RADIUS server proxies the authentication request back to MIT's RADIUS server based on the realm portion of the username ([email protected]). The proxy chain can span multiple national and international relay servers.
• ISP roaming — When a mobile user connects to a partner network, the local network's RADIUS server proxies authentication to the user's home ISP.
• Multi-site enterprises — A central RADIUS server handles authentication policy while regional proxies handle local traffic distribution and failover.

Proxy decisions are typically based on the realm — the domain portion after the @ in the username. The RADIUS server maintains a realm routing table mapping domains to upstream RADIUS servers.

RADIUS vs. TACACS+

TACACS+ (Terminal Access Controller Access-Control System Plus) is an alternative AAA protocol developed by Cisco. While RADIUS dominates network access authentication, TACACS+ is preferred for device administration — controlling who can log into network equipment (routers, switches, firewalls) and what commands they can execute.

• Transport — RADIUS uses UDP; TACACS+ uses TCP (port 49). TCP provides reliable delivery with connection tracking.
• Encryption — RADIUS encrypts only the password field; TACACS+ encrypts the entire packet body (though with a weak algorithm).
• AAA separation — RADIUS combines authentication and authorization in a single exchange; TACACS+ separates them into distinct protocol phases, allowing more granular control.
• Command authorization — TACACS+ can authorize individual CLI commands (e.g., allow show commands but deny configure terminal). RADIUS has no equivalent capability.
• Vendor support — RADIUS is an open standard with implementations from many vendors; TACACS+ is Cisco-originated and primarily supported in Cisco ecosystems (though open-source implementations exist).

Many organizations run both: RADIUS for user network access (Wi-Fi, VPN) and TACACS+ for network device administration.

RADIUS Accounting in Practice

RADIUS accounting provides detailed records of network usage. Accounting packets include attributes like:

• Acct-Session-Id — Unique identifier for the session.
• Acct-Input-Octets / Acct-Output-Octets — Bytes received and sent by the user.
• Acct-Input-Packets / Acct-Output-Packets — Packet counts.
• Acct-Session-Time — Session duration in seconds.
• Acct-Terminate-Cause — Why the session ended (user request, idle timeout, session timeout, admin reset, port error, etc.).
• Called-Station-Id / Calling-Station-Id — The NAS port (or Wi-Fi SSID and BSSID) and the client's MAC address, respectively.

ISPs use accounting data for usage-based billing. Enterprises use it for compliance auditing (tracking who accessed the network, when, and from where), security incident investigation, and capacity planning.

RadSec: RADIUS over TLS

Traditional RADIUS has significant security limitations: UDP provides no connection state, the shared secret mechanism is weak, and most of the packet is not encrypted. RadSec (RFC 6614) addresses these by running RADIUS over TLS.

RadSec provides:

• Full encryption — The entire RADIUS packet is encrypted, not just the password field.
• Certificate-based authentication — Replaces shared secrets with X.509 certificates, enabling stronger mutual authentication between RADIUS client and server.
• Reliable transport — Runs over TCP, providing connection state and retransmission.
• NAT-friendly — TCP connections work through NAT devices; UDP RADIUS often does not.

RadSec is particularly important for proxy chains (like eduroam) where RADIUS packets traverse untrusted networks between institutions.

Security Considerations

• Shared secret strength — Use cryptographically random secrets of at least 16 characters. Never reuse the same shared secret across multiple NAS devices — a compromised device would allow the attacker to forge RADIUS responses for all other devices sharing the secret.
• EAP method selection — PAP sends the password in a reversible form (XOR with MD5 hash). MSCHAPv2 outside a TLS tunnel is vulnerable to offline dictionary attacks. Always use a tunneled EAP method (PEAP, EAP-TTLS) or certificate-based EAP-TLS.
• Certificate validation — In PEAP and EAP-TTLS, the supplicant must validate the RADIUS server's TLS certificate. If certificate validation is disabled (a disturbingly common misconfiguration), an attacker can set up a rogue access point, present a fake certificate, and capture credentials inside the TLS tunnel.
• RADIUS bombing — DoS attacks flooding the RADIUS server with forged Access-Requests. Rate limiting, source IP filtering, and connection tracking help mitigate this.
• Attribute manipulation — If the shared secret is compromised, an attacker can forge Access-Accept responses with arbitrary authorization attributes (VLAN assignments, admin privileges).

RADIUS and Network Infrastructure

RADIUS is deeply embedded in network infrastructure:

• LDAP / Active Directory — Most RADIUS servers authenticate against an LDAP directory or Active Directory. The RADIUS server translates between the RADIUS protocol and LDAP bind operations.
• Kerberos — In Windows environments, the RADIUS server (Microsoft NPS) can use Kerberos to validate credentials against Active Directory, integrating network access with the domain authentication infrastructure.
• TLS — EAP methods (PEAP, EAP-TLS, EAP-TTLS) use TLS for tunnel establishment and certificate-based authentication. RadSec uses TLS to encrypt the entire RADIUS transport.
• BGP — RADIUS servers in distributed deployments rely on BGP for reachability. A routing disruption between a NAS and its RADIUS server causes authentication failures, locking users out of the network.
• VPN — VPN concentrators are major RADIUS clients, using RADIUS to authenticate remote users and assign tunnel parameters (IP address, DNS server, split-tunnel configuration).

Relevant RFCs

• RFC 2865 — Remote Authentication Dial In User Service (RADIUS). The core authentication protocol.
• RFC 2866 — RADIUS Accounting.
• RFC 3748 — Extensible Authentication Protocol (EAP).
• RFC 5216 — EAP-TLS Authentication Protocol.
• RFC 5281 — EAP-TTLS.
• RFC 6614 — Transport Layer Security (TLS) Encryption for RADIUS (RadSec).
• RFC 7542 — The Network Access Identifier (NAI) — defines the user@realm format used for RADIUS proxy routing.
• IEEE 802.1X-2020 — Port-Based Network Access Control.

See It in Action

RADIUS infrastructure runs on networks routed via BGP. Explore the networks behind major authentication services using the god.ad BGP Looking Glass:

• AS8075 — Microsoft (Azure AD / NPS integration)
• AS16509 — Amazon (AWS network authentication infrastructure)
• AS2914 — NTT (global eduroam relay infrastructure)
• AS11537 — Internet2 (US eduroam federation)
• AS13335 — Cloudflare (Cloudflare Access with RADIUS integration)