diff options
Diffstat (limited to 'docs/rfc/rfc1413.txt')
| -rw-r--r-- | docs/rfc/rfc1413.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/docs/rfc/rfc1413.txt b/docs/rfc/rfc1413.txt new file mode 100644 index 000000000..17ede58a2 --- /dev/null +++ b/docs/rfc/rfc1413.txt @@ -0,0 +1,451 @@ + + + + + + +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] +
\ No newline at end of file |