Resumo

  • O host que recebia uma conexão abria outra, no sentido inverso, até a porta TCP 113. O par de portas da primeira conversa, ordenado pela perspectiva do host consultado, delimitava a busca em seu estado local.
  • A promessa diminuiu no nome: Authentication Service em 1984, Authentication Server Protocol em 1985 e Identification Protocol em 1993. A mudança reconheceu o que a troca realmente podia sustentar.
  • RFC 1413 proibiu usar USERID como identificador de controle de acesso. HIDDEN-USER, NO-USER e UNKNOWN-ERROR reforçavam que a resposta era uma declaração remota, sujeita a privacidade, falha e mentira.

O direito de não dizer

O erro HIDDEN-USER é uma boa porta de entrada para a história. Ele não quer dizer que o serviço desconhece a resposta. Quer dizer que a política local não autoriza revelá-la. Antes de discutir precisão, o protocolo já precisava admitir que um nome de conta atravessando a rede era uma divulgação.

Essa escolha faz sentido quando se observa a mecânica. A inicia uma conexão do porto local 6191 para o porto 23 de B. B decide perguntar qual usuário de A possui aquela conexão. Para isso, B abre uma nova conexão até o TCP 113 de A e envia 6191, 23.

O primeiro número é local para quem responde, A; o segundo é remoto. B via os papéis invertidos na conexão original. Se enviar 23, 6191, consulta outro estado. RFC 1413 obtém as duas endereços IP da própria conexão de consulta. Endereços e portas, em conjunto, restringem a pergunta a uma conexão TCP entre os mesmos hosts.

O serviço não percorre um diretório mundial nem prova uma pessoa. Ele pede ao sistema operacional de A que consulte sua relação local entre conexão e usuário. Se encontrar, a resposta USERID repete o par, apresenta um tipo de sistema operacional e uma cadeia. Um parâmetro de conjunto de caracteres pode orientar a leitura.

O valor OTHER permite um token opaco em vez de um nome convencional. Isso impede que o receptor suponha automaticamente uma conta Unix, uma identidade global ou um vínculo empregatício estável. A informação pertence ao espaço de nomes do host que respondeu.

A autenticação estava no título antes de estar na prova

RFC 912, de setembro de 1984, chamava a ideia de Authentication Service e reservava a porta 113. Imaginava que FTP pudesse comparar o usuário informado na aplicação com o usuário ao qual o host remoto atribuía a conexão. Considerava inclusive operações privilegiadas.

O próprio texto dependia da confiança no outro computador: seus administradores, seu sistema de contas e sua capacidade de impedir manipulação local. Um host comprometido poderia devolver o nome que levasse ao resultado desejado.

Em janeiro de 1985, RFC 931 formalizou o Authentication Server Protocol. Definiu a consulta por par de portas, respostas USERID e ERROR e o campo OPSYS. Também explorou mapeamentos locais de acesso.

O salto conceitual era sedutor. Se A sabe qual usuário abriu a conexão, B talvez não precise autenticá-lo de novo. Mas o conhecimento local de A não se converte em credencial de B. A troca não prova quem está no teclado, não protege criptograficamente a resposta e não estabelece que o mesmo nome significa o mesmo sujeito nos dois domínios.

A correção de 1993

Em fevereiro de 1993, o grupo de trabalho IDENT do IETF publicou RFC 1413, substituindo RFC 931. O título mudou para Identification Protocol, segundo o documento, para refletir melhor a função.

A seção de segurança fixou a fronteira: a resposta é, no máximo, útil para auditoria e não deve ser usada como identificador de controle de acesso. Se B conceder acesso porque A respondeu alice, A passa a ter poder de fabricar alice. A conexão de retorno não criou uma fonte de confiança independente.

Identificação, aqui, significa a associação que A declara entre um fluxo e um identificador local. Não significa autenticação humana, equivalência de contas entre organizações nem autorização para uma operação.

Dentro dessa limitação, a informação pode ajudar. B guarda nome, hora, endereços, portas e evento de aplicação. O administrador de A compara depois com sessões, processos e logs locais. A cadeia encurta a busca entre operadores, mas continua precisando de confirmação.

A ordem e o tempo preservam o contexto

Portas efêmeras são reutilizadas. Um par sem horário pode apontar para uma conexão posterior. Uma trilha verificável precisa das duas endereços, das duas portas, da direção e do momento da conexão original, além da consulta e resposta IDENT.

Derivar endereços da conexão de consulta reduz ambiguidade, mas não produz vínculo criptográfico. O conteúdo continua sob controle do host remoto. Uma sintaxe correta mostra que a pergunta se referiu ao fluxo pretendido; não mostra que a resposta foi honesta.

O identificador recomendado deveria permitir que o administrador do host consultado encontrasse o evento, sem revelar gratuitamente comando, processo ou outros detalhes. O objetivo era correlação, não inspeção aberta do sistema estrangeiro.

Falha, ausência e privacidade não são a mesma coisa

INVALID-PORT cobre formato ou intervalo inválido. NO-USER informa que o serviço não consegue identificar usuário para a conexão. HIDDEN-USER registra uma decisão de não divulgar. UNKNOWN-ERROR evita expor causa interna; fechamento prematuro deve ser tratado da mesma forma.

NO-USER não prova anonimato. HIDDEN-USER não sugere culpa. UNKNOWN-ERROR não prova inexistência do mapeamento. Cada resultado delimita o que o sistema consegue ou aceita afirmar naquele instante.

RFC 1413 compara o problema de privacidade a CallerID e Finger. Um nome corriqueiro dentro do host vira nova exposição quando todo servidor que recebe uma conexão pode consultá-lo. Desligar o serviço, esconder usuários ou retornar tokens são escolhas locais legítimas, embora alterem o valor de auditoria.

Estruturar o dado não o torna verdadeiro

RFC 1414 definiu uma MIB indexada por endereço local, porta local, endereço remoto e porta remota. A geometria de quatro elementos migrou para uma tabela de gestão, acompanhada de identificador e estado.

RFC 1414 hoje é Historic; RFC 1413 aparece como Proposed Standard. Esses rótulos não medem implantação atual. A MIB repete que o resultado não é autoritativo nem apropriado para acesso. Uma coluna torna a declaração consultável, não comprovada.

O atual registro da IANA de nomes de serviço e portas mantém ident e o antigo auth em TCP 113. Ele coordena onde fazer a pergunta e preserva a mudança histórica. Não certifica conta, sistema operacional, política ou resposta.

Uma pista útil porque sua autoridade foi recusada

O IDENT separa duas decisões. Atribuição pergunta qual usuário A associa ao fluxo. Autorização pergunta o que B permite com as provas aceitas por B. Um texto idêntico não unifica as autoridades.

A consulta era estreita: dois hosts, duas portas, um instante. Os erros admitiam ignorância; HIDDEN-USER admitia reserva; a segurança admitia engano. Nesse perímetro, USERID enriquece a cronologia. Fora dele, o host remoto passa a cunhar a palavra que abre a porta.

A passagem de Authentication para Identification não abandonou uma função comprovada. Removeu do nome um poder que o protocolo nunca conseguiu demonstrar.

Fontes e limites da evidência

As fontes estabelecem versões do protocolo, a MIB e o registro de serviço. Não medem uso atual, exatidão, práticas de privacidade ou ataques. Não se inferem comportamentos de NAT, proxy ou contêiner que o conjunto fechado não documenta.