Sean Butler

April 1996

RIT: ICSA750 Distributed Systems

Introduction

Terminal Access Control Access Control System, or TACACS, was first documented in RFC 927 in December of 1984 as a method of preventing double logins on certain network hosts. It has since evolved into a centralized security system for distributed computing environments with Cisco’s release of TACACS+ in 1995. This paper will review the history and development of TACACS from its inauspicious beginnings to its current state. The focus of the paper will discuss the functionality of the Cisco protocol TACACS+.

Request for Comments: 927

TACACS was first documented as an RFC which described a TELNET option to prevent double logins to a given host. This RFC describes the protocol used between two agents, a TELNET user and a TELNET server.

With two hosts configured to run the TACACS protocol, the user’s host and the TELNET server communicate back and forth with a very small set of messages listed here:

• IAC WILL TUIDThe TELNET user host either tries to authenticate the user on the TELNET server host, or the TELNET server host agrees to authenticate the user trying to establish the connection.
• IAC WON’T TUIDThe TELNET user refuses to authenticate the user.
• IAC DO TUIDThe TELNET server proposes that the TELNET user’s host authenticates the user, or the TELNET server accepts the authentication sent by the TELNET user’s host.
• IAC DON’T TUIDThe TELNET server refuses to authenticate the user.
• IAC SB TUID uuid IAC SEThe TELNET user’s host sends the Universal User ID of the user to the TELNET server.
• WON’T TUIDA TELNET user’s host (the host initiating the session) will respond to DO TUID with this negative reply if it is not running TACACS.
• DON’T TUIDA TELNET server host (the host receiving the session request) that does not implement TACACS will respond with this negative reply to a WILL TUID.

With the TACACS protocol described by this RFC, users are authenticated to hosts before they connect to it by sending correct user names and passwords. Then, to avoid a second login on the same host, the destination host can either allow the authentication or not, based on its own discretion.

The RFC contains several examples of how this version of the TACACS protocol can be used which you can see by clicking on the link above.

Request for Comments: 1492

In July of 1993, RFC 1492 was introduced by the University of Minnesota, to describe a protocol that was used to control which network users could access certain nodes via dial sessions. A node could send a query to a centralized database to authenticate a given username and password. The authentication server would respond with an accept or deny response to the node, so that it would allow or disallow the session request.

RFC 1492 was written with the assistance of Cisco Systems, as the original protocol was not available due to copyright reasons. However, the Cisco implementation the RFC was based on is believed to have been compatible with the original version, and the Cisco version has evolved to the de facto standard, in part because of the RFC. RFC 1492 is an informational document, and was not intended to define a standard.

The basic unit of interaction defined by TACACS in RFC 1492 is the request/response pair. With this pair, a client forwards a request to a server, and all requests must be acknowledged with a response. The RFC describes several types of connections, and each type of connection has a client/server script that may have one or more request response pairs that are used to authenticate the session. These scripts are listed below (note theses are taken directly from the RFC):

• Authenticate only, no connection

             client:  sends an AUTH packet
             server:  responds with a REPLY

• Login connection

             client:  sends a LOGIN packet
             server:  responds with a REPLY
  
             repeat zero or more times:
                     client:  sends a CONNECT packet
                     server:  responds with a REPLY
  
             client:  sends a LOGOUT packet
             server:  responds with a REPLY

• SLIP connection

             client:  sends a LOGIN packet
             server:  responds with a REPLY
  
             repeat zero or more times:
                     client:  sends a CONNECT packet
                     server:  responds with a REPLY
  
             client:  sends a SLIPADDR packet
             server:  responds with a REPLY
  
             repeat zero or more times:
                     client:  sends a CONNECT packet
                     server:  responds with a REPLY
  
             client:  sends a SLIPON packet
             server:  responds with a REPLY
             client:  sends a LOGOUT packet (immediate)
             server:  responds with a REPLY
  
             client:  sends a SLIPOFF packet
             server:  responds with a REPLY

The RFC defines the actual client requests as:

• AUTH(username, password, line, style)This requests asks for the server to authenticate the user. The username and password parameters are obvious, but the line is an indication of which ‘line’ the request is for, in the cases where a host supports multiple access channels, and the style defines what kind of access is to be granted. Style is defined locally on the TACACS server, and, as an example, could be ‘STAFF,’ ‘STUDENT’, ‘ADMIN,’ etc. to define various levels of authorization.
• LOGIN(username, password, line) returns (result1, result2, result3)This requests asks for authentication, and if that is successful, a login connection is started. The parameters correlate to the AUTH request. The results are defined locally and are interpreted based on local meanings. For instance, the result could identify a local access list that might be used for additional authorization.
• CONNECT(username, password, line, destinationIP, destinationPort) returns (result1, result2, result3)This request can only be issued for an already existing connection, and asks for an additional TCP session to the destination IP host and port. The return values are used as they are for the LOGIN request.
• SUPERUSER(username, password, line)This request can only be used for an already existing connection, and is used to allow the user to login to the ‘super user’ state on the host. This Unix state is similar to the ENABLE mode on Cisco routers, where many features of the host can be accessed that are used for administration purposes.
• LOGOUT(username, password, line, reason)Again, this request can only be issued for a pre-existing connection, and indicates that the session should be terminated.
• SLIPON(username, password, line, SLIPaddress) returns (result1, result2, result3)This request can only be issued for an already existing connection, and asks if the SLIPaddress can be used for the remote end of the connection.
• SLIPOFF(username, password, line, reason)This request can only be issued for an already existing connection that is in SLIP mode, and it asks that the connection be terminated.

At the time RFC 1492 was written, most of the above requests and responses were encoded with User Datagram Protocol, the connection less aspect of the TCP/IP protocol suite. The RFC goes into detail on the exact formats of the UDP packets, and which fields and numbers correspond to which TACACS requests. Please see that RFC for more information, as that level of detail is beyond the scope of this paper.

Basically, a client and server authenticate (i.e. permit or deny) session requests using the above requests and responses. The responses are returned as results to the request. This conversation is transported over the TCP/IP network in UDP datagrams, which is connectionless oriented and delivery is not guaranteed, so the client/server application layer must guarantee packet delivery.

The RFC briefly discussed the TCP encoding of TACACS, which was just starting to be used at the time the RFC was written. TCP is now much more commonly used for encoding TACACS. The RFC goes into the same detail for TCP as it does for UDP, as far as describing the TACACS requests and TCP packet format. Please see the RFC for more detail on this aspect of the protocol.

RFC 1492 also explores various problems with the implementation of TACACS as it was at that time, such as the userid and password being carried in plain, non-encrypted format over the network, the fact that only a userid and password are used for authentication, which is already done on hosts, etc. All of these issues are briefly discussed, and possible solutions are given. However, rather than cover those here, we will move on to the TACACS+ product Cisco introduced in 1995, as it addresses all of those issues and more.

TACACS+

TACACS+ is a protocol Cicso Systems introduced in 1995, based on the TACACS protocol described by RFC 1492, which was explored above. It is a network security protocol that supports the “AAA” (pronounced “triple A”) technology. The “A”s stand for authentication, authorization, and accounting. More information on the three A’s will be presented below.

Network Access Security (NAS) is a general protocol system to control who gains access to a network, generally via dial-up sessions, though this is being extended to leased line connections as well. NAS information can be stored directly on a server in an internal database, and forwarded to a centralized database. TACACS+ is a protocol used to exchange NAS information between distributed devices and a centralized database.

Why Centralize?

Client/server computing is all about distributing information and resources across the network. However, once this is done, there are many devices on the network that network users will want access to. For instance, in a router-based network, the support personnel will need access to all routers involved. Each router generally stores and maintains its own set of userids and passwords. Often, many support personnel in one company will share a common userid and password across all routers, but each router still stores and maintains this information locally. If the userid and password need to be changed, each individual router has to be manually updated. However, by storing the password on a single server, it only needs to be changed there, and only needs to be changed once. When a user wants to request access to a router, the router forwards the request to the central server which permits or denies the request.

There are more benefits to centralizing NAS information in general, and to TACACS+ in particular, but first let’s discuss the features of TACACS+.

TACACS+ Features

TACACS+ allows a security administrator to separate the three A’s (authentication, authorization, and accounting) into there components:

• Authentication — Determines who a user is and if they have access to a given service.Simple and advanced authentication schemes are available. Simple schemes include a database of user names and passwords, while more advanced schemes include token card exchange, or additional security software such as Kerberos. Also, for remote (dial) users, once authentication has been granted to access the network, additional authentication may be performed for each service (i.e. router, file server, host, etc.) the users wishes to access.
• Authorization — Once a user is connected, limits what services and capabilities that user has on each system they access.This is primarily necessary to limit users to only services they are allowed to access, but with TACACS+, can be used to limit other features, such as various protocols (Telnet, IP, IPX, etc.) or various portions of the network (for TCP/IP, subnets 1, 2, or 3 for one user, but subnets 2, 3, and 5 for another).
• Accounting — records when and what the user did while connectedThis can be used to actually track users actions when there has been a security breach, and/or can be used to bill users for connection times or amount of data sent and received.

TACACS+ Benefits

Some of the benefits of TACACS+ have already been discussed, but there are many more, some of the important of which are listed below. Many of these benefits built onto the TACACS protocol introduced in RFC1492, and some of them work around problems of RFC1492.

• TACACS+ saves memory in all access devices and eliminates the need to update every access server when new users are added, deleted, or changed, when authorizations are modified, or when passwords are changed. Memory usage can be quite high if every user in the system stores a userid and password on every server in the network. By centralizing this information on a TACACS+ server, the information is stored only once, and not many times.
• Each ‘A’ of the NAS can be sent to different databases to work with that information separately. For instance, the accounting information can be forwarded to a database that bills users for access time, while the authorization information can be retrieved from and stored on a server that runs advanced authorization scripts to permit or deny a user access to various portions of the network.
• TACACS+ supports multiple challenge and response authorization sequences. Administrators can design simple or complex authorization schemes. It also allows other authorization schemes, such as Kerberos, to be used on top of TACACS+. PAP and CHAP authorization schemes can also run with TACACS+. Again, the TACACS+ administrator has complete control over the exact authorization scheme chose.
• TACACS+ offers MD5 encryption, so that userids and passwords (and any other information used in the authorization process), is no longer sent in clear text. If anyone captures the TACACS+ protocol on the network, this information will be unreadable.
• TACACS+ is based on TCP transport, instead of the UDP transport the RFC1492 TACACS protocol was originally based on. RFC1492 did introduce a TCP based TACACS protocol, but it was in its early stages. TCP is the connection based portion of the TCP/IP protocol, and is more secure than UDP and offers fewer accounting errors for transmissions.
• TACACS+ allows the use of multiple independent or backup servers. A user can specify which TACACS+ server to use when logging in. The list of user names and authorizations can be kept consistent across all TACACS+ servers, or they can be kept separate. This flexibility allows for less administration based on the method chosen by the administrator.
• TACACS+ supports per user IP access lists. This allows employees and customers to share access points such as the same rotary for dial connections. It could also be used to allow customers of a VAN network access to certain portions of a router, such as displays, while keeping more advanced access features such as configuration commands segregated for employees.
• TACACS+ can be used to monitor the actions of sessions that are authorized by the protocol. This way, if there is a breach in network security, it will be much easier to track. Start and stop times of sessions can be recorded for billing, or amount of data transfer for a given session could be recorded. This is configurable by the TACACS+ administrator.

Summary

TACACS+ is a security protocol which is built upon the TACACS protocol which was first outlined in RFC927, and later enhanced in RFC1492. It offers a network administrator to centralize authorizations to all of their accessible hosts in the network, and allows for the customization of the authorization scheme. Authorizations can grant different access for each user, and the information TACACS+ records about each session it authorizes can be customized to track session durations, actions, and amount of data transferred. All of this information is beneficial to a network administrator for accounting and security reasons.

References

• Cisco. Single-User Network Access Security TACACS+. 1995. Available at URL http://www.cisco.com/warp/public/614/7.html.
• Cisco Product Announcement. TACACS+ Software 10.3(3). 1995. Available at URL http://www.cisco.com/warp/public/558/42.html.
• Cisco. Cisco IOS Security Architecture. 1995. Available at URL http://www.cisco.com/warp/public/614/9.html.
• Anderson, Brian, Network Working Group. RFC 927: TACACS User Identification Telnet Option. 1984. Available at URL http://info.internet.isi.edu/in-notes/rfc/files/rfc927.txt.
• Finseth, C., Network Working Group. RFC 1492: An Access Control Protocol, Sometimes called TACACS. 1993. Available at URL http://ds.internic.net/rfc/rfc1492.txt.