Resumo

  • Um atributo opaco não era necessariamente um identificador permanente de usuário. State, Class e Proxy-State tinham responsáveis, usos e durações diferentes.
  • Cada proxy podia acrescentar um Proxy-State próprio e retirá-lo na resposta, preservando os valores anteriores. Também podia guardar os valores recebidos localmente, desde que os restituísse ao cliente.
  • Conservar bytes não provava que todos os intermediários haviam tomado a mesma decisão. Contabilização, política de acesso e proteção de cada conexão exigiam evidências próprias.

A marca que podia seguir adiante

Uma resposta que autoriza acesso podia trazer Class. Quando havia contabilização, a especificação básica de RADIUS recomendava levar esse valor, sem alterações, para a solicitação contábil. No mesmo caminho de resposta, um Proxy-State tinha destino diferente: o proxy que o havia acrescentado deveria retirar o seu antes de devolver a mensagem ao cliente anterior.

Os dois valores podiam parecer igualmente misteriosos para quem os transportava. Isso não os tornava a mesma informação. Um podia ajudar a relacionar o acesso com registros posteriores; o outro resolvia uma necessidade do intermediário na viagem de volta. A opacidade descrevia como o conteúdo seria tratado por terceiros, não por quanto tempo deveria existir.

O RFC 2865, de junho de 2000, permite reconstruir essa distinção. Não é preciso supor um único grande banco de sessões compartilhado por toda a cadeia. Cada valor tinha uma relação com quem o produzira e com a etapa em que voltaria a ser necessário.

É nesse detalhe que a história se afasta de uma descrição genérica de autenticação. Um sistema podia cooperar na circulação de dados privados sem adotar um significado universal para todos eles. O acordo comum precisava definir cuidadosamente os movimentos, não tomar para si toda a memória dos participantes.

O cliente não era a pessoa diante da tela

No cenário clássico, o cliente RADIUS era o servidor de acesso à rede. Era ele que enviava uma requisição de autenticação a um servidor. Se o servidor recebesse uma solicitação destinada a outro domínio de autenticação, poderia encaminhá-la conforme sua configuração.

O intermediário passava então a exercer duas funções. Para o equipamento de acesso, era servidor; para o próximo servidor, era cliente. Uma mesma máquina podia responder diretamente por alguns domínios e encaminhar pedidos de outros. Também era possível encadear proxies, com o cuidado explícito de não criar ciclos. Proxy-State não calculava a rota nem transformava automaticamente esse encadeamento em um caminho sem loops.

O documento informativo RFC 2607, de junho de 1999, analisou essa arquitetura para roaming. Ela permitia que o ponto de conexão estivesse em uma organização e a decisão de autenticação dependesse de outra. O texto discutiu redução das relações de chaves, adaptação de capacidades, aplicação de políticas e tratamento dos registros de uso.

Também registrou uma advertência que não deve desaparecer da narrativa: as hipóteses de segurança daquela solução não a tornavam adequada a uma implantação ampla na Internet. A confiança interna de um domínio administrativo não era transferida automaticamente para um conjunto de organizações independentes. A descrição de uso em 1999 não é uma medição de adoção atual, muito menos um certificado de segurança.

Uma numeração comum, três ciclos de vida

No registro de atributos RADIUS da IANA, State, Class e Proxy-State aparecem como 24, 25 e 33. A numeração comum permite reconhecer o tipo de dado. Não revela a representação interna escolhida por cada aplicação nem atesta o resultado de uma transação.

State pode acompanhar um Access-Challenge e retornar no Access-Request seguinte. O servidor consegue, assim, manter o vínculo com uma conversa de autenticação que ainda não terminou. Já Class pode sair em Access-Accept e continuar na contabilização. No cenário de roaming discutido em 1999, sua preservação ajudava a conciliar registros entre participantes.

Uma conversa de autenticação não dura para sempre apenas porque o usuário e a porta continuam iguais. O RFC 5080, de dezembro de 2007, esclarece que uma autenticação nova ou reiniciada não deve levar o State da conversa anterior. O identificador aparente da pessoa ou do ponto de acesso não substitui a delimitação do processo.

Proxy-State tinha outra tarefa. O intermediário podia acrescentar uma informação para recuperar ao receber a resposta de seu próprio encaminhamento. O conteúdo era específico da implementação. O resto da cadeia precisava respeitar sua devolução, sem assumir que aquele conteúdo era uma instrução destinada a todos.

Acrescentar, preservar, retirar

Proxy-State já estava presente no RFC 2138, de abril de 1997. A revisão de 2000 detalhou as regras para o encaminhamento. Cada proxy podia acrescentar um valor próprio, mas não mais de um, depois dos Proxy-State já existentes. Não podia modificar os anteriores nem mudar a ordem entre atributos do mesmo tipo.

O servidor final copiava os Proxy-State recebidos para a resposta, sem alteração e na mesma ordem. Isso valia para Access-Accept, Access-Reject e Access-Challenge. A devolução da informação não dependia de o acesso ser autorizado. Uma recusa também precisava voltar de forma que os intermediários conseguissem concluir o trabalho que haviam iniciado.

Quando recebia a resposta, o proxy que havia acrescentado um valor retirava o último Proxy-State: o seu. Os valores anteriores continuavam para os intermediários anteriores. Quem não havia acrescentado um não ganhava, por isso, o direito de remover o de outra pessoa.

O último Proxy-State não precisava ser o último atributo do pacote inteiro. A ordem relevante era a das ocorrências do mesmo tipo. A especificação não exigia ordem fixa entre tipos diferentes nem que ocorrências iguais fossem contíguas. Havia espaço para outro atributo entre dois Proxy-State ou depois deles. Confundir ordem relativa com posição absoluta criaria uma restrição que os participantes nunca haviam combinado.

Preservar sem transportar até o fim

O proxy também podia omitir do pedido encaminhado os Proxy-State que já havia recebido. Nesse caso, tinha de acrescentá-los novamente à resposta antes de enviá-la a seu cliente. A decisão de manter uma informação localmente era permitida; a decisão de esquecê-la, não.

Essa possibilidade muda o valor de uma observação de tráfego. Um estado ausente na conexão seguinte não está necessariamente perdido. Um estado que reaparece na resposta não esteve necessariamente no servidor final. Proxy-State não é um relatório completo dos lugares por onde passou o pacote.

O compromisso estava na fronteira entre o proxy e quem lhe entregara a informação. Internamente, o proxy podia escolher entre carregá-la adiante ou assumir sua guarda e restituição. A especificação deixava a organização desse armazenamento em aberto, mas não deixava em aberto a obrigação de devolver.

O retorno também exigia trabalho criptográfico

Na sequência original descrita pelo RFC 2865, o intermediário verificava a resposta usando o segredo compartilhado com o servidor remoto. Uma resposta que não passasse na verificação era descartada. Depois de tratar seu Proxy-State, o proxy restaurava o Identifier correspondente à requisição anterior e calculava o autenticador para o cliente a quem responderia.

Isso é diferente de receber um único envelope autenticado que permaneceu intacto de uma ponta à outra. A relação de confiança se renovava entre vizinhos. A verificação feita pelo último cliente, sozinha, não demonstrava que todas as decisões anteriores tinham sido preservadas.

Além disso, o proxy não era necessariamente neutro em relação ao serviço. Podia modificar alguns atributos para aplicar políticas locais, mas não os Proxy-State, State e Class já presentes. O protocolo distinguia a área de decisão do intermediário da área em que ele devia preservar informações alheias. Não dizia que o pacote inteiro era imutável, nem que toda modificação equivalia a uma ação maliciosa.

O RFC 2607 discutia separadamente o risco de um proxy malicioso contrariar decisões esperadas. Uma regra que proíbe determinada alteração não a torna fisicamente impossível. Capacidade técnica, comportamento permitido e autoridade sobre outras organizações não são a mesma coisa.

Confirmar uma conta não era apenas receber um pacote

O documento informativo RFC 2866, também de junho de 2000, exige receber e registrar a solicitação antes de enviar Accounting-Response. Se o registro não puder ser feito, a confirmação não deve ser emitida segundo essa regra. Portanto, a resposta tem um compromisso mais forte que a simples chegada de bytes à rede.

Ainda assim, o alcance desse compromisso depende da cadeia. Um intermediário pode esperar uma confirmação remota antes de responder, ou assumir responsabilidade local de guardar e encaminhar. O RFC 2607 examina essas diferenças. Uma confirmação emitida sob responsabilidade local não prova que todos os demais participantes já registraram o mesmo evento.

Essa distinção evita atribuir a um campo privado ou a uma resposta curta o papel de um acordo contábil global. A conciliação exige saber de quem é o registro, em que etapa houve confirmação e que obrigação de transmissão ainda permanece aberta.

Opaco não significava secreto

Proxy-State carrega octetos, não um texto que o intermediário deva embelezar. A extensão do valor vem do campo de comprimento. Um zero no meio não é um convite para truncar o dado; espaços e letras não podem ser normalizados como se fossem uma legenda destinada ao leitor.

Ao mesmo tempo, tratar um valor como opaco não equivale a criptografá-lo. Um proxy pode ter acesso físico ao conteúdo que, pelas regras, não deve interpretar como comando próprio. A independência semântica entre implementações não produz confidencialidade por conta própria.

As proteções evoluíram por outro caminho. O RFC 6614, experimental, tratou do transporte RADIUS sobre TLS em maio de 2012, mantendo o papel dos proxies no processamento das mensagens. O RFC 9765, experimental e publicado em abril de 2025, definiu RADIUS/1.1 para TLS e DTLS e retirou, naquele perfil, mecanismos antigos de pacote baseados em MD5 e segredos compartilhados.

Essa história não recomenda hoje os mecanismos antigos e não demonstra adoção universal dos novos. As conexões de cada lado de um proxy podem ser negociadas separadamente. Proteger uma delas não descreve automaticamente a proteção da seguinte, nem transforma o intermediário em testemunha de toda a política aplicada antes dele.

O que Proxy-State compartilhava era mais restrito: uma forma de devolver trabalho privado a quem precisava terminá-lo. Respeitar essa restrição fazia parte de sua utilidade. A informação que voltava ao proxy não precisava se tornar a informação que ficava na conta, nem o documento que autorizava toda a cadeia.