home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc931 < prev    next >
Text File  |  1991-04-21  |  9KB  |  278 lines
  1. Network Working Group                                       Mike StJohns
  2. Request for Comments: 931                                           TPSC
  3. Supersedes: RFC 912                                         January 1985
  4.  
  5.                          Authentication Server
  6.  
  7.  
  8. STATUS OF THIS MEMO
  9.  
  10.    This RFC suggests a proposed protocol for the ARPA-Internet
  11.    community, and requests discussion and suggestions for improvements.
  12.    This is the second draft of this proposal (superseding RFC 912) and
  13.    incorporates a more formal description of the syntax for the request
  14.    and response dialog, as well as a change to specify the type of user
  15.    identification returned.  Distribution of this memo is unlimited.
  16.  
  17. INTRODUCTION
  18.  
  19.    The Authentication Server Protocol provides a means to determine the
  20.    identity of a user of a particular TCP connection.  Given a TCP port
  21.    number pair, it returns a character string which identifies the owner
  22.    of that connection on the server's system.  Suggested uses include
  23.    automatic identification and verification of a user during an FTP
  24.    session, additional verification of a TAC dial up user, and access
  25.    verification for a generalized network file server.
  26.  
  27. OVERVIEW
  28.  
  29.    This is a connection based application on TCP.  A server listens for
  30.    TCP connections on TCP port 113 (decimal).  Once a connection is
  31.    established, the server reads one line of data which specifies the
  32.    connection of interest.  If it exists, the system dependent user
  33.    identifier of the connection of interest is sent out the connection.
  34.    The service closes the connection after sending the user identifier.
  35.  
  36. RESTRICTIONS
  37.  
  38.    Queries are permitted only for fully specified connections. The
  39.    local/foreign host pair used to fully specify the connection are
  40.    taken from the query connection.  This means a user on Host A may
  41.    only query the server on Host B about connections between A and B.
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. StJohns                                                         [Page 1]
  55.  
  56.  
  57. RFC 931                                                     January 1985
  58. Authentication Server
  59.  
  60.  
  61. QUERY/RESPONSE FORMAT
  62.  
  63.    The server accepts simple text query requests of the form
  64.  
  65.       <local-port>, <foreign-port>
  66.  
  67.    where <local-port> is the TCP port (decimal) on the target (server)
  68.    system, and <foreign-port> is the TCP port (decimal) on the source
  69.    (user) system.
  70.  
  71.       For example:
  72.  
  73.          23, 6191
  74.  
  75.    The response is of the form
  76.  
  77.       <local-port>, <foreign-port> : <response-type> : <additional-info>
  78.  
  79.    where <local-port>,<foreign-port> are the same pair as the query,
  80.    <response-type> is a keyword identifying the type of response, and
  81.    <additional info> is context dependent.
  82.  
  83.       For example:
  84.  
  85.          23, 6191 : USERID : MULTICS : StJohns.DODCSC.a
  86.          23, 6193 : USERID : TAC : MCSJ-MITMUL
  87.          23, 6195 : ERROR : NO-USER
  88.  
  89. RESPONSE TYPES
  90.  
  91.    A response can be one of two types:
  92.  
  93.    USERID
  94.  
  95.       In this case, <additional-info> is a string consisting of an
  96.       operating system name, followed by a ":", followed by user
  97.       identification string in a format peculiar to the operating system
  98.       indicated.  Permitted operating system names are specified in
  99.       RFC-923, "Assigned Numbers" or its successors.  The only other
  100.       names permitted are "TAC" to specify a BBN Terminal Access
  101.       Controller, and "OTHER" to specify any other operating system not
  102.       yet registered with the NIC.
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. StJohns                                                         [Page 2]
  111.  
  112.  
  113. RFC 931                                                     January 1985
  114. Authentication Server
  115.  
  116.  
  117.    ERROR
  118.  
  119.       For some reason the owner of <TCP-port> could not be determined,
  120.       <additional-info> tells why.  The following are suggested values
  121.       of <additional-info> and their meanings.
  122.  
  123.       INVALID-PORT
  124.  
  125.          Either the local or foreign port was improperly specified.
  126.  
  127.       NO-USER
  128.  
  129.          The connection specified by the port pair is not currently in
  130.          use.
  131.  
  132.       UNKNOWN-ERROR
  133.  
  134.          Can't determine connection owner; reason unknown.  Other values
  135.          may be specified as necessary.
  136.  
  137. CAVEATS
  138.  
  139.    Unfortunately, the trustworthiness of the various host systems that
  140.    might implement an authentication server will vary quite a bit.  It
  141.    is up to the various applications that will use the server to
  142.    determine the amount of trust they will place in the returned
  143.    information.  It may be appropriate in some cases restrict the use of
  144.    the server to within a locally controlled subnet.
  145.  
  146. APPLICATIONS
  147.  
  148.    1) Automatic user authentication for FTP
  149.  
  150.       A user-FTP may send a USER command with no argument to the
  151.       server-FTP to request automatic authentication.  The server-FTP
  152.       will reply with a 230 (user logged in) if it can use the
  153.       authentication.  It will reply with a 530 (not logged in) if it
  154.       cannot authenticate the user.  It will reply with a 500 or 501
  155.       (syntax or parameter problem) if it does not implement automatic
  156.       authentication.  Please note that no change is needed to currently
  157.       implemented servers to handle the request for authentication; they
  158.       will reject it normally as a parameter problem.  This is a
  159.       suggested implementation for experimental use only.
  160.  
  161.    2) Verification for privileged network operations.  For example,
  162.    having the server start or stop special purpose servers.
  163.  
  164.  
  165.  
  166. StJohns                                                         [Page 3]
  167.  
  168.  
  169. RFC 931                                                     January 1985
  170. Authentication Server
  171.  
  172.  
  173.    3) Elimination of "double login" for TAC and other TELNET users.
  174.  
  175.       This will be implemented as a TELNET option.
  176.  
  177. FORMAL SYNTAX
  178.  
  179.    <request>     ::= <port-pair> <CR> <LF>
  180.  
  181.    <port-pair>   ::= <integer-number> "," <integer-number>
  182.  
  183.    <reply>       ::= <reply-text> <CR> <LF>
  184.  
  185.    <reply-text>  ::= <error-reply> | <auth-reply>
  186.  
  187.    <error-reply> ::= <port-pair> ":" ERROR ":" <error-type>
  188.  
  189.    <auth-reply>  ::= <port-pair> ":" USERID ":" <opsys> ":" <user-id>
  190.  
  191.    <error-type>  ::= INVALID-PORT | NO-USER | UNKNOWN-ERROR
  192.  
  193.    <opsys>       ::= TAC | OTHER | MULTICS | UNIX ...etc.
  194.                      (See "Assigned Numbers")
  195.  
  196.    Notes on Syntax:
  197.  
  198.       1)  White space (blanks and tab characters) between tokens is not
  199.       important and may be ignored.
  200.  
  201.       2)  White space, the token separator character (":"), and the port
  202.       pair separator character (",") must be quoted if used within a
  203.       token.  The quote character is a back-slash, ASCII 92 (decimal)
  204.       ("\").  For example, a quoted colon is "\:".  The back-slash must
  205.       also be quoted if its needed to represent itself ("\\").
  206.  
  207. Notes on User Identification Format:
  208.  
  209.    The user identifier returned by the server should be the standard one
  210.    for the system.  For example, the standard Multics identifier
  211.    consists of a PERSONID followed by a ".", followed by a PROJECTID,
  212.    followed by a ".", followed by an INSTANCE TAG of one character.  An
  213.    instance tag of "a" identifies an interactive user, and instance tag
  214.    of "m" identifies an absentee job (batch job) user, and an instance
  215.    tag of "z" identifies a daemon (background) user.
  216.  
  217.    Each set of operating system users must come to a consensus as to
  218.  
  219.  
  220.  
  221.  
  222. StJohns                                                         [Page 4]
  223.  
  224.  
  225. RFC 931                                                     January 1985
  226. Authentication Server
  227.  
  228.  
  229.    what the OFFICIAL user identification for their systems will be.
  230.    Until they register this information, they must use the "OTHER" tag
  231.    to specify their user identification.
  232.  
  233. Notes on User Identification Translation:
  234.  
  235.    Once you have a user identifier from a remote system, you must then
  236.    have a way of translating it into an identifier that meaningful on
  237.    the local system.  The following is a sketchy outline of table driven
  238.    scheme for doing this.
  239.  
  240.    The table consists of four columns, the first three are used to match
  241.    against, the fourth is the result.
  242.  
  243.       USERID              Opsys     Address     Result
  244.       MCSJ-MITMUL         TAC       26.*.*.*    StJohns
  245.       *                   MULTICS   192.5.42.*  =
  246.       *                   OTHER     10.0.0.42   anonymous
  247.       MSJ                 ITS       10.3.0.44   StJohns
  248.  
  249.    The above table is a sample one for a Multics system on MILNET at the
  250.    Pentagon.  When an authentication is returned, the particular
  251.    application using the userid simply looks for the first match in the
  252.    table.  Notice the second line.  It says that any authentication
  253.    coming from a Multics system on Net 192.5.42 is accepted in the same
  254.    format.
  255.  
  256.    Obviously, various users will have to be registered to use this
  257.    facility, but the registration can be done at the same time the use
  258.    receives his login identity from the system.
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. StJohns                                                         [Page 5]