home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1492.txt < prev    next >
Text File  |  1994-05-29  |  43KB  |  1,180 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         C. Finseth
  8. Request for Comments: 1492                       University of Minnesota
  9.                                                                July 1993
  10.  
  11.  
  12.           An Access Control Protocol, Sometimes Called TACACS
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard.  Distribution of this memo is
  19.    unlimited.
  20.  
  21. Background
  22.  
  23.    There used to be a network called ARPANET.  This network consisted of
  24.    end nodes (hosts), routing nodes (IMPs) and links.  There were (at
  25.    least) two types of IMPs: those that connected dedicated lines only
  26.    and those that could accept dial up lines.  The latter were called
  27.    "TIPs."
  28.  
  29.    People being what they were, there was a desire to control who could
  30.    use the dial up lines.  Someone invented a protocol, called "TACACS"
  31.    (Terminal Access Controller Access Control System?), which allowed a
  32.    TIP to accept a username and password and send a query to a TACACS
  33.    authentication server, sometimes called a TACACS daemon or simply
  34.    TACACSD.  This server was normally a program running on a host. The
  35.    host would determine whether to accept or deny the request and sent a
  36.    response back.  The TIP would then allow access or not, based upon
  37.    the response.
  38.  
  39.    While TIPs are -- shall we say? -- no longer a major presence on the
  40.    Internet, terminal servers are.  Cisco Systems terminal servers
  41.    implement an extended version of this TACACS protocol.  Thus, the
  42.    access control decision is delegated to a host.  In this way, the
  43.    process of making the decision is "opened up" and the algorithms and
  44.    data used to make the decision are under the complete control of
  45.    whoever is running the TACACS daemon.  For example, "anyone with a
  46.    first name of Joe can only login after 10:00 PM Mon-Fri, unless his
  47.    last name is Smith or there is a Susan already logged in."
  48.  
  49.    The extensions to the protocol provide for more types of
  50.    authentication requests and more types of response codes than were in
  51.    the original specification.
  52.  
  53.    The original TACACS protocol specification does exist.  However, due
  54.    to copyright issues, I was not able to obtain a copy of this document
  55.  
  56.  
  57.  
  58. Finseth                                                         [Page 1]
  59.  
  60. RFC 1492                         TACACS                        July 1993
  61.  
  62.  
  63.    and this lack of access is the main reason for the writing of this
  64.    document.  This version of the specification was developed with the
  65.    assistance of Cisco Systems, who has an implementation of the TACACS
  66.    protocol that is believed to be compatible with the original
  67.    specification.  To be precise, the Cisco Systems implementation
  68.    supports both the simple (non-extended) and extended versions.  It is
  69.    the simple version that would be compatible with the original.
  70.  
  71.    Please keep in mind that this is an informational RFC and does not
  72.    specify a standard, and that more information may be uncovered in the
  73.    future (i.e., the original specification may become available) that
  74.    could cause parts of this document to be known to be incorrect.
  75.  
  76.    This RFC documents the extended TACACS protocol use by the Cisco
  77.    Systems terminal servers.  This same protocol is used by the
  78.    University of Minnesota's distributed authentication system.
  79.  
  80. 1. Protocol Semantics
  81.  
  82.    This section will describe the requests and responses.  The following
  83.    two sections will describe two different ways of encoding the
  84.    protocol.
  85.  
  86.    A request/response pair is the basic unit of interaction.  In this
  87.    pair, the client sends a request and the server replies with a
  88.    response.  All requests must be acknowledged with a response.  This
  89.    requirement implies that all requests can be denied, although it is
  90.    probably futile to attempt to deny a "logout" request.
  91.  
  92. 1.1 Connections
  93.  
  94.    In some cases, a string of request/response pairs forms a larger
  95.    unit, called a "connection."
  96.  
  97.    There are three types of connections:
  98.  
  99.    1) Authenticate only, no connection:
  100.  
  101.            client:  sends an AUTH packet
  102.            server:  responds with a REPLY
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Finseth                                                         [Page 2]
  115.  
  116. RFC 1492                         TACACS                        July 1993
  117.  
  118.  
  119.    2) Login connection:
  120.  
  121.            client:  sends a LOGIN packet
  122.            server:  responds with a REPLY
  123.  
  124.            repeat zero or more times:
  125.                    client:  sends a CONNECT packet
  126.                    server:  responds with a REPLY
  127.  
  128.            client:  sends a LOGOUT packet
  129.            server:  responds with a REPLY
  130.  
  131.    3) SLIP connection:
  132.  
  133.            client:  sends a LOGIN packet
  134.            server:  responds with a REPLY
  135.  
  136.            repeat zero or more times:
  137.                    client:  sends a CONNECT packet
  138.                    server:  responds with a REPLY
  139.  
  140.            client:  sends a SLIPADDR packet
  141.            server:  responds with a REPLY
  142.  
  143.            repeat zero or more times:
  144.                    client:  sends a CONNECT packet
  145.                    server:  responds with a REPLY
  146.  
  147.            client:  sends a SLIPON packet
  148.            server:  responds with a REPLY
  149.            client:  sends a LOGOUT packet (immediate)
  150.            server:  responds with a REPLY
  151.  
  152.            client:  sends a SLIPOFF packet
  153.            server:  responds with a REPLY
  154.  
  155. 1.2 Requests
  156.  
  157.    This section lists the requests supported by the protocol.  The
  158.    responses are described in the later encodings sections.
  159.  
  160.    AUTH(username, password, line, style)
  161.  
  162.       This request asks for an authentication.  The parameters are:
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Finseth                                                         [Page 3]
  171.  
  172. RFC 1492                         TACACS                        July 1993
  173.  
  174.  
  175.               - the username
  176.               - the password
  177.               - an indication of which line the request is for, and
  178.               - a style of authentication
  179.  
  180.       The username is a string that identifies the user.  In principle,
  181.       it can be of any length and contain any characters.  In practice,
  182.       it should be no longer than 128 characters and should contain only
  183.       the ASCII characters "!" (33 decimal) through "~" (126 decimal),
  184.       inclusive.
  185.  
  186.       The password is a string that is used to authenticate the user
  187.       identified by the username.  In principle, it can be of any length
  188.       and contain any characters.  In practice, it should be no longer
  189.       than 128 characters and should contain only the ASCII characters
  190.       "!" (33 decimal) through "~" (126 decimal), inclusive.
  191.  
  192.       The line is a non-negative decimal integer.  If the client
  193.       supports multiple physical access channels, this value identifies
  194.       the particular channel.  By convention, lines are numbered
  195.       starting from one, although this should be taken with a grain of
  196.       salt.  For example, Cisco Systems' implementation uses zero to
  197.       designate the console port, then continues with one for the "main"
  198.       serial lines. Clients that support only one channel should use
  199.       line zero.
  200.  
  201.       The authentication style is a possibly empty string.  It
  202.       identifies the particular style of authentication to be performed.
  203.       Its syntax and semantics are local.
  204.  
  205.       Example:
  206.  
  207.               AUTH("fin@unet.umn.edu", "fake-password", 0, "staff")
  208.  
  209.       This specifies a username of "fin@unet.umn.edu" (which happens to
  210.       be my e-mail address), a password, an indication that no line is
  211.       associated with this request, and a style of "staff".  The
  212.       semantics for this style might be that I am required to be a staff
  213.       member (in addition, of course, to supplying a valid username and
  214.       password).  The server would presumably consult an external
  215.       database to verify the staff status.
  216.  
  217.       As a local option, the implementation may choose to encode the
  218.       style information by using alternate port numbers.  E.g. port 4001
  219.       would mean style 1, 4002 would be style 2, etc.
  220.  
  221.       Note that the AUTH request type cannot be sent using the UDP
  222.       encoding.
  223.  
  224.  
  225.  
  226. Finseth                                                         [Page 4]
  227.  
  228. RFC 1492                         TACACS                        July 1993
  229.  
  230.  
  231.    LOGIN(username, password, line) returns (result1, result2, result3)
  232.  
  233.       This request asks for an authentication and signals that -- if the
  234.       authentication succeeds -- a login connection is starting.  The
  235.       parameters are:
  236.  
  237.       - the username
  238.       - the password
  239.       - an indication of which line the request is for
  240.  
  241.       The meanings of the input fields are the same as the AUTH request.
  242.       If the request is successful, this request returns three result
  243.       values in addition to the success status.  The result values are
  244.       non-negative integers.  Their interpretation is local.  For
  245.       example, Cisco Systems terminal servers interpret result3 to be
  246.       the identifier of a local access list to use for additional
  247.       validation.
  248.  
  249.    CONNECT(username, password, line, destinationIP, destinationPort)
  250.    returns (result1, result2, result3)
  251.  
  252.       This request can only be issued when the username and line specify
  253.       an already-existing connection.  As such, no authentication is
  254.       required and the password will in general be the empty string. It
  255.       asks, in the context of that connection, whether a TCP connection
  256.       can be opened to the specified destination IP address and port.
  257.  
  258.       The return values are as for LOGIN.
  259.  
  260.    SUPERUSER(username, password, line)
  261.  
  262.       This request can only be issued when the username and line specify
  263.       an already-existing connection.  As such, no authentication is
  264.       required and the password will in general be the empty string.  It
  265.       asks, in the context of that connection, whether the user can go
  266.       into "super-user" or "enable" mode on the terminal server.
  267.  
  268.       As an example of the flexibility inherint in this whole scheme,
  269.       the TACACSD supplied by Cisco Systems ignores the username part
  270.       and instead checks wether the password matches that of the special
  271.       user "$enable$".
  272.  
  273.    LOGOUT(username, password, line, reason)
  274.  
  275.       This request can only be issued when the username and line specify
  276.       an already-existing connection.  As such, no authentication is
  277.       required and the password will in general be the empty string.  It
  278.       indicates that the connection should be terminated (but see
  279.  
  280.  
  281.  
  282. Finseth                                                         [Page 5]
  283.  
  284. RFC 1492                         TACACS                        July 1993
  285.  
  286.  
  287.       SLIPON).  It must be acknowledged, but the success/fail status of
  288.       the acknowledgment is irrelevant.  The reason value indicates why
  289.       the connection is terminating.  A null reason value is supplied
  290.       when the connection is going into SLIP mode.
  291.  
  292.    SLIPON(username, password, line, SLIPaddress) returns (result1,
  293.    result2, result3)
  294.  
  295.       This request can only be issued when the username and line specify
  296.       an already-existing connection.  As such, no authentication is
  297.       required and the password will in general be the empty string.  It
  298.       asks, in the context of that connection, whether the specified
  299.       SLIPaddress can be used for the remote end of the connection.
  300.  
  301.       If the server replies with a success, the client can proceed to a
  302.       SLIPON request.  (It need not do so right away, however.)
  303.  
  304.       Note that semantics of "username" can get hairy.  For example, the
  305.       Cisco Systems implementation encodes information in this way:
  306.  
  307.       - If the user just requested the default address be assigned, this
  308.       field holds the username in lower case.
  309.  
  310.       - If the user requested a specific IP address or host name for the
  311.       SLIP connection, this field contains the requested host name in
  312.       UPPER case.
  313.  
  314.       If the server replies with a success, the client will immediately
  315.       send a LOGOUT request.  However, the connection will remain
  316.       established until a SLIPOFF request is sent.  No other
  317.       authentication requests will be sent for that connection.
  318.  
  319.       SLIPaddress specifies the IP address used by the remote host.  If
  320.       a SLIPADDR request has been made, it will be that address.
  321.       Otherwise, it will be the default address assigned by the client
  322.       (e.g., Cisco terminal server).
  323.  
  324.       The return values are as for LOGIN.
  325.  
  326.    SLIPOFF(username, password, line, reason)
  327.  
  328.       This request can only be issued when the username and line specify
  329.       an already-existing connection that is in "SLIP" mode.  As such,
  330.       no authentication is required and the password will in general be
  331.       the empty string.  It indicates that the connection should be
  332.       terminated.  It must be acknowledged, but the success/fail status
  333.       of the acknowledgment is irrelevant.  The reason value indicates
  334.       why the connection is terminating.
  335.  
  336.  
  337.  
  338. Finseth                                                         [Page 6]
  339.  
  340. RFC 1492                         TACACS                        July 1993
  341.  
  342.  
  343. 2.0 UDP Encoding: TACACS
  344.  
  345.    This section describes the UDP encoding of the requests that have
  346.    just been described.  It also describes the responses.  This UDP
  347.    encoding forms the basis of the historical TACACS protocol.
  348.  
  349.    This protocol uses port 49.  This assignment continues to be
  350.    confirmed by the IANA in the Assigned Numbers RFCs.  (I can't say
  351.    that it was assigned by the IANA as the assignment preceded the
  352.    organization.)
  353.  
  354.    The basic packet format is shown here.  All multi-bytes values are in
  355.    network byte order.  Unless otherwise specified, all values given are
  356.    in decimal.  Unused fields should be set to zero, but the recipient
  357.    should not depend on that setting.
  358.  
  359.    As was mentioned earlier, there are both simple and extended forms,
  360.    of which the simple form is a proper subset of the extended form.  A
  361.    server should support both.  I will describe both forms in parallel.
  362.  
  363.    Simple Form
  364.  
  365.    The fields are:
  366.  
  367.       offset       length  field
  368.  
  369.       0    1       version
  370.       1    1       type
  371.       2    2       nonce value
  372.       4    1       username length (to server) / response (to client)
  373.       5    1       password length (to server) / reason (to client)
  374.  
  375.    in the usual packet layout format:
  376.  
  377.     0                   1                   2                   3
  378.     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
  379.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  380.    :    Version    :     Type      :             Nonce             :
  381.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  382.    : User len/Resp : PW len/Reason :            data...            :
  383.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Finseth                                                         [Page 7]
  395.  
  396. RFC 1492                         TACACS                        July 1993
  397.  
  398.  
  399.    Extended Form
  400.  
  401.    The fields are:
  402.  
  403.            offset  length  field
  404.  
  405.            0       1       version
  406.            1       1       type
  407.            2       2       nonce value
  408.            4       1       username length
  409.            5       1       password length
  410.            6       1       response
  411.            7       1       reason
  412.            8       4       result1
  413.            12      4       destination host, IP address
  414.            16      2       destination port
  415.            18      2       line
  416.            20      4       result2
  417.            24      2       result3
  418.            26      varies  data: username + password
  419.  
  420.    in the usual packet layout format:
  421.  
  422.     0                   1                   2                   3
  423.     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
  424.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  425.    :    Version    :     Type      :             Nonce             :
  426.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  427.    :   User len    : Password len  :   Response    :    Reason     :
  428.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  429.    :                           Result 1                            :
  430.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  431.    :                      Destination Address                      :
  432.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  433.    :           Dest Port           :             Line              :
  434.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  435.    :                           Result 2                            :
  436.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  437.    :           Result 3            :            data...            :
  438.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  439.  
  440. 2.1 Fields
  441.  
  442.    The VERSION field specifies the version number.  It must be zero for
  443.    simple or 128 (80 hexadecimal) for extended.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Finseth                                                         [Page 8]
  451.  
  452. RFC 1492                         TACACS                        July 1993
  453.  
  454.  
  455.    The TYPE field encodes the request type.  Values are:
  456.  
  457.            LOGIN           1
  458.            RESPONSE        2       (server to client only)
  459.            CHANGE          3
  460.            FOLLOW          4
  461.            CONNECT         5
  462.            SUPERUSER       6
  463.            LOGOUT          7
  464.            RELOAD          8
  465.            SLIPON          9
  466.            SLIPOFF         10
  467.            SLIPADDR        11
  468.  
  469.    Other values below 128 are reserved for future use.  Values from 128
  470.    to 255 are reserved for local use.
  471.  
  472.    Note that the semantics of the CHANGE, FOLLOW, RELOAD requests have
  473.    not been determined.
  474.  
  475.    The NONCE field is set by the client to an arbitrary value.  Its
  476.    purpose is to allow clients that may have multiple outstanding
  477.    requests to determine which request a response is for. The server
  478.    must copy this value to the reply unaltered.
  479.  
  480.    The USERNAME LENGTH field is set by the client to the length of the
  481.    username in characters.  Legal values are 0 to 255, inclusive. The
  482.    server must copy this value to the reply unaltered.
  483.  
  484.    The PASSWORD LENGTH is set by the client to the length of the
  485.    password in characters. Legal values are 0 to 255, inclusive. The
  486.    server must copy this value to the reply unaltered.
  487.  
  488.    The RESPONSE field should be set by the client to zero.  The server
  489.    sets the value to one of:
  490.  
  491.            value   meaning
  492.  
  493.            1       accepted
  494.            2       rejected
  495.  
  496.    Other values below 128 are reserved for future use.  Values from 128
  497.    to 255 are reserved for local use.
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Finseth                                                         [Page 9]
  507.  
  508. RFC 1492                         TACACS                        July 1993
  509.  
  510.  
  511.    The REASON field should be set by the client to zero, except for
  512.    LOGOUT and SLIPOFF requests, which may use values of 4, 5, or 6.  The
  513.    server sets the value to one of:
  514.  
  515.            value   meaning         notes
  516.  
  517.            0       none            used for ACCEPTED or if the server
  518.                                    is ornery
  519.            1       expiring
  520.            2       password
  521.            3       denied
  522.            4       quit            user quit normally
  523.            5       idle            idle timeout
  524.            6       drop            carrier dropped
  525.            7       bad             too many bad passwords
  526.  
  527.    The values from 4 to 6 will only be used for reasons for LOGOUT or
  528.    SLIPOFF requests: they will not be returned by the server.  Other
  529.    values below 128 are reserved for future use.  Values from 128 to 255
  530.    are reserved for local use.
  531.  
  532.    The RESULT1 field should be set by the client to zero.  For LOGIN or
  533.    CONNECT requests, it is set by the server as specified in the request
  534.    description.  For all other requests, it should be set by the server
  535.    to zero.
  536.  
  537.    The DESTINATION HOST field is set by the client.  On CONNECT, SLIPON,
  538.    and SLIPOFF requests it specifies an IP address.  It should be set to
  539.    zero on all other requests.  For SLIPON and SLIPOFF request, this
  540.    value should be the IP address assigned to the line.  For CONNECT
  541.    requests, this value is the IP address of the host that the user is
  542.    attempting to connect to.  The server copies this value to the reply.
  543.  
  544.    The DESTINATION PORT field is set by the client.  On CONNECT requests
  545.    it specifies the port number that the user is attempting to connect
  546.    to.  It should be set to zero on all other requests. The server
  547.    copies this value to the reply.
  548.  
  549.    The LINE field is set by the client to the line number that the
  550.    request is for.  The server copies this value to the reply.
  551.  
  552.    The RESULT2 field should be set by the client to zero.  For LOGIN or
  553.    CONNECT requests, it is set by the server as specified in the request
  554.    description.  For all other requests, it should be set by the server
  555.    to zero.
  556.  
  557.    The RESULT3 field should be set by the client to zero.  For LOGIN or
  558.    CONNECT requests, it is set by the server as specified in the request
  559.  
  560.  
  561.  
  562. Finseth                                                        [Page 10]
  563.  
  564. RFC 1492                         TACACS                        July 1993
  565.  
  566.  
  567.    description.  For all other requests, it should be set by the server
  568.    to zero.
  569.  
  570.    The DATA field contains just the text of the username and password,
  571.    with no separator characters (you use username length and password
  572.    length to sort them out).  The server does not copy the values to the
  573.    reply. (However, the server does copy the username length and
  574.    password length fields to the reply.) The username data may be in
  575.    upper case: comparisons should be case-insensitive.
  576.  
  577. 2.2 What a Client Does
  578.  
  579.    The client must format and send a UDP request to port 49.  It
  580.    constructs the request by following these steps:
  581.  
  582.            - set the version to 128
  583.            - set the type to that of the request
  584.            - set the nonce to a unique value that is different from all
  585.              outstanding requests
  586.            - set the username length
  587.            - set the password length
  588.            - set the response to zero
  589.            - set the reason to zero (except for LOGOUT and SLIPOFF)
  590.            - set the result1 to zero
  591.            - if CONNECT, SLIPON, or SLIPOFF, set the destination address
  592.              to the IP address, otherwise set it to zero
  593.            - if CONNECT, set the destination port to the port, otherwise
  594.              set it to zero
  595.            - set the line
  596.            - set the result2 to zero
  597.            - set the result3 to zero
  598.            - copy the username to the location just after result3
  599.            - copy the password to the location just after the end of the
  600.              username
  601.  
  602.    Send the request.  Wait for a reasonable (and hopefully configurable)
  603.    period of time.  If no response has been received, retry a reasonable
  604.    (and hopefully configurable) number of times.  Reasonable default
  605.    wait times are 5 seconds and retries are 2.
  606.  
  607.    If a response has been received, use the nonce value (and as many
  608.    other fields as you like) to match it to an outstanding request.  If
  609.    there is no matching outstanding request, take appropriate (and
  610.    hopefully configurable) action such as discarding and/or logging the
  611.    packet.
  612.  
  613.    If the response matches an outstanding request, examine the response
  614.    and reason codes and take whatever action you deem correct.  For
  615.  
  616.  
  617.  
  618. Finseth                                                        [Page 11]
  619.  
  620. RFC 1492                         TACACS                        July 1993
  621.  
  622.  
  623.    responses to LOGIN and CONNECT requests, also incorporate the
  624.    result1, result2, and result3 values as you deem correct.
  625.  
  626. 2.3 What a Server Does
  627.  
  628.    Upon receipt of a UDP format request, the server examines the data in
  629.    the request packet and determines its response.  It constructs the
  630.    reply by following these steps:
  631.  
  632.            - set the version to 128
  633.            - set the type to RESPONSE (2)
  634.            - copy the nonce value
  635.            - copy the username length value
  636.            - copy the password length value
  637.            - set the response value to the desired response
  638.            - set the reason value to the desired reason
  639.            - if LOGIN or CONNECT, set the result1 else zero the result1
  640.            - copy the destination host value
  641.            - copy the destination port value
  642.            - copy the line value
  643.            - if LOGIN or CONNECT, set the result2 else zero the result2
  644.            - if LOGIN or CONNECT, set the result3 else zero the result3
  645.            - do NOT copy the username or password data
  646.  
  647.    (As always, be liberal in what you expect and conservative in what
  648.    you send.) Send the response.  Do not attempt to retry, as you have
  649.    no basis for determining whether a retry is required.  Any retries
  650.    are up to the client.  This, of course, implies that requests are
  651.    idempotent.  They aren't, of course, so the retries must be
  652.    considered when trying to assemble requests into connections.
  653.  
  654. 3.0 TCP Encoding
  655.  
  656.    This section describes the TCP encoding of the requests and
  657.    responses.  This encoding is not compatible with the historical
  658.    TACACS protocol.  However, it is somewhat more "modern" in that it
  659.    has been updated to provide for current feature needs.
  660.  
  661.    This protocol does not use a reserved port.  Instead, it must be
  662.    possible to configure the ports used by both the the client and
  663.    server.
  664.  
  665.    The basic request format is shown here.  The request consists of four
  666.    lines of ASCII text.  All numeric values are expressed in ASCII as
  667.    decimal integers.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Finseth                                                        [Page 12]
  675.  
  676. RFC 1492                         TACACS                        July 1993
  677.  
  678.  
  679.            <version> <type> <parameters>
  680.            <username>
  681.            <password>
  682.            <line>
  683.  
  684.    Each line in the example corresponds to one line of text.  That is,
  685.    the lines are separated with <CR>/<LF> (13/10 decimal) pairs.  In no
  686.    event may "bare" <CR> or <LF> characters appear within a field.  In
  687.    addition, <NUL> (0 decimal) characters may not be sent.
  688.  
  689.    The <version> and <type> fields are separated with one or more
  690.    <SPACE> (32 decimal) or <TAB> (9 decimal) characters.
  691.  
  692.    The <parameters> field is optional.  If present, it is separated from
  693.    the <type> field and internal parameters separated from each other by
  694.    or more <SPACE> or <TAB> characters.  Any trailing <SPACE> or <TAB>
  695.    characters present on this line should be ignored by the server: they
  696.    should not be taken to imply a trailing empty field.
  697.  
  698.    In theory there are no line length limits.  In practice, lines should
  699.    not exceed 255 characters (counting the <CR> and <LF>) and probably
  700.    should be 80 characters or less.
  701.  
  702. 3.1 Fields
  703.  
  704.    The VERSION field specifies the version number.  It must be 1.  Other
  705.    values below 128 are reserved for future use.  Values from 128 to 255
  706.    are reserved for local use.
  707.  
  708.    The TYPE field encodes the request type.  Values are:
  709.  
  710.            AUTH
  711.            LOGIN
  712.            CONNECT
  713.            SUPERUSER
  714.            LOGOUT
  715.            SLIPON
  716.            SLIPOFF
  717.  
  718.    I.e., the keyword simply encodes itself.  It must be in upper case.
  719.    Keywords that begin with the letter "X" are reserved for local use.
  720.  
  721.    The USERNAME field contains the text of the username.  Leading and
  722.    trailing <SPACE> or <TAB> characters are considered significant.  The
  723.    username data may be in upper case: comparisons should be case-
  724.    insensitive.
  725.  
  726.    The PASSWORD field contains the text of the password.  Leading and
  727.  
  728.  
  729.  
  730. Finseth                                                        [Page 13]
  731.  
  732. RFC 1492                         TACACS                        July 1993
  733.  
  734.  
  735.    trailing <SPACE> or <TAB> characters are considered significant.
  736.  
  737.    The LINE field is set by the client to the line number that the
  738.    request is for.
  739.  
  740. 3.2 Responses
  741.  
  742.    Appendix E of STD 10, RFC 821 describes the general theory of reply
  743.    codes.  The this protocol follows the format described in that
  744.    document.  In a nutshell, replies are of the form:
  745.  
  746.            <number> <text>
  747.  
  748.    Where <number> is a three-digit decimal value and <text> is an
  749.    arbitrary text string, presumably containing only printing text
  750.    characters (<SP> (32 decimal) through "~" (126 decimal)).  At least
  751.    one <SP> (32 decimal) character separates the number from the text.
  752.    A <CR>/<LF> sequence follows the text.
  753.  
  754.    The three digit codes completely determine the response.  The text
  755.    should be considered an explanatory comment for human understanding.
  756.    However, even without knowing all values, the first digit can be used
  757.    to determine the overall nature of the response.  The encodings are:
  758.  
  759.            1       Positive Preliminary: the request is acceptable,
  760.                    but no action will be taken until an additional
  761.                    request is made (not used in this version of the
  762.                    protocol)
  763.  
  764.            2       Positive Completion
  765.  
  766.            3       Positive Intermediate: the request is acceptable
  767.                    so far, but has not been completely transferred
  768.                    (not used in this version of the protocol)
  769.  
  770.            4       Transient Negative: the request is not acceptable
  771.                    for now.  It is acceptable to retry, as another
  772.                    instance may have a different result.
  773.  
  774.            5       Permanent Negative: the request is not acceptable
  775.  
  776.    The text portion is optional (i.e., may be the empty string) and it
  777.    describes the meaning of the message in human readable form.
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Finseth                                                        [Page 14]
  787.  
  788. RFC 1492                         TACACS                        July 1993
  789.  
  790.  
  791.    While different server implementations will result in different
  792.    messages, the following are suggested:
  793.  
  794.            201 accepted: # # #
  795.            202 accepted, password is expiring: # # #
  796.            401 no response; retry
  797.            501 invalid format
  798.            502 access denied
  799.  
  800.    The ": # # #" in the first two messages is the suggested way of
  801.    returning the three result codes for LOGIN and CONNECT requests.
  802.  
  803. 3.3 What a Client Does
  804.  
  805.    The client opens a TCP connection to the locally-configured address
  806.    and port.  It sends the request by sending:
  807.  
  808.            - the character "1"
  809.            - one or more <SPACE> or <TAB> characters
  810.            - the request type as an ASCII string
  811.            - if an AUTH, send one or more <SPACE> or <TAB> characters
  812.              and the authentication style
  813.            - if a CONNECT, SLIPON, or SLIPOFF, send one or more <SPACE>
  814.              or <TAB> characters and the IP address in dotted decimal
  815.              notation
  816.            - if a CONNECT, send one or more <SPACE> or <TAB> characters
  817.              and the port number in decimal
  818.            - a <CR>/<LF>
  819.            - the username (or hostname for SLIPADDR)
  820.            - a <CR>/<LF>
  821.            - the password
  822.            - a <CR>/<LF>
  823.            - the line
  824.            - a <CR>/<LF>
  825.  
  826.    Then read one line from the connection and close the connection.
  827.    This encoding lets TCP take care of waiting, retries, and matching up
  828.    requests and responses.
  829.  
  830.    Examine the response line and take whatever action you deem correct.
  831.  
  832. 3.4 What the Server Does
  833.  
  834.    The server waits on the locally-specified port for requests.  When
  835.    one is made, it reads four lines of input.
  836.  
  837.    It examines the first line for a valid version number and request.
  838.    It also records any optional parameters.
  839.  
  840.  
  841.  
  842. Finseth                                                        [Page 15]
  843.  
  844. RFC 1492                         TACACS                        July 1993
  845.  
  846.  
  847.    It uses the username, password, and line number along with any other
  848.    information it deems fit to determine its response.
  849.  
  850.    It then sends exactly one line of response, terminated by a
  851.    <CR>/<LF>, and closes the connection.
  852.  
  853. 4.0 Pros and Cons
  854.  
  855.    Advantages to using the UDP format:
  856.  
  857.            - lower overhead
  858.            - compatible with historical standard
  859.            - some existing equipment supports it
  860.  
  861.    Advantages to using the TCP format:
  862.  
  863.            - easier to implement, especially on machines with no or
  864.              poor UDP support
  865.            - simpler, cleaner syntax
  866.            - potentially wider range of error codes, and support for
  867.              temporary and negotiated authentication sequences
  868.  
  869.  
  870. 5.0 Security Notes
  871.  
  872.    While the protocol itself has been described, there are a number of
  873.    other considerations worth mentioning.
  874.  
  875.    First, the protocol carries the username and password in clear text
  876.    in either a single UDP packet or a TCP stream.  As such, if an
  877.    attacker is capable of monitoring that data, the attacker could
  878.    capture username/password pairs.  Implementations can take several
  879.    steps to minimize this danger:
  880.  
  881.    - Use point-to-point links where possible.
  882.  
  883.    - Physically secure the transmission medium.
  884.  
  885.    - If packets must traverse multiple network segments, use a secure
  886.    routing subsystem.  This implies:
  887.  
  888.            - Tight control over router configurations.
  889.            - Tight control over routing protocols.
  890.            - Avoid use of bridges, as they can be silently fooled into
  891.              duplicating packets.
  892.  
  893.    Second, this protocol potentially opens up a new way of probing
  894.    usernames and passwords.  Thus, implementations may wish to have
  895.  
  896.  
  897.  
  898. Finseth                                                        [Page 16]
  899.  
  900. RFC 1492                         TACACS                        July 1993
  901.  
  902.  
  903.    servers:
  904.  
  905.            - limit responses to a controlled list of clients,
  906.            - throttle the rate of responding to requests,
  907.            - log all failures (and possibly successes, too).
  908.  
  909.    Third, this protocol essentially allows clients to offload
  910.    accept/reject decisions to servers.  While an obvious implementation
  911.    would simply use the server's native login mechanism to make the
  912.    determination, there is no reason to limit implementations to that
  913.    mechanism. Servers could:
  914.  
  915.            - use alternate lists of accounts (e.g., password files),
  916.            - use alternate mechanisms for accessing the accounts (e.g.,
  917.              a database, NIS),
  918.            - use alternate algorithms (e.g., SecureID cards),
  919.            - translate the request to another protocol and use that
  920.              protocol to make the determination (e.g., Kerberos).
  921.  
  922.    Fourth, the use of a "fanout" server (described in the next section)
  923.    allows for:
  924.  
  925.            - centralized logging of usage for attack analysis
  926.            - centralized policy:
  927.  
  928.                    - ability to block selected specific users
  929.                    - ability to block selected user names (e.g., don't
  930.                      allow "root" or "guest")
  931.                    - ability to block poor passwords (e.g., none or weak)
  932.  
  933. 6.0 Case Study
  934.  
  935.    This section presents the basic steps used by the implementation at
  936.    the University of Minnesota.  Two examples will be used.  The first
  937.    is a basic terminal login.  The second is a database access
  938.    verification.
  939.  
  940.    Usernames are in one of three forms:
  941.  
  942.            First.M.Last-#@umn.edu
  943.            First.M.Last-#
  944.            user@host
  945.  
  946.    A name in the first form is converted to one in the second.
  947.  
  948.    A name in the second form is looked up in the University-wide
  949.    directory system.  If found, the associated electronic mail address
  950.    is treated as if the third form was entered.
  951.  
  952.  
  953.  
  954. Finseth                                                        [Page 17]
  955.  
  956. RFC 1492                         TACACS                        July 1993
  957.  
  958.  
  959.    The third form specifics the name of a computer whose manager has
  960.    agreed to perform validations and the name of an account on that
  961.    computer.
  962.  
  963.    The system that we use allows for many requesting clients (typically
  964.    modem pools).  Further, each client can support multiple distinct
  965.    pools of users.  For example, lines 1-20 could be general access, but
  966.    lines 21-25 could be 800-numbers with a restricted set of valid
  967.    users.  The system supports this distinction by specifying which
  968.    validation computers are legal for each modem pool.
  969.  
  970. 6.1 Terminal Login
  971.  
  972.    On the Cisco Terminal Server:
  973.  
  974.    - accept a connection
  975.    - request a username and password
  976.    - pack the request into a UDP TACACS packet and send to the central
  977.      fanout
  978.  
  979.    Central Fanout:
  980.  
  981.    - accept a request
  982.    - if the request is not in a valid format, return "nope"
  983.    - log the request
  984.    - if the source IP address is not in a list of valid clients,
  985.      status = "nope"
  986.    - else if the username contains invalid characters, status = "nope"
  987.    - else
  988.            if the username is of the form First.M.Last-#@umn.edu,
  989.                    convert to First.M.Last-#
  990.            if the username is of the form First.M.Last-#,
  991.                    look up the name in the directory
  992.                    if the name is not found, status = "nope"
  993.                    otherwise, use the e-mail address as the username
  994.  
  995.            if the user is on a special "blocked" list, status = "nope"
  996.                    and send mail warning that access to a blocked
  997.                    account was attempted
  998.            split the username into user and host parts
  999.            if the host is not on a list of known servers,
  1000.                    status = "nope"
  1001.            else if the host is not allowed to validate this type of
  1002.                    request for this pool, status = "nope"
  1003.  
  1004.            now format a request for validation of the user and send it
  1005.            to the specified host
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Finseth                                                        [Page 18]
  1011.  
  1012. RFC 1492                         TACACS                        July 1993
  1013.  
  1014.  
  1015.            if no response, status = "nope"
  1016.            otherwise set the status to the returned status
  1017.  
  1018.    - log what response is going to be returned
  1019.    - return the response
  1020.  
  1021.    Validation Host:
  1022.  
  1023.    This machine can run a "stripped down" version of the central fanout.
  1024.    It need perform no special validation or logging, with one exception.
  1025.  
  1026.    - accept a request
  1027.    - if the request is not in a valid format, return "nope"
  1028.    - if the request is not from the central fanout, return "nope"
  1029.    - figure the return status
  1030.    - return the response
  1031.  
  1032. 6.2 Database Access Verification
  1033.  
  1034.    In this example, assume that a database is only to be accessed by
  1035.    faculty and staff.
  1036.  
  1037.    Mainframe:
  1038.  
  1039.    - the user is on the mainframe and makes a request
  1040.    - the program requests username and password
  1041.    - the program packs the request into a UDP TACACS packet and send to
  1042.      the central fanout
  1043.  
  1044.    Central Fanout:
  1045.  
  1046.    - accept a request
  1047.    - if the request is not in a valid format, return "nope"
  1048.    - log the request
  1049.    - if the source IP address is not in a list of valid clients,
  1050.      status = "nope"
  1051.    - else if the username contains invalid characters, status = "nope"
  1052.    - else
  1053.            if the username is of the form First.M.Last-#@umn.edu,
  1054.                    convert to First.M.Last-#
  1055.            if the username is of the form First.M.Last-#,
  1056.                    look up the name in the directory
  1057.                    if the name is not found, status = "nope"
  1058.                    otherwise, use the e-mail address as the username
  1059.                       and obtain the staff status from the directory
  1060.            if the user is on a special "blocked" list, status = "nope"
  1061.                    and send mail warning that access to a blocked
  1062.                    account was attempted
  1063.  
  1064.  
  1065.  
  1066. Finseth                                                        [Page 19]
  1067.  
  1068. RFC 1492                         TACACS                        July 1993
  1069.  
  1070.  
  1071.            split the username into user and host parts
  1072.            if the host is not on a list of known servers,
  1073.                    status = "nope"
  1074.            else if the host is not allowed to validate this type of
  1075.                    request for this pool, status = "nope"
  1076.  
  1077.            now format a request for validation of the user and send it
  1078.            to the specified host
  1079.  
  1080.            if no response or status is "nope", status = "nope"
  1081.  
  1082.            else if the user originally gave a user@host mail address,
  1083.                    do a directory lookup and obtain the staff status
  1084.  
  1085.            set the status to the staff status
  1086.    - log what response is going to be returned
  1087.    - return the response
  1088.  
  1089.    Note that the validation host is unchanged.
  1090.  
  1091. References
  1092.  
  1093.    [RFC821] Postel, J. "Simple Mail Transfer Protocol", STD 10, RFC 821,
  1094.    USC/Information Sciences Institute, August 1982.
  1095.  
  1096.    [RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers," STD 2, RFC
  1097.    1340, USC/Information Sciences Institute, July 1992.
  1098.  
  1099.    Anderson, Brian; Ruth, Greg; Ditmars, Peter; Eisner, Sharon;
  1100.    Delsignore, John (1985) TAC Access Control System Protocols, Second
  1101.    Edition: August 16 1985. BBN Tech Memo CC-0045.
  1102.  
  1103.    Cisco Systems, Inc. (September 1992) Communications Server
  1104.    Configuration and Reference.  Menlo Park, California.
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Finseth                                                        [Page 20]
  1123.  
  1124. RFC 1492                         TACACS                        July 1993
  1125.  
  1126.  
  1127. Security Considerations
  1128.  
  1129.    Security issues are the main topic of this memo.
  1130.  
  1131. Author's Address
  1132.  
  1133.    Craig A. Finseth
  1134.    Networking Services
  1135.    Computer and Information Services
  1136.    University of Minnesota
  1137.    130 Lind Hall
  1138.    207 Church St SE
  1139.    Minneapolis MN 55455-0134
  1140.  
  1141.    Phone: +1 612 624 3375
  1142.    Fax:   +1 612 626 1002
  1143.  
  1144.    EMail: Craig.A.Finseth-1@umn.edu, or
  1145.           fin@unet.umn.edu
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Finseth                                                        [Page 21]
  1179.  
  1180.