TACACS+ vs RADIUS – AAA

As identity security and access management become more complex, networks and network resources require safeguarding from unauthorized access. Authentication, Authorization, and Accounting, referred to as AAA (Triple-A), provide the framework that controls and monitors network access. We refer to the IINS exam in this post however, this exam has now retired. Please consider CompTIA Security+ or Cisco CyberOps Associate.

Please read our Securing Network Devices guide for more information.

This chapter is broken up into the following sections:

AAA Overview 

Authentication is used to validate identity, i.e. who the user is. Authorization is used to determine what that particular user can do, i.e. the services available to the user. And Accounting is used to allow for an audit trail, i.e. what that user did.

AAA provides a flexible, modular solution for controlling access to the network. It provides the primary framework through which access control is set up on a network device, such as a router, switch, or firewall. In such devices, AAA services can be used to control administrative access, such as via Telnet and Console login, which is referred to as character mode access. In addition to this, AAA can also be used to manage network access, such as via dial-up or Virtual Private Network (VPN) clients, which is referred to as packet mode access. The primary advantages of using AAA are as follows:

• Standard authentication methods
• Scalability
• Greater flexibility and control
• Multiple backup systems

AAA uses standard authentication methods, which include Remote Authentication Dial-In User Service (RADIUS), Terminal Access Controller Access Control System Plus (TACACS+), and Kerberos. These authentication methods will be described in detail later in this chapter.

AAA scales to networks of all sizes. Multiple security servers can be implemented allowing access control to be added easily. This allows AAA to scale from small networks with very few devices to very large networks that may contain hundreds of devices.

In addition to scalability, AAA provides great flexibility and control. For example, in small networks, AAA services can be administered by using local databases that are stored on the network devices instead of using a security server. Username and password credentials can be stored on the local database of the device and referenced by the AAA services. AAA services can also be configured for per-user, per-group, or per-service control.

AAA allows devices to point to multiple security servers, often referred to as server groups. User, device, and services information can be replicated between multiple servers, which provide redundancy in large networks.

The AAA Model

The AAA framework uses a set of three independent security functions in a modular format to offer secure access control. The AAA model is used to control access to network devices (Authentication), enforce policies (Authorization), and audit usage (Accounting). AAA uses RADIUS, TACACS+, and Kerberos as authentication protocols to administer the AAA security functions. Using the AAA engine, network devices establish communications with the security server(s) using these protocols. The three independent security functions that offer secure access control and are provided by AAA are as follows:

• Authentication
• Authorization
• Accounting

Authentication

Authentication is used to validate user identity before allowing access to network resources. It occurs when a client passes the appropriate credentials to a security server for validation. This validation is based on verifying user credentials, which can be any of the following:

• Something the user knows – which is referred to as Authentication by knowledge. This method verifies identity by something known only to the user, such as a username and password, for example.

• Something the user possesses – which is referred to as Authentication by possession. This method verifies identity by something possessed only by the user. Examples of this type of authentication include ATM cards or tokens (such as RSA Secure ID tokens).

• Something the user is – which is referred to as user characteristics or biometrics. This is the strongest authentication method because it avoids the problems that are associated with other authentication methods, for example, the password being cracked or the ATM card being stolen. Examples of biometrics include finger prints, face recognition, and DNA.

Once the security server has received the credentials, it will respond with a pass (accept) or fail (deny) message. Authentication also offers additional services, such as challenge and response, messaging support, and even encryption, depending on the security protocol implemented.

Authorization

Authorization provides the capability to enforce policies for network resources after the user has been successfully authenticated. In other words, Authorization is used to determine the actions a user, group, system, or server is allowed to perform. Attribute-value (AV) pairs – which are described in the next section – that define user rights are associated with the user to determine the specific rights of the user.

Clients query the AAA server to determine what actions a user is authorized to perform, and the server provides AV pairs that define user authorization. The client is then responsible for enforcing user access control based on those AV pairs.

Accounting

Accounting provides the means to capture resource utilization by collecting and sending information that can be used for billing, auditing, and reporting to the security server. This information can include user identities (who logged in), session start and stop times, the command(s) executed, and traffic information such as bytes or packets transmitted.

Accounting records are also made up of accounting AV pairs. Accounting methods must be defined through AAA. The client then sends the Accounting records, with the relevant AV pairs, to the AAA server for storage.

Now that we are familiar with the three independent security functions within the AAA framework, it is important to understand what their correlation is, as follows:

1. Authentication is valid without Authorization. This means that you can enable and authenticate users without enabling and authorizing those same users.

2. Authentication is valid without Accounting. This means that you can enable and authenticate users without enabling accounting for the actions performed by those users.

3. Authorization is not valid without Authentication. This means that you must authenticate users before you can authorize them. You cannot authorize anyone who has not been authenticated.

4. Accounting is not valid without Authentication. This means that you must authenticate users before you enable accounting for them. You do not need to enable authorization because authentication is valid without authorization.

AAA Operation

In order for AAA to work, the Network Access Server (NAS), which is any device – such as a router, switch, or firewall – must be able to access security information for a specific user before providing AAA services. This information may be stored locally, i.e. on the NAS itself, or remotely, i.e. on a RADUIS, TACACS+, or Kerberos server.

Although both methods are valid, it is important to keep in mind that the local user database supports only a limited number of Cisco-specific security attribute-values, but server-based AAA provides more capabilities and security information is stored on the server, not the network device. An AV pair is simply a secured network object. It is comprised of an attribute, such as the username or password, and a value for that particular attribute.

To reinforce the concept of AV pairs, the following network diagram illustrates their use in AAA services when the security information is stored locally on the NAS:

 

Based on the diagram illustrated above, in step 1, the remote user attempts to connect to R1 (NAS) via Telnet. Assuming that the NAS has been configured for AAA services, using its local database for Authentication, the NAS presents the remote user with the username and password prompt, as illustrated in step 2.

The remote user then enters his or her credentials, providing the username iinsuser (which is the ATTRIBUTE) and password ccn@secur!ty (which is the VALUE for that ATTRIBUTE), as illustrated in step 3. The NAS then checks the information against its local database:

Attribute	Value
Username	iinsuser
Password	ccn@secur!ty

 

Assuming that the NAS has been configured with the username iinsuser secret ccn@secur!ty global configuration command, each AV is on file and the AV pair is found. The request is accepted and a pass message is returned (as illustrated in step 4), which enables the connection from the remote user to be made. The same logic would apply if AAA services were authenticating against a remote server, such as TACACS+ or RADIUS, for example.

Taking this example a step further, this time depicting the use of an external AAA server, the following diagram illustrates the use of AV pairs for Authorization:

In the diagram above, assume that the remote user has been successfully authenticated. Once logged in to R1 (NAS), the remote user attempts to issue the configure terminal command, as illustrated in step 1. The NAS has been configured to use AAA services for Authorization, and so the request is sent to the TACACS+ server, as illustrated in step 2. The TACACS+ server then checks the following information against its local database:

Attribute	Value
command	configure terminal

 

In step 3, the server finds that the attribute and value are on file, and an AV pair is found. The request is accepted and the configure terminal command is successfully authorized on R1, as illustrated in step 4. The remote user successfully enters configuration mode. Again, the same concept would be applicable if Authorization was being performed using the local database.

Unlike Authentication and Authorization, there is no search for AV pairs in any kind of database for Accounting. Instead, information is simply received with AV pairs and is stored in the database. Accounting is illustrated in the following diagram:

Based on the diagram above, in step 1, the remote user dials in to the NAS for access to the network resources and services. We will assume that R1 belongs to an ISP providing its customers with Internet service via dial-up modems.

We will also assume that the remote user has authenticated successfully and is authorized to use this service. The NAS has been configured for Accounting so that the ISP can bill customers based on usage, etc. Based on this, in step 2, the NAS sends the following Accounting AV pair information to the AAA server:

Attribute	Value
start time	02:30:00
stop time	04:30:00
elapsed time	02:00:00
packets sent	1234567
packets received	9876543

 

The AAA server simply receives this information and performs no AV pair searches. Instead, the information is stored in the local database, as illustrated in step 3, where it can later be retrieved and the remote user billed for the amount of time spent on the ISP network.

Now that we have an understanding of AAA and how it works, we are going to move along and learn about the two main security server protocols: RADIUS and TACACS+.

RADIUS

RADIUS stands for Remote Authentication Dial-In User Service. RADIUS is a client/server protocol that is used to secure networks against intruders. RADIUS was created by Livingston Enterprises but is now defined in RFC 2138 and RFC 2139. The RADIUS protocol Authentication and Accounting services are documented separately in RFC 2865 and RFC 2866, respectively. These two RFCs replace RFC 2138 and RFC 2139.

A RADIUS server is a device that has the RADIUS daemon or application installed. Unlike TACACS+, which is described in detail in the following section, RADIUS is an open-standard protocol that is distributed in C source code format. This allows for interoperability and flexibility between RADIUS-based products from different vendors; however, as will be explained later in this chapter, this is also one of the main problems with using RADIUS.

Before delving into the specifics pertaining to RADIUS, it is important to have a solid understanding of the RADIUS packet format and the fields contained therein. The following diagram illustrates the header format of the RADIUS packet:

The information contained in each field is as follows:

• Code

This 1-byte field contains the message type of the RADIUS packet. Valid codes are:

1. Code 1 = Access-Request
2. Code 2 = Access-Accept
3. Code 3 = Access-Reject
4. Code 4 = Accounting-Request
5. Code 5 = Accounting-Response
6. Code 11 = Access-Challenge

• Identifier

This 1-byte field matches request and reply packets. The identifier is a message sequence number that allows the RADIUS client to match a RADIUS response with the correct outstanding request, i.e. the value in reply is equal to the value in request.

• Length

This 2-byte field includes the message length and the header.

• Authenticator

This 16-byte field is used to authenticate the reply from the RADIUS server. The value in the request packet is randomly generated, whereas the value in the reply packet is an MD5 hash of the reply message data appended with a shared secret using a vector from the request packet.

• Attributes

RADIUS attributes carry the specific Authentication, Authorization, and Accounting details for the request and response. Some attributes may be included more than once. These attributes are stored in Type/Length/Value (or TLV) notation. The Type specifies the attribute type and is 8-bits in length. The Length is 8-bits long and is used to indicate the length of the attribute. And, finally, the Value is a variable-length field that contains the information specific to the attribute.

RADIUS Authentication and Authorization

RADIUS uses UDP as the Transport layer protocol for communications between the client and the server, using UDP port 1812 for Authentication and Authorization and UDP port 1813 for Accounting. However, it should be noted that earlier deployments of RADIUS use UDP port 1645 for Authentication and Authorization and UDP port 1646 for Accounting. Because RADIUS uses UDP as a transport protocol, there is no offer of guaranteed delivery of RADIUS packets. Therefore, any issues related to server availability, the retransmission of packets, and timeouts, for example, are handled by the RADIUS-enabled devices.

RADIUS communication is triggered by a user login that consists of a query. The following diagram illustrates the sequence of messages that are exchanged:

Following the diagram illustrated above, in step 1, the remote user dials in to the NAS. The NAS proceeds and asks the remote user for a username and password, as illustrated in step 2.The user then proceeds and inputs his or her assigned, valid credentials, which are the username iinsuser and the password s3cur!ty. This process is illustrated in step 3.

This received username and encrypted password, as well as the NAS IP address and NAS port information, is sent as an Access-Request packet from the NAS to the RADIUS server, as illustrated in step 4. The Access-Request packet will also contain other information on the type of session that the user wants to initiate. For example, if the query is presented in character mode (e.g. Telnet), the packet will include Service-Type=Shell; however, if the packet is presented in PPP mode, for example, it will include Service-Type=Framed-User, as well as Framed-Type=PPP.

When the RADIUS server receives the Access-Request packet from the NAS, the first thing it will check for is the shared secret key for the client that is sending the request. This step is performed to ensure that only authorized clients are able to communicate with the server. In the event that the shared secret key is not configured or is incorrect, the server will silently discard the request packet without sending back a response.

However, if the username is found in the database and the password is validated, the server returns an Access-Accept response back to the client, as illustrated in step 5. The Access-Accept carries a list of AV pairs that describe the parameters to be used for this session. In addition to the standard set of attributes, RADIUS also specifies the vendor-specific attribute (Attribute 26) that allows vendors to support their own extended attributes, which may be specifically tailored to their particular application and are not for general use.

Although the diagram used in the example depicts the Access-Accept packet being sent from the RADIUS server to the NAS in step 5, it is important to know that this is simply one of many possible responses that the server may provide.  In this step, the RADIUS server may also send one of the following messages:

1. Access-Reject

The Access-Reject response is returned to the client when the username is not found in the database or if the password entered is incorrect. This packet may also be sent when Authorization fails.

2. Access-Challenge

The Access-Challenge response is typically issued when the RADIUS server wants more information from the user. Depending on the information requested, the client then sends that in another Access-Request packet. When the server receives the additional requested information, it responds back to the client with either an Access-Accept or Access-Reject.

3. Change-Password

The Change-Password response is sent from the RADIUS server to the client when asking the user to select a new password. This may be because the password has expired or this is a new account with a default password and the user must create a new password.

Although RADIUS is a security protocol, its own operation is not entirely secure. When the Access-Request packet is sent from the NAS to the RADIUS server, only the password is encrypted by a shared secret but the remainder of the packet is sent in clear text, making it vulnerable to various exploits and attacks, such as MITM attacks. It is important to take this into consideration when deploying and using RADIUS for AAA services in production networks. 

RADIUS Accounting

The RADIUS Accounting function is designed for data to be transmitted at the beginning and at the end of a session. This data can indicate resource utilization, such as bandwidth and time used, and may be used for billing and/or security purposes.

There are two types of messages that are exchanged during RADUIS Accounting sessions: Accounting-Request and Accounting-Response messages. The following diagram illustrates the exchange of messages between the NAS (AAA client) and the RADIUS server:

As illustrated in the network diagram above, after the user has been Authenticated and Authorized (which is considered a single process in RADIUS), the NAS sends an Accounting Start packet, which is simply a RADIUS Accounting-Request packet that contains the attribute acct-status-type and the value start. This AV pair is used to signal the start of the user’s network access and typically contains the user’s identification, network address, point of attachment, and a unique session identifier. This is illustrated in step 1.

When the RADIUS server receives this packet, it responds with an Accounting-Response packet, which is used as an acknowledgement that the Accounting information was received. This process is illustrated in step 2.

As the user session progresses, the NAS periodically sends interim update records. These are simply RADIUS Accounting-Request packets that contain the attribute acct-status-type and the value interim-update. This AV pair is used to communicate the current duration of the session and other information (e.g. bandwidth, bytes used, etc.) that pertain to data usage by the user for this session. This is illustrated in step 3. The RADIUS server acknowledges this packet again by sending the Accounting-Response packet, as illustrated in step 4.

When the user’s network access is closed, the NAS issues an Accounting Stop record to the RADIUS server. This packet is simply an Accounting-Request packet with the attribute acct-status-type and the value stop. This packet is used to provide information on the final usage of network resources and may include time, packets transferred, data transferred, disconnect reason, and any other information related to the user’s activities during the session. This is illustrated in step 5. When the RADIUS server receives this packet, it acknowledges it by sending an Accounting-Response packet, as illustrated in step 6.

Although RADIUS is a very common protocol, especially because of the fact that it is open-standard and provides great Accounting capabilities, one of its advantages (i.e. the fact that it is distributed in C source code format, which allows for interoperability and flexibility between RADIUS-based products from different vendors) has become a disadvantage as individual organizations extend RADIUS to meet their specific needs. This has resulted in RADIUS compatibility issues amongst different vendors; for example, the RADIUS implementation by Vendor X may be incompatible with that of Vendor Y, due to proprietary enhancements, etc.

To address this issue, a new open-standard security protocol, called DIAMETER, has been proposed to replace RADIUS. While DIAMETER will work in the same basic manner as RADIUS (i.e. as a client/server security protocol), it also aims to improve on some of the weaknesses of RADIUS by offering greater AAA capabilities and using the connection-oriented TCP as the Transport Layer protocol, instead of UDP.

In addition, DIAMETER also provides an improved method of encrypting message exchanges that offer more security than that provided by RADIUS. Going into detail and the specifics of DIAMETER is beyond the scope of the IINS course requirements; however, as a future security administrator, ensure that you are aware of this upcoming protocol. It may very well be something you are called on to consider, speak on, or even deploy, at some point in your career.

RADIUS Attributes

RADIUS supports numerous attributes that can be exchanged between client and server. These attributes carry specific information about Authentication and are defined in RFC 2138. Although going into detail and knowing every one of these attributes is beyond the scope of the IINS course requirements, the following table contains a list of some of the more common RADIUS attributes:

Attribute	Description/Purpose
Type 1	Username – used to define usernames, e.g. ASCII characters or SMTP addresses
Type 2	Password – used to define the password, which is encrypted using MD5
Type 3	CHAP Password – used only in Access-Request packets
Type 4	NAS IP Address – defines the NAS IP address; used in Access-Request packets
Type 5	NAS Port – used to indicate the physical port of the NAS (ranging from 0 to 65,535)
Type 6	Service-Type – used to indicate the Type of Service; not supported by Cisco
Type 7	Protocol – used to define the required framing, e.g. PPP
Type 8	IP Address – used to define the IP address to be used by the remote user
Type 9	IP Subnet Mask – used to define the subnet mask to be used by the remote user
Type 10	Routing – used to define routing options
Type 13	Compression – used to define data compression
Type 19	Callback ID – used to specify the number or address for callback
Type 26	Vendor-specific – used to define the vendor-specific attribute
Type 61	NAS Port Type – used to specify the type of port on the NAS

 

NOTE: Attribute 26 is particularly important to remember, as it is of particular importance in the Cisco security world. Cisco, vendor ID 9, uses a single defined option, which is vendor type 1 named the Cisco-AV Pair. This attribute is used to transmit TACACS+ AV pairs. TACACS+ is a Cisco-proprietary security protocol, which is described in the next section.

TACACS+

TACACS+ stands for Terminal Access Controller Access Control System Plus. Unlike RADIUS, which is an open-standard protocol, TACACS+ is a Cisco-proprietary protocol that is used in the AAA framework to provide centralized authentication of users who are attempting to gain access to network resources.

There are several notable differences between TACACS+ and RADIUS. One of the most notable differences is that TACACS+ uses TCP as a Transport Layer protocol, using TCP port 49. In addition to this, TACACS+ separates the three AAA architectures, unlike RADIUS, which groups Authentication and Authorization together and separates Accounting. TACACS+ also encrypts the data between the user and the server, unlike RADUIS, which encrypts only the password. Finally, TACACS+ supports multiple protocols, such as IP, IPX, AppleTalk, and X.25, whereas RADIUS has limited protocol support. The TACACS+ packet header is illustrated in the following diagram:

The information contained in each field is as follows:

• Major

This 4-bit field indicates the major TACACS+ version number. This value appears in the header as TAC_PLUS_MAJOR_VER=0xc.

• Minor

This 4-bit field indicates the minor TACACS+ version number, which is the revision number. This value allows for revisions to the TACACS+ protocol while maintaining backward compatibility. Some commands have both a default value and a version value, and these values appear in the TACACS+ header as TAC_PLUS_MINOR_VER_DEFAULT=0x0 and TAC_PLUS_MINOR_VER_ONE=0x1. If a TACACS+ server receives a TACACS+ packet other than the two just listed, it sends an error status back and sets the Minor Version field to the closest version that is supported.

• Packet Type

This 1-byte field defines whether the packet is used for Authentication, Authorization, or Accounting. The possible values that this field may contain are as follows:

1. TAC_PLUS_AUTHEN=0x01 (Authentication)
2. TAC_PLUS_AUTHOR=0x02 (Authorization)
3. TAC_PLUS_ACCT=0x03 (Accounting)

• Sequence Number

This 1-byte field contains the sequence number for the current session. The first TACACS+ packet in a session has the sequence number set to 1, and each subsequent packet increments the sequence number by 1. Thus, clients send only packets that contain ODD numbers (e.g. 1, 3, 5, and 7) because they send the first packet, and TACACS+ servers send only EVEN numbers (e.g. 2, 4, 6, and 8) in response to the packets from the client. The highest sequence number that can be reached during a session is 2⁸-1. If this limit is reached, the current session between the client and the TACACS+ server is reset and a new session is established.

• Flags

This 1-byte field contains various flags in the form of bitmaps, which can be the TAC_PLUS_UNENCRYPTED_FLAG and the TAC_PLUS_SINGLE_CONNECT_FLAG. The TAC_PLUS_UNENCRYPTED_FLAG is the TACACS+ packet that is being encrypted. If this flag is set to a value of 1, it means that no encryption is being performed; however, if the flag is set to 0, then the packet is being encrypted. Keep in mind that only the packet payload is encrypted; the packet header is always sent in clear text. The TAC_PLUS_SINGLE_CONNECT_FLAG flag determines whether multiplexing (joining) multiple TACACS+ sessions over one TCP session is supported, which is determined in the first two TACACS+ messages of a session, and once determined, this will not change during the course of the session.

It is important to understand that the encryption of the TACACS+ packet is not the same as that of traditional user data. Instead, it relies on a combination of a hashing function and an XOR or EOR algorithm, which is an algorithm that basically means either one or the other, but not both.  This process is performed as follows:

1. Information is taken from the packet header and the pre-shared key calculates a series of hashes. The first is a hash that is calculated on a concatenation of the Session ID, the version, the Sequence Number, and the pre-shared key value. Each hash that is created also includes the previous hash, and this is performed on a number of times, depending on the particular implementation of TACACS+.

2. The calculated data is linked together and then shortened to the length of the data that is being encrypted. Each hash has the previous hash linked into its input values, and the end result is referred to as the pseudo pad.

3. The cipher text is produced by doing a byte-wise XOR or EOR algorithm on the pseudo pad with the data that is being encrypted.

4. The receiving device uses its pre-shared key to calculate the pseudo pad, and then an XOR algorithm of the newly created pseudo pad results in the original data in clear text, i.e. unencrypted text.

• Session ID

This 4-byte field contains the ID for the TACACS+ session.  This random value remains the same during the course of the session.

• Length

This 4-byte field contains the total length of the TACACS+ packet, excluding the header.

TACACS+ Authentication

TACACS+ Authentication is typically initiated when a user attempts an ASCII login by authenticating to a server running the TACACS+ daemon. The TACACS+ Authentication phase uses three distinct packet types, as follows:

1. START packets – which are used initially when the user attempts to connect.
2. REPLY or RESPONSE packets – which are sent by the AAA server during Authentication.
3. CONTINUE packets – which are used by AAA clients to return username and password information to the TACACS+ server.

The TACACS+ Authentication communication process is illustrated in the following diagram:

In the network diagram illustrated above, in step 1, the remote user initiates a connection to the NAS, which is configured for AAA services using TACACS+.

The NAS then contacts the TACACS+ server (START) to get a username prompt, as illustrated in step 2. The TACACS+ server responds (REPLY) with username prompt, illustrated in step 3, and this is then displayed to the user, in step 4.

The user types in his or her username, also illustrated in step 4, and the NAS sends this information (CONTINUE packet) to the TACACS+ server, as illustrated in step 5.

The TACACS+ server receives the username and checks its local or external database for the username. The name is found and the TACACS+ server sends a request for a password (REPLY), as illustrated in step 6. The NAS relays this information to the remote user, who inputs the password, as illustrated in step 7.

The NAS relays the password (CONTINUE) to the TACACS+ sever, in step 8, and the TACACS+ server checks its local or external database for the correct password. Depending on the result, the TACACS+ server responds, as illustrated in step 9, with the result (REPLY), which could be any one of the following messages:

1. ACCEPT

This response indicates that the user has been successfully authenticated and service may begin.  If the NAS is required to perform Authorization, that begins at this time as well.

2. REJECT

This response states that Authentication has failed. This could be due to incorrect credentials and could result in the user being denied further access at that point.

3. ERROR

This response is usually received when a communication problem exists between the NAS and the AAA server. The error can be on either the client-side or the server-side. Some of the reasons that could cause this response to be received include an incorrect secret key, an incorrect NAS IP address, or even a latency (delay) issue in the network. When the NAS receives this message from the server, it typically attempts to use an alternate method to continue the Authentication process.

4. CONTINUE

This response states that the server is expecting additional information and, as such, the user is prompted for further input variables.

TACACS+ Authorization

The TACACS+ Authorization process is performed using two distinct message types: REQUEST and RESPONSE. The Authorization process is performed using a session that consists of this pair of messages.

REQUEST messages are sent by clients and they contain information pertaining to the authenticity of the user or service (Authentication information), as well as a list of the services or options for which Authorization is being requested.

When the TACACS+ server receives the REQUEST message, it replies with a RESPONSE message. This message contains one of the following replies:

1. FAIL

This message indicates that the services or options requested for Authorization are denied.

2. PASS_ADD

This message indicates that request is authorized and the information returned in the RESPONSE packet is used in addition to the requested information. If no additional arguments are returned in the RESPONSE, the request is authorized.

3. PASS_REPL

This message is sent by the AAA server when it ignores the request and, instead, replaces it with the information placed in the RESPONSE packet.

4. FOLLOW

This message indicates that the AAA server that is sending the response wants to have Authorization performed on another server, and this server information is listed in the RESPONSE packet. The NAS can either follow this response or view it as a FAIL.

5. ERROR

This message is used to indicate an error on the AAA server, such as a pre-shared key mismatch, for example.

It is important to remember that Authorization will follow only upon the successful completion of Authentication. You cannot have Authorization before Authentication. In Authentication and Authorization, attribute-value (AV) pairs are used to enforce various services and functions, as well as to determine the user access for network resources. Some of the more common AV pairs used by TACACS+ are provided later in this chapter. The following diagram provides a basic illustration of TACACS+ Authorization communication:

In the diagram illustrated above, the remote user (who has been successfully authenticated), issues the show run command on the NAS (R1), as illustrated in step 1.

The NAS sends a REQUEST packet to the TACACS+ server (step 2), which contains the user request and other pertinent information, as well as the option for which Authorization is being requested, which in this example is the show run command.

The TACACS+ server receives this REQUEST and replies back with a RESPONSE message, illustrated in step 3. For the sake of simplicity, the RESPONSE is a pass and the command is successfully executed, and the running configuration is provided by the router. 

TACACS+ Accounting

TACACS+ Accounting is similar to Authorization in that it uses the same two messages that Authorization uses, i.e. REQUEST and RESPONSE. However, the information contained in the Accounting RESPONSE message may either be a SUCCESS message, which indicates that the server received the Accounting record from the AAA client; an ERROR message, which indicates that the AAA server was unable to commit the Accounting record to its database; or a FOLLOW message, which is similar to the FOLLOW message used in Authorization.

TACACS+ Accounting takes place by sending a record to the AAA server. Each record includes an AV pair for Accounting and one of three types of record may be sent:

1. START

The START record indicates when a service begins. This record also includes information that was included in the Authorization process and other specific information pertaining to the user account.

2. STOP

The STOP record indicates when a service is about to stop or when a service is stopped.  This record also includes information that was included in the Authorization process and other specific information pertaining to the user account.

3. CONTINUE

The CONTINUE, or WATCHDOG, record is sent when a service is still in progress and allows the AAA client (NAS) to provide updated information to the AAA server. As with the previous two records, this record also includes information that was included in the Authorization process and other specific information pertaining to the user account. A CONTINUE record can also be sent with a START record. When this happens, it means that the CONTINUE record is a duplicate of the START record. 

TACACS+ Attributes

The following table provides a brief list of some of the attributes used by the TACACS+ security protocol. Please note that this is not a complete list of all attributes, as knowledge of those is beyond the requirement of the IINS course; however, this provides some common attributes that you should be familiar with:

AAA Function	Attribute	Description
Authentication	user=	Specifies the user ID
	authen_type=	Specifies the Authentication type, e.g. CHAP
	service=	Specifies the service type, e.g. PPP
	list=	Specifies the Authentication Method List
	action=	Specifies the action being performed, e.g. login
	method=	Specifies the Authentication method, e.g. TACACS+
	priv=	Specifies the user privilege level
Authorization	nas-password=	Specifies the NAS password
	protocol=	A protocol is a subset of a service; e.g.  IPCP for PPP
	ip-addresses=	IP addresses(s) for the tunnel endpoint, e.g. for PPP
	dns-servers=	Specifies the IP address(es) of the DNS server(s)
	port-type=	Specifies the physical port of the NAS
	priv-lvl=	Specifies the EXEC privilege level
Accounting	timezone=	Specifies the Time Zone, e.g. UTC/GMT, EST, etc.
	bytes_in=	The received number of bytes from the session
	bytes_out=	The sent number of bytes from the session
	paks_in=	The received number of packets from the session
	paks_out=	The sent number of packets from the session
	elapsed_time=	The duration of the session
	service=	The type of service, e.g. the router EXEC
	protocol=	The type of protocol, e.g. Telnet
	cmd=	The command(s) entered

 

Now that we have a solid understanding of the RADIUS and TACACS+ security protocols, we will move on to the next section, which addresses AAA implementation. 

Implementing AAA Services

All major Cisco devices, including router, switches, and firewalls, support AAA services. Although firewall (e.g. Cisco ASA and PIX) configuration is beyond the scope of the IINS course requirements, you are required to know how to implement AAA services on Cisco IOS devices. Following are three ways in which AAA services can be implemented:

1. AAA can be implemented as a self-contained AAA local security database containing usernames and passwords, which are typically configured via the username [name] privilege [level] secret [password] global configuration command, directly on the NAS device, such as a router, for example. This implementation is suitable for a small network with a small amount of users.

2. AAA can be implemented as a Cisco Access Control Server (ACS) application server. This can be an external server that operates well. Cisco ACS can be installed onto both Windows and Unix-based platforms. This implementation is suitable for medium to large networks.

3. Finally, AAA can be implemented using the Cisco Secure ACS Solutions Engine appliance. This is a dedicated external platform offered by Cisco that scales very well and is suitable for very large networks.

AAA services are based on method lists, which contain sequenced AAA entries and are configured to define which of the three AAA services will be performed and the sequence in which they will be performed. The method argument refers to the actual method the Authentication algorithm tries. Therefore, when a user attempts to authenticate, the NAS contacts each of the entries in sequence to validate the user.

Method lists allow control of one or more security protocols and security servers to be used to offer fault tolerance and backup of Authentication databases. The AAA engine will use the first method listed in the method list, and if that is unavailable, it will fall back to the next method list. However, it is important that this works only if the message received from the first method listed is not a FAIL message of any kind.

In other words, even though multiple methods may be listed, if a FAIL (i.e. deny) message is received from the first method tried, the Authentication process stops and no further Authentication methods are attempted in the list. In addition to this, it is also important to know that if all entries are processed without receiving a PASS message, access is denied.

In AAA implementation, there are two basic types of method lists:

1. Named Method

A named method list can be configured for any AAA service, such as Authentication or Authorization, for example. These methods are applied to specific interfaces or even terminal lines (e.g. Console and VTY) as required by the administrator.

2. Default Method

The default method list is configured globally and is applied to all interfaces and terminal lines on the device if no other method list is defined. However, if a defined (named) method list is configured, that list will take precedence over the default method list.

The following is an example of an Authentication method list configured on a Cisco IOS router:

R1(config)#aaa authentication login default group tacacs+ local none

To reinforce the concepts we have just been learning, we will dissect this command and highlight the various facets we have learned about, as illustrated in the following figure:

Based on the figure illustrated above, the aaa authentication command enables AAA Authentication services. Next, the login command tells the router to use AAA Authentication for all logins into the router. The keyword, or option, default specifies the AAA method. Because no named methods are used, the administrator is opting to use the default method list.

The group tacacs+ local none command lists the methods that will be used for Authentication of all logins. First, the AAA engine will attempt to contact the TACACS+ server group (group tacacs+), which may be a single server or a group of servers. If there is no response from the server(s), the AAA engine will attempt to use the local database (local) to authenticate all logins. If there is no entry in the local database, then the third option (none) will be attempted. This option tells the AAA engine not to attempt any other Authentication methods, meaning that the Authentication process ceases at this point. If at this point the user has not received a PASS, he or she will be denied access.

In order to configure AAA services, the following general steps should be taken:

1. Globally enable AAA services using the aaa new-model global configuration command.

2. Configure the security protocol parameters, such as the IP address and shared key of the TACACS+ and RADIUS server via the aaa group server [radius|tacacs+][group_name] global configuration command for TACACS+ or RADIUS server groups. Alternatively, you can configure individual TACACS+ or RADIUS servers by using the tacacs-server host [address|hostname] key [shared_key] or the radius-server host [address|hostname] key [shared_key] global configuration commands, respectively.

3. Define the Authentication service and the method lists by using the aaa authentication global configuration command. Keep in mind that named method lists must be configured on the AAA server; they are simply applied (as configured on the server) to the NAS.

4. Apply the Authentication named method list(s) to interfaces or terminal lines by using the login authentication interface or line configuration command.

5. Define the Authorization method list(s) using the aaa authorization global configuration command. As is the case with Authentication, named (defined) method lists must be configured on the server; they are simply applied (as configured on the server) to the NAS.

6. Apply the Authorization method list(s) to terminal lines via the authorization line configuration command. Authorization can also be enabled for WAN interfaces using protocols such as PPP by using the ppp authorization interface configuration command.

7. Define the Accounting service and method lists by using the aaa accounting global configuration command.

8. Apply the Accounting method list(s) to terminal lines via the accounting line configuration command. Accounting can also be enabled for WAN interfaces using protocols such as PPP by using the ppp accounting interface configuration command.

Configuring AAA Servers and Groups

In this section, we are going to be learning about configuring AAA servers and server groups in Cisco IOS software. The first part of this section focuses on RADIUS server configuration and the second part will focus on TACACS+ server configuration.

RADIUS server parameters are configured by using the radius-server host [address|hostname] global configuration command. However, before you can configure AAA servers, it is important that you enable AAA services via the aaa new-model global configuration command. RADIUS server configuration has the following options:

R1(config)#aaa new-model R1(config)#radius-server host 10.1.1.254 ? acct-port     UDP port for RADIUS accounting server (default is 1646) alias         1-8 aliases for this server (max. 8) auth-port     UDP port for RADIUS authentication server (default is 1645) backoff       Retry backoff pattern (Default is retransmits with constant delay) key           per-server encryption key (overrides default) non-standard  Parse attributes that violate the RADIUS standard retransmit    Specify the number of retries to active server (overrides default) test          Configure server automated testing. timeout       Time to wait for this RADIUS server to reply (overrides default) <cr>

 

Before we progress any further, we are going to look at the options provided by this command and what they are used for; however, because some of the options are beyond the scope of the IINS course requirements, we will be looking at only those that are applicable at this level. These options are described in the following table:

Keyword	Description
acct-port	This keyword is used to specify the UDP port that RADIUS will use for Accounting. By default, the Cisco IOS will use UDP port 1646, which is the port defined in RFC 2138. However, it is recommended that the UDP port number be set to 1813.
auth-port	This keyword specifies the UDP port that RADIUS will use for Authentication and Authorization. By default, the Cisco IOS will use UDP port 1645, which is the port defined in RFC 2138. However, it is recommended that the UDP port number be set to 1812.
key	This keyword is used to configure the pre-shared key that RADIUS will use.
timeout	This keyword is used to specify the duration that the NAS will wait for the RADIUS server to respond before moving on to the next method specified.

 

To reinforce these concepts, we will go through an example of RADIUS server configuration. In the following example, a RADIUS server with the IP address 10.1.1.254 is configured. This server will use the pre-shared key h0w2n3tw0rk.

The RADIUS server will be configured to use UDP port 1812 for Authentication and Authorization, and the UDP port 1813 for Account communication. Finally, the NAS will be configured to wait 30 seconds for the server to reply before attempting the next method specified in the method list:

R1(config)#aaa new-model R1(config)#radius-server host 10.1.1.254 key h0w2n3tw0rk R1(config)#radius-server host 10.1.1.254 auth-port 1812 acct-port 1813 R1(config)#radius-server host 10.1.1.254 timeout 30 R1(config)#end R1#

It is important to remember that, depending on the Cisco IOS version your NAS is running, these commands can be performed on a single line or they may need to be implemented on a line-by-line basis. Either method is acceptable and produces the same end result.

Next, we are going to learn about TACACS+ server configuration, which is performed by using the tacacs-server host [address|hostname] global configuration command. This command provides the following options:

R1(config)#tacacs-server host 10.1.1.254 ? key                per-server encryption key (overrides default) nat                To send client's post NAT address to tacacs+ server port               TCP port for TACACS+ server (default is 49) single-connection  Multiplex all packets over a single tcp connection to server (CiscoSecure) timeout            Time to wait for this TACACS+ server to reply (overrides default) <cr>

 

As was performed with RADIUS, we are going to describe the keywords that are relevant to the IINS course requirements, as applicable to TACACS+. These are described in the following table:

Keyword	Description
key	This keyword is used to configure the pre-shared key that TACACS+ will use.
port	This keyword is used to utilize a TCP port other than 49 for TACACS+.
timeout	This keyword is used to specify the duration that the NAS will wait for the TACACS+ server to respond before moving on to the next method specified.

 

The following example illustrates the configuration of a TACACS+ server using the IP address 10.1.1.254, with a pre-shared key of h0w2n3tw0rk and a timeout value of 15 seconds. As with RADUIS configuration, this can all be performed on a single line or on multiple lines. The net effect of using either method is the same as long as the configured options are correct:

R1(config)#aaa new-model R1(config)#tacacs-server host 10.1.1.254 R1(config)#tacacs-server key h0w2n3tw0rk R1(config)#tacacs-server timeout 15 R1(config)#exit R1#

 

Now that we have an understanding of the configuration commands required to configure individual RADIUS and TACACS+ servers, we will move on and look at the configuration commands required to configure AAA server groups, starting with RADIUS. AAA server groups are configured by using the aaa group server [radius|tacacs+][name] global configuration command. Once in server group configuration mode, the same basic concepts apply for the configuration of RADIUS or TACACS+ servers.

When configuring a RADIUS server group, the aaa group server radius [name] global configuration command is used. The options available with this command are as follows:

R1(config)#aaa group server radius MY-RADIUS-GROUP R1(config-sg-radius)#? RADIUS Server-group commands: accounting      Specify a RADIUS attribute filter for accounting attribute       Customize selected radius attributes authorization   Specify a RADIUS attribute filter for authorization backoff         Retry backoff pattern (Default is retransmits with constant delay) deadtime        Specify time in minutes to ignore an unresponsive server default         Set a command to its defaults exit            Exit from RADIUS server-group configuration mode ip              Internet Protocol config commands load-balance    Server group load-balancing options. no              Negate a command or set its defaults server          Specify a RADIUS server server-private  Define a private RADIUS server (per group)

 

Before we move forward, we need to understand the meaning of the keywords used and what function they serve. As before, the majority of these options are beyond the scope of the IINS course requirements; therefore, only applicable keywords are described. This is provided in the following table:

Keyword	Description
deadtime	This is the same as the timeout command when configuring individual servers. It is used to specify the duration that the NAS will wait for a RADIUS server to respond before moving on to the next server in the group. This value, however, is in minutes.
ip	This keyword is used to specify RADIUS IP parameters. The only applicable option (for IINS) is using this keyword to specify the source interface RADIUS packets will be sent from.
load-balance	This keyword is used to perform load balancing between the RADIUS servers in the group.
server	This keyword is used to specify the IP address of the hostname of a server in the group. This option also allows the administrator to specify the AAA ports that the RADIUS server will use.

 

The following example illustrates how to configure a RADIUS server group named IINS-RADIUS. This group will contain servers with IP addresses 10.1.1.1, 10.1.1.2, and 10.1.1.3. The RADIUS servers will be configured to use ports 1812 and 1813 for AAA services. Finally, all RADIUS packets will be sourced from the FastEthernet0/0 interface of the NAS:

R1(config)#aaa new-model R1(config)#aaa group server radius IINS-RADIUS R1(config-sg-radius)#server 10.1.1.1 auth-port 1812 acct-port 1813 R1(config-sg-radius)#server 10.1.1.2 auth-port 1812 acct-port 1813 R1(config-sg-radius)#server 10.1.1.3 auth-port 1812 acct-port 1813 R1(config-sg-radius)#ip radius source-interface fastethernet0/0 R1(config-sg-radius)#exit R1(config)#exit R1#

 

TACACS+ server groups are configured via the aaa group server tacacs+ [name] global configuration command. The options available with this command are:

R1(config)#aaa group server tacacs+ MY-TACACS-GROUP R1(config-sg-tacacs+)#? TACACS+ Server-group commands: accounting      Accounting specific command default         Set a command to its defaults exit            Exit from TACACS+ server-group configuration mode ip              Internet Protocol config commands no              Negate a command or set its defaults server          Specify a TACACS+ server server-private  Define a private TACACS+ server (per group)

 

The keywords that fall within the scope of the IINS course requirements are described in the following table:

Keyword	Description
ip	This keyword is used to specify TACACS+ IP parameters. The only applicable option (for IINS) is using this keyword to specify the source interface TACACS+ packets will be sent from.
server	This keyword is used to specify the IP address of the hostname of a server in the group.

 

The following example illustrates how to configure a TACACS+ server group named IINS-TACACS. This TACACS+ server group will contain servers with IP addresses 10.1.1.254, 172.31.1.254, and 192.168.1.254. All TACACS+ packets will be sourced from the Loopback0 interface of the NAS:

R1(config)#aaa new-model R1(config)#aaa group server tacacs+ IINS-TACACS R1(config-sg-tacacs+)#server 10.1.1.254 R1(config-sg-tacacs+)#server 172.31.1.254 R1(config-sg-tacacs+)#server 192.168.1.254 R1(config-sg-tacacs+)#ip tacacs source-interface loopback0 R1(config-sg-tacacs+)#exit R1(config)#exit R1# R1#show running-config Building configuration…   Current configuration : 2679 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R1 ! boot-start-marker boot-end-marker ! no logging console ! aaa new-model ! ! ! aaa group server tacacs+ IINS-TACACS  server 172.31.1.254  server 192.168.1.254  server 10.1.1.254  ip tacacs source-interface Loopback0 ! ! ! aaa session-id common ! —- [Truncated Output] —-

 

Now that we have a solid understanding of the configuration requirements for AAA servers and server groups, we will move on to the configuration of AAA services, beginning with Authentication. 

Configuring AAA Authentication

Authentication can also be configured for interfaces or terminal lines by using the login authentication interface or line configuration command. The options available with Authentication are configured via the aaa authentication global configuration command, as follows:

R1(config)#aaa authentication ? arap             Set authentication lists for arap. attempts         Set the maximum number of authentication attempts banner           Message to use when starting login/authentication. dot1x            Set authentication lists for IEEE 802.1x. enable           Set authentication list for enable. eou              Set authentication lists for EAPoUDP fail-message     Message to use for failed login/authentication. login            Set authentication lists for logins. password-prompt  Text to use when prompting for a password ppp              Set authentication lists for ppp. sgbp             Set authentication lists for sgbp. username-prompt  Text to use when prompting for a username

 

The following table describes the keywords that you must be familiar with for the purposes of satisfying the IINS requirements:

Keyword	Description
attempts	This keyword is used to specify the maximum number of login attempts allowed. Possible values range from 1 to 255.
banner	This keyword is used to configure a banner for login Authentication.
dot1x	This keyword is used to enable Authentication for 802.1x – which will be described in detail later in this guide.
enable	This keyword is used to enable Authentication for enable access.
fail-message	This keyword is used to specify a message that is printed when Authentication fails.
login	This keyword is used to enable Authentication for all logins.
password-prompt	This keyword is used to specify the password prompt that users will see when authenticating.
username-prompt	This keyword is used to specify the username prompt that users will see when authenticating.

 

Once you have selected the service you would like to authenticate (e.g. logins), you must then specify the method list that will be used for Authentication. You can either use a named (defined) method list or select the default method list, as illustrated in the following output:

R1(config)#aaa authentication login ? WORD     Named authentication list. default  The default authentication list.

 

Once the method lists have been selected, the next step is to define an ordered list of methods, which will be attempted by the AAA engine in the order in which they are configured:

R1(config)#aaa authentication login default ? enable         Use enable password for authentication. group          Use Server-group krb5           Use Kerberos 5 authentication. krb5-telnet    Allow logins only if already authenticated via Kerberos V Telnet. line           Use line password for authentication. local          Use local username authentication. local-case     Use case-sensitive local username authentication. none           NO authentication. passwd-expiry  enable the login list to provide password aging support

 

Before we move forward, it is imperative to understand the options presented here. Therefore, they are described in detail in the following table:

Keyword	Description
enable	This keyword specifies that the enable password/secret should be used for Authentication.
group	This keyword specifies that TACACS+ or RADIUS servers, or server groups, should be used for Authentication.
line	This keyword specifies that the line password (e.g. VTY) should be used for Authentication.
local	This keyword specifies that the username – configured via the username command – be used for Authentication.
local-case	This keyword specifies that the username – configured via the username command – be used for Authentication; however, the username is case-sensitive.
none	This method is effectively a deny all. It should be specified at the end of the list of methods configured because it prevents any further Authentication attempts once reached.

 

To reinforce Authentication configuration, we will go through a few examples, illustrating the different ways in which Authentication can be configured in Cisco IOS software.

In the first example, Authentication will be configured on the router for all logins using the default method list. The sequential methods used in Authentication will be via:

1. TACACS+, using a server with the IP address 10.1.1.254 and a pre-shared key of 11nsc3rt;
2. The enable password; and
3. The line password.

In addition, all terminal lines will be configured so that they are authenticated using AAA. This configuration is performed as follows:

 

R1(config)#aaa new-model R1(config)#aaa authentication login default group tacacs+ enable line none R1(config)#tacacs-server host 10.1.1.254 key 11nsc3rt R1(config)#line con 0 R1(config-line)#login authentication default R1(config-line)#exit R1(config)#line vty 0 4 R1(config-line)#login authentication default R1(config-line)#exit R1(config)#exit R1#

 

In the second example, Authentication will be enabled for 802.1x using a method list named RADIUS-DOT1X. The sequential methods used in Authentication will be via:

1. RADIUS server 10.1.1.254, using default ports for AAA and a pre-shared key of dot1x;
2. The local database; and
3. The enable password.

This configuration is performed as follows:

R1(config)#aaa new-model R1(config)#aaa authentication dot1x RADIUS-DOT1X group radius local enable none R1(config)#radius-server host 10.1.1.254 key dot1x R1(config)#exit R1#

 

The third, and final, example demonstrates how to configure Authentication for all logins using a method list named LOGIN-LIST. The sequential methods used in Authentication will be via:

1. A TACACS+ server group named TAC-GRP, which contains servers 10.0.0.1 and 10.0.0.2;
2. A RADIUS server group named RAD-GRP, which contains servers 11.0.0.1 and 11.0.0.2; and
3. The enable secret.

This configuration is performed as follows:

R1(config)#aaa new-model R1(config)#aaa authentication login LOGIN-LIST group TAC-GRP group RAD-GRP enable none R1(config)#aaa group server tacacs+ TAC-GRP R1(config-sg-tacacs+)#server 10.0.0.1 R1(config-sg-tacacs+)#server 10.0.0.2 R1(config-sg-tacacs+)#exit R1(config)#aaa group server radius RAD-GRP R1(config-sg-radius)#server 11.0.0.1 R1(config-sg-radius)#server 11.0.0.2 R1(config-sg-radius)#exit R1(config)#line con 0 R1(config-line)#login authentication LOGIN-LIST R1(config-line)#exit R1(config)#line vty 0 4 R1(config-line)#login authentication LOGIN-LIST R1(config-line)#exit R1(config)#exit R1#

 

Although the configuration options may seem confusing at first glance, remember that practice makes perfect. Take your time to understand the manner in which these commands are executed and the logic behind method lists, and in no time, it will all make perfect sense. Having stated that, we will now move on to the second part of the AAA framework: Authorization. 

Configuring AAA Authorization

Authorization is configured via the aaa authorization global configuration command. In addition to this, Authorization can be applied to terminal lines (e.g. VTY) via the authorization line configuration command. In order for Authorization to work,

Authentication must be configured and the AAA client must have successfully authenticated.  The options available for Authorization in the Cisco IOS software are as follows:

R2(config)#aaa authorization ? auth-proxy       For Authentication Proxy Services cache            For AAA cache configuration commands         For exec (shell) commands. config-commands  For configuration mode commands. configuration    For downloading configurations from AAA server console          For enabling console authorization exec             For starting an exec (shell). multicast        For downloading Multicast configurations from an AAA server network          For network services. (PPP, SLIP, ARAP) reverse-access   For reverse access connections template         Enable template authorization

 

The following table describes the keywords that you are expected to be familiar with when configuring Authorization:

Keyword	Description
commands	This keyword is used to enable Authorization for EXEC commands.
config-commands	This keyword is used to enable Authorization for configuration (Config) commands, e.g. router ospf 1.
console	This keyword is used to enable Authorization for Console access.
exec	This keyword is used to enable Authorization for beginning an EXEC shell on the selected lines.
network	This keyword is used to enable Authorization for network services, such as PPP.

 

Once you have selected the service you want to authorize, you must then select the method list to use for Authorization. As is the case for Authentication, you can select either a named (defined) method list that is configured on a AAA server or use the default method list, as illustrated in the following output:

R2(config)#aaa authorization network ? WORD     Named authorization list. default  The default authorization list.

 

The final step is specifying the methods used after the method list has been defined. This step follows the same logic as that used in Authentication.  In a manner similar to Authentication, we will go through a few examples on Authorization to ensure that you are comfortable with the Authorization CLI in Cisco IOS software.

The first example illustrates how to configure Authorization for PPP (network) using the method list PPP-AUTHOR. PPP will be enabled and authorized via the same method list on the Serial0/0 interface of the router. The sequential methods to be used will be the local user database. This is performed as follows:

R2(config)#aaa authorization network PPP-AUTHOR local none R2(config)#interface serial0/0 R2(config-if)#encapsulation ppp R2(config-if)#ppp authorization PPP-AUTHOR R2(config-if)#exit R2(config)#exit R2#

 

The second Authorization example illustrates how to authorize level 15 commands if the user has been successfully authenticated via the method list COMND-AUTHOR. This method list is also applied to all terminal lines on the router (this example assumes that Authentication has been configured and, thus, focuses only on Authorization commands), as follows:

R2(config)#aaa authorization commands 15 COMND-AUTHOR if-authenticated R2(config)#line con 0 R2(config-line)#authorization commands 15 COMND-AUTHOR R2(config-line)#exit R2(config)#line vty 0 4 R2(config-line)#authorization commands 15 COMND-AUTHOR R2(config-line)#exit R2(config)#exit R2#

 

The final example in this section illustrates how to enable Authorization for configuration commands. Authorization is also configured so that users attempting to begin an EXEC shell on any terminal lines should be authorized using the method list TAC-AUTHOR. TACACS+ is configured to authorize EXEC shell access and a TACACS+ server group named TAC-GROUP, which contains servers 10.1.1.1 and 11.1.1.1, is used for Authorization:

R2(config)#aaa authorization config-commands R2(config)#aaa authorization exec TAC-AUTHOR group TAC-GROUP R2(config)#aaa group server tacacs+ TAC-GROUP R2(config-sg-tacacs+)#server 10.1.1.1 R2(config-sg-tacacs+)#server 11.1.1.1 R2(config-sg-tacacs+)#exit R2(config)#line con 0 R2(config-line)#authorization exec TAC-AUTHOR R2(config-line)#exit R2(config)#line vty 0 4 R2(config-line)#authorization exec TAC-AUTHOR R2(config-line)#exit R2(config)#exit R2#

 

 Configuring AAA Accounting

As we learned earlier in this chapter, Accounting is configured via the aaa accounting global configuration command. Accounting is enabled for terminal lines via the accounting line configuration command and can also be enabled for certain WAN protocols (e.g. PPP) via the ppp accounting interface configuration command. The options available for Accounting in Cisco IOS software are as follows:

R1(config)#aaa accounting ? delay-start       Delay PPP Network start record until peer IP address is known. nested            When starting PPP from EXEC, generate NETWORK records before EXEC-STOP send              Send records to accounting server. session-duration  Set the preference for calculating session durations suppress          Do not generate accounting records for a specific type of user record. auth-proxy        For authentication proxy events. commands          For exec (shell) commands. connection        For outbound connections. (telnet, rlogin) dot1x             For dot1x sessions. exec              For starting an exec (shell). gigawords         64 bit interface counters to support Radius attributes 52 & 53. multicast         For multicast accounting. network           For network services. (PPP, SLIP, ARAP) resource          For resource events. system            For system events. update            Enable accounting update records.

 

As is the case with Authentication and Authorization, some of the keywords presented are beyond the scope of the IINS course requirements. However, the following table lists and describes the Accounting keywords that you are expected to be familiar with:

Keyword	Description
send	This keyword configures Accounting to send stop records for authenticated users (or failures) to the AAA server.
commands	This keyword configures Accounting to send records for EXEC commands to the AAA server.
connection	This keyword configures Accounting to send records for all outbound connections to the AAA server.
exec	This keyword configures Accounting for EXEC sessions (user shells).
network	This keyword configures Accounting for network-related services, such as PPP.
system	This keyword configures Accounting for all system-level events.

 

Once the service for which you want Accounting enabled has been selected, you then have the option of specifying either the default method list or a named (defined) method list to be used for Accounting. In addition to these two options, a third option is also available for Accounting. This option, guarantee-first, guarantees that the first AAA packet sent will be the Accounting-On packet. This is not a desirable trait (due to reasons beyond the scope of the IINS course requirements); therefore, we will not be discussing this keyword in any further detail. Accounting options are as follows:

R1(config)#aaa accounting commands 15 ? WORD             Named Accounting list. default          The default accounting list.   guarantee-first  Guarantee system accounting as first record.

 

Now that we have an understanding of the command logic required to successfully configure Accounting, we will conclude this section with a few configuration examples to reinforce the concepts and steps we have learned. The first example illustrates how to enable Accounting to send start and stop records for EXEC sessions using a method list named ACCT-LIST. Accounting information will be sent to the RADIUS server 192.168.1.254 using port 1813:

R1(config)#aaa accounting exec ACCT-LIST start-stop group radius R1(config)#radius-server host 192.168.1.254 auth-port 1812 acct-port 1813 R1(config)#line con 0 R1(config-line)#accounting exec ACCT-LIST R1(config-line)#exit R1(config)#line vty 0 4 R1(config-line)#accounting exec ACCT-LIST R1(config-line)#exit R1(config)#exit R1#

 

The second example illustrates how to enable only stop records Accounting for all Level 15 commands using the CMD-ACC method list. This Accounting information will be sent to a TACACS+ server group named TAC-ACC, which contains servers 10.1.1.254 and 10.2.2.254:

R1(config)#aaa accounting commands 15 CMD-ACC stop-only group TAC-ACC R1(config)#aaa group server tacacs+ TAC-ACC R1(config-sg-tacacs+)#server 10.1.1.254 R1(config-sg-tacacs+)#server 10.2.2.254 R1(config-sg-tacacs+)#exit R1(config)#line con 0 R1(config-line)#accounting commands 15 CMD-ACC R1(config-line)#exit R1(config)#line vty 0 4 R1(config-line)#accounting commands 15 CMD-ACC R1(config-line)#exit R1(config)#exit R1#

 

The final example illustrates how to enable Accounting for network services (PPP) using the default method list. Start and stop records will be sent to RADIUS server 172.16.1.254 using the default Accounting port 1646 and a pre-shared key accntkey. PPP is enabled on the Serial0/0 interface of the router and configured for Accounting services:

R1(config)#aaa accounting network default start-stop group radius R1(config)#radius-server host 172.16.1.254 key accntkey R1(config)#interface serial0/0 R1(config-if)#encapsulation ppp R1(config-if)#ppp accounting default R1(config-if)#exit R1(config)#exit R1#

 

As with any other new concept, practice makes perfect. Therefore, if you are able to get your hands on a personal router, practice configuring AAA as much as possible. If you do not have your own personal router(s), then leverage the labs available on www.howtonetwork.com to practice your configurations and reinforce these concepts.

The last section in this chapter deals with Kerberos. Although not explicitly stated in the IINS exam objectives, Kerberos is a security protocol that falls under the AAA umbrella. Going through this section will provide you with a basic understanding of the Kerberos protocol. 

Kerberos Basics

Kerberos is a trusted third-party Authentication Layer 7 (Application Layer) service. Kerberos is a secret-key network authentication protocol developed at the Massachusetts Institute of Technology (MIT) that uses the Data Encryption Standard (DES) cryptographic algorithm for encryption and authentication services. DES is described in detail later in this guide. In the Kerberos protocol, the trusted third party is the Key Distribution Center (KDC). The following diagram illustrates the basic operation of Kerberos:

In the diagram illustrated above, the Kerberos Authentication process begins when the remote user initiates a connection to the NAS, as illustrated in step 1. When the NAS receives this connection, it builds a service credential request and sends it to the Key Distribution Center (KDC), as illustrated in step 2.

In step 3, the KDC decrypts the request from the NAS and builds a service credential, which is then sent back to the remote user. When the service credential from the NAS is sent, both the NAS and the remote user decrypt the credential. Once decrypted, the remote user is then able to exchange data with the NAS, as illustrated in step 4.

Unlike RADIUS and TACACS+, Kerberos authenticates users by issuing tickets. These tickets have a limited lifespan and are stored in a user’s credential cache. These tickets can then be used in place of the standard username/password Authentication scheme.

The Kerberos credential scheme uses a concept called single logon. This process allows for a user to be authenticated once and then allows a user access to network resources whenever the user’s credentials are accepted. To enhance security, Kerberos also uses timestamps, which are simply numbers that represent the date and time, to assist in the detection of replay attacks.

Unlike RADIUS and TACACS+, Kerberos uses both TCP and UDP ports. TCP/UDP ports 88, 543, and 749 and TCP ports 754, 2105, and 444 are all used for packet delivery in Kerberos. In addition to this, Kerberos supports username/password encryption and allows for Telnet sessions to be encrypted. While we will not be going into any further technical details on Kerberos, the following table provides a brief description of common Kerberos terminology:

Kerberos Term	Definition
Credential	This is a general term that refers to authentication tickets, such as ticket granting tickets (TGTs) and service credentials. Credentials are used to verify the identity of a user or service. If a network service trusts the Kerberos server that issued a ticket, it can be used in place of retyping in a username and password. Credentials have a default lifespan of 8 hours.
Instance	This is an authorization level label for Kerberos principals. Most Kerberos principals are in the form user@REALM, for example, paul@HOWTONETWORK.NET. In Kerberos, the realm name MUST be in uppercase letters.
Kerberized	Applications and services that have been modified to support the Kerberos credential infrastructure are said to be Kerberized.
Kerberos realm	A domain consisting of users, hosts, and network services that are registered to a Kerberos server. Kerberos realms are always in uppercase letters. The Kerberos realm is also used to map a DNS domain to a Kerberos realm.
Kerberos server	A daemon running on a network host. Users and network services register their identities with the Kerberos server. Network services query the Kerberos server to authenticate to other network services. It is sometimes referred to as the Master Kerberos server.
Key Distribution Center (KDC)	A Kerberos server and database program that runs on a network host. It is used to issue TGTs.
Principal	Also known as a Kerberos identity, this is who you are or what a service is according to the Kerberos server.
Service credential	A credential for a network service. When issued from the KDC,  service credentials are encrypted with the password shared by the network service and the KDC, and also with the user’s TGT.
SRVTAB	A password that a network service shares with the KDC. The network service authenticates an encrypted service credential using the SRVTAB to decrypt it.  The SRVTAB is also referred to as the KEYTAB.
Ticket Granting Ticket (TGT)	A credential issued by the KDC to authenticated users. When users receive a TGT, they can authenticate to network services within the Kerberos realm represented by the KDC.

 

Chapter Summary

 

The following section is a summary of the major points you should be aware of in this chapter:

AAA Overview

• AAA stands for Authentication, Authorization and Accounting
• Authentication is used to validate identity
• Authorization is used to determine what that particular user can do
• Accounting is used to allow for an audit trail
• The primary advantages of using AAA are:

• Standard Authentication methods
• Scalability
• Greater Flexibility and Control
• Multiple Backup Systems

• AAA uses the TACACS+, Kerberos, and RADIUS authentication methods

The AAA Model

• The AAA model is used to control access to devices, enforce policies and audit usage
• The AAA framework uses a set of three independent function which are:

• Authentication
• Authorization
• Accounting

• Authentication is based on verifying user credentials, which can be any of the following:

1. Something the user knows – which is referred to as Authentication by knowledge
2. Something the user possesses – which is referred to as Authentication by possession
3. Something the user is – which is referred to as user characteristic or, biometrics.

• Authorization uses AV pairs to determine the actions a user, etc is allowed to perform
• AAA clients are responsible for enforcing user access control based on AV pairs
• Accounting records are made up of accounting AV pairs
• The AAA client then sends Accounting records to the AAA server for storage
• AAA services are correlated as follows:

1. Authentication is valid without authorization
2. Authentication is valid without accounting
3. Authorization is not valid without authentication
4. Accounting is not valid without authentication

 

AAA Operation

• In order for AAA to work, the NAS must be able to access security information for a specific user to provide AAA services. This information may be stored locally, i.e. on the NAS itself, or remotely, on a RADUIS, TACACS+ or Kerberos server
• Unlike authentication and Authorization, there is no search for AV pairs in Accounting

RADIUS

• RADIUS stands for Remote Authentication Dial-In User Service
• The original specification for RADIUS is defined in RFC 2138 and 2139
• Updates to RADIUS are included in newer RFCS 2865 and 2866
• A RADIUS server is a device that has the RADIUS daemon or application installed
• RADIUS is an open-standard protocol that is distributed in C source code format
• RADIUS only encrypts the password, the rest of the packet is sent in clear text
• RADIUS uses UDP as the Transport layer protocol
• RADIUS uses UDP port 1812 for Authentication and Authorization
• RADIUS uses UDP port 1813 for Accounting
• Legacy applications use 1645 for Authentication and Authorization and 1646 for Accounting
• RADIUS has limited protocol support, and does not support protocols like IPX, for example
• RADIUS packet message types are:

1. Access-Request (username/password and other information is sent to the AAA server)
2. Access-Accept (the username is found in the database, and the password is validated)
3. Access-Reject (username is not found in the database, or the password is incorrect)
4. Accounting-Request (used by the NAS to start, send updates, or stop Accounting)
5. Accounting Response (sent by the AAA server to acknowledge Accounting-Requests)
6. Access-Challenge (the RADIUS server wants more information from the user)

TACACS+

• TACACS+ is a Cisco-proprietary protocol that is used in the AAA framework
• TACACS+ uses TCP as a Transport Layer protocol, using TCP port 49
• TACACS+ separates the three AAA architectures
• TACACS+ encrypts the data between the user and the server
• TACACS+ supports multiple protocols, e.g. IP, IPX, AppleTalk and X.25
• The TACACS+ Authentication phase uses three distinct packet types:

1. START packets (used initially when the user attempts to connect)
2. REPLY / RESPONSE packets (sent by the AAA server during)
3. CONTINUE packets (used by AAA clients to return username/password information)

• Valid TACACS+ REPLY / RESPONSE packets could be any one of the following messages:

1. ACCEPT (user has been successfully authenticated)
2. REJECT (Authentication has failed)
3. ERROR (a communication problem exists between the NAS and the AAA server)
4. CONTINUE (that the server is expecting additional information)

• TACACS+ Authorization uses REQUEST and RESPONSE messages
• TACACS+ REQUEST messages are sent by the NAS
• TACACS+ RESPONSE messages are sent by the server and contain one of the following:

1. PASS_ADD (indicates that request is authorized)
2. PASS_REPL ( sent by the AAA server when it ignores the request)
3. FOLLOW ( the AAA wants to have Authorization performed on another server)
4. ERROR (indicates indicate an error on the AAA server)

• TACACS+ Accounting also uses REQUEST and the RESPONSE messages
• TACACS+ Accounting takes place by sending a record to the AAA server
• Each record includes an AV pair for Accounting and one of three types may be sent:

1. START (indicates when a service begins)
2. STOP (indicates when a service is about to stop, or when a service is stopped)
3. CONTINUE (is sent when a service is still in progress)

Implementing AAA Services

• There are three ways in which AAA services can be implemented:

1. AAA can be implemented as a self-contained AAA local security database
2. AAA can be implemented as a Cisco Access Control Server (ACS) application server
3. AAA can be implemented using the Cisco Secure ACS Solutions Engine appliance

• AAA services are based on method lists
• Methods lists contain sequenced AAA entries
• Method lists allow control of one or more security protocols and servers to be used
• There are two basic types of method lists:

1. Named Method
2. Default Method

• In order to configure AAA services, the following general steps should be taken:

1. Enable AAA via the aaa new-model global configuration command.
2. Configure the security protocol parameters, such as the IP address and shared key
3. Define the Authentication service and the method lists
4. Apply the Authentication named method list(s) to interfaces or terminal lines
5. Define the Authorization method list(s)
6. Apply the Authorization method list(s) to terminal lines
7. Define the Accounting service and method lists
8. Apply the Accounting method list(s) to terminal lines

Configuring AAA Servers and Groups

• RADIUS server parameters are configured by using the radius-server host [address|hostname] global configuration command
• TACACS+ server parameters are configured by using the tacacs-server host [address|hostname] global configuration command
• AAA server groups are configured by using the aaa group server [radius|tacacs+][name] global configuration command

Configuring AAA Authentication

• Authentication is configured via the aaa authentication global configuration command

Configuring AAA Authorization

• Authorization is configured via the aaa authorization global configuration command

Configuring AAA Accounting

• Accounting is configured via the aaa accounting global configuration command

Kerberos Basics

• Kerberos is a trusted third-party Authentication Layer 7 service
• In the Kerberos protocol, the trusted third-party is the KDC
• The Kerberos credential scheme uses a concept called single logon
• Kerberos uses both TCP and UDP ports
• Kerberos uses TCP/UDP ports 88, 543, 749 and TCP ports 754, 2105, and 444

 

Commands Used in this Chapter

The following section is a summary of the commands used in this chapter:

 

Command	Description
username [name] privilege [level] secret [password]	Used to configure a username, assign privileges and set the user password
aaa new-model	Globally enables AAA
aaa group server [radius|tacacs+][group_name]	Used to configure AAA RADIUS or TACACS+ server groups
tacacs-server host [address|hostname] key [shared_key]	Used to configure TACACS+ server and specify parameters
radius-server host [address|hostname] key [shared_key]	Used to configure RADIUS server and specify parameters
aaa authentication [attempts|banner|dot1x|enable|fail-message|login|password-prompt|username-prompt]	Used to configure AAA Authentication globally
login authentication	Used to configure AAA Authentication for interfaces and terminal lines
aaa authorization [commands|config-commands|console|exec|network]	Used to configure AAA Authorization globally
authorization	Used to configure AAA Authorization for interfaces and terminal lines
aaa accounting [send|commands|connection|exec|network|system]	Used to configure AAA Accounting globally
accounting	Used to configure AAA Accounting for interfaces and terminal lines

Read the Cisco AAA paper.