CCNP Security SISAS 300-208 Official Cert Guide (2015)

Part II: “The Triple A” (Authentication, Authorization, and Accounting)

Chapter 2. Fundamentals of AAA

This chapter covers the following exam topics:

Compare and Select AAA Options

TACACS+

RADIUS

Describe Features and Functionality of Authentication and Authorization

Describe RADIUS Flows

AV Pairs

Device Administration

In the world of security, we can only be as secure as our controls permit us to be. There are laws in the United States defining what a passenger of an airplane is permitted to bring onboard. If the TSA agents weren’t operating the metal detectors and x-ray machines (and all the other things that slow us down when trying to reach our planes), then how would the FAA ever really enforce those policies?

With technology, we are faced with the same challenges. We need to have controls in place to ensure that only the correct entities are using our technological “gadgets” while getting in the way of the user as little as possible. The same concepts can be applied to many use cases, including human interaction with a computer, a computer’s interaction with a network, and even an application’s interaction with data.

This security principle is known as authentication, authorization, and accounting (AAA), often referred to as Triple-A.

Before allowing an entity to perform certain actions, you must ensure you know who that entity actually is (authentication) and whether the entity is authorized to perform that action (authorization). Additionally, you need to ensure that accurate records are maintained showing that the action has occurred, so you should keep a security log of the events (accounting).

The concepts of AAA can be applied to many aspects of a technology lifecycle. However, this exam, and therefore this book, will focus on the two main aspects of AAA related to networking:

1. Device administration—Controlling access to who can log in to a network device console, telnet session, secure shell (SSH) session, or other method is one form of AAA that you should be aware of. This is AAA for device administration, and although it can often seem similar to network access AAA, it has a completely different purpose and requires different policy constructs.

2. Network access—Securing network access can provide the identity of the device or user before permitting the entity to communicate with the network. This is AAA for network access and is the type of AAA that is most focused on in this exam and book.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 2-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Table 2-1 “Do I Know This Already?” Section-to-Question Mapping

Caution

The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

1. Which of the following best describes the difference between authentication and authorization?

a. There is no difference between authentication and authorization.

b. Authorization determines what a user may do, whereas an authentication determines what devices the user can interact with.

c. Authentication is used with both network access and device administration, whereas authorization applies only to device administration.

d. Authentication validates the user’s identity, whereas authorization determines what that user is permitted to do.

2. Which of the following are types of AAA as related to the topics of this exam? (Select two.)

a. Device administration

b. Device access

c. A division of minor league baseball

d. Network access

e. Network administration

3. Which of the following protocols is best suited for granular command-level control with device administration AAA?

a. DIAMETER

b. TACACS+

c. RADIUS

d. RADIUS+

4. Which of the following protocols is best suited for authenticating and authorizing a user for network access AAA?

a. TACACS+

b. CHAP

c. RADIUS

d. MS-CHAPv2

5. True or False? RADIUS can be used for device administration AAA.

a. True

b. False

6. Which of the following Cisco products should be used for device administration with TACACS+?

a. Cisco Secure Access Control Server (ACS)

b. Cisco Identity Services Engine

c. Cisco TACACS+ Control Server (TCS)

d. Cisco Centri

7. Why is RADIUS or TACACS+ needed? Why can’t the end user authenticate directly to the authentication server?

a. The added level of complexity helps Cisco and other vendors to sell more products.

b. Because the names sound so cool.

c. RADIUS and TACACS+ are used between the end user and the authentication server.

d. Both RADIUS and TACACS+ extend the Layer-2 authentication protocols, allowing the end user to communicate with an authentication server that is not Layer-2 adjacent.

8. Which of the following are TACACS+ messages sent from the AAA client to the AAA server? (Select all that apply.)

a. START

b. REPLY

c. CHALLENGE

d. REQUEST

9. When using RADIUS, what tells the AAA server which type of action is being authenticated?

a. The TACACS+ service.

b. The Service-Type field.

c. RADIUS does not distinguish between different services.

d. The action AV-pair.

10. Which of the following best describes an AV-pair?

a. When communicating with an AAA protocol, the AV-pair stipulates a common attribute or object and its assigned value.

b. Cisco likes to throw in terms to confuse the reader.

c. The AV-pair is used to choose either TACACS+ or RADIUS.

d. The AV-pair is used to specify the quality of service (QoS) for audio and video traffic.

Foundation Topics

Triple-A

Simply put, authentication is the validation of an identity or a credential. It is a very important step in the process of performing any sort of secure access control, regardless of what you are controlling. Forget about networking for a second, and consider paying for groceries with a credit card. As a credit card owner, you have the choice to sign the back of the card or to write “check ID” on the back. The more secure method is to force the validation of the ID of the person using that card and ensure that the credential matches the name on the front of the credit card.

Having a cashier verify the identity of the card user is authentication. Ensuring that the identity matches the name printed on the card is an authorization. Think about it: What if Kevin Redmon were to go into a retail store and hand over a credit card to pay for the $10,000 of electronics he is purchasing? He passes his driver’s license to the cashier, who verifies that he and the picture on the license match. It is certainly his identity. However, the name printed on the credit card is Aaron Woland. Should the transaction go through? Of course not.

Kevin’s attempt to use Aaron’s credit card is now in the log files of the point of sale system, the video monitoring system of the store, and other systems. This is the accounting portion of AAA. It’s a critical piece that is required for reporting, audits, and more.

It will become paramount for you as a security professional and as someone who is taking the Implementing Cisco Secure Access Solutions exam to understand the differences between and purposes of all three A’s in Triple-A.

Compare and Select AAA Options

As previously described in this chapter, there are two uses of AAA that you will focus on for this exam and this book: device administration and network access.

Device Administration

Device administration is a method of AAA for controlling access to a network device console, telnet session, SSH session, or other method of accessing the device’s operating system itself for purposes of configuration. For example, imagine your company has an Active Directory group named Network Administrators, which should have full access (privilege level 15) to the Cisco Switches in a company’s network. They should therefore be able to make changes to virtual local area networks (VLANs), see the entire running configuration of the device, and more.

There could be another group named Network Operators who should be allowed to only view the output of show commands and not allowed to configure anything in the device.

Device administration AAA allows you to get more granular. Cisco Secure Access Control Server (ACS) has a capability to provide command sets, which are listings of commands that are permitted or denied to be run by an authenticated user. In other words, a user can authenticate to the Cisco IOS shell, and ACS can permit or deny his execution of individual commands, if you choose.

Figure 2-1 illustrates device administration.

Figure 2-1 Device administration.

Device administration can be very interactive in nature, with the need to authenticate once but authorize many times during a single administrative session in the command line of a device. As such, it lends itself well to using the Terminal Access Controller Access Control System (TACACS) client/server protocol, more so than Remote Authentication Dial-in User Service (RADIUS).

As the name describes, TACACS was designed for device administration AAA to authenticate and authorize users for mainframes, Unix terminals, and other consoles.

Both the TACACS and RADIUS protocols are discussed in more depth within this chapter; however, TACACS separates out the authorization portion of AAA, allowing for a single authentication and multiple authorizations within the same session. This is why it lends itself to device administration more than RADIUS. RADIUS does not provide the ability to control which commands can be executed.

To learn more about device administration AAA, beyond the knowledge necessary to pass the SISAS exam, take a look at the Cisco Press book AAA Identity Management Security (ISBN-10 1-58714-144-2).

Network Access

Secure network access is essentially all about learning the identity of the user or endpoint before permitting that entity to communicate within the network. This type of AAA is the main focus in this exam and book. Network access AAA really took a strong hold back in the day of modems and dial-up networking with plain old telephone service (POTS). In those days companies provided network access to workers from outside the physical boundaries of the company’s buildings with the use of modems. People gained Internet access by using dial-up to Internet service providers (ISPs) over their modems, as well. Basically, all that was needed was a modem and a phone line.

Allowing anyone to dial in to your network just by dialing your modem’s phone number is not a secure idea. The user needs to be authenticated before allowing the connection. That is where RADIUS came into play originally, as is evident in the name of the protocol (Remote Access Dial In User Service). RADIUS was used between the network access device (NAD) and the authentication server. The authentication was normally Password Authentication Protocol (PAP), Challenge/Handshake Authentication Protocol (CHAP), or Microsoft CHAP (MS-CHAP).

Figure 2-2 illustrates dial-up remote access.

Figure 2-2 Dial-Up remote access.

As technology continued to evolve and Wi-Fi became prevalent, direct dial-in to a company was replaced by Remote Access virtual private networks (VPNs). The IEEE standardized on a method to use Extensible Authentication Protocol (EAP) over local area networks (IEEE 802.1X), and RADIUS was used as the protocol of choice to carry the authentication traffic. In fact, IEEE 802.1X cannot use TACACS—it must use RADIUS.

Note

Another protocol similar to RADIUS, known as DIAMETER, also can be used with 802.1X. However, it is mostly found in the service provider space and is not covered as part of this exam.

RADIUS is the protocol used almost exclusively with network access AAA.

TACACS+

TACACS is a protocol set created and intended for controlling access to Unix terminals. Cisco created a new protocol called TACACS+, which was released as an open standard in the early 1990s. TACACS+ may be derived from TACACS, but it is a completely separate and non–backward-compatible protocol designed for AAA. Although TACACS+ is mainly used for device administration AAA, you can use it for some types of network access AAA.

It is important to understand that TACACS+ is not currently a supported protocol with Cisco Identity Services Engine (ISE) 1.2. The Cisco Secure Access Control Server (ACS) is Cisco’s primary authentication server product for enterprises that have a need to use TACACS+ for device administration AAA.

Note

Other products from Cisco support TACACS+, such as the Cisco Access Registrar solution. However, those solutions are geared toward service providers and are not covered in the exam or this book.

TACACS+ uses Transmission Control Protocol (TCP) port 49 to communicate between the TACACS+ client and the TACACS+ server. An example is a Cisco switch authenticating and authorizing administrative access to the switch’s IOS CLI. The switch is the TACACS+ client, and Cisco Secure ACS is the server, as illustrated in Figure 2-3.

Figure 2-3 TACACS+ client server communication.

One of the key differentiators of TACACS+ is its capability to separate authentication, authorization, and accounting as separate and independent functions. This is why TACACS+ is so commonly used for device administration, even though RADIUS is still certainly capable of providing device administration AAA.

Device administration can be interactive in nature, with the need to authenticate once but authorize many times during a single administrative session in the command line of a device. A router or switch might need to authorize a user’s activity on a per-command basis. TACACS+ is designed to accommodate that type of authorization. As the name describes, TACACS+ was designed for device administration AAA, to authenticate and authorize users into mainframe and Unix terminals and other terminals or consoles. TACACS+ communication between the client and server uses different message types depending on the function. In other words, different messages can be used for authentication than are used for authorization and accounting. Another interesting point to know, especially for the purposes of the SISAS exam, is that TACACS+ communication will encrypt the entire payload.

TACACS+ Authentication Messages

When using TACACS+ for authentication, only three types of packets are exchanged between the client (the network device) and the server:

START—This packet is used to begin the authentication request between the AAA client and the AAA server.

REPLY—Messages sent from the AAA server to the AAA client.

CONTINUE—Messages from the AAA client used to respond to the AAA server requests for username and password.

The following paragraphs describe the authentication flow process and the messages used.

When an authentication request is sent from the client to the server, it begins with a START message from the network device to the server. The START message tells the server that an authentication request is coming. All messages from the server to the network device (client) will be a REPLY during authentication. The server sends a REPLY message asking the client to retrieve the username. The username is sent to the server within a CONTINUE message.

After the server receives the username, it sends a REPLY message back to the client requesting the password, which is sent back to the server in another CONTINUE message. The server then sends a final REPLY message with the pass or fail status of the authentication request.

The possible values returned from the AAA server to the AAA client within the final REPLY message are

ACCEPT—The user authentication succeeded and the authorization process may begin, if the AAA client is configured for authorization.

REJECT—The user authentication has failed. The login will be denied or the end user will be prompted to try again, depending on the configuration of the AAA client.

ERROR—An error occurred at some point during the authentication. AAA clients will typically attempt to authenticate the user again or attempt a different method of authenticating the user.

CONTINUE—The user is prompted for additional information. This is not to be confused with the CONTINUE message sent from the AAA client to the AAA server. This value is sent from the AAA server within a REPLY message, indicating that more information is required.

Figure 2-4 illustrates the authentication messages between the client and server.

Figure 2-4 TACACS+ authentication communication flows.

TACACS+ Authorization and Accounting Messages

When using TACACS+ for authorization, only two messages are used between the AAA client and the AAA server:

REQUEST—This message is sent from the AAA client to the AAA server to request an authorization. The authorization can be related to access to a CLI shell or possibly to authorize a specific command. The protocol communication does not discriminate. The function requested is known as a service. For example, the service would be “shell” for CLI access to a device running Cisco IOS. Each service may be communicated with attribute-value (AV) pairs. You can find more about specific TACACS+ AV pairs at http://bit.ly/1mF27aT.

RESPONSE—This message is sent from the AAA server back to the AAA client with the result of the authorization request including specific details, such as the privilege level assigned to the end user. RESPONSE messages can contain one of five replies:

FAIL—This response indicates the user should be denied access to the requested service.

PASS_ADD—This response indicates a successful authorization, and the information contained within the RESPONSE message should be used in addition to the requested information. If no additional arguments are returned by the AAA server within the RESPONSE message, the request is simply authorized as-is.

PASS_REPL—Indicates a successful authorization, but the server has chosen to ignore the REQUEST and is replacing it with the information sent back in the RESPONSE.

FOLLOW—This reply indicates that the AAA server wants the AAA client to send the authorization request to a different server. The new server information will be listed in the RESPONSE packet. The AAA client can use that new server or treat the response as a FAIL.

ERROR—A reply of ERROR indicates a problem occurring on the AAA server, and further troubleshooting needs to occur.

A key function of AAA that cannot be overlooked is accounting. It is crucial to security to have a record of what has transpired. In addition to the authorization request being sent to the AAA server, there should be accounting records of the activities of the user.

Much like authorization messages, only two message types are used in accounting:

REQUEST—This message is sent from the AAA client to the AAA server to indicate a notification of activity. Three values can be included with the REQUEST:

START—A start record indicates that a service has begun.

STOP—The stop record indicates that the service has ended.

CONTINUE—The continue record is also sometimes referred to as a Watchdog or UPDATE record. This is sent when a service has already started and is in progress, but there is updated information to provide in relation to the service.

RESPONSE—This message is sent from the AAA server back to the AAA client with the result of the accounting REQUEST and can contain one of three replies:

SUCCESS—Indicates that the server received the record from the client

ERROR—Indicates an error on the server and that the record was not stored

FOLLOW—Indicates that the server wants the client to send the record to a different AAA server and includes that server’s information in the RESPONSE

Figure 2-5 illustrates an end user being authorized to access the IOS exec CLI. The figure is a direct continuation of Figure 2-4 where the authentication occurred. In this illustration, the end user gets authorized to enter the IOS exec and is authorized to run the show run command. The command the user is requesting to use is contained within the REQUEST (authorization) message.

Figure 2-5 TACACS+ authorization and accounting communication flows.

This concludes the material related to TACACS+ for the purposes of the SISAS exam. For more information on TACACS+, take a look at the Cisco Press book AAA Identity Management Security (ISBN-10 1-58714-1442).

RADIUS

RADIUS is an IETF standard for AAA. As with TACACS+, RADIUS follows a client/server model in which the client initiates the requests to the server. RADIUS is the protocol of choice for network access AAA, and it’s time to get very familiar with RADIUS. If you connect to a secure wireless network regularly, RADIUS is most likely being used between the wireless device and the AAA server. Why? Because RADIUS is the transport protocol for EAP, along with many other authentication protocols.

Originally, RADIUS was used to extend the authentications from the Layer-2 Point-to-Point Protocol (PPP) used between the end user and the Network Access Server (NAS) and carry that authentication traffic from the NAS to the AAA server performing the authentication. This enabled a Layer-2 authentication protocol to be extended across Layer-3 boundaries to a centralized authentication server.

As described earlier in this chapter, RADIUS has evolved far beyond just the dial-up networking use cases it was originally created for. Today it is still used in the same way, carrying the authentication traffic from the network device to the authentication server. With IEEE 802.1X, RADIUS is used to extend the Layer-2 EAP from the end user to the authentication server, as illustrated in Figure 2-6.

Figure 2-6 RADIUS carries the Layer-2 EAP communication.

There are many differences between RADIUS and TACACS+. One such difference is that authentication and authorization are not separated in a RADIUS transaction. When the authentication request is sent to an AAA server, the AAA client expects to have the authorization result sent back in reply.

There are only a few message types with RADIUS authentication and authorization:

Access-Request—This message is sent from the AAA client to the AAA server to request an authentication and authorization. The request could be for network access or for device shell access—RADIUS does not discriminate. The function requested is known as a service type. For example, the service type might be “framed” for an IEEE 802.1X authentication. Some common RADIUS service types are shown in Table 2-2.

Table 2-2 Common RADIUS Service Types

Access-Accept—Sent from the AAA server to the AAA client signaling a passed authentication. The authorization result will be included as AV-pairs. The AV-pairs can include items such as the assigned VLAN, a downloadable access control list (dACL), a security group tag (SGT), and much more.

Access-Reject—Sent from the AAA server to the AAA client signaling the authentication failure. The failed authentication also signifies that no authorization has been granted.

Access-Challenge—This optional message can be sent from the AAA server to the AAA client when additional information is needed, such as a second password for two-factor authentications.

Figure 2-7 illustrates a sample RADIUS flow.

Figure 2-7 RADIUS authentication and authorization communication flows.

When looking at Figure 2-7, keep in mind that authentication and authorization are combined with RADIUS. The Access-Accept message includes the AV-pairs defining what the user is authorized to do.

Only two message types are used in accounting:

Accounting-Request—This message is sent by the AAA client to the AAA server. This can include time, packets, DHCP information, CDP information, and so on. The message can be a START message indicating that service has begun or a STOP message indicating the service has ended.

Accounting-Response—This message acts like an acknowledgement of receipt, so the AAA client knows the accounting message was received by the AAA server.

Figure 2-8 illustrates a sample RADIUS accounting flow. The figure is a direct continuation of Figure 2-7 where the authentication and authorization occurred.

Figure 2-8 RADIUS accounting communication flows.

Unlike TACACS+, RADIUS uses UDP as the transmission protocol. The standard ports used by RADIUS are UDP/1812 for authentication and UDP/1813 for accounting. However, Cisco supported RADIUS before the standard was ratified, and the ports used were UDP/1645 (authentication) and UDP/1646 (accounting). Most Cisco devices will support using either set of ports to ensure backward compatibility.

AV-Pairs

There are references to something called an attribute value pair (AV-pair) all through the TACACS+ and RADIUS sections. When communicating with an AAA protocol, many attributes can be referenced to clearly dictate answers or results. The RADIUS server might be assigning an attribute to the authentication session, such as a VLAN. The VLAN placeholder is the attribute, and the actual assigned VLAN number is the value for that placeholder. The placeholder and its value are paired together and referred to as AV-pairs.

Change of Authorization

Because RADIUS was always defined to be a client server architecture, with the client always initiating the conversation, it became challenging for the AAA server to take action. As RADIUS was defined, the AAA server could only assign an authorization as a result to an authentication request.

As technology advanced, many new demands appeared, including the ability for the network to kick out misbehaving clients, to quarantine them, or basically to just change their access.

How can that happen when the network access is using a RADIUS control plane and the AAA client must always initiate the RADIUS conversations? That is where RFC 3576 and its successor RFC 5176 come in. These RFCs define a new enhancement to RADIUS known as Dynamic Authorization Extensions to RADIUS or, as it is more commonly called, change of authorization (CoA).

CoA is what enables a RADIUS server to initiate a conversation to the network device and disconnect a user’s session, bounce the port (perform a shut/no-shut), or even tell the device to reauthenticate the user. As you learn more about Cisco ISE and the advanced functionality it brings to network access AAA, you will also see how critically important CoA is. For more information regarding CoA, refer to Chapter 6, “Introduction to Advanced Concepts.”

Comparing RADIUS and TACACS+

Table 2-3 is included as a summary to the chapter and to provide you with a reference table for your studies.

Table 2-3 Summary of the Two Main AAA Protocols: RADIUS and TACACS+

Exam Preparation Tasks

Review All Key Topics

Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 2-4 lists a reference of these key topics and the page numbers on which each is found.

Table 2-4 Key Topics for Chapter 2

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

device administration

network access