Summary

  • RFC 1413 made the Ident request connection-specific: a query named the server and client ports as the queried host saw them, and the host returned its own user string for that socket.
  • RFC 931 had suggested experimental use in automatic FTP login. The 1993 revision called the service an Identification Protocol and said its result could support auditing, but must not make authentication or access-control decisions.

Two numbers, one host’s point of view

The telling example in RFC 1413 looks like a clerical correction. A connection appears locally as ports 23, 6191; when the other endpoint is asked about it, the query must be 6191, 23. Nothing about the connection has changed. The labels “local” and “foreign” have changed because the query is now being asked from the other machine’s side.

That reversal was the protocol’s working key. An Ident client connected to TCP port 113 on a host and sent a line containing <port-on-server>, <port-on-client>. The IP addresses were supplied by the TCP connection to the Ident service itself. Together, those addresses and the two queried ports specified one existing TCP connection. The server could then return the system-dependent identifier associated with that connection on its own machine.

The exchange was narrow by design. It did not ask a central service to resolve a person across the Internet. It asked a host to report how its local system associated a particular socket with a user string. A USERID response carried an operating-system field and an identifier; an ERROR response could say that no owner was available. RFC 1413 also defined HIDDEN-USER for a server that could identify the user but withheld the information at the user’s request.

This was not the same query surface as the earlier Name/Finger service. A blank Finger request could ask a host for a list of people currently online; Ident selected one TCP connection by its port pair. The distinction matters because an online roster and a socket-owner string answer different operational questions. The earlier Name/Finger article covers that host-wide presence boundary.

“Authentication Server” was an early application idea

The lineage begins with Mike St. Johns’s September 1984 RFC 912, titled “Authentication Service.” It proposed a TCP service on port 113 that could return the identifier of the owner of a particular TCP connection. The document listed several possible uses, including automatic user authentication during FTP and checks for privileged network operations. It also warned that the trustworthiness of host systems would vary and left applications to decide how much confidence to place in a reply.

RFC 931, published in January 1985, superseded that proposal. It specified a more formal response that paired an operating-system name with a user identifier. For FTP, it sketched a user client sending a USER command without an argument so the server might use the authentication service. The memo called that an experimental use and repeated the host-trust caveat. The document records an application that authors proposed; it does not show that FTP servers widely implemented it.

This distinction between a protocol answer and an application decision is central. The authentication server did not independently validate a password or prove who was sitting at a terminal. It returned a host’s account of which local identifier owned a connection. An FTP server could choose to use that string, but the choice and any consequences belonged to the application and its trust relationship with the other host.

The 1993 name made the boundary explicit

RFC 1413, issued in February 1993, obsoleted RFC 931 and renamed the former Authentication Server Protocol to the Identification Protocol, or Ident, “to better reflect its function.” The document retained TCP port 113 and the connection-specific port pair. It added clearer rules for multiple queries on one Ident connection and for responses such as HIDDEN-USER.

Its security considerations left little room for a stronger interpretation. Returned information was “at most as trustworthy” as the host or organization operating the host. The protocol was not intended for authorization or access control; at best, it supplied additional audit information about TCP connections. The RFC strongly discouraged using it for other purposes and warned that it could expose information normally considered private.

The warning followed from the service’s data path. A server produced the identifier from its own operating system’s view. A compromised host could return misleading information; an open lab machine might let a user choose what identifier appeared. A syntactically valid USERID line did not turn the server’s statement into an independently verified fact. The client could learn what the queried host reported, not whether a human claim had been authenticated elsewhere.

The wording change therefore marks a useful historical boundary, but not proof that every earlier use stopped. RFC 1413 called the service identification rather than authentication and constrained the safe inference a reader should draw from it. The available RFCs do not tell us how many sites ran Ident, how often users hid an identifier, or whether particular FTP systems relied on it. A standards document records a protocol contract, not an adoption census.

What the port pair can support

For an audit trail, a host-reported identifier can be useful context if the surrounding record keeps the host, direction, ports, time and response together. It can help an operator ask which local account the remote endpoint associated with a connection. It cannot establish that the named person initiated the traffic, that the account holder controlled the remote machine, or that the application was entitled to accept the claim.

The protocol’s history turns on that separation. RFC 931 described one possible way an application might consume a remote user string. RFC 1413 named the service for the identification it actually returned and warned against using that report as authority. A pair of ports could make a particular connection legible to its host. The trust decision still belonged to the system that chose what to do with the answer.

Sources