Protocolo Ident

El protocolo Ident ( Protocolo de Identificación , a menudo simplemente ident ) es un protocolo de capa de aplicación especificado en RFC 1413. ^{[ 1 ]} Dado un par de números de puerto TCP correspondientes a una conexión existente, un servidor Ident devuelve una cadena corta que identifica al propietario de esa conexión en el host del servidor. El protocolo escucha en el puerto TCP 113. ^{[ 2 ]} Reemplaza al protocolo anterior de "Servidor de Autenticación". ^{[ 3 ] [ 1 ]} 

El protocolo Ident está diseñado para funcionar como un demonio de servidor en el ordenador del usuario , donde recibe solicitudes a un puerto TCP específico , generalmente el 113. En la consulta, el cliente especifica un par de puertos TCP (uno local y otro remoto), codificados como decimales ASCII y separados por comas (,). El servidor envía entonces una respuesta que identifica el nombre de usuario del programa que ejecuta el par de puertos TCP especificado, o bien indica un error.

Supongamos que el host A quiere saber el nombre del usuario que se conecta a su puerto TCP 23 ( Telnet ) desde el puerto 6191 del cliente (host B). El host A abriría entonces una conexión al servicio ident en el host B y realizaría la siguiente consulta:

6191, 23

Como las conexiones TCP generalmente usan un único puerto local (6191 en este caso), el host B puede identificar sin ambigüedad el programa que inició la conexión especificada al puerto 23 del host A, si existe. El host B emitiría entonces una respuesta, identificando al usuario ("stjohns" en este ejemplo) propietario del programa que inició esta conexión y el nombre de su sistema operativo local :

6193, 23: ID DE USUARIO: UNIX: stjohns

Pero si resultara que no existe tal conexión en el host B, en su lugar emitiría una respuesta de error:

6195, 23: ERROR: NO HAY USUARIO

Todos los mensajes de identificación deben estar delimitados por una secuencia de fin de línea que consta de los caracteres de retorno de carro y salto de línea (CR+LF). ^{[ 1 ]}

Los servidores de acceso telefónico o de shell compartido suelen proporcionar identificadores para rastrear los abusos hasta usuarios específicos. Si el abuso se gestiona en este servidor, la preocupación por confiar en el demonio identificador es prácticamente irrelevante. La suplantación de identidad del servicio y los problemas de privacidad pueden evitarse proporcionando tokens criptográficamente seguros en lugar de nombres de usuario reales.

Si los administradores del servicio al que se conectan los usuarios mediante el servidor que proporciona la identidad van a gestionar el abuso, dicho servicio debe proporcionar información que identifique a cada usuario. Por lo general, a los administradores del servicio remoto les resulta imposible saber si los usuarios se conectan a través de un servidor de confianza o desde un ordenador que ellos mismos controlan. En este último caso, el servicio de identidad no proporciona información fiable.

La utilidad de Ident para demostrar una identidad conocida a un host remoto se limita a las circunstancias en las que:

• El usuario que se conecta no es el administrador de la máquina. Esto solo suele ocurrir en hosts que proporcionan acceso a la línea de comandos de Unix , servidores compartidos que utilizan una estructura similar a suEXEC y similares.
• Se confía en los administradores del equipo y se conocen sus políticas de usuario. Esto suele ser así en el caso de equipos que comparten un dominio de seguridad común, como por ejemplo dentro de una misma organización.
• Se confía en que la máquina es quien dice ser y se la conoce. Esto solo se logra fácilmente en redes locales o virtuales donde todos los hosts son de confianza y no se pueden agregar nuevos hosts fácilmente debido a la protección física. En redes remotas y locales normales, se pueden obtener respuestas de identificación falsas mediante la suplantación de IP y, si se usa DNS, mediante todo tipo de trucos de DNS. El demonio de identificación puede proporcionar respuestas firmadas criptográficamente que, si se pueden confirmar, resuelven estas últimas preocupaciones, pero no la primera.
• No existen obstáculos intermedios para conectarse a identd, como cortafuegos, NAT o proxy (por ejemplo, si se utilizara ident con Apache httpd). Estos son problemas comunes al cambiar entre dominios de seguridad (como con servidores HTTP o FTP públicos ).

Ident es un servicio simple de solicitud/respuesta sobre TCP. Un cliente se conecta al servidor en el puerto 113 y envía el puerto TCP del servidor y el puerto TCP del cliente como decimales ASCII separados por una coma (por ejemplo, 6191, 23). El servidor responde con una USERIDrespuesta que incluye una etiqueta del sistema operativo y una cadena de identificador, o con un ERRORcódigo como NO-USERo HIDDEN-USER. ^{[ 1 ]}

La especificación señala que la información de Ident es tan confiable como el host que la devuelve y puede revelar información que normalmente se consideraría privada. Advierte contra el uso de Ident para el control de acceso. ^{[ 1 ]}

La guía de seguridad BCP del IETF también describe el uso de Ident para la autenticación del remitente (por ejemplo, en sistemas de correo) como “una mala idea”, citando riesgos que incluyen el reenvío, el secuestro de TCP y la posibilidad de respuestas engañosas o falsas; también señala problemas operativos debido a que muchos sitios descartan o bloquean las consultas de Ident. ^{[ 4 ]}

Históricamente, Ident se utilizaba en sistemas multiusuario para facilitar la auditoría y la gestión de abusos (por ejemplo, en redes IRC). Las especificaciones modernas de IRC consideran Ident como opcional: los servidores PUEDEN usar el protocolo Ident para buscar el "nombre de usuario real" de un cliente y (si está habilitado) a menudo marcan los nombres proporcionados por el cliente como no verificados cuando no se recibe una respuesta de Ident. ^{[ 5 ]}

En la práctica, el uso generalizado de cortafuegos y traducción de direcciones de red (NAT) reduce la utilidad de Ident en las redes, ya que las conexiones entrantes a los hosts cliente suelen ser bloqueadas o traducidas. ^{[ 6 ]}

Ident se publicó como estándar propuesto en febrero de 1993, reemplazando al anterior “Servidor de autenticación”. ^{[ 3 ] [ 1 ]} El nombre del servicio “auth/ident” sigue asignado al puerto TCP 113 en el registro de IANA. ^{[ 2 ]}

• oidentd (para sistemas tipo Unix)
• SMTP
• NNTP
• SSH
• Proxies SOCKS

• RFC 912 – Servicio de autenticación 
• RFC 931 – Servidor de autenticación 
• Daniel J. Bernstein : Borrador de TAP para Internet , junio de 1992
• Daniel J. Bernstein : ¿Por qué TAP? Un documento técnico , 20 de agosto de 1992
• RFC 1413 – Protocolo de identificación 
• RFC 1414 – MIB de identificación 
• Peter Eriksson: TAPvsIDENT , 1993-11-03
• Damien Doligez : ¿Por qué cifrar las respuestas de identificación/TAP?, 22 de febrero de 1994