RADIUS
acronymISP & telecomsecuritynetworking
Stands for: Remote Authentication Dial-In User Service (RFC 2865, RFC 2866)
The AAA workhorse: authenticates who connects, authorizes what they get, and accounts for what they used - for ISPs, VPNs, and Wi-Fi alike.
Remote Authentication Dial-In User Service; the name remembers modems, the protocol outlived them. RFC 2865 (June 2000) defines a UDP protocol on port 1812 with six codes that matter, Access-Request, Access-Accept, Access-Reject, Access-Challenge and the two accounting packets of RFC 2866 on port 1813, and a packet of Code, Identifier, Length, a 16-octet Authenticator and attributes in type-length-value form: User-Name (1), User-Password (2), NAS-IP-Address (4), Service-Type (6), Framed-IP-Address (8), Reply-Message (18), State (24), Class (25), Vendor-Specific (26), Called- and Calling-Station-Id (30, 31), NAS-Identifier (32), NAS-Port-Type (61) and the EAP-Message (79) and Message-Authenticator (80) of RFC 3579 that carry 802.1X. Its security is a shared secret and MD5: only the User-Password is hidden, by XOR with an MD5 stream of the secret and the request authenticator; the rest of the packet is in the clear, which is the weakness RadSec (RFC 6614) answers by wrapping the whole packet in TLS. RFC 5176 adds the server-initiated Disconnect and Change-of-Authorization messages on UDP 3799. It is the protocol behind every 802.1X port, every enterprise SSID, most VPN logins and most carrier subscriber sessions.
RADIUS was written for terminal servers full of modems and it is still the protocol every switch port, access point and VPN concentrator speaks to the thing that decides. RFC 2865, published in June 2000 by Rigney, Willens, Rubens and Simpson as a Standards Track document obsoleting RFC 2138, defines a client-server protocol over UDP, the server listening on port 1812 (the earlier 1645 had been assigned to another service), in which the network access server is the client and the policy server is the server. A packet is a Code, an Identifier of one octet that "aids in matching requests and replies", a Length between 20 and 4096 octets, a 16-octet Authenticator and a list of attributes. The codes that carry authentication are 1 Access-Request, 2 Access-Accept, 3 Access-Reject and 11 Access-Challenge; the companion RFC 2866 of the same month, by Rigney, defines 4 Accounting-Request and 5 Accounting-Response on port 1813. A NAS sends an Access-Request with what it knows about the session and receives one of the three answers; a Challenge means the server wants another round, which is how multi-step methods and the whole of EAP ride on top.
The attributes are where the protocol's expressiveness lives, and their numbers are worth knowing because packet captures and server logs show them. RFC 2865 assigns User-Name (1), User-Password (2), CHAP-Password (3), NAS-IP-Address (4), NAS-Port (5), Service-Type (6), Framed-Protocol (7), Framed-IP-Address (8), Filter-Id (11), Reply-Message (18), State (24), Class (25), Vendor-Specific (26), Session-Timeout (27), Idle-Timeout (28), Termination-Action (29), Called-Station-Id (30), Calling-Station-Id (31), NAS-Identifier (32), Proxy-State (33) and NAS-Port-Type (61), among others. Vendor-Specific is the escape hatch every vendor used for its own attributes. Class is the server's way of tagging a session so the tag comes back in accounting: the RFC says it "SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported". RFC 3579 added EAP-Message (79) and Message-Authenticator (80), the pair that lets a switch relay an 802.1X conversation it cannot read, and RFC 2868 and RFC 3580 supplied the tunnel attributes, Tunnel-Type (64), Tunnel-Medium-Type (65) and Tunnel-Private-Group-ID (81), that assign a VLAN to an authenticated port. Proxy-State is how a chain of proxies, each appending its own, routes a reply back along the path it came.
Security is where the protocol shows its age, and the RFC is candid about the design. The client and server share a secret that the document says "SHOULD be as unguessable as a well-chosen password" and "MUST NOT be empty". Only the User-Password attribute is hidden: it is XORed, sixteen octets at a time, with an MD5 stream computed from the shared secret and the request's Authenticator. The Access-Reply's Authenticator is an MD5 over the code, identifier, length, request authenticator, attributes and secret, which authenticates the reply to the client; the request itself, apart from Message-Authenticator where present, is unauthenticated, and every attribute except the password travels in clear text, including usernames, MAC addresses and the policy the server returns. Cisco's comparison document states it in one line, "RADIUS encrypts only the password in the access-request packet, from the client to the server. The remainder of the packet is unencrypted." RFC 6614, the RadSec specification, says of the result that "RADIUS security is based on the MD5 algorithm, which has been proven to be insecure" and answers by carrying the whole packet inside TLS over TCP port 2083; the RadSec entry has that story.
The second thing RADIUS was not designed to do is take instructions from the server after the session has started. The base protocol is request-response from the NAS; once an Access-Accept has been issued the server has no voice until the next request. RFC 5176 (January 2008, obsoleting RFC 3576) adds the Dynamic Authorization Extensions: a Disconnect-Request (code 40) that ends a session and a CoA-Request (43) that changes its authorisation, sent by the server side to the NAS on UDP port 3799 and answered with an ACK or NAK (41, 42, 44, 45). That is what lets a policy engine quarantine a device whose posture changed or move it to another VLAN without the user re-authenticating, and the RADIUS CoA entry covers it.
The protocol's other half, accounting, is covered by RFC 2866 and by the accounting entry: Start, Stop and Interim-Update records with octet and packet counters, session time and termination cause, acknowledged by the server and retried by the client with backoff until they are. Against TACACS+ the division of labour is stable: Cisco's own comparison notes that "RADIUS combines authentication and authorization" in one exchange and "does not allow users to control which commands can be executed on a router", so RADIUS owns network access, user and device authentication at the port, the SSID and the VPN, while TACACS+ owns device administration with its per-command authorisation and accounting. The article on RADIUS end to end walks one 802.1X conversation through every field named here.
Also known as: remote authentication dial-in user service, udp 1812, udp 1813, access-request, access-accept, nas
Sources
- RFC 2865, Remote Authentication Dial In User Service (RADIUS), Rigney, Willens, Rubens, Simpson, June 2000, Standards Track: UDP 1812, the codes, the packet fields, the attribute numbers, the User-Password hiding and the response authenticator, the shared secret rules, Class, Proxy-State and the 4096-octet maximum (read 2026-10-06)
- RFC 2866, RADIUS Accounting, Rigney, June 2000, Informational: UDP 1813, Acct-Status-Type values and the accounting attributes, retry with backoff (read 2026-10-06)
- RFC 3579, RADIUS Support For EAP, Aboba and Calhoun, September 2003: EAP-Message (79) and Message-Authenticator (80) (read 2026-10-06)
- RFC 3580, IEEE 802.1X RADIUS Usage Guidelines, September 2003: VLAN assignment with the tunnel attributes, station identifiers, NAS-Port-Type, Session-Timeout (read 2026-10-06)
- Cisco, TACACS+ and RADIUS Comparison (document 13838): UDP against TCP, only the password encrypted, authentication and authorization combined, no per-command control (read 2026-10-06)