Next go around on 931

[Mike StJohns <[e-mail]>]

Here's the next version.  Open issues include user id character sets,
the relationship of the opsys field to the user id, some of the
wording in the security considerations section.

Mike

Network Working Group                                       Mike StJohns
Request for Comments:                                                DOD
Supersedes: RFC912, RFC931                                    April 1992

			Identification Server


STATUS OF THIS MEMO

INTRODUCTION

   The Identification 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.

   The Identification Server Protocol was formerly called the
   Authentication Server Protocol.  It has been renamed to better
   reflect its function.

OVERVIEW

   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.

RESTRICTIONS

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


QUERY/RESPONSE FORMAT

   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 (where
   the "ident" server is running) system, and <foreign-port> is the TCP
   port (decimal) on the source (client) system.
   
   N.B - "local" and "foreign" are relative.  If there is a TCP
   connection from host A to host B, <local-port> on host A equals
   <foreign-port> on host B and <foreign-port> on host A equals
   <local-port> on host B.  If a client on host A wants to ask a
   server on host B about a connection specified locally as 23, 6191
   (an inbound TELNET connection), the client must actually ask about
   6191, 23 - which is how the connection would be specified on host
   B.

      For example:

         6191, 23

   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.
   
   The information returned is that associated with the fully
   specified TCP connection identified by <local-host>,
   <foreign-host>, <local-port>, <foreign-port>, where <local-host>
   and <foreign-host> are the local and foreign IP addresses of the
   querying connection -- i.e. the TCP connection to the Identity
   Protocol Server.  (<local-port> and <foreign-port> are taken from
   the query.)

      For example:

         6193, 23 : USERID : UNIX : stjohns
         6195, 23 : ERROR : NO-USER

RESPONSE TYPES

   A response can be one of two types:

   USERID

      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 system running
      the ident server.  N.B. This is a change from the RFC931
      specification.  The user identification string returned by this
      protocol, its syntax, and relative meaning may vary from
      implementation to implementation and from host to host.

[[[ I *don't* like this - I think its a mistake.  Dan claims "current
      practice" so I put it in - but it will probably come back out
      again unless I hear reasons to the contrary]]]

      Permitted operating system names are specified in RFC-1060,
      "Assigned Numbers" or its successors.  The only other name
      permitted is "OTHER" to specify any operating system not yet
      registered with the IANA (Internet Assigned Numbers Authority).
      "OTHER" should also be used to represent unregistered operating
      system types.  It MAY optionally be used in place of a
      registered OS to hide such information.


   ERROR

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

      INVALID-PORT

         Either the local or foreign port was improperly specified.
	 This should be returned if either or both of the port ids
         were out of range (TCP port #s are from 1-65535), negative
         integers, reals or in any fashion not recognized as a
         non-negative integer.

      NO-USER

         The connection specified by the port pair is not currently in
         use or currently not owned by an identifiable entity.

      UNKNOWN-ERROR

         Can't determine connection owner; reason unknown.  Any error
         not covered above should return this error code value.
	 Optionally, this code MAY be returned in lieu of "NO-USER" or
	 "INVALID-PORT" to hide such information.  If a server
	 implements such a feature, it MUST be configurable and it
	 MUST default to returning the proper error message.

   Other values may eventually be specified and defined in future
   revisions to this document.  If an implementer has a need to
   specify a non-standard error code, that code must begin with "X-".

   In addition, the server is allowed to drop the query connection
   without responding.  Any close, whether graceful or an abort should
   be considered to have the same meaning as "ERROR : UNKNOWN-ERROR".

[[[Again - Dan claims current practice - I think its a mistake.  If
   you blow up on query, you should tell the asker why, if only to keep him
   from asking again.  In absence of a negative answer, how do you
   know when to stop asking?  Closing the connection feels too much
   like laziness.  Also, what happens if you close the connection
   halfway through the userid or maybe even half way through the OPSYS?]]]


FORMAL SYNTAX

   <request> ::= <port-pair> <CR> <LF>

   <port-pair> ::= <integer> "," <integer>

   <reply> ::= <reply-text> <CR> <LF>

   <reply-text> ::= <error-reply> | <auth-reply>

   <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>

   <auth-reply> ::= <port-pair> ":" "USERID" ":" <opsys> ":" <user-id>

   <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
                /   |  <error-token>

   <opsys> ::= "OTHER" | "MULTICS" | "UNIX" | <token> ...etc.  (See
      "Assigned Numbers")

   <user-id>   ::= <octet-string>

   <token>     ::= 1*64<token-characters> ; 1-64 characters

   <error-token> ::= "X"<token>

   <integer>     ::= 1*5<digit> ; 1-5 digits.

   <digit> ::= "0" | "1" ... "8" | "9" ; 0-9

   <token-characters> ::= <Any of these ASCII characters: a-z, A-Z, /
      - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[];\| > ; upper and
      lowercase a-z plus printables minus ; the colon ":" character.

   <octet-string> ::= 1*512<octet-characters>

   <octet-characters> ::= <any octet from 0 to '377 (octal) except for
      / ASCII NUL, CR and LF>

[[[The subject of character sets is still an open one - at least in
   the userid string.  Does anyone have objections to restricting
   everything except the userid to the NET-ASCII character set? 

   I've changed userid from a token to octet string pending the
   closing of the character set issue.]]]

   Notes on Syntax:

      1) White space (blanks and tab characters) between tokens is not
      important and may be ignored.  White space may occur anywhere,
      except within a token -- specifically, any amount of white space
      is permitted at the beginning or end of a line both for queries
      and responses.  Note that this does not apply for responses that
      contain a user ID -- everything after the colon after the
      operating system type until the terminating CR/LF is taken as
      part of the user ID.  The terminating CR/LF is NOT considered
      part of the user ID.
      
      2) Note that neither whitespace nor the ":" character may appear
      within a token.  If there is a need to represent a colon or
      whitespace within a token, continguous whitespace within the
      value to be represented as a token should be replaced by a
      single dash (ASCII ?), and the ":" (colon) character should be
      replaced by ".." (period period - a colon on its side).
      
      3) For purposes of comparison for all fields, uppercase is
      distinct from lower case.  I.e. "Error" and "ERROR" are not the
      same value.

      4)  Any additional <error-type>s must also be <token>s. 

      5) The 512 character limit on user IDs and the 64 character
      limit on tokens should be understood to mean as follows: a) No
      new token (i.e. OPSYS or ERROR-TYPE) token will be defined that
      has a length greater than 64 and b) a server SHOULD NOT send
      more than 512 octets of user ID and a client MUST accept at
      least 512 octets of user ID.  Because of this limitation, a
      server MUST return the most significant portion of the user ID
      in the first 512 octets.

Notes on User Identifier:

   The user identifier returned by the server should be the standard
   one for the system.  Usually, but not always, this has the same
   value and format as a users mailing address.

Security Considerations:


   The information returned by this protocol is at most as trustworthy
   as the host providing it OR the organization operating the host.
   For example, a PC in an open lab has few if any controls on it to
   prevent a user from having this protocol return any identifier the
   user wants.  Likewise, if the host has been compromised the
   information returned may be completely erroneous and misleading.

   The Identity Protocol is not a security protocol.  At best it
   provides some additional auditing information with respect to TCP
   connections.  At worse it can provide misleading, incorrect or
   maliciously incorrect information.  UNDER NO CIRCUMSTANCES should
   information returned from an Identity Protocol server be used to
   make access control decisions - either as the primary method (i.e
   no other checks) or as an adjunct to other methods.

   A server for this protocol provides information roughly as revealing
   as that returned by the "finger" server and protocol.  If you
   wouldn't run a "finger" server due to privacy considerations you
   may not want to run this protocol.


ACKNOWLEDGEMENTS:

   Acknowledgement is given to Dan Bernstein who is primarily
   responsible for renewing interest in this protocol and for pointing
   out some annoying errors in RFC931.