Resumo

  • Cada consulta do Ident apontava para uma conexão específica: os números indicavam as portas do servidor e do cliente conforme o host consultado as enxergava, e o próprio host devolvia a identificação local daquele socket.
  • O RFC 931 sugeriu um uso experimental no login automático do FTP. Em 1993, o RFC 1413 chamou o serviço de Protocolo de Identificação e deixou claro que a resposta podia auxiliar uma auditoria, mas não autenticar nem autorizar.

Dois números, a perspectiva de um host

O exemplo mais esclarecedor do RFC 1413 parece um erro de digitação. Em uma ponta, a conexão aparece como 23, 6191; para perguntar à outra ponta sobre a mesma conexão, é preciso enviar 6191, 23. A conexão não mudou. Mudou quem considera cada porta “local” e “remota”.

Essa inversão era a chave operacional do protocolo. Um cliente Ident se conectava à porta TCP 113 de um host e enviava uma linha com <porta-no-servidor>, <porta-no-cliente>. Os endereços IP vinham da própria conexão TCP com o serviço Ident. Somados às duas portas, eles especificavam uma conexão TCP que já existia. O servidor então podia devolver o identificador, dependente do sistema, que sua própria máquina associava àquela sessão.

O escopo da pergunta era deliberadamente estreito. Não se pedia a um serviço central que localizasse uma pessoa pela Internet. Pedia-se a um host que relatasse qual string de usuário o sistema local associava a um socket específico. A resposta USERID trazia um campo de sistema operacional e uma identificação; ERROR podia indicar que não havia proprietário identificável. O RFC 1413 também definiu HIDDEN-USER para a situação em que o servidor conhecia o usuário, mas ocultava a informação a pedido dele.

Isso era diferente da consulta ao serviço anterior Name/Finger. Uma linha Finger vazia podia pedir a um host uma lista das pessoas conectadas naquele momento; o Ident selecionava uma conexão TCP pela dupla de portas. Lista de presença e string do dono de um socket respondem a perguntas operacionais distintas. O artigo anterior sobre Name/Finger cobre essa fronteira de presença no host.

“Authentication Server” era uma proposta para aplicações

A história começa com o RFC 912, de Mike St. Johns, publicado em setembro de 1984 com o título “Authentication Service”. Ele propôs um serviço TCP na porta 113 para devolver o identificador associado ao dono de uma conexão TCP específica. Entre os usos cogitados estavam a autenticação automática de usuários no FTP e a verificação de operações privilegiadas. O texto também alertava que a confiança nos hosts variava e atribuía a cada aplicação a decisão sobre quanto confiar no retorno.

O RFC 931, publicado em janeiro de 1985, substituiu a proposta. Ele formalizou uma resposta com o nome do sistema operacional e o identificador do usuário. Para o FTP, descreveu uma possibilidade: o cliente enviaria um comando USER sem argumento, e o servidor poderia recorrer ao serviço. O documento chamou isso expressamente de uso experimental e repetiu o alerta sobre a confiança no host. Ele registra uma integração sugerida, não prova que servidores FTP a tenham adotado amplamente.

A distinção entre a resposta do protocolo e a decisão da aplicação é central. O Authentication Server não verificava uma senha por conta própria nem provava quem estava diante de um terminal. Devolvia o identificador que o host associava localmente àquela conexão. Um servidor FTP podia optar por usar a string, mas a escolha e as consequências cabiam à aplicação e à relação de confiança com o outro host.

Em 1993, o nome explicitou o limite

Publicado em fevereiro de 1993, o RFC 1413 tornou o RFC 931 obsoleto e renomeou o antigo Authentication Server Protocol como Identification Protocol, ou Ident, “para refletir melhor sua função”. Manteve a porta TCP 113 e o par específico de cada conexão. Também detalhou como uma conexão Ident podia receber várias consultas e como interpretar respostas como HIDDEN-USER.

As considerações de segurança não deixam margem para uma leitura mais forte. As informações devolvidas eram, no máximo, tão confiáveis quanto o host ou a organização que o operava. O protocolo não se destinava a autenticação ou controle de acesso; no melhor cenário, acrescentava informação de auditoria sobre conexões TCP. O RFC desaconselhava fortemente outros usos e alertava para a exposição de informações normalmente consideradas privadas.

Esse limite vinha do caminho dos dados. O servidor produzia o identificador a partir da perspectiva do próprio sistema operacional. Um host comprometido podia retornar informações enganosas; em um computador aberto de laboratório, um usuário talvez pudesse escolher o identificador apresentado. Uma linha USERID sintaticamente correta não transformava a afirmação do servidor em um fato verificado de forma independente. O cliente recebia o relato do host consultado, não uma prova de que uma pessoa havia sido autenticada em outro lugar.

A mudança de nome, portanto, marca uma fronteira histórica útil, mas não comprova que todo uso anterior tenha cessado. O RFC 1413 chama o serviço de identificação, não de autenticação, e restringe o que se deve concluir a partir da resposta. Os RFCs não informam quantos sites executavam o Ident, quantas vezes um usuário pedia para ocultar sua identificação nem quais softwares FTP dependiam dele. Uma especificação registra um contrato de protocolo, não um levantamento de adoção.

O que o par de portas pode sustentar

Em uma trilha de auditoria, a identificação fornecida por um host pode ser um contexto útil se o registro mantiver juntos o host, o sentido do tráfego, as portas, o horário e a resposta. Ela pode ajudar a descobrir qual conta local a outra ponta associava a um socket. Não comprova que a pessoa citada iniciou o tráfego, controlava a máquina remota ou tinha direito de entrar na aplicação.

A história do protocolo depende dessa separação. O RFC 931 descreveu uma forma possível de uma aplicação usar uma string de usuário remota. O RFC 1413 nomeou o serviço segundo a identificação que realmente devolvia e alertou contra tratar o relato como autoridade. Um par de portas permitia que o host tornasse legível uma conexão específica. A decisão de confiar continuava com o sistema que escolhia o que fazer com a resposta.

Fontes