RADIUS
RADIUS, or Remote Authentication Dial-In User Service, is a client/server networking protocol that enables centralized Authentication, Authorization, and Accounting (AAA) management for users connecting to and utilizing network services, primarily through remote access servers like Network Access Servers (NAS).[1] Developed in 1991 by Livingston Enterprises for the Merit Network to handle dial-in access across points of presence (POPs), it has evolved into a de facto industry standard for securing network access in diverse environments, including ISPs, enterprises, universities, and cellular providers.[2][3] In operation, a RADIUS client—typically a NAS or similar device—intercepts user connection attempts and forwards authentication requests, including credentials via protocols like PAP or CHAP, to a central RADIUS server using UDP port 1812 for authentication/authorization and 1813 for accounting.[1] The server verifies the user's identity against a database, determines access permissions and session parameters, and responds with an accept, reject, or challenge message, while also logging usage data for billing, auditing, or policy enforcement.[2] Security relies on a shared secret between client and server to protect passwords and certain sensitive attributes (e.g., via MD5 obfuscation), though the protocol assumes trusted network paths and has known vulnerabilities like lack of IPsec support, including the 2024 Blast-RADIUS vulnerability (CVE-2024-3596) enabling packet forgery, prompting extensions for modern threats.[3][4] Standardized by the Internet Engineering Task Force (IETF) as RFC 2865 for authentication and authorization in 2000, and RFC 2866 for accounting, RADIUS supports extensible attributes for flexibility, integrating with protocols like EAP for advanced authentication (e.g., in 802.1X wired/wireless networks) and directory services such as Microsoft Active Directory.[5] Its advantages include simplified administration through centralized user profiles, enhanced security by offloading authentication from access devices, and scalability for large deployments via proxies, though it was originally designed for dial-up scenarios and may require adaptations for high-traffic or untrusted networks.[2] Today, RADIUS underpins VPNs, Wi-Fi access, and network access control, remaining widely implemented due to its open design and vendor interoperability.[1]Fundamentals
Definition and Purpose
RADIUS, or Remote Authentication Dial-In User Service, is a client-server networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users connecting to IP-based networks.[5] In this model, a Network Access Server (NAS) acts as the client, forwarding user credentials and connection details to a remote RADIUS server, which processes the request and responds with access decisions and configuration parameters.[5] The primary purpose of RADIUS is to enable secure and scalable control over network access by centralizing user validation and resource allocation, supporting services such as dial-up connections, virtual private networks (VPNs), and Wi-Fi authentication.[1] This allows organizations to manage authentication for remote users from a single point, reducing administrative overhead and enhancing security consistency across diverse access points like modems, routers, and wireless access points.[1] Key use cases involve NAS devices querying RADIUS servers to verify user identities before granting access to network resources.[5] Historically, RADIUS was developed in the early 1990s as a more standardized alternative to earlier protocols like TACACS for handling AAA in growing IP networks, emphasizing a UDP-based, stateless design to support high-volume, scalable operations without the overhead of connection-oriented protocols. Developed by Livingston Enterprises in the early 1990s and standardized by the IETF in RFC 2865, its lightweight architecture facilitates rapid transaction processing, making it suitable for environments with thousands of concurrent users.[5][1]AAA Framework
The AAA (Authentication, Authorization, and Accounting) framework provides a structured approach to network access control, where authentication verifies the identity of a user or device attempting to connect, authorization determines the specific permissions and resources granted to that entity, and accounting records usage details for billing, auditing, or security analysis.[6] In the context of RADIUS, this model enables centralized management of remote access, distinguishing it from decentralized systems where each network access server (NAS) might handle credentials independently, potentially leading to inconsistencies and heightened security risks.[6] RADIUS implements the AAA framework through a client-server architecture, with the NAS functioning as the client that forwards user credentials to a central RADIUS server for processing.[6] Upon a user's connection attempt, the NAS encapsulates the provided identity information—such as a username and password—into an Access-Request message and transmits it to the RADIUS server over UDP.[7] The server then authenticates the user against a centralized database, authorizes access by evaluating policies, and responds with an Access-Accept (including attributes for session parameters), Access-Reject, or Access-Challenge message to prompt further verification if needed.[7] For accounting, RADIUS supports tracking session start, stop, and interim updates via separate Accounting-Request messages, which the server logs for resource monitoring. This centralized approach in RADIUS offers key advantages over decentralized authentication, including simplified administration through a single user database that enforces consistent policies across distributed networks, reduced exposure of sensitive credentials on individual NAS devices, and enhanced scalability for large-scale deployments.[6] By consolidating AAA functions on the server, organizations can more effectively manage access control without the fragmentation risks of local authentication methods.[8]Protocol Operation
Authentication and Authorization
In the RADIUS protocol, authentication begins when a Network Access Server (NAS) receives a connection request from a user or device and forwards an Access-Request packet (Code 1) to the RADIUS server, including the User-Name attribute and credentials such as User-Password for Password Authentication Protocol (PAP) or CHAP-Password and CHAP-Challenge for Challenge-Handshake Authentication Protocol (CHAP).[9][10][11] The RADIUS server validates these credentials against a back-end user database, such as LDAP directories or SQL databases, to verify the user's identity.[12][13] Upon successful validation, the server responds with an Access-Accept packet (Code 2), granting access; if validation fails, it sends an Access-Reject (Code 3); or for multi-round authentication, an Access-Challenge (Code 11) prompting the NAS to solicit additional user input, which is then resent in a new Access-Request with a State attribute to track the exchange.[9][14] RADIUS supports extensible authentication via the Extensible Authentication Protocol (EAP), encapsulated in Access-Request and Access-Challenge packets, enabling advanced methods like EAP-TLS or EAP-TTLS for certificate-based or tunneled authentication.[15] Microsoft-specific extensions, such as MS-CHAP, are handled through vendor-specific attributes (VSAs) in Access-Requests, providing enhanced challenge-response security compatible with Windows environments.[16] Authorization occurs concurrently with or immediately following authentication, where the Access-Accept packet includes Attribute-Value Pairs (AVPs) defining the user's permissions and session parameters, such as Service-Type to assign roles like "Framed User" for dial-in access or "Administrative User" for management privileges.[17] For network segmentation, Tunnel-Type and Tunnel-Medium-Type AVPs enable dynamic VLAN assignment, directing the user to a specific virtual LAN based on policy.[18] Session controls are enforced via attributes like Session-Timeout for maximum service duration or Idle-Timeout for inactivity thresholds, while Quality of Service (QoS) policies are applied through Filter-Id, referencing access control lists or bandwidth limits stored in the back-end system.[19][20] These authorization details ensure granular control over resource allocation without requiring separate protocols.[7]Accounting
In the RADIUS protocol, accounting begins after successful authentication and authorization, with the Network Access Server (NAS) initiating the process by sending an Accounting-Request packet of type Start to the accounting server, marking the beginning of the user's session.[21] This packet includes initial session details, such as the user's identifier and the NAS's IP address or identifier.[22] During the session, the NAS may send Interim-Update Accounting-Request packets to provide periodic updates on resource usage, followed by a Stop Accounting-Request packet upon session termination, which includes final statistics.[21] The accounting server confirms receipt of each request with an Accounting-Response packet containing a status indicator, ensuring reliable logging.[23] Key data captured in these packets encompasses session metrics like the total bytes transferred (via Acct-Input-Octets and Acct-Output-Octets attributes), packet counts (Acct-Input-Packets and Acct-Output-Packets), session duration (Acct-Session-Time), and timestamps for connection start and disconnect events, alongside NAS-specific identifiers for traceability.[24] These elements enable detailed tracking of user activity without interrupting service delivery.[25] RADIUS accounting supports critical use cases including billing based on usage, auditing for compliance and security reviews, and capacity planning to monitor network load and resource allocation.[25] To enhance reliability, implementations allow configuration of multiple accounting servers, where the NAS can retry requests on alternates using round-robin or failover mechanisms if the primary server is unavailable.[21] In cases of transmission failures, the NAS retransmits Accounting-Request packets with exponential backoff until confirmation or a timeout, preventing data loss while avoiding network congestion; if the server cannot record the data, it may withhold the Accounting-Response to signal the issue.[21]Session Management
RADIUS supports ongoing management of user sessions through extensions that enable dynamic communication between the Network Access Server (NAS) and the RADIUS server after initial authentication. These extensions, defined in the Dynamic Authorization protocol, allow for unsolicited messages such as Change-of-Authorization (CoA) requests and Disconnect messages to handle periodic re-authentication and session modifications. A CoA-Request can trigger re-authentication by including a Service-Type attribute set to "Authorize Only," prompting the NAS to send a new Access-Request to verify the user's continued eligibility. Similarly, Disconnect-Request messages initiate immediate session termination without requiring further accounting updates from the NAS.[26] Session attributes in RADIUS provide mechanisms for controlling active connections, including idle timeouts and limits on simultaneous use. The Idle-Timeout attribute specifies the maximum period of inactivity before a session is terminated, helping to free resources for inactive users. Session-Timeout sets the overall maximum duration of a session in seconds. Dynamic updates to these and other authorizations, such as filter rules or IP address assignments, can be applied via CoA-Requests, which modify the session parameters atomically—if any change fails, the entire update is rejected with a CoA-NAK. Simultaneous use limits are enforced by the RADIUS server, which tracks active sessions for a user (often via backend databases) and rejects additional authentications exceeding the configured threshold, despite the protocol's core statelessness.[5][26] Session termination in RADIUS involves coordinated actions to ensure clean endpoint handling. Upon receiving a Disconnect-Request, the NAS immediately ends the session and responds with a Disconnect-ACK, including an Acct-Terminate-Cause attribute to indicate the reason, such as administrative reset or idle timeout. Accounting records, generated via Accounting-Stop messages, capture session duration and termination details for auditing, with the Class attribute passing opaque data from authorization to accounting packets to maintain continuity. Forced disconnections occur if the NAS cannot identify the session, resulting in a Disconnect-NAK with an appropriate error cause.[26][5] The stateless design of RADIUS enhances scalability for session management by avoiding per-user state tracking on the server. Each request-response pair operates independently over UDP, allowing the server to handle multiple concurrent sessions without maintaining connection state, which reduces memory overhead and supports large-scale deployments. The NAS bears the responsibility for session tracking, periodically querying the server as needed for updates or terminations, while retransmission logic ensures reliability without persistent sessions.[5]Packet Format
Overall Structure
RADIUS packets are encapsulated within User Datagram Protocol (UDP) datagrams for transmission between clients and servers, utilizing UDP port 1812 for authentication and authorization packets and port 1813 for accounting packets.[5][27] The overall packet structure consists of a fixed 20-octet header followed by a variable-length sequence of attributes, with the total packet length ranging from a minimum of 20 octets to a maximum of 4096 octets.[5] This design ensures efficient, lightweight communication suited to the protocol's role in the AAA (Authentication, Authorization, and Accounting) framework, where packets carry requests and responses for user access control and resource tracking.[5] The header begins with the Code field, a single octet that specifies the packet type, such as 1 for Access-Request (initiating authentication and authorization) or 4 for Accounting-Request (submitting usage data).[5][27] Following the Code is the Identifier field, also one octet, which pairs requests with their corresponding responses in a stateless manner, allowing the server to match replies without maintaining session state.[5] The Length field, two octets in network byte order, indicates the total size of the packet including the header and all attributes, ensuring proper parsing even if the UDP datagram is padded.[5] The header concludes with the 16-octet Authenticator field, which provides message integrity and supports request-response verification through a shared secret known only to the client and server.[5] In operation, the Authenticator is generated as a pseudo-random value for requests and computed as an MD5 hash of the packet contents combined with the shared secret for responses, preventing tampering and enabling encrypted transport of sensitive data like passwords.[5] RADIUS supports two primary message categories: access packets for authentication and authorization (e.g., Access-Request, Access-Accept, Access-Reject) and accounting packets (e.g., Accounting-Request, Accounting-Response), each leveraging the same header format but distinguished by their Code values.[5][27] This uniform structure facilitates interoperability across diverse network environments while relying on the shared secret—never transmitted over the network—for security.[5]Attribute Value Pairs
Attribute Value Pairs (AVPs) form the flexible payload of RADIUS packets, consisting of a sequence of encoded attributes that carry authentication, authorization, and accounting information between the Network Access Server (NAS) and the RADIUS server.[9] These pairs are encoded in a Type-Length-Value (TLV) format, allowing for extensible data transmission within the variable-length portion of the packet following the fixed header.[9] The AVP format begins with a one-octet Type field, which identifies the attribute (ranging from 0 to 255 for standard types), followed by a one-octet Length field specifying the total length of the AVP in octets (minimum 3, maximum 255).[28] The Value field then occupies the remaining octets (up to 253), containing the attribute-specific data; if the actual value is shorter, the unused portion is padded with zeros, though only octets up to the specified Length are processed.[28] AVPs are optional in some contexts but must appear in multiples if needed, and the packet's total length accounts for all AVPs following the 20-octet header.[9] Encoding rules for AVP values vary by data type to ensure interoperability. Text strings are encoded as 1 to 253 octets of UTF-8 characters from ISO 10646, without null termination or padding beyond the Length.[9] Binary strings treat the value as raw octets, also 1 to 253 long, with no interpretation imposed.[9] IP addresses and similar 32-bit values use four octets in network byte order (most significant octet first), such as for IPv4 addresses.[9] Integers are 32-bit unsigned values, similarly in network byte order, while multi-octet values like dates are represented as seconds since January 1, 1970 UTC.[9] Padding ensures alignment but is ignored if it exceeds the Length field.[28] Several standard AVPs are defined in the IETF specifications for core RADIUS operations. For instance, User-Name (Type 1) carries the user's identity as a text string, such as "user@example.com," and is typically required in Access-Request packets if known.[29] User-Password (Type 2) conveys the user's password as a string of 16 to 128 octets, encrypted using a shared secret and MD5 hashing for transmission in Access-Request messages.[10] NAS-IP-Address (Type 4) specifies the IP address of the NAS as a four-octet address value, mandatory in Access-Request packets from IPv4-enabled NAS devices.[30] Service-Type (Type 6) indicates the type of service requested or granted as a 32-bit integer, with values like 2 for Framed (e.g., PPP sessions) used in both Access-Request and Access-Accept packets.[17] Framed-IP-Address (Type 8) assigns an IPv4 address to the user as a four-octet value, such as 192.0.2.1, and appears in Access-Accept responses or optionally in requests.[31] In RADIUS protocol exchanges, AVPs serve to encapsulate essential data without fixed positions, enabling dynamic conveyance of user credentials like User-Name and User-Password in authentication requests, as well as authorization policies such as Service-Type and Framed-IP-Address in responses.[32] They also report status information, for example, in Access-Reject or Access-Challenge packets, supporting the AAA framework's need for modular information transfer across diverse network access scenarios.[28]| Attribute Name | Type | Value Type | Description | Example Value |
|---|---|---|---|---|
| User-Name | 1 | String (1-253 octets) | User's identity | "[email protected]" |
| User-Password | 2 | String (16-128 octets, encrypted) | Encrypted user password | MD5-hashed "secret" with shared key |
| NAS-IP-Address | 4 | IP Address (4 octets) | NAS IPv4 address | 192.0.2.15 |
| Service-Type | 6 | Integer (4 octets) | Type of service | 2 (Framed) |
| Framed-IP-Address | 8 | IP Address (4 octets) | Assigned user IP | 198.51.100.44 |
Deployment Features
Roaming
RADIUS roaming enables authenticated users to access network services from foreign or visited networks by querying their home RADIUS server for validation, rather than requiring local accounts at each provider. This mechanism supports user mobility across different administrative domains, where the local Network Access Server (NAS) in the visited network forwards authentication requests to the user's home RADIUS server, typically through intermediary proxies or routing services. For instance, implementations like those from GRIC and i-PASS demonstrate this by routing requests based on the user's identity format, ensuring centralized credential management at the home provider.[33] In inter-domain operations, the home RADIUS server performs authentication and authorization on behalf of the visited network, facilitating federated authentication models. This process relies on the user's identity including a realm identifier (e.g., [email protected]) to direct queries to the appropriate home server. Such federation allows seamless validation without sharing sensitive user data between providers, as seen in early roaming alliances like Microsoft Network and Merit, which proxy requests across interconnected ISPs.[33] The primary benefits of RADIUS roaming include enhanced user mobility for applications like Wi-Fi and VPN access, reducing the need for multiple subscriptions and enabling global connectivity. For example, it supports seamless transitions between hotspots operated by different providers, improving service continuity for mobile users. However, challenges arise from latency introduced by cross-provider queries and proxy chains, which can delay authentication; some implementations mitigate this with caching mechanisms, such as three-day caches in systems like ChinaNet, though this trades off security for performance.[33] In modern applications, RADIUS roaming integrates with Wi-Fi alliances like eduroam, providing global academic network access across thousands of institutions. Eduroam leverages IEEE 802.1X, EAP, and RADIUS to route authentication requests hierarchically based on user realms, supporting millions of users with secure, privacy-preserving federated authentication. This setup ensures visitors from participating networks can connect automatically to any eduroam hotspot worldwide, using their home credentials without local registration.[34]Realms
In RADIUS, a realm serves as a domain identifier appended to a username in the User-Name attribute, typically in the form of a Network Access Identifier (NAI) such as[email protected], where example.com denotes the realm responsible for authentication.[29][35] This structure allows the Network Access Server (NAS) or an intermediate proxy to identify the appropriate authentication server without requiring prior knowledge of all possible usernames. The realm portion, defined as a UTF-8 encoded Fully Qualified Domain Name (FQDN), enables logical separation of administrative domains in multi-provider environments.[35]
When processing an Access-Request packet, the NAS or proxy examines the realm in the NAI to determine routing. If the realm matches a locally configured domain, the proxy typically strips the realm from the username (e.g., converting [email protected] to user) and handles authentication internally or forwards to a local server.[36] For remote realms, the full NAI is preserved and routed unchanged to the next-hop server based on a pre-configured routing table that maps realm suffixes to target IP addresses, ports, or DNS records; intermediate proxies must not modify the realm to maintain integrity.[37] This process supports nested realms, such as [email protected], where routing rules can match hierarchical suffixes (e.g., falling back to us.example.com if no exact match exists), allowing scalable delegation in complex organizational structures.[38]
Configuration of realms occurs via proxy server rules that define matching patterns, such as exact realm names, suffixes, or regular expressions, to decide between local processing and remote forwarding.[36] These rules often include options for attribute manipulation to strip or rewrite realms, with fallback mechanisms directing unmatched requests to a default realm or local authentication if no remote server is specified.[36] For instance, a policy might route all requests ending in .example.com to a specific server group while treating realm-less usernames as belonging to a default local domain.
Realms play a crucial role in enabling seamless roaming by directing authentication requests to the user's home realm server, even when the NAS operates in a visited network, thus supporting inter-domain access without exposing full user details across proxies.[39] This mechanism ensures efficient request delegation in federated environments, such as wireless service provider consortia, where users from one realm authenticate via another's infrastructure.