Identification Protocol
obsoletes
- rfc-931 — Authentication server
Extracted elements (23)
The 'HIDDEN-USER' error code was defined to allow users to opt out of having their identity disclosed while still signaling that the connection is owned by a known user, balancing auditability against user privacy preferences.
The protocol was renamed from 'Authentication Server Protocol' (RFC 931) to 'Identification Protocol' to better reflect its actual function: identifying the owner of a TCP connection rather than authenticating them.
Clients and servers must follow 'be conservative in what you send, be liberal in what you accept' for whitespace. Whitespace is permitted anywhere except within a token, but everything from the colon after the OS type through the terminating CR-LF is part of the user-id and whitespace there is significant.
Clients should abort the connection if 1000 characters are received without an EOL, as a guard against malformed or excessively padded responses.
If a client does not recognize the returned character set, it should handle the user-id as OCTET data and additionally represent it in hex notation (0-9a-f) as a standard fallback, while still storing or reporting the charset identifier.
A server MAY return UNKNOWN-ERROR in lieu of any other specific error code to conceal information implied by the more specific code. If implemented, this feature MUST be configurable and MUST default to returning the proper specific error message.
A server SHOULD NOT send more than 512 octets of user ID; a client MUST accept at least 512 octets. When the identifier exceeds 512 octets, the server MUST return the most significant portion in the first 512 octets.
All protocol fields except the user-id must be defined in and sent as US-ASCII. Character set identifiers apply only to the user identification field.
Any premature close of the query connection before the client receives the EOL—whether graceful or aborted—must be treated as equivalent to 'ERROR : UNKNOWN-ERROR'.
Queries are permitted only for fully specified connections. The local/foreign address pair is taken from the query connection itself, meaning a user on address A may only query a server on address B about connections between A and B.
The client should wait at least 30 seconds after a query before abandoning it and closing the connection, to allow for network delays.
The server should close the connection after a configurable idle period; a 60–180 second idle timeout is recommended.
Token values (OPSYS names, ERROR-TYPE codes) are limited to 64 characters. No new standard token will be defined exceeding this length, and non-standard error tokens must begin with 'X' and be 2–64 characters.
An Identification server may reveal private information about users, entities, objects, or processes. The privacy considerations are analogous to telephone CallerID services; operators who would not run a 'finger' server due to privacy concerns may not want to run this protocol either.
The ERROR response type's <add-info> is one of: INVALID-PORT (port out of range or malformed), NO-USER (connection not currently in use or not owned by an identifiable entity), HIDDEN-USER (user identified but withheld at user's request), or UNKNOWN-ERROR (all other failures). Non-standard error codes must begin with 'X'.
The Identification Protocol runs over TCP on port 113. A server listens for connections, reads a query specifying a connection of interest by port pair, and returns the system-dependent user identifier of that connection's owner. The server may handle multiple queries per connection.
The special OS type 'OTHER' indicates the identifier is an unformatted printable string not conforming to normal user-identifier constraints, such as an encrypted audit token or real-name/phone-number data. 'OTHER' should be used whenever the identifier does not uniquely identify the connection owner in a directly usable form.
The USERID response type's <add-info> is '<opsys>[,<charset>]:<user-id>'. The OS name and optional charset identifier are taken from RFC 1340 Assigned Numbers. The charset defaults to US-ASCII when omitted.
The Identification Protocol is not intended as an authorization or access control protocol. Using its output for access control—whether as the primary method or as an adjunct—may weaken normal host security. Its appropriate use is limited to auditing.
The information returned by this protocol is at most as trustworthy as the host providing it. A compromised host or an open-access machine (e.g., a public-lab PC) can return arbitrary, misleading, or maliciously incorrect identifiers.
The query format is '<port-on-server> , <port-on-client>' where each port is a decimal integer (1–5 digits). The client must reverse the local/remote port perspective: a locally observed connection of 23, 6191 must be queried as '6191, 23' when sent to the server.
The response format is '<port-on-server> , <port-on-client> : <resp-type> : <add-info>', echoing the queried port pair followed by a keyword response type and context-dependent additional info. All lines terminate with CR-LF (octal 015 012).
The user-id field is an unformatted octet-string of 1–512 octets. All octet values are permitted except NUL (000), LF (012), and CR (015). Space characters immediately after the OS-type colon separator are part of the identifier string and must not be ignored.