EAP-TTLS
siglaSignifica: EAP Tunneled Transport Layer Security (RFC 5281, EAP Type 21)
O EAP Tunneled TLS da RFC 5281, EAP Type 21: um túnel TLS autenticado pelo servidor, dentro do qual o cliente pode se autenticar com quase qualquer coisa, inclusive PAP, CHAP, MS-CHAP e MS-CHAP-V2, além de outro método EAP.
A RFC 5281 (Funk e Blake-Wilson, agosto de 2008, Informational) especifica o EAP-TTLSv0 em duas fases: uma fase de handshake em que o servidor é autenticado por TLS e uma fase de dados em que o cliente é autenticado dentro do túnel por um mecanismo de autenticação arbitrário, que pode ser EAP ou um protocolo legado como PAP, CHAP, MS-CHAP ou MS-CHAP-V2. Essa é a diferença para o PEAP, que só carrega EAP dentro do túnel: o EAP-TTLS consegue atender um RADIUS ou um diretório de retaguarda que só sabe conferir uma senha simples, porque o PAP dentro do túnel entrega a senha ao servidor numa forma que ele consegue verificar contra qualquer base. A RFC admite autenticação unilateral, o servidor por certificado e o cliente por senha, e orienta o cliente a não incluir o nome real do usuário na identidade externa, usando um valor em branco ou anônimo para que a identidade só seja revelada dentro do túnel. O servidor TTLS pode, ele mesmo, encaminhar a autenticação interna ao servidor AAA de origem do usuário, que é como as federações de roaming funcionam entre domínios administrativos. Como em todo método tunelado, o cliente precisa validar o certificado do servidor ou o túnel não protege nada.
O EAP-TTLS foi escrito para as retaguardas de autenticação que as empresas realmente tinham: diretórios e servidores RADIUS capazes de verificar uma senha simples, ou um desafio-resposta legado, mas incapazes de rodar um método EAP. A RFC 5281, publicada em agosto de 2008 por Funk e Blake-Wilson como documento Informational, especifica o EAP-TTLSv0 no EAP Type 21 e descreve uma troca em duas fases. A fase de handshake é uma negociação TLS em que o servidor se autentica perante o cliente com um certificado e os dois derivam chaves; o cliente pode apresentar certificado também, mas a RFC admite explicitamente a autenticação unilateral do servidor. A fase de dados roda então dentro do túnel, onde o cliente se autentica com um mecanismo arbitrário: segundo a RFC, ele pode ser o próprio EAP ou um protocolo legado como PAP, CHAP, MS-CHAP ou MS-CHAP-V2.
Essa frase é a distinção prática entre EAP-TTLS e PEAP. O PEAP tunela EAP e somente EAP, então a troca interna tem de ser um método EAP como o EAP-MSCHAPv2, e a retaguarda tem de suportar o que esse método exige. O EAP-TTLS com PAP dentro do túnel entrega ao servidor a própria senha, protegida pelo TLS no caminho, e o servidor pode verificá-la contra qualquer coisa, inclusive um diretório que guarda senhas numa forma que só um bind simples confere. É por isso que EAP-TTLS/PAP é a recomendação usual quando a base de usuários é um diretório LDAP sem os hashes de que o MSCHAPv2 precisa, e por isso ele aparece tanto em universidades e federações.
A RFC leva a privacidade de identidade a sério. A troca de Identity do EAP precede o túnel e é visível a quem escuta, então a identidade externa não deve incluir o nome real do usuário; o cliente deve enviar um nome em branco ou a palavra anonymous, mantendo a parte de realm necessária ao roteamento, e revelar a identidade real só na fase de dados. O roteamento é o outro recurso que fez do EAP-TTLS um protocolo de federação: o servidor TTLS que termina o túnel não precisa ter a credencial do usuário. Ele pode atuar como proxy, encaminhando a autenticação interna ao servidor AAA de origem do realm do usuário, de modo que a senha de um visitante seja conferida pela própria instituição dele enquanto a rede visitada só fica sabendo que a resposta foi sim.
As ressalvas de segurança são as de todo método tunelado. O túnel só é tão confiável quanto a verificação do certificado do servidor pelo cliente; um suplicante que aceita qualquer certificado constrói seu túnel com um impostor e entrega a credencial interna, que no caso do PAP é a senha em claro dentro do túnel do atacante. O método legado interno não acrescenta segurança, só herda a do túnel, de modo que o certificado do servidor, a âncora de confiança no cliente e o nome de servidor esperado são os controles que importam. E como o método interno pode ser tão fraco quanto o PAP, o lado servidor não pode expor a credencial interna a nada fora do ponto de terminação do TLS: o trajeto de retaguarda do servidor TTLS até o diretório é um segundo lugar em que uma senha pode ser vista.
Na árvore da família, o EAP-TTLS fica ao lado do PEAP como o segundo dos métodos tunelados de senha, com o EAP-FAST e depois o TEAP (RFC 7170) como a geração seguinte, que acrescentou provisionamento de credenciais e amarração criptográfica da troca interna ao túnel externo. Onde o cliente pode portar um certificado, o EAP-TLS tira a senha de cena; onde não pode, o EAP-TTLS é o método que deixa quase qualquer retaguarda participar.
Também conhecido como: ttls, eap-ttlsv0, tunneled tls