What Is RADIUS?
Remote Authentication Dial-In User Service (RADIUS) is a distributed information exchange protocol that uses a client/server model. It protects a network against unauthorized access and is often used on networks that require high security and allow remote user access. RADIUS is a standard protocol supported by almost all mainstream devices and is the most widely used AAA protocol on live networks. It uses User Datagram Protocol (UDP) as the transmission protocol and therefore has good real-time performance. In addition, it features high reliability by providing retransmission and backup server mechanisms. RADIUS is easy to implement and supports multithreading on a server for authenticating large numbers of users.
Why Do We Need RADIUS?
Authentication, Authorization, and Accounting (AAA) provides a management framework for configuring access control on a network access server (NAS). It determines which users can access a network, which resources or services authorized users can access, and how to charge users who are using network resources. AAA can be implemented using multiple protocols, among which RADIUS is most frequently used in real-world applications.
RADIUS is a protocol used for communication between the NAS and AAA server. It was initially used to manage large numbers of scattered users who used serial ports and modems, and was then later applied extensively to the NAS system. To obtain permission to access certain networks or to use some network resources, a user needs to set up a connection with the NAS through a network (such as a telephony network). In this case, the NAS is responsible for authenticating the user or the connection and sends the AAA information of the user to the RADIUS server. RADIUS prescribes how to transmit the user information and accounting information between the NAS and RADIUS server. Upon receiving requests from users, the RADIUS server authenticates the users and then sends the required configuration information back to the NAS.
What Are the Characteristics of RADIUS?
RADIUS has the following characteristics:
- Client/server structure
- Secure information exchange mechanism
- Good scalability
RADIUS adopts the typical client/server structure, which features good scalability and facilitates centralized management of user information.
RADIUS clients usually run on NASs and can be deployed across the network. A RADIUS client is responsible for transmitting user information to a specified RADIUS server, and then performs operations accordingly (for example, accept or reject user access) based on the responses from the server.
The RADIUS client supports the following functions:
Standard RADIUS protocol and extended attributes
Huawei proprietary RADIUS attributes
RADIUS server status detection
- Automatic switching to another RADIUS server
Retransmission of accounting packets in the local buffer
RADIUS server selection using the master/backup or load balancing mode algorithm
RADIUS servers typically run on central computers and workstations to maintain user authentication and network service access information. The servers receive user connection requests, authenticate the users, and send responses (for example, accept or reject user access) to the clients. A RADIUS server can serve multiple RADIUS clients.
A RADIUS server generally needs to maintain three databases, as shown in the following figure.
Databases maintained by a RADIUS server
- Users: This database stores user information (such as usernames, passwords, protocols, and IP addresses).
- Clients: This database stores RADIUS client information (such as the shared keys and IP addresses).
- Dictionary: This database stores RADIUS attributes and their value descriptions.
Secure Message Exchange Mechanism
The RADIUS client and server exchange authentication messages using a shared key. The shared key is a character string that is known to both the client and server and does not need to be transmitted independently on the network. In addition, a RADIUS packet has a 16-octet Authenticator field that contains the digital signature data of the whole packet. This signature data is calculated using the MD5 algorithm and shared key. Upon receipt of a RADIUS packet, a device verifies the signature and discards the packet if the signature is incorrect. This mechanism ensures the security of information exchange between the RADIUS client and RADIUS server.
In addition, user passwords carried in RADIUS packets are encrypted using shared keys before the packets are transmitted. This prevents the user passwords from being stolen during transmission on an insecure network.
A RADIUS attribute, that is, the Attribute field in RADIUS packets, carries authentication, authorization, and accounting information. A RADIUS packet consists of the packet header and a certain number of attributes. New attributes can be added without affecting the existing implementation of the protocol.
How Does RADIUS Work?
RADIUS Authentication, Authorization, and Accounting
RADIUS supports the authentication, authorization, and accounting components in AAA. Because RADIUS was defined earlier than the AAA framework model, RADIUS combines authentication and authorization. RADIUS authentication and accounting can be performed on different servers.
A device that functions as a RADIUS client collects user information (for example, usernames and passwords) and sends this information to a RADIUS server. The RADIUS server authenticates a user according to the information, and then performs authorization and accounting for the user. The following figure shows the process of exchanging information between a user, a RADIUS client, and a RADIUS server.
RADIUS authentication, authorization, and accounting process
- The user wants to access the network and sends a connection request containing the username and password to the RADIUS client.
- The RADIUS client sends an Access-Request packet containing the username and password to the RADIUS server.
The RADIUS server verifies the user identity:
- If the user identity is valid, the RADIUS server replies with an Access-Accept packet to the RADIUS client, permitting the user to perform further operations. The Access-Accept packet carries authorization information because RADIUS provides both authentication and authorization functions.
- If the user identity is invalid, the RADIUS server replies with an Access-Reject packet to the RADIUS client, rejecting the access request from the user.
- The RADIUS client notifies the user of the authentication result.
- The RADIUS client accepts or rejects the user access request according to the authentication result. If the user access request is accepted, the RADIUS client sends an Accounting-Request (Start) packet to the RADIUS server.
- The RADIUS server replies with an Accounting-Response (Start) packet and starts accounting.
- The user starts to access network resources.
- (Optional) If real-time accounting is enabled, the RADIUS client periodically sends an Accounting-Request (Interim-Update) packet to the RADIUS server. This prevents accounting from being conducted unreasonably if a paid user is logged out unexpectedly due to the failure to send an Accounting-Request (Stop) packet. The interval at which Accounting-Request (Interim-Update) packets are sent can be set on the client.
- (Optional) The RADIUS server replies with an Accounting-Response (Interim-update) packet and performs real-time accounting.
- The user sends a logout request to stop accessing network resources.
- The RADIUS client sends an Accounting-Request (Stop) packet to the RADIUS server.
- The RADIUS server replies with an Accounting-Response (Stop) packet and stops accounting.
- The RADIUS client notifies the user that network access ends and the user stops accessing network resources.
RADIUS Dynamic Authorization
RADIUS supports the Change of Authorization (CoA) function. After a user is successfully authenticated, the RADIUS server can modify the permissions of the online user through RADIUS. CoA packets include CoA-Request, CoA-ACK, and CoA-NAK packets, which are dynamic authorization request packets, dynamic authorization request accept packets, and dynamic authorization request reject packets, respectively. The following figure shows the CoA packet exchange process.
CoA packet exchange process
- The RADIUS server sends a CoA-Request packet to the RADIUS client according to service information, requesting the client to modify user authorization information. The packet may include authorization information such as ACLs.
- After receiving the CoA-Request packet, the RADIUS client matches the packet against user information on the client for user identification. If the match is successful, the RADIUS client modifies authorization information of the user. Otherwise, the device retains the original authorization information of the user.
- The RADIUS client returns a CoA-ACK or CoA-NAK packet.
- If authorization information is successfully modified, the RADIUS client sends a CoA-ACK packet to the RADIUS server.
- If authorization information fails to be modified, the RADIUS client returns a CoA-NAK packet to the RADIUS server.
Logging Out Users Through RADIUS
RADIUS also supports the Disconnect Message (DM) function. After a user goes online, an administrator can forcibly disconnect the user on the RADIUS server, which initiates a Disconnect-Request packet. DMs are classified into three types: Disconnect-Request, Disconnect-ACK, and Disconnect-NAK, which respectively indicate the user logout request packet, user logout request accept packet, and user logout request reject packet. The following figure shows the DM exchange process.
DM exchange process
- An administrator forcibly disconnects a user on the RADIUS server. The RADIUS server then sends a Disconnect-Request packet to the RADIUS client, requesting the client to disconnect the user.
- Upon receipt, the RADIUS client matches the packet against the locally stored user information to identify the user. If the match is successful, the device instructs the user to go offline. Otherwise, the user remains online.
The RADIUS client returns a Disconnect-ACK or Disconnect-NAK packet.
- If the user is successfully logged out, the RADIUS client returns a Disconnect-ACK packet to the RADIUS server.
- If the user fails to be logged out, the RADIUS client sends a Disconnect-NAK packet to the RADIUS server.
Unlike the process in which authorization is performed for an online user or a user proactively goes offline, in the CoA/DM process, the RADIUS server sends a Disconnect-Request packet to the RADIUS client, which then responds with a Disconnect-ACK (if the operation is successful) or Disconnect-NAK (if the operation fails) packet.
How Does RADIUS Ensure Transmission Reliability?
RADIUS uses UDP to ensure real-time data transmission. However, when the network condition is poor, using UDP may result in packet loss during transmission. To improve the reliability of data transmission, RADIUS supports the backup server and retransmission mechanisms.
Backup RADIUS Server Mechanism
On large networks, multiple RADIUS servers are typically deployed. As such, user access will not be affected if a server fails. In addition, load balancing of a large number of users accessing the network can be performed among these servers, preventing resources of a single server from being exhausted. If multiple servers are configured in a RADIUS server group, a RADIUS client can select a RADIUS server based on the master/backup algorithm or load balancing algorithm when sending packets to the server.
A RADIUS server group can have one master server and zero, one, or more backup servers configured. A RADIUS client selects the master server if it exists and is in the Up state. Otherwise, the RADIUS client selects a backup server to respond to user requests. After the RADIUS client receives an AAA request, it checks whether the master server exists and is in the Up state. If it is, the RADIUS client selects it to respond to user requests. Otherwise, the client selects the first backup server that is configured to respond to user requests.
Load balancing mode
In load balancing mode, traffic is balanced among multiple RADIUS servers so that more user requests can be processed more quickly. If the load balancing algorithm is used, when the RADIUS client sends authentication or accounting packets to a server, the client selects the server based on the weights configured for the RADIUS authentication servers or RADIUS accounting servers.
RADIUS Packet Retransmission Mechanism
During user authentication, the RADIUS client sends an authentication request packet to the RADIUS server. To ensure that factors such as network faults or delay do not prevent the RADIUS client from receiving the response packet sent by the RADIUS server, the retransmission mechanism is provided for request packets to be sent to the RADIUS server. If the client does not receive a response packet from the server within the timeout period, the client resends a request packet. Specifically, the RADIUS client retransmits the request to the same server a specified number of retransmission times. If no reply is received, the client sends the request to a different server, regardless of whether the master/backup or load balancing mode is used. The number of retransmission attempts and the response timeout period for a server group and servers in the server group can be configured on the RADIUS client.
What Are the Differences Between RADIUS and HWTACACS?
Terminal Access Controller Access Control System (TACACS) is an AAA protocol that emerged in the 1980s. HWTACACS, developed by Huawei, is an enhancement of TACACS. It is a centralized information exchange protocol and adopts the client/server structure. Similar to RADIUS, HWTACACS uses the client/server model to implement user authentication, authorization, and accounting. Unlike RADIUS, however, HWTACACS uses TCP to provide reliable transmission and separates authentication from authorization. HWTACACS features more reliable transmission and encryption than RADIUS does and is more suitable for security control.
The following table lists the main differences between HWTACACS and RADIUS.
Comparison between RADIUS and HWTACACS
- Author： Zhang Yuting
- Updated on： 2022-12-30
- Views： 1189
- Average rating：