EAP-TLS
termoSignifica: EAP Transport Layer Security (RFC 5216, EAP Type 13)
Autenticação sem fio e cabeada usando certificados dos dois lados, em vez de senha compartilhada.
A RFC 5216 (Simon, Aboba e Hurst, da Microsoft, março de 2008, trilha de padrão, tornando obsoleta a RFC 2716) especifica o EAP-TLS no EAP Type 13: um handshake TLS carregado em pacotes EAP, em que o servidor apresenta um certificado, o cliente apresenta outro e ambos derivam material de chave; a RFC define a fragmentação com um bit L (um TLS Message Length de quatro octetos vai incluído) e um bit M (há mais fragmentos), porque um handshake com certificados não cabe num único pacote EAP lock-step. As chaves exportadas seguem uma receita fixa, a função pseudoaleatória do TLS sobre o master secret com o rótulo client EAP encryption e os dois valores aleatórios, com os primeiros 64 octetos como MSK e os 64 seguintes como EMSK. É a opção comum mais forte porque não há senha para compartilhar, afixar ou levar para um ex-empregador, e cada dispositivo se autentica como si mesmo. O custo é um ciclo de vida de certificado para cada ponta, que é a razão de implantações travarem. A configuração errada frequente merece nome: um cliente que não valida o certificado do servidor se autentica alegremente a um impostor, o que transforma a opção mais forte numa oportunidade de colheita de credenciais.
O EAP-TLS é o método pelo qual os outros métodos EAP são medidos, porque é o que remove a senha. A RFC 5216, publicada em março de 2008 por Simon, Aboba e Hurst, da Microsoft, como documento em trilha de padrão e tornando obsoleta a RFC 2716, o especifica no EAP Type 13. O método é um handshake TLS carregado dentro de pacotes EAP Request e Response: o servidor apresenta seu certificado, o cliente apresenta o seu, cada um verifica o outro contra suas âncoras de confiança, e o resultado do handshake é material de chave para o enlace. A RFC o descreve como provendo autenticação mútua baseada em certificado e derivação de chave, e essa combinação, os dois lados provando identidade com certificado e uma chave saindo da troca, é o que faz dele a opção mais forte da família e a única em que não existe um segredo que um humano possa escrever num papel colado no monitor.
A mecânica tem um traço que todos os outros métodos baseados em TLS herdaram. O EAP é um protocolo lock-step de pacotes pequenos, e um handshake TLS carregando certificados e cadeias não é pequeno, então a RFC 5216 define a fragmentação: um octeto de flags com um bit L, significando que um campo TLS Message Length de quatro octetos está presente, e um bit M, significando que há mais fragmentos, com quem recebe um fragmento respondendo, nas palavras da RFC, com EAP-Type=EAP-TLS e sem dados. Dezenas de idas e vindas entre suplicante, switch e servidor RADIUS são normais, e um enlace lento ou com perda entre o switch e o servidor aparece como tempo esgotado de autenticação muito antes de aparecer como qualquer outra coisa. Concluído o handshake, o material de chave é exportado por uma receita fixa: a função pseudoaleatória do TLS sobre o master secret com o rótulo client EAP encryption e os valores aleatórios de cliente e servidor, produzindo 128 octetos dos quais os primeiros 64 são a Master Session Key e os 64 seguintes a Extended Master Session Key. O uso dessas chaves, diz a RFC, é específico da camada inferior; no Wi-Fi corporativo essa camada inferior é a que cifra o enlace, e é assim que uma sessão autenticada por 802.1X ganha chaves próprias sem que ninguém as configure.
A força vem com um ciclo de vida. Toda ponta precisa de um certificado emitido para ela, uma chave privada guardada nela, renovação antes do vencimento e revogação quando o dispositivo é perdido ou aposentado, e o servidor precisa de um certificado em que os clientes confiem. Organizações com uma plataforma de gestão de dispositivos e uma autoridade certificadora capaz de inscrevê-los automaticamente acham isso rotina; organizações sem isso acham que é a razão de o projeto travar, e muitas vezes se acomodam num método tunelado de senha pelo caminho. A RFC 5216 também anota uma limitação de privacidade: um par configurado para manter sua identidade privada, retendo o certificado até o servidor ser autenticado, tipicamente não consegue se autenticar com um servidor que não suporta essa opção, de modo que a privacidade é um recurso a ser projetado nos dois lados.
A configuração errada que desfaz o método merece parágrafo próprio. A autenticação mútua só é mútua se o cliente confere o certificado do servidor contra uma autoridade confiável e um nome esperado. Um suplicante configurado para pular essa verificação completa o handshake com qualquer ponto de acesso que apresente um certificado e, embora o EAP-TLS não dê a um impostor nenhuma senha para roubar, dá a ele um cliente autenticado para prender numa rede hostil, e treina os usuários a aceitar o que aparecer. A configuração fica no cliente, é imposta por política de gestão e deveria ser verificada em cada classe de dispositivo que entra na rede, que é a mesma disciplina de que o PEAP e o EAP-TTLS precisam por uma razão mais perigosa.
Onde ele se encaixa: EAP-TLS para todo dispositivo que pode portar um certificado, o que hoje inclui notebooks, celulares e tablets sob gestão e uma parcela crescente de impressoras e controladores; TEAP onde máquina e usuário precisam ser provados juntos ou onde credenciais serão provisionadas dentro do túnel; PEAP e EAP-TTLS onde a retaguarda de senha é a restrição; MAB para os dispositivos que não conseguem fazer nada. O verbete 802.1X cobre o transporte, o verbete RADIUS o lado do servidor, e o artigo sobre 802.1X e métodos EAP põe as escolhas lado a lado.
Também conhecido como: 802.1x, certificate-based wi-fi, eap type 13, mutual tls wi-fi