RADIUS Overview

The Remote Authentication Dial In User Service (RADIUS) protocol is widely used and implemented to manage access to network services. It defines a standard for information exchange between a Network Access Server (NAS) and an authentication, authorization, and accounting (AAA) server for performing authentication, authorization, and accounting operations. A RADIUS AAA server can manage user profiles for authentication (verifying user name and password), configuration information that specifies the type of service to deliver, and policies to enforce that may restrict user access.

Server Compatibility

The HP-UX AAA Server should operate with any Network Access Server (NAS) or other network device that adheres to the RADIUS standard. The HP-UX AAA Server has been used successfully in configurations with network devices from the following vendors:

Avail
Ascend/Lucent
Bay Networks
Cisco
Cisco Aironet (software version 11.10 or higher)
Computone
Compaq/DEC
Hewlett Packard
Livingston/Lucent
Shiva/Intel
Telebit
Unisphere
US Robotics/3COM

RADIUS Topology

The RADIUS protocol follows client-server architecture. The client sends user information to the RADIUS AAA server (in an Access-Request message) and after receiving a reply from the server acts according to the returned information. The RADIUS AAA server receives user requests for access from the client, attempts to authenticate the user, and returns the configuration information and polices to the client. The RADIUS AAA server may be configured to authenticate an Access-Request locally or to act as a proxy client and forward a request to another AAA server. After forwarding a request, it handles the message exchanges between the NAS and the remote server. A single server can be configured to handle some requests locally and to forward proxy requests to remote servers.

In Figure 1-1 “Generic AAA Network Topology”, an example ISP uses four AAA servers to handle user requests. Each user organization represents a logical grouping of users (defined as a realm). Each user organization dials in to one of the ISP's servers through an assigned NAS, some of which are shared by the same groups or realm. To provide appropriate service to a customer, the server accesses user and policy information from a repository, which may be integrated with the server, may be an external application, or a database that interfaces with the server. For the HP-UX AAA RADIUS and policy server the repository information may be stored in flat text files or in an external database, such as an Oracle® database or LDAP directory server.

Figure 1-1 Generic AAA Network Topology

Establishing a RADIUS Session

The handling of a user request is series of message exchanges that attempts to provide the user with a network service by establishing a session for the user. This transaction can be described as a series of actions that exchange data packets containing information related to the request. Figure 1-2 “Client-Server RADIUS Transaction” illustrates the details of the transaction between a RADIUS AAA server and a client (an NAS in this example). When the user's workstation connects to the client, the client sends an Access-Request RADIUS data packet to the AAA server.

Figure 1-2 Client-Server RADIUS Transaction

When the server receives the request, it validates the sending client. If the client is permitted to send requests to the server, the server will then take information from the Access-Request and attempt to match the request to a user profile. The profile will contain a list of requirements that must be met to successfully authenticate the user. Authentication usually includes verification of a password, but can also specify other information, such as the port number of the client or the service type that has been requested, that must be verified.

If all conditions are met, the server will send an Access-Accept packet to the client; otherwise, the server will send an Access-Reject. An Access-Accept data packet often includes authorization information that specifies what services the user can access and other session information, such as a timeout value that will indicate when the user should be disconnected from the system.

When the client receives an Access-Accept packet, it will generate an Accounting-Request to start the session and send the request to the server. The Accounting-Request data packet describes the type of service being delivered and the user that will use the service. The server will respond with an Accounting-Response to acknowledge that the request was successfully received and recorded. The user's session will end when the client generates an Accounting-Request—triggered by the user, by the client, or an interruption in service—to stop the session. Again, the server will acknowledge the Accounting-Request with an Accounting-Response.

Supported Authentication Methods

The following list describes the authentication methods the HP-UX AAA Server supports:

Password Authentication Protocol ( PAP) is not a strong authentication method to establish a connection; passwords are sent in clear text between the user and client. When used with RADIUS for authentication, the messages exchanged between the client and server to establish a PPP connection corresponds to Figure 1-2 “Client-Server RADIUS Transaction”. This authentication method is most appropriately used where a plaintext password must be available to simulate a login at a remote host. In such use, this method provides a similar level of security to the usual user login at the remote host.
Challenge-Handshake Authentication Protocol (CHAP) is a stronger authentication protocol to establish a connection. When used with RADIUS for authentication, the messages exchanged between the client and server to establish a PPP connection is similar to Figure 1-2 “Client-Server RADIUS Transaction”. One difference, however, is that a challenge occurs between the user and NAS before the NAS sends an Access-Request. The user must respond by encrypting the challenge (usually a random number) and returning the result. Authorized users are equipped with special devices, like smart cards or software, which can calculate the correct response. The NAS will then forward the challenge and the response in the Access-Request, which the AAA server will use to authenticate the user.
Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) is an implementation of the CHAP protocol that Microsoft created to authenticate remote Windows workstations. In most respects, MS-CHAP is identical to CHAP, but there are some differences. MS-CHAP is based on the encryption and hashing algorithms used by Windows networks, and the MS-CHAP response to a challenge is in a format optimized for compatibility with Windows operating systems.
Extensible Authentication Protocol (EAP) Like CHAP, EAP is a more secure authentication protocol to establish a PPP connection than PAP and offers more flexibility to handle authentication requests with different encryption algorithms. It allows authentication by encapsulating various types of authentication exchanges, such as MD5. These EAP messages can be encapsulated in the packets of other protocols, such as RADIUS, for compatibility with a wide range of authentication mechanisms. This flexibility also allows EAP to be implemented in a way (LEAP, for example) that is more suitable for wireless and mobile environments than other authentication protocols. EAP allows authentication to take place directly between the user and server without the intervention by the access device that occurs with CHAP.




	NOTE: EAP/TLS and EAP/TTLS functionality is not supported in the HP-UX AAA Server A.06.00.

RADIUS Data Packets

The Access-Request and other RADIUS data packets contain a header and a set of attribute-value (A-V) pairs, which are used by the server during the AAA transaction. The RADIUS RFC 2865 defines how vendors can extend the protocol. Encapsulation is the RFC defined way of extending RADIUS. Conflicts can occur when the RFC is not followed. In those cases, the server can map the attributes to unique internal values for processing. For a full description of RADIUS attribute-value pairs, refer to Chapter 17 “Attribute-Value Pairs”.

Data Packet Format

RADIUS requests and replies share a common format, refer to Figure 1-3 “RADIUS Request/Reply Message Format”). These messages are transported by UDP. By default, the server listens on UDP port 1812 for Access-Requests and port 1813 for Accounting-Requests.

Figure 1-3 RADIUS Request/Reply Message Format

Table 1-1 RADIUS Request/Reply Message Format Description

Data	Description
Code	8-bit request/reply type: 1 = Access-Request 2 = Access-Accept 3 = Access-Reject 4 = Accounting-Request 5 = Accounting-Response 11 = Access-Challenge
Id	8-bit message sequence number: value in reply = value in request.
Length	16-bit message length, including the header beginning at Code.
Authenticator	16 octet binary vector: Value in request is randomly generated. Value in reply is MD5 digest of reply message data appended with secret, using vector value from request.
Attributes	Arbitrary numbers of information pairs with format shown in Figure 1-4 “Attribute-Value Pair Format”.

Attribute-Value Pair Format

An attribute-value (A-V) pair represents a variable and one of the possible values that the variable can hold. The A-V pair data format is depicted in Figure 1-4 “Attribute-Value Pair Format”. In the HP-UX AAA server, A-V pairs may be added to configuration files to compare values when trying to authenticate an Access-Request (check items) or to add authorization instructions or other messages to an Access-Accept data packet (reply items). These A-V pair's values will also appear in server session logs. The A-V pairs usually appear as AttributeName=Value in the configuration files and AttributeName=:Type:Value in the log files.

Figure 1-4 Attribute-Value Pair Format

Table 1-2 Attribute Value Pair Format Description

Data	Description
attribute	8-bit value-pair code, listed in the dictionary file.
length	8-bit integer from 2-255.
value	0 - 253 octet information item. (The data type of value is determined by the data type associated with the attribute code.)

As shown in Figure 1-4 “Attribute-Value Pair Format”, the Access-Request contains a set of attribute-value pairs. The A-V pairs typically placed in these requests are the User-Name and User-Password, along with the NAS-IP-Address, NAS-Port, Service-Type, and Framed-Protocol A-V pairs— Framed-Protocol being present only if the user is making a PPP or SLIP connection. Only a few attributes, such as User-Password and CHAP-Password, are encrypted.

(For a full description of RADIUS attribute-value pairs, refer to Chapter 17 “Attribute-Value Pairs”.

Shared Secret

Encrypting the transmission of the User-Password in a request is accomplished by a shared secret. The shared secret is used to sign RADIUS data packets to ensure they are coming from a trusted source. The shared secret is also used to encrypt user passwords with certain authentication methods such as PAP. The HP-UX AAA Server uses the clients configuration file to associate a secret to each client (or server) that is authorized to make use of its services.

RADIUS Overview

Technical documentation

» Table of Contents

» Glossary

» Index