Resumo

  • A RFC 927 propôs TUID, a opção 26 do Telnet, para que um lado que já autenticara um usuário pudesse apresentar a um destino consentinte um identificador binário de 32 bits.
  • WILL TUID e DO TUID tinham de estabelecer o acordo antes da subnegociação; WON'T e DON'T mantinham a recusa como comportamento normal.
  • O número de quatro octetos era uma afirmação da origem, não prova da senha, autorização na máquina de destino, proteção criptográfica ou confirmação de uma ação.

Em dezembro de 1984, Brian A. Anderson, da BBN, publicou a RFC 927, TACACS User Identification Telnet Option. A proposta mirava um incômodo muito simples: alguém já havia dado nome e senha corretos a um Terminal Access Controller, o TAC. Se esse controlador abrisse uma conexão Telnet para outro host em nome dessa pessoa, seria necessário pedir o mesmo segredo de novo?

A RFC não mandava a senha adiante. Ela definia TUID, código 26. O Telnet do lado usuário podia declarar que autenticaria o usuário e enviaria seu UUID; o Telnet servidor podia declarar que aceitaria essa autenticação. Depois do acordo, uma subnegociação carregava um número binário de 32 bits. Eram quatro octetos, e não o UUID de 128 bits que a expressão passou a sugerir muito depois.

O ponto histórico não está no tamanho do campo. A origem podia falar sobre sua própria verificação; o destino ainda escolhia se confiava nela. A conveniência de uma tela de login a menos trocava repetição por uma relação explícita de confiança entre operadores. Não convertia a origem em mandatária do destino.

A verificação anterior virou uma declaração

Na motivação da RFC, o usuário apresentava um par nome/senha correto ao TAC antes de ser conectado a um host. O TAC tinha então um fato local: seu processo aceitara um usuário associado a certo número. TUID permitia que esse fato fosse oferecido à próxima máquina.

O host alvo não recebia a senha para testar de novo. Recebia uma declaração: a máquina que iniciou a conexão havia autenticado a pessoa em cujo nome ela existia e chamava essa pessoa por este identificador. Para dispensar a segunda pergunta, o alvo precisava avaliar o procedimento, a administração e a palavra da origem.

RFC 927 preserva a fronteira de forma direta: hosts podiam aceitar a autenticação do TAC ou não, a seu critério. A origem controlava o processo que alegava ter executado. O destino continuava responsável pelos recursos que oferecia. A declaração não podia obrigar a consequência.

O consenso vinha antes do valor

RFC 854 já dava ao Telnet uma gramática para funções opcionais: WILL, WON'T, DO e DON'T expressavam oferta, pedido, aceitação e recusa além do terminal virtual básico. RFC 855 acrescentava a regra de que parâmetros de subnegociação só deveriam circular depois de ambas as partes aceitarem entender a opção.

Em TUID, IAC WILL TUID colocava o lado usuário no papel de autenticar e enviar o identificador. IAC DO TUID colocava o lado servidor no papel de pedir ou aceitar essa autenticação. WON'T recusava o primeiro papel e DON'T o segundo. Só depois de WILL e DO compatíveis vinha IAC SB TUID <uuid> IAC SE.

As recusas eram tão importantes quanto a via de sucesso. Uma implementação que não conhecesse TUID respondia com a negativa apropriada e permanecia no Telnet normal. A ausência de suporte não virava confiança silenciosa, nem uma regra central obrigava todos os hosts a aceitar o mesmo emissor.

Quatro octetos não se autenticavam sozinhos

O UUID da RFC é apenas um número binário de 32 bits. Os exemplos usam 1, 255 e todos os bits em um. Não há na especificação uma autoridade mundial de números, prazo de validade, prevenção de colisão, prova de posse, assinatura, nonce, horário ou defesa contra repetição.

O octeto 255 é IAC no Telnet. Quando ele aparece como dado, precisa ser duplicado, para não ser lido como comando. Isso conserva a transparência de bytes; não cifra o campo nem prova sua origem. Um traço de rede pode mostrar que quatro octetos foram apresentados após a negociação. Não mostra quem digitou a senha, se o TAC estava correto, se o número era único, como a conta local foi escolhida, ou se um comando foi concluído.

Identificação aceita não era permissão concedida

Aceitar a autenticação anterior respondia somente se o destino trataria a afirmação como suficiente para representar o usuário naquela conexão. Não respondia quais arquivos seriam lidos, quais comandos seriam aceitos, qual privilégio seria concedido ou se um resultado ocorreu.

RFC 1492, uma reconstrução informativa posterior de TACACS, separa o aceite de login de um pedido CONNECT para endereço e porta; seu autor alerta que não teve a especificação original e que informações posteriores poderiam corrigi-la. RFC 8907 descreve o TACACS+ posterior, que separa autenticação, autorização e contabilidade e não associa automaticamente um pedido de autenticação ao de autorização. São comparações de fronteira, não uma definição retroativa de TUID.

O registro IANA de opções Telnet ainda associa o código 26 a TACACS User Identification e RFC 927. Ele fixa o sentido do código, não mede adoção histórica ou atual.

Menos atrito pede uma cadeia de evidência maior

Para o usuário, o ganho era uma senha a menos. Para o alvo, a obrigação passava a incluir lista de origens confiáveis, espaço de nomes de cada uma, mapeamento para contas locais e retirada de confiança após mudança de política ou comprometimento.

Um log de “login bem-sucedido” esconde a barganha. Ele não distingue senha local, aceite de TUID, mapeamento de conta, autorização de operação e efeito da aplicação. Devem permanecer separados o resultado da autenticação na origem, a sequência WILL/DO, o valor sem escape e seu namespace, a decisão de confiança no destino, a autorização local e a ação observada.

RFC 927 não resolveu identidade universal. Ela mostrou como duas máquinas podiam reduzir uma repetição sem confundir evidência com direito de decidir. Quatro bytes cruzaram a conexão; a responsabilidade por aceitá-los ficou onde o serviço era operado.

Fontes e limites

As fontes são RFC 927, RFC 854, RFC 855, o registro IANA e, apenas como contraste posterior, RFC 1492 e RFC 8907. Elas não demonstram implantação ampla, criptografia, federação moderna de identidade nem o êxito de qualquer sessão real.