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.

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 (a 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)

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)

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)

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.

The following is a list of the EAP supported authentication methods you can use with the HP-UX AAA Server A.06.01:

Transport Layer Security (TLS): Uses TLS (also known as SSL) to authenticate the client using its digital certificate. Note: some wireless supplicants require specific extensions to support certificates for EAP. TLS features include: Dynamic Key Exchange; Mutual Authentication; Digital Certificate/Token Card-based Authentication; and, Encrypted Tunnelling.
Tunneled TLS (TTLS): Can carry additional EAP or legacy authentication methods like PAP, MS-CHAP, and CHAP. Integrates with the widest variety of password storage formats and existing password-based authentication systems. Wireless supplicants available for a large number of clients. TTLS features include: Dynamic Key Exchange; Mutual Authentication; Password-based Authentication; and, Encrypted Tunnelling.
Protected EAP (PEAP): Functionally very similar to TTLS, but does not encapsulate legacy authentication methods. PEAP features include: Dynamic Key Exchange; Mutual Authentication; and, Encrypted Tunnelling.
Message Digest 5 (MD5): Passwords are hashed using the MD5 algorithm. Can be deployed for protecting access to LAN switches where the authentication traffic will not be transmitted over airwaves. Can also be safely deployed for wireless authentication inside EAP tunnel methods. The main feature in MD5 is Password-based Authentication.
Lightweight EAP (LEAP) : For Legacy Cisco equipment only. LEAP features include: Dynamic Key Exchange; Mutual Authentication; and, Password-based Authentication.
Generic Token Card (GTC): Carries user specific token cards for authentication. The main feature in GTC is Digital Certificate/Token Card-based Authentication.
EAP MS-CHAP: Passwords are hashed using a Microsoft algorithm. Can be deployed for protecting access to LAN switches where the authentication traffic will not be transmitted over airwaves. Can also be safely deployed for wireless authentication inside EAP tunnel methods. EAP-MSCHAP features include Mutual Authentication and Password-based Authentication.

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, see the Administrator’s Guide.

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.