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