Once authenticated Radius also determines what rights or privileges the person or computer is "Authorized" to perform and makes a record of this access in the "Accounting" feature of the server. The support of Authentication, Authorization and Accounting is referred to as the AAA (said triple A) process.
Because of the broad support and the ubiquitous nature of the RADIUS protocol it is often used by ISPs, Wireless Networks, integrated e-mail services, Access Points, Network Ports, Web Servers or any provider needing a well supported AAA server.
RADIUS servers use the AAA concept to manage network access in the following two-step process, also known as an "AAA transaction".
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 many dialup or DSL providers.
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 contains 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 checks that the information is correct using authentication schemes like PAP, CHAP or EAP. The user's proof of identification is verified, along with, optionally, other 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; a "Nay" (Access Reject), "Challenge" (Access Challenge) or "Yea" (Access Accept).
Authorization attributes are conveyed to the NAS stipulating terms of access to be granted. For example: the following authorization attributes may be included in an Access-Accept.
Accounting is described in RFC 2866.
The RADIUS protocol does not transmit passwords in cleartext between the NAS and RADIUS server (not even with PAP protocol). Rather, a shared secret is used along with the MD5 hashing algorithm to obfuscate passwords. Because MD5 is not considered to be a very strong protection of the user's credentials, additional protection - such as IPsec tunnels - should be used to further encrypt the RADIUS traffic. The user's credentials are the only part protected by RADIUS itself, but other user-specific attributes passed by RADIUS may be considered sensitive or private information as well. Please refer to the references for more details on this subject.
RADIUS is a common authentication protocol utilized by the IEEE 802.1X security standard (often used in wireless networks). Although RADIUS was not initially intended to be a wireless security authentication method, it improves the WEP encryption key standard, in conjunction with other security methods such as EAP-PEAP.
RADIUS is extensible; many vendors of RADIUS hardware and software implement their own variants using Vendor-Specific Attributes (VSAs).
RADIUS has been officially assigned UDP ports 1812 for RADIUS Authentication and 1813 for RADIUS Accounting by the Internet Assigned Number Authority (IANA) however before IANA allocation ports 1645 - Authentication and 1646 - Accounting were used unofficially and became the default ports assigned by many RADIUS Client/Server implementations of the time. The tradition of using 1645 and 1646 for backwards compatibility continues to this day. For this reason many RADIUS Server implementations monitor both sets of UDP ports for RADIUS requests. Microsoft RADIUS servers default to 1812 and 1813 but Cisco devices default to the traditional 1645 and 1646 ports. Juniper Networks' RADIUS servers also defaults to 1645 and 1646.
RADIUS is used by RSA SecurID to enable strong authentication for access control; products such as PhoneFactor add two-factor authentication to legacy RADIUS applications that typically only support username and password authentication.
RADIUS is widely used by VoIP service providers. It is used to pass login credentials of a SIP end point (like a broadband phone) to a SIP Registrar using digest authentication, and then to RADIUS server using RADIUS. Sometimes it is also used to collect call detail records (CDRs) later used, for instance, to bill customers for international long distance.
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 RFC 2058 and RFC 2059 (current versions are RFC 2865 and RFC 2866). 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. RADIUS proxy servers are used for centralized administration and can rewrite RADIUS packets on the fly (for security reasons, or to convert between vendor dialects).
Modern RADIUS servers allow any character to be used as a realm delimiter, although in practice '@' and '' are usually used.
Realms can also be compounded using both prefix and postfix notation, to allow for complicated roaming scenarios; for example, email@example.com could be a valid username with two realms.
Although realms often resemble email domains, it is important to note that realms are in fact arbitrary text and need not contain real domain names.
Roaming with RADIUS exposes the users to various security and privacy concerns. Some EAP methods establish a secure tunnel between an authenticator and the home AAA server before the transmission of sensitive data, providing relief for most of those concerns. In these cases, there is sometimes an outer identity in clear text transmitted outside the eap tunnel, visible to proxies so they can route packets, and which doesn't have to reveal much about the user's true identity, and an inner identity which does, and as such is transmitted inside the secure EAP tunnel.
More generally, some roaming partners establish a secure tunnel between the RADIUS servers to ensure that users' credentials cannot be intercepted while being proxied across the internet. This is a concern as the encyption built into RADIUS is considered insecure.
Other relevant RFCs are: