Authentication server
RFC 931

Document Type RFC - Unknown (January 1985; No errata)
Obsoleted by RFC 1413
Obsoletes RFC 912
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 931 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       Mike StJohns
Request for Comments: 931                                           TPSC
Supersedes: RFC 912                                         January 1985

                         Authentication Server


   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   This is the second draft of this proposal (superseding RFC 912) and
   incorporates a more formal description of the syntax for the request
   and response dialog, as well as a change to specify the type of user
   identification returned.  Distribution of this memo is unlimited.


   The Authentication Server Protocol provides a means to determine the
   identity of a user of a particular TCP connection.  Given a TCP port
   number pair, it returns a character string which identifies the owner
   of that connection on the server's system.  Suggested uses include
   automatic identification and verification of a user during an FTP
   session, additional verification of a TAC dial up user, and access
   verification for a generalized network file server.


   This is a connection based application on TCP.  A server listens for
   TCP connections on TCP port 113 (decimal).  Once a connection is
   established, the server reads one line of data which specifies the
   connection of interest.  If it exists, the system dependent user
   identifier of the connection of interest is sent out the connection.
   The service closes the connection after sending the user identifier.


   Queries are permitted only for fully specified connections. The
   local/foreign host pair used to fully specify the connection are
   taken from the query connection.  This means a user on Host A may
   only query the server on Host B about connections between A and B.

StJohns                                                         [Page 1]

RFC 931                                                     January 1985
Authentication Server


   The server accepts simple text query requests of the form

      <local-port>, <foreign-port>

   where <local-port> is the TCP port (decimal) on the target (server)
   system, and <foreign-port> is the TCP port (decimal) on the source
   (user) system.

      For example:

         23, 6191

   The response is of the form

      <local-port>, <foreign-port> : <response-type> : <additional-info>

   where <local-port>,<foreign-port> are the same pair as the query,
   <response-type> is a keyword identifying the type of response, and
   <additional info> is context dependent.

      For example:

         23, 6191 : USERID : MULTICS : StJohns.DODCSC.a
         23, 6193 : USERID : TAC : MCSJ-MITMUL
         23, 6195 : ERROR : NO-USER


   A response can be one of two types:


      In this case, <additional-info> is a string consisting of an
      operating system name, followed by a ":", followed by user
      identification string in a format peculiar to the operating system
      indicated.  Permitted operating system names are specified in
      RFC-923, "Assigned Numbers" or its successors.  The only other
      names permitted are "TAC" to specify a BBN Terminal Access
      Controller, and "OTHER" to specify any other operating system not
      yet registered with the NIC.

StJohns                                                         [Page 2]

RFC 931                                                     January 1985
Authentication Server


      For some reason the owner of <TCP-port> could not be determined,
      <additional-info> tells why.  The following are suggested values
      of <additional-info> and their meanings.


         Either the local or foreign port was improperly specified.


         The connection specified by the port pair is not currently in


         Can't determine connection owner; reason unknown.  Other values
         may be specified as necessary.


   Unfortunately, the trustworthiness of the various host systems that
   might implement an authentication server will vary quite a bit.  It
   is up to the various applications that will use the server to
   determine the amount of trust they will place in the returned
   information.  It may be appropriate in some cases restrict the use of
   the server to within a locally controlled subnet.


   1) Automatic user authentication for FTP

      A user-FTP may send a USER command with no argument to the
      server-FTP to request automatic authentication.  The server-FTP
      will reply with a 230 (user logged in) if it can use the
      authentication.  It will reply with a 530 (not logged in) if it
      cannot authenticate the user.  It will reply with a 500 or 501
      (syntax or parameter problem) if it does not implement automatic
Show full document text