User Guide for the Cisco Secure Access Control System 5.0
AAA Protocols
Downloads: This chapterpdf (PDF - 186.0KB) The complete bookPDF (PDF - 12.93MB) | Feedback

AAA Protocols

Table Of Contents

AAA Protocols

Typical Use Cases

Device Administration

Session Access Requests (RADIUS or TACACS+)

Command Authorization Requests (TACACS+ Only)

Network Access

RADIUS with PAP Authentication

RADIUS with EAP Authentication

Access Protocols—TACACS+ and RADIUS

Overview of TACACS+

Overview of RADIUS

RADIUS VSAs

ACS 5.0 as the AAA Server

RADIUS Attribute Support in ACS 5.0

RADIUS Access Requests


AAA Protocols


This section contains the following topics:

Typical Use Cases

Access Protocols—TACACS+ and RADIUS

Overview of TACACS+

Overview of RADIUS

Typical Use Cases

This section contains the following topics:

Device Administration

Network Access

Device Administration

Figure A-1 shows the flows associated with device administration. The two primary triggers are:

Session Access Requests (RADIUS or TACACS+).

Command Authorization Requests (TACACS+ Only).

Figure A-1 Device Administration Flow

Session Access Requests (RADIUS or TACACS+)


Note The numbers refer to Figure A-1.


For session request:

1. An administrator logs in to a network device.

2. The network device sends a RADIUS or TACACS+ access request to ACS.

3. ACS uses an identity store to validate the user's credentials.

4. ACS sends the RADIUS response (access-accept or access-reject) to the network device that will apply the decision. An access-accept response also includes parameters, such as the privilege level that determines the level of administrator access for the duration of the session.

Command Authorization Requests (TACACS+ Only)


Note The numbers refer to Figure A-1.


For command authorization:

1. An administrator issues a command at a network device.

2. The network device sends a TACACS+ access request to ACS.

3. ACS optionally uses an identity store to retrieve user attributes for inclusion in policy processing.

4. The TACACS+ response indicates whether the administrator is authorized to issue the command.

Network Access

For network access, a host connects to the network and requests to use network resources. A network device identifies the new connected host and requests ACS to authenticate and authorize the user.

ACS 5.0 supports these network flows:

RADIUS with PAP Authentication.

RADIUS with EAP Authentication.

RADIUS with EAP-TLS Authentication

RADIUS with EAP-MD5. See EAP-MD5, page B-3.

RADIUS with PEAP (EAP-MSCHAPv2). See PEAPv0v1, page B-12.

RADIUS with EAP-FAST (EAP-MSCHAPv2). See EAP-FAST, page B-16.

RADIUS with PAP Authentication

For RADIUS with PAP authentication:

1. A host connects to the network.

2. A network device sends a RADIUS access request to ACS.

3. ACS uses an identity store to validate the user's credentials.

4. The RADIUS response (access-accept or access-reject) is sent to the network device that will apply the decision.

Figure A-2 shows RADIUS with PAP authentication.

Figure A-2 RADIUS with PAP Authentication

RADIUS with EAP Authentication

EAP provides an extensible framework that can support a variety of authentication types on top of RADIUS. ACS supports authentication by:

Generic EAP

EAP-TLS

PEAP (EAP-MSCHAPv2)

EAP-FAST(EAP-MSCHAPv2)

In generic EAP authentication:

1. The server and the host negotiate to determine the authentication method.

2. Authentication occurs by using the authentication method.

Figure A-3 shows RADIUS with generic EAP authentication.

In generic EAP authentication:

1. A host connects to the network. A network device sends an EAP request to the host.

a. The network access device embeds the EAP packet that it received from the host into a RADIUS request and sends the request to ACS.

b. ACS suggests an EAP method for authentication to the host. The host can accept the method or reject it. If the host rejects the suggested method, another exchange of messages can start.

2. If the host accepts the suggested method, the host sends the appropriate credential data for the agreed EAP authentication method. Then:

a. ACS performs authentication. ACS can use an identity store to validate the user's credentials (if the database is required in the selected authentication method). In some cases, additional message exchanges can occur before authentication against the database.

b. ACS returns an EAP success message to the host and a RADIUS access-accept response to the network device.

Figure A-3 RADIUS with Generic EAP Authentication

Access Protocols—TACACS+ and RADIUS

This section contains the following topics:

Overview of TACACS+

Overview of RADIUS

ACS 5.0 can use the TACACS+ and RADIUS access protocols. Table A-1 compares the two protocols.

Table A-1 TACACS+ and RADIUS Protocol Comparison  

Point of Comparison
TACACS+
RADIUS

Transmission Protocol

TCP—Connection-oriented transport-layer protocol, reliable full-duplex data transmission.

UDP—Connectionless transport-layer protocol, datagram exchange without acknowledgments or guaranteed delivery. UDP uses the IP to get a data unit (called a datagram) from one computer to another.

Ports Used

49

Authentication and Authorization: 1645 and 1812
Accounting: 1646 and 1813.

Encryption

Full packet encryption.

Encrypts only passwords up to 16 bytes.

AAA Architecture

Separate control of each service: authentication, authorization, and accounting.

Authentication and authorization combined as one service.

Intended Purpose

Device management.

User access control.


Overview of TACACS+

TACACS+ must be used if the network device is a Cisco device-management application, access server, router, or firewall. ACS 5.0 supports Cisco device-management applications by providing command authorization for network users who are using the management application to configure managed network devices. You provide support for command authorization for management application users by using unique command sets for each management application that is configured to use ACS for authorization.

ACS 5.0 uses TACACS+ to communicate with management applications. For a management application to communicate with ACS, you must configure the management application in ACS 5.0 as a AAA client that uses TACACS+. Also, you must provide the device-management application with a valid administrator name and password. When a management application initially communicates with ACS, these requirements ensure the validity of the communication.

Transactions between the client and TACACS+ server are authenticated through the use of a shared secret, sent over the network. In addition, user passwords are encrypted before traveling between the client and TACACS+ server to eliminate the possibility that someone snooping on an insecure network could determine a user's password.

Additionally, the administrator that the management application uses must have the Command Set privilege enabled.

Overview of RADIUS

This section contains the following topics:

RADIUS VSAs

ACS 5.0 as the AAA Server

RADIUS Attribute Support in ACS 5.0

RADIUS Access Requests

RADIUS is a client/server protocol through which remote access servers communicate with a central server to authenticate dial-in users, and authorize their access to the requested system or service. A company could use RADIUS to maintain user profiles in a central database that all remote servers can share. This protocol provides better security, and the company can use it to set up a policy that is applied at a single administered network point.

To support the older and newer RFCs, ACS 5.0 accepts authentication requests on port 1645 and port 1812. For accounting, ACS accepts accounting packets on ports 1646 and 1813.

RADIUS VSAs

In addition to support for standard IETF RADIUS attributes, ACS 5.0 includes support for RADIUS vendor-specific attributes (VSAs). ACS 5.0 supports the following predefined RADIUS VSAs:

Cisco

Microsoft

RedCreek

Nortel (Bay Networks)

Ascend

Cisco VPN 3000 Concentrator

Cisco VPN 5000 Series Concentrator

Cisco Airespace

Cisco Aironet

Cisco Business Service Management (BSM)

Juniper

US Robotics

ACS 5.0 supports the list of vendors above only. In the Network Resources section of the ACS 5.0 web interface, you can configure AAA clients to use a user-defined RADIUS VSA as the AAA protocol. In Interface Configuration, you can enable user-level and group-level attributes for user-defined RADIUS VSAs. In User Setup and Group Setup, you can configure the values for enabled attributes of a user-defined RADIUS VSA.

ACS 5.0 as the AAA Server

A AAA server is a server program that handles user requests for access to computer resources, and for an enterprise, provides AAA services. The AAA server typically interacts with network access and gateway servers, and databases and directories that contain user information. The current standard by which devices or applications communicate with an AAA server is RADIUS.

ACS 5.0 functions as a AAA server for one or more network access devices (NADs). The NADs are clients of the ACS server. You must specify the IP address of ACS on each client NAD, to direct user access requests to ACS by using the RADIUS protocol. RADIUS is universally used to secure the access of end-users to network resources. A RADIUS server can act as a proxy to other RADIUS servers or other kinds of authentication servers.


Note RADIUS proxy is not supported for ACS 5.0.


The NAD serves as the network gatekeeper, and sends an access request to ACS on behalf of the user. ACS verifies the username, password, and possibly other data by using the configured LDAP and Windows AD external databases. ACS ultimately responds to the NAD with an access-reject or an access-accept message with a set of authorization attributes.

ACS 5.0 provides network transport over User Datagram Protocol (UDP) and implements the RADIUS protocol, including RADIUS packet parsing and assembling, necessary data validation, and tracking of duplicate requests.

Some reasons for using UDP are:

The processing time is only a few seconds.

No special handling is required for rebooting or offline clients and servers.

UDP is a connectionless protocol.

UDP easily implements multithreaded servers to serve multiple client requests.

The UDP-assigned port number for RADIUS are:

1812 for access requests

1813 for accounting

1645 for access requests

1646 for accounting

ACS 5.0 is the entrance point to the authentication system. ACS listens on specific configurable UDP ports. When data arrives from the network:

1. ACS tries to process the data as a RADIUS client request or proxy response packet.

2. ACS verifies that the packet arrived from the NAD that is registered in the configuration, and then prevents duplicate packet processing.

3. ACS parses the RADIUS packet and performs the necessary validations of its contents.

4. ACS then passes the data for processing to the appropriate flow.

5. When the system is ready to respond, ACS:

a. Receives the result of the data processing.

b. Creates a corresponding response to the client.

c. Returns the response to the network.

RADIUS Attribute Support in ACS 5.0

ACS 5.0 supports the RADIUS protocol as RFC 2865 describes.

ACS 5.0 supports the following types of RADIUS attributes:

IETF RADIUS attributes

Generic and Cisco VSAs

Other vendors' attributes


Note When RADIUS parameters are referenced, the convention [attribute-number] [attribute name] is used. For example, [1]User-Name, where the number and name correspond to that assigned to the parameter in the specification.


RADIUS supports receiving, sending, and dictionary-based parsing and construction of any RADIUS attribute regardless of whether it is a regular attribute, VSA, or Cisco attribute-value (AV) pair. The RADIUS interface in ACS supports the attribute data types defined in RFC 2865, namely:

text (UTF-8)

string (binary)

address (IP)

integer

time

Data types, integer, string, and text enumerated (ENUM) specifications of allowed values are supported. Attribute values are checked against these when packet parsing and construction occur.

ACS uses the RADIUS State attribute (24) to identify a specific conversation. Each conversation has a unique ID. Every conversation is processed under a specific configuration version—the latest available version at the moment the conversation was initiated.


Note The RADIUS State attribute (24) is not used for PAP authentication.


Authentication

ACS supports PAP, EAP-TLS, PEAP (EAP-MSCHAPv2), and EAP-FAST(EAP-MSCHAPv2).

Authorization

Authorization is permitted according to the configured access policies.

Accounting

You can use the accounting functions of the RADIUS protocol independently of the RADIUS authentication or authorization functions. You can use some of the RADIUS accounting functions to send data at the start and end of sessions, and indicate the amount of resources (such as time, packets, bytes, and so on) that you used during the session. An Internet Service Provider (ISP) might use RADIUS access control and accounting software to meet special security and billing needs.

Transactions between the client and RADIUS server are authenticated through the use of a shared secret, sent over the network. In addition, user passwords are sent encrypted between the client and RADIUS server to eliminate the possibility that someone snooping on an insecure network could determine a user's password.

RADIUS Access Requests

A user login contains a query (access-request) from the network access device to the RADIUS server and a corresponding response (access-accept or access-reject) from the server. The access-request packet contains the username, password, NAD IP address, and NAD port, and other relevant attributes.

When the RADIUS server receives the access-request from the NAD, it searches a database for the username. Depending on the result of the database query, an accept or reject is sent. A text message can accompany the access-reject message to indicate the reason for the refusal.

In RADIUS, authentication and authorization are coupled. If the RADIUS server finds the username and the password is correct, the RADIUS server returns an access-accept response, including a list of attribute-value pairs that describe the parameters to use for this session. This list of parameters sets the authorization rights for the user.

Typical parameters include:

Service type

Protocol type

IP address to assign the user (static or dynamic)

Access list to apply

A static route to install in the NAD routing table

The configuration information in the RADIUS server defines which parameters to set on the NAD during installation.