RADIUS

Significa: Remote Authentication Dial-In User Service (RFC 2865, RFC 2866)

O burro de carga do AAA: autentica quem conecta, autoriza o que recebe e contabiliza o que usou - para provedores, VPNs e Wi-Fi igualmente.

Remote Authentication Dial-In User Service; o nome lembra os modems, o protocolo sobreviveu a eles. A RFC 2865 (junho de 2000) define um protocolo UDP na porta 1812 com os códigos que importam, Access-Request, Access-Accept, Access-Reject e Access-Challenge, mais os dois pacotes de contabilização da RFC 2866 na porta 1813, e um pacote de Code, Identifier, Length, um Authenticator de 16 octetos e atributos em tipo-comprimento-valor: User-Name (1), User-Password (2), NAS-IP-Address (4), Service-Type (6), Framed-IP-Address (8), Reply-Message (18), State (24), Class (25), Vendor-Specific (26), Called- e Calling-Station-Id (30, 31), NAS-Identifier (32), NAS-Port-Type (61) e o EAP-Message (79) e o Message-Authenticator (80) da RFC 3579 que carregam o 802.1X. Sua segurança é um segredo compartilhado e MD5: só o User-Password é escondido, por XOR com um fluxo MD5 do segredo e do autenticador do pedido; o resto do pacote vai em claro, que é a fraqueza que o RadSec (RFC 6614) responde embrulhando o pacote inteiro em TLS. A RFC 5176 acrescenta as mensagens Disconnect e Change-of-Authorization iniciadas pelo servidor na UDP 3799. É o protocolo por trás de toda porta 802.1X, de todo SSID corporativo, da maioria dos logins de VPN e da maioria das sessões de assinante das operadoras.

O RADIUS foi escrito para servidores de terminal cheios de modems e continua sendo o protocolo que toda porta de switch, ponto de acesso e concentrador de VPN fala com a coisa que decide. A RFC 2865, publicada em junho de 2000 por Rigney, Willens, Rubens e Simpson como documento em trilha de padrão tornando obsoleta a RFC 2138, define um protocolo cliente-servidor sobre UDP, com o servidor escutando na porta 1812 (a 1645 anterior já estava atribuída a outro serviço), em que o servidor de acesso à rede é o cliente e o servidor de política é o servidor. Um pacote é um Code, um Identifier de um octeto que ajuda a casar pedidos e respostas, um Length entre 20 e 4096 octetos, um Authenticator de 16 octetos e uma lista de atributos. Os códigos que carregam autenticação são 1 Access-Request, 2 Access-Accept, 3 Access-Reject e 11 Access-Challenge; a RFC 2866 companheira, do mesmo mês, de Rigney, define 4 Accounting-Request e 5 Accounting-Response na porta 1813. Um NAS envia um Access-Request com o que sabe da sessão e recebe uma das três respostas; um Challenge significa que o servidor quer outra rodada, que é como os métodos de várias etapas e todo o EAP viajam por cima.

Os atributos são onde mora a expressividade do protocolo, e seus números valem a pena saber porque capturas e logs de servidor os exibem. A RFC 2865 atribui User-Name (1), User-Password (2), CHAP-Password (3), NAS-IP-Address (4), NAS-Port (5), Service-Type (6), Framed-Protocol (7), Framed-IP-Address (8), Filter-Id (11), Reply-Message (18), State (24), Class (25), Vendor-Specific (26), Session-Timeout (27), Idle-Timeout (28), Termination-Action (29), Called-Station-Id (30), Calling-Station-Id (31), NAS-Identifier (32), Proxy-State (33) e NAS-Port-Type (61), entre outros. O Vendor-Specific é a válvula de escape que todo fabricante usou para seus próprios atributos. O Class é o jeito de o servidor etiquetar uma sessão para que a etiqueta volte na contabilização: a RFC diz que ele deve ser enviado sem modificação pelo cliente ao servidor de contabilização como parte do Accounting-Request, se houver contabilização. A RFC 3579 acrescentou o EAP-Message (79) e o Message-Authenticator (80), o par que deixa um switch repassar uma conversa 802.1X que não consegue ler, e as RFCs 2868 e 3580 forneceram os atributos de túnel, Tunnel-Type (64), Tunnel-Medium-Type (65) e Tunnel-Private-Group-ID (81), que atribuem uma VLAN a uma porta autenticada. O Proxy-State é como uma cadeia de proxies, cada um anexando o seu, roteia uma resposta de volta pelo caminho de onde veio.

Segurança é onde o protocolo mostra a idade, e a RFC é franca sobre o projeto. Cliente e servidor compartilham um segredo que o documento diz dever ser tão difícil de adivinhar quanto uma senha bem escolhida e que não pode ser vazio. Só o atributo User-Password é escondido: ele é combinado por XOR, dezesseis octetos por vez, com um fluxo MD5 calculado a partir do segredo compartilhado e do Authenticator do pedido. O Authenticator da resposta é um MD5 sobre código, identificador, comprimento, autenticador do pedido, atributos e segredo, o que autentica a resposta perante o cliente; o pedido em si, fora o Message-Authenticator quando presente, não é autenticado, e todo atributo exceto a senha viaja em claro, inclusive nomes de usuário, endereços MAC e a política que o servidor devolve. O documento de comparação da Cisco resume numa linha: o RADIUS cifra apenas a senha no pacote access-request, do cliente para o servidor; o restante do pacote não é cifrado. A RFC 6614, a especificação do RadSec, diz do resultado que a segurança do RADIUS se baseia no algoritmo MD5, que já se provou inseguro, e responde carregando o pacote inteiro dentro de TLS sobre a porta TCP 2083; o verbete RadSec conta essa história.

A segunda coisa que o RADIUS não foi projetado para fazer é receber instruções do servidor depois que a sessão começou. O protocolo base é pedido-resposta a partir do NAS; emitido o Access-Accept, o servidor não tem voz até o próximo pedido. A RFC 5176 (janeiro de 2008, tornando obsoleta a RFC 3576) acrescenta as Dynamic Authorization Extensions: um Disconnect-Request (código 40) que encerra uma sessão e um CoA-Request (43) que muda sua autorização, enviados pelo lado servidor ao NAS na porta UDP 3799 e respondidos com ACK ou NAK (41, 42, 44, 45). É isso que deixa um motor de política colocar em quarentena um dispositivo cuja postura mudou ou movê-lo a outra VLAN sem que o usuário se reautentique, e o verbete RADIUS CoA cobre o assunto.

A outra metade do protocolo, a contabilização, é coberta pela RFC 2866 e pelo verbete accounting: registros Start, Stop e Interim-Update com contadores de octetos e pacotes, tempo de sessão e causa de término, confirmados pelo servidor e reenviados pelo cliente com recuo até serem confirmados. Diante do TACACS+ a divisão de trabalho é estável: a própria comparação da Cisco observa que o RADIUS combina autenticação e autorização numa só troca e não permite controlar quais comandos podem ser executados num roteador, então o RADIUS é dono do acesso à rede, a autenticação de usuário e de dispositivo na porta, no SSID e na VPN, enquanto o TACACS+ é dono da administração de equipamentos com sua autorização e contabilização por comando. O artigo sobre o RADIUS de ponta a ponta percorre uma conversa 802.1X por cada campo nomeado aqui.

Também conhecido como: remote authentication dial-in user service, udp 1812, udp 1813, access-request, access-accept, nas

Fontes

← Todos os verbetes do glossário