Once more -

[Mike StJohns <[e-mail]>]

This is the up-to-date draft - final comments before I submit it as an
ID?  Major changes from last draft are making OCTET a character set vs
an operating system ID and making OCTET the default character set.

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 "ident", 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 a line of data which specifies the
   connection of interest.  If it exists, the system dependent user
   identifier of the connection of interest is sent as the reply.  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

      <port-on-server> , <port-on-client>

   where <port-on-server> is the TCP port (decimal) on the target (where
   the "ident" server is running) system, and <port-on-client> is the TCP
   port (decimal) on the source (client) system.
   
   N.B - If a client on host A wants to ask a server on host B about a
   connection specified locally (on the client's machine) 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

   <port-on-server> , <port-on-client> : <response-type> : <addnl-info>

   where <port-on-server>,<port-on-client> are the same pair as the query,
   <response-type> is a keyword identifying the type of response, and
   <addnl-info> is context dependent.
   
   The information returned is that associated with the fully
   specified TCP connection identified by <server-address>,
   <client-address>, <port-on-server>, <port-on-client>, where
   <server-address> and <client-address> are the local and foreign IP
   addresses of the querying connection -- i.e. the TCP connection to
   the Identity Protocol Server.  (<port-on-server> and
   <port-on-client> 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, <addnl-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.  The
      character set identifier, if omitted, defaults to "OCTET" (see
      below). 

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

      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 (i.e. the default), returned user identifiers are expected
      to be printable in the character set 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,
      <addnl-info> tells why.  The following are the permitted
      values of <addnl-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 defined or reference by RFC-1340, "Assigned
      Numbers" or its successors.  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.