As per Relevance of the word password, we have this rfc below:
Network Working Group C.
Request for Comments: 1492 University of
July 1993
An Access Control Protocol, Sometimes Called
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
There used to be a network called ARPANET. This network consisted
end nodes (hosts), routing nodes (IMPs) and links. There were (
least) two types of IMPs: those that connected dedicated lines
and those that could accept dial up lines. The latter were
"TIPs."
People being what they were, there was a desire to control who
use the dial up lines. Someone invented a protocol, called "TACACS
(Terminal Access Controller Access Control System?), which allowed
TIP to accept a username and password and send a query to a
authentication server, sometimes called a TACACS daemon or
TACACSD. This server was normally a program running on a host.
host would determine whether to accept or deny the request and sent
response back. The TIP would then allow access or not, based
the response
While TIPs are -- shall we say? -- no longer a major presence on
Internet, terminal servers are. Cisco Systems terminal
implement an extended version of this TACACS protocol. Thus,
access control decision is delegated to a host. In this way,
process of making the decision is "opened up" and the algorithms
data used to make the decision are under the complete control
whoever is running the TACACS daemon. For example, "anyone with
first name of Joe can only login after 10:00 PM Mon-Fri, unless
last name is Smith or there is a Susan already logged in."
The extensions to the protocol provide for more types
authentication requests and more types of response codes than were
the original specification
The original TACACS protocol specification does exist. However,
to copyright issues, I was not able to obtain a copy of this
Finseth [Page 1]
RFC 1492 TACACS July 1993
and this lack of access is the main reason for the writing of
document. This version of the specification was developed with
assistance of Cisco Systems, who has an implementation of the
protocol that is believed to be compatible with the
specification. To be precise, the Cisco Systems
supports both the simple (non-extended) and extended versions. It
the simple version that would be compatible with the original
Please keep in mind that this is an informational RFC and does
specify a standard, and that more information may be uncovered in
future (i.e., the original specification may become available)
could cause parts of this document to be known to be incorrect
This RFC documents the extended TACACS protocol use by the
Systems terminal servers. This same protocol is used by
University of Minnesota's distributed authentication system
1. Protocol
This section will describe the requests and responses. The
two sections will describe two different ways of encoding
protocol
A request/response pair is the basic unit of interaction. In
pair, the client sends a request and the server replies with
response. All requests must be acknowledged with a response.
requirement implies that all requests can be denied, although it
probably futile to attempt to deny a "logout" request
1.1
In some cases, a string of request/response pairs forms a
unit, called a "connection."
There are three types of connections
1) Authenticate only, no connection
client: sends an AUTH
server: responds with a
Finseth [Page 2]
RFC 1492 TACACS July 1993
2) Login connection
client: sends a LOGIN
server: responds with a
repeat zero or more times
client: sends a CONNECT
server: responds with a
client: sends a LOGOUT
server: responds with a
3) SLIP connection
client: sends a LOGIN
server: responds with a
repeat zero or more times
client: sends a CONNECT
server: responds with a
client: sends a SLIPADDR
server: responds with a
repeat zero or more times
client: sends a CONNECT
server: responds with a
client: sends a SLIPON
server: responds with a
client: sends a LOGOUT packet (immediate
server: responds with a
client: sends a SLIPOFF
server: responds with a
1.2
This section lists the requests supported by the protocol.
responses are described in the later encodings sections
AUTH(username, password, line, style
This request asks for an authentication. The parameters are
Finseth [Page 3]
RFC 1492 TACACS July 1993
- the
- the
- an indication of which line the request is for,
- a style of
The username is a string that identifies the user. In principle
it can be of any length and contain any characters. In practice
it should be no longer than 128 characters and should contain
the ASCII characters "!" (33 decimal) through "~" (126 decimal),
inclusive
The password is a string that is used to authenticate the
identified by the username. In principle, it can be of any
and contain any characters. In practice, it should be no
than 128 characters and should contain only the ASCII
"!" (33 decimal) through "~" (126 decimal), inclusive
The line is a non-negative decimal integer. If the
supports multiple physical access channels, this value
the particular channel. By convention, lines are
starting from one, although this should be taken with a grain
salt. For example, Cisco Systems' implementation uses zero
designate the console port, then continues with one for the "main
serial lines. Clients that support only one channel should
line zero
The authentication style is a possibly empty string.
identifies the particular style of authentication to be performed
Its syntax and semantics are local
Example
AUTH("fin@unet.umn.edu", "fake-password", 0, "staff")
This specifies a username of "fin@unet.umn.edu" (which happens
be my e-mail address), a password, an indication that no line
associated with this request, and a style of "staff".
semantics for this style might be that I am required to be a
member (in addition, of course, to supplying a valid username
password). The server would presumably consult an
database to verify the staff status
As a local option, the implementation may choose to encode
style information by using alternate port numbers. E.g. port 4001
would mean style 1, 4002 would be style 2, etc
Note that the AUTH request type cannot be sent using the
encoding
Finseth [Page 4]
RFC 1492 TACACS July 1993
LOGIN(username, password, line) returns (result1, result2, result3)
This request asks for an authentication and signals that -- if
authentication succeeds -- a login connection is starting.
parameters are
- the
- the
- an indication of which line the request is
The meanings of the input fields are the same as the AUTH request
If the request is successful, this request returns three
values in addition to the success status. The result values
non-negative integers. Their interpretation is local.
example, Cisco Systems terminal servers interpret result3 to
the identifier of a local access list to use for
validation
CONNECT(username, password, line, destinationIP, destinationPort
returns (result1, result2, result3)
This request can only be issued when the username and line
an already-existing connection. As such, no authentication
required and the password will in general be the empty string.
asks, in the context of that connection, whether a TCP
can be opened to the specified destination IP address and port
The return values are as for LOGIN
SUPERUSER(username, password, line
This request can only be issued when the username and line
an already-existing connection. As such, no authentication
required and the password will in general be the empty string.
asks, in the context of that connection, whether the user can
into "super-user" or "enable" mode on the terminal server
As an example of the flexibility inherint in this whole scheme
the TACACSD supplied by Cisco Systems ignores the username
and instead checks wether the password matches that of the
user "$enable$".
LOGOUT(username, password, line, reason
This request can only be issued when the username and line
an already-existing connection. As such, no authentication
required and the password will in general be the empty string.
indicates that the connection should be terminated (but
Finseth [Page 5]
RFC 1492 TACACS July 1993
SLIPON). It must be acknowledged, but the success/fail status
the acknowledgment is irrelevant. The reason value indicates
the connection is terminating. A null reason value is
when the connection is going into SLIP mode
SLIPON(username, password, line, SLIPaddress) returns (result1,
result2, result3)
This request can only be issued when the username and line
an already-existing connection. As such, no authentication
required and the password will in general be the empty string.
asks, in the context of that connection, whether the
SLIPaddress can be used for the remote end of the connection
If the server replies with a success, the client can proceed to
SLIPON request. (It need not do so right away, however.)
Note that semantics of "username" can get hairy. For example,
Cisco Systems implementation encodes information in this way
- If the user just requested the default address be assigned,
field holds the username in lower case
- If the user requested a specific IP address or host name for
SLIP connection, this field contains the requested host name
UPPER case
If the server replies with a success, the client will
send a LOGOUT request. However, the connection will
established until a SLIPOFF request is sent. No
authentication requests will be sent for that connection
SLIPaddress specifies the IP address used by the remote host.
a SLIPADDR request has been made, it will be that address
Otherwise, it will be the default address assigned by the
(e.g., Cisco terminal server).
The return values are as for LOGIN
SLIPOFF(username, password, line, reason
This request can only be issued when the username and line
an already-existing connection that is in "SLIP" mode. As such
no authentication is required and the password will in general
the empty string. It indicates that the connection should
terminated. It must be acknowledged, but the success/fail
of the acknowledgment is irrelevant. The reason value
why the connection is terminating
Finseth [Page 6]
RFC 1492 TACACS July 1993
2.0 UDP Encoding:
This section describes the UDP encoding of the requests that
just been described. It also describes the responses. This
encoding forms the basis of the historical TACACS protocol
This protocol uses port 49. This assignment continues to
confirmed by the IANA in the Assigned Numbers RFCs. (I can't
that it was assigned by the IANA as the assignment preceded
organization.)
The basic packet format is shown here. All multi-bytes values are
network byte order. Unless otherwise specified, all values given
in decimal. Unused fields should be set to zero, but the
should not depend on that setting
As was mentioned earlier, there are both simple and extended forms
of which the simple form is a proper subset of the extended form.
server should support both. I will describe both forms in parallel
Simple
The fields are
offset length
0 1
1 1
2 2 nonce
4 1 username length (to server) / response (to client
5 1 password length (to server) / reason (to client
in the usual packet layout format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Version : Type : Nonce :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: User len/Resp : PW len/Reason : data... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Finseth [Page 7]
RFC 1492 TACACS July 1993
Extended
The fields are
offset length
0 1
1 1
2 2 nonce
4 1 username
5 1 password
6 1
7 1
8 4 result
12 4 destination host, IP
16 2 destination
18 2
20 4 result
24 2 result
26 varies data: username +
in the usual packet layout format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Version : Type : Nonce :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: User len : Password len : Response : Reason :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Result 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Destination Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Dest Port : Line :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Result 2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Result 3 : data... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1
The VERSION field specifies the version number. It must be zero
simple or 128 (80 hexadecimal) for extended
Finseth [Page 8]
RFC 1492 TACACS July 1993
The TYPE field encodes the request type. Values are
LOGIN 1
RESPONSE 2 (server to client only
CHANGE 3
FOLLOW 4
CONNECT 5
SUPERUSER 6
LOGOUT 7
RELOAD 8
SLIPON 9
SLIPOFF 10
SLIPADDR 11
Other values below 128 are reserved for future use. Values from 128
to 255 are reserved for local use
Note that the semantics of the CHANGE, FOLLOW, RELOAD requests
not been determined
The NONCE field is set by the client to an arbitrary value.
purpose is to allow clients that may have multiple
requests to determine which request a response is for. The
must copy this value to the reply unaltered
The USERNAME LENGTH field is set by the client to the length of
username in characters. Legal values are 0 to 255, inclusive.
server must copy this value to the reply unaltered
The PASSWORD LENGTH is set by the client to the length of
password in characters. Legal values are 0 to 255, inclusive.
server must copy this value to the reply unaltered
The RESPONSE field should be set by the client to zero. The
sets the value to one of
value
1
2
Other values below 128 are reserved for future use. Values from 128
to 255 are reserved for local use
Finseth [Page 9]
RFC 1492 TACACS July 1993
The REASON field should be set by the client to zero, except
LOGOUT and SLIPOFF requests, which may use values of 4, 5, or 6.
server sets the value to one of
value meaning
0 none used for ACCEPTED or if the
is
1
2
3
4 quit user quit
5 idle idle
6 drop carrier
7 bad too many bad
The values from 4 to 6 will only be used for reasons for LOGOUT
SLIPOFF requests: they will not be returned by the server.
values below 128 are reserved for future use. Values from 128 to 255
are reserved for local use
The RESULT1 field should be set by the client to zero. For LOGIN
CONNECT requests, it is set by the server as specified in the
description. For all other requests, it should be set by the
to zero
The DESTINATION HOST field is set by the client. On CONNECT, SLIPON
and SLIPOFF requests it specifies an IP address. It should be set
zero on all other requests. For SLIPON and SLIPOFF request,
value should be the IP address assigned to the line. For
requests, this value is the IP address of the host that the user
attempting to connect to. The server copies this value to the reply
The DESTINATION PORT field is set by the client. On CONNECT
it specifies the port number that the user is attempting to
to. It should be set to zero on all other requests. The
copies this value to the reply
The LINE field is set by the client to the line number that
request is for. The server copies this value to the reply
The RESULT2 field should be set by the client to zero. For LOGIN
CONNECT requests, it is set by the server as specified in the
description. For all other requests, it should be set by the
to zero
The RESULT3 field should be set by the client to zero. For LOGIN
CONNECT requests, it is set by the server as specified in the
Finseth [Page 10]
RFC 1492 TACACS July 1993
description. For all other requests, it should be set by the
to zero
The DATA field contains just the text of the username and password
with no separator characters (you use username length and
length to sort them out). The server does not copy the values to
reply. (However, the server does copy the username length
password length fields to the reply.) The username data may be
upper case: comparisons should be case-insensitive
2.2 What a Client
The client must format and send a UDP request to port 49.
constructs the request by following these steps
- set the version to 128
- set the type to that of the
- set the nonce to a unique value that is different from
outstanding
- set the username
- set the password
- set the response to
- set the reason to zero (except for LOGOUT and SLIPOFF
- set the result1 to
- if CONNECT, SLIPON, or SLIPOFF, set the destination
to the IP address, otherwise set it to
- if CONNECT, set the destination port to the port,
set it to
- set the
- set the result2 to
- set the result3 to
- copy the username to the location just after result
- copy the password to the location just after the end of
Send the request. Wait for a reasonable (and hopefully configurable
period of time. If no response has been received, retry a
(and hopefully configurable) number of times. Reasonable
wait times are 5 seconds and retries are 2.
If a response has been received, use the nonce value (and as
other fields as you like) to match it to an outstanding request.
there is no matching outstanding request, take appropriate (
hopefully configurable) action such as discarding and/or logging
packet
If the response matches an outstanding request, examine the
and reason codes and take whatever action you deem correct.
Finseth [Page 11]
RFC 1492 TACACS July 1993
responses to LOGIN and CONNECT requests, also incorporate
result1, result2, and result3 values as you deem correct
2.3 What a Server
Upon receipt of a UDP format request, the server examines the data
the request packet and determines its response. It constructs
reply by following these steps
- set the version to 128
- set the type to RESPONSE (2)
- copy the nonce
- copy the username length
- copy the password length
- set the response value to the desired
- set the reason value to the desired
- if LOGIN or CONNECT, set the result1 else zero the result
- copy the destination host
- copy the destination port
- copy the line
- if LOGIN or CONNECT, set the result2 else zero the result
- if LOGIN or CONNECT, set the result3 else zero the result
- do NOT copy the username or password
(As always, be liberal in what you expect and conservative in
you send.) Send the response. Do not attempt to retry, as you
no basis for determining whether a retry is required. Any
are up to the client. This, of course, implies that requests
idempotent. They aren't, of course, so the retries must
considered when trying to assemble requests into connections
3.0 TCP
This section describes the TCP encoding of the requests
responses. This encoding is not compatible with the
TACACS protocol. However, it is somewhat more "modern" in that
has been updated to provide for current feature needs
This protocol does not use a reserved port. Instead, it must
possible to configure the ports used by both the the client
server
The basic request format is shown here. The request consists of
lines of ASCII text. All numeric values are expressed in ASCII
decimal integers
Finseth [Page 12]
RFC 1492 TACACS July 1993
<parameters
<username
<password
Each line in the example corresponds to one line of text. That is
the lines are separated with / (13/10 decimal) pairs. In
event may "bare" or characters appear within a field.
addition, (0 decimal) characters may not be sent
The and fields are separated with one or
(32 decimal) or (9 decimal) characters
The <parameters> field is optional. If present, it is separated
the field and internal parameters separated from each other
or more or characters. Any trailing or
characters present on this line should be ignored by the server:
should not be taken to imply a trailing empty field
In theory there are no line length limits. In practice, lines
not exceed 255 characters (counting the and ) and
should be 80 characters or less
3.1
The VERSION field specifies the version number. It must be 1.
values below 128 are reserved for future use. Values from 128 to 255
are reserved for local use
The TYPE field encodes the request type. Values are
I.e., the keyword simply encodes itself. It must be in upper case
Keywords that begin with the letter "X" are reserved for local use
The USERNAME field contains the text of the username. Leading
trailing or characters are considered significant.
username data may be in upper case: comparisons should be case
insensitive
The PASSWORD field contains the text of the password. Leading
Finseth [Page 13]
RFC 1492 TACACS July 1993
trailing or characters are considered significant
The LINE field is set by the client to the line number that
request is for
3.2
Appendix E of STD 10, RFC 821 describes the general theory of
codes. The this protocol follows the format described in
document. In a nutshell, replies are of the form
Where is a three-digit decimal value and is
arbitrary text string, presumably containing only printing
characters ( (32 decimal) through "~" (126 decimal)). At
one (32 decimal) character separates the number from the text
A / sequence follows the text
The three digit codes completely determine the response. The
should be considered an explanatory comment for human understanding
However, even without knowing all values, the first digit can be
to determine the overall nature of the response. The encodings are
1 Positive Preliminary: the request is acceptable
but no action will be taken until an
request is made (not used in this version of
protocol
2 Positive
3 Positive Intermediate: the request is
so far, but has not been completely
(not used in this version of the protocol
4 Transient Negative: the request is not
for now. It is acceptable to retry, as
instance may have a different result
5 Permanent Negative: the request is not
The text portion is optional (i.e., may be the empty string) and
describes the meaning of the message in human readable form
Finseth [Page 14]
RFC 1492 TACACS July 1993
While different server implementations will result in
messages, the following are suggested
201 accepted: # # #
202 accepted, password is expiring: # # #
401 no response;
501 invalid
502 access
The ": # # #" in the first two messages is the suggested way
returning the three result codes for LOGIN and CONNECT requests
3.3 What a Client
The client opens a TCP connection to the locally-configured
and port. It sends the request by sending
- the character "1"
- one or more or
- the request type as an ASCII
- if an AUTH, send one or more or
and the authentication
- if a CONNECT, SLIPON, or SLIPOFF, send one or more
or characters and the IP address in dotted
- if a CONNECT, send one or more or
and the port number in
- a /
- the username (or hostname for SLIPADDR
- a /
- the
- a /
- the
- a /
Then read one line from the connection and close the connection
This encoding lets TCP take care of waiting, retries, and matching
requests and responses
Examine the response line and take whatever action you deem correct
3.4 What the Server
The server waits on the locally-specified port for requests.
one is made, it reads four lines of input
It examines the first line for a valid version number and request
It also records any optional parameters
Finseth [Page 15]
RFC 1492 TACACS July 1993
It uses the username, password, and line number along with any
information it deems fit to determine its response
It then sends exactly one line of response, terminated by
/, and closes the connection
4.0 Pros and
Advantages to using the UDP format
- lower
- compatible with historical
- some existing equipment supports
Advantages to using the TCP format
- easier to implement, especially on machines with no
poor UDP
- simpler, cleaner
- potentially wider range of error codes, and support
temporary and negotiated authentication
5.0 Security
While the protocol itself has been described, there are a number
other considerations worth mentioning
First, the protocol carries the username and password in clear
in either a single UDP packet or a TCP stream. As such, if
attacker is capable of monitoring that data, the attacker
capture username/password pairs. Implementations can take
steps to minimize this danger
- Use point-to-point links where possible
- Physically secure the transmission medium
- If packets must traverse multiple network segments, use a
routing subsystem. This implies
- Tight control over router configurations
- Tight control over routing protocols
- Avoid use of bridges, as they can be silently fooled
duplicating packets
Second, this protocol potentially opens up a new way of
usernames and passwords. Thus, implementations may wish to
Finseth [Page 16]
RFC 1492 TACACS July 1993
servers
- limit responses to a controlled list of clients
- throttle the rate of responding to requests
- log all failures (and possibly successes, too).
Third, this protocol essentially allows clients to
accept/reject decisions to servers. While an obvious
would simply use the server's native login mechanism to make
determination, there is no reason to limit implementations to
mechanism. Servers could
- use alternate lists of accounts (e.g., password files),
- use alternate mechanisms for accessing the accounts (e.g.,
a database, NIS),
- use alternate algorithms (e.g., SecureID cards),
- translate the request to another protocol and use
protocol to make the determination (e.g., Kerberos).
Fourth, the use of a "fanout" server (described in the next section
allows for
- centralized logging of usage for attack
- centralized policy
- ability to block selected specific
- ability to block selected user names (e.g., don'
allow "root" or "guest")
- ability to block poor passwords (e.g., none or weak
6.0 Case
This section presents the basic steps used by the implementation
the University of Minnesota. Two examples will be used. The
is a basic terminal login. The second is a database
verification
Usernames are in one of three forms
First.M.Last-#@umn.
First.M.Last-#
user@
A name in the first form is converted to one in the second
A name in the second form is looked up in the University-
directory system. If found, the associated electronic mail
is treated as if the third form was entered
Finseth [Page 17]
RFC 1492 TACACS July 1993
The third form specifics the name of a computer whose manager
agreed to perform validations and the name of an account on
computer
The system that we use allows for many requesting clients (
modem pools). Further, each client can support multiple
pools of users. For example, lines 1-20 could be general access,
lines 21-25 could be 800-numbers with a restricted set of
users. The system supports this distinction by specifying
validation computers are legal for each modem pool
6.1 Terminal
On the Cisco Terminal Server
- accept a
- request a username and
- pack the request into a UDP TACACS packet and send to the
Central Fanout
- accept a
- if the request is not in a valid format, return "nope
- log the
- if the source IP address is not in a list of valid clients
status = "nope
- else if the username contains invalid characters, status = "nope
-
if the username is of the form First.M.Last-#@umn.edu
convert to First.M.Last-#
if the username is of the form First.M.Last-#,
look up the name in the
if the name is not found, status = "nope
otherwise, use the e-mail address as the
if the user is on a special "blocked" list, status = "nope
and send mail warning that access to a
account was
split the username into user and host
if the host is not on a list of known servers
status = "nope
else if the host is not allowed to validate this type
request for this pool, status = "nope
now format a request for validation of the user and send
to the specified
Finseth [Page 18]
RFC 1492 TACACS July 1993
if no response, status = "nope
otherwise set the status to the returned
- log what response is going to be
- return the
Validation Host
This machine can run a "stripped down" version of the central fanout
It need perform no special validation or logging, with one exception
- accept a
- if the request is not in a valid format, return "nope
- if the request is not from the central fanout, return "nope
- figure the return
- return the
6.2 Database Access
In this example, assume that a database is only to be accessed
faculty and staff
Mainframe
- the user is on the mainframe and makes a
- the program requests username and
- the program packs the request into a UDP TACACS packet and send
the central
Central Fanout
- accept a
- if the request is not in a valid format, return "nope
- log the
- if the source IP address is not in a list of valid clients
status = "nope
- else if the username contains invalid characters, status = "nope
-
if the username is of the form First.M.Last-#@umn.edu
convert to First.M.Last-#
if the username is of the form First.M.Last-#,
look up the name in the
if the name is not found, status = "nope
otherwise, use the e-mail address as the
and obtain the staff status from the
if the user is on a special "blocked" list, status = "nope
and send mail warning that access to a
account was
Finseth [Page 19]
RFC 1492 TACACS July 1993
split the username into user and host
if the host is not on a list of known servers
status = "nope
else if the host is not allowed to validate this type
request for this pool, status = "nope
now format a request for validation of the user and send
to the specified
if no response or status is "nope", status = "nope
else if the user originally gave a user@host mail address
do a directory lookup and obtain the staff
set the status to the staff
- log what response is going to be
- return the
Note that the validation host is unchanged
[RFC821] Postel, J. "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers," STD 2,
1340, USC/Information Sciences Institute, July 1992.
Anderson, Brian; Ruth, Greg; Ditmars, Peter; Eisner, Sharon
Delsignore, John (1985) TAC Access Control System Protocols,
Edition: August 16 1985. BBN Tech Memo CC-0045.
Cisco Systems, Inc. (September 1992) Communications
Configuration and Reference. Menlo Park, California
Finseth [Page 20]
RFC 1492 TACACS July 1993
Security
Security issues are the main topic of this memo
Author's
Craig A.
Networking
Computer and Information
University of
130 Lind
207 Church St
Minneapolis MN 55455-0134
Phone: +1 612 624 3375
Fax: +1 612 626 1002
EMail: Craig.A.Finseth-1@umn.edu,
fin@unet.umn.
Finseth [Page 21]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
