Como entendí, EAP-TTLS y PEAP comparten el mismo nivel de seguridad cuando se implementan en redes inalámbricas. Ambos solo proporcionan autenticación del lado del servidor mediante certificado.

El inconveniente de EAP-TTLS puede ser el soporte no nativo en Microsoft Windows, por lo que cada usuario debe instalar software adicional.

El beneficio de EAP-TTLS puede ser la compatibilidad con mecanismos de autenticación menos seguros (PAP, CHAP, MS-CHAP), pero ¿por qué los necesitaría en un sistema inalámbrico moderno y adecuadamente seguro?

Cuales son tus opiniones ¿Por qué debería implementar EAP-TTLS en lugar de PEAP? Digamos que tengo la mayoría de los usuarios de Windows, usuarios de Linux medianos y menos usuarios de iOS, OSX.

Puede admitir ambos, si su backend RADIUS lo admite. Sin embargo, algunos clientes se conectan "automáticamente" (Mac OS X> = 10.7 + iOS, por ejemplo), y podrían funcionar de manera no óptima si admite más de un tipo, ya que solo prueban diferentes combinaciones hasta que una de ellas funciona, es decir, se conectan con menos problemas si solo hay una forma de conectarse.

Básicamente: solo admite PEAP o PEAP + TTLS si tiene clientes que requieren TTLS.

Restricciones del cliente

• clientes de iOS no apoyarán EAP-TTLScon PAP(sólo MsCHAPv2) a menos que manualmente (a través de un ordenador) instalar un perfil.

• Los clientes de Windows no serán compatibles de EAP-TTLSinmediato (necesitará instalar un software como secure2w), a menos que tengan tarjetas inalámbricas Intel.

• Android admite casi todas las combinaciones de EAPy PEAP.

Restricciones de la base de datos de contraseñas

Por lo tanto, el verdadero problema es cómo se almacenan sus contraseñas.

Si están en:

• Active Directory , luego puede usar EAP-PEAP-MsCHAPv2(cuadros de Windows) y EAP-TTLS-MsCHAPv2(con clientes iOS)

• Si almacena contraseñas en LDAP , puede usar EAP-TTLS-PAP(cajas de Windows) pero se perderá con iOS.

Importantes preocupaciones de seguridad

• Ambos EAP-TTLSy PEAPusar TLS(Seguridad de la capa de transporte) sobre EAP(Protocolo de autenticación extensible).

Como ya sabrás, TLSes una versión más nueva SSLy funciona basada en certificados firmados por una autoridad central de confianza (Autoridad de Certificación - CA).

Para establecer un TLStúnel, el cliente debe confirmar que está hablando con el servidor correcto (en este caso, el servidor de radio utilizado para autenticar a los usuarios). Lo hace comprobando si el servidor presentó un certificado válido, emitido por una CA de confianza.

El problema es: normalmente, no tendrá un certificado emitido por una CA confiable, sino uno emitido por una CA ad-hoc que haya hecho solo para este propósito. El sistema operativo se quejará ante los usuarios de que no sabe que CA y los usuarios (según lo ordene usted) lo aceptarán con gusto.

Pero esto plantea un importante riesgo de seguridad:

Alguien puede configurar un AP falso dentro de su negocio (en una bolsa o incluso en una computadora portátil), configurarlo para hablar con su propio servidor de radio (que se ejecuta en su computadora portátil o en el propio AP falso).

Si sus clientes encuentran que este AP tiene una señal más fuerte que sus puntos de acceso, intentarán conectarse a él. Verá una CA desconocida (los usuarios aceptan), establecerá un TLStúnel, enviará información de autenticación en este túnel y el radio no autorizado lo registrará.

Ahora la parte importante: si está utilizando un esquema de autenticación de texto sin formato ( PAPpor ejemplo), el servidor de radio falso tendrá acceso a las contraseñas de sus usuarios.

Puede resolver eso utilizando un certificado válido emitido por una Autoridad de Certificación de confianza tanto para iOS como para Windows (y Android). O bien, puede distribuir el certificado raíz de CA a sus usuarios e informarles que rechacen la conexión cuando vean problemas con el certificado (buena suerte con eso).

PEAPv0, PEAPv1 y TTLS tienen las mismas propiedades de seguridad.

PEAP es un contenedor SSL alrededor de EAP que lleva EAP. TTLS es un contenedor SSL de TLV de diámetro que lleva atributos de autenticación RADIUS.

EAP-TTLS-PAP puede ser útil sobre EAP-PEAP si las credenciales de la base de datos de autenticación de back-end en un formato hash no reversible como bigcrypt o cualquier forma no compatible con MSCHAP (NT-OWF) En este caso no es posible autenticarse usando cualquiera de los métodos basados ​​en CHAP.

Si bien también podría emular PAP utilizando EAP-PEAPv1-GTC, los clientes no lo admiten tanto.

PEAP tiene algo de equipaje adicional sobre TTLS en forma de dolores de cabeza de negociación de versiones de PEAP e incompatibilidades históricas en PEAPv1 (como la magia del cliente al derivar la clave maestra de PRF) que se han abierto paso en implementaciones tempranas.

Normalmente veo EAP-TTLS implementado en clientes integrados, como módulos de suscriptores en equipos inalámbricos con PEAP más utilizado por computadoras portátiles y teléfonos móviles.

Históricamente, EAP-TTLS no ha sido compatible con clientes Windows sin tener que instalar software de terceros. EAP-TTLS ahora es compatible a partir de Windows 8.

Algunos pensamientos adicionales:

EAP-TTLS fue inventado por un proveedor de RADIUS. EAP-PEAPv0 fue inventado por Microsoft. EAP-PEAPv1 salió del proceso IETF.

Hubo algún trabajo adicional de IETF en un PEAPv2 que habría hecho que el sistema fuera más seguro mediante enlaces criptográficos a los métodos de autenticación interna. Esto no ha ido a ningún lado tan cerca como puedo ver.

Como escribió Disk Eater, la razón principal por la que las personas usan TTLS es que puede permitir que su servidor de radio vea la contraseña de texto claro de esa manera, lo que puede ser útil dependiendo de su backend de autenticación.

Una consideración más reciente que podría favorecer PEAP es que SoH es AFAICT solo presentado al servidor RADIUS si lo solicita, y la única forma de solicitarlo en los sistemas Microsoft es durante una sesión PEAP. Por lo tanto, si desea obtener una evaluación similar a la de un agente sin la evaluación de un agente (probablemente habrá más proveedores de AV de próxima aparición), querrá PEAP, sin embargo, si está buscando evitar un back-end OAUTH de 1 factor tomando una contraseña desnuda (porque diablos, los grandes IDP que no proporcionarán un servicio de túnel interno no merecen menos y sus usuarios no tienen ni idea de cómo escribirlo) usan TTLS.

Debe tener en cuenta qué métodos EAP admite el cliente de forma nativa frente a software adicional y qué métodos de autenticación interna admite el servidor.

PEAP y EAP-TTLS están diseñados para permitirle validar la identificación del servidor, pero debe asegurarse de que los clientes estén configurados correctamente para validar el certificado.

PEAP y MS-CHAPv2 están bien soportados por los clientes, pero si su servidor no es compatible con MS-CHAPv2 (porque no almacena contraseñas de texto sin formato), debe encontrar otra solución. Esa es la razón principal por la que verá que las personas usan EAP-TTLS y PAP.

Creo que la conexión automática se beneficiaría de ambas opciones, cuantas más opciones menos problemas ... por ejemplo. si la conexión automática intenta TTLS-PAP primero y luego PEAP-MSCHAP, la conexión automática es más rápida con TTLS-PAP disponible. Básicamente: admite ambos, no puedo ver una desventaja.

Dado que la seguridad de MSCHAP está rota (google para "crack mschap"), pap con contraseña de texto claro a través de ttls tiene el mismo nivel de seguridad que PEAP-MSCHAP.

No conozco ninguna diferencia de seguridad entre EAP-TTLS y PEAP, por lo que básicamente se trata de soporte, donde PEAP es el ganador.