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