PEAP
siglaSignifica: Protected Extensible Authentication Protocol (EAP Type 25)
Protected EAP, EAP Type 25: um túnel TLS autenticado pelo certificado do servidor, dentro do qual um segundo método EAP mais fraco (na prática quase sempre o EAP-MSCHAPv2) autentica o usuário com uma senha.
O PEAP resolve o problema de senhas não poderem viajar com segurança numa troca EAP nua: a parte um é um handshake TLS em que o servidor apresenta um certificado e o cliente o verifica, e a parte dois roda zero ou mais métodos EAP dentro do túnel resultante, protegidos de escuta e de um autenticador impostor. A especificação, o draft-josefsson-pppext-eap-tls-eap-10, Protected EAP Protocol (PEAP) Version 2, de 15 de outubro de 2004, é um Internet-Draft expirado de Palekar, Simon, Salowey, Zhou, Zorn e Josefsson; ele atribui o Type 25 e descreve os objetivos como proteção contra autenticadores impostores, proteção da confidencialidade e da integridade da troca interna e privacidade de identidade para o par. Ele torna obrigatório um Crypto-Binding TLV que amarra o método interno ao túnel externo. Toda a segurança de uma implantação PEAP repousa sobre uma configuração do cliente: se o suplicante valida o certificado do servidor e o nome nele. Um cliente que não valida completa o túnel com qualquer ponto de acesso que ofereça um certificado e entrega sua troca MSCHAPv2 a quem estiver do outro lado. PEAP com EAP-MSCHAPv2 é o método que tornou possível o Wi-Fi corporativo com senhas do Active Directory, e o que mais precisa dessa configuração conferida.
O Protected EAP foi projetado para um mundo em que o que a empresa tinha era um banco de senhas e o que ela queria era autenticação sem fio. Métodos EAP nus que usam senha a expõem, ou ao menos expõem um desafio-resposta atacável offline, a qualquer um no alcance do rádio; um certificado para cada cliente, a resposta do EAP-TLS, era mais administração do que a maioria das organizações aceitava. A resposta do PEAP foi emprestar o TLS para a primeira metade da conversa. O draft, draft-josefsson-pppext-eap-tls-eap-10 de 15 de outubro de 2004, intitulado Protected EAP Protocol (PEAP) Version 2 e escrito por Palekar, Simon, Salowey, Zhou, Zorn e Josefsson, descreve duas partes. Na parte um o servidor responde ao par com um PEAP/Start, segue-se um handshake TLS com suítes baseadas em certificado, e o servidor é autenticado pelo seu certificado; o par pode ou não apresentar um. Na parte dois, dentro do túnel que o handshake produziu, rodam zero ou mais métodos EAP. Na prática o método interno é quase sempre o EAP-MSCHAPv2, e por isso a combinação se escreve PEAP-MSCHAPv2 e se encaixa tão naturalmente num domínio Windows.
O draft declara os objetivos sem rodeios: o PEAPv2 usa TLS para proteger contra autenticadores impostores, proteger contra ataques à confidencialidade e à integridade da troca do método EAP interno e oferecer privacidade de identidade ao par. A privacidade importa porque a troca de Identity que abre toda conversa 802.1X acontece antes de existir túnel: a identidade externa vai em claro, e o PEAP permite que ela seja um valor de fachada, com o nome de usuário real revelado só dentro do túnel. O draft também torna obrigatório o Crypto-Binding TLV, uma construção que prova aos dois lados que o par que concluiu o método interno é o mesmo que construiu o túnel externo; sem essa amarração, métodos tunelados ficam abertos a um intermediário que rode o método interno com a vítima e o túnel externo com o servidor.
O status do documento merece registro exato. A especificação é um Internet-Draft expirado; o PEAP chegou à ubiquidade por implementações, acima de tudo o suplicante do Windows e os produtos de servidor que o acompanharam, e não por um padrão publicado, e a versão mais implantada não é a que o draft descreve como versão 2. Para quem opera, a consequência é que os detalhes de interoperabilidade vivem na documentação dos fabricantes e nos testes, não numa RFC que se possa citar contra um fornecedor.
A segurança do PEAP é quase inteiramente uma questão de configuração do cliente. O túnel protege a troca interna apenas contra quem está fora dele; se o suplicante aceita qualquer certificado de servidor, o túnel pode ser terminado por um ponto de acesso impostor, e a troca MSCHAPv2 interna, desafio e resposta, é entregue ao atacante, que a ataca offline. Todo suplicante tem, por isso, uma configuração para validar o certificado do servidor, em geral com uma lista de autoridades certificadoras confiáveis e um nome de servidor esperado, e a diferença entre uma implantação PEAP segura e uma oportunidade de colheita de credenciais é se essa configuração é imposta, por política, em todos os dispositivos. Dispositivos fora da gestão, celulares pessoais entrando no SSID corporativo, são onde ela mais fica desligada, e também são os dispositivos cujos usuários clicam em qualquer aviso.
Entre os irmãos, o PEAP fica entre o EAP-TLS, que autentica o cliente com certificado e não tem senha a roubar, e o EAP-TTLS, que também constrói um túnel TLS mas admite métodos legados não EAP, como PAP e CHAP, dentro dele. O TEAP, o método de túnel em trilha de padrão da RFC 7170, foi escrito para substituir essa geração por uma que encadeia autenticação de usuário e de máquina e provisiona credenciais dentro do túnel. Onde o PEAP permanece, e ele permanece em quase todo lugar em que senhas são usadas para Wi-Fi, as questões de projeto são o método interno, o certificado no servidor e a validação nos clientes.
Também conhecido como: protected eap, peapv0, peap-mschapv2, peap mschapv2