Pelo que entendi, o EAP-TTLS e o PEAP compartilham o mesmo nível de segurança quando implementados em redes sem fio. Ambos fornecem apenas autenticação do lado do servidor via certificado.

A desvantagem do EAP-TTLS pode ser o suporte não nativo no Microsoft Windows, portanto, todo usuário precisa instalar software adicional.

O benefício do EAP-TTLS pode ser o suporte a mecanismos de autenticação menos seguros (PAP, CHAP, MS-CHAP), mas por que você precisaria deles em um sistema sem fio moderno e adequadamente seguro?

Quais são suas opiniões? Por que devo implementar o EAP-TTLS em vez do PEAP? Digamos que eu tenho a maioria dos usuários do Windows, usuários médios do Linux e menos usuários do iOS e OSX.

Você pode suportar ambos, se o seu back-end RADIUS suportar. No entanto, alguns clientes se conectam "automaticamente" (Mac OS X> = 10.7 + iOS, por exemplo), e eles podem funcionar abaixo do ideal se você oferecer suporte a mais de um tipo, pois eles apenas tentam combinações diferentes até que um deles funcione, ou seja, eles se conectam com menos problemas se houver apenas uma maneira de se conectar.

Então, basicamente: suporte apenas PEAP ou PEAP + TTLS se você tiver clientes que exigem TTLS.

Restrições de cliente

• clientes iOS não vai apoiar EAP-TTLScom PAP(apenas MsCHAPv2) a menos que você manualmente (através de um computador) instalar um perfil.

• Os clientes Windows não oferecem suporte EAP-TTLSimediato (você precisará instalar um software como secure2w), a menos que possuam placas sem fio Intel.

• O Android suporta quase todas as combinações de EAPe PEAP.

Restrições de banco de dados de senha

Assim, o verdadeiro problema é como suas senhas são armazenadas.

Se eles estão em:

• Active Directory , você pode usar EAP-PEAP-MsCHAPv2(caixas do Windows) e EAP-TTLS-MsCHAPv2(com clientes iOS).

• Se você armazenar senhas no LDAP , poderá usar EAP-TTLS-PAP(caixas do Windows), mas ficará perdido com o iOS.

Preocupações importantes de segurança

• Ambos EAP-TTLSe PEAPuse TLS(Transport Layer Security) sobre EAP(Extensible Authentication Protocol).

Como você deve saber, TLSé uma versão mais recente SSLe funciona com base em certificados assinados por uma autoridade central confiável (Autoridade de Certificação - CA).

Para estabelecer um TLSencapsulamento, o cliente deve confirmar que está falando com o servidor correto (nesse caso, o servidor radius usado para autenticar usuários). Faz isso verificando se o servidor apresentou um certificado válido, emitido por uma CA confiável.

O problema é: normalmente, você não terá um certificado emitido por uma CA confiável, mas um emitido por uma CA ad-hoc que você criou apenas para esse fim. O sistema operacional reclamará com os usuários que não sabe que a CA e os usuários (conforme orientado por você) aceitarão com satisfação isso.

Mas isso representa um grande risco de segurança:

Alguém pode configurar um ponto de acesso não autorizado na sua empresa (em uma bolsa ou até em um laptop), configurá-lo para conversar com seu próprio servidor radius (executando em seu laptop ou no próprio ponto de acesso não autorizado).

Se seus clientes acharem que este ponto de acesso possui um sinal mais forte que seus pontos de acesso, eles tentarão se conectar a ele. Verá uma CA desconhecida (os usuários aceitam), estabelecerá um TLStúnel, enviará informações de autenticação nesse túnel e o raio do invasor o registrará.

Agora a parte importante: se você estiver usando um esquema de autenticação de texto sem formatação ( PAPpor exemplo), o servidor do rogue radius terá acesso às senhas dos usuários.

Você pode resolver isso usando um certificado válido emitido por uma autoridade de certificação, tanto no iOS quanto no Windows (e no Android). Ou, você pode distribuir o certificado raiz da CA para seus usuários e informá-los a recusar a conexão quando encontrarem problemas de certificado (boa sorte com isso).

PEAPv0, PEAPv1 e TTLS têm as mesmas propriedades de segurança.

O PEAP é um wrapper SSL em torno do EAP que leva o EAP. TTLS é um wrapper SSL em torno de TLVs de diâmetro que carrega atributos de autenticação RADIUS.

O EAP-TTLS-PAP pode ser útil no EAP-PEAP se as credenciais de armazenamento do banco de dados de autenticação de back-end em um formato de hash não reversível, como bigcrypt ou qualquer formato não compatível com MSCHAP (NT-OWF), não for possível autenticar usando qualquer um dos métodos baseados em CHAP.

Embora você também possa emular o PAP usando o EAP-PEAPv1-GTC, isso não é tão amplamente suportado pelos clientes.

O PEAP adicionou alguma bagagem sobre o TTLS na forma de dores de cabeça de negociação da versão PEAP e incompatibilidades históricas no PEAPv1 (como a mágica do cliente ao derivar a chave mestre do PRF), que chegaram às implementações iniciais.

Normalmente, vejo o EAP-TTLS implementado em clientes incorporados, como módulos de assinante em equipamentos sem fio com PEAP usados ​​mais por laptops e celulares.

Historicamente, o EAP-TTLS não é suportado em clientes Windows sem a necessidade de instalar software de terceiros. O EAP-TTLS agora é suportado a partir do Windows 8.

Algumas reflexões adicionais:

O EAP-TTLS foi inventado por um fornecedor RADIUS. O EAP-PEAPv0 foi inventado pela Microsoft. O EAP-PEAPv1 saiu do processo da IETF.

Houve algum trabalho adicional da IETF em um PEAPv2 que tornaria o sistema mais seguro por meio de ligações criptográficas aos métodos de autenticação interna. Isso não foi tão longe quanto eu posso dizer.

Como o comedor de disco escreveu, a principal razão pela qual as pessoas usam o TTLS é que você pode permitir que o servidor radius veja a senha de texto não criptografado dessa maneira, o que pode ser útil dependendo do seu back-end de autenticação.

Uma consideração mais recente que pode favorecer o PEAP é que o SoH é o AFAICT apenas apresentado ao servidor RADIUS se solicitado, e a única maneira de solicitá-lo nos sistemas Microsoft é durante uma sessão do PEAP. Portanto, se você deseja obter uma avaliação semelhante a um agente a partir de uma avaliação sem agente (suporte provavelmente a mais fornecedores de antivírus), você desejará o PEAP, no entanto, se estiver procurando contornar um back-end OAUTH de um fator usando uma senha simples (porque caramba, os grandes deslocados internos que não fornecerão um serviço de túnel interno merecem nada menos e seus usuários não têm noção suficiente para digitá-lo) usam TTLS.

Você deve considerar quais métodos EAP o cliente oferece suporte nativo versus software adicional e quais métodos de autenticação interna o servidor suporta.

O PEAP e o EAP-TTLS foram projetados para permitir a validação da identificação do servidor, mas você deve garantir que os clientes estejam configurados corretamente para validar o certificado.

O PEAP e o MS-CHAPv2 são bem suportados pelos clientes, mas se o seu servidor não suportar o MS-CHAPv2 (porque você não armazena senhas em texto não criptografado), é necessário criar outra solução. Essa é a principal razão pela qual você verá as pessoas usarem EAP-TTLS e PAP.

Eu acho que a conexão automática se beneficiaria das duas opções, quanto mais opções, menos problemas ... por exemplo. se a conexão automática tentar primeiro o TTLS-PAP e depois o PEAP-MSCHAP, a conexão automática será mais rápida com o TTLS-PAP disponível. Então, basicamente: apóie os dois, não vejo uma desvantagem.

Como a segurança do MSCHAPs está corrompida (google para "crack mschap"), pap com senha de texto não criptografado por meio de ttls tem o mesmo nível de segurança que o PEAP-MSCHAP.

Não conheço nenhuma diferença de segurança entre o EAP-TTLS e o PEAP, por isso tudo se resume ao suporte, onde o PEAP é o vencedor.