Ident protocol

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.

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.

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.

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.

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.

History

Ident was published as a Proposed Standard in February 1993, replacing the earlier “Authentication Server”. The service name “auth/ident” remains assigned to TCP port 113 in the IANA registry.