--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / ircu2.10.12-pk.git / blobdiff