EAP
siglaSignifica: Extensible Authentication Protocol (RFC 3748)
O Extensible Authentication Protocol da RFC 3748: um arcabouço de quatro códigos de pacote que transporta qualquer um de dezenas de métodos de autenticação entre um par e um autenticador, em geral sobre PPP ou Ethernet, sem precisar de IP.
O EAP não é um método de autenticação; é o envelope em que os métodos viajam. A RFC 3748 (junho de 2004) define quatro códigos, Request, Response, Success e Failure, e um octeto Type nos Requests e Responses que nomeia o método: 1 Identity, 2 Notification, 3 Nak, 4 MD5-Challenge, 5 One-Time Password, 6 Generic Token Card, 254 Expanded Types e 255 Experimental. Tudo o que uma empresa de fato implanta, EAP-TLS, PEAP, EAP-TTLS, EAP-FAST, TEAP, EAP-pwd, EAP-SIM e EAP-AKA, é um Type carregado dentro desse envelope. A RFC o chama de protocolo lock-step (um Request, um Response, sem paralelismo) que tipicamente roda diretamente sobre camadas de enlace como PPP ou IEEE 802, e é por isso que um dispositivo pode ser autenticado antes de ter endereço. O autenticador, um switch, um ponto de acesso ou um servidor discado, pode atuar como agente pass-through, repassando cada pacote EAP a um servidor de retaguarda dentro de atributos EAP-Message do RADIUS (RFC 3579) e agindo só sobre o Success ou Failure final. O 802.1X é EAP sobre LAN; o método lá dentro é uma decisão à parte, e a mais difícil de um projeto de Wi-Fi.
O Extensible Authentication Protocol foi escrito para que a camada de enlace não precisasse ser reescrita cada vez que alguém inventasse um jeito novo de provar identidade. A RFC 3748, publicada em junho de 2004 por Aboba, Blunk, Vollbrecht, Carlson e Levkowetz, tornando obsoleta a RFC 2284, define um pacote de quatro campos, Code, Identifier, Length e Data, e quatro códigos: 1 Request, 2 Response, 3 Success e 4 Failure. Requests e Responses carregam um octeto Type na primeira posição do campo Data, e é no Type que os métodos moram. O documento base atribui apenas os tipos de infraestrutura: 1 Identity, 2 Notification, 3 Nak (o jeito de o par dizer que não suporta o método proposto e listar os que suporta), 4 MD5-Challenge, 5 One-Time Password, 6 Generic Token Card, 254 Expanded Types para métodos de fabricante e 255 Experimental. Cada método que importa numa rede de hoje, EAP-TLS no Type 13, EAP-TTLS no 21, PEAP no 25, EAP-FAST no 43, EAP-pwd no 52, TEAP no 55, EAP-SIM no 18 e EAP-AKA no 23, é especificado num documento próprio e viaja nesse campo.
Duas propriedades do envelope explicam onde o EAP aparece. A RFC afirma que o EAP tipicamente roda diretamente sobre camadas de enlace como PPP ou IEEE 802, sem exigir IP, e essa é toda a razão de ele conseguir guardar uma porta de switch ou uma associação sem fio: o dispositivo ainda não tem endereço, talvez nunca tenha, e mesmo assim precisa ser identificado. E a RFC o descreve como um protocolo lock-step, um Request pendente por vez, cada um respondido por exatamente um Response, com retransmissão a cargo do autenticador e sem paralelismo. Essa simplicidade custa idas e vindas (um método baseado em TLS precisa de muitas) e é por isso que conversas EAP em enlaces lentos ou com perda parecem arrastadas, mas mantém a máquina de estados pequena o bastante para caber na CPU auxiliar de um ASIC de switch.
A terceira decisão de projeto é a que criou a indústria de AAA como ela existe. O autenticador, o equipamento a que o par está fisicamente ligado, não precisa entender o método. A RFC 3748 permite que ele atue como agente pass-through de um servidor de autenticação de retaguarda, e a RFC 3579 (Aboba e Calhoun, setembro de 2003) especifica como: o switch ou ponto de acesso encaminha cada pacote EAP a um servidor RADIUS encapsulado em atributos EAP-Message (tipo 79), e todo pacote RADIUS que carrega um EAP-Message precisa carregar também um atributo Message-Authenticator (tipo 80) para protegê-lo. Quando um pacote EAP é maior que um atributo, vários EAP-Message são colocados em ordem, consecutivos, e concatenados na outra ponta. O switch vê, portanto, uma conversa que não consegue ler entre o suplicante e o servidor, e age apenas sobre o Access-Accept ou Access-Reject final, que carrega o Success ou Failure do EAP. Trocar o método de autenticação num parque é uma mudança no servidor e nos clientes; as centenas de switches no meio não se importam.
Essa separação também é onde começam as discussões. Como os métodos são documentos independentes, eles diferem no que protegem: o MD5-Challenge (Type 4, na própria RFC base) é um desafio-resposta nu cujas alegações de segurança a RFC lista como autenticação mútua não e derivação de chave não, o que o exclui de qualquer enlace que precise de chaves vindas da autenticação, como um enlace sem fio precisa; os métodos baseados em TLS autenticam o servidor com certificado e derivam material de chave; os métodos tunelados (PEAP, EAP-TTLS, EAP-FAST, TEAP) rodam uma troca legada mais fraca dentro de um túnel TLS para que uma senha possa ser usada sem ser exposta ao ar. A consequência prática para quem projeta é que dizer "usamos 802.1X" não diz nada sobre segurança até que o método seja nomeado, e que a falha comum das implantações, um cliente que não valida o certificado do servidor dentro do método escolhido, é uma configuração do método que o arcabouço não tem como impor.
Os verbetes de cada método neste glossário carregam seus próprios fatos de RFC: o EAP-TLS e seu certificado dos dois lados, o PEAP e seu draft expirado, o EAP-TTLS e os métodos legados dentro dele, o EAP-FAST e a Protected Access Credential, o TEAP e seu encadeamento, o EAP-pwd e sua troca só com senha, o EAP-SIM e o EAP-AKA e o SIM da operadora. O verbete 802.1X cobre o transporte em LAN (EAPOL), e o verbete RADIUS cobre o outro lado do pass-through.
Também conhecido como: extensible authentication protocol, eap method, eap methods, eapol, eap over lan