rfc1492.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,179 行 · 第 1/3 页


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: [phone]
   Fax:   [phone]

   EMail: [e-mail], or
          [e-mail]
































Finseth                                                        [Page 21]