View source for Ident protocol

{{short description|Internet protocol that helps identify the user of a particular TCP connection}}
{{Infobox networking protocol
| title        = Ident
| purpose      = Identification
| developer    = Michael C. St. Johns at US Department of Defense
| date         = {{Start date and age|1993|02}}
| based on     = {{IETF RFC|931}}
| osilayer     = [[Application layer]] (Layer 7)
| ports        = TCP/113
| rfcs         = {{IETF RFC|1413}}
}}
{{IPstack}}
The '''Ident Protocol''' ('''Identification Protocol''', '''Ident'''), specified in [https://tools.ietf.org/html/rfc1413 RFC 1413], is an [[Internet]] protocol that helps identify the user of a particular [[Transmission Control Protocol|TCP]] connection. One popular daemon program for providing the ident service is '''identd'''. 

==Function==

The Ident Protocol is designed to work as a server daemon, on a [[User (computing)|user]]'s computer, where it receives requests to a specified [[Port (computer networking)|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|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).<ref name="rfc">{{cite IETF |title=Identification Protocol |rfc=1413 |last=Johns |first=Michael |date=February 1993 |publisher=[[Organization:Internet Engineering Task Force|IETF]] |access-date=1 April 2013 }}</ref>

==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 [[Software:SuEXEC|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).

==Security==
The ident protocol is considered dangerous because it allows crackers to gain a list of usernames on a computer system which can later be used for attacks. A generally accepted solution to this is to set up a generic/generated identifier, returning [[Node (networking)|node]] information or even [[Social:Gibberish|gibberish]] (from the requesters point of view) rather than usernames. This gibberish may be turned into real usernames by the ident administrator, when he or she is contacted about possible abuse, which means the usefulness for tracking abuse is preserved.

==Uses==

Ident is important on [[Internet Relay Chat|IRC]] as a large number of people connect to IRC from a server shared by multiple users, often using a bouncer. Without Ident there would be no way to ban a single user without banning the entire host. The server administrator may also use this information to identify the abusive user.

On most IRC networks, when the server fails to get an Ident response it falls back to the username given by client, but marks it as "not verified", usually by prefixing with a tilde; e.g., {{mono|~josh}}. Some IRC servers even go as far as blocking clients without an ident response,<ref>{{cite web | url = http://www.ircd.de/doc/ident.html#1 | title = News für IRCNet-Nutzer bei T-Online | publisher = german IRCnet opers | access-date  = 2011-12-26}}</ref> the main reason being that it makes it much harder to connect via an "[[Open proxy|open proxy]]" or a system where you have compromised a single account of some form but do not have [[Superuser|root]] (on Unix-like systems, only root can listen for network connections on ports below 1024).

However, Ident provides no additional authentication when the user is connecting directly from their personal computer, on which they have enough privileges to control the Ident daemon as well.<ref name="rfc" />

==Software==

* [[Software:Oidentd|oidentd]] (for Unix-like systems)
* [https://sourceforge.net/projects/retinascan/ Retina Scan Identd] (for Windows; supports multiple users in a way similar to Unix identd)
* [http://rndware.info/products/windows-ident-server.html Windows Ident Server].

==See also==
*[[Internet Relay Chat|IRC]]
*[[File Transfer Protocol|FTP]]
*[[Simple Mail Transfer Protocol|SMTP]]
*[[Social:Network News Transfer Protocol|NNTP]]
*[[Secure Shell|SSH]]
*SOCKS proxies ([[SOCKS]])

==References==
{{reflist}}

== Further reading ==

* {{IETF RFC|912|link=no}} – Authentication Service
* {{IETF RFC|931|link=no}} – Authentication Server
* [[Biography:Daniel J. Bernstein|Daniel J. Bernstein]]: [http://tools.ietf.org/html/draft-bernstein-tap TAP Internet Draft], June 1992
* [[Biography:Daniel J. Bernstein|Daniel J. Bernstein]]: [http://ftp.lysator.liu.se/pub/unix/ident/doc/why-tap.txt Why TAP? A White Paper], 1992-08-20
* {{IETF RFC|1413|link=no}} – Identification Protocol
* {{IETF RFC|1414|link=no}} – Identification MIB
* Peter Eriksson: [http://ftp.lysator.liu.se/pub/unix/ident/TAPvsIDENT TAPvsIDENT], 1993-11-03
* Damien Doligez: [https://web.archive.org/web/20060616060249/http://www.geckil.com/~harvest/tcpip-docs/why-encrypt.txt Why encrypt ident/TAP replies?], 1994-02-22

[[Category:Internet protocols]]
[[Category:Email authentication]]

{{Sourceattribution|Ident protocol}}