Network Working Group                                       D. Bernstein
INTERNET DRAFT                                                        IR
                                           June 1991, revised March 1992

                            Identity Server


Status of This Memo

   This is an Internet Draft. Distribution is unlimited.


1. Introduction

   <Note to the I-D reader: I requested in July 1991 that the ``authd
   protocol'' be moved along the standards track, eventually to become a
   Standard with Recommended status. The IETF has taken no action
   relevant to my request. The protocol is in use at hundreds of sites,
   is supported on the client side by multiple interoperable
   implementations and on the server side by several applications
   including the wuarchive ftpd, and has not changed for two years. This
   is the current authd protocol spec. It is not an IAB Standard. I hope
   you find it useful anyway.>

   It is common for Internet hosts to associate a relatively long-lived
   identifier, often called a username or owner name, to each TCP
   connection. The Identity Server announces the identifier associated
   with a particular TCP connection to the host on the other end of the
   connection. The Identity Server may be used on any host which
   associates a relatively long-lived identifier to each connection.

   Note that RFC 931 purported to specify an "Authentication Server."
   In fact, it was a specification for a server that asserted the
   identity of the user of a TCP connection, and the protocol has been
   renamed accordingly. The confidence in (and in fact any meaning of)
   the identifier as asserted depended on information outside the scope
   of the protocol. For example, within a cooperating community of
   hosts, such as a local area network under a single administrative
   control, the asserted identifiers could be believed (and assigned
   meaning) with high confidence.


2. Overview

   This is a connection-based application which runs over TCP. The
   server listens for TCP connections on port 113 (decimal). After a
   connection is established, the server reads one line of data which
   specifies the connection of interest. If that connection exists and
   is associated with a system-dependent identifier, the server sends
   the identifier. Otherwise it sends an error line. After sending the
   identifier or error line, the server closes its connection.

   The server will give information about TCP connections between the
   server's host and host H only to host H itself. The two hosts (i.e.,
   IP addresses) involved are not transmitted explicitly by the
   protocol; they are implicit in the connection made to the server.


3. Request format

   The server accepts simple text query requests of the form

      <localport> , <foreignport>

   where <localport> is the TCP port on the server's host and
   <foreignport> is the TCP port on the client's host. All numbers are
   expressed in decimal without a sign, and all text is ASCII. If the
   request is not in this format, the server may immediately drop the
   connection.

   For example, say user joe@rose connects to the standard TELNET port
   on host tulip, through TCP ports 6191 on rose and 23 on tulip. (In
   other words, let's say this connection exists, and rose associates
   the identifier joe to it. Note that rose and tulip are simply names
   used in this document to identify two IP-connected machines. They are
   not fully qualified domain names.) tulip connects to the Identity
   Server at port 113 on rose. It sends this line:

      6191 , 23

   Here 6191 is the TCP port on the server's host (rose) and 23 is the
   TCP port on the client's host (tulip). This uniquely specifies the
   given TELNET connection.

   The precise format of the request line is as follows: <localport>,
   followed by any amount of whitespace, followed by a comma and any
   amount of whitespace, followed by <foreignport>, followed by carriage
   return and line feed. Whitespace means space or tab; "any amount"
   means zero or more, though a client should not print excessively many
   spaces. The client should not send anything after the line feed; the
   server should ignore everything after the line feed. The client should
   not add initial zeros to its decimal numbers, but the server must
   accept such numbers. Future revisions of this standard may assign
   additional meaning to decimals with a leading 0.


4. Response format

   The server sends a response line in one of these two formats:

      <localport> , <foreignport> : USERID : <systemtype> : <identifier>
   or
      <localport> , <foreignport> : ERROR : <errortype>

   Here <localport> and <foreignport> are the same numbers as in the
   query. (If the client uses initial zeros, the server may do so as
   well, but otherwise it should not use initial zeros.) <systemtype> is
   an operating system name for the server's host as described in
   Assigned Numbers, RFC 1060 or its successors. <identifier> is a
   system-dependent identifier. <errortype> is text describing an error
   as outlined below.

   <systemtype> may also be OTHER to specify any other operating system
   not yet listed in Assigned Numbers. Even if the server's system is
   listed in Assigned Numbers, the server may use OTHER for any reason,
   including operating system type privacy.

   <identifier> is in some format defined by the system. This standard
   does not define the format or meaning of <identifier>. <identifier>
   is typically in the same format as a system-dependent mailbox name,
   which is typically in the same format as a system-dependent username,
   but these equivalences are not required.

   For example, some possible responses to the 6191 , 23 query might be
   the following:

      6191 , 23 : USERID : UNIX : joe
      6191 , 23 : USERID : MULTICS : StJohns.DODCSC.a
      6191 , 23 : USERID : OTHER : StJohns.DODCSC.a
      6191 , 23 : USERID : TAC : MCSJ-MITMUL
      6191 , 23 : ERROR : NO-USER
      6191,23     :USERID:OTHER:wewishyouamerrychristmasandahappynewyear

   An ERROR line means that the server could not determine the
   identifier associated to the TCP connection. <errortype> tells why.
   <errortype> may be any of the following:

      INVALID-PORT

	 <localport> or <foreignport> was improperly specified---out of
	 the range 0 to 65535, for example---or the request was
	 otherwise nonstandard. In this case the server may drop the
	 connection without replying.

      NO-USER

         The connection specified by the port pair is not currently in
         use.

      UNKNOWN-ERROR

         Cannot determine the identifier associated to the connection,
	 for an unknown reason. The server may give this <errortype> in
	 any case and for any reason, including privacy, whether or not
	 another <errortype> applies.

   Other <errortype> values may be specified as necessary. The server
   may also report an <errortype> beginning with the letter X; all such
   <errortype>s are reserved for experimental or nonstandard use.

   The precise format of the response line is as follows: <localport>,
   followed by any amount of whitespace, followed by a comma and any
   amount of whitespace, followed by <foreignport>, followed by any
   amount of whitespace, followed by a colon and any amount of
   whitespace. In the USERID case, it is then followed by USERID and any
   amount of whitespace, a colon and any amount of whitespace,
   <systemtype> and any amount of whitespace, one or more characters
   giving <identifier>, and finally carriage return and line feed. In
   the ERROR case, it is followed by ERROR and any amount of whitespace,
   a colon and any amount of whitespace, one or more characters giving
   <errortype>, and finally carriage return and line feed.

   Note that this format is ambiguous if <systemtype> contains colons or
   whitespace. Assigned Numbers does not currently list any <systemtype>
   with colons or whitespace, but if it ever does, the Identity Server
   must use OTHER for the <systemtype> on such a machine. The server
   should also not use a <systemtype> containing carriage return or line
   feed.

   Similarly, if <identifier> or <errortype> begins with whitespace or
   contains carriage return-line feed, the response line format is
   ambiguous. The server must never use <errortype> containing
   whitespace, carriage return, or line feed, and future revisions of
   this RFC will never provide for such an <errortype>. The server
   cannot send <identifier> beginning with whitespace or containing
   carriage return-line feed; it should not send <identifier> containing
   whitespace, carriage return, or linefeed. ERROR : UNKNOWN-ERROR is
   preferable.

   Finally, <systemtype>, <identifier>, and <errortype> cannot be empty
   strings, and cannot contain ASCII nul (character 0).


5. Security

   The identifier returned by the Identity Server on a host is under the
   complete control of that host, and hence has a meaning completely
   determined by whatever entities determine the actions of that host.
   Attempts to interpret <identifier> outside the context of the host
   will, in the experience of the author, inevitably lead to security
   violations. Therefore the client must never use an identifier without
   also keeping track of the IP address whose Identity Server generated
   the identifier. When possible it should also keep track of the domain
   name corresponding to that IP address.

   The scope of this document is limited to the definition of the
   Identity Server protocol. Applications are not discussed here.
   Implementors are advised that no guarantees are made in this document
   as to the validity, security, authenticity, or usefulness of the data
   returned by the Identity Server. Implementors are also advised that
   there is no a priori reason to believe that a server running on port
   113 of a particular Internet host is, in fact, the Identity Server.

   The reader is warned that there is some debate over the proper use of
   the Identity Server. It is planned that future RFCs will document the
   various applications of the Identity Server and illustrate how the
   server may be used properly. In the meantime the reader is encouraged
   to exercise caution and logic in his use of the Identity Server. In
   particular, note that the Identity Server, like many other network
   protocols, is a means by which a host can announce certain
   information; the statement "host X announces that Z is true" does not
   logically imply the statement "Z is true." In particular, the
   statement "host X announces that user U is associated with connection
   C" does not logically imply the statement "user U is associated with
   connection C."

   At this time there is a non-IETF mailing list whose participants
   discuss the use of the Identity Server; to join, send mail to
   rfc931-users-request@kramden.acf.nyu.edu. Official discussions of the
   standardization of the Identity Server currently take place on the
   SAAG list, saag@tis.com.


Author's Address

   Daniel J. Bernstein
   5 Brewster Lane
   Bellport, NY 11713

   Phone:  516-286-1339

   Email:  brnstnd@nyu.edu