Application layer protocol-RADIUS

I. Introduction

Introduction to RADIUS

Application layer protocol Radius is the abbreviation of Remote Authentication Dial In User Service, that is, remote authentication dial-in user service . When a user wants to establish a connection with a network access server NAS (Network Access Server) (this NAS is not the other NAS) through a certain network (such as a telephone network) to gain access to other networks, the NAS can choose to perform local operations on the NAS Authentication and accounting, or transfer user information to the Radius server, and Radius performs authentication and accounting. The Radius protocol specifies how to transfer user information and accounting information between the NAS and the Radius server. The Radius server is responsible for receiving the user's connection request, completing the verification, and returning the configuration information required to deliver the service to the user to the NAS. For example, if a user requests certain services (such as SLIP, PPP, telnet), they must pass through the NAS, and the NAS will communicate with the connected server in a certain order for verification. The user enters the NAS by dialing, and the NAS requires the user name, password and other information according to the configured authentication method (such as PPP PAP, CHAP, etc.), and the user enters as prompted. Through the connection with the NAS, the NAS obtains this information. Then, the NAS transmits this information to the Radius server, and determines whether the user can obtain the service he requires based on the server's response.

2. What is AAA protocol

At present, the authentication methods adopted by telecom operators and service providers mainly include local authentication, RADIUS authentication and non-authentication; and the charging strategies are even more colorful. Common ones include non-charging (monthly subscription), long-term charging, and Traffic accounting, billing by port, etc. Among all these authentication and accounting methods, the use of RADIUS Server for centralized authentication and accounting applications is the most popular and widespread.

Radius is an implementation of AAA protocol, so what is AAA protocol?

AAA is the abbreviation for Authentication, Authorization and Accounting (Authentication, Authorization, Accounting). It is a client program running on the NAS and provides a consistent configuration for the three security functions of authentication, authorization and accounting. s frame. A network allows external users to access it through the public network, so that users can be extremely geographically dispersed. A large number of scattered users can access this network randomly from different places through modems (modems, modems) and other devices. Users can pass their own information to this network, or get the information they want from this network. Due to the two-way data flow between internal and external, network security has become a very important issue. A large number of modems have formed modem pools. The management of the modem pool becomes the task of the network access server or router. The content of management includes: which users can obtain access rights, which services are allowed to users who have access rights, and how to charge users who use network resources. AAA accomplished these three tasks well. The configuration of AAA is actually a management of network security. The network security here mainly refers to access control, including which users can access network servers, which services are available to users with access rights, and how to perform actions on users who are using network resources. Bookkeeping. The following briefly introduces the role of authentication, authorization, and accounting.

• Authentication (Authentication): to identify whether the user can obtain access.

• Authorization (Authorization): Authorized users can use which services.

• Accounting: Record the user's use of network resources.

Various functions of AAA

• Authentication function, AAA supports the following authentication methods:

  • No authentication: Trust users very much and do not check them. Generally, this method is not used.

  • Local authentication: Configure user information (including the user name, password, and various attributes of local users) on the access server. The advantage of local authentication is that it is fast and reduces operating costs; but the amount of information stored is limited by the hardware conditions of the device.

  • Remote authentication: It supports remote authentication through RADIUS protocol or HWTACACS protocol. The access server acts as the client to communicate with the RADIUS server or TACACS server.

• Authorization function, AAA supports the following authorization methods:

  • Direct authorization: Trust the user very much and authorize directly.

  • Local authorization: Authorize according to the relevant attributes configured for the local user account on the broadband access server.

  • HWTACACS authorization: The TACACS server authorizes users.

  • if-authenticated authorization: If the user is authenticated and the authentication method used is not none, the user is authorized to pass.

  • Authorization after successful RADIUS authentication: The authentication and authorization of the RADIUS protocol are bound together, and you cannot use RADIUS alone for authorization.

• Accounting function, AAA supports the following accounting methods:

  • No billing

  • Remote accounting: Support remote accounting through RADIUS server or TACACS server.

3. Why RADIUS uses UDP instead of TCP

The RADIUS protocol uses the UDP protocol. Data packets may be lost on the network. If the client does not receive a response, the request packet can be resent. If the response is still not received after multiple transmissions, the RADIUS client can send a request packet to the backup RADIUS server.
RADIUS is a distributed, C/S-based information exchange protocol that can include the network without interference from unauthorized access. It is often used in various network environments that require high security and allow remote user access.

The protocol defines the RADIUS message format and transmission mechanism based on UDP (User Datagram Protocol), and specifies UDP port 1812 as the authentication port and 1813 accounting port.

If it is a Cisco device: the authentication and authorization port is UDP1645, and the accounting port is 1646.

RADIUS was originally an AAA protocol for dial-up users. Later, with the diversified development of user access methods, RADIUS also adapted to multiple user access methods, such as Ethernet access. It provides access services through authentication and authorization, and collects and records the use of network resources by users through charging.

The reasons for using UDP are as follows

• NAS and RADIUS servers are mostly in the same LAN, using UDP is faster and more convenient.

• Simplifies the implementation of the server.

• The data transmitted between the NAS and the RADIUS server is generally tens to hundreds of bytes in length, and users have to tolerate the authentication waiting time of several seconds to ten seconds. When dealing with a large number of users, the server side uses multi-threading, and UDP simplifies the server-side implementation process.

• TCP must successfully establish a connection before data transmission can be carried out. This method has poor real-time performance when used by a large number of users.

• When the request to the main server fails, the request must be sent to the standby server. Therefore, RADIUS must have a retransmission mechanism and a backup server mechanism. The timing mechanism it uses cannot be satisfied by TCP.

• RADIUS has its own mechanism to solve the characteristics of UDP packet loss.

  If the NAS submits a request to a RADIUS server without receiving the return information, it can request the backup RADIUS server to retransmit. Since there are multiple backup RADIUS servers, the NAS can use the polling method when retransmitting. If the key of the backup RADIUS server is different from the key of the previous RADIUS server, re-authentication is required.

Fourth, the architecture of Radius:

Client/server model.

RADIUS client

Generally located on the network access server NAS (Network Access Server), which can spread across the entire network, is responsible for transmitting user information to a designated RADIUS server, and then corresponding processing (such as accepting/rejecting user access) based on the information returned from the server.

As a client of the RADIUS protocol, the device implements the following functions:

• Support standard RADIUS protocol and extended attributes, including RFC (Request For Comments) 2865 and RFC 2866.
• Support Huawei extended private attributes.
• Active detection of RADIUS server status.
• Local buffering and retransmission of accounting end packets.
• Automatic switching function of RADIUS server.

RADIUS server

Generally running on a central computer or workstation, it maintains relevant user authentication and network service access information, is responsible for receiving user connection requests and authenticating users, and then returning all required information to the client (such as accepting/rejecting authentication requests). The RADIUS server usually maintains three databases.

• Users: Used to store user information (such as user name, password, and configuration information such as the used protocol and IP address).
• Clients: Used to store RADIUS client information (such as shared keys and IP addresses of access devices).
• Dictionary: used to store the meaning of attributes and attribute values ​​in the RADIUS protocol.

Five, the main features of Radius

• Client/server model

The network access server (NAS) operates as a RADIUS client. The client is responsible for passing user information to the designated RADIUS server and then performing operations on the response returned. The RADIUS server is responsible for receiving the user connection request, authenticating the user, and then returning all the clients to deliver the required configuration information service to the user.

The RADIUS server can be used as a proxy client of other RADIUS servers or other types of authentication servers.

• cyber security

The transaction between the client and the RADIUS server is through the use of a shared secret for authentication. In addition, sending any user password is encrypted between the client and the RADIUS server, eliminating the possibility of someone snooping on an insecure network to determine the user password.

• Flexible authentication mechanism

The RADIUS server can support multiple methods of authenticating users. Including point-to-point PAP authentication (PPP PAP), point-to-point CHAP authentication (PPP CHAP), UNIX login operation (UNIX login), and other authentication mechanisms.

• Scalable protocol

All transactions are composed of variable-length Attribute length value 3-tuples. New attribute values ​​can be added to affect the existing implementation of the protocol.

Six, RADIUS packet

RADIUS packet format

The explanation of each field of the message transmission based on UDP message is as follows:

• Code: The length is 1 byte, used to describe the type of RADIUS packet.

Code value	Message type
1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
255	Reserved (reserved, used when generating a new data packet)

• Identifier: The length is 1 byte (0~255), used to match the request message and the response message, and to detect the request message retransmitted within a period of time (to prevent replay attacks). After the client sends the request message, the Identifier value in the response message returned by the server should be the same as the Identifier value in the request message .
• Length: The length is 2 bytes, used to specify the length of the RADIUS packet. Indicates the length of the RADIUS data area (including Code, Identifier, Length, Authenticator, Attributes), in bytes, the minimum is 20, and the maximum is 4096. Bytes exceeding the value of Length will be ignored as padding characters. If the actual length of the received packet is less than the value of Length, the packet will be discarded.
• Authenticator: The length is 16 bytes, used to verify the response message of the RADIUS server, and also used to encrypt the user password.
• Attribute: variable length, the main body of the message, used to carry special authentication, authorization, and accounting information, and provide configuration details of the request and response messages. Attribute can include multiple attributes, and each attribute is represented by a triple structure of (Type, Length, Value) (the meaning of specific attribute values ​​is not elaborated).

RADISU message type:

Currently, RADIUS defines sixteen message types.

RADIUS authentication packet

• Access-Request: Authentication request message, the first message in the RADIUS message interaction process, used to carry user authentication information (for example, user name, password, etc.). The authentication request message is sent by the RADIUS client to the RADIUS server, and the RADIUS server determines whether to allow access based on the user information carried in the message .

• Access-Accept: Authentication acceptance message, which is the server's acceptance response message to the Access-Request message sent by the client. If all attributes in the Access-Request message are acceptable (that is, the authentication is passed), then this type of message is sent. After the client receives this message, the authenticated user can be authenticated and given the corresponding authority.

• Access-Reject: The authentication rejection message is the server's rejection response message to the client's Access-Request message. If any attribute in the Access-Request packet is unacceptable (that is, authentication fails), the RADIUS server returns an Access-Reject packet, and user authentication fails.

RADIUS accounting packet

• Accounting-Request(Start): Accounting start request message. If the client uses the RADIUS mode for accounting, the client will send an accounting start request message to the server when the user starts to access network resources.

• Accounting-Response (Start): Accounting start response message. After the server receives and successfully records the charging start request message, it needs to respond with a charging start response message.

• Accounting-Request (Interim-update): Real-time accounting request message. To prevent the charging server from failing to receive the charging stop request message and continue charging for the user, you can configure the real-time charging function on the client . The client periodically sends real-time accounting messages to the server to reduce accounting errors.

• Accounting-Response (Interim-update): Real-time accounting response message. After the server receives and successfully records the real-time charging request message, it needs to respond with a real-time charging response message.

• Accounting-Request (Stop): Accounting end request message. When the user is disconnected (the connection can also be disconnected by the access server), the client sends a billing end request message to the server, which includes the statistical information of the network resources used by the user (online time, in/out The number of bytes, etc.), request the server to stop accounting.

• Accounting-Response (Stop): Accounting end response message. After the server receives the charging stop request message, it needs to respond with a charging stop response message.

RADIUS authorization packet

CoA: (Change of Authorization) means that after the user is successfully authenticated, the administrator can modify the authority of the online user through the RADIUS protocol.

DM: (Disconnect Message) refers to a user offline message, that is, a message initiated by the RADIUS server to force a user to go offline.

• CoA-Request: Dynamic authorization request message. When the administrator needs to change the authority of an online user (for example, the administrator does not want the user to access a certain website), a dynamic authorization request message can be sent to the client through the server, so that the client can modify the authority of the online user.

• CoA-ACK: Dynamic authorization request acceptance message. If the client successfully changes the user's authority, the client responds to the dynamic authorization request acceptance message to the server.

• CoA-NAK: Dynamic authorization request rejection message. If the client fails to change the user's permissions, the client responds with a dynamic authorization request rejection message to the server.

• DM-Request: User offline request message. When the administrator needs to let an online user offline, he can send a user offline request message to the client through the server, so that the client terminates the user's connection.

• DM-ACK: The user requests to accept messages offline. If the client has cut off the user's connection, the client responds to the user's offline request to accept the message to the server.

• DM-NAK: The user requests a rejection message offline. If the client cannot cut off the user's connection, the client responds to the user's offline request rejection message to the server.

Seven, RADIUS working process

1. User dial-in

2. The dial-in device (such as NAS) packages the information of the dial-in user (such as user name, password, occupied port, etc.) to the RADIUS server. If the Radius server sends an Access-Challenge to request secondary authentication, the Radius client will collect user information again and send it through the Access-Request.

3. If the user is a legitimate user, Radius tells the NAS that the user can access the Internet and at the same time returns the configuration parameters of the user; otherwise, Radius feeds back the illegal information of the user to the NAS.

4. If the user is valid, the NAS configures the user according to the configuration parameters returned from the RADIUS server. If the user is illegal, the NAS will feedback an error message to the user and disconnect the user.

5. If the user can access the network, the RADIUS client must send an accounting request packet to the RADIUS server to indicate that accounting for the user has started.

6. The RADIUS server shall respond after receiving and successfully recording the request packet.

7. When the user disconnects (the connection can also be disconnected by the access server).

8. The RADIUS client sends an accounting stop request packet to the RADIUS server, which contains the statistical information of the network resources used by the user to access the Internet (the duration of the Internet access, the number of bytes/packets in/out, etc.).

9. The RADIUS server shall respond after receiving and successfully recording the request packet.

8. RADIUS proxy

For a RADIUS proxy server, after a RADIUS server receives an authentication request (or accounting request) from a RADIUS client (such as a NAS server), it submits the request to a remote RADIUS server and receives the request from the remote server. After replying, the reply is transmitted to the customer. This reply may contain changes that reflect the local management strategy. RADIUS proxy server is usually used for roaming. The roaming function allows two or more management entities to allow each user to dial into any entity network for a certain service.

A RADIUS server can operate as a forwarding server and a remote server at the same time. As a forwarding server in some domains, as a remote server in other domains. A forwarding server can act as a forwarder for any number of remote servers. A remote server can have any number of forwarding servers forwarding to it, and it can also provide authentication to any number of domains. A forwarding server can forward to another forwarding server, thereby generating a proxy chain. Care should be taken to avoid circular references.

The following procedure explains the communication of a proxy server between a NAS server, a forwarding server, and a remote server.

1. The NAS sends an access request to a forwarding server.
2. The forwarding server forwards the request to a remote server.
3. The remote server sends back an access permission, an access rejection, or an access challenge to the forwarding server. At this time, the server sends back the access permission.
4. The forwarding server transmits the access permission to the NAS.

The forwarding server must treat any agent state attributes that are already in the data packet as invisible data. Its operation must not rely on the content added to the agent state attribute by the previous server.

If there are any proxy status attributes in the request received from the client, the forwarding server must include these proxy status attributes in the reply to the client. When the forwarding server forwards this request, it can include the proxy state attribute in it, or it can ignore the proxy state attribute in the forwarded request. If the forwarding server ignores the proxy state attributes in the forwarded access request, it must add these proxy state attributes to the response before the response is returned to the user.