RADIUS stands for Remote Authentication Dial-in User Service. It is a network protocol that enables centralized authentication, authorization, and accounting regarding requests sent over a network. Leveraging the RADIUS protocol can be highly advantageous in the modern office, but how has a network protocol that was originally designed for dial-up internet managed to stay relevant? To answer this question, let’s take a look at the history and evolution of the RADIUS protocol.
Genesis and Development
It all 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. Yet, their network had to be converted from their proprietary protocol to the IP based network of the NSFnet. Merit then solicited proposals from various vendors to develop a protocol that would support Merit’s dial in support needs. In 1991, a response was received from a company called Livingston Enterprises. Their proposal was a description of the RADIUS protocol. Merit awarded the contract to Livingston and the rest is history.
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 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.
What core problem does it solve?
The proto-internet was largely based on proprietary protocols and was very exclusive. RADIUS was developed to replace the proprietary dial-in services with standard dial in servers in an effort to bring internet services to the public. RADIUS initially solved the problem of authentication, authorization, and accounting (AAA) for network traffic and requests from public clients. Today, it is still primarily focused on AAA. However, it has been expanded to support a wide variety of other authentication protocols as well as modern networks.
Key Features of RADIUS
- 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 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 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.
- 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 many others.
- 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.
JumpCloud RADIUS works in much the same way as more traditional applications. However, RADIUS-as-a-Service with JumpCloud takes the traditional approach a step further by moving AAA to the cloud. The advantage is that remote management is now possible from anywhere with an internet connection. Another benefit of RADIUS-as-a-Service 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 WiFi access point to authenticate against the JumpCloud RADIUS server. If the credentials match those stored in the database, the user is authorized for access. Of course, all of this happens securely behind the scenes and the administrator can rest easy knowing they can restrict access to their network at any given time.
You can find a diagram of the architecture of our Radius-as-a-Service platform here. You can also sign up for free at anytime and enjoy full access to our product. Your first ten users are free forever!
Vollbrecht, John (2006, June). The Beginnings and History of RADIUS. <https://www.interlinknetworks.com/app_notes/History%20of%20RADIUS.pdf>
Unknown. “How Does RADIUS Work?” Cisco. Cisco, 25 May 2017. Web. 07 July 2017. <http://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/12433-32.html>
Rigney, Carl, Allan C. Rubens, William A. Simpson, and Steve Willens. “Remote Authentication Dial In User Service (RADIUS).” IETF Tools. The Internet Society, June 2000. Web. 07 July 2017.< https://tools.ietf.org/html/rfc2865>