RADIUS

RADIUS (Remote Authentication Dial-In User Service) is a client–server protocol that carries authentication, authorization, and accounting (AAA) information between a network access device and a central server, and it remains the de facto AAA standard for dial-up, DSL, wireless, and mobile networks as well as the typical implementation supporting 802.1X access control¹. A network access server (NAS), such as a Wi-Fi controller, VPN gateway, or DSL router, forwards a user's credentials to a RADIUS server and enforces the answer it receives². Essentially all DSL and fiber ISPs use it, and eduroam's global hierarchy of RADIUS servers handled 7.5 billion authentications in 2023 across 100 countries³.

History and standardization

The protocol began with a 1991 request for proposal from Merit Network, which wanted to consolidate the proprietary authentication systems serving its dial-up users. Livingston Enterprises' response, describing RADIUS, won the contract, and Livingston implemented the proto-RADIUS in its PortMaster dial-in server along with a simple RADIUS server to support it¹.

Standardization followed the deployment. A RADIUS working group was established in the IETF in December 1995, chartered only to document and clean up the existing draft; an initial RADIUS RFC was issued in January 1997, and the current standard, RFC 2865, in June 2000^{1 • 5}. A successor protocol, Diameter, was initially proposed as RADIUS v2 and became an IETF standard, but the growth of RADIUS extensions blunted its commercial progress, and RADIUS kept its position as the working standard for dial-up, DSL, wireless, and mobile access¹.

How the protocol works

A RADIUS exchange runs as follows:

1. A user connects to a NAS. The NAS creates an Access-Request containing attributes such as the user's name, the user's password, the ID of the client, and the port being accessed; it also carries the NAS IP address. When a password is present, it is hidden using a method based on the RSA MD5 algorithm^{5 • 2}.
2. The server checks the credentials and replies with Access-Accept, Access-Reject, or, in challenge-based schemes, Access-Challenge³.
3. An Access-Accept carries attribute-value pairs describing the session: service type, IP assignment, access lists, and, in ISP deployments, rate limits, specific IPv4 addresses, IPv6 prefix delegation, or CGNAT (carrier-grade NAT: shared public IPs for many subscribers) address pools^{2 • 4}.
4. The NAS then sends accounting messages at the start and end of the session, reporting resources such as time, packets, and bytes used².

Transport and ports. Communication between the NAS and the server is based on UDP and is generally a connectionless service; retransmission and timeout handling are done by the RADIUS devices themselves rather than by the transport protocol². Early deployment used UDP port 1645, which conflicted with the "datametrics" service, so RFC 2865 assigned port 1812; accounting uses 1813 (legacy 1646), and Change of Authorization (CoA) or Disconnect messages typically use UDP 3799^{5 • 4}.

Accounting and CoA. RFC 2866 extends the protocol to deliver accounting information from the NAS to the server⁷. Accounting can be used independently of authentication or authorization, and the session records, with start time, stop time, and bytes in and out, feed usage reporting, billing, and data-cap enforcement^{2 • 4}. With CoA, the RADIUS side can push a change into a live session, such as upgrading the speed, suspending the account, or redirecting to a payment page, without dropping the connection⁴.

Security properties and limitations

Classic RADIUS protects very little. Transactions between client and server are authenticated with a shared secret that is never sent over the network, and user passwords are encrypted between client and server to prevent snooping⁵. But most attributes are sent in clear text; only a few, such as User-Password and Tunnel-Password, have their contents hidden, and even with the Message-Authenticator attribute an observer can brute-force shared secrets⁶. Integrity relies on MD5, an algorithm the IETF describes as proven insecure⁹.

Blast-RADIUS. In 2024 researchers published a chosen-prefix MD5 collision attack against the Response Authenticator, recorded by NVD as CVE-2024-3596: an on-path attacker can modify any valid response (Access-Accept, Access-Reject, or Access-Challenge) into any other, for flows that do not use the Message-Authenticator attribute^{3 • 8}. Subject to those limitations, the IETF draft states that attackers can cause any user to be authenticated and given any authorization, that multifactor authentication systems can be bypassed, and that the RADIUS server will in many cases not even be aware an unauthorized user is on the network⁶. FreeRADIUS's July 9, 2024 notification stressed that mitigating the attack requires updating all RADIUS servers and all RADIUS clients, because it relies on a design flaw in the protocol¹⁴.

Mitigations. The IETF draft is direct: there is no way to fix the RADIUS protocol itself, and the only complete solution is to wrap it in a secure transport such as TLS or IPsec; all systems sending RADIUS outside secure networks must use IPsec, RADIUS/TLS, or RADIUS/DTLS, with the TLS-based transports recommended⁶. Administrators should use shared secrets of at least 24 octets generated from a source of secure random numbers⁶. Cloudflare, whose researchers participated in the work, calls RADIUS over TLS the best mitigation and notes that many more vendors now offer it following the research¹⁵. Systems performing only EAP authentication, such as 802.1X/WPA enterprise, are not vulnerable, because the master session keys are obfuscated and not visible to on-path attackers⁶.

Secure transports: RADSEC, DTLS, and RADIUS/1.1

RADIUS over TLS, commonly called RadSec, wraps the entire RADIUS packet payload into a TLS stream, mitigating the risk of attacks on MD5, and replaces IP-address-and-shared-secret peer identification with certificate-based trust; it typically runs on TCP port 2083^{9 • 11}. Additional transports were defined for TCP (RFC 6613) and DTLS (RFC 7360), but those still used MD5 underneath¹⁰. The push for crypto-agility, mandated as future work by RFC 6421, produced these transports, which had been in widespread use for about a decade, including in eduroam and OpenRoaming, before the 2024 attack⁶.

Adoption nonetheless lagged. The first hop between a NAS and its RADIUS server is "almost always" over UDP; only rare security-oriented organizations use RADIUS/TLS internally, and a majority of country eduroam networks still send RADIUS/UDP over the internet³. RFC 9765 (2025) defines RADIUS/1.1, an Application-Layer Protocol Negotiation extension for RADIUS over (D)TLS that removes the need to use MD5, with no changes to UDP or TCP transport¹⁰. In the FreeRADIUS implementation, RadSec support arrived in version 3.0.0 in 2013¹⁶.

By the numbers

• Ports: UDP 1812 (authentication), UDP 1813 (accounting), legacy 1645/1646, CoA/Disconnect on UDP 3799, RadSec on TCP 2083^{4 • 11}.
• eduroam: 7.5 billion authentications in 2023 across 100 countries³.
• FreeRADIUS, November 2006 survey (over 500 responses): about 100 million users authenticated daily, roughly a third of internet users at the time, across more than 50,000 sites ranging from 10 users to over 10 million; among other servers, Cisco ACS held 24% and Microsoft IAS 23%¹².
• A studied organization of about 80,000 affiliates used Cisco ISE with RADIUS/UDP and PAP for VPN and Wi-Fi, with about 90,000 active RADIUS connections at a time and 300,000 clients over a typical five-day period³.
• Before open-source competition, commercial RADIUS servers such as Steel-Belted RADIUS sold for $50,000 to $100,000 or more per server license; large national ISPs now run FreeRADIUS with 10M to 20M users¹⁷.

How it compares with TACACS+ and Diameter

TACACS+ is the other long-lived AAA protocol. RADIUS uses UDP with best-effort delivery while TACACS+ uses TCP, which offers connection-oriented transport¹³. RADIUS encrypts only the password in the access-request packet, leaving the rest unencrypted, while TACACS+ encrypts the entire body of the packet except a standard header¹³. RADIUS combines authentication and authorization in Access-Accept packets, whereas TACACS+ separates the three AAA functions, effectively making it a suite of three protocols^{13 • 18}. RADIUS does not allow control over which commands can be executed on a router, so it is less useful for router management; TACACS+ is today mainly confined to Device Administration, authenticating access to network devices, providing central authorization of operations, and auditing them^{13 • 18}. TACACS+ runs on TCP port 49, and it cannot replace RADIUS for network access because it does not support 802.1X, end-user authentication, or end-user accounting^{19 • 6}. Juniper's guidance is to use RADIUS for semi-trusted environments and TACACS+ for trusted environments¹⁹.

Diameter is the closest protocol in functionality to RADIUS, but its use case is large-scale telecommunications and ISPs; it runs over TCP or SCTP, offers no security over TCP by default, and 5G replaced it with HTTP/2 signaling^{6 • 3}. With an estimated millions of RADIUS/UDP devices still in daily use, Diameter never displaced RADIUS for enterprise and ISP access⁶.

Applications and deployments

802.1X and Wi-Fi. IEEE 802.1X port-based network access control specifies the use of EAP with a centrally administered authentication server, and access controls bound to the results of authentication are distributed via AAA protocols such as Diameter or RADIUS; 802.1X mutual authentication also distributes the master keys used by IEEE 802.11 to protect wireless data frames²⁰. When RADIUS carries EAP, RFC 3580 requires the Message-Authenticator attribute to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute, so RADIUS packets containing an EAP-Message attribute are authenticated and integrity protected²¹. Attributes in the exchange describe the session: the Access-Request carries attributes such as the username and NAS IP address and port; when a password is present, it is hidden using an MD5-based method².

Roaming and proxy chains. A RADIUS proxy can be employed to route authentication and accounting requests; to the NAS, the proxy appears to act as a RADIUS server²². eduroam, created by the European research and education community in 2002, grew to more than 10,000 service locations serving millions of users on all continents except Antarctica, with a federation trust fabric based on RADIUS and trust resting on shared secrets between RADIUS peers²³. A hierarchical system of RADIUS servers transports each authentication request from the visited institution to the user's home institution and the response back; eduroam supports transport over RADIUS/UDP and RADIUS/TLS and recommends RADIUS/TLS, with dynamic DNS-based routing supported only over RADIUS/TLS²⁴.

ISP operations. ISPs use RADIUS access control and accounting for security and billing: Access-Accept attributes provision the subscriber's service parameters, and the router streams back session records with start time, stop time, and bytes in and out^{2 • 4}.

Products. The major server implementations include FreeRADIUS, the long-dominant open-source server and the typical implementation behind eduroam; Cisco ISE (whose predecessor Cisco ACS held 24% among other RADIUS servers in the 2006 survey); and Microsoft NPS (whose predecessor IAS held 23% among other RADIUS servers in the same survey)^{12 • 16}. FreeRADIUS version 2.0.0 (2008) added virtual servers, IPv6, and a policy language, and version 3.0.0 (2013) added RadSec¹⁶.

References

1. The Beginnings and History of RADIUS, Interlink Networks (Merit Network participant account)
2. Examine How RADIUS Works, Cisco
3. RADIUS/UDP Considered Harmful (Blast-RADIUS), USENIX Security 2024
4. What Is a RADIUS Server? A Practical Guide for ISPs, ISPbox
5. RFC 2865: Remote Authentication Dial In User Service (RADIUS), IETF
6. Deprecating Insecure Practices in RADIUS, IETF Internet-Draft
7. RFC 2866: RADIUS Accounting, IETF
8. NVD entry for CVE-2024-3596, NIST
9. RFC 6614: Transport Layer Security (TLS) Encryption for RADIUS, IETF
10. RFC 9765: RADIUS/1.1 — ALPN to Remove MD5, IETF
11. Migrating from On-Premises RADIUS (NPS), Purple Security
12. About Us — FreeRADIUS (November 2006 survey)
13. Compare TACACS+ and RADIUS, Cisco
14. BlastRADIUS notification, FreeRADIUS, July 9, 2024
15. RADIUS/UDP vulnerable to improved MD5 collision attack, Cloudflare Blog
16. FreeRADIUS — Authenticates about a third of the people on the internet, Ronutz
17. A $500 million industry toppled with free software, Inkbridge Networks
18. RFC 8907: The TACACS+ Protocol, IETF
19. Understanding Central Network Access Using RADIUS and TACACS+, Juniper Networks
20. IEEE Std 802.1X-2020, Port-Based Network Access Control
21. RFC 3580: IEEE 802.1X RADIUS Usage Guidelines, IETF
22. RFC 2607: Proxy Chaining and Policy Implementation in Roaming, IETF
23. RFC 7593: The eduroam Architecture for Network Roaming, IETF
24. eduroam Policy Service Definition

Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Networks and security › Network defense and threats › Firewalls and perimeter defense

Initially written Sep 17, 2026 · Reviewed: Sep 30, 2026; Oct 15, 2026 · Edited: Sep 30, 2026; Oct 15, 2026 · Last review: Oct 15, 2026

© 2026 EdgeChat AI, a subsidiary of Biostate AI. Free to use with credit under the Edgepedia Community License. Developers: read Edgepedia by API or MCP. Embed a reference card.