RadSec (RADIUS over TLS)
termoSignifica: Transport Layer Security Encryption for RADIUS (RFC 6614): RADIUS over TCP port 2083 inside TLS
RADIUS sobre TLS, RFC 6614: o pacote RADIUS inteiro carregado dentro de uma sessão TLS na porta TCP 2083, com as duas pontas autenticadas por certificados X.509 e o segredo compartilhado do RADIUS fixado na string literal radsec.
A RFC 6614 (Winter, da RESTENA, McCauley, Venaas e Wierenga, da Cisco, maio de 2012, Experimental) parte de uma afirmação direta: a segurança do RADIUS se baseia no algoritmo MD5, que já se provou inseguro, e só o atributo de senha era escondido de todo modo. O RadSec embrulha a carga inteira do pacote RADIUS num fluxo TLS sobre TCP, na porta 2083, com autenticação X.509 mútua, de modo que os nomes de usuário, endereços MAC, trocas EAP e atributos de política que o RADIUS puro envia em claro ficam cifrados e os pares são autenticados por certificados em vez de por um segredo compartilhado por par. Como o formato do pacote RADIUS ainda exige um segredo para seus cálculos MD5 internos, a RFC o fixa na string radsec. O uso principal que a RFC nomeia é o roaming entre domínios administrativos, em que proxies RADIUS de organizações diferentes encaminham as autenticações uns dos outros pela Internet pública e um segredo por par não escala; grandes federações de universidades e operadoras são o caso motivador. Dentro de uma empresa, é a resposta ao apontamento de auditoria de que o tráfego de autenticação entre os switches e os servidores de política cruza a rede sem cifragem.
O RADIUS deixa quase tudo o que carrega em texto claro e autentica seus pacotes com MD5 e um segredo compartilhado, um projeto que os próprios documentos sucessores do protocolo pararam de defender. A RFC 6614, Transport Layer Security (TLS) Encryption for RADIUS, publicada em maio de 2012 por Winter, da RESTENA, McCauley, Venaas e Wierenga, da Cisco, como documento Experimental, abre com o diagnóstico: a segurança do RADIUS se baseia no algoritmo MD5, que já se provou inseguro. Seu remédio não é um protocolo novo, e sim um transporte novo. O RadSec embrulha a carga inteira do pacote RADIUS num fluxo TLS, carregado sobre TCP na porta 2083, e autentica as duas pontas com certificados X.509.
O projeto mantém os pacotes e muda o que os cerca. Um pacote RADIUS dentro do fluxo TLS é, byte a byte, o pacote que a RFC 2865 define, códigos, identificador, autenticador e atributos, de modo que servidores, proxies e dicionários de atributos permanecem inalterados e uma frente que termina o TLS pode entregar RADIUS comum a uma retaguarda existente. Como os cálculos MD5 internos do formato, o ocultamento do User-Password e o autenticador de resposta, ainda precisam de um segredo compartilhado, a RFC 6614 o fixa: o segredo é a string literal radsec, que não carrega segurança alguma e está ali só para que a aritmética possa ser feita. A segurança vem do TLS: confidencialidade para os nomes de usuário, endereços MAC, trocas EAP e atributos de política que o RADIUS puro expõe, integridade para todos os atributos e não só para a senha, e autenticação de par por certificado, que substitui o segredo por par que tinha de ser configurado nas duas pontas de cada relação.
A RFC nomeia o roaming entre domínios administrativos como uso principal, e as implantações motivadoras foram as federações em que universidades e operadoras encaminham as autenticações umas das outras para que as credenciais de um visitante sejam conferidas em casa. Numa federação dessas, um proxy RADIUS pode falar com centenas de pares que não opera, por redes que ninguém controla; um segredo compartilhado por par é ingerenciável e a carga em claro é inaceitável. Certificados emitidos por uma autoridade da federação resolvem os dois, e uma conexão TCP com TLS também dá aos proxies algo que o RADIUS sobre UDP nunca teve, um canal confiável e de longa duração cuja saúde é observável.
Para uma empresa o caso é mais simples e cada vez mais comum. Auditores que descobrem que toda conversa 802.1X e todo login de administrador cruza o campus ou a WAN num protocolo cuja única proteção é MD5 sobre um segredo compartilhado querem cifragem, e o RadSec é como os switches, controladoras e servidores de política que o suportam fazem isso. As ressalvas são de suporte e de operação: um equipamento precisa implementar RadSec do lado NAS tanto quanto do lado servidor; certificados têm de ser emitidos para switches e controladoras e renovados; e as mensagens de direção inversa da RFC 5176, Disconnect e Change of Authorization, só ficam protegidas onde as duas pontas as carregam pela mesma sessão TLS.
O status merece ser dito com precisão. A RFC 6614 é Experimental, e o trabalho do IETF sobre transporte do RADIUS continuou depois dela; o que se implanta hoje sob o nome RadSec é o protocolo deste documento, TLS sobre TCP 2083 com o segredo fixo, implementado pelos principais servidores AAA e por uma lista crescente de equipamentos de rede. O verbete RADIUS descreve o que está sendo protegido, e o artigo sobre o RADIUS de ponta a ponta mostra onde o transporte entra numa conversa completa.
Também conhecido como: radius over tls, radius/tls, rfc 6614, tcp 2083