An Access Control Protocol, Sometimes Called TACACS
RFC 1492
|
Document |
Type |
|
RFC - Informational
(July 1993; No errata)
|
|
Author |
|
Craig Finseth
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy stream
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1492 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text