New Version - at last

[Mike StJohns <[e-mail]>]

Sorry for the editing delays - here's the new draft which incorporates
the changes from the IETF and some of the chatting we did here.  Let
me know if I've made any stupid editing errors.  I'm not particularly
happy with with wording about userids (I was hoping for more
definition and less example - i.e. "I know a userid when I see
one"...) so I'd appreciate specific wording comments there.  With or
without changes I'll be sending this forward as an ID by next Tuesday.

Mike


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

			Identification Server


STATUS OF THIS MEMO

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts).

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

   This Draft expires: 1 December 1992.



INTRODUCTION

   The Identification Server Protocol (aka the Ident Protocol, aka the
   Identification 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 or octet 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 server may then either shut the connection down or
   it may continue to read/respond to multiple queries.
 
   The server should close the connection down after a configurable
   amount of time with no queries - a 60-180 second idle timeout is
   recommended.  The client may close the connection down at any time,
   however to allow for network delays the client should wait at least
   30 seconds (or longer) after a query before abandoning the query
   and closing the connection.


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 (with an optional character set
      identifier), followed by a ":", followed by identification
      string.  

      The character set (if present) is separated from the operating
      system name by ",".  The character set identifier is used to
      indicate the character set of the identification string.  If a
      character set identifier is omitted, the identification string
      is assumed to be in "US-ASCII".

      Permitted operating system names and character set names are
      specified in RFC-1060, "Assigned Numbers" or its successors.

      [Note that "Assigned Numbers" does not currently list character
      set names but should eventually include them both as a source
      for this protocol and as the result of the work of the MIME
      mail extensions working group.]

      In addition to those operating system and character set names
      specified in "Assigned Numbers" there is one special case
      operating system identifier - "OTHER" and one special case
      character set name - "OCTET".

      Unless "OTHER" is specified as the operating system type, the
      server is expected to return the "normal" user identification of
      the owner of this connection.  "Normal" in this context may be
      taken to mean a string of characters which uniquely identifies
      the connection owner such as a user identifier assigned by the
      system administrator and used by such user as a mail identifier,
      or as the "user" part of a user/password pair used to gain
      access to system resources.  When an operating system is
      specified (e.g. anything but "OTHER"), the user identifier is
      expected to be in a more or less immediately useful form - e.g.
      something that could be used as an argument to "finger" or as a
      mail address.

      "OTHER" indicates the identifier is an unformatted character
      string consisting of printable characters in the specified
      character set (or an octet string if "OCTET" is the character
      set).  "OTHER" should be specified if the user identifier does
      not meet the constraints of the previous paragraph.  Sending an
      encrypted audit token, or returning other non-userid information
      about a user (such as the real name and phone number of a user
      from a UNIX passwd file) are both examples of when "OTHER"
      should be used.

      With the exception of those responses with "OCTET" character set
      name, returned user identifiers are expected to be printable in
      the character set indicated (or in the US-ASCII character set if
      no character set is indicated).  "OCTET" indicates the
      identifier is an unformatted octet string - all octets are
      permissible EXCEPT \000 (NUL), \012 (LF) and \015 (CR).  N.B. -
      space characters (\040) following the colon separator ARE part
      of the identifier string and may not be ignored. A response
      containing an OCTET string is still terminated normally by a
      CR/LF.  N.B. An "OCTET" string may be printable, but is not
      *necessarily* printable.

   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.

      HIDDEN-USER
    
         The server was able to identify the user of this port, but
         the information was not returned at the request of the user.

      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 premature close (i.e. one where the client
   does not receive the EOL, whether graceful or an abort should be
   considered to have the same meaning as "ERROR : UNKNOWN-ERROR".



FORMAL SYNTAX

   <request> ::= <port-pair> <EOL>

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

   <reply> ::= <reply-text> <EOL>

   <EOL> ::= "\015\012"  ; CR-LF End of Line Indicator

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

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

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

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

   <opsys-field> ::= <opsys> [ "," <charset>]

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

   <charset> ::= "OCTET" | "US-ASCII" | ...etc.   ;  (See "Assigned Numbers")

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

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

   <error-token> ::= "X"1*63<token-characters>  ; 2-64 chars beginning w/X

   <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 \000 to \377 (octal) except for
      / ASCII NUL (\000), CR (\015) and LF (\012)>

   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) For purposes of comparison for all fields except the
      <user-id> field, uppercase is not distinct from lower case.
      I.e.  "Error" and "ERROR" are the same value.
 
      3) Servers should restrict the amount of inter-token white space
      they send to the smallest amount reasonable or useful.  Clients
      should feel free to abort a connection if they receive 1000
      characters without receiving an <EOL>.

      4) 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.

      5) The character sets and character set identifiers should map
      directly to those specified and used by the MIME Mail
      extensions.  Character set identifiers only apply to the user
      identification field - all other fields will be defined in and
      must be sent as US-ASCII.

      6) Although <user-id> is defined as an <octet-string> above, it
      must follow the format and character set constraints implied by
      the <opsys-field>; see the discussion above.

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 intended as an authorization or access
   control protocol.  At best, it provides some additional auditing
   information with respect to TCP connections.  At worst, it can
   provide misleading, incorrect, or maliciously incorrect
   information.

   The use of the information returned by this protocol for other than
   auditing is strongly discouraged.  Specifically, using Identity
   Protocol information to make access control decisions - either as
   the primary method (i.e no other checks) or as an adjunct to other
   methods may result in a weakening of normal host security.

   An Ident server may reveal information about users, entities,
   objects or processes which might normally be considered private.
   An Ident server provides service which is a rough analog of the
   CallerID (tm) services provided by some phone companies and many of
   the same privacy considerations and arguments that apply to the
   CallerID service apply to Ident.  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.