O que o padrão define e o que fica por sua conta
O 802.1X é, nas palavras da enciclopédia, "an IEEE Standard for port-based network access control": uma porta de switch ou uma associação wireless não passa tráfego nenhum até que uma identidade seja apresentada e aceita. O padrão define quem conversa com quem e como os frames (quadros) são transportados. Ele não define como a identidade é provada. Isso fica a cargo do (o Extensible Authentication Protocol) e, dentro do EAP, de um método, e é no método que está quase toda a segurança. Uma implantação descrita como "802.1X" pode ter certificado em todos os dispositivos ou uma senha enviada por um túnel para um servidor que ninguém verificou, e as duas não têm nada em comum além do formato do frame. Este artigo passa rápido pelo formato do frame e se demora nos métodos, porque é neles que estão as decisões.
Três participantes, duas portas, um endereço
O modelo tem três papéis. O supplicant (o suplicante) é o software no dispositivo que pede acesso. O authenticator (o autenticador) é o switch ou o access point (ponto de acesso) em cuja porta o dispositivo está conectado; a enciclopédia diz que ele "acts like a security guard". O servidor de autenticação, quase sempre um servidor (Remote Authentication Dial-In User Service), é quem decide. No authenticator, o 802.1X-2001 define duas portas lógicas para cada porta física: uma porta não controlada, que sempre deixa passar os frames de que a própria autenticação precisa, e uma porta controlada, que só encaminha tráfego depois que a autenticação dá certo. Quem roda a máquina de estados é uma Port Access Entity.
O transporte é feito pelo EAP over , o EAPOL, definido para redes 802 cabeadas no 802.1X-2001 (, e FDDI), estendido para o wireless 802.11 no 802.1X-2004 e revisado no 802.1X-2010 para trabalhar com o MACsec do 802.1AE e com a identidade de dispositivo do 802.1AR. A conversa começa com o authenticator enviando, de tempos em tempos, um frame EAP-Request Identity para o endereço de grupo 01:80::00:00:03; o supplicant responde com um EAP-Response Identity; o authenticator encapsula essa resposta num Access-Request do RADIUS, e o servidor responde com um Access-Challenge propondo um método. Daí em diante, o switch só repassa pacotes EAP, sem nunca interpretá-los, dentro dos atributos EAP-Message da 3579, e age conforme o Access-Accept ou o Access-Reject final. O artigo complementar sobre o RADIUS de ponta a ponta mostra esse lado pacote por pacote.
O envelope: quatro códigos e um tipo
A RFC 3748, publicada em junho de 2004, define o EAP como um pacote com os campos Code, Identifier, Length e Data, e com quatro códigos: 1 Request, 2 Response, 3 Success e 4 Failure. Requests e Responses levam um octeto Type, e é o Type que identifica o método. A RFC base atribui 1 Identity, 2 Notification, 3 Nak (o peer, a ponta que se autentica, recusa um método e lista os que suporta), 4 -Challenge, 5 One-Time Password, 6 Generic Token Card, 254 Expanded Types e 255 Experimental; cada método mais abaixo é um Type atribuído no seu próprio documento. Duas características do envelope pesam no projeto. Segundo a RFC, o EAP "typically runs directly over data link layers", como ou IEEE 802, "without requiring IP", e é por isso que ele consegue autenticar um dispositivo que não tem endereço. E ele é "a 'lock step' protocol": só um Request fica pendente de cada vez. Por isso, um método que precisa de muitas idas e vindas, como todo método baseado em TLS, fica lento num caminho com perda de pacotes ou muito distante, e isso aparece como timeout de autenticação.
Os métodos
A decisão está na tabela abaixo. Cada linha mostra com que credencial o método autentica o cliente, como o servidor prova quem é, se existe um túnel protegendo a troca e de que documento o método vem. Os parágrafos depois da tabela trazem os detalhes de cada especificação.
| Método | EAP Type | Credencial do cliente | Servidor autenticado por | Túnel | Especificação |
|---|---|---|---|---|---|
| 13 | Certificado | Certificado | O próprio handshake TLS é o método | RFC 5216, Standards Track | |
| 25 | Método EAP interno, em geral (senha) | Certificado | TLS, só com EAP dentro | draft-josefsson-pppext-eap-tls-eap-10, expirado | |
| 21 | Método interno: EAP, ou , , MS-CHAP, MS-CHAP-V2 | Certificado | TLS, aceita métodos legados dentro | RFC 5281, Informational | |
| 43 | Método interno via TLVs; a pode substituir o certificado | Certificado ou PAC | TLS | RFC 4851, Informational | |
| 55 | Zero ou mais métodos EAP internos, encadeados | Certificado | TLS, com Crypto-Binding | RFC 7170, Standards Track | |
| 52 | Senha, por troca de chaves autenticada por senha | Senha compartilhada | Não precisa | RFC 5931, Informational | |
| / EAP-AKA | 18 / 23 | GSM / USIM UMTS | Centro de autenticação da operadora | Nenhum (o AKA é mútuo) | RFC 4186 / RFC 4187, Informational |
| MD5-Challenge | 4 | Hash da senha como resposta | Não é autenticado | Nenhum | RFC 3748 (base) |
EAP-TLS (RFC 5216, Simon, Aboba e Hurst, março de 2008) é um handshake TLS transportado dentro de pacotes EAP: o servidor apresenta um certificado, o cliente também apresenta o seu, e a troca deriva o material de chave por uma receita fixa, a função pseudoaleatória do TLS com o rótulo "client EAP encryption", que gera 64 octetos de MSK e 64 de EMSK. Como um handshake com certificados não cabe num único pacote EAP, a RFC define a fragmentação com um bit L (indica que há um campo de tamanho de quatro octetos) e um bit M (indica que vêm mais fragmentos), e cada fragmento é confirmado com um pacote do Type EAP-TLS "and no data". É o único método da lista sem senha em lugar nenhum, e o custo dele é ter um certificado em cada cliente, com emissão, renovação e revogação.
PEAP (o draft de 15 de outubro de 2004 de Palekar, Simon, Salowey, Zhou, Zorn e Josefsson, um que expirou) monta um túnel TLS em que o servidor se autentica por certificado e, depois, roda "zero or more EAP methods" dentro dele. Os objetivos declarados são "protect against rogue authenticators, protect against various attacks on the confidentiality and integrity of the inner EAP method exchange and provide EAP peer identity privacy", e ele torna obrigatório um Crypto-Binding TLV. Na prática, o método interno é o EAP-MSCHAPv2, e a combinação com o domínio Windows fez dele o padrão do corporativo com senha.
EAP-TTLS (RFC 5281, Funk e Blake-Wilson, agosto de 2008) também monta um túnel TLS em que o servidor se autentica, mas a autenticação interna "may itself be EAP, or it may be a legacy protocol", como PAP, CHAP, MS-CHAP ou MS-CHAP-V2. O PAP dentro do túnel entrega a senha ao servidor num formato que qualquer diretório consegue verificar, e é por isso que o EAP-TTLS/PAP é a resposta de costume quando a base de usuários é um diretório (Lightweight Directory Access Protocol) sem os hashes NT de que o MSCHAPv2 precisa. A RFC avisa ao cliente que a identidade externa (outer identity) "SHOULD NOT include the actual name of the user", e permite que o servidor TTLS faça proxy da autenticação interna até o servidor de origem do usuário (o home server), que é como funcionam as federações de roaming.
EAP-FAST (RFC 4851, Cam-Winget, McGrew, Salowey e Zhou, da Cisco, maio de 2007) é um túnel TLS seguido de TLVs, com um diferencial, a Protected Access Credential (PAC): uma PAC-Key de 32 octetos, um ticket opaco, o PAC-Opaque, que o servidor consegue decodificar e o peer não, e a PAC-Info, com o emissor e a validade. Um peer que tem uma PAC pode restabelecer o túnel sem troca de certificados e sem o servidor guardar estado. Os objetivos de projeto são autenticação mútua, imunidade a ataques passivos de dicionário, proteção contra e eficiência em dispositivos com poucos recursos; o problema operacional sempre foi como fazer a primeira PAC chegar a um dispositivo.
TEAP (RFC 7170, Zhou, Cam-Winget e Salowey, da Cisco, e Hanna, da Infineon, maio de 2014) é o sucessor em Standards Track, "a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel". Ele roda "zero or more EAP methods within the protected tunnel", e é esse encadeamento (chaining) que permite provar um certificado de máquina e uma credencial de usuário na mesma conversa; também pode provisionar uma PAC ou um certificado dentro do túnel; e já traz embutidos o Crypto-Binding TLV e o channel binding do EAP. A RFC registra que o EAP-FAST "has been widely adopted" e que ele serviu de base para o grupo de trabalho.
EAP-pwd (RFC 5931, Harkins e Zorn, agosto de 2010) troca o túnel por matemática: "a robust authentication method that is secure even when used with a weak password in the presence of a strong adversary". A partir da senha, os dois lados fixam "an element in the negotiated group called the Password Element" e provam, nas trocas Commit e Confirm, que os dois têm esse mesmo elemento. O requisito da RFC é que "any advantage an adversary can gain must be directly related to the number of interactions she makes with an honest protocol participant and not through computation", e "the best advantage an attacker can gain in a single active attack is to determine whether a single guess at the password was correct". Ou seja, cada ataque ativo testa um único palpite, e poder de computação não ajuda o atacante. Sem certificados, sem (infraestrutura de chaves públicas), sem nenhuma configuração de validação que possa ficar desligada; os limites são o suporte do servidor ao formato em que a senha está guardada e um suporte mais restrito nos clientes.
EAP-SIM e EAP-AKA (RFC 4186 e RFC 4187, Arkko e Haverinen, janeiro de 2006) permitem que o SIM de uma operadora móvel autentique um dispositivo: o centro de autenticação da operadora gera o desafio, o (U)SIM responde e, no AKA, o dispositivo também verifica a rede. A RFC 4187 resume as diferenças em relação ao EAP-SIM como "substantially longer key lengths and mutual authentication", e os dois métodos oferecem pseudônimos, para privacidade da identidade, e reautenticação rápida. São esses os métodos por trás do offload de Wi-Fi das operadoras, e a rede visitada funciona como um authenticator pass-through comum.
MD5-Challenge (Type 4, na própria RFC 3748) está na lista por completude e como alerta: as Security Claims que a própria RFC lista para ele são "Mutual authentication: No" e "Key derivation: No", o que o descarta em qualquer lugar onde o link precise de chaves geradas pela autenticação, como todo link wireless precisa.
A única configuração que anula quase toda a tabela
Todo método em que o servidor se autentica por certificado depende de o cliente validar esse certificado contra uma autoridade confiável e um nome esperado. O túnel do PEAP, do EAP-TTLS, do EAP-FAST e do TEAP só protege a credencial interna contra quem está fora do túnel. Um supplicant configurado para aceitar qualquer certificado vai montar o túnel com um access point impostor e entregar a ele a troca interna: uma senha PAP em claro dentro do túnel do atacante, ou um challenge-response MSCHAPv2 pronto para ser atacado offline. O EAP-TLS não entrega senha nenhuma a esse impostor, mas ainda assim entrega a ele um cliente autenticado numa rede hostil. Essa configuração fica no cliente, só é imposta pelo gerenciamento de dispositivos e costuma faltar justamente nos dispositivos pessoais, cujos usuários clicam em qualquer aviso para seguir adiante. A recomendação da RFC 2759 de que o authenticator "SHOULD limit the number of password retries" é o controle do lado do servidor; o que realmente importa é a validação de certificado em todos os clientes, e o EAP-pwd é o único método com senha que elimina essa questão.
O que o servidor devolve e por que a porta se comporta assim
O Access-Accept que encerra um método bem-sucedido carrega a política, e a RFC 3580, as IEEE 802.1X RADIUS Usage Guidelines, dá nome aos atributos. A atribuição de (rede local virtual) usa três atributos juntos: Tunnel-Type com o valor VLAN (13), Tunnel-Medium-Type com o valor 802 (6) e Tunnel-Private-Group-ID levando o identificador da VLAN como string. O Session-Timeout, com Termination-Action igual a RADIUS-Request, define "the maximum number of seconds of service provided prior to re-authentication". O NAS-Port-Type informa ao servidor se a requisição veio de Ethernet (15) ou de Wireless- (19), para que uma mesma política possa tratar os dois casos de forma diferente. O Calling-Station-Id leva o MAC do dispositivo em letras maiúsculas e separado por hífens, e o Called-Station-Id leva o da porta ou do access point, com o depois de dois-pontos, no caso do wireless. O artigo sobre o RADIUS mostra esses atributos numa troca completa; aqui, o ponto é que o método prova a identidade e os atributos transformam essa identidade numa posição na rede.
Os dispositivos que não conseguem fazer nada disso
Impressoras, câmeras, leitores de crachá, telefones anteriores ao padrão e uma infinidade de equipamentos embarcados não têm supplicant. A alternativa que a indústria adotou é o MAC Authentication Bypass (MAB): quando o 802.1X dá timeout numa porta, o switch envia o endereço MAC do dispositivo como se fosse a identidade dele. O guia de configuração da Cisco descreve o MAB como "a MAC-address-based authentication mechanism" para "platforms with no supplicant or not under administrative control" e dá como exemplos caixas registradoras, aparelhos de fax e impressoras. O guia também especifica a requisição: "a RADIUS request with a in the Calling-Station-Id" (atributo 31), com o Service-Type (atributo 6) no valor 10, o Call Check. A enciclopédia descreve a mesma sequência: a porta tenta primeiro o 802.1X e depois autentica usando o MAC como nome de usuário e senha. Endereço MAC não é segredo, então o MAB é uma política de admissão para equipamentos. Ele deve vir junto com uma VLAN ou um filtro restritivo e com profiling que derruba a sessão, via Change of Authorization do RADIUS, quando o equipamento deixa de se comportar como aquilo que disse ser. Para pessoas em dispositivos sem supplicant existe uma terceira opção, a autenticação web, coberta no artigo complementar; a configuração usual da porta tenta as três, nessa ordem.
Os limites conhecidos do padrão
A enciclopédia registra limites que foram documentados cedo e que continuam valendo. Em 2005, Steve Riley, com base em pesquisa de Svyatoslav Pidgorny, descreveu um ataque man-in-the-middle em que o atacante, por meio de um hub, passa a compartilhar uma porta depois que o dispositivo legítimo já se autenticou, porque a porta, uma vez aberta, não confere de novo cada frame. A mitigação sugerida na época foi o , e a resposta do próprio padrão é a integração do 802.1X-2010 com o MACsec, que autentica e criptografa cada frame no link. Os frames EAPOL-Logoff trafegam em claro e podem ser forjados (spoofing) com facilidade para derrubar um dispositivo da porta. Nenhum dos dois problemas muda a conclusão de projeto; os dois reforçam o uso de MACsec onde o cabo não é confiável e a ideia de tratar o 802.1X como controle de admissão, e não como segurança frame a frame.
Como escolher
A decisão sai da tabela. Dispositivos que conseguem guardar um certificado usam EAP-TLS, o que hoje significa notebooks, celulares e tablets gerenciados, e uma parcela cada vez maior de impressoras e controladores. Quando é preciso provar a máquina e o usuário, ou provisionar credenciais no primeiro contato, TEAP. Quando a restrição é um back end de senhas, PEAP com EAP-MSCHAPv2 para um domínio Windows e EAP-TTLS com PAP para outros diretórios, nos dois casos com a validação do certificado do servidor imposta por política em todos os clientes e conferida para cada classe de dispositivo. EAP-pwd quando as duas pontas suportam o método e ninguém quer PKI. MAB para os equipamentos, autenticação web para as pessoas sem supplicant e MACsec quando não dá para confiar nem no próprio cabo. Cada uma dessas frases é um método, e nenhuma delas é "802.1X".
Fontes
- Wikipedia, IEEE 802.1X: a definição, as edições de 2001, 2004 e 2010, o EAPOL e o endereço de grupo, os três papéis e a linha do segurança, as portas controlada e não controlada, o MAB, a análise de Riley e Pidgorny de 2005 e a fraqueza do EAPOL-Logoff (lida em 06/10/2026)
- RFC 3748, Extensible Authentication Protocol (EAP), Aboba, Blunk, Vollbrecht, Carlson, Levkowetz, junho de 2004: os códigos e tipos, o lock step, o transporte em enlace sem IP, o autenticador pass-through, as alegações de segurança do MD5-Challenge (lida em 06/10/2026)
- RFC 5216, The EAP-TLS Authentication Protocol, Simon, Aboba, Hurst, março de 2008: o Type 13, a fragmentação, a receita do material de chave (lida em 06/10/2026)
- draft-josefsson-pppext-eap-tls-eap-10, Protected EAP Protocol (PEAP) Version 2, 15 de outubro de 2004, expirado: o Type 25, as duas partes, os objetivos, o Crypto-Binding TLV (lido em 06/10/2026)
- RFC 5281, EAP-TTLSv0, Funk e Blake-Wilson, agosto de 2008: o Type 21, os métodos legados internos, a identidade externa anônima, o encaminhamento ao servidor de origem (lida em 06/10/2026)
- RFC 4851, EAP-FAST, Cam-Winget, McGrew, Salowey, Zhou, maio de 2007: o Type 43, a PAC e os objetivos de projeto (lida em 06/10/2026)
- RFC 7170, Tunnel EAP Method (TEAP) Version 1, Zhou, Cam-Winget, Salowey, Hanna, maio de 2014: o Type 55, os métodos internos encadeados, o provisionamento, o Crypto-Binding e o channel binding, o EAP-FAST como base (lida em 06/10/2026)
- RFC 5931, EAP Authentication Using Only a Password, Harkins e Zorn, agosto de 2010: o Type 52, o Password Element, o requisito contra ataque de dicionário e o limite de um palpite (lida em 06/10/2026)
- RFC 4187, EAP-AKA, Arkko e Haverinen, janeiro de 2006: o Type 23, a troca AKA, as diferenças em relação ao EAP-SIM, pseudônimos e reautenticação rápida (lida em 06/10/2026)
- RFC 2759, Microsoft PPP CHAP Extensions, Version 2, Zorn, janeiro de 2000: a autenticação mútua e o limite de tentativas (lida em 06/10/2026)
- RFC 3579, RADIUS Support For EAP, setembro de 2003: o repasse em EAP-Message (lida em 06/10/2026)
- RFC 3580, IEEE 802.1X RADIUS Usage Guidelines, setembro de 2003: a atribuição de VLAN, o Session-Timeout, o NAS-Port-Type e os identificadores de estação (lida em 06/10/2026)
- Guia de configuração do Cisco IOS, Configuring MAC Authentication Bypass: a definição, os exemplos e o pedido RADIUS que o MAB monta (lido em 06/10/2026)