 Network Working Group                                        M. St. Johns
 Request for Comments: 1413                       US Department of Defense
 Obsoletes: 931                                              February 1993

                          Identification Protocol

Status of this Memo

This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements. Please
refer to the current edition of the "IAB Official Protocol Standards" for
the standardization state and status of this protocol. Distribution of this
memo is unlimited.

1. INTRODUCTION

The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident 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 Protocol was formerly called the Authentication Server
Protocol. It has been renamed to better reflect its function. This document
is a product of the TCP Client Identity Protocol Working Group of the
Internet Engineering Task Force (IETF).

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

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

4. QUERY/RESPONSE FORMAT

The server accepts simple text query requests of the form:

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

where is the TCP port (decimal) on the target (where the "ident" server is
running) system, and 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 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 Identification 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

5. 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 "US-ASCII" (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".

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

     Returned user identifiers are expected to be printable in the character
     set indicated.

     The identifier is an unformatted octet string - - all octets are
     permissible EXCEPT octal 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 string is still
     terminated normally by a CR/LF. N.B. A 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 numbers 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 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".

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"
                            | "HIDDEN-USER" |  <error-token>

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

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

           <charset> ::= "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 (000), CR (015) and LF (012)>

Notes on Syntax:

  1. To promote interoperability among variant implementations, with respect
     to white space the above syntax is understood to embody the "be
     conservative in what you send and be liberal in what you accept"
     philosophy. Clients and servers should not generate unnecessary white
     space (space and tab characters) but should accept white space anywhere
     except within a token. In parsing responses, 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. This does not apply for responses that contain a user ID
     because 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. The above notwithstanding, 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>.

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

  4. The character sets and character set identifiers should map directly to
     those defined in or referenced 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.

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

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

6. 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 Identification 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 Identification 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 Identification server may reveal information about users, entities,
objects or processes which might normally be considered private. An
Identification server provides service which is a rough analog of the
CallerID services provided by some phone companies and many of the same
privacy considerations and arguments that apply to the CallerID service
apply to Identification. If you wouldn't run a "finger" server due to
privacy considerations you may not want to run this protocol.

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

References

  1. St. Johns, M., "Authentication Server", RFC 931, TPSC, January 1985.

  2. Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
     USC/Information Sciences Institute, July 1992.

Author's Address

     Michael C. St. Johns
     DARPA/CSTO
     3701 N. Fairfax Dr
     Arlington, VA 22203

     Phone: (703) 696-2271
     EMail: stjohns@DARPA.MIL
