Cisco Acs 57 User Guide

							5   
AAA Protocols
Overview of TACACS+
Overview of TACACS+ 
TACACS+ must be used if the network device is a Cisco device-management application, access server, router, or 
firewall. ACS 5.7 supports IPv6 addresses in TACACS+ protocols. ACS 5.7 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.7 uses TACACS+ to communicate with management applications. For a management application to communicate 
with ACS, you must configure the management application in ACS 5.7 as a AAA client that uses TACACS+.
You must also 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.
Except for the packet-headers, all information that the client and TACACS+ server communicate, which is contained in 
the packet-bodies are encrypted through the use of a shared secret (which is, itself, not sent over the network directly).
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, page 6
ACS 5.7 as the AAA Server, page 6
RADIUS Attribute Support in ACS 5.7, page 7
RADIUS Access Requests, page 9
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.
Table 40 TACACS+ and RADIUS Protocol Comparison 
Point of Comparison TACACS+ RADIUS
Transmission ProtocolTCP—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 Used49 Authentication and Authorization: 1645 and 1812
Accounting: 1646 and 1813.
EncryptionFull packet-body encryption. Encrypts only passwords up to 16 bytes.
AAA ArchitectureSeparate control of each service: 
authentication, authorization, and accounting.Authentication and authorization combined as 
one service.
Intended PurposeDevice management. User access control. 
						

							6
AAA Protocols
 
Overview of RADIUS
To support the older and newer RFCs, ACS 5.7 accepts authentication requests on port 1645 and port 1812. For 
accounting, ACS accepts accounting packets on ports 1646 and 1813.
RADIUS IETF
ACS 5.7 provides a set of standard IETF RADIUS attributes with a set of predefined sub-attributes and values. You can 
not edit these RADIUS IETF attributes. You can use them in policy conditions. You can identify RADIUS IETF attributes 
that are currently unused by their names. These unused attributes are named in the following format: attribute-nnn, 
where attribute is the name of the attribute and nnn is the ID of the attribute. 
In ACS 5.7, you have two new sub-attributes for the RADIUS IETF attribute “Service Type” and they are: 
HP-Oper and its ID is 252
HP-User and its ID is 255
You can use these two sub-attributes in policy conditions. These two sub-attributes are specifically designed for the HP 
devices to understand permissions of the user. 
RADIUS VSAs
ACS 5.7 supports RADIUS VSAs. The following set of predefined RADIUS VSAs are available after you install ACS 5.7:
Cisco
Cisco VPN 5000
Microsoft
US Robotics
Ascend
Nortel (Bay Networks)
RedCreek
Juniper
Cisco VPN 3000
Cisco Business Service Management (BSM) 
Cisco Aironet
Cisco Airespace
You can modify these predefined RADIUS VSAs or define new RADIUS VSAs. You can create, edit, and duplicate RADIUS 
VSAs. For more information, see Creating, Duplicating, and Editing RADIUS Vendor-Specific Attributes, page 7.
ACS 5.7 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.7 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.  
						

							7   
AAA Protocols
Overview of RADIUS
RA D I U S  i s  u n i ver sa l l y  u se d  t o  s ec u re  t he  a c c ess  o f  e n d - u s er s t o  n e t wo r k  re s ou rc es.  A R A D I U S se r ve r  c a n  ac t  as  a p rox y  
to other RADIUS servers or other kinds of authentication servers.
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 either the internal identity store, or an externally configured 
LDAP or Windows Active Directory identity store. 
ACS ultimately responds to the NAD with either an Access-Reject message or an Access-Accept message that contains 
a set of authorization attributes.
ACS 5.7 provides network transport over 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.7 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:
Receives the result of the data processing.
a.Creates a corresponding response to the client.
b.Returns the response to the network.
RADIUS Attribute Support in ACS 5.7
ACS 5.7 supports the RADIUS protocol as RFC 2865 describes. 
ACS 5.7 supports the following types of RADIUS attributes:
IETF RADIUS attributes  
						

							8
AAA Protocols
 
Overview of RADIUS
Generic and Cisco VSAs 
Other vendors’ attributes
ACS 5.7 also supports attributes defined in the following extensions to RADIUS:
Accounting-related attributes, as defined in RFC 2866.
Support for Tunnel Protocol, as defined in RFCs 2867 and 2868.
Support for EAP (via the EAP-Message attribute), as defined in RFCs 2869 and 3579.
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.
All transactions between the client and RADIUS server have their message integrity protected using the 
Request/Response Authenticator field inside each RADIUS packet, which makes use of a shared secret (that is, itself, not 
sent over the network directly). 
In addition, some forms of RADIUS packets that include all of those that contain encapsulated EAP-Message attributes 
have the integrity of all of their RADIUS attributes additionally protected using a Message-Authenticator RADIUS attribute 
(that also makes use of the shared secret). 
Furthermore, user passwords within the RADIUS packets sent between the client and RADIUS server are always 
encrypted to protect against the possibility that an unauthorized user on an insecure network could easily determine the 
password.
Authentication
ACS supports various authentication protocols transported over RADIUS. The supported protocols that do not include 
EAP are:
PA P
CHAP
MSCHAPv1
MSCHAPv2 
						

							9   
AAA Protocols
Overview of RADIUS
In addition, various EAP-based protocols can be transported over RADIUS, encapsulated within the RADIUS 
EAP-Message attribute. These can be further categorized with respect to whether or not, and to what extent, they make 
use of certificates. These include:
EAP methods that do not use certificates:
—EAP-MD5
—LEAP
EAP methods in which the client uses the ACS server certificate to perform server authentication:
—PEAP/EAP-MSCHAPv2
—PEAP/EAP-GTC
—EAP-FAST/EAP-MSCHAPv2
—EAP-FAST/EAP-GTC
EAP methods that use certificates for both server and client authentication:
—EAP-TLS
—PEAP/EAP-TLS
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 ISP might use RADIUS access control and accounting software to meet special security and billing needs. 
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) 
						

							10
AAA Protocols
 
Overview of RADIUS
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. 
						

							1
Cisco Systems, Inc.www.cisco.com
 
Authentication in ACS 5.7
Authentication verifies user information to confirm the user's identity. Traditional authentication uses a name and a fixed 
password. More secure methods use cryptographic techniques, such as those used inside the Challenge Authentication 
Handshake Protocol (CHAP), OTP, and advanced EAP-based protocols. ACS supports a variety of these authentication 
methods. 
A fundamental implicit relationship exists between authentication and authorization. The more authorization privileges 
granted to a user, the stronger the authentication should be. ACS supports this relationship by providing various methods 
of authentication. 
Authentication Considerations
Username and password is the most popular, simplest, and least-expensive method of authentication. The disadvantage 
is that this information can be told to someone else, guessed, or captured. Simple unencrypted username and password 
is not considered a strong authentication mechanism but can be sufficient for low authorization or privilege levels such 
as Internet access. 
You should use encryption to reduce the risk of password capture on the network. Client and server access-control 
protocols such as TACACS+ and RADIUS encrypt passwords to prevent them from being captured within a network. 
However, TACACS+ and RADIUS operate only between the AAA client and ACS. Before this point in the authentication 
process, unauthorized persons can obtain clear-text passwords; for example, in the following setups:
The communication between an end-user client dialing up over a phone line 
An Integrated Services Digital Network (ISDN) line terminating at a network-access server 
Over a TELNET session between an end-user client and the hosting device 
Authentication and User Databases
ACS supports a variety of user databases. It supports the ACS internal database and several external user databases, 
including:
Windows Active Directory
LDAP 
RSA SecurID Servers
RADIUS Identity Servers
This appendix describes the following:
RADIUS-based authentication that does not include EAP:
—PA P,  pag e 2
—CHAP, page 28
—MSCHAPv1 
						

							2
Authentication in ACS 5.7
 
PA P
—EAP-MSCHAPv2, page 27
EAP family of protocols transported over RADIUS, which can be further classified as:
—Simple EAP protocols that do not use certificates:
EAP-MD5—For more information, see EAP-MD5, page 4.
LEAP—For more information, see LEAP, page 29.
—EAP protocols that involve a TLS-handshake and in which the client uses the ACS server certificate to perform 
server authentication:
PEAP, using one of the following inner methods: PEAP/EAP-MSCHAPv2 and PEAP/EAP-GTC—For more information, 
see PEAPv0/1, page 13.
EAP-FAST, using one of the following inner methods: EAP-FAST/EAP-MSCHAPv2 and EAP-FAST/EAP-GTC—For 
more information, see EAP-FAST, page 17.
—EAP protocols that are fully certificate-based, in which the TLS handshake uses certificates for both server and 
client authentication:
EAP-TLS—For more information, see EAP-TLS, page 5.
PEAP with inner method EAP-TLS, see PEAPv0/1, page 13.
Certificate Attributes, page 29
Machine Authentication, page 31
Authentication Protocol and Identity Store Compatibility, page 32
For a list of known supplicant issues, see Release Notes for Cisco Secure Access Control System 5.7.
PAP
The Password Authentication Protocol (PAP) provides a simple method for a user to establish its identity by using a 
two-way handshake. The PAP password is encrypted with the shared secret and is the least sophisticated authentication 
protocol.
ACS checks the ID-Password pair against the external database, Identity Store, until ACS acknowledges the 
authentication or terminates the connection.
PAP is not a strong authentication method since it offers little protection from repeated trial-and-error attacks. 
Note: The RADIUS with PAP authentication flow includes logging of passed and failed attempts.
RADIUS PAP Authentication 
You can use different levels of security concurrently with ACS for different requirements. PAP applies a two-way 
handshaking procedure. If authentication succeeds, ACS returns an acknowledgment; otherwise, ACS terminates the 
connection or gives the originator another chance.
The originator is in total control of the frequency and timing of the attempts. Therefore, any server that can use a stronger 
authentication method will offer to negotiate that method prior to PAP. RFC 1334 defines PAP. 
Figure 6 on page 3 illustrates RADIUS with PAP authentication. 
						

							3   
Authentication in ACS 5.7
EAP
Figure 6 RADIUS with PAP Authentication Use Case
EAP 
Extensible Authentication Protocol (EAP) is an authentication framework for wireless networks and point-to-point 
connections. EAP supports multiple authentication methods, and provides common functions and rules for negotiation 
of the desired authentication method: 
Server authentication request
Client authentication response
Server success authentication result
Server failure authentication result
Silent discard of client packets if they do not meet integrity and security conditions
Rules for server-initiated EAP method negotiation
Message sequencing, and tracking responses to requests
Retransmit
EAP is a lock-step protocol; after the initial request, ACS cannot send a new request before receiving a valid response 
from the client.
In ACS 5.7, EAP is encapsulated in the RADIUS protocol. Incoming and outgoing EAP messages are stored in a RADIUS 
EAP-Message attribute (79). A single RADIUS packet can contain multiple EAP-Message attributes when the size of a 
particular EAP message is greater than the maximum RADIUS attribute data size (253 bytes). 
The RADIUS State attribute (24) stores the current EAP session reference information, and ACS stores the actual EAP 
session data.
The EAP standard is described in:
RFC 3748—Extensible Authentication Protocol (EAP).
RFC 3579—RADIUS Support For Extensible Authentication Protocol (EAP).
In the EAP process:
1.The network device sends an EAP Request to a host when the host connects to the network. 1A host connects to the network. Any communication 
protocol may be used depending on the host.3ACS uses an external identity store to validate the 
user's credentials.
2The network device sends a RADIUS access request 
to ACS. 4The RADIUS response (Access-Accept or 
Access-Reject) is sent to the network device that will 
apply the decision.
Host
Network Device
2
4
1
External
Identity Store3
210732
ACS Server 
						

							4
Authentication in ACS 5.7
 
EAP-MD5
2.The host sends an EAP Response to the network device; the network device embeds the EAP packet that it received 
from the host into a RADIUS request and sends it to ACS, which is acting as the EAP server.
3.ACS negotiates the EAP method for authentication. The client can acknowledge the EAP method that the EAP server 
suggests or, it can respond with a negative acknowledgment (NAK) and suggest a list of alternative EAP methods. 
The server and client must reach agreement about the EAP method to use to instantiate authentication.
Table 41 on page 4 lists the EAP codes for each type of EAP message.
Table 42 on page 4 describes the EAP methods that ACS 5.7 supports.
ACS supports full EAP infrastructure, including EAP type negotiation, message sequencing and message retransmission. 
All protocols support fragmentation of big messages.
In ACS 5.7, you configure EAP methods for authentication as part of access service configuration. For more information 
about access services, see ACS 5.x Policy Model, page 1
EAP-MD5
This section contains the following topics:
Overview of EAP-MD5, page 5
EAP- MD5 Flow in ACS 5.7, page 5
Table 41 EAP Codes
EAP message type EAP code
Accept-request 1
Response 2
Success 3
Failure 4
Table 42 Supported EAP methods
EAP Method Description
EAP-MD5 Message Digest 5 Protocol. For more information see EAP-MD5, page 4.
LEAP Lightweight Extensible Authentication Protocol.
PEAPv0v1 Protected Extensible Authentication Protocol version 0 and version 1. For 
more information see PEAPv0/1, page 13.
EAP-FAST EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol. For 
more information see EAP-FAST, page 17.
EAP-MSCHAPv2 Microsoft Challenge Handshake Authentication Protocol version 2. For more 
information see EAP-MSCHAPv2, page 27.
EAP-GTC EAP Generic Token Card.
EAP-TLS Extensible Authentication Protocol-Transport Layer Security. For more 
information, see Exporting Credentials, page 10.