Resumo

  • O RADIUS/1.1 usa ALPN e TLS 1.3 ou superior para retirar o segredo compartilhado e as operações MD5 do pacote no salto negociado; RADIUS/UDP e RADIUS/TCP continuam como estavam.
  • Para comprovar a migração, é preciso distinguir suporte, oferta, seleção, obrigatoriedade e desativação do legado em cada conexão cliente-servidor.

Quando a compatibilidade vira dívida

O RFC 9765 conta uma história técnica sem apagar a decisão anterior. Ao colocar RADIUS em TLS e DTLS, o grupo RADEXT manteve o segredo compartilhado e o processamento MD5 do pacote. A intenção era tratar TLS como um invólucro e preservar codificadores, decodificadores e validações já implantados. DeKok escreve que, em retrospecto, essa escolha provavelmente foi errada e observa que participou dela.

O compromisso inicial não era irracional. Ele permitia proteger o transporte sem exigir uma mudança coordenada de todos os clientes e servidores. Mas deixava duas camadas cumprindo funções sobrepostas. TLS protegia a conexão; o RADIUS histórico continuava autenticando pacotes e ocultando atributos com um mecanismo baseado em MD5. Em ambientes que não admitem algoritmos com fragilidades conhecidas, a duplicação passou a bloquear verificação e conformidade.

O perfil de DeKok no IETF registra seu contato com RADIUS em 1997 e a criação do FreeRADIUS em 1999. O projeto mantém um servidor de políticas e componentes usados em integrações reais. Essa experiência aproxima decisões de protocolo das restrições de uma infraestrutura que não pode simplesmente parar de autenticar. Mesmo assim, o RFC 9765 é um documento Experimental de consenso do IETF. A autoria dá contexto; não confere autoridade para declarar a rede inteira migrada.

O pacote deixa de carregar um segundo cofre

No RFC 2865, cliente e servidor compartilham um segredo usado na proteção das transações. O User-Password e outros valores dependem de construções com MD5. Os RFCs 6614 e 7360 adicionaram, respectivamente, TLS e DTLS como transportes, mas o RADIUS/TLS histórico conservou essas operações internas.

O RADIUS/1.1 começa no handshake TLS. Pelo mecanismo ALPN do RFC 7301, o cliente anuncia os nomes de protocolo de aplicação que aceita, e o servidor escolhe um nome comum. A variante nova só vale se radius/1.1 for selecionado, com TLS 1.3 ou posterior.

Nessa conexão, o segredo compartilhado RADIUS não é usado. Os antigos espaços de Request e Response Authenticator passam a formar um Token opaco para correlacionar mensagens. Identifier perde a função anterior. Message-Authenticator não é enviado. Atributos antes ofuscados com MD5 são codificados normalmente dentro da confidencialidade oferecida pelo TLS.

Isso não elimina a confiança; muda seu endereço. A sessão TLS precisa reconhecer o par certo, e a política deve decidir se ele está autorizado. Certificados, chaves, bibliotecas, revogação e telemetria do ALPN tornam-se parte direta da segurança do acesso. Retirar uma camada redundante aumenta a importância de operar corretamente a camada que ficou.

A mesma silhueta, regras incompatíveis

O perfil preserva bastante do RADIUS. O cabeçalho mantém o tamanho; Code e Length mantêm o significado; atributos simples preservam formato e semântica; e as portas de RADIUS/TLS e RADIUS/DTLS continuam em uso. O RFC o apresenta como perfil de transporte, não como substituto integral do protocolo.

Essa continuidade visual exige disciplina. RADIUS/1.0 e 1.1 interpretam de maneira diferente alguns campos e validadores. Se uma ponta aplicar regras antigas numa conexão negociada como nova, ou o contrário, requisições e respostas serão descartadas. O erro tende a falhar fechado, mas ainda produz indisponibilidade, tentativas repetidas e chamados de suporte.

Também não se deve ampliar a alegação sobre MD5. Atributos de CHAP ou MS-CHAP podem seguir como dados opacos. O RADIUS/1.1 remove os mecanismos MD5 de autenticação e ofuscação do pacote naquele salto; não redefine todos os métodos de autenticação transportados nem limpa automaticamente sistemas posteriores.

A fronteira termina no próximo par

Em redes com proxy e roaming, uma solicitação atravessa vários saltos. O controlador pode usar 1.1 com o proxy local, que por sua vez usa RADIUS/TLS histórico, UDP ou outra configuração com o servidor de origem. Só os dois participantes da conexão sabem qual perfil negociaram. Um primeiro salto moderno não produz segurança de ponta a ponta por herança.

Por isso o ALPN é mais do que detalhe de implementação: ele fornece um estado observável. Sem o sinal de radius/1.1, a aplicação não pode presumir o perfil. O RFC recomenda que implementações com as duas variantes permitam inicialmente radius/1.0 e radius/1.1. Depois de verificar as pontas e observar a seleção correta, o operador pode exigir 1.1 e acompanhar a estabilidade. Se houver problema, pode retornar temporariamente ao modo duplo enquanto corrige a causa.

O caminho reduz risco de corte, porém incentiva uma transição sem fim. “Suporta 1.1” pode significar apenas que o código existe. “Oferece 1.1” não garante que o servidor o escolheu. “Selecionou 1.1” não prova que 1.0 foi proibido. E a política de um salto não controla o seguinte.

Etapa Evidência operacional
Suportado Versões de cliente, servidor e TLS atendem ao perfil.
Oferecido A oferta ALPN aparece no handshake real.
Selecionado A conexão de produção registra radius/1.1.
Exigido O par limitado a 1.0 é recusado pela política.
Legado encerrado Perfis históricos e transportes não protegidos desapareceram do salto definido.

Uma comissão de migração deve publicar o alcance de cada linha preenchida, sem transformar capacidade em adoção.

Autoria não substitui a rede

A InkBridge identifica DeKok como criador e líder do FreeRADIUS. Isso explica a continuidade entre código e padrão, mas não o torna inventor único ou soberano de RADIUS. Há autores anteriores, consenso do IETF, implementadores de TLS, fabricantes, equipes de identidade e operadores de cada proxy. Todos controlam alguma condição necessária.

O mérito do RFC 9765 está em aceitar essa distribuição. Ele nomeia a dívida, conserva o formato útil, transfere a proteção para a camada que já a executa e cria uma escolha negociada que pode ser medida. Seu status Experimental impede confundir publicação com conclusão. A proposta só ganha autoridade operacional quando o código está disponível, a seleção é observada e os responsáveis conseguem desligar o caminho antigo sem perder o serviço.

Fontes