            H Network Working Group                                       M. St. JohnsH Request for Comments: 1413                      US Department of DefenseH Obsoletes: 931                                             February 1993    /                         Identification Protocol    Status of this Memo   F    This RFC specifies an IAB standards track protocol for the InternetG    community, and requests discussion and suggestions for improvements. D    Please refer to the current edition of the "IAB Official ProtocolH    Standards" for the standardization state and status of this protocol.*    Distribution of this memo is unlimited.   1.  INTRODUCTION  C    The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident G    Protocol") provides a means to determine the identity of a user of a G    particular TCP connection.  Given a TCP port number pair, it returns F    a character string which identifies the owner of that connection on    the server's system.   E    The Identification Protocol was formerly called the Authentication H    Server Protocol.  It has been renamed to better reflect its function.A    This document is a product of the TCP Client Identity Protocol ?    Working Group of the Internet Engineering Task Force (IETF).    2.  OVERVIEW  G    This is a connection based application on TCP.  A server listens for C    TCP connections on TCP port 113 (decimal).  Once a connection is C    established, the server reads a line of data which specifies the C    connection of interest.  If it exists, the system dependent user F    identifier of the connection of interest is sent as the reply.  TheH    server may then either shut the connection down or it may continue to$    read/respond to multiple queries.  C    The server should close the connection down after a configurable C    amount of time with no queries - a 60-180 second idle timeout is F    recommended.  The client may close the connection down at any time;F    however to allow for network delays the client should wait at leastG    30 seconds (or longer) after a query before abandoning the query and     closing the connection.              H St. Johns                                                       [Page 1]  H RFC 1413                Identification Protocol            February 1993     3.  RESTRICTIONS  C    Queries are permitted only for fully specified connections.  The B    query contains the local/foreign port pair -- the local/foreignF    address pair used to fully specify the connection is taken from theG    local and foreign address of query connection.  This means a user on E    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>   H    where <port-on-server> is the TCP port (decimal) on the target (whereE    the "ident" server is running) system, and <port-on-client> is the 4    TCP port (decimal) on the source (client) system.  F    N.B - If a client on host A wants to ask a server on host B about aE    connection specified locally (on the client's machine) as 23, 6191 E    (an inbound TELNET connection), the client must actually ask about G    6191, 23 - which is how the connection would be specified on host B.          For example:                    6191, 23       The response is of the form  A    <port-on-server> , <port-on-client> : <resp-type> : <add-info>   C    where <port-on-server>,<port-on-client> are the same pair as the H    query, <resp-type> is a keyword identifying the type of response, and#    <add-info> is context dependent.   G    The information returned is that associated with the fully specified C    TCP connection identified by <server-address>, <client-address>, A    <port-on-server>, <port-on-client>, where <server-address> and A    <client-address> are the local and foreign IP addresses of the H    querying connection -- i.e., the TCP connection to the IdentificationE    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       H St. Johns                                                       [Page 2]  H RFC 1413                Identification Protocol            February 1993     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 set1      identifier), followed by ":", followed by an       identification string.   9      The character set (if present) is separated from the 5      operating system name by ",".  The character set <      identifier is used to indicate the character set of the:      identification string.  The character set identifier,4      if omitted, defaults to "US-ASCII" (see below).  7      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 set7      names specified in "Assigned Numbers" there is one 8      special case operating system identifier - "OTHER".  8      Unless "OTHER" is specified as the operating system8      type, the server is expected to return the "normal"9      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 2      administrator and used by such user as a mail9      identifier, or as the "user" part of a user/password ;      pair used to gain access to system resources.  When an 6      operating system is specified (e.g., anything but9      "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.  7      "OTHER" indicates the identifier is an unformatted ;      character string consisting of printable characters in 4      the specified character set.  "OTHER" should be7      specified if the user identifier does not meet the 7      constraints of the previous paragraph.  Sending an 9      encrypted audit token, or returning other non-userid 8      information about a user (such as the real name and8      phone number of a user from a UNIX passwd file) are      H St. Johns                                                       [Page 3]  H RFC 1413                Identification Protocol            February 1993    2      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 and3      may not be ignored. A response string is still :      terminated normally by a CR/LF.  N.B. A string may be3      printable, but is not *necessarily* printable.    ERROR   E    For some reason the port owner could not be determined, <add-info> G    tells why.  The following are the permitted values of <add-info> and     their meanings:             INVALID-PORT  9           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 or9           in any fashion not recognized as a non-negative            integer.             NO-USER   :           The connection specified by the port pair is not7           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. 8           Any error not covered above should return this9           error code value.  Optionally, this code MAY be ;           returned in lieu of any other specific error code 5           if, for example, the server desires to hide 9           information implied by the return of that error       H St. Johns                                                       [Page 4]  H RFC 1413                Identification Protocol            February 1993    5           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.  A    Other values may eventually be specified and defined in future G    revisions to this document.  If an implementer has a need to specify <    a non-standard error code, that code must begin with "X".  B    In addition, the server is allowed to drop the query connectionG    without responding.  Any premature close (i.e., one where the client C    does not receive the EOL, whether graceful or an abort should be B    considered to have the same meaning as "ERROR : UNKNOWN-ERROR".  
 FORMAL SYNTAX   "    <request> ::= <port-pair> <EOL>  *    <port-pair> ::= <integer> "," <integer>  !    <reply> ::= <reply-text> <EOL>   5    <EOL> ::= "015 012"  ; CR-LF End of Line Indicator   1    <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"4                     | "HIDDEN-USER" |  <error-token>  -    <opsys-field> ::= <opsys> [ "," <charset>]   1    <opsys> ::= "OTHER" | "UNIX" | <token> ...etc. *                ;  (See "Assigned Numbers")  %    <charset> ::= "US-ASCII" | ...etc. ,                  ;  (See "Assigned Numbers")      <user-id> ::= <octet-string>   7    <token> ::= 1*64<token-characters> ; 1-64 characters   .    <error-token> ::= "X"1*63<token-characters>/                      ; 2-64 chars beginning w/X       H St. Johns                                                       [Page 5]  H RFC 1413                Identification Protocol            February 1993    )    <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    1)   To promote interoperability among variant >         implementations, with respect to white space the above>         syntax is understood to embody the "be conservative in8         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>.  6    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       H St. Johns                                                       [Page 6]  H RFC 1413                Identification Protocol            February 1993    ;         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 C         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 set9         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. 9         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 the4         client implements - this provides a standard7         representation among differing implementations.    6.  Security Considerations   F    The information returned by this protocol is at most as trustworthyH    as the host providing it OR the organization operating the host.  ForH    example, a PC in an open lab has few if any controls on it to preventB    a user from having this protocol return any identifier the userE    wants.  Likewise, if the host has been compromised the information 7    returned may be completely erroneous and misleading.   E    The Identification Protocol is not intended as an authorization or A    access control protocol.  At best, it provides some additional F    auditing information with respect to TCP connections.  At worst, it>    can provide misleading, incorrect, or maliciously incorrect    information.   F    The use of the information returned by this protocol for other thanH    auditing is strongly discouraged.  Specifically, using IdentificationH    Protocol information to make access control decisions - either as theC    primary method (i.e., no other checks) or as an adjunct to other =    methods may result in a weakening of normal host security.         H St. Johns                                                       [Page 7]  H RFC 1413                Identification Protocol            February 1993    ?    An Identification server may reveal information about users, D    entities, objects or processes which might normally be consideredG    private.  An Identification server provides service which is a rough G    analog of the CallerID services provided by some phone companies and F    many of the same privacy considerations and arguments that apply toG    the CallerID service apply to Identification.  If you wouldn't run a H    "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 F    responsible for renewing interest in this protocol and for pointing'    out some annoying errors in RFC 931.   
 References  E    [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January         1985.  H    [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,5        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                                       H St. Johns                                                       [Page 8]  