¿Es posible que una red 802.1x (PEAP / MSCHAPv2) no tenga certificado?

  

¿Es posible que una red 802.1x (PEAP / MSCHAPv2) no tenga certificado (CA, usuario u otro)?

PEAP / MSCHAPv2 no suele utilizar certificados de cliente, ni tampoco utiliza directamente certificados de CA para establecer una conexión TLS (* ver más abajo). Sin embargo, ciertamente requiere el uso de un certificado de servidor (PEAP es un protocolo EAP tunelizado TLS).

  

Si es así, ¿cuáles son las implicaciones de seguridad?

La imagen que proporcionó indica que es probable que esté usando alguna forma de * nix que le ofrezca dos opciones de certificado.

Primero, al abordar la segunda opción (certificado de cliente), la gran mayoría de los usuarios que se conectan a una red inalámbrica con PEAP / MSCHAPv2 nunca necesitarán este campo (he configurado / implementado miles de AP en numerosos entornos y nunca he visto esto utilizado personalmente).

La opción importante es la primera, el campo de certificado de CA. ¿Por qué? Porque esto ayuda a reducir significativamente la posibilidad de conectarse a una red inalámbrica falsa o fraudulenta que trata de hacerse pasar por la que desea conectar.

Esto plantea la pregunta de cómo ayuda el certificado de CA. Tenga en cuenta que, antes de la autenticación exitosa en la red, su cliente no tiene acceso a la red ni a los recursos en ella. El AP o el controlador inalámbrico que actúa como NAS (servidor de acceso a la red) está procesando la conexión desde el dispositivo suplicante de EAP al servidor de autenticación RADIUS. El certificado de CA se está utilizando para ayudar a validar la identidad del servidor de autenticación RADIUS en el que se autentica su suplicante EAP.

En términos generales, el suplicante de EAP debe tomar una decisión sobre si enviará su nombre de usuario / contraseña al servidor de autenticación sin estar conectado a la red. Esto significa que solo puede trabajar con la información que tiene y la información que le proporciona el servidor de autenticación, no puede salir a Internet para verificar otra fuente hasta que se haya autenticado y sea demasiado tarde para retener su nombre de usuario / contraseña.

El suplicante de EAP hace esto principalmente al verificar dos cosas (con un par de opciones presentes en muchos suplicantes de EAP como Windows y OSX, pero a menudo no en dispositivos móviles como tabletas y teléfonos):

1. ¿El certificado proporcionado por el servidor de autenticación es un certificado válido emitido por una CA que el dispositivo cliente confía en él?
2. (Opcional) ¿Se emite el certificado de las CA designadas en el suplicante de EAP?
3. ¿El nombre de host listado en el certificado coincide con el nombre de host proporcionado por el servidor de autenticación?
4. (Opcional) ¿Es el nombre de host dado por el servidor de autenticación uno de los nombres de host permitido en la configuración del suplicante EAP?

Las otras opciones para el suplicante de EAP son hacer que el sistema operativo le pida al usuario que "verifique y apruebe" el certificado (mala idea) o que no valide el certificado en absoluto (peor idea) antes de enviar su nombre de usuario / contraseña.

Por lo tanto, proporcionar el certificado de CA en la configuración de suplicante de EAP lo ayudará a usar el # 2 anterior para validar la identidad del servidor RADIUS además del # 1 y el # 3. Debe poder obtener la información y / o el certificado de CA correctos de su departamento de TI.

Nota: partes de esta respuesta se copiaron de otra de mis respuestas .

Desde cisco wesite puede leer ( enlace ):

  

PEAP se basa en el lado del servidor EAP- autenticación TLS. Con PEAP muchos   Las organizaciones pueden evitar los problemas asociados con la instalación de dispositivos digitales.   certificados en cada dispositivo cliente como lo requiere EAP-TLS; en lugar,   Pueden seleccionar los métodos de autenticación del cliente, como el inicio de sesión.   Contraseñas u OTP que mejor se adapten a sus necesidades corporativas. También PEAP es   una mejora de la autenticación EAP-TLS, PEAP encapsula un   Transacción de autenticación de segunda fase dentro del marco TLS

Por lo tanto, es posible, pero tenga en cuenta que no comprobar el certificado del servidor en el cliente hace que el sistema sea MITM vulnerable, lo que puede llevar a escuchas ilegales.