Network Working Group Mike StJohns Request for Comments: DOD Supersedes: RFC912, RFC931 June 1992 Identification Server STATUS OF THIS MEMO This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This Draft expires: 1 November 1992. INTRODUCTION The Identification Server 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 Server Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. 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 one line of data which specifies the connection of interest. If it exists, the system dependent user identifier of the connection of interest is sent out the connection. 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. 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. QUERY/RESPONSE FORMAT The server accepts simple text query requests of the form , where is the TCP port (decimal) on the target (where the "ident" server is running) system, and is the TCP port (decimal) on the source (client) system. N.B - "local" and "foreign" are relative. If there is a TCP connection from host A to host B, on host A equals on host B and on host A equals on host B. If a client on host A wants to ask a server on host B about a connection specified locally 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 , : : where , are the same pair as the query, is a keyword identifying the type of response, and is context dependent. The information returned is that associated with the fully specified TCP connection identified by , , , , where and are the local and foreign IP addresses of the querying connection -- i.e. the TCP connection to the Identity Protocol Server. ( and are taken from the query.) For example: 6193, 23 : USERID : UNIX : stjohns 6195, 23 : ERROR : NO-USER RESPONSE TYPES A response can be one of two types: USERID In this case, is a string consisting of an operating system name (with an optional character set identifier), followed by a ":", followed by identification string. The character set (if present) is seperated from the operating system name by "///". The character set identifier is used to indicate the character set of the identification string. If a character set identifier is omitted, the identification string is assumed to be in "NVT-ASCII" (exception - see OCTET below). Permitted operating system names and character set names are specified in RFC-1060, "Assigned Numbers" or its successors. [Note that "Assigned Numbers" does not currently list character set names but should eventually include them both as a source for this protocol and as the result of the work of the MIME mail extensions working group.] A particular operating system identifier implies a specific consistent format for the user identification string. E.g. "UNIX" implies an 8 character user id. An Ident server must use an operating system identifier of "OTHER" if it returns a user identification string which is not properly formatted (e.g. "Michael StJohns, DOD, Analyst" is an invalid UNIX user id) - see below. This document defines a user identifier format only for one operating system type - "UNIX". A "UNIX" identifier consists of up to 8 printable characters (in the specified character set) not including white space (SPC, TAB) or carriage motion characters (CR, LF, FF). Other formats will be published later as necessary. In addition to those operating system names specified in "Assigned Numbers" there are two special case identifiers: "OCTET" and "OTHER". "OCTET" indicates the identifier is an unformatted octet string - all octets are permissible EXCEPT \000 (NUL), \012 (LF) and \015 (CR). N.B. - space characters (\040) following the colon seperator ARE part of the identifier string and may not be ignored. A response containing an OCTET string is still terminated normally by a CR/LF. A character set MAY be specified with OCTET, but can safely be ignored. "OTHER" indicates the identifier is an unformatted character string consisting of printable characters in the specified character set. "OTHER" must be specified if there is no registered format for a user id for this operating system, if the system wishes to return an identification which is not in the format registered for this system (eg. an encrypted audit token), or if there is a desire to hide the operating system type. The main difference between "OCTET" and "OTHER" is that an "OTHER" identification string is expected to be printable in the character set identified, or in the NVT-ASCII character set if not explicitly identified. ERROR For some reason the owner of could not be determined, tells why. The following are the permitted values of 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 #s 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. 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 "NO-USER" or "INVALID-PORT" to hide such information. 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 close, whether graceful or an abort should be considered to have the same meaning as "ERROR : UNKNOWN-ERROR". FORMAL SYNTAX ::= ::= "," ::= ::= | ::= ":" "ERROR" ":" ::= ":" "USERID" ":" ":" ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR" / | ::= [ "///" ] ::= "OTHER" | "OCTET" | "UNIX" | ...etc. ; (See "Assigned Numbers") ::= "NVT-ASCII" | ...etc. ; (See "Assigned Numbers") ::= ::= 1*64 ; 1-64 characters ::= "X" ::= 1*5 ; 1-5 digits. ::= "0" | "1" ... "8" | "9" ; 0-9 ::= /?"'~`{}[];\| > ; upper and lowercase a-z plus ; printables minus the colon ":" ; character. ::= 1*512 ::= Notes on Syntax: 1) White space (blanks and tab characters) between tokens is not important and may be ignored. 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. Note that this does not apply for responses that contain a user ID -- 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) For purposes of comparison for all fields the USERID field, uppercase is not distinct from lower case. I.e. "Error" and "ERROR" are the same value. 3) Any additional s must also be s. 4) 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 user ID. Because of this limitation, a server MUST return the most significant portion of the user ID in the first 512 octets. 5) The character sets and character set identifiers should map directly to those specified and used by the MIME Mail extensions. Character set identifiers only apply to the user identification field - all other fields will be defined in and must be sent as NVT-ASCII. 6) Although is defined as an above, it must follow the format and character set constraints implied by the ; see the discussion above. 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 Identity 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 Identity 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. An Ident server may reveal information about users, entities, objects or processes which might normally be considered private. An Ident server provides service which is a rough analog of the CallerID (tm) services provided by some phone companies and many of the same privacy considerations and arguments that apply to the CallerID service apply to Ident. If you wouldn't run a "finger" server due to privacy considerations you may not want to run this protocol. 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 RFC931.