SISE (300-715) | AAA, TACACS+ and RADIUS / by MBNE

What is AAA, TACACS+ and RADIUS?

The acronym AAA stands for Authentication, Authorisation and Accounting.

AAA provides a framework for verifying authentication credentials and assigning authorisations (i.e. permissions) to a user on a network, as well as recording the interactions that happen in a given network session.

This framework applies to two types of AAA - Network Access AAA and Device Administration AAA. For both of these types, two distinct things are happening - either you as an end user are trying to access a network (like when you log into your laptop at the office), or network administrators are managing the devices that make up the network.

In simple terms, each component does the following:

  • Authentication - Validates a user identity (i.e. Who are you?)

  • Authorisation - Determines what the validated identity is permitted to do or access (i.e. What are you permitted to see or do?)

  • Accounting - Records transactional data regarding AAA sessions for reporting, logging and troubleshooting. (i.e. Monitoring what you are doing with your authorized access).

Two common AAA protocols twe are going to discuss are TACACS+ and RADIUS. Both of these are considered AAA protocols. You will see that TACACS+ is preferred for Device Administration, whereas RADIUS is better suited for Network Access AAA.

What is the use case for AAA?

There are important reasons for using AAA in a modern computer network, some examples are provided below:

Trust, but Verify

Authentication ensures that an organisation can verify that a user or group of users can be trusted. To trust a user, the user must identify itself somehow - this is achieved by providing some kind of credential, just like when you go to an airport and hand over your passport.

The credentials themselves also need to be trustworthy - an official document signed by a government body (passport) is more trustworthy than a scrap of paper with your name on it. Common types of credentials used in computer networks are usernames and password combinations, tokens or certificates.

Sometimes, addition authentication checks can be completed, to increase the certainty that a given set of credentials is valid. You can do this with Multi-Factor Authentication, which is when a user provides more than one set of credentials to meet authentication requirements.

This is often a combination of credentials such as something you know (a password), something you have (a hardware token) and/or something you are (a fingerprint).

Managing Permissions

Authorisation determines what rights (or permissions) a user or group of users should have, after they are authenticated. An employee who works for your organisation in the Finance team may require access to a secure server, which contains financial data. However, an Employee who works in the Facilities team should not.

Authorisation in the context of ISE is a set of rules and conditions which provides differentiated access to different groups of authenticated users.

Keeping Records

Accounting tracks and records each and every interaction using AAA services, and typically forwards it to the AAA server where it can be stored or exported, examined to troubleshoot problems with AAA operations or used to verify the user interactions with a specific device.

Accounting records are used extensively by ISE to track and monitoring both Device Administration and Network Access AAA.

Using AAA with Cisco ISE and Policy Sets

ISE approaches the AAA framework in a similarly logical manner, splitting Authentication and Authorisation into separate policies, to allow a network administrator to configure differentiated access as required. To facilitate different network use cases, authentications and authorisations are grouped together into Policy Sets.

For example, a Wireless Access Policy Set will have an Authentication Policy and an Authorisation Policy, which determines what kind of Wireless Authentications are permitted for this user and then what kind of Authorisation this authenticated user should receive based on the configured policy rules.

Using this methodology, many different use cases can be configured with the same AAA components facilitating a Network Access Control solution using ISE.

What protocols and components are involved in AAA?

AAA on modern computer networks tends to use two main protocols - TACACS+ and RADIUS. They have some fundamental differences which makes one more suited to Device Administration, and the other better suited to Network Access.

Other important components of AAA include 802.1X, EAP and Change of Authorisation.

AAA Clients and Servers

Both of these protocols essentially fit into the same AAA framework and operate on the same premise - a given user is attempting to access either a network device or a network, and this user needs to be authenticated and authorised to do so.

With TACACS+, a router, a switch, a firewall or another network device that supports TACACS+ is being directly accessed by an end user, such as a network administrator. The network device is considered the AAA Client, managing the authentication and authorisations of the user. The AAA Server could be Cisco ISE or a similar solution which firstly supports TACACS+ messaging, and secondly is responsible for and responding to the requests for authentication and authorisation coming from the AAA Client, on behalf of the user.

With RADIUS, a switch or wireless LAN controller is considered the AAA Client - something that a user device is connected to in the first instance. Again, the AAA Server could be ISE, or something else that provides similar functionality. This time, the client and server supports the RADIUS protocol and again the AAA Server performs authentication and authorisation of the requests from the AAA Client, on behalf of the user.

TACACS+

TACACS+ is designed for Device Administration AAA, primarily for user authentication and authorisation to device consoles and CLI terminals.

TACACS+ supports control over which specific commands could be executed by a given authenticated user. This could mean in practice that a junior network administrator could be allowed to execute a subset of commands on a Cisco switch, but a senior network engineer could be permitted the full capabilities supported by the platform. In other words, TACACS+ facilitates authorisations based on things like your job role and responsibilities, or your organisations security policies.

TACACS+ achieves this by separating the Authentication part of AAA from the Authorisation part. This allows for a single authentication and then multiple authorisations within the same user session. Why is this important? Because in order to provide differentiated, granular access, you must authorise each command that a user attempts to enter into a CLI or console window.

It's important to understand that RADIUS cannot perform this action! A single RADIUS authorisation is expected in the Authentication Response sent from the AAA Server - whereas, TACACS+ supports multiple individual authorisation. This is a key differentiator between the protocols that helped solidify the preferred use cases for both TACACS+ and RADIUS.

TACACS+ uses TCP as the Layer 4 transport method, and uses TCP port 49 to do so. TACACS+ also encrypts the ENTIRE message, whereas RADIUS encrypts only the password.

RADIUS

RADIUS is designed for Network Access AAA, primarily for end user access to computer networks.

RADIUS is a well-supported protocol and an IETF standard for AAA. An important feature of RADIUS is that it operates at Layer 7, inferring that RADIUS traffic can be carried over Layer 3 boundaries. This is a requirement for Centralised AAA as compared to Local AAA.

As opposed to TACACS+, it is key to understand that Authentication and Authorisation are NOT separated out in RADIUS messages. A successful authentication response will contain an authorisation result in the reply. Therefore, RADIUS cannot perform granular authorisations.

RADIUS is also used as a transport protocol for Extensible Authentication Protocol (EAP). EAP is an important Layer 2 protocol that is capable of carrying many types of credentials. EAP information is encapsulated in a RADIUS Attribute-Value Pair (AVP) and forwarded to a AAA Server. This is a key component of how 802.1X utilises centralised AAA Servers that support RADIUS messaging.

RADIUS uses UDP as the Layer 4 transport method, and uses UDP 1812 for Authentication and Authorisation and UDP 1813 for Accounting, or alternatively usrs UDP 1612 for Authentication and Authorisation and UDP 1613 for Accounting (legacy ports).

802.1X

The 802.1X identity management framework is a major topic that really deserves its own post. However, from an AAA perspective, it is a key component of a Network Access Control solution and used extensively with Network Access AAA.

802.1X is concerned with providing a secure method to authorise a user and/or device before it gets access to the network. Users and devices are granted access to the network after they are authenticated. To authenticate, we somehow need to deliver credentials from the endpoint and user to the authentication server. Therefore, a transport mechanism is required to deliver this information.

At Layer 2, we use a protocol called 802.1X as the transport protocol for those credentials. Another related protocol was designed to carry different types of credentials from endpoints, called Extensible Authentication Protocol over LAN (EAPoL), which is a method to transport EAP credentials over a Layer 2 network segment.

802.1X has three basic components that you should understand and remember:

  • Supplicant - This is responsible for creating 802.1X frames and delivering it to the Authenticator.

  • Authenticator - This is the device that receives 802.1X frames, and relays the information to the Authentication Server

  • Authentication Server - This is the system that will perform the authentication of a user or device.

802.1X frames encapsulate the Layer 7 EAP credentials within them.

EAP

Extensible Authentication Protocol (EAP) is also a key component of a modern Network Access AAA. EAP's focus is to be able to carry various types of credentials as it traverses a network.

Unfortunately, EAP by design does NOT provide security to the credentials it is carrying. Therefore, we need to securely tunnel those credentials to protect them, in a secure communication channel - in EAP world, these are known as methods. There are what is known as outer methods and inner methods, which are important concepts to understand regarding how AAA operates with Cisco ISE in today's AAA-enabled network designs.

Simply put, the following is what you should remember about EAP:

Outer method - This is used to build a secure communications channel between the 802.1X supplicant and the authentication server.

  • Protected EAP (PEAP) - This can, for now, be considered as similar to an SSL tunnel.

  • EAP-TLS - This is used when using certificates on both the end client and the authentication server, for mutual authentication.

  • EAP-FAST - This is a Cisco proprietary protocol, only supported by Cisco AnyConnect. It uses PACs, which are similar to RSA tokens.

Inner method - This is used to carry the required credentials themselves.

  • EAP-MSCHAPv2 - A very common protocol used in Windows environments and used with Active Directory.

  • EAP-TLS - This uses certificates and is commonly used with Linux systems.

  • EAP-MD5 - This method is used for IP Phones, printers and other devices that support simple authentication.

  • EAP-TTLS - An extra secure method for mobile devices with certificates.

And, to be clear about the common methods for these use cases, remember the following:

  • For Windows the most common combination is PEAP (outer method) with EAP-MSCHAPv2 (inner method).

  • For Linux, the most common combination is PEAP (outer method) with EAP-TLS or EAP-TTLS (inner method).

  • For Printers, the most common is to use EAP-MD5 only, or use MAC Authentication Bypass (MAB) on ISE.

  • For mobile devices, the most common is to use EAP-TTLS.

Change of Authorisation

Finally, to round off this section, we need to talk about Change of Authorisation (CoA).

CoA is a critical component of how AAA is enforced today. RADIUS was originally defined as a client-server architecture, with the client always initiating the conversation flow. As we learned before, this means that the authorisation is delivered in the authentication response, as RADIUS does not support multiple authorisations. Put simply, the client was king.

Modern networks are far more complicated than those used at the time the RADIUS protocol was introduced. These days, we need to be able to take steps to enforce policy on the network, including the ability to blacklist misbehaving endpoints or users, quarantine endpoints that do not meet security policy requirements, or change their access on the fly as we learn more about them through techniques such as profiling.

To meet these modern requirements, RADIUS was updated to support what are known as Dynamic Authorisation Extensions to RADIUS. In Cisco networks and ISE terminology, we call this Change of Authorisation (CoA).

A Change of Authorisation is used to modify the authorisation policy for an endpoint after the initial request. Typically, without CoA, the RADIUS Access-Request is always originated from the switch or wireless LAN controller (which is the AAA Client). However with CoA, the RADIUS Access-Request can be originated from either the AAA Client or the AAA Server.

This allows the Server to enforce a policy based on changes in the security posture of an endpoint. We don't have to wait for the endpoint to leave the network and reauthenticate before we can do something about its security status. We often enforce actions such as bouncing the switchport, shutting the port down or, as described previously, force the endpoint to reauthenticate, by initiating a new authorisation.

Why is CoA so important? Well, use cases for CoA include initiating a session termination, forcing a reauthentication, performing a posture assessment on the endpoint or to perform profiling. These abilities are key features that CoA allows ISE to perform, significantly improving the capabilities of the network as it relates to AAA.

How does AAA with TACACS+ and RADIUS work?

Now that we have covered what AAA is, where TACACS+ and RADIUS fit in, what the purpose of these protocols are and a simple overview of what they can achieve in a cohesive security design, let's take a closer look at how AAA actually works.

Firstly, we need to differentiate between two AAA deployment methods. AAA services can be deployed in two ways:

Local AAA - This is where the device refers to local copies of identity databases in order to enforce AAA policy. When using Local AAA, any changes to user databases or associated configurations must be individually applied to all the devices you manage. This can be difficult to maintain, especially if you have a large number of devices.

Centralised AAA - This is a preferred deployment method, where devices perform AAA in a distributed manner. Identities are store in a centralised database, such as on an Active Directory server based in a HQ or Data Centre. Other AAA enabled devices in the network communicate with and reference that central database in order to enforce Device Administration AAA or Network Access AAA.

It's possible to configure many Cisco network devices to use both local and centralised AAA methods, so that a device is still able to perform Local AAA if components of a Centralised AAA system are temporarily unavailable.

An example of Centralised AAA in action would be the following common use case - a network administrator logs into a AAA-enabled router with SSH - here's what happens from a TACACS authentication perspective:

  1. The authentication of the SSH session to the Router begins with a TACACS+ START message between the AAA Client and AAA Server. The AAA-enabled Client (Router) has a configuration that allows it to reference a remote identity store (TACACS+ AAA server) to authenticate the SSH connection request.

  2. The TACACS+ AAA server will respond with a TACACS+ REPLY message to the AAA Router which contains a prompt for the end user to provide credentials. This is served to the client from the Router (similar to a proxy).

  3. When the credentials are entered by the user, the AAA Client (Router) sends multiple TACACS+ CONTINUE messages with the credentials required. Again, these are forwarded to the AAA Server where the credentials are checked against the configured Identity Store.

  4. If the authentication challenge is successful, the AAA Server will return a final TACACS+ REPLY message to let the AAA Client know that the authentication succeeded, using an ACCEPT response.

  5. If the AAA Client is configured for AAA Authorisation, as it usually is, then that final REPLY message signals that the TACACS+ authorisation messaging can begin.

At this point, the process moves forward to TACACS+ authorisation and more messages are exchanged relating to authorisation.

TACACS+ Authentication Message Types

To expand on the previous example, let's look at the specific message types for TACACS+.

There are three types of authentication messages exchanged between the Client and Server:

  • START - This message kicks off the TACACS authentication request from AAA Client to AAA Server. It tells the Server to expect an authentication request presently.

  • REPLY - These messages are sent from Server to Client. These are used to challenge the user for their credentials.

  • CONTINUE - These messages are sent from Client to Server. This is what the Client used to respond to the credential challenge.

The final REPLY message from the Server has four possible values contained with it:

  • ACCEPT - Success! Authentication is good, now we can move on if the AAA client is configured for authorisation.

  • REJECT - Denied! Usually the end user can try again, or will simply get a rejection message.

  • ERROR - Some kind of problem occurs. This often results in the authentication starting over once more.

  • CONTINUE - This is a message that the Server sends, not the client. It prompts the user for more information, like additional credentials.

This details the actual flow that happens in the background where TACACS+ is concerned.

TACACS+ Authorisation Message Types

Of course, once a TACACS+ authentication has been successfully completed, one or more TACACS+ authorisations will be needed to grant the permissions for the request from the client.

Two types of authorisation messages are exchanged between the Client and Server:

  • REQUEST - The Client sends this to the Server to request authorisation. The authorisation is otherwise known as a service. Services may be communicated with specific TACACS+ AV Pairs and can typically be things like the IOS Shell service.

  • RESPONSE -The Server sends this to the Client with the result of the authorisation request, including specific details such as the privilege level for the end user.

The final RESPONSE message from the Server has five possible values:

  • FAIL - Whatever service the user asked for, it's not permitted. This request is rejected.

  • PASS_ADD - User is successfully authorised and the requested information is provided. Also, the user should use the information added with the RESPONSE message.

  • PASS_REPL - User is successfully authorised, but the information is NOT provided. Instead, the user should use the information in the RESPONSE message.

  • FOLLOW - Usually this means that another AAA Server should respond to this request - the Client will send the request to the new server.

  • ERROR - Some kind of problem occurs. You might need to troubleshoot.

TACACS+ Accounting Message Types

Finally, there's accounting to consider. Cisco ISE makes extensive use of accounting messages in order to log and track activities on the network.

There are two types of accounting messages exchanged between the Client and Server:

  • REQUEST - Sent from the Client to the Server - this is a notification of an activity that the Server should log.

  • RESPONSE - Sent from the Server to the Client - this is an acknowledgement of the notification sent.

The REQUEST message has three possible values:

  • START - The specified service has begun.

  • STOP - The specified service has ended.

  • CONTINUE - This is used to tell the Server that additional accounting information is pending.

The RESPONSE message has three possible values:

  • SUCCESS - OK! The Server got the request.

  • ERROR - Not OK! Something failed, the Server tells the Client something went wrong.

  • FOLLOW - Usually this means that another AAA Server should be sent the request - the Client will send the request to the new server.

Now let's look at the specific message types for RADIUS.

RADIUS Authentication and Authorisation Message Types

Similar to TACACS+, RADIUS authentication and authorisation flows follow a client-server model with a major difference - authorisations are not separated out from authentications! Instead, authorisations are returned in response to a successful authentication request.

Four types of authentication and authorisation messages are exchanged between a RADIUS Client and RADIUS Server:

  • ACCESS-REQUEST - This request is sent from Client to Server to request both authentication and authorisation. The function requested is known as a RADIUS service type. Service types values could include:

    • Login (Type 1) - Web Auth for non-Cisco equipment

    • Framed (Type 2) - used for 802.1X queries

    • Outbound (Type 5) - used for local web authentication queries

    • Call-Check (Type 10) - used for MAC Authentication Bypass queries

  • ACCESS-ACCEPT - This request is sent from the Server to Client to confirm that the authentication was successful. As you learned before, an authorisation result is included in the response as Attribute Value Pairs. Whatever authorisation you configured AAA to provide to this user, is what it will receive at this point.

  • ACCESS-REJECT - Denied! This is sent from Server to Client because the authentication failed. Without authentication, you can't be authorised, so no authorisation occurs for this users. Typically, the user will be prompted again for credentials.

  • ACCESS-CHALLENGE - This is send from the Server to the Client when additional information is required, such as secondary credentials.

RADIUS Accounting Message Types

Two types of accounting messages are exchanged between Client and Server:

  • ACCOUNTING-REQUEST - These are sent from the AAA Client to AAA Server. This can include various pieces of information relating to the activities of the RADIUS session.

  • ACCOUNTING-RESPONSE - These are sent in response to the accounting requests from Server to Client, indicating that the request has been acknowledged.

That takes care of message types for both TACACS+ and RADIUS!

For the SISE-300-715 exam, I can recommend that candidates become intimately familiar with AAA topics, as they comprise the fundamentals upon which the rest of the Cisco ISE feature set is based upon.

Thanks for reading!