rfc1492.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,179 行 · 第 1/3 页

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("[e-mail]", "fake-password", 0, "staff")

      This specifies a username of "[e-mail]" (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...            :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+