Resumen

  • El servidor consultante abría otra conexión hacia el puerto TCP 113 del host de origen. Las direcciones de esa segunda conexión y el par ordenado de puertos de la primera delimitaban la búsqueda en el estado local.
  • El servicio nació con una promesa de autenticación en RFC 912 y RFC 931. RFC 1413 lo renombró Identification Protocol para ajustar el título a una función más modesta.
  • USERID era una afirmación del sistema remoto. HIDDEN-USER, NO-USER y UNKNOWN-ERROR mostraban que la observación dependía de capacidad y política; por eso el RFC prohibía usarla como control de acceso.

La inversión que localizaba una conexión

A inicia una conexión desde su puerto 6191 al puerto 23 de B. B observa un puerto local 23 y uno remoto 6191. Si B quiere preguntar a A qué usuario pertenece el flujo, abre una conexión nueva al puerto 113 de A y envía 6191, 23.

La pareja se escribe desde la perspectiva del host que responde. Para A, 6191 es local y 23 es remoto. Si B conserva su propia perspectiva y pregunta 23, 6191, solicita otra entrada. El formato parece mínimo, pero conserva dirección y roles.

RFC 1413 no repite las direcciones IP en la línea de consulta. Se toman de la conexión que transporta la pregunta. Así, dos direcciones y dos puertos acotan una conexión TCP entre los mismos hosts. La consulta no enumera usuarios ni pregunta por un tercero: pide al equipo de origen que examine una asociación local concreta.

Una respuesta válida repite el par, declara USERID, indica un tipo de sistema operativo y aporta una cadena. Puede especificar un juego de caracteres. También admite OTHER, que permite devolver un token sin prometer que sea una cuenta Unix, una identidad mundial o un nombre estable.

Cuando el nombre del servicio prometía más

RFC 912, de septiembre de 1984, lo llamó Authentication Service. Imaginó que FTP compararía el nombre indicado en la aplicación con el usuario que el host remoto asociaba a la conexión. Incluso abordó operaciones privilegiadas.

El texto, sin embargo, ya dependía de una condición fuerte: confiar en la administración del otro sistema, en su contabilidad y en que un usuario local no pudiera manipular la respuesta. Un equipo comprometido podía afirmar el nombre que más le conviniera.

En enero de 1985, RFC 931 formalizó Authentication Server Protocol. Fijó la pareja de puertos, las respuestas USERID y ERROR y el campo OPSYS. También exploró mapas de acceso locales. Era tentador pensar que cada aplicación podía heredar la identificación que el host remoto ya poseía.

Pero una relación local no es una credencial. El protocolo no demostraba quién estaba ante el terminal, no protegía criptográficamente la contestación y no imponía una semántica común para un nombre entre organizaciones. La arquitectura entregaba una declaración del equipo consultado, no una prueba independiente de él.

El título de 1993 corrigió la cadena de confianza

RFC 1413, publicado por el grupo IDENT del IETF en febrero de 1993, reemplazó RFC 931. Cambió el nombre a Identification Protocol porque describía mejor su función.

La sección de seguridad acotó el uso: el resultado puede ayudar a auditar, pero no debe ser un identificador de control de acceso. Si B abre una puerta al recibir alice, A puede fabricar alice para cualquier conexión. La consulta inversa no ha añadido una autoridad que no dependa de A.

La identificación solo dice qué etiqueta asocia A a ese flujo. No autentica a una persona, no garantiza que el mismo texto designe al mismo sujeto en B y no autoriza una operación. Al rebajar la pretensión, el protocolo hizo más clara su utilidad real.

B puede guardar el nombre con fecha, direcciones, puertos y registros de aplicación. Luego el administrador de A puede contrastarlo con sesiones y procesos. El dato es un puente para que dos operadores encuentren el mismo episodio; no es el veredicto sobre ese episodio.

Una etiqueta local viaja, pero no se vuelve universal

El campo de sistema operativo ayudaba a interpretar el identificador, y el juego de caracteres evitaba que una secuencia de bytes se leyera de manera incompatible. Ninguno otorgaba autoridad. OTHER hacía explícito que algunos hosts entregarían un token opaco.

La recomendación era devolver un identificador útil para el administrador del host consultado, sin revelar de forma gratuita comandos o detalles de proceso. La finalidad no consistía en permitir inspección remota general, sino en facilitar correlación posterior.

También era necesario conservar el tiempo. Los puertos efímeros se reutilizan; el mismo par puede pertenecer después a otra conexión. Una prueba operativa necesita direcciones, puertos, sentido y hora de la conexión original, más la consulta y respuesta completas. Un nombre sin esa secuencia puede atribuir el hecho equivocado.

Derivar las direcciones de la conexión de consulta reduce ambigüedad, no crea vínculo criptográfico. La ruta sigue siendo una red ordinaria y el host remoto sigue controlando la respuesta. Una pregunta bien formada prueba que se preguntó por el flujo correcto, no que se recibió la verdad.

Ocultar era una opción prevista, no una anomalía

INVALID-PORT indicaba sintaxis o rango inválidos. NO-USER decía que no se podía identificar un usuario para la conexión. HIDDEN-USER permitía saberlo y, aun así, no revelarlo por política. UNKNOWN-ERROR evitaba exponer una causa interna; cerrar antes de responder debía interpretarse igual.

Cada estado tiene un límite. NO-USER no demuestra anonimato, HIDDEN-USER no acusa al usuario y UNKNOWN-ERROR no demuestra que no exista una relación. Solo informa de lo que el servicio remoto puede o quiere declarar en ese momento.

RFC 1413 comparó la privacidad con CallerID y Finger. Un nombre rutinario dentro del host cambia de naturaleza cuando cualquier servidor al que se conecta el usuario puede solicitarlo. Desactivar el servicio, ocultar cuentas o usar tokens son decisiones legítimas, aunque reducen o transforman el valor de auditoría.

La MIB repitió el alcance sin elevar la certeza

RFC 1414 creó una MIB indexada por dirección y puerto locales, dirección y puerto remotos. La misma geometría pasó a una tabla de gestión con identificador y estado.

RFC 1414 figura hoy como Historic; RFC 1413 aparece como Proposed Standard. Eso no mide uso actual. La MIB repite que la información no es autoritativa y no debe gobernar acceso. Estructurar una declaración facilita consultarla; no la convierte en prueba.

El registro de nombres de servicio y puertos de IANA conserva ident y el antiguo auth en TCP 113. Establece el punto de encuentro y guarda la historia del cambio. No certifica la cuenta, el sistema operativo, la política ni la honradez detrás de la respuesta.

La utilidad apareció al separar dos decisiones

La atribución pregunta qué usuario dice A que poseía una conexión. La autorización pregunta qué permite B con evidencia que B acepta. Aunque ambas decisiones puedan mostrar el mismo nombre, pertenecen a autoridades distintas.

IDENT delimitó la pregunta mediante dos hosts, dos puertos y un instante. Los errores admitieron ignorancia; HIDDEN-USER admitió reserva; la seguridad admitió engaño. Dentro de esos límites, USERID mejora una cronología. Fuera de ellos, entrega al sistema remoto el poder de acuñar la cadena que activa un privilegio.

Pasar de Authentication a Identification no fue abandonar la precisión. Fue retirar de la etiqueta una autoridad que el intercambio nunca había demostrado.

Fuentes y límites de la evidencia

Las fuentes documentan especificaciones sucesivas, la MIB y el registro del servicio. No cuantifican despliegue actual, exactitud, políticas de privacidad ni ataques. Este artículo tampoco deduce comportamientos de NAT, proxys o contenedores ausentes del conjunto cerrado.