Network Working Group M StJohns Department of Defense August 1992Identification Server1. STATUS OF THIS MEMO This document is an Internet Draft. Internet Draftsare working documents of the Internet Engineering Task Force(IETF), its Areas, and its Working Groups. Note that othergroups may also distribute working documents as InternetDrafts). Internet Drafts are draft documents valid for a maximumof six months. Internet Drafts may be updated, replaced, orobsoleted by other documents at any time. It is notappropriate to use Internet Drafts as reference material orto cite them other than as a "working draft" or "work inprogress." Please check the I-D abstract listing contained in eachInternet Draft directory to learn the current status of thisor any other Internet Draft. This Draft expires: 1 December 1992.2. INTRODUCTION The Identification Server Protocol (aka "ident", aka"the Ident Protocol", aka "the Identification Protocol")provides a means to determine the identity of a user of aparticular TCP connection. Given a TCP port number pair, itreturns a character or octet string which identifies theowner of that connection on the server's system. The Identification Server Protocol was formerly calledthe Authentication Server Protocol. It has been renamed tobetter reflect its function.3. OVERVIEW This is a connection based application on TCP. Aserver listens for TCP connections on TCP port 113(decimal). Once a connection is established, the serverreads a line of data which specifies the connection ofinterest. If it exists, the system dependent useridentifier of the connection of interest is sent as thereply. The server may then either shut the connection downDraft - Exp 1/93 -1-Ident WG M StJohns, DoDor it may continue to read/respond to multiple queries. The server should close the connection down after aconfigurable amount of time with no queries - a 60-180second idle timeout is recommended. The client may closethe connection down at any time; however, to allow fornetwork delays the client should wait at least 30 seconds(or longer) after a query before abandoning the query andclosing the connection.4. RESTRICTIONS Queries are permitted only for fully specifiedconnections. The query contains the local/foreign port pair- - -- the local/foreign address pair used to fully specify theconnection is taken from the local and foreign address ofquery connection. This means a user on address A may onlyquery the server on address B about connections between Aand B.5. QUERY/RESPONSE FORMAT The server accepts simple text query requests of theform <port-on-server> , <port-on-client>where <port-on-server> is the TCP port (decimal) on thetarget (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 onhost B about a connection specified locally (on the client'smachine) as 23, 6191 (an inbound TELNET connection), theclient must actually ask about 6191, 23 - which is how theconnection 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 asDraft - Exp 1/93 -2-Ident WG M StJohns, DoDthe query, <resp-type> is a keyword identifying the type ofresponse, and <add-info> is context dependent. The information returned is that associated with thefully specified TCP connection identified by <server-address>, <client-address>, <port-on-server>, <port-on-client>, where <server-address> and <client-address> are thelocal and foreign IP addresses of the querying connection --i.e. the TCP connection to the Identity Protocol Server.(<port-on-server> and <port-on-client> are taken from thequery.) For example: 6193, 23 : USERID : UNIX : stjohns 6195, 23 : ERROR : NO-USER6. 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 "OCTET" (see below). Permitted operating system names and character set names are specified inRFC-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" and one special case character set name - "OCTET". 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 butDraft - Exp 1/93 -3-Ident WG M StJohns, DoD "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 (or an octet string if "OCTET" is the 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 both examples of when "OTHER" should be used. With the exception of those responses with "OCTET" character set name (i.e. the default), returned user identifiers are expected to be printable in the character set indicated. "OCTET" indicates the identifier is an unformatted octet string - all octets are permissible EXCEPT 00 (NUL), 12 (LF) and 15 (CR). N.B. - space characters ( 40) following the colon separator 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. N.B. An "OCTET" 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 #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. HIDDEN-USERDraft - Exp 1/93 -4-Ident WG M StJohns, DoD 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 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 infuture revisions to this document. If an implementer has aneed to specify a non-standard error code, that code mustbegin with "X". In addition, the server is allowed to drop the queryconnection without responding. Any premature close (i.e.one where the client does not receive the EOL, whethergraceful or an abort should be considered to have the samemeaning as "ERROR : UNKNOWN-ERROR".Draft - Exp 1/93 -5-Ident WG M StJohns, DoDFORMAL SYNTAX <request> ::= <port-pair> <EOL> <port-pair> ::= <integer> "," <integer> <reply> ::= <reply-text> <EOL> <EOL> ::= " 15 12" ; 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" | <error-token> <opsys-field> ::= <opsys> [ "," <charset>] <opsys> ::= "OTHER" | "UNIX" | <token> ...etc. ; (See "Assigned Numbers") <charset> ::= "OCTET" | "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 <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 ( 00), CR ( 15) and LF ( 12)>Notes on Syntax:Draft - Exp 1/93 -6-Ident WG M StJohns, DoD1) 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 except the <user-id> field, uppercase is not distinct from lower case. I.e. "Error" and "ERROR" are the same value.3) 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>.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 defined or reference byRFC-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.6) 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.7) 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.Draft - Exp 1/93 -7-Ident WG M StJohns, DoD7. Security Considerations The information returned by this protocol is at most astrustworthy as the host providing it OR the organizationoperating the host. For example, a PC in an open lab hasfew if any controls on it to prevent a user from having thisprotocol return any identifier the user wants. Likewise, ifthe host has been compromised the information returned maybe completely erroneous and misleading. The Identity Protocol is not intended as anauthorization or access control protocol. At best, itprovides some additional auditing information with respectto TCP connections. At worst, it can provide misleading,incorrect, or maliciously incorrect information. The use of the information returned by this protocolfor other than auditing is strongly discouraged.Specifically, using Identity Protocol information to makeaccess control decisions - either as the primary method (i.eno other checks) or as an adjunct to other methods mayresult in a weakening of normal host security. An Ident server may reveal information about users,entities, objects or processes which might normally beconsidered private. An Ident server provides service whichis a rough analog of the CallerID (tm) services provided bysome phone companies and many of the same privacyconsiderations and arguments that apply to the CallerIDservice apply to Ident. If you wouldn't run a "finger"server due to privacy considerations you may not want to runthis protocol.8. ACKNOWLEDGEMENTS Acknowledgement is given to Dan Bernstein who isprimarily responsible for renewing interest in this protocoland for pointing out some annoying errors inRFC931.Draft - Exp 1/93 -8-
Datatracker
draft-ietf-ident-idserver-02
This is an older version of an Internet-Draft that was ultimately published asRFC 1413.
| Document | Document type | This is an older version of an Internet-Draft that was ultimately published asRFC 1413. | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | Michael StJohns Email authors | ||
| RFC stream |   | ||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | cnri.reston.va.us%3A~/ietf.mailing.lists/ident/%2A |