Windows Wi-Fi com 802.1X + EAP-TTLS + EAP-MSCHAPv2 e certificados de cliente

0

Sooo ... Temos o requisito obrigatório de que os clientes que desejam ingressar em nossa LAN sem fio apresentem um certificado de máquina válido emitido por nossa CA raiz interna. Isso é feito para evitar que usuários mal-intencionados tenham uma combinação válida de nome de usuário / senha para ingressar na LAN sem fio. Afinal, é mais fácil obter uma combinação de nome de usuário / senha que um certificado válido.

Antes do Windows 8.x, usamos EAP-TLS como protocolo de autenticação externa para atender a esse requisito e usamos o protocolo de autenticação interna para validar o nome de usuário / senha em nosso AD.

Com o Windows 8.1, parece que o EAP-TLS não é mais suportado (pelo menos não pode ser configurado na GUI. Se eu estiver enganado aqui, forneça um link como é feito). Então comecei a experimentar com EAP-TTLS como protocolo de autenticação externa e EAP-MSCHAPv2 como protocolo de autenticação interna. Enquanto isso funciona, não consigo incluir um certificado de cliente durante a fase de handshake do TLS. Eu não posso encontrar uma maneira de dizer ao Windows para fazê-lo.

Estou certo em supor que NÃO HÁ NENHUM MODO de configurar o suplicante 802.1X nativo do Windows 8.1 para fornecer um certificado de cliente quando o EAP-TTLS for usado como protocolo de autenticação externo?

RFC 5281 declara explicitamente que a validação do certificado de cliente é suportada durante a fase 1, então não consigo ver por que a Microsoft teria omitiu uma opção na GUI para configurar isso.

    
por lightxx 10.04.2015 / 10:31

1 resposta

3

A GUI do Windows referiu-se tradicionalmente à autenticação EAP-TLS como "cartão inteligente ou outro certificado". Então talvez seja isso que você está procurando.

No entanto, esta parte da sua pergunta não faz muito sentido para mim:

Prior to Windows 8.x we used EAP-TLS as outer authentication protocol to satisfy this requirement and used the inner authentication protocol to validate username / password against our AD.

... porque, até onde sei, o EAP-TLS não fornece um protocolo de autenticação "interno". Então, eu estou querendo saber se talvez você usou EAP-TLS como seu único tipo 802.1X EAP e, em seguida, a autenticação de nome de usuário / senha que você lembra não fazia parte do 802.1X, mas talvez fizesse parte da autenticação em seu domínio do AD depois já eram totalmente autenticados por 802.1X e tinham conectividade de rede.

Até onde eu sei, somente PEAP e TTLS estabelecem um túnel seguro "externo" via autenticação simulada e então usam esse túnel para transportar com segurança uma transação de autenticação "interna". E mesmo o PEAP e o TTLS, para a autenticação externa, só fazem o TLS, mas pelo que me lembro apenas utilizo para verificar o autenticador (servidor AP ou AAA) e configurar o túnel criptografado. Não me lembro de nunca ter sido possível especificar um certificado de cliente para a autenticação TLS no exterior do PEAP ou TTLS.

Tanto o PEAP quanto o TTLS permitem tecnicamente o EAP-TLS como o mecanismo de autenticação interna, embora muitas implementações iniciais do TTLS não permitissem o EAP; eles permitiam somente os métodos de autenticação PPP pré-EAP: PAP, CHAP, MS-CHAP, MS-CHAP-V2. Pode ser que o suplicante nativo do Windows 8.1 802.1X seja um deles. Da mesma forma, algumas implementações PEAP suportam EAP-MS-CHAP-V2 e EAP-GTC como os tipos de autenticação internos e podem não suportar outros tipos de autenticação, como EAP-TLS como o tipo de autenticação interno. No entanto, o suplicante nativo do Windows 802.1X da Microsoft sempre suportou o EAP-TLS como o tipo de autenticação interno para o PEAP, eles tradicionalmente o rotularam como "cartão inteligente ou outro certificado".

Nunca é uma surpresa para mim quando um implementador ignora partes opcionais de uma especificação de protocolo ao implementar esse protocolo. Quase todas as RFCs que já li tiveram partes que nunca vi ninguém implementar. Portanto, não é surpresa que o suplicante 802.1X nativo do Windows da Microsoft não forneça uma maneira de oferecer um certificado TLS de cliente na autenticação externa do TTLS. Se você ler as especificações do TTLS, verá que, quando isso acontece, o TTLS acaba ignorando a autenticação interna, portanto, é basicamente apenas EAP-TLS nesse ponto. A Microsoft provavelmente imaginou que, como eles já suportavam o EAP-TLS, por que se preocupar com a implementação do modo EAP-TTLS que acaba sendo o mesmo que o EAP-TLS?

    
por 19.05.2015 / 10:04