"Fossies" - the Fresh Open Source Software Archive

Member "pidentd-3.0.19/doc/rfc1413.txt" (20 Jan 1999, 16292 Bytes) of package /linux/misc/old/pidentd-3.0.19.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    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