Resumo

  • RFC 1492 saiu em julho de 1993 como Informational porque o autor não conseguiu obter a especificação TACACS original por questões de copyright e precisou reconstruir o mecanismo.
  • A implementação simples da Cisco era considerada compatível, mas isso não foi provado por comparação com o original; a versão estendida e o caso da Universidade de Minnesota dão evidência limitada de uso.
  • Repetição UDP, nonce, resposta do daemon, ação do servidor de terminais, conexão de destino e contabilidade são registros diferentes e não devem virar um único “acesso aceito”.

A retransmissão é um bom lugar para começar porque mostra como um detalhe aparentemente mecânico altera a história de uma conexão. Se a primeira resposta se perde, o cliente envia de novo. Mas a primeira solicitação pode já ter sido processada e mudado estado. Dois datagramas iguais não provam uma operação única nem duas operações efetivas; é preciso recuperar tempo, estado e ação.

RFC 1492 publicou essa tensão sem escondê-la. Fez o mesmo com sua própria procedência. O texto diz que a especificação TACACS original existia, porém o autor não a obteve por questões de copyright. Essa ausência foi a razão principal do novo documento. Em colaboração com a Cisco Systems, ele usou uma implementação simples que se acreditava compatível com o original.

A expressão “se acreditava” protege a fronteira da prova. Código em execução permite repetir entradas e observar saídas. Não revela se uma opção foi omitida, se um ramo é extensão do produto ou se um bug antigo virou comportamento necessário. O RFC avisou que a descoberta posterior da especificação original poderia mostrar que partes de sua reconstrução estavam erradas.

O status também limita a autoridade. RFC 1492 é Informational e não especifica um Internet Standard. A publicação colocou a reconstrução no arquivo público; não transformou o comportamento da Cisco na intenção universal de um documento inacessível.

A versão estendida tinha recibos próprios

O memo separa TACACS simples e estendido. A compatibilidade presumida dizia respeito à implementação simples da Cisco. A empresa também tinha a forma estendida, usada por seus servidores de terminais e pelo sistema de autenticação distribuída da Universidade de Minnesota. Isso demonstra operação em ambientes identificados, não adoção ampla, uniformidade de produtos ou sucesso de cada instalação.

Quando só o executável circula, copiar o executável pode ser a decisão razoável para manter interoperabilidade. O erro começa quando essa escolha prática passa a ser descrita como prova histórica. A reconstrução pode ser útil sem adquirir a identidade da fonte perdida.

LOGIN e CONNECT pediam decisões em momentos diferentes

Cada solicitação do cliente exigia uma resposta do daemon e podia ser negada. LOGIN apresentava credenciais e, se aceito, permitia ao servidor de terminais iniciar uma conexão de login. CONNECT ocorria dentro de uma conexão já existente e perguntava se devia abrir uma conexão TCP para determinado endereço e porta de destino.

Autenticar em LOGIN não concedia acesso irrestrito a qualquer destino. Receber uma resposta positiva a CONNECT também não provava que o servidor de terminais executou a decisão, que a rede entregou a tentativa ou que o destino aceitou. A contabilidade posterior, quando existia, tinha ainda outro tempo e outro identificador.

Os algoritmos e dados de aceitação ou recusa pertenciam ao operador do daemon. Essa autonomia deixava cada local usar seus registros e política. Consequentemente, a resposta representava uma decisão local, não uma norma global embutida no formato do pacote.

O nonce correlacionava uma resposta pequena

Na codificação UDP histórica, o serviço usava a porta 49. A solicitação levava um nonce, repetido na resposta. O cliente podia associar o datagrama recebido a uma pergunta pendente. O nonce não autenticava usuário nem servidor, não garantia integridade e não ocultava os campos.

Depois de um timeout, o cliente podia tentar novamente; o servidor não fazia o mesmo. RFC 1492 observa que a arquitetura implicava solicitações idempotentes, mas que elas não eram de fato idempotentes. Essa frase impede que uma ferramenta de análise descarte uma duplicata sem verificar o estado da conexão maior. Nonce, timestamps, motivo do retry, resposta e ação precisam permanecer juntos.

A senha em claro atravessava a rede antes do resultado

Tanto UDP quanto TCP carregavam nome de usuário e senha em texto claro. A discussão de segurança alertou que um monitor podia coletar pares de credenciais e que o serviço abria uma superfície para testar usuários e senhas. Um ACCEPT posterior não dá confidencialidade retroativa à solicitação.

A codificação TCP trocou outra propriedade. Era explicitamente incompatível com o TACACS histórico, adotava enquadramento mais simples, deixava a entrega para TCP e podia carregar respostas maiores. Entregar bytes em ordem não autentica as pontas, não cifra a senha e não demonstra aplicação da decisão.

TACACS+ não volta no tempo

RFC 8907 posteriormente descreveu TACACS+ como uma suíte que separa autenticação, autorização e contabilidade. Também advertiu que uma sessão de protocolo pode não corresponder a um usuário ou ato de usuário e que solicitações de autenticação não se associam automaticamente às de autorização. A comparação reforça a separação de recibos, mas não autoriza atribuir semântica moderna ao TACACS de 1993.

RFC 927, anterior, tratava da entrega de identificação TUID no TELNET. RFC 1492 pertence a outro recorte: como documentar um protocolo de decisão quando o texto-fonte não está disponível e uma implementação de fornecedor ocupa o lugar de testemunha principal.

O documento não elimina a incerteza. Ele a torna auditável. Origem do texto, comportamento do programa, publicação, transporte, decisão, execução e resultado continuam sendo fatos relacionados, nunca intercambiáveis.

Fontes