Resumen

  • La RFC 9887 asigna a TACACS+ sobre TLS un servicio separado, exige TLS 1.3 y autenticación mutua, prohíbe datos de aplicación en 0-RTT e impide volver a una conexión sin TLS después de un fallo seguro.
  • La vía antigua y la nueva pueden coexistir durante la transición, pero ese periodo sigue siendo inseguro hasta que termina; que el servidor heredado responda no prueba continuidad del servicio protegido.

La frase más importante de una migración de seguridad suele describir la indisponibilidad, no la activación. La RFC 9887 fija esa conducta para TACACS+: un cliente no debe volver a una conexión sin TLS cuando falla la conexión TLS, incluso durante la migración.

TACACS+ transporta administración de dispositivos. La RFC 8907 separa autenticación, autorización y contabilidad, pero el mecanismo histórico aplicado al cuerpo del paquete es ofuscación, no protección moderna. La RFC 9887 lo sustituye en la variante protegida por autenticación y cifrado TLS. No añade una casilla opcional al mismo oyente ambiguo.

Dos servicios con fronteras distintas

Tras establecer TCP, la negociación TLS comienza de inmediato. No se permite iniciar una sesión débil y actualizarla después. El servidor TLS escucha en un puerto distinto del servidor heredado: salvo configuración expresa, el nuevo servicio tacacss usa TCP 300 y el antiguo usa TCP 49. El registro de IANA conserva esa asignación.

La separación hace ejecutable la política. Permite filtrar cada servicio, evita ataques sobre una negociación de actualización y reduce la exposición accidental causada por una configuración ambigua. La RFC recomienda también hosts separados. Los dispositivos que no implementan TLS pueden necesitar un servidor antiguo, pero este no es el repuesto automático de un cliente obligado a usar TLS.

Un puerto abierto sólo demuestra una posibilidad de transporte. No prueba el par esperado, la versión negociada, la cadena validada, el handshake completo, la petición TACACS+ aceptada, la autorización concedida ni la acción observada. Cada hecho necesita su propio registro.

El transporte autenticado no decide la orden

TLS 1.3 es el mínimo y se prohíben las versiones anteriores. La especificación vigente es la RFC 9846, junto con la guía operativa de la RFC 9325. Las implementaciones deben admitir autenticación mutua mediante certificados como opción interoperable común.

Cada par valida la ruta y la revocación según el perfil X.509. La identidad de servicio sigue la RFC 9525. El éxito autentica al par de transporte. La política local todavía puede imponer restricciones para aceptar la conexión, y TACACS+ debe decidir por separado qué puede hacer el usuario.

Por eso un certificado válido no es una autorización de comando. Un handshake completo no es contabilidad. Una respuesta positiva no demuestra que el dispositivo ejecutó la orden ni que el estado final coincidió con la intención. Proteger una frontera no transfiere autoridad sobre las siguientes.

La RFC 9887 tampoco permite enviar TACACS+ como datos tempranos. Clientes y servidores no deben incluir early_data, y el servidor desconecta al cliente que envía 0-RTT. Un ticket de reanudación puede ayudar a establecer otra conexión autenticada; no autoriza entrada AAA expuesta a repetición antes del nuevo handshake.

El fallo no crea permiso

La prohibición de retroceso evita que un incidente de disponibilidad se convierta en un cambio de política invisible. Un certificado puede caducar, ser revocado o presentar una cadena incompleta. Una caída de red puede aislar al par de su autoridad certificadora. El servidor seguro puede no responder. La presión es real, pero ninguno de esos hechos convierte al servidor antiguo alcanzable en un par seguro aceptable.

La continuidad debe prepararse sin reducir la prueba: varios servidores seguros, cadenas provisionadas, revocación disponible, rotaciones ensayadas, supervisión independiente y recuperación fuera de banda. Si la organización admite una excepción humana, debe tener dueño, alcance, vencimiento y registro. No puede nacer como una rama silenciosa de reintento.

La coexistencia no es finalización

La RFC acepta que durante la migración existan ambos servicios. También declara que esa fase es insegura hasta completarse y pide reducir el tiempo en que un cliente conoce servidores TLS y no-TLS.

Por tanto, migrar al 90 % de los clientes no vuelve segura al 90 % de la superficie. La vía débil restante puede recibir información sensible, y provocar un fallo TLS puede ser precisamente la forma de intentar usarla. La finalización requiere demostrar que los clientes migrados no pueden volver al puerto 49 y que los servidores antiguos sólo atienden una población aislada y explícita.

SNI permanece visible en el saludo inicial. Un certificado comodín concentra el fallo de su clave privada y debe limitarse a un subdominio dedicado. El descubrimiento de servicio queda fuera del alcance. Ninguno de esos datos nombra por sí mismo a la autoridad institucional correcta; son condiciones que la organización debe gobernar.

Fuentes