Share This Article
Contents
Remote Authentication Dial-In User Service (RADIUS) is a widely implemented network protocol that enables centralized authentication, authorization, and accounting (AAA) requests over a network. There are a variety of pros and cons to RADIUS, and common use cases include user access for wireless networks and VPNs, as well as a dependable administrative access control for other protected network resources.
RADIUS was designed during a different era of computing, but it’s proven to be versatile and adaptable to meet today’s challenges. Its defenses can be bolstered with modern security controls such as:
- Multi-factor authentication (MFA)
- TLS
- VPNs to encrypt payloads
RADIUS may also work across authentication providers by using delegated access control.
Cloud RADIUS solutions make it even more convenient to incorporate RADIUS into your identity and access management (IAM) stack, enabling even more user scenarios by using group memberships and conditional access policies. Setup takes minutes versus staging a server. Those factors make cloud RADIUS approachable and cost-effective for IT departments, and flexible to meet current and future requirements.
History
Work began in 1987 when the National Science Foundation (NSF) released a bid to expand and support the national internet via the NSFnet, the foundation of what would become the internet we know and love today.
Merit Network Inc., a nonprofit corporation hosted at the University of Michigan, had been developing a proprietary network protocol to connect universities throughout the state of Michigan for years and was awarded the contract from the NSF. However, their network had to be converted from their proprietary protocol to the IP-based network of the NSFnet.
Merit solicited proposals from various vendors to develop a protocol that would support Merit’s dial-in support needs. In 1991, Livingston Enterprises submitted a proposal of the RADIUS protocol. Merit awarded the contract to Livingston, which was acquired by Lucent Technologies later that decade.
Launch of RFC 2058
RADIUS was standardized in 1997 as RFC 2058 by the Internet Engineering Task Force (IETF) specifically for dial-up internet services, but was made obsolete by RFC 2138 that same year to make it more accommodating for vendors to adopt.
The protocol then began to gain industry acceptance and vendors developed their own variant(s) using customizations called vendor specific attributes (VSAs) to better fit their use cases. The RADIUS standard was again updated in 2000 to support authentication and authorization between a Network Access Server (NAS) and a RADIUS server.
NAS is used to route authentication requests from clients to separate RADIUS servers, which may then assign IP addresses to the user(s). This authentication is accomplished by using a strong shared secret, similar to how WPA2 and WPA3 function in wireless networks, i.e., the “Wi-Fi password.”
However, the RADIUS authentication server also authorizes users from an LDAP directory service. Pertinent configuration information is carried between the RADIUS server and NAS, verifying identities and the level of access that users should be granted to a particular network resource.
RADIUS servers have the capacity to subsequently change or revoke authorization by disconnecting a user that no longer should be able to access it after an authorization has been issued.
RADIUS Today
RADIUS continues to evolve and has spawned an ecosystem of solutions. Authentication and authorization are defined in RFC 2865 while accounting is described by RFC 2866. There’s even a proposed standard, RFC 8559, to enable dynamic authorization proxying in RADIUS protocol.
The latter proposal extends support for scenarios where networks use realm-based proxying, which provides multi-tenant deployments where different authentication services are required based on the client realm that’s being specified. Several different RADIUS servers may be used. The following section describes how RADIUS functions in greater detail.
Learn more about popular RADIUS service options in Best RADIUS Solutions.
How Does the RADIUS Protocol Work?
RADIUS utilizes the client/server model. Requests for access are sent from a client to the RADIUS server for verification. The server receives requests as a package containing the client’s username, password, IP address, and port, and then queries the database for matching credentials.
Depending on the information received from the client, the server will then return an action to accept, reject, or challenge, and will grant access to the requested service accordingly.
Key Features of RADIUS
RADIUS consists of several standards that outline the protocol, resulting in a AAA network access system that operates at the application layer.
Client/Server Model
The simplified client/server model distinguishes the client as the individual user requesting access to the RADIUS server, which is essentially the gatekeeper for the requested service. In this system, the client or user is initially prompted to enter their unique credentials — typically in the form of a username and password.
Generally, the request is accompanied by a specific IP address and the port related to the origin of the request. These pieces of information form the action request package that the server uses to authenticate and authorize access.
The server then compares the information contained in the action request package against approved information stored in the RADIUS database. If the user credentials match the database, the system will return a message to accept, and subsequently authorizes access to a service. If the credentials do not match, the system will return a reject message and the service will be denied.
Finally, the system can also return a message to challenge the user data. In which case, the server requests additional credentials.
Network Security
Client requests are authenticated and authorized by verifying the user credentials and shared secret. In most cases, the user credentials are the username and password and the shared secret comes from the access point like a router or switch.
The password is always sent over encrypted channels to prevent an attacker from intercepting shared secrets on an unsecured network. The encryption is essentially impossible to decode. If the information matches the credentials stored in the RADIUS database, the client request is authorized for service. If not, service is denied.
Flexible Authentication Mechanisms
RADIUS can support a variety of user authentication protocols like EAP-TTLS and PEAP to name a few — although there are several others.
Extensible Protocol
Essentially, this means RADIUS can support means of authentication other than username and password such as token cards, smart cards, certificates, one-time passwords, and other various means of authentication.
Security
RADIUS passwords are protected by MD5 hashing, which has some weaknesses when packets travel through untrusted networks. Network administrators can remediate that security/privacy concern by deploying encrypted tunnels such as RADIUS over TLS (RADSec), or IPSec or WireGuard VPNs as a control.
JumpCloud has also added integrated Push and TOTP multi-factor authentication (MFA) to the authentication flow to improve security for remote users. Encryption protects information that flows between the NAS server and RADIUS such as user-specific attributes including VLANs that might be helpful to malicious attackers.
Diameter is an alternative AAA protocol to RADIUS that defines a policy protocol for services at the application level. It was proposed to replace RADIUS, but it’s more commonly used with 3G cellular networks. Diameter isn’t backwards compatible with RADIUS, and isn’t supported by many network devices such as wireless access points and layer 2 and layer 3 switches. The advent of RADSec has also addressed some of the limitations Diameter was created to solve.
RADIUS can be securely incorporated into perimeter network access by incorporating technical controls such as MFA and/or by using VPNs that offer end-to-end encryption.
The Future of RADIUS
RADIUS servers are no longer limited to private domains. RADIUS is useful in a number of different contexts, and by shifting it to the cloud it can be used in a wide variety of scenarios including with VPNs, Wi-Fi access points, and more.
By moving to the cloud, RADIUS is more integrated into the core infrastructure of an IT organization. This concept extends to other areas as well, including:
- LDAP
- SAML
- Other authentication protocols
IT admins can add multi-factor authentication to the RADIUS authentication process for VPNs and even use attributes to dynamically place users in VLANs based on their group membership, for example.
IT admins don’t need an Active Directory server or a Windows Network Policy Server (NPS), LDAP instance, FreeRADIUS infrastructure, or any of that additional hardware. All of these features are integrated into cloud directories that support whatever IT resources are needed.
Returning to RADIUS, the big picture innovation is delivering RADIUS from the cloud. This feature enables organizations to leverage RADIUS as a core protocol within their infrastructure, and allows them to reap the benefits of it. Additionally, this is all achievable without the heavy lifting of implementing RADIUS in-house and managing it manually.
JumpCloud Cloud RADIUS
JumpCloud Cloud RADIUS works in much the same way as more traditional applications. However, hosted RADIUS with JumpCloud takes the traditional approach a step further by moving RADIUS AAA to the cloud. The advantage is that remote management is now possible from anywhere with an internet connection.
Another benefit of RADIUS in the cloud is that administrators leverage JumpCloud credentials to authenticate and authorize against the server. The process begins when a user system sends a request to access the network.
User credentials are then passed to the client supplicant software that speaks PEAP or EAP-TTLS to make requests via your Wi-Fi access point to authenticate against the JumpCloud Cloud RADIUS server. If the credentials match those stored in the database, the user is authorized for access.
Zero Trust Security
RADIUS security may be further enhanced by JumpCloud’s pre-built conditional access policies that are managed using group memberships and user attributes. Policies restrict RADIUS access to a specific region, managed devices only, and may make MFA a mandatory component of your system. Of course, all of this happens securely behind the scenes and administrators can rest easy knowing they can restrict access to their network at any given time.
Third Party Authentication
JumpCloud also provides simple password-based delegated authentication for scenarios such as managing Wi-Fi access where IT admins aren’t willing to manage their own RADIUS servers on premise.
This capability extends other directory services such as Microsoft Azure, Google Workspace, or Okta that don’t provide RADIUS. Integrations with third-party authentication providers are either supported or in the process of being added to the JumpCloud platform.
Try JumpCloud’s Cloud RADIUS Service
It’s JumpCloud’s mission to connect you to more resources by implementing the methods that you want to use. You can sign up at any time and enjoy full access to our product, even if your credentials reside on a different identity platform. Your first 10 users/devices are free of cost.
