GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1413

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.

St. Johns [Page 1] RFC 1413 Identification Protocol February 1993

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

St. Johns [Page 2] 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 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

St. Johns [Page 3] RFC 1413 Identification Protocol February 1993

   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

St. Johns [Page 4] RFC 1413 Identification Protocol February 1993

        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

St. Johns [Page 5] 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)   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

St. Johns [Page 6] 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
      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.

St. Johns [Page 7] RFC 1413 Identification Protocol February 1993

 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

St. Johns [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1413.txt · Last modified: 1993/02/02 21:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki