# RADIUS de ponta a ponta: um login 802.1X, pacote por pacote

> O que um switch e um servidor RADIUS de fato dizem um ao outro quando um notebook é ligado na rede: os campos e códigos de pacote da RFC 2865, os atributos que carregam a identidade e a política, a conversa EAP repassada em atributos EAP-Message, a atribuição de VLAN da RFC 3580, os registros Start e Stop da RFC 2866, o Change of Authorization iniciado pelo servidor da RFC 5176, a cadeia de proxies e as duas coisas que o segredo compartilhado protege e não protege. Cada número vem da RFC em que está.

Source: https://ronutz.com/pt-BR/learn/radius-end-to-end  
Updated: 2026-10-06

---

## Por que um protocolo para modems ainda decide quem entra na rede

O RADIUS (Remote Authentication Dial-In User Service) foi especificado para servidores de terminal que atendiam chamadas telefônicas, e o nome nunca foi atualizado porque o trabalho não mudou: um equipamento na borda da rede tem alguém do outro lado de uma conexão e precisa de uma resposta de um servidor sobre se, e como, deixá-lo entrar. A RFC 2865, publicada em junho de 2000 por Rigney, Willens, Rubens e Simpson, tornando obsoleta a RFC 2138, continua sendo a especificação base. Seu cliente é o servidor de acesso à rede, o NAS, que hoje é um switch, um ponto de acesso, uma controladora sem fio, um concentrador de VPN (rede privada virtual) ou um gateway de banda larga; seu servidor é a coisa que tem a política. Toda porta 802.1X, todo SSID corporativo e a maioria dos logins de VPN rodam esse protocolo, então uma conversa que vale a pena entender em detalhe é um login 802.1X cabeado, que exercita quase todas as partes dele.

## O pacote

Um pacote RADIUS é cinco coisas em ordem: um Code de um octeto, um Identifier de um octeto, um Length de dois octetos, um Authenticator de dezesseis octetos e uma lista de atributos. A RFC 2865 diz que o Identifier ajuda a casar pedidos e respostas, e que o comprimento mínimo do pacote é 20 e o máximo é 4096. Os códigos que um login usa são 1 Access-Request, 2 Access-Accept, 3 Access-Reject e 11 Access-Challenge; a RFC 2866 acrescenta 4 Accounting-Request e 5 Accounting-Response. O transporte é UDP, porta 1812 para autenticação e 1813 para contabilização; as RFCs anotam que as portas anteriores, 1645 e 1646, conflitavam com outros serviços e foram substituídas.

Os atributos são triplas tipo-comprimento-valor, e seus números aparecem em toda captura e em todo log de servidor. Os que este login vai usar, com seus números da RFC 2865: User-Name (1), User-Password (2), NAS-IP-Address (4), NAS-Port (5), Service-Type (6), Framed-IP-Address (8), 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). A RFC 3579 acrescentou o EAP-Message (79) e o Message-Authenticator (80). A RFC 2868 acrescentou os atributos de túnel, dos quais três importam aqui: Tunnel-Type (64), Tunnel-Medium-Type (65) e Tunnel-Private-Group-ID (81).

## Passo um: o switch pergunta

Um notebook é ligado numa porta configurada para 802.1X. O switch, agindo como autenticador, vinha enviando quadros EAP-Request Identity à porta, e o suplicante do notebook responde com sua identidade. O switch agora monta um Access-Request. Põe a identidade no User-Name (1), o pacote EAP bruto em um ou mais atributos EAP-Message (79), seu próprio endereço ou nome no NAS-IP-Address (4) ou no NAS-Identifier (32), a porta no NAS-Port (5) e o NAS-Port-Type (61) com o valor Ethernet (15), o valor que a RFC 3580 nomeia para 802.1X cabeado; uma controladora sem fio enviaria Wireless-IEEE 802.11 (19). O Calling-Station-Id (31) carrega o endereço MAC do notebook, que a RFC 3580 manda enviar em ASCII, só em maiúsculas, com os octetos separados por hífen, como 00-10-A4-23-19-C0; o Called-Station-Id (30) carrega o MAC da porta do switch ou do ponto de acesso na mesma forma, com o SSID anexado após dois-pontos no sem fio.

Como o pedido contém um EAP-Message, a RFC 3579 exige que ele contenha também um Message-Authenticator (80): o atributo Message-Authenticator deve ser usado para proteger todos os pacotes Access-Request, Access-Challenge, Access-Accept e Access-Reject que contenham um atributo EAP-Message. Esse atributo é, na definição da RFC 3579, um HMAC-MD5 sobre tipo, identificador, comprimento, autenticador do pedido e atributos com o segredo compartilhado como chave, e é a única coisa que autentica o pedido como um todo; quem recebe deve descartar silenciosamente o pacote se o valor não confere, e um servidor que recebe um EAP-Message sem Message-Authenticator deve descartá-lo também.

## Passo dois: as rodadas de desafio

O servidor não responde sim ou não. Responde com um Access-Challenge (11), carregando seu próprio EAP-Message com o passo seguinte do método EAP que quer rodar, e um atributo State (24). O State é a alça do servidor sobre a conversa: o cliente o devolve sem modificação no próximo Access-Request, e é assim que uma troca UDP de aparência sem estado carrega uma conversa de várias rodadas. O switch extrai o pacote EAP do desafio, envia-o ao notebook num quadro EAPOL, espera a resposta EAP do notebook, embrulha-a num novo Access-Request com o mesmo State e devolve.

Para um método como EAP-TLS ou PEAP isso acontece muitas vezes, porque um handshake TLS carregando certificados não cabe num único pacote EAP; a RFC 5216 define a fragmentação e as confirmações vazias, e a RFC 3579 diz que, quando vários atributos EAP-Message são necessários num mesmo pacote RADIUS, eles devem estar em ordem e ser consecutivos, e são concatenados num único pacote EAP. O switch nunca interpreta nada disso. Nas palavras da RFC 3579, o NAS encaminha pacotes EAP de e para o servidor RADIUS, encapsulados em atributos EAP-Message. O artigo sobre 802.1X e os métodos EAP cobre o que acontece dentro desses pacotes; para o switch o método é opaco, e é por isso que trocá-lo nunca exige mexer nos switches.

## Passo três: a resposta, e a política que viaja nela

Quando o método EAP termina, o servidor envia um Access-Accept (2) ou um Access-Reject (3), com o Success ou Failure final do EAP dentro de um EAP-Message. O Accept é onde a política viaja, e os atributos nele são o que as regras de um motor de política de fato produzem.

A atribuição de VLAN (rede local virtual) usa os três atributos de túnel juntos, exatamente como a RFC 3580 os escreve: Tunnel-Type com o valor VLAN (13), Tunnel-Medium-Type com o valor 802 (6) e Tunnel-Private-Group-ID carregando o identificador da VLAN, um número de 1 a 4094, como string. O switch coloca a porta nessa VLAN pela duração da sessão. O Session-Timeout (27) junto com o Termination-Action (29) igual a RADIUS-Request diz à porta, nas palavras da RFC 3580, o número máximo de segundos de serviço antes da reautenticação. O Class (25) é uma etiqueta que o servidor anexa, e a RFC 2865 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, que é como os registros de contabilização de uma sessão podem ser amarrados à política que a admitiu. O Filter-Id (11) nomeia uma lista de acesso no switch; o Vendor-Specific (26) carrega o que o fabricante definiu. O Reply-Message (18) carrega texto para o usuário, que um suplicante 802.1X não tem onde mostrar mas um portal de autenticação web tem.

Um Reject carrega o Failure do EAP e nada mais que o switch vá usar. A porta continua fechada, ou passa ao que o switch estiver configurado para fazer em seguida: uma VLAN de visitante, o MAC Authentication Bypass, a autenticação web, ou nada.

## O que o segredo compartilhado protege, e o que não protege

Cada par de cliente e servidor compartilha um segredo, que a RFC 2865 diz dever ser tão difícil de adivinhar quanto uma senha bem escolhida e que não pode ser vazio. Ele é usado em três lugares. O atributo User-Password (2), quando presente, é escondido por XOR com um fluxo MD5 calculado a partir do segredo e do Authenticator do pedido, dezesseis octetos por vez; num login 802.1X não há User-Password, porque a credencial viaja dentro do EAP. O Authenticator de toda resposta é um MD5 sobre código, identificador, comprimento, autenticador do pedido, atributos e segredo, o que deixa o cliente confirmar que a resposta veio de quem tem o segredo. E o atributo Message-Authenticator é um HMAC sobre o pacote, protegendo a troca EAP contra adulteração.

Todo o resto vai em texto claro: o nome de usuário, os endereços MAC, a identidade do switch, as próprias mensagens EAP (o TLS dentro delas é cifrado, a moldura EAP não) e todos os atributos do Accept, inclusive a VLAN em que o usuário caiu. O documento de comparação da Cisco diz sem rodeios: 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, acrescenta o veredito sobre a criptografia: a segurança do RADIUS se baseia no algoritmo MD5, que já se provou inseguro. Seu remédio embrulha a carga inteira do pacote RADIUS num fluxo TLS sobre a porta TCP 2083, com as duas pontas autenticadas por certificados X.509 e o segredo compartilhado fixado na string literal radsec, que está ali só para que a aritmética MD5 ainda possa ser feita. Onde switches e servidores o suportam, o RadSec é como a conversa acima deixa de cruzar a rede em claro.

## Passo quatro: contabilização

Aberta a porta, o switch envia um Accounting-Request (4) à porta 1813 com Acct-Status-Type igual a Start (1), e o servidor responde com um Accounting-Response (5). A RFC 2866 recomenda que o cliente continue tentando enviar o Accounting-Request até receber uma confirmação, usando alguma forma de recuo, de modo que uma queda breve do servidor atrasa os registros em vez de perdê-los. O Start carrega o User-Name, os identificadores de estação, um Acct-Session-Id que identificará todo registro desta sessão e o Class que o servidor enviou no Accept. Registros Interim-Update (3) seguem no intervalo para o qual o switch está configurado, com os contadores correntes: Acct-Input-Octets e Acct-Output-Octets, Acct-Input-Packets e Acct-Output-Packets, Acct-Session-Time em segundos. Quando o notebook é desligado ou a sessão é encerrada, um registro Stop (2) carrega os contadores finais e o Acct-Terminate-Cause. Accounting-On (7) e Accounting-Off (8) são enviados quando o próprio switch começa ou para de servir, o que avisa o servidor para fechar toda sessão que ele ainda acredite aberta naquele equipamento.

O Request Authenticator de um pacote de contabilização é um MD5 sobre o pacote com dezesseis octetos zero no lugar do Authenticator e o segredo anexado, o que deixa o servidor rejeitar registros de um cliente que não conhece o segredo. Os próprios registros vão em texto claro. O artigo sobre quem fez o quê e quando descreve o que fazer com eles.

## Passo cinco: o servidor muda de ideia

O RADIUS base não dá ao servidor como falar depois do Accept. A RFC 5176, as Dynamic Authorization Extensions de janeiro de 2008, acrescenta dois pedidos que o lado servidor envia ao switch: Disconnect-Request (40), respondido por Disconnect-ACK (41) ou Disconnect-NAK (42), e CoA-Request (43), Change of Authorization, respondido por CoA-ACK (44) ou CoA-NAK (45). A RFC especifica o destino: para pacotes Disconnect-Request ou CoA-Request, a porta UDP 3799 é usada como porta de destino. Os papéis são nomeados ao contrário do login acima, o Dynamic Authorization Client sendo o servidor de política e o Dynamic Authorization Server sendo o switch, e é por isso que uma captura mostra o switch respondendo na 3799.

Um CoA identifica a sessão com os mesmos atributos com que ela foi construída, User-Name, Calling-Station-Id, Acct-Session-Id, e carrega os atributos a mudar, na maioria das vezes um novo Tunnel-Private-Group-ID para mover o dispositivo a uma VLAN de quarentena, um filtro novo ou uma instrução para reautenticar. Se o switch não consegue aplicar um atributo, responde CoA-NAK com um Error-Cause, e a RFC atribui 401 a Unsupported Attribute. Esse é o mecanismo sob toda verificação de postura, toda expiração de visitante e todo botão de isolar esta ponta, e ele exige duas coisas de que os fluxos originais nunca precisaram: o switch configurado para aceitar autorização dinâmica dos servidores específicos, e a direção inversa aberta em qualquer firewall entre eles.

## Proxies, realms e federações

O servidor com que o switch fala muitas vezes não é o servidor que conhece o usuário. A RFC 2865 permite que um servidor atue como proxy, encaminhando o pedido a outro servidor e repassando a resposta; cada proxy anexa seu próprio atributo Proxy-State (33) para que a resposta possa ser roteada de volta pelo caminho, e a RFC avisa que loops devem ser evitados. O roteamento em geral é por realm, a parte do User-Name depois de um arroba, e é assim que as credenciais de um visitante são conferidas pela própria organização dele. Cadeias de proxies entre organizações são o cenário que a RFC 6614 nomeia como uso principal do RadSec, já que um segredo compartilhado por par de organizações não escala e atributos em texto claro cruzando a Internet pública são inaceitáveis. Dentro de uma única organização o mesmo mecanismo deixa um conjunto de switches alcançar vários servidores de política por um proxy local, com o segredo configurado uma vez só.

## Onde o RADIUS para e o TACACS+ começa

A comparação da Cisco, escrita pela empresa que desenvolveu o TACACS+ depois de avaliar seriamente o RADIUS como protocolo de segurança, lista as diferenças que ainda decidem qual protocolo faz qual trabalho: o RADIUS usa UDP enquanto o TACACS+ usa TCP; o RADIUS combina autenticação e autorização, enquanto o TACACS+ separa as três trocas; o RADIUS não permite controlar quais comandos podem ser executados num roteador, enquanto o TACACS+ oferece dois métodos para controlar a autorização de comandos por usuário ou por grupo. A consequência é a divisão em que todo parque acaba: RADIUS para acesso à rede, o usuário ou o dispositivo sendo admitido numa porta, num SSID ou numa VPN, onde vivem o 802.1X e os métodos EAP; TACACS+ para administração de equipamentos, onde os comandos de um engenheiro precisam ser autorizados um a um e registrados. O artigo companheiro sobre administração de equipamentos com TACACS+ percorre esse lado.

## Uma lista de diagnóstico, a partir dos campos acima

A maioria das falhas de RADIUS é visível nos campos que este artigo nomeou. Um pedido que não recebe resposta alguma em geral é um segredo divergente, porque um servidor cuja verificação do Message-Authenticator falha deve descartar o pacote em silêncio em vez de rejeitá-lo, ou um firewall fechando a 1812. Um método que falha depois de várias rodadas de desafio, num caminho que funciona para trocas curtas, é fragmentação ou um problema de tamanho de pacote em algum ponto entre o switch e o servidor, já que o EAP-TLS precisa de muitos pacotes grandes onde um método de senha precisa de poucos. Um usuário que se autentica mas cai na rede errada tem um Accept cujos atributos de túnel nomeiam uma VLAN que o switch não tem, ou um Tunnel-Medium-Type diferente de 6. Um motor de política que acredita ter colocado em quarentena um dispositivo que o switch continua servindo tem um CoA que nunca foi aceito, o que o CoA-NAK e seu Error-Cause explicam se alguém os lê. E uma sessão sem registros de contabilização tem um switch que nunca foi avisado para onde enviá-los, que é o apontamento mais antigo da área e o assunto do artigo sobre contabilização.

## Fontes

- [RFC 2865, Remote Authentication Dial In User Service (RADIUS), Rigney, Willens, Rubens, Simpson, junho de 2000: os campos do pacote, os códigos, os números dos atributos, o ocultamento do User-Password, o autenticador de resposta, as regras do segredo compartilhado, o papel do Identifier, o comprimento de 20 a 4096 octetos, o Class na contabilização, o Proxy-State e as cadeias de proxies (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc2865)
- [RFC 2866, RADIUS Accounting, Rigney, junho de 2000: a porta 1813, os valores de Acct-Status-Type, os atributos de contabilização, o autenticador de pedido zerado e a recomendação de reenvio (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc2866)
- [RFC 3579, RADIUS Support For Extensible Authentication Protocol (EAP), Aboba e Calhoun, setembro de 2003: EAP-Message (79) e Message-Authenticator (80), o NAS pass-through, os atributos EAP-Message consecutivos (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc3579)
- [RFC 3580, IEEE 802.1X RADIUS Usage Guidelines, Congdon, Aboba, Smith, Zorn, Roese, setembro de 2003: a atribuição de VLAN com os três atributos de túnel, os formatos dos identificadores de estação, NAS-Port-Type 15 e 19, Session-Timeout e Termination-Action (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc3580)
- [RFC 2868, RADIUS Attributes for Tunnel Protocol Support, junho de 2000: Tunnel-Type (64), Tunnel-Medium-Type (65) e Tunnel-Private-Group-ID (81), o tipo de meio 6 para 802 (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc2868)
- [RFC 5176, Dynamic Authorization Extensions to RADIUS, Chiba, Dommety, Eklund, Mitton, Aboba, janeiro de 2008: os códigos 40 a 45, a porta UDP 3799, os papéis de cliente e servidor, o Error-Cause 401 (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc5176)
- [RFC 6614, Transport Layer Security (TLS) Encryption for RADIUS, Winter, McCauley, Venaas, Wierenga, maio de 2012: o veredito sobre o MD5, o fluxo TLS na TCP 2083, o segredo fixo e o caso de uso de roaming (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc6614)
- [RFC 5216, The EAP-TLS Authentication Protocol, março de 2008: a fragmentação com os bits L e M e a confirmação vazia (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc5216)
- [Cisco, TACACS+ and RADIUS Comparison, documento 13838: UDP contra TCP, só a senha cifrada, autenticação e autorização combinadas, controle por comando, a avaliação do RADIUS pela Cisco antes de desenvolver o TACACS+ (lido em 06/10/2026)](https://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/13838-10.html)