Resumo

  • A RFC 9887 dá ao TACACS+ sobre TLS uma fronteira de serviço própria, exige TLS 1.3 e autenticação mútua, proíbe dados de aplicação em 0-RTT e impede o retorno ao serviço sem TLS após uma falha segura.
  • Os caminhos novo e antigo podem coexistir durante a transição, mas o período é considerado inseguro até terminar; alcançar o servidor legado não comprova continuidade do serviço protegido.

Numa migração de segurança, a frase decisiva costuma dizer o que fazer quando o caminho novo não funciona. A RFC 9887 determina que um cliente TACACS+ não volte a uma conexão sem TLS quando a conexão TLS falhar, inclusive durante a migração.

TACACS+ transporta administração de equipamentos. A RFC 8907 separa autenticação, autorização e contabilização, mas o mecanismo histórico aplicado ao corpo do pacote é ofuscação, não proteção moderna. A RFC 9887 o substitui na variante protegida por autenticação e criptografia TLS. Não se trata de habilitar uma opção no mesmo serviço ambíguo.

Serviços separados tornam a regra verificável

Depois que TCP é estabelecido, o handshake TLS começa imediatamente. Não se permite iniciar sem proteção e negociar uma atualização. Por padrão, o TACACS+ antigo usa TCP 49 e o novo serviço tacacss usa TCP 300, conforme o registro da IANA.

A separação permite filtrar os dois fluxos, evita interferência no mecanismo de atualização e reduz envio acidental causado por configuração ambígua. A RFC também recomenda hosts diferentes. Equipamentos que não implementam TLS podem precisar de um servidor legado dedicado, mas esse servidor não é a reserva automática de um cliente obrigado a usar TLS.

Uma porta aberta comprova apenas um ponto de entrada. Não comprova o par esperado, a versão negociada, o certificado validado, o handshake completo, a mensagem TACACS+ aceita, a autorização ou a ação executada. Cada camada precisa de evidência própria.

Autenticar o transporte não autoriza o comando

TLS 1.3 é o mínimo; versões anteriores são proibidas. A especificação atual é a RFC 9846, acompanhada pela orientação da RFC 9325. As implementações devem oferecer autenticação mútua por certificados como opção interoperável.

Cada par valida o caminho e a revogação conforme o perfil X.509, e a identidade do serviço segue a RFC 9525. O sucesso autentica o par TLS. A política local ainda pode restringir a conexão, e o serviço TACACS+ continua responsável por decidir o que cada usuário ou comando pode fazer.

Um certificado válido não é autorização de comando. Um handshake concluído não é registro contábil. Uma resposta positiva não prova que a ação ocorreu nem que o estado final correspondeu à intenção. A autoridade de uma fronteira não se propaga para todas as seguintes.

A RFC também proíbe dados TACACS+ em 0-RTT. Clientes e servidores não incluem early_data, e o servidor desconecta quem envia dados antes do fim do handshake. Um ticket de retomada pode ajudar a formar uma nova conexão autenticada; não permite entrada AAA sujeita a repetição antecipada.

A falha não cria permissão

A proibição de retrocesso evita que um incidente de disponibilidade se torne uma mudança silenciosa de política. Certificado vencido ou revogado, cadeia incompleta, isolamento da autoridade certificadora, indisponibilidade de revogação ou queda do servidor seguro geram pressão operacional. Nenhum desses fatos transforma o servidor antigo alcançável num par protegido aceitável.

A continuidade deve preservar o padrão de evidência: vários servidores seguros, cadeias provisionadas, revogação funcional, rotação ensaiada, monitoramento independente e recuperação fora de banda. Se houver exceção humana, ela precisa de dono, escopo, prazo e auditoria; não pode aparecer como ramificação invisível de nova tentativa.

Coexistência é exposição, não conclusão

A RFC reconhece que os dois serviços podem existir durante a migração, mas chama essa fase de insegura até que seja concluída e recomenda reduzir o tempo em que um cliente conhece ambos.

Ter 90% dos clientes migrados não prova 90% de segurança. O caminho fraco restante ainda pode receber tráfego sensível, e provocar a falha TLS pode ser a forma de tentar acioná-lo. A conclusão exige demonstrar que clientes migrados não conseguem voltar à porta 49 e que servidores antigos atendem apenas uma população explicitamente isolada.

SNI permanece visível no início da conexão. Certificados curinga ampliam o impacto de uma chave comprometida e devem ficar restritos a um subdomínio dedicado. Descoberta de serviço está fora do escopo. Esses elementos são entradas para governança local, não provas automáticas de autoridade institucional.

Fontes