Resumo

  • O Identifier de um octeto só selecionava um pedido pendente. O cliente ainda validava o Response Authenticator com o Request Authenticator de 16 octetos daquele pedido e o segredo compartilhado do salto.
  • Uma retransmissão inalterada ao mesmo servidor preservava Identifier, Request Authenticator e porta de origem. O servidor reconhecia a duplicata e reenviava a resposta em cache; alterar qualquer atributo iniciava um pedido novo.

Um número pequeno com validade curta

O cabeçalho RADIUS começa com Code, Identifier de oito bits, Length, Authenticator de 16 octetos e Attributes. Duzentos e cinquenta e seis valores parecem incompatíveis com muitos acessos simultâneos, perdas UDP, servidores alternativos e conversas de desafio com várias rodadas.

O protocolo nunca resolveu isso chamando o Identifier de número global. O primeiro RFC do RADIUS, o RFC 2058, surgiu em janeiro de 1997. O RFC 2138 o substituiu em abril, e o RFC 2865, de 2000, consolidou a forma clássica. Em todos, o octeto ajuda a casar pedidos e respostas; não é um registro permanente.

O cliente mantém cada valor exclusivo entre pedidos ainda pendentes para um endereço e uma porta de origem. RFC 5080 recomenda escolher pelo menos recentemente usado e só reciclar depois de resposta válida ou timeout.

Assim, Identifier 82 não identifica uma pessoa nem uma sessão para sempre. Ele nomeia o uso atual de 82 dentro de um contexto operacional. O nome ganha sentido da janela em que está vivo.

A resposta carregava uma dependência da pergunta

No Access-Request, o campo longo é o Request Authenticator. Ele muda quando um Identifier novo é usado e deve ser imprevisível e único ao longo da vida do segredo compartilhado. Repetir o valor com o mesmo segredo pode permitir o reaproveitamento de uma resposta capturada; prever um valor futuro pode ajudar a preparar uma falsificação antecipada.

Access-Accept, Access-Reject e Access-Challenge copiam o Identifier. O Response Authenticator, porém, é calculado sobre Code, Identifier, Length, o Request Authenticator original, os Attributes da resposta e o segredo.

Ao receber o pacote, o cliente localiza um pedido candidato pelo octeto e testa a resposta contra os 16 octetos daquele pedido exato. Uma resposta atrasada para um uso anterior do mesmo número não passa na validação atual.

O desenho é composto: o número reduz a busca; o valor imprevisível amarra a resposta à pergunta; o segredo autentica o vizinho; a tabela de pendências limita o tempo. Nenhum desses elementos, sozinho, prova toda a transação.

A retransmissão tinha que conservar sua identidade

O RADIUS clássico usou UDP porque uma decisão de acesso precisa chegar em segundos. Uma entrega confiável minutos depois já não ajuda o usuário. O cliente guarda a requisição acima do transporte, controla timeout e pode retransmitir ou consultar outro servidor.

Ao reenviar Attributes idênticos para o mesmo servidor, deve conservar Request Authenticator, Identifier e porta de origem. O segundo datagrama é outra tentativa de entregar o mesmo pedido, não outra tentativa de autenticação.

Se algum Attribute mudar, Request Authenticator e Identifier também mudam. Acrescentar Event-Timestamp, trocar a resposta do usuário ou pedir outro serviço cria uma pergunta nova. A semelhança do nome de usuário não substitui a igualdade dos bytes relevantes.

Essa regra protege tanto o servidor quanto o histórico: ela permite dizer com precisão se dois pacotes representam um ato lógico ou dois.

O cache mantinha um único efeito

RFC 5080 exige detecção de Access-Request duplicado e cache temporário de Access-Accept, Access-Reject ou Access-Challenge. Se a duplicata chega após a resposta, o servidor reenvia a resposta original sem processar o pedido outra vez. Se chega enquanto o primeiro pedido ainda está em execução, é descartada silenciosamente.

Reexecutar pode alterar estado. Pode contar dois acessos, consumir novamente um valor, escrever duas linhas de auditoria ou repetir uma consulta cara. A repetição da resposta corrige provável perda de rede sem multiplicar essas consequências.

A chave do cache inclui endereço e porta de origem, socket receptor, Identifier e Request Authenticator. A entrada costuma durar de cinco a trinta segundos. Um pacote igual nos quatro primeiros elementos, mas com Request Authenticator diferente, invalida a entrada antiga. O octeto visível não tem poder para apagar a diferença.

O cache não transforma a decisão em autorização eterna. Ele existe pelo intervalo curto em que o cliente ainda pode estar buscando a mesma resposta.

Mudar o conteúdo tornava a resposta anterior obsoleta

Um servidor pode continuar processando o primeiro pedido quando o cliente envia um segundo com Attributes alterados. A resposta antiga pode ser perfeitamente válida para o Request Authenticator anterior. Mesmo assim, ela não responde mais ao pedido atual.

O cliente processa a primeira resposta válida para um pedido que ainda está pendente. Depois disso, respostas tardias são não solicitadas e devem ser descartadas. Autenticidade histórica não restaura a atualidade perdida.

O Access-Challenge torna a diferença visível. O servidor pode devolver State e pedir outra informação. O NAS envia novo Access-Request, com Identifier e Request Authenticator novos, carregando State e a nova resposta. State une as rodadas da conversa; não faz todas as rodadas serem uma só transação.

Se servidores alternativos têm políticas ou bases divergentes, podem discordar. A regra da primeira resposta válida organiza o cliente, mas não sincroniza a operação. Consistência continua sendo responsabilidade de quem administra o serviço.

Um Accept não criava capacidade local

RFC 2865 determina que o NAS trate como rejeição um Access-Accept cujo serviço não consiga oferecer. A resposta não cria uma VLAN inexistente, um protocolo não suportado ou uma rota impossível.

O Response Authenticator clássico prova, dentro de suas limitações, que o par com o segredo respondeu ao pedido pendente e que os campos cobertos correspondem. Não prova que a política foi correta, que o usuário é quem diz ser sem considerar o método transportado, nem que pacotes do serviço realmente circularam.

A execução permanece uma decisão e uma evidência locais. O servidor pode autorizar; só o equipamento de acesso conhece sua capacidade presente.

O proxy encerrava uma prova e emitia outra

Em uma cadeia, o proxy valida a resposta do servidor remoto com o segredo daquele salto, remove seu último Proxy-State, restaura o Identifier esperado pelo cliente anterior e calcula novo Response Authenticator com o segredo do salto de volta.

O NAS não recebe uma assinatura fim a fim do home server. Recebe uma afirmação do par RADIUS direto. Proxy-State ajuda o pacote a percorrer o retorno e deve ser opaco para quem não o criou; não concede acesso.

Por isso, registrar apenas “ID 82, Accept” quase não preserva evidência. É preciso saber o salto, endereço e porta, socket, tempo pendente, impressão protegida do Request Authenticator, forma do pedido, ação de cache, caminho de proxy e efeito aplicado. Segredos e credenciais não devem ser expostos para construir essa trilha.

Reintentos iguais podiam derrubar o serviço juntos

RFC 5080 descreve clientes que retransmitiam a cada segundo ou menos, sem backoff. Depois de uma queda de energia, milhares de NAS poderiam reiniciar em fase e repetir em fase, sobrecarregando o servidor na recuperação.

O algoritmo recomendado aumenta o prazo, introduz jitter e limita intervalo, quantidade e duração. O jitter quebra sincronização e não precisa ser criptograficamente forte. A imprevisibilidade do Request Authenticator serve contra ataques e precisa de qualidade apropriada. Os dois não devem compartilhar um gerador fraco só porque ambos usam aleatoriedade.

Em sobrecarga, o servidor pode priorizar pedidos com State válido para concluir conversas iniciadas. O proxy pode encaminhar respostas antes de aceitar mais requisições novas. Isso reduz trabalho abandonado; não declara um usuário mais merecedor.

TLS moveu o limite anos depois

O RFC 6614, de 2012, colocou RADIUS em TLS/TCP, mas manteve a mecânica MD5 do pacote clássico e o segredo fixo radsec dentro do túnel. A conexão ganhou proteção sem eliminar o processamento antigo.

O RFC 9765, de 2025, define RADIUS/1.1 para um salto que negocia explicitamente o perfil por ALPN em TLS 1.3 ou posterior. Nesse caso, saem o segredo RADIUS e as operações MD5; os 16 octetos viram um Token opaco e assumem também o papel de correlação do Identifier.

Essa é a fronteira com a matéria já publicada sobre RADIUS/1.1. O perfil não muda RADIUS/UDP nem atualiza todos os proxies por consequência. Ele apenas mostra que, mesmo quando o transporte assume autenticidade e confidencialidade, a conexão ainda precisa identificar qual resposta pertence a qual pedido.

História não é recomendação criptográfica

O Response Authenticator clássico não torna MD5 adequado para novos projetos. Não certifica a correção da autorização, a gravação contábil, a integridade de todos os proxies ou a entrega de serviço. Os RFCs estabelecem semântica e evolução, não conformidade de produto nem presença atual.

A lição durável está no uso de nomes curtos. Eles funcionam quando escopo, tempo e contexto composto permanecem juntos. Tornam-se enganosos quando a organização guarda os oito bits em um relatório e perde tudo que permitia interpretá-los.