Resumen

  • Ident hacía que cada consulta se refiriera a una conexión: los puertos indicaban el servidor y el cliente tal como los veía el host consultado, que devolvía su propia cadena de usuario para ese socket.
  • RFC 931 propuso un uso experimental para el inicio de sesión automático en FTP. En 1993, RFC 1413 llamó al servicio Protocolo de Identificación y advirtió que la respuesta podía servir para auditoría, pero no para autenticar ni autorizar.

Dos puertos, la perspectiva de un host

El ejemplo más revelador de RFC 1413 parece una corrección tipográfica. Una conexión figura localmente como 23, 6191; para preguntar al otro extremo por ella, hay que enviar 6191, 23. La conexión no ha cambiado. Lo que cambia es cuál de las máquinas llama «local» a un puerto y «remoto» al otro.

Ese orden era la llave práctica del protocolo. Un cliente de Ident abría una conexión TCP al puerto 113 de un host y enviaba una línea con <puerto-en-servidor>, <puerto-en-cliente>. Las direcciones IP procedían de la conexión TCP con el propio servicio Ident. Esas direcciones y los dos puertos identificaban una conexión TCP ya existente. Entonces el servidor podía responder con el identificador, dependiente del sistema, que asociaba a esa conexión en su propia máquina.

El intercambio tenía un alcance deliberadamente limitado. No pedía a un servicio central resolver la identidad de una persona en Internet. Pedía a un host que informara cómo su sistema local relacionaba un socket determinado con una cadena de usuario. Una respuesta USERID incluía el sistema operativo y un identificador; ERROR podía indicar que no había un propietario disponible. RFC 1413 también definió HIDDEN-USER para los casos en que el servidor conocía al usuario del puerto pero ocultaba el dato a petición de este.

No era la misma superficie de consulta que Name/Finger. Una petición Finger vacía podía pedirle a un host la lista de personas conectadas; Ident seleccionaba una sola conexión TCP mediante su par de puertos. Un listado de presencia y una cadena vinculada a un socket responden preguntas operativas distintas. El artículo anterior sobre Name/Finger analiza ese límite de presencia en el host.

«Authentication Server» era una idea para una aplicación

La historia comienza con RFC 912, de Mike St. Johns, publicado en septiembre de 1984 bajo el título «Authentication Service». Proponía un servicio TCP en el puerto 113 que devolvería el identificador del propietario de una conexión TCP específica. Entre sus posibles usos mencionaba la autenticación automática de usuarios en FTP y la verificación de operaciones privilegiadas. También advertía que la confianza variaba entre hosts y dejaba que cada aplicación decidiera cuánta credibilidad otorgar a la respuesta.

RFC 931, publicado en enero de 1985, sustituyó esa propuesta. Describió con más formalidad una respuesta que unía el nombre del sistema operativo con el identificador del usuario. Para FTP bosquejó una orden USER sin argumento, de modo que el servidor pudiera recurrir al servicio. El documento calificó expresamente ese uso de experimental y reiteró la advertencia sobre la confianza en el host. Describe una integración sugerida; no demuestra que los servidores FTP la adoptaran de forma generalizada.

La diferencia entre la respuesta del protocolo y la decisión de la aplicación es esencial. El servidor de autenticación no comprobaba una contraseña de forma independiente ni demostraba quién estaba ante un terminal. Devolvía la versión del host acerca del identificador local propietario de una conexión. Un servidor FTP podía decidir usar esa cadena, pero la decisión y sus consecuencias correspondían a la aplicación y a la confianza que depositaba en el otro host.

En 1993, el nombre dejó clara la frontera

RFC 1413, publicado en febrero de 1993, dejó obsoleto RFC 931 y cambió el antiguo Authentication Server Protocol por Identification Protocol, o Ident, «para reflejar mejor su función». Conservó el puerto TCP 113 y el par de puertos específico de cada conexión. También aclaró cómo gestionar varias consultas en una conexión Ident y respuestas como HIDDEN-USER.

Las consideraciones de seguridad difícilmente admiten una interpretación más fuerte. La información devuelta era como máximo tan confiable como el host o la organización que lo operaba. El protocolo no estaba pensado para autorización ni control de acceso; en el mejor de los casos añadía información de auditoría sobre conexiones TCP. RFC 1413 desaconsejó firmemente otros usos y alertó de que el servicio podía revelar información normalmente privada.

La advertencia se desprendía del recorrido de los datos. El servidor producía el identificador según la visión de su propio sistema operativo. Un host comprometido podía responder de manera engañosa; en un ordenador de laboratorio abierto, un usuario podía elegir el identificador que aparecía. Una línea USERID sintácticamente válida no convertía la declaración del servidor en un hecho verificado por otra fuente. El cliente sabía lo que decía el host consultado, no si una persona había sido autenticada por otra vía.

El cambio de nombre marca así una frontera histórica útil, pero no prueba que todos los usos anteriores terminaran. RFC 1413 denominó al servicio identificación, no autenticación, y delimitó la inferencia segura que podía extraerse de una respuesta. Los RFC no indican cuántos sitios ejecutaban Ident, con qué frecuencia se ocultaba un identificador ni qué programas de FTP dependían de él. Un estándar documenta un contrato de protocolo, no un censo de adopción.

Lo que permite sostener el par de puertos

En un registro de auditoría, el identificador proporcionado por un host puede ser un contexto útil si se conservan el host, el sentido de la conexión, los puertos, la hora y la respuesta. Puede ayudar a saber qué cuenta local asociaba el otro extremo a un socket. No demuestra que la persona nombrada iniciara el tráfico, controlara la máquina remota ni tuviera autoridad para entrar en la aplicación.

La historia del protocolo gira en torno a esa separación. RFC 931 describió una manera posible de que una aplicación utilizara una cadena de usuario remota. RFC 1413 nombró el servicio según la identificación que realmente devolvía y desaconsejó tratar ese informe como una autoridad. Un par de puertos permitía que un host reconociera una conexión concreta. La decisión de confiar seguía en manos del sistema que resolvía qué hacer con la respuesta.

Fuentes