RADIUS
Remote Authentication Dial-In User ServiceRADIUS answers the question asked before any traffic is allowed. A switch, Wi-Fi controller or VPN forwards a joining device’s credentials to a central server, which replies accept or reject — often with a VLAN to put them on — and then logs the whole session for accounting.
RADIUS centralises authentication, authorisation and accounting for network access — the switch asks, the server decides.
How it works
The authenticator forwards the identity and credentials it was given, with the port it arrived on.
The reply may also carry attributes — a VLAN, an ACL, a session timeout to enforce.
Start, interim and stop records on 1813 record who was on, for how long, and how much they moved.
The switch is a relay, not a judge — it holds the port closed until the server says otherwise. That is what makes one policy apply across every access point and every switch at once.
What RADIUS does, step by step
With 802.1X, a switch port passes nothing but EAP until the device has authenticated.
The authenticator wraps the credentials in RADIUS and sends them to the server on 1812.
The server checks the directory and answers — often adding the VLAN or ACL to apply.
Start and stop records on 1813 give a complete picture of who was connected, and when.
In cybersecurity
RADIUS is old enough that its packet protection is a shared secret and MD5 — modern deployments must tunnel it, or rely on EAP to protect what actually matters.
Only the password attribute is obscured, using MD5 with the shared secret — the rest is plaintext.
CVE-2024-3596 forges responses via MD5 collisions; Message-Authenticator must be required.
Long and unique per client — a reused secret compromises every device that has it.
Certificate-based EAP means no password is exposed even if RADIUS itself is observed.
RADIUS over TLS on 2083 fixes the transport properly; use it wherever both ends support it.
Clients that don’t check it will hand credentials to any evil-twin AP that asks.