doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc1492.txt b/doc/rfc/rfc1492.txt
new file mode 100644
index 0000000..e170e28
--- /dev/null
+++ b/doc/rfc/rfc1492.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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
+
+           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
+
+1.2 Requests
+
+   This section lists the requests supported by the protocol.  The
+   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 username
+              - the password
+              - an indication of which line the request is for, and
+              - a style of authentication
+
+      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 only
+      the ASCII characters "!" (33 decimal) through "~" (126 decimal),
+      inclusive.
+
+      The password is a string that is used to authenticate the user
+      identified by the username.  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 only the ASCII characters
+      "!" (33 decimal) through "~" (126 decimal), inclusive.
+
+      The line is a non-negative decimal integer.  If the client
+      supports multiple physical access channels, this value identifies
+      the particular channel.  By convention, lines are numbered
+      starting from one, although this should be taken with a grain of
+      salt.  For example, Cisco Systems' implementation uses zero to
+      designate the console port, then continues with one for the "main"
+      serial lines. Clients that support only one channel should use
+      line zero.
+
+      The authentication style is a possibly empty string.  It
+      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 to
+      be my e-mail address), a password, an indication that no line is
+      associated with this request, and a style of "staff".  The
+      semantics for this style might be that I am required to be a staff
+      member (in addition, of course, to supplying a valid username and
+      password).  The server would presumably consult an external
+      database to verify the staff status.
+
+      As a local option, the implementation may choose to encode the
+      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 UDP
+      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 the
+      authentication succeeds -- a login connection is starting.  The
+      parameters are:
+
+      - the username
+      - the password
+      - an indication of which line the request is for
+
+      The meanings of the input fields are the same as the AUTH request.
+      If the request is successful, this request returns three result
+      values in addition to the success status.  The result values are
+      non-negative integers.  Their interpretation is local.  For
+      example, Cisco Systems terminal servers interpret result3 to be
+      the identifier of a local access list to use for additional
+      validation.
+
+   CONNECT(username, password, line, destinationIP, destinationPort)
+   returns (result1, result2, result3)
+
+      This request can only be issued when the username and line specify
+      an already-existing connection.  As such, no authentication is
+      required and the password will in general be the empty string. It
+      asks, in the context of that connection, whether a TCP connection
+      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 specify
+      an already-existing connection.  As such, no authentication is
+      required and the password will in general be the empty string.  It
+      asks, in the context of that connection, whether the user can go
+      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 part
+      and instead checks wether the password matches that of the special
+      user "$enable$".
+
+   LOGOUT(username, password, line, reason)
+
+      This request can only be issued when the username and line specify
+      an already-existing connection.  As such, no authentication is
+      required and the password will in general be the empty string.  It
+      indicates that the connection should be terminated (but see
+
+
+
+Finseth                                                         [Page 5]
+
+RFC 1492                         TACACS                        July 1993
+
+
+      SLIPON).  It must be acknowledged, but the success/fail status of
+      the acknowledgment is irrelevant.  The reason value indicates why
+      the connection is terminating.  A null reason value is supplied
+      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 specify
+      an already-existing connection.  As such, no authentication is
+      required and the password will in general be the empty string.  It
+      asks, in the context of that connection, whether the specified
+      SLIPaddress can be used for the remote end of the connection.
+
+      If the server replies with a success, the client can proceed to a
+      SLIPON request.  (It need not do so right away, however.)
+
+      Note that semantics of "username" can get hairy.  For example, the
+      Cisco Systems implementation encodes information in this way:
+
+      - If the user just requested the default address be assigned, this
+      field holds the username in lower case.
+
+      - If the user requested a specific IP address or host name for the
+      SLIP connection, this field contains the requested host name in
+      UPPER case.
+
+      If the server replies with a success, the client will immediately
+      send a LOGOUT request.  However, the connection will remain
+      established until a SLIPOFF request is sent.  No other
+      authentication requests will be sent for that connection.
+
+      SLIPaddress specifies the IP address used by the remote host.  If
+      a SLIPADDR request has been made, it will be that address.
+      Otherwise, it will be the default address assigned by the client
+      (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 specify
+      an already-existing connection that is in "SLIP" mode.  As such,
+      no authentication is required and the password will in general be
+      the empty string.  It indicates that the connection should be
+      terminated.  It must be acknowledged, but the success/fail status
+      of the acknowledgment is irrelevant.  The reason value indicates
+      why the connection is terminating.
+
+
+
+Finseth                                                         [Page 6]
+
+RFC 1492                         TACACS                        July 1993
+
+
+2.0 UDP Encoding: TACACS
+
+   This section describes the UDP encoding of the requests that have
+   just been described.  It also describes the responses.  This UDP
+   encoding forms the basis of the historical TACACS protocol.
+
+   This protocol uses port 49.  This assignment continues to be
+   confirmed by the IANA in the Assigned Numbers RFCs.  (I can't say
+   that it was assigned by the IANA as the assignment preceded the
+   organization.)
+
+   The basic packet format is shown here.  All multi-bytes values are in
+   network byte order.  Unless otherwise specified, all values given are
+   in decimal.  Unused fields should be set to zero, but the recipient
+   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.  A
+   server should support both.  I will describe both forms in parallel.
+
+   Simple Form
+
+   The fields are:
+
+      offset       length  field
+
+      0    1       version
+      1    1       type
+      2    2       nonce value
+      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 Form
+
+   The fields are:
+
+           offset  length  field
+
+           0       1       version
+           1       1       type
+           2       2       nonce value
+           4       1       username length
+           5       1       password length
+           6       1       response
+           7       1       reason
+           8       4       result1
+           12      4       destination host, IP address
+           16      2       destination port
+           18      2       line
+           20      4       result2
+           24      2       result3
+           26      varies  data: username + password
+
+   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 Fields
+
+   The VERSION field specifies the version number.  It must be zero for
+   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 have
+   not been determined.
+
+   The NONCE field is set by the client to an arbitrary value.  Its
+   purpose is to allow clients that may have multiple outstanding
+   requests to determine which request a response is for. The server
+   must copy this value to the reply unaltered.
+
+   The USERNAME LENGTH field is set by the client to the length of the
+   username in characters.  Legal values are 0 to 255, inclusive. The
+   server must copy this value to the reply unaltered.
+
+   The PASSWORD LENGTH is set by the client to the length of the
+   password in characters. Legal values are 0 to 255, inclusive. The
+   server must copy this value to the reply unaltered.
+
+   The RESPONSE field should be set by the client to zero.  The server
+   sets the value to one of:
+
+           value   meaning
+
+           1       accepted
+           2       rejected
+
+   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 for
+   LOGOUT and SLIPOFF requests, which may use values of 4, 5, or 6.  The
+   server sets the value to one of:
+
+           value   meaning         notes
+
+           0       none            used for ACCEPTED or if the server
+                                   is ornery
+           1       expiring
+           2       password
+           3       denied
+           4       quit            user quit normally
+           5       idle            idle timeout
+           6       drop            carrier dropped
+           7       bad             too many bad passwords
+
+   The values from 4 to 6 will only be used for reasons for LOGOUT or
+   SLIPOFF requests: they will not be returned by the server.  Other
+   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 or
+   CONNECT requests, it is set by the server as specified in the request
+   description.  For all other requests, it should be set by the server
+   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 to
+   zero on all other requests.  For SLIPON and SLIPOFF request, this
+   value should be the IP address assigned to the line.  For CONNECT
+   requests, this value is the IP address of the host that the user is
+   attempting to connect to.  The server copies this value to the reply.
+
+   The DESTINATION PORT field is set by the client.  On CONNECT requests
+   it specifies the port number that the user is attempting to connect
+   to.  It should be set to zero on all other requests. The server
+   copies this value to the reply.
+
+   The LINE field is set by the client to the line number that the
+   request is for.  The server copies this value to the reply.
+
+   The RESULT2 field should be set by the client to zero.  For LOGIN or
+   CONNECT requests, it is set by the server as specified in the request
+   description.  For all other requests, it should be set by the server
+   to zero.
+
+   The RESULT3 field should be set by the client to zero.  For LOGIN or
+   CONNECT requests, it is set by the server as specified in the request
+
+
+
+Finseth                                                        [Page 10]
+
+RFC 1492                         TACACS                        July 1993
+
+
+   description.  For all other requests, it should be set by the server
+   to zero.
+
+   The DATA field contains just the text of the username and password,
+   with no separator characters (you use username length and password
+   length to sort them out).  The server does not copy the values to the
+   reply. (However, the server does copy the username length and
+   password length fields to the reply.) The username data may be in
+   upper case: comparisons should be case-insensitive.
+
+2.2 What a Client Does
+
+   The client must format and send a UDP request to port 49.  It
+   constructs the request by following these steps:
+
+           - set the version to 128
+           - set the type to that of the request
+           - set the nonce to a unique value that is different from all
+             outstanding requests
+           - set the username length
+           - set the password length
+           - set the response to zero
+           - set the reason to zero (except for LOGOUT and SLIPOFF)
+           - set the result1 to zero
+           - if CONNECT, SLIPON, or SLIPOFF, set the destination address
+             to the IP address, otherwise set it to zero
+           - if CONNECT, set the destination port to the port, otherwise
+             set it to zero
+           - set the line
+           - set the result2 to zero
+           - set the result3 to zero
+           - copy the username to the location just after result3
+           - copy the password to the location just after the end of the
+             username
+
+   Send the request.  Wait for a reasonable (and hopefully configurable)
+   period of time.  If no response has been received, retry a reasonable
+   (and hopefully configurable) number of times.  Reasonable default
+   wait times are 5 seconds and retries are 2.
+
+   If a response has been received, use the nonce value (and as many
+   other fields as you like) to match it to an outstanding request.  If
+   there is no matching outstanding request, take appropriate (and
+   hopefully configurable) action such as discarding and/or logging the
+   packet.
+
+   If the response matches an outstanding request, examine the response
+   and reason codes and take whatever action you deem correct.  For
+
+
+
+Finseth                                                        [Page 11]
+
+RFC 1492                         TACACS                        July 1993
+
+
+   responses to LOGIN and CONNECT requests, also incorporate the
+   result1, result2, and result3 values as you deem correct.
+
+2.3 What a Server Does
+
+   Upon receipt of a UDP format request, the server examines the data in
+   the request packet and determines its response.  It constructs the
+   reply by following these steps:
+
+           - set the version to 128
+           - set the type to RESPONSE (2)
+           - copy the nonce value
+           - copy the username length value
+           - copy the password length value
+           - set the response value to the desired response
+           - set the reason value to the desired reason
+           - if LOGIN or CONNECT, set the result1 else zero the result1
+           - copy the destination host value
+           - copy the destination port value
+           - copy the line value
+           - if LOGIN or CONNECT, set the result2 else zero the result2
+           - if LOGIN or CONNECT, set the result3 else zero the result3
+           - do NOT copy the username or password data
+
+   (As always, be liberal in what you expect and conservative in what
+   you send.) Send the response.  Do not attempt to retry, as you have
+   no basis for determining whether a retry is required.  Any retries
+   are up to the client.  This, of course, implies that requests are
+   idempotent.  They aren't, of course, so the retries must be
+   considered when trying to assemble requests into connections.
+
+3.0 TCP Encoding
+
+   This section describes the TCP encoding of the requests and
+   responses.  This encoding is not compatible with the historical
+   TACACS protocol.  However, it is somewhat more "modern" in that it
+   has been updated to provide for current feature needs.
+
+   This protocol does not use a reserved port.  Instead, it must be
+   possible to configure the ports used by both the the client and
+   server.
+
+   The basic request format is shown here.  The request consists of four
+   lines of ASCII text.  All numeric values are expressed in ASCII as
+   decimal integers.
+
+
+
+
+
+
+Finseth                                                        [Page 12]
+
+RFC 1492                         TACACS                        July 1993
+
+
+           <version> <type> <parameters>
+           <username>
+           <password>
+           <line>
+
+   Each line in the example corresponds to one line of text.  That is,
+   the lines are separated with <CR>/<LF> (13/10 decimal) pairs.  In no
+   event may "bare" <CR> or <LF> characters appear within a field.  In
+   addition, <NUL> (0 decimal) characters may not be sent.
+
+   The <version> and <type> fields are separated with one or more
+   <SPACE> (32 decimal) or <TAB> (9 decimal) characters.
+
+   The <parameters> field is optional.  If present, it is separated from
+   the <type> field and internal parameters separated from each other by
+   or more <SPACE> or <TAB> characters.  Any trailing <SPACE> or <TAB>
+   characters present on this line should be ignored by the server: they
+   should not be taken to imply a trailing empty field.
+
+   In theory there are no line length limits.  In practice, lines should
+   not exceed 255 characters (counting the <CR> and <LF>) and probably
+   should be 80 characters or less.
+
+3.1 Fields
+
+   The VERSION field specifies the version number.  It must be 1.  Other
+   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:
+
+           AUTH
+           LOGIN
+           CONNECT
+           SUPERUSER
+           LOGOUT
+           SLIPON
+           SLIPOFF
+
+   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 and
+   trailing <SPACE> or <TAB> characters are considered significant.  The
+   username data may be in upper case: comparisons should be case-
+   insensitive.
+
+   The PASSWORD field contains the text of the password.  Leading and
+
+
+
+Finseth                                                        [Page 13]
+
+RFC 1492                         TACACS                        July 1993
+
+
+   trailing <SPACE> or <TAB> characters are considered significant.
+
+   The LINE field is set by the client to the line number that the
+   request is for.
+
+3.2 Responses
+
+   Appendix E of STD 10, RFC 821 describes the general theory of reply
+   codes.  The this protocol follows the format described in that
+   document.  In a nutshell, replies are of the form:
+
+           <number> <text>
+
+   Where <number> is a three-digit decimal value and <text> is an
+   arbitrary text string, presumably containing only printing text
+   characters (<SP> (32 decimal) through "~" (126 decimal)).  At least
+   one <SP> (32 decimal) character separates the number from the text.
+   A <CR>/<LF> sequence follows the text.
+
+   The three digit codes completely determine the response.  The text
+   should be considered an explanatory comment for human understanding.
+   However, even without knowing all values, the first digit can be used
+   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 additional
+                   request is made (not used in this version of the
+                   protocol)
+
+           2       Positive Completion
+
+           3       Positive Intermediate: the request is acceptable
+                   so far, but has not been completely transferred
+                   (not used in this version of the protocol)
+
+           4       Transient Negative: the request is not acceptable
+                   for now.  It is acceptable to retry, as another
+                   instance may have a different result.
+
+           5       Permanent Negative: the request is not acceptable
+
+   The text portion is optional (i.e., may be the empty string) and it
+   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 different
+   messages, the following are suggested:
+
+           201 accepted: # # #
+           202 accepted, password is expiring: # # #
+           401 no response; retry
+           501 invalid format
+           502 access denied
+
+   The ": # # #" in the first two messages is the suggested way of
+   returning the three result codes for LOGIN and CONNECT requests.
+
+3.3 What a Client Does
+
+   The client opens a TCP connection to the locally-configured address
+   and port.  It sends the request by sending:
+
+           - the character "1"
+           - one or more <SPACE> or <TAB> characters
+           - the request type as an ASCII string
+           - if an AUTH, send one or more <SPACE> or <TAB> characters
+             and the authentication style
+           - if a CONNECT, SLIPON, or SLIPOFF, send one or more <SPACE>
+             or <TAB> characters and the IP address in dotted decimal
+             notation
+           - if a CONNECT, send one or more <SPACE> or <TAB> characters
+             and the port number in decimal
+           - a <CR>/<LF>
+           - the username (or hostname for SLIPADDR)
+           - a <CR>/<LF>
+           - the password
+           - a <CR>/<LF>
+           - the line
+           - a <CR>/<LF>
+
+   Then read one line from the connection and close the connection.
+   This encoding lets TCP take care of waiting, retries, and matching up
+   requests and responses.
+
+   Examine the response line and take whatever action you deem correct.
+
+3.4 What the Server Does
+
+   The server waits on the locally-specified port for requests.  When
+   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 other
+   information it deems fit to determine its response.
+
+   It then sends exactly one line of response, terminated by a
+   <CR>/<LF>, and closes the connection.
+
+4.0 Pros and Cons
+
+   Advantages to using the UDP format:
+
+           - lower overhead
+           - compatible with historical standard
+           - some existing equipment supports it
+
+   Advantages to using the TCP format:
+
+           - easier to implement, especially on machines with no or
+             poor UDP support
+           - simpler, cleaner syntax
+           - potentially wider range of error codes, and support for
+             temporary and negotiated authentication sequences
+
+
+5.0 Security Notes
+
+   While the protocol itself has been described, there are a number of
+   other considerations worth mentioning.
+
+   First, the protocol carries the username and password in clear text
+   in either a single UDP packet or a TCP stream.  As such, if an
+   attacker is capable of monitoring that data, the attacker could
+   capture username/password pairs.  Implementations can take several
+   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 secure
+   routing subsystem.  This implies:
+
+           - Tight control over router configurations.
+           - Tight control over routing protocols.
+           - Avoid use of bridges, as they can be silently fooled into
+             duplicating packets.
+
+   Second, this protocol potentially opens up a new way of probing
+   usernames and passwords.  Thus, implementations may wish to have
+
+
+
+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 offload
+   accept/reject decisions to servers.  While an obvious implementation
+   would simply use the server's native login mechanism to make the
+   determination, there is no reason to limit implementations to that
+   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 that
+             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 analysis
+           - centralized policy:
+
+                   - ability to block selected specific users
+                   - ability to block selected user names (e.g., don't
+                     allow "root" or "guest")
+                   - ability to block poor passwords (e.g., none or weak)
+
+6.0 Case Study
+
+   This section presents the basic steps used by the implementation at
+   the University of Minnesota.  Two examples will be used.  The first
+   is a basic terminal login.  The second is a database access
+   verification.
+
+   Usernames are in one of three forms:
+
+           First.M.Last-#@umn.edu
+           First.M.Last-#
+           user@host
+
+   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-wide
+   directory system.  If found, the associated electronic mail address
+   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 has
+   agreed to perform validations and the name of an account on that
+   computer.
+
+   The system that we use allows for many requesting clients (typically
+   modem pools).  Further, each client can support multiple distinct
+   pools of users.  For example, lines 1-20 could be general access, but
+   lines 21-25 could be 800-numbers with a restricted set of valid
+   users.  The system supports this distinction by specifying which
+   validation computers are legal for each modem pool.
+
+6.1 Terminal Login
+
+   On the Cisco Terminal Server:
+
+   - accept a connection
+   - request a username and password
+   - pack the request into a UDP TACACS packet and send to the central
+     fanout
+
+   Central Fanout:
+
+   - accept a request
+   - if the request is not in a valid format, return "nope"
+   - log the request
+   - if the source IP address is not in a list of valid clients,
+     status = "nope"
+   - else if the username contains invalid characters, status = "nope"
+   - else
+           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 directory
+                   if the name is not found, status = "nope"
+                   otherwise, use the e-mail address as the username
+
+           if the user is on a special "blocked" list, status = "nope"
+                   and send mail warning that access to a blocked
+                   account was attempted
+           split the username into user and host parts
+           if the host is not on a list of known servers,
+                   status = "nope"
+           else if the host is not allowed to validate this type of
+                   request for this pool, status = "nope"
+
+           now format a request for validation of the user and send it
+           to the specified host
+
+
+
+
+Finseth                                                        [Page 18]
+
+RFC 1492                         TACACS                        July 1993
+
+
+           if no response, status = "nope"
+           otherwise set the status to the returned status
+
+   - log what response is going to be returned
+   - return the response
+
+   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 request
+   - 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 status
+   - return the response
+
+6.2 Database Access Verification
+
+   In this example, assume that a database is only to be accessed by
+   faculty and staff.
+
+   Mainframe:
+
+   - the user is on the mainframe and makes a request
+   - the program requests username and password
+   - the program packs the request into a UDP TACACS packet and send to
+     the central fanout
+
+   Central Fanout:
+
+   - accept a request
+   - if the request is not in a valid format, return "nope"
+   - log the request
+   - if the source IP address is not in a list of valid clients,
+     status = "nope"
+   - else if the username contains invalid characters, status = "nope"
+   - else
+           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 directory
+                   if the name is not found, status = "nope"
+                   otherwise, use the e-mail address as the username
+                      and obtain the staff status from the directory
+           if the user is on a special "blocked" list, status = "nope"
+                   and send mail warning that access to a blocked
+                   account was attempted
+
+
+
+Finseth                                                        [Page 19]
+
+RFC 1492                         TACACS                        July 1993
+
+
+           split the username into user and host parts
+           if the host is not on a list of known servers,
+                   status = "nope"
+           else if the host is not allowed to validate this type of
+                   request for this pool, status = "nope"
+
+           now format a request for validation of the user and send it
+           to the specified host
+
+           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 status
+
+           set the status to the staff status
+   - log what response is going to be returned
+   - return the response
+
+   Note that the validation host is unchanged.
+
+References
+
+   [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, RFC
+   1340, USC/Information Sciences Institute, July 1992.
+
+   Anderson, Brian; Ruth, Greg; Ditmars, Peter; Eisner, Sharon;
+   Delsignore, John (1985) TAC Access Control System Protocols, Second
+   Edition: August 16 1985. BBN Tech Memo CC-0045.
+
+   Cisco Systems, Inc. (September 1992) Communications Server
+   Configuration and Reference.  Menlo Park, California.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finseth                                                        [Page 20]
+
+RFC 1492                         TACACS                        July 1993
+
+
+Security Considerations
+
+   Security issues are the main topic of this memo.
+
+Author's Address
+
+   Craig A. Finseth
+   Networking Services
+   Computer and Information Services
+   University of Minnesota
+   130 Lind Hall
+   207 Church St SE
+   Minneapolis MN 55455-0134
+
+   Phone: +1 612 624 3375
+   Fax:   +1 612 626 1002
+
+   EMail: Craig.A.Finseth-1@umn.edu, or
+          fin@unet.umn.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finseth                                                        [Page 21]
+
\ No newline at end of file