An identification or Identd protocol, also called a user authentication protocol, is an interactive protocol that allows one party to prove their identity to another party. The part that is identified is called a tester. The party that verifies identity is called the verifier. They can be of two types: cryptographic or non-cryptographic, hosts or shared shell servers often provide identities to allow abuse to be traced to specific users. In the event that abuse is handled on this host, the concern with trusting the ident daemon is mostly irrelevant. Service spoofing and privacy concerns can be avoided by providing variable cryptographically strong tokens instead of actual usernames.
But of course is something to keep in mind because this identification protocol is considered dangerous because it allows hackers to obtain a list of usernames on a computer system that can then be used for attacks and that is why a generally accepted solution for this is to configure a generic identifier, which returns node information instead of usernames. This function can be converted to real usernames by the identity manager, when he or she is contacted about possible abuse, which means that the usefulness for tracking abuse is preserved.
The utility of Identd to prove a known identity to a remote host is limited to circumstances where:
▸You trust that the machine is the machine it claims to be and you know it. 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 be easily added due to physical protection. On normal, remote local networks, fake ID responses can be achieved by IP spoofing and, if using DNS, by all kinds of DNS tricks. The ident daemon can provide cryptographically signed responses that, if confirmed, resolve the latter, but not the former, concerns.
▸The user connecting is not the administrator of the machine. This is only likely for hosts that provide access to the Unix shell, shared servers that use a construction similar to suEXEC, and the like.
▸You trust the administrators of the machine and know their user policy. This is most likely for hosts in a common security domain, such as within a single organization.
▸There are no intermediate obstacles to connecting to identd such as firewall, NAT or proxy and these are common events when moving from one security domain to another
Related reads:
SIP Protocol and how it works?
PPP protocol and what does it offers us
