An Access Control Protocol, Sometimes Called TACACS
RFC 1492

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• rfc1492

Network Working Group                                         C. Finseth
Request for Comments: 1492                       University of Minnesota
                                                               July 1993

          An Access Control Protocol, Sometimes Called TACACS

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Background

   There used to be a network called ARPANET.  This network consisted of
   end nodes (hosts), routing nodes (IMPs) and links.  There were (at
   least) two types of IMPs: those that connected dedicated lines only
   and those that could accept dial up lines.  The latter were called
   "TIPs."

   People being what they were, there was a desire to control who could
   use the dial up lines.  Someone invented a protocol, called "TACACS"
   (Terminal Access Controller Access Control System?), which allowed a
   TIP to accept a username and password and send a query to a TACACS
   authentication server, sometimes called a TACACS daemon or simply
   TACACSD.  This server was normally a program running on a host. The
   host would determine whether to accept or deny the request and sent a
   response back.  The TIP would then allow access or not, based upon
   the response.

   While TIPs are -- shall we say? -- no longer a major presence on the
   Internet, terminal servers are.  Cisco Systems terminal servers
   implement an extended version of this TACACS protocol.  Thus, the
   access control decision is delegated to a host.  In this way, the
   process of making the decision is "opened up" and the algorithms and
   data used to make the decision are under the complete control of
   whoever is running the TACACS daemon.  For example, "anyone with a
   first name of Joe can only login after 10:00 PM Mon-Fri, unless his
   last name is Smith or there is a Susan already logged in."

   The extensions to the protocol provide for more types of
   authentication requests and more types of response codes than were in
   the original specification.

   The original TACACS protocol specification does exist.  However, due
   to copyright issues, I was not able to obtain a copy of this document

Finseth                                                         [Page 1]
RFC 1492                         TACACS                        July 1993

   and this lack of access is the main reason for the writing of this
   document.  This version of the specification was developed with the
   assistance of Cisco Systems, who has an implementation of the TACACS
   protocol that is believed to be compatible with the original
   specification.  To be precise, the Cisco Systems implementation
   supports both the simple (non-extended) and extended versions.  It is
   the simple version that would be compatible with the original.

   Please keep in mind that this is an informational RFC and does not
   specify a standard, and that more information may be uncovered in the
   future (i.e., the original specification may become available) that
   could cause parts of this document to be known to be incorrect.

   This RFC documents the extended TACACS protocol use by the Cisco
   Systems terminal servers.  This same protocol is used by the
   University of Minnesota's distributed authentication system.

1. Protocol Semantics

   This section will describe the requests and responses.  The following
   two sections will describe two different ways of encoding the
   protocol.

   A request/response pair is the basic unit of interaction.  In this
   pair, the client sends a request and the server replies with a
   response.  All requests must be acknowledged with a response.  This
   requirement implies that all requests can be denied, although it is
   probably futile to attempt to deny a "logout" request.

1.1 Connections

   In some cases, a string of request/response pairs forms a larger
   unit, called a "connection."

   There are three types of connections:

   1) Authenticate only, no connection:

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

Finseth                                                         [Page 2]
RFC 1492                         TACACS                        July 1993

   2) 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

   3) 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