How Does RADIUS Work
Overview of RADIUS
AAA can be implemented using multiple protocols. RADIUS is most frequently used in actual scenarios.
RADIUS is a protocol that uses the client/server model in distributed mode and protects a network from unauthorized access. It is often used on networks that require high security and control remote user access. It defines the UDP-based RADIUS packet format and transmission mechanism, and specifies UDP ports 1812 and 1813 as the default authentication and accounting ports respectively.
At the very beginning, RADIUS was only the AAA protocol used for dial-up users. As user access modes diversifies, such as Ethernet access, RADIUS can also be applied to these access modes. RADIUS provides the access service through authentication and authorization and records the network resource usage of users through accounting.
RADIUS has the following characteristics:
- Client/Server model
- Secure message exchange mechanism
- Fine scalability
Client/Server Model
- RADIUS client
RADIUS clients run on the NAS to transmit user information to a specified RADIUS server and process requests (for example, permit or reject user access requests) based on the responses from the server. RADIUS clients can locate at any node on a network.
As a RADIUS client, a device supports:
- standard RADIUS protocol and its extensions, including RFC 2865 and RFC 2866
- Huawei extended RADIUS attributes
- RADIUS server status detection
- retransmission of Accounting-Request(Stop) packets in the local buffer
- active/standby and load balancing functions between RADIUS servers
- RADIUS server
RADIUS servers typically run on central computers and workstations to maintain user authentication and network service access information. The servers receive connection requests from users, authenticate the users, and send all required information (such as permitting or rejecting authentication requests) to the clients. A RADIUS server generally needs to maintain three databases, as shown in Figure 1-1.
- Users: This database stores user information such as user names, passwords, protocols, and IP addresses.
- Clients: This database stores RADIUS client information, such as the shared keys and IP addresses.
- Dictionary: This database stores the attributes in the RADIUS protocol and their value descriptions.
Secure Message Exchange Mechanism
Authentication messages between a RADIUS server and RADIUS clients are exchanged using a shared key. The shared key is a character string that is transmitted in out-of-band mode, is known to both clients and the server, and does not need to be transmitted independently on the network.
A RADIUS packet has a 16-octet Authenticator field that contains the digital signature data of the whole packet. The signature data is calculated using the MD5 algorithm and shared key. The RADIUS packet receiver needs to verify whether the signature is correct and discards the packet if the signature is incorrect.
This mechanism improves security of message exchange between RADIUS clients and the RADIUS server. In addition, user passwords contained in RADIUS packets are encrypted using shared keys before the packets are transmitted to prevent the user passwords from being stolen during transmission on an insecure network.
Fine Scalability
A RADIUS packet consists of a packet header and a certain number of attributes. The protocol implementation remains unchanged even if new attributes are added to a RADIUS packet.
RADIUS Packets
RADIUS Packet Format
RADIUS is based on the UDP protocol. Figure 1-2 shows the RADIUS packet format.
Each RADIUS packet contains the following information:
- Code: The Code field is one octet and identifies type of a RADIUS packet. Value of the Code field varies depending on the RADIUS packet type. For example, the value 1 indicates an Access-Request packet and the value 2 indicates an Access-Accept packet.
- Identifier: The identifier field is one octet, and helps the RADIUS server match requests and responses and detect duplicate requests retransmitted within a certain period. After a client sends a request packet, the server sends a reply packet with the same Identifier value as the request packet.
- Length: The Length field is two octets and specifies length of a RADIUS packet. Octets outside the range of the Length field must be treated as padding and ignored on reception. If a packet is shorter than the Length field, it must be silently discarded.
- Authenticator: The Authenticator field is 16 octets. This value is used to authenticate the reply from the RADIUS server and is used in the password hiding algorithm.
- Attribute: This field is variable in length. RADIUS attributes carry the specific authentication, authorization, accounting information and configuration details for the request and reply packets. The Attribute field may contain multiple attributes, each of which consists of Type, Length, and Value.
- Type: The Type field is one octet and indicates the RADIUS attribute ID. The value ranges from 1 to 255.
- Length: The Length field is one octet, and indicates the length of the RADIUS attribute (including the Type, Length and Value fields). The Length is measured in octets.
- Value: The maximum length of the Value field is 253 bytes. The Value field contains information specific to the RADIUS attribute. The format and length of the Value field is determined by the Type and Length fields.
RADIUS Packet Type
RADIUS defines 16 types of packets. Table 1-1 describes types of the authentication packets, Table 1-2 describes types of the accounting packets. For RADIUS CoA/DM packets, see RADIUS CoA/DM.
Packet Name |
Description |
|---|---|
Access-Request |
Access-Request packets are sent from a client to a RADIUS server and is the first packet transmitted in a RADIUS packet exchange process. This packet conveys information (such as the user name and password) used to determine whether a user is allowed access to a specific NAS and any special services requested for that user. |
Access-Accept |
After a RADIUS server receives an Access-Request packet, it must send an Access-Accept packet if all attribute values in the Access-Request packet are acceptable (authentication success). The user is allowed access to requested services only after the RADIUS client receives this packet. |
Access-Reject |
After a RADIUS server receives an Access-Request packet, it must send an Access-Reject packet if any of the attribute values are not acceptable (authentication failure). |
Access-Challenge |
During an EAP relay authentication, when a RADIUS server receives an Access-Request packet carrying the user name from a client, it generates a random MD5 challenge and sends the MD5 challenge to the client through an Access-Challenge packet. The client encrypts the user password using the MD5 challenge, and then sends the encrypted password in an Access-Request packet to the RADIUS server. The RADIUS server compares the encrypted password received from the client with the locally encrypted password. If they are the same, the server determines the user is valid. |
Packet Name |
Description |
|---|---|
Accounting-Request(Start) |
If a RADIUS client uses RADIUS accounting, the client sends this packet to a RADIUS server before accessing network resources. |
Accounting-Response(Start) |
The RADIUS server must send an Accounting-Response(Start) packet after the server successfully receives and records an Accounting-Request(Start) packet. |
Accounting-Request(Interim-update) |
You can configure the real-time accounting function on a RADIUS client to prevent the RADIUS server from continuing user accounting if it fails to receive the Accounting-Request(Stop) packet. The client then periodically sends Accounting-Request(Interim-update) packets to the server, reducing accounting deviation. |
Accounting-Response(Interim-update) |
The RADIUS server must send an Accounting-Response(Interim-update) packet after the server successfully receives and records an Accounting-Request(Interim-update) packet. |
Accounting-Request(Stop) |
When a user goes offline proactively or is forcibly disconnected by the NAS, the RADIUS client sends this packet carrying the network resource usage information (including the online duration and number of incoming/outgoing bytes) to the RADIUS server, requesting the server to stop accounting. |
Accounting-Response(Stop) |
The RADIUS server must send an Accounting-Response(Stop) packet after receiving an Accounting-Request(Stop) packet. |
RADIUS Authentication, Authorization, and Accounting Process
A device that functions as a RADIUS client collects user information, including the user name and password, and sends the information to the RADIUS server. The RADIUS server then authenticates users according to the information, after which it performs authorization and accounting for the users. Figure 1-3 shows the information exchange process between a user, a RADIUS client, and a RADIUS server.
- A user needs to access a network and sends a connection request containing the user name and password to the RADIUS client (device).
- The RADIUS client sends a RADIUS Access-Request packet containing the user name and password to the RADIUS server.
- The RADIUS server verifies the user identity:
- If the user identity is valid, the RADIUS server returns an Access-Accept packet to the RADIUS client to permit further operations of the user. The Access-Accept packet contains authorization information because RADIUS provides both authentication and authorization functions.
- If the user identity is invalid, the RADIUS server returns an Access-Reject packet to the RADIUS client to reject access from the user.
- The RADIUS client notifies the user of whether authentication is successful.
- The RADIUS client permits or rejects the user access request according to the authentication result. If the access request is permitted, the RADIUS client sends an Accounting-Request (Start) packet to the RADIUS server.
- The RADIUS server sends an Accounting-Response (Start) packet to the RADIUS client and starts accounting.
- The user starts to access network resources.
- (Optional) If interim accounting is enabled, the RADIUS client periodically sends an Accounting-Request (Interim-update) packet to the RADIUS server, preventing incorrect accounting result caused by unexpected user disconnection.
- (Optional) The RADIUS server returns an Accounting-Response (Interim-update) packet and performs interim accounting.
- The user sends a logout request.
- The RADIUS client sends an Accounting-Request (Stop) packet to the RADIUS server.
- The RADIUS server sends an Accounting-Response (Stop) packet to the RADIUS client and stops accounting.
- The RADIUS client notifies the user of the processing result, and the user stops accessing network resources.
RADIUS CoA/DM
The device supports the RADIUS Change of Authorization (CoA) and Disconnect Message (DM) functions. CoA provides a mechanism to change the rights of online users, and DM provides a mechanism to forcibly disconnect users. This section contains the following contents:
RADIUS CoA/DM packet
Table 1-3 describes types of the CoA/DM packets.
Packet Name |
Description |
|---|---|
CoA-Request |
When an administrator needs to modify the rights of an online user (for example, prohibit the user from accessing a website), the RADIUS server sends this packet to the RADIUS client, requesting the client to modify the user rights. |
CoA-ACK |
If the RADIUS client successfully modifies the user rights, it returns this packet to the RADIUS server. |
CoA-NAK |
If the RADIUS client fails to modify the user rights, it returns this packet to the RADIUS server. |
DM-Request |
When an administrator needs to disconnect a user, the server sends this packet to the RADIUS client, requesting the client to disconnect the user. |
DM-ACK |
If the RADIUS client has disconnected the user, it returns this packet to the RADIUS server. |
DM-NAK |
If the RADIUS client fails to disconnect the user, it returns this packet to the RADIUS server. |
Exchange Procedure
CoA allows the administrator to change the rights of an online user or perform reauthentication for the user through RADIUS after the user passes authentication. Figure 1-4 shows the CoA interaction process.
- The RADIUS server sends a CoA-Request packet to the device according to service information, requesting the device to modify user authorization information. This packet can contain authorization information including the ACL.
- Upon receiving the CoA-Request packet, the device performs a match check between the packet and user information on the device to identify the user. If the match succeeds, the device modifies authorization information of the user. Otherwise, the device retains the original authorization information of the user.
- The device returns a CoA-ACK or CoA-NAK packet as follows:
- If authorization information is successfully modified, the device sends a CoA-ACK packet to the RADIUS server.
- If authorization information fails to be modified, the device sends a CoA-NAK packet to the RADIUS server.
When a user needs to be disconnected forcibly, the RADIUS server sends a DM packet to the device. Figure 1-5 shows the DM interaction process.
- The administrator forcibly disconnects a user on the RADIUS server. The RADIUS server sends a DM-Request packet to the device, requesting the device to disconnect the user.
- Upon receiving the DM-Request packet, the device performs a match check between the packet and user information on the device to identify the user. If the match succeeds, the user is notified to go offline. Otherwise, the user remains online.
- The device returns a DM-ACK or DM-NAK packet as follows:
- If the user successfully goes offline, the device sends a DM-ACK packet to the RADIUS server.
- Otherwise, the device sends a DM-NAK packet to the RADIUS server.
Different from the process in which authorization is performed for an online user or a user proactively goes offline, the server sends a request packet and the device sends a response packet in the CoA/DM process. If CoA/DM succeeds, the device returns an ACK packet. Otherwise, the device returns a NAK packet.
Session Identification
Each service provided by the NAS to a user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended.
After the device receives a CoA-Request or DM-Request packet from the RADIUS server, it identifies the user depending on some RADIUS attributes in the packet. The following RADIUS attributes can be used to identify users:
- User-Name (IETF attribute #1)
- Acct-Session-ID (IETF attribute #4)
- Framed-IP-Address (IETF attribute #8)
- Calling-Station-Id (IETF attribute #31)
The match methods are as follows:
- any method
The device performs a match check between an attribute and user information on the device. The priority for identifying the RADIUS attributes used by the users is as follows: Acct-Session-ID (4) > Calling-Station-Id (31) > Framed-IP-Address (8). The device searches for the attributes in the request packet based on the priority, and performs a match check between the first found attribute and user information on the device. If the attribute is successfully matched, the device responds with an ACK packet; otherwise, the device responds with a NAK packet.
- all method
The device performs a match check between all attributes and user information on the device. The device identifies the following RADIUS attributes used by the users: Acct-Session-ID (4), Calling-Station-Id (31), Framed-IP-Address (8), and User-Name (1). The device performs a match check between all the preceding attributes in the Request packet and user information on the device. If all the preceding attributes are successfully matched, the device responds with an ACK packet; otherwise, the device responds with a NAK packet.
Error Code Description
When the CoA-Request or DM-Request packet from the RADIUS server fails to match user information on the device, the device describes the failure cause using the error code in the CoA-NAK or DM-NAK packet. For the error code description, see Table 1-4 and Table 1-5.
Name |
Value |
Description |
|---|---|---|
RD_DM_ERRCODE_MISSING_ATTRIBUTE |
402 |
The request packet lacks key attributes, so that the integrity check of the RADIUS attributes fails. |
RD_DM_ERRCODE_INVALID_REQUEST |
404 |
Parsing the attributes in the request packet fails. |
RD_DM_ERRCODE_INVALID_ATTRIBUTE_VALUE |
407 |
The request packet contains attributes that are not supported by the device or do not exist, so that the attribute check fails. Contents of the authorization check include VLAN, ACL, CAR, number of the ACL used for redirection, and whether Huawei RADIUS extended attributes RD_hw_URL_Flag and RD_hw_Portal_URL can be authorized to the interface-based authenticated user. Errors that may occur are as follows:
|
RD_DM_ERRCODE_SESSION_CONTEXT_NOT_FOUND |
503 |
The session request fails. The cause includes:
|
RD_DM_ERRCODE_RESOURCES_UNAVAILABLE |
506 |
This error code is used for other authorization failures. |
Related Information
- AR100, AR120, AR160, AR1200, AR2200, AR3200, and AR3600 V300R003 CLI-based Configuration Guide - Security
- S2720, S5700, and S6720 V200R013C00 Configuration Guide - User Access and Authentication
- Wireless Access Controller (AC and FITAP) V200R010C00 CLI-based Configuration Guide - User Access and Authentication Configuration Guide
- CloudEngine 12800 and 12800E V200R005C10 Configuration Guide - Security