doc/rfc1413.txt

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