Remote dial-in user authentication service (RADIUS)

Remote dial-in user authentication service (RADIUS)

Http://91mail.51.net provides translation for learning and communication only

It shall not be used for other purposes; otherwise, the consequences shall be borne by you

Abstract: This document describes a protocol used to transmit authentication, authorization, and configuration information between the network access server and the shared authentication server that want to authenticate the connection.

Application tip: The memorandum describes the RADIUS protocol. In earlier versions, radius was configured with UDP port number 1645, which conflicted with datametrics. The officially assigned Port Number of radius is 1812.

1. Introduction

??? This document abolished rfc2138 [1]. This document's changes to rfc2138 can be found in the changlog appendix.

??? Managing a large number of scattered serial lines or modem pools creates a significant management support requirement. Since modem pools has been interpreted as a connection to the external world, they need to pay attention to security, authorization, and billing by managing a user database, this kind of attention can be well reflected. This database combines authentication (authentication username and password) and configuration information details-the type of service that is delivered to the user (for example: serial Line Interface Protocol (slip), end-to-end protocol (PPP), standard remote connection protocol (Telnet), remote login (rlogin )).

Customer/service mode (Client/Server)

??? The Network Access Server operates as a radius client. The client is responsible for passing user information to the specified RADIUS server and performing the returned response.

??? Radius ?????? The server is responsible for receiving user connection requests, identifying users, and returning all necessary configuration information for the client to provide services to users.

??? One RADIUS server can act as a proxy for other RADIUS servers or other type of Authentication servers.

Network Security)

??? Transactions between the client and the RADIUS server are identified by using a shared secret that is never transmitted online. In addition, any user password between the client and the RADIUS server is encrypted and transmitted to avoid the possibility that some people may listen on insecure networks to obtain the user password.

Flexible authentication mechanism)

??? The adius server supports multiple user authentication methods. After the user provides the user name and the original password, the RADIUS server can support point-to-point pap authentication (ppp pap), point-to-point CHAP authentication (ppp chap), and Unix login operations) and other authentication mechanisms.

Extensible Protocol)

All transactions consist of variable-length attributes, length values, and such triplet. The value of the new attribute can be added without interrupting the execution of an existing protocol.

1.1 description of required terms

???? The keywords in the text are "mandatory", "must not", "required", "should", "no", "yes", "no", and "suggestion ", "Maybe", "optional" is explained in this document as described in BCP 14 [2. And whether or not they are capitalized, they all mean the same.

??? If the protocol for an operation cannot meet one or more of the required conditions or meet the conditions that cannot be met, the operation will not be executed. An operation meets all the necessary conditions for the protocol to be executed, such as "mandatory", "required", "required", and "not required". It is called "unconditional obedience "; an operation meets all the "mandatory" and "mandatory" Conditions for the protocol to be executed, but does not fully meet the "yes" and "no" conditions, it is called "Conditional obedience ".

A network access server that does not execute a given service must not have the radius attribute for executing the service. For example, a NAS server that does not provide the Apple Talk Remote Access Protocol (Arap) service must not meet the radius attribute of the Arap service. A nas ?????? The server will certainly regard an unfeasible specified service in the access allowed packet as receiving the access denial packet.

1.2 Terms

This document will be frequently used in the following terms:

Service ????

A service provided by the network access server for dial-up users. For example, point-to-point transmission and remote logon.

Session

???? Each service provided by the NAS server to the dial-up user is composed of sessions. Its start is defined as the first service.

When a session is provided, the end of the session is defined as the end of the service. With the support of the NAS server, you can have multiple parallel or serial sessions.

Simple discard

??? This means that the operation is not capable of further processing, but simply discards data packets. This execution should be initiated

The ability to record errors, such as discarded packets, and the event is recorded in statistics.

2. Run

After a client is configured to use the RADIUS Protocol, any user using the terminal must provide authentication information to the client. This information may appear with a customized prompt. You need to enter your username and password. You can also select a configuration connection protocol, such as a Point-to-Point Protocol, to pass this authentication information through the authentication package.

Once the client receives such information, it will use the RADIUS protocol for authentication. Then, the client creates an access request data packet, which contains the user name, user password, client ID, and port number that the user is accessing. When a password appears, there is an RSA-based information classification algorithm (Message Digest algorithm) MD5 [3] to encrypt it.

"Access Request" is submitted to the RADIUS server over the network. If the server does not return response information for a certain period of time, the request will be transmitted multiple times. When the master server fails or cannot be connected to, the client can send requests to one or more backup servers. The backup server is selected to connect to the master server after multiple attempts to connect to the master server or after a round of loop. Retry and rollback algorithms are the subject of current research. This article will not detail them.

Once the RADIUS server receives the request information, it verifies the client that transmits the information. A client request that does not share confidential information with the RADIUS server will be discarded. If the client is valid, the RADIUS server queries the user database to find the user and compares the queried user name with the user name in the request. The user records in the database contain a set of user access conditions that must be met by the user. They not only contain the user's password verification information, but also can specify the client and port number that can be accessed.

To meet a request, the RADIUS server can also act as a client to transmit requests to other servers.

If any "proxy-state" attribute appears in the access request packet, it must be copied to the response packet without any changes or original order. Other attributes can be placed before, after, or even in the middle of the "proxy-state" attribute.

If any conditions are not met, the RADIUS server sends an "Access-Denial" response, indicating that the user request is invalid. If required, the RADIUS server can include a text message in the access rejection response. The text message can be displayed to the user through the client. No other attributes except the proxy-state attribute are allowed to exist in access-reject responses.

If all the conditions are met and the server will transmit an Access Challenge response, the RADIUS server will send an Access Challenge response. It may contain a text message, a response prompt displayed to the user on the user end, and a status attribute.

If the client receives an access question and supports "challenge/respond", it displays text information to the user and prompts the user to respond. Then, the client submits a source access request containing the new request number and uses the encrypted response to replace the User Password attribute. If so, it also includes the status attribute from the access question. The status attribute should only contain 0 or 1 constants in one request. The server can respond to the new access request using "Access-accept", "Access-reject", or "Access-Challenge.

If all the conditions are met, the user's configuration value table is placed in the access permit response. These values include all the required values for the service type (such as the Serial Line Interface Protocol (slip), point-to-point transmission protocol (PPP), login user (Login User), and delivery requirements. For the Serial Line Interface Protocol (slip) and point-to-point transmission protocol (PPP), these values may include IP addresses, subnet masks, maximum transmission units (MTU ), the compression rate and the specified package filter flag are required. For users in character mode, these values may also include the request protocol and host.

2.1 interrogation/Response

??? During the authentication process, the user is given an unpredictable number and is required to encrypt the number and return the result. Authorized users are equipped with special devices, such as smart cards or software, which can easily calculate correct response results. Unauthorized users can only guess responses because they lack the appropriate device or software and necessary key knowledge to simulate such devices or software.

??? An access question message typically contains a reply message, which contains a question that can be displayed to the user, for example, a value that cannot be repeated. A typical scenario is from an extended server. The extended server knows that the type of authentication code corresponds to the authorized user, therefore, you can select a random or non-repeating pseudo-random number with an appropriate base number and length.

??? The user then enters this question (no repeated value) into his device or software and calculates a response value. The user enters this value to the client, the client submits it to the RADIUS server through the second access request packet. If the response packet matches the expected response packet of the RADIUS server, the server returns an access permitted packet. Otherwise, the server returns a rejected packet.

For example, the Network Access Server transmits an access request packet to the RADIUS server, which contains the identification of the network access server, the port number of the Network Access Server, and the user name, user Password (this password may be a fixed string like "challenge" or ignored ). The server returns an access interrogation packet with status and reply message. The reply message contains "challenge 12345678, enter your response value at the prompt, these rows can be displayed on the Access Server. The Network Access Server (NAS) provides prompt information for this response and transmits a new access request to the server (with the new package number ), this includes the NAS identifier, NAS port number, user name, and user password (the response value entered by the user is encrypted now). It is the same as the status attribute in the access question from the server. Based on whether the response value matches the required value, the server returns an access permit or access denial packet, or even transmits another access interrogation packet.

2.2 combination of non-encrypted authentication and encryption Verification

???? For the password verification protocol (PAP), NAS adopts the pap id and password, and transmits them as the user name and password in an access request package. NAS can contain the service type attribute service-type = framed-user, and framed-Protocol = PPP as a prompt to tell the RADIUS server that the PPP service is the desired service.

??? For the question Handshake Authentication Protocol (CHAP), NAS creates a random question (preferably 16 bytes) and transmits it to the user, the user returns a chap response with the chap ID and chap username. NAS then transmits a request to the RADIUS server. In the request packet, the chap user name replaces the user name (User-name), chap ID and encrypted response value replace chap password (chap-password) (attribute 3 ). A random question can be included in the chap-challenge attribute, or if it is 16 bytes long, it can be put into the request authentication code (request authenticator) in the access request packet) domain. NAS can contain attribute service-type = framed-user, and framed-Protocol = PPP as a prompt to tell the RADIUS server that the PPP service is the desired service.

??? The RADIUS server checks the corresponding password based on the user name, encrypts the cross-query, and uses the MD5 Algorithm to obtain the chap ID byte. The preceding password and chap cross-query (if the chap cross-query attribute exists, otherwise, the request is from the authenticator. The result is compared with the chap password. If they match, the server returns an access allowed packet; otherwise, an access denial packet is returned.

If the RADIUS server cannot perform the requested authentication, it must return an access denial packet. For example, chap requires that a password be transmitted to the server in plaintext so that it can encrypt chap interrogation and compare it with the chap response. If you do not use a plaintext transmission password, the server will transmit an access rejection packet to the client.

2.3 proxy

For the radius proxy server, after receiving a verification request (or accounting request) from a radius client (such as a NAS server), a RADIUS server submits the request to a remote RADIUS server, after receiving a reply from the remote server, the reply will be sent to the customer, which may reflect changes in the local management policy. The radius proxy server is generally used for roaming. The roaming function allows two or more management entities to allow each user to dial in to any physical network for a service.

??? The NAS transmits the radius access request to the forwarding server, which forwards the request to the remote server )". The remote server returns a response (access permit, access rejection, and access question) to the forwarding server, and the forwarding server returns the response to the NAs. For radius proxy operations, the user name attribute can contain a network interface identifier [8]. Which server should receive the transfer request depends on the authentication domain. The authentication domain can be part of the network interface identifier (specified domain. Or, the selection of the server that receives the transfer request can be based on any criteria specified by the transfer server, for example, "called-station ID )".

??? A radius server can run as both the forwarding server and remote server. As a forwarding server in some domains and as a remote server in other domains. A forwarding server can act as a forwarder of any number of remote servers. A remote server can forward any number of forwarding servers to it, and also provide authentication to any number of domains. A forwarding server can forward data to another forwarding server to generate a proxy chain. Avoid circular references.

??? The following describes the communication between a proxy server on a NAS server, a forwarding server, and a remote server.

1. 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 the forwarding server back to the access permit, access denied, or access question. In this example, the server returns the access permit.

??? 4. The forwarding server will allow the access to be transmitted to NAs.

??? The forwarding server must regard any proxy status attribute that already exists in the data packet as invisible data. Its operations are prohibited by being added to the proxy status attribute by the Front server.

??? If you receive a request from a client that contains any proxy status attributes, the forwarding server must include these proxy status attributes in the response to the client. When the forwarding server forwards this request, it can include the proxy status attribute or ignore the proxy status attribute in the forwarded request. If the forwarding server ignores the proxy status attribute in the forwarded access request, it must add these proxy status attributes to the response before the response is returned to the user.

??? Now we will describe each step in more detail.

??? 1. NAS transmits its access request to the forwarding server. If the user password exists, the forwarding server decrypts the user password with the key shared with the NAs. If there is a chap Password attribute in the data packet and no chap interrogation attribute exists, the forwarding server must ensure that the request authentication code is complete or copy it to the chap interrogation attribute.

??? The forwarding server can add only one proxy status attribute to the data packet ). If a proxy is added, the proxy status can only appear after any other proxy status attribute in the data packet. The forwarding server prohibits you from modifying any other proxy status attributes that already exist in the data packet (the forwarding server can choose not to forward them, but cannot modify them ). The forwarding server prohibits you from changing the order of any attribute of the same type, including the agent status.

??? 2. If the user password exists, the keys shared by the forwarding server and remote server are used to encrypt the user password. It also sets the identity as required to forward access requests to the remote server.

??? 3. the remote server (if it is the final target server) will use the user password, chap password, or some methods specified during future expansion to verify the legality of the user, then, access permits, access denied, or access questions are returned to the forwarding server. In this example, the remote server transmits a data packet that is allowed for access. The remote server must follow the original sequence without any modification, copy all proxy status attributes from the access request to the response data

Package.

4. The forwarding server uses the key it shares with the remote server to verify the response authentication code (responseauthenticator). If the verification fails, it will simply discard the data packet. If the verification succeeds, the forwarding server removes the final proxy status (if it has attached one in the packet) and uses the key-issued response authentication code that it shares with the NAs, the recovery ID matches the source request ID transmitted by the NAS, And the transfer access is allowed to the NAs.

The forwarding server may modify attributes to execute local policies. This policy is beyond the scope of this document and is subject to the following restrictions. The forwarding server prohibits the modification of the agent status, status, or category attribute in the data packet.

2.4 why UDP

???? A frequently asked question is why UDP instead of TCP is used as the transmission protocol. The choice of UDP is based on strict technical reasons.

??? There are many arguments that must be understood. Radius is a transaction based on several interesting protocols.

??? 1. If the request sent to the master verification server fails, you must find the slave server.

??? To meet this requirement, the request copy must be retained at the transport layer, meaning that the retransmission timer is still required.

? 2. the timing requirements of this special protocol are significantly different from those provided by TCP.

In an extreme situation, radius does not perform response checks for data loss. Users are willing to wait several seconds to complete the verification. Generally, aggressive TCP Relay (based on average round-trip time) is not required, and TC confirms that P overhead is not required.

? In another extreme case, users do not want to spend minutes waiting for verification. Therefore, reliable TCP data delivery is invalid two minutes later. Quick use of the backup server can be accessed before the user gives up.

? 3. Protocol stateless features simplify the use of UDP

Servers and clients keep changing. The system restarts, or a single power supply. Normally, this will not cause problems,

However, timeout and TCP connection interruption detection may occur, and such exception events can be handled by coding. In any case, UDP completely eliminates such special processing and any part of it. Each server and client only needs to enable UDP transmission once, and then the transmission can be in an open state. It may fail to transmit information from the slave network.

4. UDP simplifies server implementation

In the earliest radius implementation, the server was single-threaded. This means that only one request can be received, processed, and returned. Later, it was found that the background security mechanism would take up real-time (1 second or more) and this was difficult to manage. The request queue of the server is filled up. In every minute, hundreds of users are waiting for verification. The request rotation time is longer than the waiting time that the user can endure, (especially when a special search in the database or the time spent on DNS is greater than 30 seconds ). The obvious solution is multithreading. It is very easy to use UDP to solve this problem. Each request generates a separate process and communicates with the client through a simple UDP packet, so as to directly respond to the client NAs.

UDP is not a panacea. It should be noted that using UDP requires a function embedded in TCP: using UDP, We must contact the same server through manual management to relay the timer, but we don't need to spend the same time. We have to manually manage the timer to connect to the same server, but we don't need to pay the same attention to the timer provided by TCP. This is a penalty for UDP's many advantages at a very low price.

? Without TCP, we may still use tin tank communication with metal wires. However, UDP is a better choice for this special protocol.

2.5 relay prompt

If the RADIUS server and the secondary RADIUS server have a shared key, it is feasible to use the same ID and request authentication code when forwarding data packets to the standby server, because the attribute content has not changed. It is also possible to transmit a new request authentication code to the backup server.

If you change the content (or other attributes) of the user's password, you need a new request authentication code and a new ID.

If NAS transmits a RADIUS request to a server that is identical to the previous server, and the attribute content does not change, you must use the same request authentication code, ID, and source port number. If the attribute is modified, you must use the new request authentication code and ID.

NAS can use the same ID in all servers or use a separate ID for each server, which is determined by the user's requirements. If a NAS requires more than 256 IDs for an additional request, it can use an additional source port number to transmit these requests and track each source port ID. In this way, the maximum number of additional requests to a server at a certain time point is approximately 16,000,000.

2.6 damage to remain active

Some applications have used the transfer test RADIUS request to the server to check whether the server is activated. This method is not possible because it increases additional load and damages measurability because it does not provide any additional useful information. Because a RADIUS request is contained in a separate packet, you may be able to transmit a RADIUS request during the ping period, A radius response is returned, indicating that the RADIUS server is active. If you do not have a radius request to be transmitted, you do not have to worry about whether the server is active because you have not used it.

If you want to monitor your radius server, you can use the Simple Network Management Protocol (SNMP), which is the accusation of SNMP.