home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1413 < prev    next >
Text File  |  1993-02-10  |  16KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       M. St. Johns
  8. Request for Comments: 1413                      US Department of Defense
  9. Obsoletes: 931                                             February 1993
  10.  
  11.  
  12.                         Identification Protocol
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. 1.  INTRODUCTION
  23.  
  24.    The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident
  25.    Protocol") provides a means to determine the identity of a user of a
  26.    particular TCP connection.  Given a TCP port number pair, it returns
  27.    a character string which identifies the owner of that connection on
  28.    the server's system.
  29.  
  30.    The Identification Protocol was formerly called the Authentication
  31.    Server Protocol.  It has been renamed to better reflect its function.
  32.    This document is a product of the TCP Client Identity Protocol
  33.    Working Group of the Internet Engineering Task Force (IETF).
  34.  
  35. 2.  OVERVIEW
  36.  
  37.    This is a connection based application on TCP.  A server listens for
  38.    TCP connections on TCP port 113 (decimal).  Once a connection is
  39.    established, the server reads a line of data which specifies the
  40.    connection of interest.  If it exists, the system dependent user
  41.    identifier of the connection of interest is sent as the reply.  The
  42.    server may then either shut the connection down or it may continue to
  43.    read/respond to multiple queries.
  44.  
  45.    The server should close the connection down after a configurable
  46.    amount of time with no queries - a 60-180 second idle timeout is
  47.    recommended.  The client may close the connection down at any time;
  48.    however to allow for network delays the client should wait at least
  49.    30 seconds (or longer) after a query before abandoning the query and
  50.    closing the connection.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. St. Johns                                                       [Page 1]
  59.  
  60. RFC 1413                Identification Protocol            February 1993
  61.  
  62.  
  63. 3.  RESTRICTIONS
  64.  
  65.    Queries are permitted only for fully specified connections.  The
  66.    query contains the local/foreign port pair -- the local/foreign
  67.    address pair used to fully specify the connection is taken from the
  68.    local and foreign address of query connection.  This means a user on
  69.    address A may only query the server on address B about connections
  70.    between A and B.
  71.  
  72. 4.  QUERY/RESPONSE FORMAT
  73.  
  74.    The server accepts simple text query requests of the form:
  75.  
  76.             <port-on-server> , <port-on-client>
  77.  
  78.    where <port-on-server> is the TCP port (decimal) on the target (where
  79.    the "ident" server is running) system, and <port-on-client> is the
  80.    TCP port (decimal) on the source (client) system.
  81.  
  82.    N.B - If a client on host A wants to ask a server on host B about a
  83.    connection specified locally (on the client's machine) as 23, 6191
  84.    (an inbound TELNET connection), the client must actually ask about
  85.    6191, 23 - which is how the connection would be specified on host B.
  86.  
  87.       For example:
  88.  
  89.                  6191, 23
  90.  
  91.    The response is of the form
  92.  
  93.    <port-on-server> , <port-on-client> : <resp-type> : <add-info>
  94.  
  95.    where <port-on-server>,<port-on-client> are the same pair as the
  96.    query, <resp-type> is a keyword identifying the type of response, and
  97.    <add-info> is context dependent.
  98.  
  99.    The information returned is that associated with the fully specified
  100.    TCP connection identified by <server-address>, <client-address>,
  101.    <port-on-server>, <port-on-client>, where <server-address> and
  102.    <client-address> are the local and foreign IP addresses of the
  103.    querying connection -- i.e., the TCP connection to the Identification
  104.    Protocol Server.  (<port-on-server> and <port-on-client> are taken
  105.    from the query.)
  106.  
  107.       For example:
  108.  
  109.          6193, 23 : USERID : UNIX : stjohns
  110.          6195, 23 : ERROR : NO-USER
  111.  
  112.  
  113.  
  114. St. Johns                                                       [Page 2]
  115.  
  116. RFC 1413                Identification Protocol            February 1993
  117.  
  118.  
  119. 5.  RESPONSE TYPES
  120.  
  121. A response can be one of two types:
  122.  
  123. USERID
  124.  
  125.      In this case, <add-info> is a string consisting of an
  126.      operating system name (with an optional character set
  127.      identifier), followed by ":", followed by an
  128.      identification string.
  129.  
  130.      The character set (if present) is separated from the
  131.      operating system name by ",".  The character set
  132.      identifier is used to indicate the character set of the
  133.      identification string.  The character set identifier,
  134.      if omitted, defaults to "US-ASCII" (see below).
  135.  
  136.      Permitted operating system names and character set
  137.      names are specified in RFC 1340, "Assigned Numbers" or
  138.      its successors.
  139.  
  140.      In addition to those operating system and character set
  141.      names specified in "Assigned Numbers" there is one
  142.      special case operating system identifier - "OTHER".
  143.  
  144.      Unless "OTHER" is specified as the operating system
  145.      type, the server is expected to return the "normal"
  146.      user identification of the owner of this connection.
  147.      "Normal" in this context may be taken to mean a string
  148.      of characters which uniquely identifies the connection
  149.      owner such as a user identifier assigned by the system
  150.      administrator and used by such user as a mail
  151.      identifier, or as the "user" part of a user/password
  152.      pair used to gain access to system resources.  When an
  153.      operating system is specified (e.g., anything but
  154.      "OTHER"), the user identifier is expected to be in a
  155.      more or less immediately useful form - e.g., something
  156.      that could be used as an argument to "finger" or as a
  157.      mail address.
  158.  
  159.      "OTHER" indicates the identifier is an unformatted
  160.      character string consisting of printable characters in
  161.      the specified character set.  "OTHER" should be
  162.      specified if the user identifier does not meet the
  163.      constraints of the previous paragraph.  Sending an
  164.      encrypted audit token, or returning other non-userid
  165.      information about a user (such as the real name and
  166.      phone number of a user from a UNIX passwd file) are
  167.  
  168.  
  169.  
  170. St. Johns                                                       [Page 3]
  171.  
  172. RFC 1413                Identification Protocol            February 1993
  173.  
  174.  
  175.      both examples of when "OTHER" should be used.
  176.  
  177.      Returned user identifiers are expected to be printable
  178.      in the character set indicated.
  179.  
  180.      The identifier is an unformatted octet string - - all
  181.      octets are permissible EXCEPT octal 000 (NUL), 012 (LF)
  182.      and 015 (CR).  N.B. - space characters (040) following the
  183.      colon separator ARE part of the identifier string and
  184.      may not be ignored. A response string is still
  185.      terminated normally by a CR/LF.  N.B. A string may be
  186.      printable, but is not *necessarily* printable.
  187.  
  188. ERROR
  189.  
  190.    For some reason the port owner could not be determined, <add-info>
  191.    tells why.  The following are the permitted values of <add-info> and
  192.    their meanings:
  193.  
  194.           INVALID-PORT
  195.  
  196.           Either the local or foreign port was improperly
  197.           specified.  This should be returned if either or
  198.           both of the port ids were out of range (TCP port
  199.           numbers are from 1-65535), negative integers, reals or
  200.           in any fashion not recognized as a non-negative
  201.           integer.
  202.  
  203.           NO-USER
  204.  
  205.           The connection specified by the port pair is not
  206.           currently in use or currently not owned by an
  207.           identifiable entity.
  208.  
  209.           HIDDEN-USER
  210.  
  211.           The server was able to identify the user of this
  212.           port, but the information was not returned at the
  213.           request of the user.
  214.  
  215.           UNKNOWN-ERROR
  216.  
  217.           Can't determine connection owner; reason unknown.
  218.           Any error not covered above should return this
  219.           error code value.  Optionally, this code MAY be
  220.           returned in lieu of any other specific error code
  221.           if, for example, the server desires to hide
  222.           information implied by the return of that error
  223.  
  224.  
  225.  
  226. St. Johns                                                       [Page 4]
  227.  
  228. RFC 1413                Identification Protocol            February 1993
  229.  
  230.  
  231.           code, or for any other reason.  If a server
  232.           implements such a feature, it MUST be configurable
  233.           and it MUST default to returning the proper error
  234.           message.
  235.  
  236.    Other values may eventually be specified and defined in future
  237.    revisions to this document.  If an implementer has a need to specify
  238.    a non-standard error code, that code must begin with "X".
  239.  
  240.    In addition, the server is allowed to drop the query connection
  241.    without responding.  Any premature close (i.e., one where the client
  242.    does not receive the EOL, whether graceful or an abort should be
  243.    considered to have the same meaning as "ERROR : UNKNOWN-ERROR".
  244.  
  245. FORMAL SYNTAX
  246.  
  247.    <request> ::= <port-pair> <EOL>
  248.  
  249.    <port-pair> ::= <integer> "," <integer>
  250.  
  251.    <reply> ::= <reply-text> <EOL>
  252.  
  253.    <EOL> ::= "015 012"  ; CR-LF End of Line Indicator
  254.  
  255.    <reply-text> ::= <error-reply> | <ident-reply>
  256.  
  257.    <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>
  258.  
  259.    <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
  260.                      ":" <user-id>
  261.  
  262.    <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
  263.                     | "HIDDEN-USER" |  <error-token>
  264.  
  265.    <opsys-field> ::= <opsys> [ "," <charset>]
  266.  
  267.    <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
  268.                ;  (See "Assigned Numbers")
  269.  
  270.    <charset> ::= "US-ASCII" | ...etc.
  271.                  ;  (See "Assigned Numbers")
  272.  
  273.    <user-id> ::= <octet-string>
  274.  
  275.    <token> ::= 1*64<token-characters> ; 1-64 characters
  276.  
  277.    <error-token> ::= "X"1*63<token-characters>
  278.                      ; 2-64 chars beginning w/X
  279.  
  280.  
  281.  
  282. St. Johns                                                       [Page 5]
  283.  
  284. RFC 1413                Identification Protocol            February 1993
  285.  
  286.  
  287.    <integer> ::= 1*5<digit> ; 1-5 digits.
  288.  
  289.    <digit> ::= "0" | "1" ... "8" | "9" ; 0-9
  290.  
  291.    <token-characters> ::=
  292.                   <Any of these ASCII characters: a-z, A-Z,
  293.                    - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >
  294.                                ; upper and lowercase a-z plus
  295.                                ; printables minus the colon ":"
  296.                                ; character.
  297.  
  298.    <octet-string> ::= 1*512<octet-characters>
  299.  
  300.    <octet-characters> ::=
  301.                   <any octet from  00 to 377 (octal) except for
  302.                    ASCII NUL (000), CR (015) and LF (012)>
  303.  
  304. Notes on Syntax:
  305.  
  306.    1)   To promote interoperability among variant
  307.         implementations, with respect to white space the above
  308.         syntax is understood to embody the "be conservative in
  309.         what you send and be liberal in what you accept"
  310.         philosophy.  Clients and servers should not generate
  311.         unnecessary white space (space and tab characters) but
  312.         should accept white space anywhere except within a
  313.         token.  In parsing responses, white space may occur
  314.         anywhere, except within a token.  Specifically, any
  315.         amount of white space is permitted at the beginning or
  316.         end of a line both for queries and responses.  This
  317.         does not apply for responses that contain a user ID
  318.         because everything after the colon after the operating
  319.         system type until the terminating CR/LF is taken as
  320.         part of the user ID.  The terminating CR/LF is NOT
  321.         considered part of the user ID.
  322.  
  323.    2)   The above notwithstanding, servers should restrict the
  324.         amount of inter-token white space they send to the
  325.         smallest amount reasonable or useful.  Clients should
  326.         feel free to abort a connection if they receive 1000
  327.         characters without receiving an <EOL>.
  328.  
  329.    3)   The 512 character limit on user IDs and the 64
  330.         character limit on tokens should be understood to mean
  331.         as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
  332.         token will be defined that has a length greater than 64
  333.         and b) a server SHOULD NOT send more than 512 octets of
  334.         user ID and a client MUST accept at least 512 octets of
  335.  
  336.  
  337.  
  338. St. Johns                                                       [Page 6]
  339.  
  340. RFC 1413                Identification Protocol            February 1993
  341.  
  342.  
  343.         user ID.  Because of this limitation, a server MUST
  344.         return the most significant portion of the user ID in
  345.         the first 512 octets.
  346.  
  347.    4)   The character sets and character set identifiers should
  348.         map directly to those defined in or referenced by RFC 1340,
  349.         "Assigned Numbers" or its successors.  Character set
  350.         identifiers only apply to the user identification field
  351.         - all other fields will be defined in and must be sent
  352.         as US-ASCII.
  353.  
  354.    5)   Although <user-id> is defined as an <octet-string>
  355.         above, it must follow the format and character set
  356.         constraints implied by the <opsys-field>; see the
  357.         discussion above.
  358.  
  359.    6)   The character set provides context for the client to
  360.         print or store the returned user identification string.
  361.         If the client does not recognize or implement the
  362.         returned character set, it should handle the returned
  363.         identification string as OCTET, but should in addition
  364.         store or report the character set.  An OCTET string
  365.         should be printed, stored or handled in hex notation
  366.         (0-9a-f) in addition to any other representation the
  367.         client implements - this provides a standard
  368.         representation among differing implementations.
  369.  
  370. 6.  Security Considerations
  371.  
  372.    The information returned by this protocol is at most as trustworthy
  373.    as the host providing it OR the organization operating the host.  For
  374.    example, a PC in an open lab has few if any controls on it to prevent
  375.    a user from having this protocol return any identifier the user
  376.    wants.  Likewise, if the host has been compromised the information
  377.    returned may be completely erroneous and misleading.
  378.  
  379.    The Identification Protocol is not intended as an authorization or
  380.    access control protocol.  At best, it provides some additional
  381.    auditing information with respect to TCP connections.  At worst, it
  382.    can provide misleading, incorrect, or maliciously incorrect
  383.    information.
  384.  
  385.    The use of the information returned by this protocol for other than
  386.    auditing is strongly discouraged.  Specifically, using Identification
  387.    Protocol information to make access control decisions - either as the
  388.    primary method (i.e., no other checks) or as an adjunct to other
  389.    methods may result in a weakening of normal host security.
  390.  
  391.  
  392.  
  393.  
  394. St. Johns                                                       [Page 7]
  395.  
  396. RFC 1413                Identification Protocol            February 1993
  397.  
  398.  
  399.    An Identification server may reveal information about users,
  400.    entities, objects or processes which might normally be considered
  401.    private.  An Identification server provides service which is a rough
  402.    analog of the CallerID services provided by some phone companies and
  403.    many of the same privacy considerations and arguments that apply to
  404.    the CallerID service apply to Identification.  If you wouldn't run a
  405.    "finger" server due to privacy considerations you may not want to run
  406.    this protocol.
  407.  
  408. 7.  ACKNOWLEDGEMENTS
  409.  
  410.    Acknowledgement is given to Dan Bernstein who is primarily
  411.    responsible for renewing interest in this protocol and for pointing
  412.    out some annoying errors in RFC 931.
  413.  
  414. References
  415.  
  416.    [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January
  417.        1985.
  418.  
  419.    [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  420.        USC/Information Sciences Institute, July 1992.
  421.  
  422. Author's Address
  423.  
  424.        Michael C. St. Johns
  425.        DARPA/CSTO
  426.        3701 N. Fairfax Dr
  427.        Arlington, VA 22203
  428.  
  429.        Phone: (703) 696-2271
  430.        EMail: stjohns@DARPA.MIL
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. St. Johns                                                       [Page 8]
  451.  
  452.