Radius Overview

RADIUS is a distributed client/server protocol that secures networks against unauthorized access. RADIUS includes two pieces: an authentication server and client protocols. A NAS operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response that is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. RADIUS servers can act as proxy clients to other kinds of authentication servers. RADIUS uses User Datagram Protocol (UDP) as the communication protocol between the client and the server on port UDP 1645. Figure 6-2 shows a RADIUS server supporting a dialup client.

Figure 6-2. Dialup Client Supported by a RADIUS Server

Figure 6-2. Dialup Client Supported by a RADIUS Server

The RADIUS packet format includes the following fields:

• Code Identifies the type of RADIUS command/response packet. There are five types of packets: Access-Request, Access-Accept, Access-Reject, Accounting-Request, and Accounting Response. This field is 1 octet.

• Identifier Correlates a request packet to response packet and detects duplicate requests. This field is 1 octet.

• Length Specifies the length of the entire RADIUS packet. This field is 2 octets.

• Authenticator Authenticates the reply from the RADIUS server and is used in the password-hiding algorithm. The authenticator field is 16 octets long. The two types of authenticators are the Request Authenticator and the Response Authenticator:

- Request Authentication Available in Access-Request and Accounting-Request packets

- Response Authenticator Available in Access-Accept, Access-Reject, Access-Challenge, and Accounting-Response packets

• Attributes Carries the specific AAA details for the request and response.

RADIUS attributes are divided into two categories: RADIUS Internet Engineering Task Force (IETF) attributes and the vendor-specific attributes (VSA). The IETF attributes are a predefined set of standard attributes that are used in the AAA communication between client and server. RADIUS VSAs are a subset of the IETF attribute: vendor-specific (attribute 26). Vendors may use this attribute to create up to 255 additional custom attributes and encapsulate them behind attribute 26. You can find a complete list of IETF attributes at Cisco.com . You can find a list of IETF attributes in RFC 2865, RFC 2866, RFC 2867, RFC 2868, and RFC 2869.

When a user attempts to log in and authenticate to an access server using RADIUS, the following steps occur: 1.

The user is prompted for and enters a username and password. 2.

The username and encrypted password are sent over the network to the RADIUS server. 3.

The user receives one of the following responses from the RADIUS server:

- ACCEPT The user is authenticated.

- REJECT The user is not authenticated and is prompted to reenter the username and password, or access is denied.

- CHALLENGE A challenge is issued by the RADIUS server. The challenge collects additional data from the user.

- CHANGE PASSWORD A request is issued by the RADIUS server, asking the user to select a new password.

The ACCEPT or REJECT response is bundled with additional data that is used for EXEC or network authorization. You must first complete RADIUS authentication before using RADIUS authorization.

RADIUS encrypts only the password in the Access-Request packet from the client to the server. The remainder of the packet is unencrypted. Other information, such as username, authorized services, and accounting, could be captured by a third party.

The RADIUS server supports a variety of methods to authenticate a user. When it is provided with the username and original password given by the user, it can support PPP, PAP, CHAP, UNIX login, Extensible Authentication Protocol (EAP), and other authentication mechanisms.

RADIUS combines authentication and authorization. The Access-Accept packets sent by the RADIUS server to the client contain authorization information, which makes it difficult to decouple authentication and authorization. RADIUS does perform accounting separately.

RADIUS and TACACS+ have several key differences. Table 6-3 briefly compares TACACS+ and RADIUS.

AAA support

AAA services are separate.

Authentication and authorization are combined, but accounting services are separate. Transport protocol TCP port 49.

The original RFC ports (still supported) are as follows:

UDP port 1645 authentication/authorization

UDP port 1646 accounting

New (additional) ports are as follows:

UDP port 1812 authentication/authorization

UDP port 1813 accounting

Challenge/response

Bidirectional.

Unidirectional.

Protocol support

Multiproctocol support.

No NetBIOS Extended User Interface (NetBEUI), ARA, Netware Asynchronous Services Interface (NASI), and X.25 PAD.

Data integrity

The entire TACACS+ packet is encrypted in MD5.

Only the user password is encrypted.

Accounting

Limited.

Extensive.

Multilevel authorization Per user or per group. No privilege level control. Interoperability

Cisco specific. Industry-standard RFC.

0 0

Post a comment