RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. It can protect networks against unauthorized access and is often used in network environments that require both high security and remote user access.

RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting.

RADIUS was originally designed for dial-in user access. With the addition of new access methods, RADIUS has been extended to support additional access methods, including Ethernet and ADSL. RADIUS provides access authentication, authorization, and accounting services. The accounting function collects and records network resource usage information.

The RADIUS client runs on every NAS on the network to pass user information to the RADIUS server and determines to reject or accept each access request based on the server response.

The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network access. It receives connection requests, authenticates users, and returns access control information (for example, rejecting or accepting the user access request) to the client.

The RADIUS server typically maintains the following databases: Users, Clients, and Dictionary. See Figure 2.

• Users—Stores user information, such as the usernames, passwords, applied protocols, and IP addresses.

• Clients—Stores information about RADIUS clients, such as shared keys and IP addresses.

• Dictionary—Stores RADIUS protocol attributes and their values.

The RADIUS client and the RADIUS server use a shared key to authenticate RADIUS packets and encrypt user passwords exchanged between them. For security, this key must be manually configured on the client and the server.

RADIUS servers support multiple authentication protocols, including PAP and CHAP. A RADIUS server can also act as the client of another AAA server to provide authentication proxy services.

Figure 3 illustrates the interactions between the host, the RADIUS client, and the RADIUS server.

RADIUS operates in the following manner:

RADIUS uses UDP to transmit messages. To ensure smooth message exchange between the RADIUS server and the client, RADIUS uses timer management, retransmission, and a backup server mechanism. Figure 4 shows the RADIUS packet format.

Descriptions of the fields are as follows:

• The Code field (1 byte long) indicates the type of the RADIUS packet.

• The Identifier field (1 byte long) is used to match request packets and response packets and to detect duplicate request packets. Request and response packets of the same type have the same identifier.

• The Length field (2 bytes long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are considered padding and are ignored at the receiver. If the length of a received packet is less than this length, the packet is dropped. The value of this field is in the range 20 to 4096.

• The Authenticator field (16 bytes long) is used to authenticate responses from the RADIUS server and to encrypt user passwords. There are two types of authenticators: request authenticator and response authenticator.

• The Attributes field (variable in length) carries the specific authentication, authorization, and accounting information that defines the configuration details of the request or response. This field may contain multiple attributes, each with three sub-fields:

  • Type—(1 byte long) Type of the attribute. It is in the range of 1 to 255. Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868. Table 2 shows a list of the attributes. For more information, see "Commonly used standard RADIUS attributes."

  • Length—(1 byte long) Length of the attribute in bytes, including the Type, Length, and Value sub-fields.

  • Value—(Up to 253 bytes) Value of the attribute. Its format and content depend on the Type and Length sub-fields.

Attribute 26 (Vender-Specific), an attribute defined in RFC 2865, allows a vendor to define extended attributes to implement functions that the standard RADIUS protocol does not provide.

A vendor can encapsulate multiple sub-attributes as TLVs in attribute 26 to provide extended functions. As shown in Figure 5, a sub-attribute encapsulated in attribute 26 consists of the following parts:

• Vendor-ID—ID of the vendor. Its most significant byte is 0. The other three bytes contains a code that is compliant to RFC 1700. For more information about the proprietary RADIUS sub-attributes of HPE, see "HPE proprietary RADIUS sub-attributes."

• Vendor-Type—Type of the sub-attribute.

• Vendor-Length—Length of the sub-attribute.

• Vendor-Data—Contents of the sub-attribute.