Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralised Authentication, Authorization, and Accounting (AAA or Triple A) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises, Inc. in 1991 as an access server authentication and accounting protocol and later brought into the Internet Engineering Task Force (IETF) standards.

Because of the broad support and the ubiquitous nature of the RADIUS protocol, it is often used by ISPs and enterprises to manage access to the Internet or internal networks, wireless networks, and integrated e-mail services. These networks might incorporate modems, DSL, access points, VPNs, network ports, web servers, etc.

RADIUS is a client/server protocol that runs in the application layer, and can use either TCP or UDP as transport. Network access servers, the gateways that control access to a network, usually contain a RADIUS client component that communicates with the RADIUS server. RADIUS is often the back-end of choice for 802.1X authentication as well.

The RADIUS server is usually a background process running on a UNIX or Microsoft Windows server.

Protocol components

RADIUS is an AAA protocol which manages network access in the following two-step process, additionally known as a AAA transaction. AAA stands for authentication, authorization and accounting. Authentication and authorization characteristics in RADIUS are described in while accounting is described by .

Authentication and authorization

The user or machine sends a request to a Network Access Server (NAS) to gain access to a particular network resource using access credentials. The credentials are passed to the NAS device via the link-layer protocol - for example, Point-to-Point Protocol (PPP) in the case of a large number of dialup or DSL providers or posted in an HTTPS secure web form.

In turn, the NAS sends a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol.

This request includes access credentials, typically in the form of username and password or security certificate provided by the user. Additionally, the request might contain additional information which the NAS knows about the user, such as its network address or phone number, and information regarding the user's physical point of attachment to the NAS.

The RADIUS server cheques that the information is correct using authentication schemes such as PAP, CHAP or EAP. The user's proof of identification is verified, along with, optionally, additional information related to the request, such as the user's network address or phone number, account status, and specific network service access privileges. Historically, RADIUS servers checked the user's information against a locally stored flat file database. Modern RADIUS servers can do this, or can refer to external sources — commonly SQL, Kerberos, LDAP, or Active Directory servers — to verify the user's credentials.

The RADIUS server then returns one of three responses to the NAS : 1) Access Reject, 2) Access Challenge, or 3) Access Accept.

  • Access Reject - The user is unconditionally denied access to all requested network resources. Reasons might include failure to provide proof of identification or an unknown or inactive user account.
  • Access Challenge - Requests additional information from the user such as a secondary password, PIN, token, or card. Access Challenge is additionally used in more complex authentication dialogues where a secure tunnel is established between the user machine and the Radius Server in a way that the access credentials are hidden from the NAS.
  • Access Accept - The user is granted access. Once the user is authenticated, the RADIUS server will often cheque that the user is authorised to use the network service requested. A given user might be allowed to use a company's wireless network, but not its VPN service, for example. Again, this information might be stored locally on the RADIUS server, or might be looked up in an external source such as LDAP or Active Directory.

Each of these three RADIUS responses might include a Reply-Message attribute which might give a reason for the rejection, the prompt for the challenge, or a welcome message for the accept. The text in the attribute can be passed on to the user in a return web page.

Authorization attributes are conveyed to the NAS stipulating terms of access to be granted. For example, the following authorization attributes might be included in an Access-Accept:

  • The specific IP address to be assigned to the user
  • The address pool from which the user's IP should be chosen
  • The maximum length of time that the user might remain connected
  • An access list, priority queue or additional restrictions on a user's access
  • L2TP parameters
  • VLAN parameters
  • Quality of Service (QoS) parameters

When a client is configured to use RADIUS, any user of the client presents authentication information to the client. This might be with a customizable login prompt, where the user is expected to enter their username and password. Alternatively, the user might use a link framing protocol such as the Point-to-Point Protocol (PPP), which has authentication packets which carry this information.

Once the client has obtained such information, it might choose to authenticate using RADIUS. To do so, the client creates an "Access- Request" containing such Attributes as the user's name, the user's password, the ID of the client and the Port ID which the user is accessing. When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5.

Accounting

RADIUS Accounting Flow

Accounting is described in .

When network access is granted to the user by the NAS, an Accounting Start (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "start") is sent by the NAS to the RADIUS server to signal the start of the user's network access. "Start" records typically contain the user's identification, network address, point of attachment and a unique session identifier.

Periodically, Interim Update records (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "interim-update") might be sent by the NAS to the RADIUS server, to update it on the status of an active session. "Interim" records typically convey the current session duration and information on current data usage.

Finally, when the user's network access is closed, the NAS issues a final Accounting Stop record (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "stop") to the RADIUS server, providing information on the final usage in terms of time, packets transferred, data transferred, reason for disconnect and additional information related to the user's network access.

Typically, the client sends Accounting-Request packets until it receives an Accounting-Response acknowledgement, using a few retry interval.

The primary purpose of this data is that the user can be billed accordingly; the data is additionally commonly used for statistical purposes and for general network monitoring.

Roaming

Roaming using a proxy RADIUS AAA server.

RADIUS is commonly used to facilitate roaming between ISPs, for example:

  • by companies which provide a single global set of credentials that are usable on a large number of public networks;
  • by independent, but collaborating, institutions issuing their own credentials to their own users, that allow a visitor from one to another to be authenticated by their home institution, such as in eduroam.

RADIUS facilitates this by the use of realms, which identify where the RADIUS server should forward the AAA requests for processing.

Realms

A realm is commonly appended to a user's user name and delimited with an '@' sign, resembling an email address domain name. This is known as postfix notation for the realm. An Additional common usage is prefix notation, which involves prepending the realm to the username and using '' as a delimiter. Modern RADIUS servers allow any character to be used as a realm delimiter, although in practise '@' and '' are usually used.

Realms can additionally be compounded using both prefix and postfix notation, to allow for complicated roaming scenarios; for example, somedomain.comusername@anotherdomain.com can be a valid username with two realms.

Although realms often resemble domains, it is important to note that realms are in fact arbitrary text and need not contain real domain names. Realm formats are standardised in , which defines a Network Access Identifier (NAI) in the form of 'user@realm'. In that specification, the 'realm' portion is required to be a domain name. Notwithstanding this practise isn't always followed. replaced in May 2015.

Proxy operations

When a RADIUS server receives an AAA request for a user name containing a realm, the server will reference a table of configured realms. If the realm is known, the server will then proxy the request to the configured home server for that domain. The behaviour of the proxying server regarding the removal of the realm from the request ("stripping") is configuration-dependent on most servers. In addition, the proxying server can be configured to add, remove or rewrite AAA requests when they're proxied over time again.

Proxy Chaining is possible in RADIUS and authentication/authorization and accounting packets are usually routed between a NAS Device and a Home server through a series of proxies. Some of advantages of using Proxy chains include scalability improvements, policy implementations and capability adjustments. But in roaming scenarios, the NAS, Proxies and Home Server can be typically managed by different administrative entities. Hence, the trust factor among the proxies gains more significance under such Inter-domain applications. Further, the absence of end to end security in RADIUS adds to the criticality of trust among the Proxies involved. Proxy Chains are explained in .

Security

Roaming with RADIUS exposes the users to various security and privacy concerns. More generally, a few roaming partners establish a secure tunnel between the RADIUS servers to ensure that users' credentials can't be intercepted while being proxied across the internet. This is a concern as the MD5 hash built into RADIUS is considered insecure.

Packet structure

RADIUS packet data format.

The RADIUS packet data format is shown to the right. The fields are transmitted from left to right, starting with the code, the identifier, the length, the authenticator and the attributes.

RADIUS Codes (decimal) are assigned as follows:

CodeAssignment
1Access-Request
2Access-Accept
3Access-Reject
4Accounting-Request
5Accounting-Response
11Access-Challenge
12Status-Server (experimental)
13Status-Client (experimental)
255Reserved

The Identifier field aids in matching requests and replies.

The Length field indicates the length of the entire RADIUS packet including the Code, Identifier, Length, Authenticator and optional Attribute fields.

The Authenticator is used to authenticate the reply from the RADIUS server, and is used in encrypting passwords; its length is 16 bytes.

Attribute value pairs

RADIUS AVP layout

The RADIUS Attribute Value Pairs (AVP) carry data in both the request and the response for the authentication, authorization, and accounting transactions. The length of the radius packet is used to determine the end of the AVPs.

Vendor-specific attributes

RADIUS is extensible; a large number of vendors of RADIUS hardware and software implement their own variants using Vendor-Specific Attributes (VSAs). Microsoft has published a few of their VSAs. VSA definitions from a large number of additional companies remain proprietary and/or ad-hoc, nonetheless a large number of VSA dictionaries can be found by downloading the source code of open source RADIUS implementations, for example FreeRADIUS or openRADIUS.

Security

The RADIUS protocol transmits obfuscated passwords using a shared secret and the MD5 hashing algorithm. As this particular implementation provides only weak protection of the user's credentials, additional protection, such as IPsec tunnels or physically secured data-center networks, should be used to further protect the RADIUS traffic between the NAS device and the RADIUS server. Additionally, the user's security credentials are the only part protected by RADIUS itself, yet additional user-specific attributes such as tunnel-group IDs or vlan memberships passed over RADIUS might be considered sensitive (helpful to an attacker) or private (sufficient to identify the individual client) information as well. The RadSec protocol claims to solve aforementioned security issues.

History

RADIUS was originally specified in an RFI by Merit Network in 1991 to control dial-in access to NSFnet. Livingston Enterprises responded to the RFI with a description of a RADIUS server. Merit Network awarded the contract to Livingston Enterprises that delivered their PortMaster series of Network Access Servers and the initial RADIUS server to Merit. RADIUS was later (1997) published as and (current versions are and ).

Now, several commercial and open-source RADIUS servers exist. Features can vary, but most can look up the users in text files, LDAP servers, various databases, etc. Accounting records can be written to text files, various databases, forwarded to external servers, etc. SNMP is often used for remote monitoring and keep-alive checking of a RADIUS server. RADIUS proxy servers are used for centralised administration and can rewrite RADIUS packets on the fly (for security reasons, or to convert between vendor dialects).

The Diameter protocol was intended as the replacement for RADIUS. While both are Authentication, Authorization, and Accounting (AAA) protocols, the use-cases for the two protocols have after diverged. Diameter is largely used in the 3G space. RADIUS is used elsewhere. One of the largest barriers to having Diameter replace RADIUS is that switches and Access Points typically implement RADIUS, but not Diameter.

Diameter uses SCTP or TCP while RADIUS typically uses UDP as the transport layer. As of 2012, RADIUS can additionally use TCP as the transport layer with TLS for security.

Standards documentation

The RADIUS protocol is currently defined in the following IETF RFC documents.

RFCTitleDate publishedRelated articleRelated RFCsNotes
Remote Authentication Dial In User Service (RADIUS)January 1997RADIUSObsoleted by
RADIUS AccountingJanuary 1997RADIUSObsoleted by
Remote Authentication Dial In User Service (RADIUS)April 1997RADIUSObsoleted by
RADIUS AccountingApril 1997RADIUSObsoleted by
Microsoft Vendor-specific RADIUS AttributesMarch 1999RADIUS
Proxy Chaining and Policy Implementation in RoamingJune 1999
RADIUS Authentication Client MIBManagement information baseObsoleted by
RADIUS Authentication Server MIBManagement information baseObsoleted by
RADIUS Accounting Client MIBJune 1999Management information baseObsoleted by
RADIUS Accounting Server MIBJune 1999Management information baseObsoleted by
Implementation of L2TP Compulsory Tunneling via RADIUSApril 2000
Remote Authentication Dial In User Service (RADIUS)June 2000RADIUSUpdated by , , This standard describes RADIUS authentication and authorization between a Network Access Server (NAS) and a shared RADIUS authentication server. This protocol is additionally used to carry configuration information from the RADIUS server to the NAS.
RADIUS AccountingJune 2000RADIUSThis standard describes how accounting information is carried from the NAS to a shared RADIUS accounting server.
RADIUS Accounting Modifications for Tunnel Protocol SupportJune 2000RADIUSUpdates
RADIUS Attributes for Tunnel Protocol SupportJune 2000Updates
RADIUS ExtensionsJune 2000Updated by ,
Network Access Servers Requirements: Extended RADIUS PracticesJuly 2000
RADIUS and IPv6August 2001
IANA Considerations for RADIUSJuly 2003
Dynamic Authorization Extensions to RADIUSJuly 2003Obsoleted by
RADIUS Support for EAPSeptember 2003Extensible Authentication ProtocolUpdates
IEEE 802.1X RADIUS Usage GuidelinesSeptember 2003802.1X
RADIUS Attributes Suboption for the DHCP Relay Agent Information OptionFebruary 2005
Chargeable User IdentityJanuary 2006
RADIUS Extension for Digest AuthenticationJuly 2006Obsoleted by
RADIUS Authentication Client MIB for IPv6August 2006Management information base
RADIUS Authentication Server MIB for IPv6August 2006Management information base
RADIUS Accounting Client MIB for IPv6August 2006Management information base
RADIUS Accounting Server MIB for IPv6August 2006Management information base
RADIUS Attributes for Virtual LAN and Priority SupportSeptember 2006
DSL Forum Vendor-Specific RADIUS AttributesSeptember 2006
RADIUS Delegated-IPv6-Prefix AttributeApril 2007
RADIUS Filter Rule AttributeApril 2007
Common RADIUS Implementation Issues and Suggested FixesDecember 2007Updates
RADIUS Extension for Digest AuthenticationFebruary 2008
Dynamic Authorization Extensions to RADIUSJanuary 2008
RADIUS Authorization for NAS ManagementJuly 2009
Use of Status-Server Packets in the RADIUS ProtocolAugust 2010Updates
RADIUS Design GuidelinesMarch 2011
Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying MaterialApril 2011
Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)November 2011
RADIUS over TCPMay 2012Experimental
Transport Layer Security (TLS) Encryption for RADIUSMay 2012Experimental