Summary

  • IDENT did not ask a global directory who a person was. A remote server opened TCP port 113 on the other host and submitted the exact local and foreign port pair of an existing TCP connection.
  • The protocol's name narrowed as its authority became clearer. The 1984 Authentication Service and 1985 Authentication Server Protocol became the 1993 Identification Protocol, whose specification forbade treating its USERID response as authorization.
  • USERID, HIDDEN-USER and UNKNOWN-ERROR were reports made by a remote host under its own policy. They could enrich an audit trail, but the host could lie, conceal a user or fail to map the connection at all.

One conversation produced a second conversation

Suppose host A has opened a TCP connection from local port 6191 to host B's Telnet port 23. Host B sees the connection and wants an account name to place beside it in a log. It does not add a field to Telnet, inspect application text or ask a central identity provider. It opens a new TCP connection back to host A's service on port 113.

On that reverse connection B sends 6191, 23: the first number is the TCP port on A, the machine answering the query; the second is the port on B, the machine asking it. A can now look for the connection that joins those two hosts and those two endpoints. If it finds one, it may return a USERID response containing an operating-system label and an identifier chosen by A.

That choreography, specified in RFC 1413, was an unusual form of protocol introspection. The data connection did not identify its owner. A second connection asked the host that created it to inspect local state. The answer crossed the network, but the act of attribution remained inside the originating machine.

The geometry supplied a boundary. The query applied only to TCP connections between the same two IP hosts as the query connection. A was not being asked for every user on its system, nor for the owner of an unrelated flow. Two addresses came from the reverse connection; two port numbers came from the request. Together they selected one candidate in A's connection table.

Authentication was the first ambition

The earliest document in the closed record used a stronger name. RFC 912, published in September 1984, described an “Authentication Service” on port 113. It imagined FTP servers verifying that a username supplied in an application conversation matched the user who owned the TCP connection. It also discussed privileged operations and inter-host trust.

The proposal already carried a warning. Its usefulness depended on trusting the foreign host to report honestly and to protect the service from local manipulation. A username supplied by a machine was no stronger than that machine's accounting, operating system and administrative discipline.

RFC 931 formalized the Authentication Server Protocol in January 1985. It introduced the recognizable port-pair query and the USERID or ERROR response. It also explored access mappings: a server might use a reported identifier when deciding which local privileges to expose.

The vocabulary made an architectural hope visible. If a remote system could name the user behind a connection, perhaps applications would no longer need separate identification exchanges. But the protocol had not proved the user, secured the return path or established a shared policy for what the name meant. It had asked one host to report its own local association.

The rename removed an authority the packet never had

RFC 1413, published in February 1993 by the IETF IDENT working group, obsoleted RFC 931 and changed the name to “Identification Protocol.” The specification says the new name better reflects the function. That sentence is not cosmetic housekeeping. It is a correction to the claim made by the system's label.

The later RFC states that the information is at most useful for auditing. It must not be used as an access-control identifier. If a site were to grant access because a USERID response said alice, a compromised or deliberately deceptive remote host could simply return alice. The extra lookup would have replaced an application credential with an assertion controlled by the other side.

Identification here meant a claimed association between a TCP connection and a local identifier. It did not mean that the network had authenticated a human, that two sites assigned the same meaning to the same string, or that the returned subject was authorized for the requested operation.

This limitation strengthened the protocol's honest use. A mail, chat or terminal server could record the reported name beside addresses, ports and time. During an incident, the remote administrator could correlate that record with local login and process evidence. The result might help two operators find the same event. It could not settle the event by itself.

The order of the two ports was part of the evidence

Port-pair syntax looks trivial until direction changes. Each side calls its own endpoint “local.” The server making the IDENT query therefore had to reverse the pair it observed on the original connection.

For a connection from A:6191 to B:23, B observes local port 23 and foreign port 6191. In its query to A, however, it sends 6191, 23, because the query is ordered from the perspective of the answering host. Reversing those fields incorrectly asks about a different tuple and should produce INVALID-PORT or no useful answer.

The IP addresses were not repeated in the query string. RFC 1413 derived them from the TCP connection carrying the query. That choice reduced ambiguity, but it did not create cryptographic binding. Packets still travelled through the ordinary network, and the queried host still generated the content of the reply.

The exact tuple mattered operationally because ports were temporary and reusable. A record without query time could be matched to a later connection that happened to reuse the same numbers. An audit system therefore needed the original connection's addresses, ports, direction and time, plus the IDENT exchange itself. The username was one observation in a sequence, not a timeless property of a port.

USERID carried a local namespace across a boundary

A successful response contained the echoed port pair, the response type USERID, an operating-system type and a character string. The operating-system field told the receiver how to interpret the identifier. The optional character-set parameter addressed a second problem: even if both sides accepted that a name had been returned, they still needed to agree on its encoding.

RFC 1413 also allowed the operating-system value OTHER. In that case, the response could be an unformatted token rather than a conventional username. This was an explicit reminder that the protocol transported a host-defined identifier. A receiver was not entitled to assume a Unix account name, a globally unique person or a stable employee record.

The server was advised to return the identifier useful to an administrator, not gratuitous details about a process or command. That distinction limited disclosure. The protocol's purpose was correlation with the system that answered, not remote inspection of everything behind the socket.

Errors were policy as well as failure

The error vocabulary showed that non-disclosure could be deliberate. INVALID-PORT meant the query was malformed or outside the valid range. NO-USER meant the host could not identify a user for the specified connection. HIDDEN-USER meant it knew but policy prevented disclosure. UNKNOWN-ERROR gave implementations a way to avoid exposing an internal condition; a connection closed before a response was to be treated the same way.

Those states were not interchangeable evidence. NO-USER did not prove anonymous use. HIDDEN-USER did not prove misconduct. UNKNOWN-ERROR did not establish that no mapping existed. Each described what the answering service was willing or able to return at that moment.

RFC 1413 compared the privacy issue with services such as CallerID and Finger. A username that is ordinary inside one host becomes a new disclosure when any remote server receiving a connection can ask for it. A site could disable the service, hide selected users or return tokens, but each choice changed the value and interpretation of remote logs.

Privacy therefore was not an add-on to an otherwise objective lookup. It shaped the observable result. Silence, concealment and a local alias were all legitimate outcomes under different policies.

A MIB mirrored the same boundary

RFC 1414 defined a Management Information Base for the Identification Protocol. Its table used local address, local port, remote address and remote port as indexes and exposed a user identifier plus status. The model repeated the same four-part connection geometry in a management system rather than on the port-113 exchange.

The MIB is now classified Historic, while RFC 1413 remains listed by the RFC Editor as a Proposed Standard. That status difference should not be converted into a claim about present deployment. The documents establish specification history and authority boundaries, not a census of current hosts.

The MIB also repeated the warning: an ident response was not authoritative and should not be used for access control. Moving a value into structured management data did not improve its proof. A column could make a report easier to query without making it truer.

Registration standardized the door, not the answer

The current IANA Service Name and Transport Protocol Port Number Registry records both ident and the older auth name for TCP port 113. The registry lets implementations agree where the service listens and preserves the historical alias.

It does not certify the user named in a response. Port registration coordinates a rendezvous point; it does not control the operating system, account database, privacy policy or administrator behind that point. This is the same separation the rename made explicit: shared protocol grammar can standardize a question without centralizing the truth of every answer.

A username became useful by losing the power to authorize

IDENT's durable lesson is not that every service should ask who owns a TCP connection. It is that attribution and authorization must remain different operations even when they share a name-like value.

The query had a precise scope. It referred to one connection between two hosts, selected by an ordered pair of ports. The response came from the host that held the relevant local state. The error model admitted inability and refusal. The privacy options admitted that observation had a cost. The security section admitted deception.

Within those limits, the reply could reduce the work of correlation. Outside them, it created a dangerous shortcut. A local username reported by a remote system was evidence about what that system said, not a credential presented by the user and not a mandate for the receiving service.

The protocol began with authentication in its name and ended with identification in its title. That retreat was not failure. It was specification catching up with the actual chain of authority.

Sources and evidence limits

The sources define successive protocols, the management model and the registered service name. They do not measure current deployment, response accuracy, privacy practice or attack frequency. The article therefore makes no claim that IDENT is widely enabled today, and it does not infer behavior through address translators, proxies or containers that the closed source set does not document.