Function
The Ident Protocol is designed to work as a server daemon, on a user's computer, where it receives requests to a specified TCP port, generally 113. In the query, a client specifies a pair of TCP ports (a local and a remote port), encoded as ASCII decimals and separated by a comma (,). The server then sends a response that identifies the username of the user who runs the program that uses the specified pair of TCP ports, or specifies an error.
Suppose host A wants to know the name of the user who is connecting to its TCP port 23 (Telnet) from the client's (host B) port 6191. Host A would then open a connection to the ident service on host B, and issue the following query:
6191, 23
As TCP connections generally use one unique local port (6191 in this case), host B can unambiguously identify the program that has initiated the specified connection to host A's port 23, should it exist. Host B would then issue a response, identifying the user ("stjohns" in this example) who owns the program that initiated this connection and the name of its local operating system:
6193, 23 : USERID : UNIX : stjohns
But if it would turn out that no such connection exists on host B, it would instead issue an error response:
6195, 23 : ERROR : NO-USER
All ident messages should be delimited by an end of line sequence consisting of the carriage return and linefeed characters (CR+LF).1
Usefulness of ident
Dialup hosts or shared shell servers often provide ident to enable abuse to be tracked back to specific users. In the case that abuse is handled on this host, the concern about trusting the ident daemon is mostly irrelevant. Spoofing of the service and privacy concerns can be avoided by providing varying cryptographically strong tokens instead of real usernames.
If abuse is to be handled by the administrators of the service that users connect to using the ident providing host, then the ident service must provide information identifying each user. Usually, it is impossible for the administrators of the remote service to know whether specific users are connecting via a trustable server or from a computer they themselves control. In the latter case the ident service provides no reliable information.
The usefulness of Ident for proving of a known identity to a remote host is limited to circumstances when:
- The user connecting is not the administrator of the machine. This is only likely for hosts providing Unix shell access, shared servers using a suEXEC-like construction and the like.
- One trusts the administrators of the machine and knows their user policy. This is most likely for hosts in a common security domain such as within a single organization.
- One trusts that the machine is the machine it claims to be and knows that machine. This is only easily arranged for hosts on a local area network or virtual network where all hosts on the network are trusted and new hosts cannot easily be added due to physical protection. On remote and normal local networks false ident replies can be accomplished by ip spoofing and, if DNS is used, by all kinds of DNS trickery. The ident daemon may provide cryptographically signed replies which, if they can be confirmed, solves these last, but not the first, concerns.
- There exist no intermediate obstacles to connecting to identd such as firewall, NAT, or proxy (such as if you were using ident with Apache httpd). These are common occurrences when going between security domains (as with public HTTP or FTP servers).
Protocol
Ident is a simple request/response service over TCP. A client connects to the server on port 113 and sends the server’s TCP port and the client’s TCP port as ASCII decimals separated by a comma (e.g. 6191, 23). The server replies with either a USERID response, which includes an operating-system tag and an identifier string, or an ERROR code such as NO-USER or HIDDEN-USER.1
Security and Privacy
The specification notes that Ident information is only as trustworthy as the host returning it and may reveal information that would normally be considered private. It warns against using Ident for access control.1
The IETF’s security-guidance BCP also describes use of Ident for sender authentication (for example in mail systems) as “a bad idea”, citing risks including relaying, TCP hijacking and the possibility of misleading or false replies; it also notes operational issues due to many sites dropping or black-holing Ident queries.4
Deployment and Usage
Historically, Ident was used on multi-user systems to aid auditing and abuse handling (for example, on IRC networks). Modern IRC specifications treat Ident as optional: servers MAY use the Ident protocol to look up a client’s “real username”, and (if enabled) often mark client-supplied names as unverified when no Ident reply is received.5
In practice, widespread use of firewalls and network address translation (NAT) reduces the usefulness of Ident across networks, since inbound connections to client hosts are commonly blocked or translated.6
History
Ident was published as a Proposed Standard in February 1993, replacing the earlier “Authentication Server”.31 The service name “auth/ident” remains assigned to TCP port 113 in the IANA registry.2
