| Communication protocol | |
| Purpose | Identification |
|---|---|
| Developer(s) | Michael C. St. Johns at US Department of Defense |
| Introduction | February 1993 |
| Based on | RFC 931 |
| OSI layer | Application layer (Layer 7) |
| Port(s) | TCP/113 |
| RFC(s) | 1413 |
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
The Ident protocol (Identification Protocol, often just ident) is an application-layer protocol specified in {{citation}}: Empty citation (help). Given a pair of TCP port numbers corresponding to an existing connection, an Ident server returns a short string that identifies the owner of that connection on the server’s host. The protocol listens on TCP port 113. "Service Name and Transport Protocol Port Number Registry". IANA. Retrieved 2025-09-15. It obsoletes the earlier {{citation}}: Empty citation (help) “Authentication Server” protocol. "RFC 1413 - Identification Protocol". IETF Datatracker. Retrieved 2025-09-15.
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]
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:
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.{{citation}}: Empty citation (help)
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. "RFC 1413 - Identification Protocol". IETF Datatracker. Retrieved 2025-09-15.
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. "RFC 3552 - Guidelines for Writing RFC Text on Security Considerations". IETF Datatracker. July 2003. Retrieved 2025-09-15. NOTE: One bad approach to sender authentication is [IDENT]… Aside from the fact that IDENT is of low security value, use of IDENT by receiving sites can lead to operational problems. Many sending sites blackhole IDENT requests, thus causing mail to be held until the receiving server's IDENT request times out.
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. "IRCv3 Client Protocol (modern specification)". modern.ircdocs.horse. Retrieved 2025-09-15.
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.{{citation}}: Empty citation (help)
Ident was published as a Proposed Standard in February 1993, replacing the earlier {{citation}}: Empty citation (help) “Authentication Server”. "RFC 1413 - Identification Protocol". IETF Datatracker. Retrieved 2025-09-15. The service name “auth/ident” remains assigned to TCP port 113 in the IANA registry. "Service Name and Transport Protocol Port Number Registry". IANA. Retrieved 2025-09-15.