Resumen

  • RFC 927 propuso TUID, la opción Telnet 26, para que un host que ya había autenticado a una persona entregara a un destino que consintiera un identificador binario de 32 bits.
  • WILL TUID y DO TUID debían coincidir antes de que viajara el valor; WON'T y DON'T convertían la negativa en un resultado normal del protocolo.
  • El valor no repetía una contraseña ni concedía permisos locales: era la afirmación de un host dentro de una relación de confianza que el otro host podía rechazar.

En diciembre de 1984, Brian A. Anderson, de BBN, publicó la RFC 927, TACACS User Identification Telnet Option. El problema era la doble identificación. Una persona podía haber presentado ya un nombre y una contraseña correctos ante un Terminal Access Controller, o TAC. Cuando aquel TAC abría después una conexión Telnet hacia otra máquina en nombre de la persona, volver a pedir el secreto era costoso y poco elegante.

La solución propuesta no mandaba el secreto hacia adelante. La opción TUID, con el código 26, permitía que el lado usuario de Telnet dijera que autenticaría a la persona y enviaría su UUID. Si el lado servidor aceptaba ese papel, una subnegociación llevaba un número binario de 32 bits: cuatro octetos, no la posterior convención de UUID de 128 bits.

La diferencia decisiva estaba fuera del número. La fuente podía afirmar que había autenticado; el destino debía decidir si confiaba en esa afirmación. El ahorro de una pregunta al usuario introducía una decisión entre operadores, no una transferencia automática de autoridad.

La primera comprobación se convirtió en testimonio

Según RFC 927, TACACS exigía un par nombre/contraseña correcto antes de que el TAC conectara al usuario con un host. El TAC poseía por ello un hecho local: su procedimiento había aceptado a alguien asociado con un identificador. Con TUID podía comunicar ese resultado a la máquina siguiente.

No era una repetición verificable de la contraseña. El destino recibía algo más parecido a una declaración: «yo autentiqué al usuario para quien abrí esta conexión, y éste es el número que empleo para nombrarlo». Que esa declaración sirviera para evitar otro login dependía de la política del receptor.

La RFC lo dice sin ambigüedad: los hosts podían aceptar la autenticación del TAC o no hacerlo, a su elección. La máquina origen controlaba su propio procedimiento de autenticación. La máquina destino mantenía la responsabilidad sobre el servicio que exponía. Ninguno de los dos papeles absorbía al otro.

Primero el consentimiento, luego el parámetro

El diseño usaba la gramática opcional de Telnet. RFC 854 definía WILL, WON'T, DO y DON'T para ofrecer, solicitar, aceptar o rechazar una función adicional a la terminal virtual básica. RFC 855 añadía la disciplina de parámetros: la subnegociación no debía empezar hasta que ambas partes hubieran acordado entender la opción.

En TUID, IAC WILL TUID proponía o aceptaba autenticar al usuario y enviar el identificador desde el lado usuario. IAC DO TUID proponía o aceptaba recibir aquella autenticación desde el lado servidor. WON'T negaba el primer compromiso y DON'T el segundo. Solo con WILL y DO alineados viajaba IAC SB TUID <uuid> IAC SE.

La RFC mostró dos caminos de éxito y dos de negativa. El servidor podía pedir primero y obtener WILL; el usuario podía ofrecer primero y obtener DO. Un programa que no conociera la opción respondía con la forma de rechazo correspondiente. La falta de soporte no se convertía en aceptación silenciosa: el flujo volvía al Telnet ordinario y el destino podía conservar su propio login.

Un UUID de 32 bits no se demostraba a sí mismo

La palabra UUID puede inducir a un error histórico. En RFC 927 es un número binario de 32 bits. El texto ilustra los valores 1, 255 y todos los bits a uno. No especifica un espacio de nombres mundial, una regla de asignación, caducidad, renovación o prevención de colisiones.

Además, el octeto 255 es IAC en Telnet. Si aparecía dentro del valor, debía duplicarse para que el receptor no lo interpretara como comando. Ese escape mantenía transparente el flujo de bytes; no aportaba cifrado, firma, frescura ni prueba criptográfica.

Por tanto, una captura de la subnegociación puede demostrar que cuatro bytes fueron presentados como el identificador del usuario después de activar la opción. No demuestra quién introdujo una contraseña, que el sistema origen aplicara bien su política, que el número fuese único, ni que el receptor lo asociara con la misma cuenta local.

Autenticar una afirmación no autorizaba una acción

Aceptar la palabra de un TAC respondía a una pregunta limitada: ¿tratará el destino esa autenticación previa como suficiente para representar a este usuario? No respondía qué archivos podía abrir, qué comando podía ejecutar, qué privilegio podía adquirir ni si una acción se completó.

Los documentos posteriores ayudan a nombrar el límite sin reescribir 1984. RFC 1492, una reconstrucción informativa de TACACS de 1993, separa la aceptación de un login de una petición CONNECT hacia una dirección y un puerto. Su propio autor advirtió que no tuvo acceso a la especificación original y que posteriores datos podían corregirlo. RFC 8907 describe el TACACS+ posterior y separa autenticación, autorización y contabilidad; también afirma que el protocolo no vincula por sí mismo una petición de autenticación a una petición de autorización. No son semántica retroactiva de TUID, sino límites comparativos.

El registro IANA de opciones Telnet aún reserva el 26 para TACACS User Identification. Eso preserva el significado del código. No mide el despliegue de TUID ni prueba que funcionara en una red concreta.

Menos fricción exigía más evidencia

El beneficio visible era una contraseña menos. La carga que aparecía era otra: el destino debía saber qué fuentes aceptaba, qué espacio de identificadores usaba cada una, cómo traducía el número a una cuenta local y cuándo retiraba esa confianza.

Un registro que solo diga «login correcto» borra la secuencia. Ya no se sabe si hubo contraseña local, aceptación TUID, mapeo de cuenta, autorización específica o ejecución real. La evidencia útil debe conservar el resultado de autenticación de origen, la negociación WILL/DO, el valor sin escape, su espacio de nombres, la decisión de confianza del destino, el permiso local y el efecto observado.

La aportación histórica de RFC 927 no fue una identidad universal. Fue una gramática pequeña para que dos hosts cooperantes pudieran ahorrar repetición sin fingir que el primero mandaba sobre el segundo. Los cuatro bytes cruzaron la conexión. La responsabilidad de aceptarlos no.

Fuentes y límites

Esta pieza usa RFC 927 como fuente principal, RFC 854 y RFC 855 para la negociación Telnet, el registro IANA para el código 26, y RFC 1492/RFC 8907 solo como comparaciones posteriores delimitadas. No prueba adopción amplia, protección criptográfica, una federación de identidad moderna ni el resultado de una sesión real.