Resumen

  • La RFC 9887 especifica TACACS+ sobre un mínimo de TLS 1.3. El cliente inicia TLS inmediatamente después de establecer TCP y envía TACACS+ únicamente como datos de aplicación TLS; un fallo TLS no autoriza fallback a una ruta no TLS.
  • Las implementaciones deben admitir autenticación mutua basada en certificados. Cada extremo valida la cadena del certificado remoto, incluida la comprobación de revocación. Las PSK TLS y las claves públicas sin formato son alternativas opcionales; una PSK TLS debe mantenerse separada del secreto de ofuscación TACACS+ heredado.
  • El 0-RTT de TLS está prohibido para datos TACACS+ porque existe riesgo de repetición. Los tickets de reanudación son de un solo uso y la revocación debe comprobarse de nuevo durante la reanudación. El mecanismo histórico de ofuscación queda obsoleto para la operación TLS; los extremos establecen el indicador de no cifrado porque TLS proporciona confidencialidad e integridad.
  • Un servidor TACACS+ TLS debe rechazar conexiones no TLS. La RFC 9887 considera insegura la fase mixta hasta que finaliza y señala que su duración debería minimizarse. Los servidores no TLS deberían separarse de los servidores TLS. IANA asignó el puerto TCP 300 y el nombre tacacss; siguen siendo posibles otros puertos con una consideración operativa explícita.

La distinción clave está entre el comportamiento del protocolo y la arquitectura de migración. «Sin fallback» es una regla del cliente: un intento TLS fallido no puede convertirse silenciosamente en un intento de autenticación no TLS. Eso no significa que todos los dispositivos puedan actualizarse simultáneamente. Una organización puede conservar un servicio heredado con direccionamiento separado para el equipo que todavía no puede migrar, pero esa excepción mantiene una ruta insegura y no vuelve seguro el despliegue completo. Terminar la migración exige algo más que demostrar que responde un extremo TLS.

En el extremo TLS, la secuencia observable empieza con la negociación inmediata después del establecimiento TCP; después, los registros TACACS+ viajan dentro de datos de aplicación TLS. La base es la autenticación mutua mediante certificados, con validación de la cadena y del estado de revocación en ambos sentidos. Puede elegirse una PSK o una clave pública sin formato cuando el protocolo lo permita, pero la PSK no debe confundirse con el secreto de ofuscación heredado ni sustituirlo. La reanudación no elimina la comprobación de revocación y un ticket no puede tratarse como reutilizable. Ningún extremo debe enviar datos TACACS+ en 0-RTT.

TLS proporciona confidencialidad e integridad, por lo que el mecanismo de ofuscación TACACS+ queda obsoleto para la operación TLS y los extremos establecen el indicador de no cifrado. Esto no afirma que un servidor heredado sea seguro; describe la representación dentro del intercambio protegido por TLS. El servidor TLS no acepta conexiones no TLS. Un servidor no TLS operado por separado es una facilidad de transición, no un punto de fallback.

La evidencia congelada no establece la cobertura actual de implementaciones, la adopción en producción del puerto TCP 300, la duración observada de las migraciones o los incidentes de downgrade, la disponibilidad de autoridades certificadoras, la latencia de comprobación de revocación en redes desplegadas, ni los efectos de rendimiento medidos de la reanudación TLS. La RFC 9887 tampoco establece prevalencia de despliegues, resultados operativos, conformidad de proveedores, historial de incidentes o adopción actual por parte de operadores.

Ruta de decisión para el operador

  1. Análisis de Theo March: inventariar cada dispositivo, su modo TACACS+, su dirección, los materiales de confianza, su capacidad de certificados o PSK y si puede usar TCP 300 o un puerto alternativo evaluado explícitamente.
  2. Si admite TLS 1.3 y la autenticación requerida, trasladarlo al servidor TLS. Verificar la cadena del certificado y la revocación, o verificar el método PSK/clave pública elegido y su separación de los secretos heredados.
  3. Si falla la negociación TLS, detenerse e investigar; no activar fallback del cliente. Si el dispositivo no puede migrar, colocarlo únicamente en el servicio heredado separado y registrar, como análisis de Theo March, un responsable y una fecha de vencimiento para la excepción.
  4. Análisis de Theo March: al terminar la excepción, eliminar la accesibilidad heredada, las reglas de firewall y las rutas, así como las credenciales o secretos heredados; después comprobar que el servidor TLS rechaza tráfico no TLS. Estos controles no son requisitos adicionales de la RFC.

Fixtures de verificación

Usar una captura que muestre el establecimiento TCP seguido inmediatamente por una negociación TLS 1.3, sin bytes TACACS+ en claro. Presentar un certificado de par inválido o revocado y confirmar el rechazo. Intentar 0-RTT y confirmar que los datos TACACS+ no se aceptan como datos tempranos. Reutilizar un ticket de reanudación y confirmar el uso único y una nueva comprobación de revocación. Enviar una conexión no TLS al receptor TLS y confirmar el rechazo; probar por separado que un fallo TLS produce un error y no una conexión al servicio heredado.

Por último, inspeccionar el indicador de no cifrado y confirmar que el secreto de ofuscación heredado no se usa como PSK TLS.

Fuentes