Table Of Contents

Overview

RADIUS Protocol

Steps to Connection

Types of RADIUS Messages

Packet Contents

The Attribute Dictionary

Proxy Servers

Cross Server Session and Resource Management

Overview

Session-Service Service Step and Radius-session Service

Configure Front Line Access Registrar

Configure Central AR

Overview

---

The chapter provides an overview of the RADIUS server, including connection steps, RADIUS message types, and using Cisco Access Registrar as a proxy server.

Cisco Access Registrar is a RADIUS (Remote Authentication Dial-In User Service) server that allows multiple dial-in Network Access Server (NAS) devices to share a common authentication, authorization, and accounting database.

Cisco Access Registrar handles the following tasks:

•Authentication—determines the identity of users and whether they may be allowed to access the network

•Authorization—determines the level of network services available to authenticated users after they are connected

•Accounting—keeps track of each user's network activity

•Session and resource management—tracks user sessions and allocates dynamic resources

Using a RADIUS server allows you to better manage the access to your network, as it allows you to store all security information in a single, centralized database instead of distributing the information around the network in many different devices. You can make changes to that single database instead of making changes to every network access server in your network.

RADIUS Protocol

Cisco Access Registrar is based on a client/server model, which supports AAA (authentication, authorization, and accounting). The client is the Network Access Server (NAS) and the server is Cisco Access Registrar. The client passes user information on to the RADIUS server and acts on the response it receives. The server, on the other hand, is responsible for receiving user access requests, authenticating and authorizing users, and returning all of the necessary configuration information the client can then pass on to the user.

The protocol is a simple packet exchange in which the NAS sends a request packet to the Cisco Access Registrar with a name and a password. Cisco Access Registrar looks up the name and password to verify it is correct, determines for which dynamic resouces the user is authorized, then returns an accept packet that contains configuration information for the user session (Figure 1-1).

Figure 1-1 Packet Exchange Between User, NAS, and RADIUS

Cisco Access Registrar can also reject the packet if it needs to deny network access to the user. Or, Cisco Access Registrar may issue a challenge that the NAS sends to the user, who then creates the proper response and returns it to the NAS, which forwards the challenge response to Cisco Access Registrar in a second request packet.

In order to ensure network security, the client and server use a shared secret, which is a string they both know, but which is never sent over the network. User passwords are also encrypted between the client and the server to protect the network from unauthorized access.

Steps to Connection

Three participants exist in this interaction: the user, the NAS, and the RADIUS server. The following steps describe the receipt of an access request through the sending of an access response.

---

Step 1 The user, at a remote location such as a branch office or at home, dials into the NAS, and supplies a name and password.

Step 2 The NAS picks up the call and begins negotiating the session.

a. The NAS receives the name and password.

b. The NAS formats this information into an Access-Request packet.

c. The NAS sends the packet on to the Cisco Access Registrar server.

Step 3 The Cisco Access Registrar server determines what hardware sent the request (NAS) and parses the packet.

d. It sets up the Request dictionary based on the packet information.

e. It runs any incoming scripts, which are user-written extensions to Cisco Access Registrar. An incoming script can examine and change the attributes of the request packet or the environment variables, which can affect subsequent processing.

f. Based on the scripts or the defaults, it chooses a service to authenticate and/or authorize the user.

Step 4 Cisco Access Registrar's authentication service verifies the username and password is in its database. Or, Cisco Access Registrar delegates the authentication (as a proxy) to another RADIUS server, an LDAP, or TACACS server.

Step 5 Cisco Access Registrar's authorization service creates the response with the appropriate attributes for the user's session and puts it in the Response dictionary.

Step 6 If you are using Cisco Access Registrar session management at your site, the Session Manager calls the appropriate Resource Managers that allocate dynamic resources for this session.

Step 7 Cisco Access Registrar runs any outgoing scripts to change the attributes of the response packet.

Step 8 Cisco Access Registrar formats the response based on the Response dictionary and sends it back to the client (NAS).

Step 9 The NAS receives the response and communicates with the user, which may include sending the user an IP addres,s to indicate the connection has been successfully established.

Types of RADIUS Messages

The client/server packet exchange consists primarily of the following types of RADIUS messages:

•Access-Request—sent by the client (NAS) requesting access

•Access-Reject—sent by the RADIUS server rejecting access

•Access-Accept—sent by the RADIUS server allowing access

•Access-Challenge—sent by the RADIUS server requesting more information in order to allow access. The NAS, after communicating with the user, responds with another Access-Rrequest.

When you use RADIUS accounting, the client and server can also exchange the following two types of messages:

•Accounting-Request—sent by the client (NAS) requesting accounting

•Accounting-Response—sent by the RADIUS server acknowledging accounting

Packet Contents

The information in each RADIUS message is encapsulated in a UDP (User Datagram Protocol) data packet. A packet is a block of data in a standard format for transmission. It is accompanied by other information, such as the origin and destination of the data.

Table 1-1 lists each message packet which contains the following five fields:

Table 1-1 RADIUS Packet Fields

Fields	Description
Code	Indicates what type of message it is: Access-Request, Access-Accept, Access-Reject, Access-Challenge, Accounting-Request, or Accounting-Response.
Identifier	Contains a value that is copied into the server's response so the client can correctly associate its requests and the server's responses when multiple users are being authenticated simultaneously.
Length	Provides a simple error-checking device. The server silently drops a packet if it is shorter than the value specified in the length field, and ignores the octets beyond the value of the length field.
Authenticator	Contains a value for a Request Authenticator or a Response Authenticator. The Request Authenticator is included in a client's Access-Request. The value is unpredictable and unique, and is added to the client/server shared secret so the combination can be run through a one-way algorithm. The NAS then uses the result in conjunction with the shared secret to encrypt the user's password.
Attribute(s)	Depends on the type of message being sent. The number of attribute/value pairs included in the packet's attribute field is variable, including those required or optional for the type of service requested.

The Attribute Dictionary

The Attribute dictionary contains a list of preconfigured authentication, authorization, and accounting attributes that can be part of a client's or user's configuration. The dictionary entries translate an attribute into a value Cisco Access Registrar uses to parse incoming requests and generate responses. Attributes have a human-readable name and an enumerated equivalent from 1-255.

Sixty three standard attributes exist, which are defined in RFC 2138 and 2139. There also are additional vendor-specific attributes that depend on the particular NAS you are using. For a complete list of attributes, see Chapter 5 of the Cisco Access Registrar Concepts and Reference Guide.

Some sample attributes include:

•User-Name—the name of the user

•User-Password—the user's password

•NAS-IP-Address—the IP address of the NAS

•NAS-Port—the NAS port the user is dialed in to

•Framed Protocol—such as SLIP or PPP

•Framed-IP-Address—the IP address the client uses for the session

•Filter-ID—vendor-specific; identifies a set of filters configured in the NAS

•Callback-Number—the actual callback number.

Proxy Servers

Any one or all of the RADIUS server's three functions: authentication, authorization, or accounting can be subcontracted to another RADIUS server. Cisco Access Registrar then becomes a proxy server. Proxying to other servers enables you to delegate some of the RADIUS server's functions to other servers.

You could use Cisco Access Registrar to "proxy" to an LDAP server for access to directory information about users in order to authenticate them. Figure 1-2 shows user joe initiating a request, the Cisco Access Registrar server proxying the authentication to the LDAP server, and then performing the authorization and accounting processing in order to enable joe to log in.

Figure 1-2 Proxying to an LDAP Server for Authentication

Cross Server Session and Resource Management

Prior to AR 1.6, sessions and resources were managed locally, meaning that in a multi-AR server environment, resources such as IP addresses, user-based session limits, and group-based session limits were divided between all the AR servers. It also meant that, to ensure accurate session tracking, all packets relating to one user session were required to go to the same AR server.

Overview

Access Registrar 1.6 and above can manage sessions and resources across AAA server boundaries. A session can be created by an Access-Request sent to AR1, and it can be removed by an Accounting-Stop request sent to AR2, as shown in Figure 1-3. This enables accurate tracking of User and Group session limits across multiple AAA servers, and IP addresses allocated to sessions are managed in one place.

Figure 1-3 Multiple AR Servers

All resources that must be shared cross multiple front line ARs are configured in the Central Resource AR. Resources that are not shared can still be configured at each front line AR as done prior to the AR 1.6 release.

When the front line AR receives the access-request, it does the regular AA processing. If the packet is not rejected and a Central Resource AR is also configured, the front line AR will proxy the packet¹ to the configured Central Resource AR. If the Central Resource AR returns the requested resources, the process continues to the local session management (if local session manager is configured) for allocating any local resources. If the Central Resource AR cannot allocate the requested resource, the packet is rejected.

When the Accounting-Stop packet arrives at the frontline AR, AR does the regular accounting processing. Then, if the front line AR is configured to use Central Resource AR, a proxy packet will be sent to Central Resource AR for it to release all the allocated resources for this session. After that, any locally allocated resources are released by the local session manager.

Session-Service Service Step and Radius-session Service

A new Service step has been added in the processing of Access-Request and Accounting packets. This is an additional step after the AA processing for Access packet or Accounting processing for Accounting packet, but before the local session management processing. The Session-Service should have a service type of radius-session.

An environment variable Session-Service is introduced to determine the Session-Service dynamically. You can use a script or the rule engine to set the Session-Service environment variable.

Configure Front Line Access Registrar

To use a Central Resource server, the DefaultSessionService property must be set or the Session-Service environment variable must be set through a script or the rule engine. The value in the Session-Service variable overrides the DefaultSessionService.

The configuration parameters for a Session-Service service type are the same as those for configuring a radius service type for proxy, except the service type is radius-session.

The configuration for a Session-Service Remote Server is the same as configuring a proxy server.

[ //localhost/Radius ]

Name = Radius

Description =

Version = 1.6R0

IncomingScript =

OutgoingScript =

DefaultAuthenticationService = local-users

DefaultAuthorizationService = local-users

DefaultAccountingService = local-file

DefaultSessionService = Remote-Session-Service

DefaultSessionManager = session-mgr-1

[ //localhost/Radius/Services ]

Remote-Session-Service/

   Name = Remote-Session-Service

   Description =

   Type = radius-session

   IncomingScript =

   OutgoingScript =

   OutagePolicy = RejectAll

   OutageScript =

   MultipleServersPolicy = Failover

   RemoteServers/

1. central-server

[ //localhost/Radius/RemoteServers ]

central-server/

   Name = central-server

   Description =

   Protocol = RADIUS

   IPAddress = 209.165.200.224

   Port = 1645

   ReactivateTimerInterval = 300000

   SharedSecret = secret

   Vendor =

   IncomingScript =

   OutgoingScript =

   MaxTries = 3

   InitialTimeout = 2000

   AccountingPort = 1646

Configure Central AR

Resources at the Central Resource server are configured the same way as local resources are configured. These resources are local resources from the Central Resource server's point of view.

¹ The proxy packet is actually a resource allocation request, not an Access Request.