Resumen

  • Publicado en julio de 1993 con categoría Informational, RFC 1492 reconstruyó TACACS porque su autor no pudo obtener la especificación original por cuestiones de copyright.
  • La implementación simple de Cisco se consideraba compatible, pero no había comparación documental que lo demostrara; la variante extendida y el caso de Minnesota aportaban evidencia de uso limitado, no un censo.
  • Nonce, respuesta del daemon, actuación del servidor terminal, conexión de destino y contabilidad eran comprobantes diferentes, no sinónimos de un único “acceso autorizado”.

La dificultad no era solo que coexistieran dos variantes. Era que la palabra “TACACS” arrastraba una genealogía que nadie en la redacción podía verificar de extremo a extremo. El documento original existía, según RFC 1492, pero el autor no logró obtenerlo debido a cuestiones de copyright. Esa ausencia fue la razón principal para publicar el nuevo texto.

La colaboración con Cisco ofreció un sustituto parcial: una implementación de la versión simple que se creía compatible con el original. “Se creía” marca el límite correcto. Ejecutar un programa permite observar formatos y respuestas; no permite comparar sus decisiones con las frases de un documento inaccesible. El propio RFC avisa que, si el original aparecía después, algunas partes de la reconstrucción podrían resultar incorrectas.

Tampoco la publicación resolvía esa deuda. RFC 1492 fue Informational y señaló que no especificaba un estándar de Internet. Hizo pública una descripción operable y su incertidumbre. No convirtió la práctica de un proveedor en ley universal.

La extensión tenía su propia procedencia

La forma simple conservaba la presunta continuidad con el TACACS anterior. La forma extendida añadía solicitudes y se documentó a partir de servidores terminales Cisco y del sistema de autenticación distribuida de la Universidad de Minnesota. Esos nombres fijan una procedencia concreta. No prueban que el protocolo dominara el mercado ni que todas las instalaciones interpretaran igual los campos.

Una implementación también puede ser una mezcla: intención heredada, limitaciones del producto, errores persistentes y extensiones locales. Si solo sobrevive la mezcla, copiarla puede ser necesario para interoperar. Sin embargo, llamarla “el original” elimina precisamente la incertidumbre que un historiador o un operador necesita conservar.

LOGIN iniciaba una sesión; CONNECT pedía otra decisión

El mecanismo básico era petición y respuesta. Cada petición debía recibir respuesta, lo que permitía al daemon denegarla. LOGIN enviaba credenciales para autenticar y, si la respuesta era positiva, el servidor terminal podía iniciar una conexión de login. CONNECT aparecía dentro de una conexión ya existente y preguntaba si se podía abrir una conexión TCP hacia una dirección y un puerto concretos.

La separación temporal desmonta una equivalencia peligrosa. Haber pasado LOGIN no autorizaba automáticamente cada destino. Recibir aceptación de CONNECT tampoco probaba que el servidor terminal obedeciera, que la red entregara el intento o que el destino aceptara. La respuesta era una decisión bajo los datos y algoritmos del daemon; la acción y el resultado pertenecían a otros sistemas.

RFC 1492 dejaba esos algoritmos y datos en manos del operador. La decisión podía incorporar archivos de contraseñas o reglas propias del sitio. La libertad era útil, pero local. Dos daemons compatibles con el mismo formato podían contestar de modo distinto sin que uno violara una política universal inexistente.

El nonce cerraba una correlación pequeña

En la codificación UDP histórica, el servicio usaba el puerto 49. La petición incluía un nonce que debía reaparecer en la respuesta. Así el cliente relacionaba un datagrama recibido con una petición pendiente. La coincidencia no autenticaba al usuario ni al servidor, no cifraba el contenido y no certificaba que la política empleada fuera la correcta.

Las retransmisiones mostraban lo frágil de resumir el intercambio. Tras un timeout, el cliente UDP podía volver a enviar. El servidor no hacía reintentos. El RFC observa que el diseño parecía requerir peticiones idempotentes, aunque en realidad no lo eran. Si el primer procesamiento ya había alterado el estado de una conexión y solo se perdió la respuesta, el segundo paquete no era necesariamente una repetición sin consecuencias.

Por eso dos mensajes con el mismo nonce no bastan para contar una sola decisión. Hacen falta tiempos, estado del daemon, motivo del retry y registro de actuación del servidor terminal.

La contraseña visible viajaba antes que la aceptación

Las codificaciones UDP y TCP incluían usuario y contraseña en texto claro. El análisis de seguridad advertía que un monitor podía capturar pares de credenciales y que el servicio permitía sondear combinaciones de usuario y contraseña. Operar en una red administrada podía reducir exposición física; no añadía confidencialidad criptográfica al paquete.

La versión TCP resolvía encuadre y entrega. Era explícitamente incompatible con el TACACS histórico, usaba el flujo para simplificar la representación y permitía respuestas más amplias. Pero recibir todos los bytes en orden no demostraba quién los envió, no ocultaba las credenciales y no convertía la decisión del daemon en un efecto consumado.

TACACS+ es una comparación posterior

Mucho después, RFC 8907 describió TACACS+ como una suite que separa autenticación, autorización y contabilidad. Además, aclaró que una sesión del protocolo no siempre representa a una persona o una acción y que una solicitud de autenticación no queda automáticamente vinculada a otra de autorización. Esa precisión ayuda a no fusionar recibos, pero no debe proyectarse sobre 1993 como si ambos protocolos fueran uno.

RFC 927 también queda en su propio lugar: su opción TELNET TUID entregaba una identificación de usuario. RFC 1492 trata otra frontera, la reconstrucción de un protocolo de decisión mediante una implementación disponible y un texto ausente.

La contribución duradera del memo es metodológica. Puede publicarse una descripción útil sin fingir que se posee la fuente. Puede observarse código sin elevarlo a constitución. Y puede recibirse un ACCEPT sin afirmar todavía que hubo identidad auténtica, ejecución correcta, conexión o contabilidad.

Fuentes