RADIUS — Remote Authentication

RADIUS

RADIUS centralises authentication, authorisation, and accounting for network access — VPNs, Wi-Fi, 802.1X port authentication, and dial-up all delegate credential verification to a RADIUS server. It is the reason your corporate Wi-Fi can check your Active Directory password without each access point knowing anything about your account.

applicationradiusaaa802.1xauthenticationaccountingeaprfc2865

Overview

RADIUS — Remote Authentication Dial-In User Service — was created in 1991 to centralise authentication for dial-up modem pools. The name reflects its origins, but RADIUS today authenticates Wi-Fi connections, VPN users, network switches via 802.1X, and administrative access to routers and firewalls.

The core value proposition: centralisation. Without RADIUS, each network device (each access point, each VPN endpoint, each switch) would need its own user database. With RADIUS, all these devices delegate authentication to a central server that can check credentials against Active Directory, LDAP, a local database, or any other source.

RADIUS operates on:


AAA — The Three Functions

RADIUS implements AAA:

Authentication: Is this user who they claim to be? Verify identity via username/password, certificate, or token.

Authorisation: What is this user allowed to do? After authentication, the RADIUS server returns attributes that tell the network device how to treat the user — which VLAN to assign, which ACL to apply, what services to permit.

Accounting: What did the user do? Session start/stop records with duration, bytes transferred, and the assigned address. Used for billing (ISPs), auditing (enterprise), and troubleshooting.


The Three Roles

Supplicant: The device or user requesting access (laptop, phone, VPN client).

NAS (Network Access Server) / RADIUS Client: The device enforcing access — wireless access point, VPN concentrator, switch, or router. The NAS does not validate credentials itself; it forwards them to the RADIUS server and acts on the response.

RADIUS Server: The central authentication server — FreeRADIUS, Cisco ISE, Microsoft NPS (Network Policy Server), Aruba ClearPass. Validates credentials, applies policy, returns access decision.


RADIUS Authentication Flow

Supplicant
NAS (AP/VPN)
Connection request
Wi-Fi association or VPN connection attempt
Access-Request
Username, password (encrypted), NAS IP, Called-Station-Id
Access-Challenge (optional)
Request for additional factor — OTP, EAP message
Challenge forwarded
Challenge response
OTP code or EAP response
Access-Request (with response)
Access-Accept
User authenticated — includes authorisation attributes
Access granted
VLAN assigned, session started
Accounting-Request (Start)
Session start timestamp, framed IP, session ID
Accounting-Request (Stop)
Session end — bytes in/out, duration, terminate cause

RADIUS Packet Structure

RADIUS Packet

Code (1 byte)
1B
Identifier (1 byte)
1B
Length (2 bytes)
2B
Authenticator (16 bytes)
4B
Attributes (variable)
8B

Code values: 1 = Access-Request, 2 = Access-Accept, 3 = Access-Reject, 4 = Accounting-Request, 5 = Accounting-Response, 11 = Access-Challenge

Authenticator: A 16-byte MD5 hash used for packet integrity and to obfuscate the password in Access-Request packets. In Access-Request, this is a random value (Request Authenticator). In responses, it is an MD5 hash over the packet content and the shared secret.

Password encryption: The user’s password is XORed with the MD5 of (shared secret + Request Authenticator). This is not strong encryption — it prevents casual interception but is not resistant to offline attacks if the shared secret is weak.


RADIUS Attributes

Attributes are type-length-value (TLV) structures carrying all the data in a RADIUS packet. Standard attributes are defined in RFC 2865/2866; vendors add their own in VSA (Vendor-Specific Attributes), attribute type 26.

Authentication attributes:

AttributeTypePurpose
User-Name1The username
User-Password2Encrypted password
NAS-IP-Address4IP of the NAS
NAS-Port5Physical port on NAS
Called-Station-Id30BSSID/SSID for Wi-Fi
Calling-Station-Id31MAC address of supplicant
EAP-Message79EAP payload (fragmented)

Authorisation attributes (returned in Access-Accept):

AttributeTypePurpose
Framed-IP-Address8Assign specific IP to user
Session-Timeout27Maximum session length (seconds)
Filter-Id11ACL name to apply
Tunnel-Type64Tunnel protocol for VLAN assignment
Tunnel-Medium-Type65Medium type (802 for Ethernet)
Tunnel-Private-Group-Id81VLAN ID to assign

Dynamic VLAN assignment uses attributes 64, 65, and 81: the RADIUS server tells the NAS which VLAN to put the user in based on their group membership. A developer gets VLAN 10, a guest gets VLAN 99, an admin gets VLAN 5 — all using the same SSID.


802.1X — Port-Based Network Access Control

802.1X is the IEEE standard for authenticating devices before granting network access at the port level. RADIUS is the authentication back-end for 802.1X.

Without 802.1X: anyone who plugs into a network port or connects to an SSID gets network access. With 802.1X: the port remains in an unauthorised state, only allowing RADIUS EAP traffic, until authentication succeeds.

EAP — Extensible Authentication Protocol

EAP is the authentication framework used within 802.1X (and encapsulated in RADIUS’s EAP-Message attributes). EAP itself is just a container — the actual authentication happens in an EAP method:

EAP MethodAuthenticationTLS TunnelNotes
EAP-TLSClient certificateYesStrongest — no passwords; requires PKI for all clients
PEAP (Protected EAP)Password inside TLS tunnelYesMost common enterprise Wi-Fi; uses server cert only
EAP-TTLSPassword inside TLS tunnelYesSimilar to PEAP; more flexible inner methods
EAP-MD5MD5 challengeNoNo server authentication — vulnerable to MITM
EAP-FASTPAC-basedYesCisco proprietary; no certificates needed

PEAP with MSCHAPv2 is the dominant enterprise Wi-Fi authentication combination: the server presents a TLS certificate (so the client can verify it is talking to the real RADIUS server), and the user’s password is exchanged inside the TLS tunnel using MSCHAPv2.


Shared Secret — The RADIUS Weak Point

RADIUS uses a shared secret between the NAS and the RADIUS server for packet authentication and password encryption. This is a static password configured on both sides. Its security implications:

RADSEC (RADIUS over TLS/DTLS) — RFC 6614 — solves this by tunnelling RADIUS over TLS, providing proper channel encryption and mutual certificate authentication. Increasingly deployed in large enterprise and carrier environments.


FreeRADIUS

FreeRADIUS is the dominant open-source RADIUS server. It supports every EAP method, integrates with LDAP/AD, SQL databases, and REST APIs, and handles millions of authentication requests per day in ISP deployments.

Configuration directory: /etc/freeradius/3.0/

Key files:


Key Concepts

RADIUS vs LDAP for authentication

Both can authenticate users, but they serve different roles. LDAP is a directory protocol — applications query it directly. RADIUS is an AAA proxy — network devices forward credentials to it. RADIUS can use LDAP as its back-end. A VPN authenticating against AD typically does so via RADIUS (with FreeRADIUS or NPS as the RADIUS server, which in turn queries AD over LDAP).

Accounting is underutilised

RADIUS accounting provides a detailed log of every session: who connected, when, from where, for how long, how much data they transferred. This is invaluable for incident response (who was on the VPN when the breach happened?) and capacity planning. Many organisations deploy RADIUS auth but ignore the accounting data.


References