Identification Protocol
draft-ietf-ident-idserver-02

Network Working Group                             M StJohns
                                      Department of Defense
                                                August 1992

                   Identification Server

1.  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.

2.  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.

3.  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

Draft - Exp 1/93            -1-

Ident WG                                      M StJohns, DoD

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.

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

5.  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> : <resp-type> : <add-info>

where <port-on-server>,<port-on-client> are the same pair as

Draft - Exp 1/93            -2-

Ident WG                                      M StJohns, DoD

the query, <resp-type> is a keyword identifying the type of
response, and <add-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

6.  RESPONSE TYPES

     A response can be one of two types:

USERID

     In this case, <add-info> is a string consisting of an
     operating system name (with an optional character set
     identifier), followed by ":", followed by an
     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

Draft - Exp 1/93            -3-

Ident WG                                      M StJohns, DoD

     "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  00
     (NUL),  12 (LF) and  15 (CR).  N.B. - space characters
     ( 40) 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 port owner could not be determined,
     <add-info> tells why.  The following are the permitted
     values of <add-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

Draft - Exp 1/93            -4-

Ident WG                                      M StJohns, DoD

          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 any other specific error code
          if, for example, the server desires to hide
          information implied by the return of that error
          code, or for any other reason.  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".

Draft - Exp 1/93            -5-

Ident WG                                      M StJohns, DoD

FORMAL SYNTAX

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

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

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

   <EOL> ::= " 15 12"  ; 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  00 to 377 (octal) except for
                   ASCII NUL ( 00), CR ( 15) and LF ( 12)>

Notes on Syntax:

Draft - Exp 1/93            -6-

Ident WG                                      M StJohns, DoD

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.

7)   The character set provides context for the client to
     print or store the returned user identification string.
     If the client does not recognize or implement the
     returned character set, it should handle the returned
     identification string as OCTET, but should in addition
     store or report the character set.  An OCTET string
     should be printed, stored or handled in hex notation
     (0-9a-f) in addition to any other representation the
     client implements - this provides a standard
     representation among differing implementations.

Draft - Exp 1/93            -7-

Ident WG                                      M StJohns, DoD

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

8.  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.

Draft - Exp 1/93            -8-