Como eu 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 para mecanismos de autenticação menos seguros (PAP, CHAP, MS-CHAP), mas por que você precisaria deles no 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 tenha mais usuários do Windows, usuários médios do Linux e menos usuários do iOS, OSX.
Você pode suportar ambos, se o seu back-end RADIUS for compatível. No entanto, alguns clientes "auto" -conexões (Mac OS X > = 10.7 + iOS por exemplo), e eles podem funcionar menos que o ideal se você suportar mais de um tipo, pois eles tentam combinações diferentes até que um deles funcione. conecte-se com menos problemas se houver apenas uma maneira de se conectar.
Então Basicamente: suporte somente PEAP, ou PEAP + TTLS se você tiver clientes que requerem TTLS.
O PEAPv0, o PEAPv1 e o TTLS têm as mesmas propriedades de segurança.
O PEAP é um wrapper SSL em torno do EAP que transporta o EAP. O TTLS é um wrapper SSL em torno de TLVs de diâmetro que transportam atributos de autenticação RADIUS.
EAP-TTLS-PAP pode ser útil sobre EAP-PEAP se as credenciais de armazenamento de banco de dados de autenticação de back-end em um formato de hash não reversível, como bigcrypt ou qualquer formulário não compatível com MSCHAP (NT-OWF) Nesse caso, não é possível para autenticar usando qualquer um dos métodos baseados em CHAP.
Embora você possa também emular o PAP usando o EAP-PEAPv1-GTC, isso não é amplamente suportado pelos clientes.
O PEAP tem alguma bagagem adicional 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 mestra do PRF) que foram implementadas com antecedência.
Normalmente, vejo o EAP-TTLS implementado em clientes integrados, como módulos de assinante em equipamentos sem fio, com o PEAP mais usado por laptops e telefones celulares.
O EAP-TTLS historicamente 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 ideias adicionais:
O EAP-TTLS foi inventado por um fornecedor RADIUS. O EAP-PEAPv0 foi inventado pela Microsoft. EAP-PEAPv1 saiu do processo da IETF.
Havia algum trabalho adicional do IETF em um PEAPv2 que tornaria o sistema mais seguro por meio de ligações de criptografia para métodos de autenticação interna. Isso não foi tão longe quanto eu posso dizer.
clientes iOS não suportam EAP-TTLS com PAP (apenas MsCHAPv2 ), a menos que você manualmente (por meio de um computador) instale um perfil.
Os clientes Windows não suportam EAP-TTLS pronto (você precisará instalar um software como o secure2w), a menos que eles tenham placas sem fio Intel.
O Android suporta quase todas as combinações de EAP e PEAP .
Assim, o problema real é como suas senhas são armazenadas.
Se eles estiverem em:
Diretório Ativo , 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 perderá o iOS.
EAP-TTLS e PEAP use TLS (Segurança da Camada de Transporte) acima de EAP (Protocolo de Autenticação Extensível). Como você deve saber, TLS é uma versão mais recente de SSL e funciona com base em certificados assinados por uma autoridade central confiável (autoridade de certificação - CA).
Para estabelecer um túnel TLS , o cliente deve confirmar que está falando com o servidor correto (nesse caso, o servidor radius usado para autenticar usuários). Ele faz isso verificando se o servidor apresentou um certificado válido, emitido por uma autoridade de certificação confiável.
O problema é: normalmente, você não terá um certificado emitido por uma CA confiável, mas um certificado emitido por uma CA ad-hoc feita apenas para essa finalidade. O sistema operacional reclamará aos usuários que ele 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 AP não autorizado dentro de sua empresa (em uma bolsa ou até mesmo em um laptop), configurá-lo para falar com seu próprio servidor radius (rodando em seu laptop ou no próprio AP não autorizado).
Se os seus clientes acharem que este AP tem um sinal mais strong que os seus pontos de acesso, eles tentarão se conectar a ele. Verá uma CA desconhecida (os usuários aceitam), estabelecerá um túnel TLS , enviará informações de autenticação neste túnel e o raio não autorizado irá registrá-lo.
Agora, a parte importante: se você estiver usando um esquema de autenticação de texto simples ( PAP , por exemplo), o servidor rogue radius terá acesso às senhas de seus usuários.
Você pode resolver isso usando um certificado válido emitido por uma Autoridade de Certificação, seja iOS, Windows (e Android). Ou, você pode distribuir o certificado raiz da CA para seus usuários e informá-los a recusar a conexão quando virem problemas de certificado (boa sorte com isso).
Como o Comedor de Disco escreveu, a principal razão pela qual as pessoas usam o TTLS é que você pode permitir que seu servidor radius veja a senha do texto não criptografado dessa maneira, o que pode ser útil dependendo do backend de autenticação.
Uma consideração mais recente que pode favorecer o PEAP é que SoH é AFAICT apresentado apenas ao servidor RADIUS se ele solicitar, e a única maneira de solicitá-lo nos sistemas da Microsoft é durante uma sessão PEAP. Portanto, se você deseja obter uma avaliação sem agente da avaliação sem agente (suporte de mais fornecedores de antivírus provavelmente futuros), você deseja PEAP, no entanto, se estiver procurando um back-end de 1 fator OAUTH usando uma senha nua (porque diabos, os grandes IDPs que não fornecerão um serviço de túnel interno não merecem menos e seus usuários não sabem o suficiente para digitá-lo) use o TTLS.
Você deve considerar quais métodos EAP o cliente suporta nativamente versus software adicional e quais métodos de autenticação interna o servidor suporta.
O PEAP e o EAP-TTLS são projetados para permitir que você valide a identificação do servidor, mas é necessário certificar-se de 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 suporta o MS-CHAPv2 (porque você não armazena senhas em texto puro), você precisa criar outra solução. Essa é a principal razão pela qual você verá pessoas usando EAP-TTLS e PAP.
Acho que a conexão automática beneficiaria as duas opções, quanto mais opções, menos complicações ... 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: apoiar ambos, não vejo uma desvantagem.
Desde que a segurança MSCHAPs está quebrada (google para "crack mschap") pap com senha de texto simples através de ttls tem o mesmo nível de segurança que PEAP-MSCHAP.
Eu não sei de nenhuma diferença na segurança entre o EAP-TTLS e o PEAP, então basicamente se trata de suporte, onde o PEAP é o vencedor.