The Terminal Access Controller Access Control System (TACACS) protocol dates back to an earlier era in networking when terminal servers were common. The terminal server was also called a Terminal Access Controller (TAC). So TACACS was the TAC Access Control System.
The TACACS protocol was developed in the early 1980s by a company called BBN, which played a key role in the early development of the Internet (parts of BBN were subsequently absorbed by companies such as Verizon and Cisco). The original protocol only included basic functionality to forward login credentials to a central server, and the ability for the server to respond with a pass or fail on those credentials.
Cisco implemented several extensions to the original TACACS protocol in 1990, and called the new version XTACACS (Extended TACACS), which is described in RFC 1492. However, the IETF considers this RFC to be purely informational, and not an official protocol specification.
More recently, Cisco has replaced both of these earlier versions of TACACS by a newer implementation called TACACS+. The three different versions are not compatible with one another. In fact, Cisco considers the two earlier versions to be obsolete and no longer supports them, although they are still included in the IOS for backward compatibility reasons. This chapter will focus on only the newest TACACS+ version. There is no RFC protocol specification for TACACS+.
It is important to remember that TACACS+ is a Cisco proprietary standard, unlike the competing Remote Authentication Dial In User Service (RADIUS), standard, which is documented in RFC 2865.
TACACS+ uses a TCP transport, on port 49, which makes it more reliable than RADIUS, which uses UDP. RFC 2865 includes a lengthy technical defense of the RADIUS UDP implementation. However, TACACS+ and RADIUS use different implementation models. TACACS+ prefers to get a reliable delivery of data between the client and server, while RADIUS prefers a stateless model that allows it to quickly switch to a backup server.
There are also more tangible benefits to using TACACS+. The biggest real advantage is that TACACS+ allows true command authorization. This means that you can create very clear usage policies with TACACS+, where different users have access to different commands with very fine administrative granularity. TACACS+ can do this because it separates Authentication and Authorization functions, while RADIUS combines them.
Another important advantage is that TACACS+ encrypts the entire payload of the client server exchange. This is important in highly secure environments. RADIUS, on the other hand, only encrypts the password. So intercepting packets can reveal important information.
The strongest point in favor of RADIUS is the fact that it is an open standard implemented by many vendors, including Cisco. Therefore, if you operate a multi-vendor network that already includes RADIUS, you may prefer to use RADIUS with your Cisco routers. This chapter does not specifically cover RADIUS, although many of the concepts discussed here are equally applicable to both TACACS+ and RADIUS.
TACACS+ is part of Cisco's Authentication, Authorization, and Accounting (AAA) framework and works with each of these three functions separately:
Authentication
-
Authentication identifies users by challenging them to provide a username and password. This information can be encrypted if required, depending on the underlying protocol.
Authorization
-
Authorization provides a method of authorizing commands and services on a per user profile basis.
Accounting
-
Accounting functions collect detailed system and command information and store it on a central server, where it can be used for security and quality assurance purposes.
Throughout this chapter, we will discuss some of the most important benefits of using centralized AAA services with TACACS+. These include the ability to administer login IDs from a central server, as well as centrally defining login and command authorizations for each user centrally. This allows for easy grouping of users by their administrative functions. For example, you can give network operators access to one set of commands, web site administrators access to a different set, and still allow network engineers to have full access. In addition, you can define and modify these capabilities centrally so that a particular user has similar capabilities on all routers, without having to configure this separately on each router.