Port 113 carries the Identification Protocol. When a server receives a TCP connection and wants to know who made it, it can reach back across the wire to port 113 and ask: "Who is the user behind this connection?"
The answer it gets might be true. It might be false. It might never come at all.
This is the story of the Internet's first attempt at caller ID, and why the question it asked became impossible to answer.
What Ident Does
The Ident protocol provides a simple service: given a TCP connection defined by two port numbers, it returns the username of the person who owns that connection on the client's system.1
The protocol is elegant in its simplicity. A server running on port 113 waits for queries. When one arrives, it looks like this:
Two numbers separated by a comma. The first is the port on the server side. The second is the port on the client side. Together, they uniquely identify a TCP connection.
The Ident server looks up who owns that connection and responds:
The response says: "The connection from your port 6191 to my port 23 belongs to a user named 'john' on a UNIX system."
That is all the protocol does. It names names.
The Problem It Solved
In the 1980s, the Internet was a different place. The ARPANET connected universities and government research facilities. Everyone who used it had a real identity. When someone connected to your FTP server or sent you email, there was a reasonable expectation that you could find out who they were.
But TCP/IP connections are anonymous by design. A connection comes from an IP address and a port number. The IP address might tell you which machine, but not which person. On a university Unix system with hundreds of students sharing a single machine, knowing the IP address told you nothing about who was responsible for the connection.
Michael St. Johns, working at the Department of Defense, faced this problem directly.2 The Defense Data Network needed accountability. When someone abused a service or violated policy, administrators needed to trace the connection back to a specific user. The Authentication Server protocol, published in RFC 931 in January 1985, was his solution.3
A Protocol Built on Trust
St. Johns understood something fundamental about the early Internet: it was a network of known systems operated by people who knew each other. If the MIT AI Lab said a connection belonged to user "rms," you could believe them because you trusted the MIT AI Lab.
The protocol depended entirely on this trust. RFC 1413, the updated specification published in February 1993, makes this explicit:1
"The information returned by this protocol is at most as trustworthy as the host providing it OR the organization operating the host."
This was not a bug. It was an honest acknowledgment of reality. The protocol could not verify identities. It could only ask a question and trust the answer.
The Name Change
The original RFC 931 called the service the "Authentication Server."3 By 1993, St. Johns had realized this name was a lie. The protocol did not authenticate anyone. It merely identified them, and even that identification depended entirely on the honesty of the responding server.
RFC 1413 renamed it to the "Identification Protocol."1 The acknowledgments section credits Dan Bernstein for "renewing interest in this protocol and for pointing out some annoying errors" in the original specification. One of those errors was the name itself.
The IRC Connection
If you used Internet Relay Chat in the 1990s and 2000s, you encountered the Ident protocol whether you knew it or not.
IRC servers would query your machine on port 113 before completing your connection. If you had an Ident daemon running, it would return your local username. If you did not, the IRC server would mark your username as unverified by prepending a tilde: ~john instead of john.4
Some IRC networks required verified Ident responses before allowing connections. Others used the information for logging and abuse prevention. When someone flooded a channel or harassed other users, the Ident response helped administrators trace the behavior to a specific account on a specific system.
This was Ident's longest-lasting use case. Even today, some IRC servers query port 113, though most have stopped requiring responses.5
Why Ident Failed
The protocol was designed for a world that no longer exists.
The Internet grew beyond the trust boundary. When the network expanded from research institutions to the general public, the assumption that operators could be trusted collapsed. A malicious user could run their own Ident server that lied about everything.
Firewalls killed inbound queries. Ident requires the server to initiate a connection back to the client. Stateful firewalls block this by default. By the late 1990s, most home connections and many corporate networks silently dropped Ident queries, causing connection delays as servers waited for responses that would never come.6
NAT made the question meaningless. When multiple users share a single public IP address through Network Address Translation, asking "who owns this connection" to the NAT device returns only the NAT process itself. The protocol has no way to trace through to the actual user behind the NAT.
The information helped attackers. Knowing that a connection belongs to "root" tells an attacker they have found something worth exploiting. User enumeration through Ident became a standard reconnaissance technique.7
The Stealth Port Debate
Port 113 created a peculiar security controversy in the early days of personal firewalls.
When a firewall silently drops packets to a port (making it "stealth"), the port appears to not exist at all. This sounds secure, but it causes problems. Servers expecting Ident responses wait for a timeout, delaying connections by 30 seconds or more.
The alternative is to have the firewall actively reject (RST) connections to port 113, indicating the port is closed. This is faster but reveals that a host exists at that IP address.6
Security scanner tools like Nmap specifically note this behavior: "Forging RST packets by firewalls and IDS/IPS is not particularly common outside of port 113."8 The port became a special case in firewall rules everywhere.
Security Considerations
RFC 1413 contains unusually direct security warnings:1
"The Identification Protocol is not intended as an authorization or access control protocol. At best, it provides some additional auditing information with respect to TCP connections. At worst, it can provide misleading, incorrect, or maliciously incorrect information."
The specification explicitly warns against using Ident responses for access control decisions. The IETF's security guidance describes using Ident for email sender authentication as "a bad idea," citing risks including TCP hijacking and the certainty of false replies.9
A 2019 vulnerability in Cisco IOS demonstrated that even implementing an Ident server can be dangerous. A malformed query could cause the device to reload, creating a denial-of-service condition.10
The Legacy of Michael St. Johns
St. Johns went on to serve on the Internet Architecture Board twice and chair multiple IETF working groups. His later work includes RFC 5011 on automated DNSSEC trust anchor updates.11
In an interview, he reflected on the evolution of the Internet he helped build: "One of the things about the Internet is that it was designed to be used by experts. We have gone from a benign environment where we knew everyone who is on the Internet to an environment where we have cyber-stalkers and cyber-terrorists."12
The Ident protocol embodied that benign environment. It asked a question that made sense when trust was the default. The protocol did not fail because it was poorly designed. It failed because the world it was designed for disappeared.
What Replaced Ident
Modern systems use different approaches to the accountability problem:
- SASL (Simple Authentication and Security Layer) provides application-layer authentication that does not depend on the client's operating system
- TLS client certificates offer cryptographic proof of identity
- OAuth and OpenID Connect delegate identity to trusted providers
- IP reputation systems track behavior across connections rather than asking who made them
None of these are direct replacements for Ident. They solve different problems, or solve the same problem under different trust assumptions.
Related Ports
- Port 22 (SSH): Replaced Telnet in part because SSH provides cryptographic authentication, making identity queries unnecessary
- Port 25 (SMTP): Mail servers were heavy users of Ident lookups in the 1990s
- Port 6667 (IRC): The service most associated with Ident queries in practice
- Port 79 (Finger): Another information disclosure protocol from the same era, mentioned in RFC 1413 as a comparable privacy concern
Current Status
Port 113 is still assigned to the Ident protocol in the IANA registry.13 Some systems still run Ident daemons, particularly:
- Legacy Unix/Linux systems maintaining backward compatibility
- IRC bouncers and clients connecting to servers that still query Ident
- PostgreSQL servers using Ident authentication for local connections14
Most modern operating systems do not run an Ident server by default. Most firewalls block or reject inbound connections to port 113. The protocol persists in documentation and in the muscle memory of system administrators who remember when it mattered.
Frequently Asked Questions
Was this page helpful?