Me gustaría configurar una puerta de enlace VPN IKEv2 para que varios usuarios remotos accedan a una red privada.
Tengo una configuración de prueba en la que el respondedor se autentica con un certificado autofirmado. El iniciador se autentica con un nombre de usuario y contraseña.
Un par de cuestiones:
- El certificado es demasiado complicado. No configuraré una PKI adecuada, por lo que un certificado autofirmado que debe distribuirse a cada cliente y configurarse para que sea confiable equivale a una clave precompartida (PSK), aunque es sustancialmente más difícil de generar y administrar.
- El iniciador está autenticado.solopor un nombre de usuario y contraseña, por lo que un atacante externo puede intentar adivinar fácilmente contraseñas débiles o comprometidas.
A falta de implementar una PKI adecuada, preferiría realizarmutualautenticación de los hosts iniciador y respondedor a través de un PSK. Esta clave se distribuirá de forma segura a todos los usuarios. Los atacantes externos no tendrían el PSK y, por lo tanto, una contraseña débil o comprometida no es suficiente para acceder. La autenticación de nombre de usuario y contraseña permite la identificación y autorización de un usuario específico en un sistema de directorio existente, sin la necesidad de generar y distribuir claves únicas para cada usuario.
¿Es posible algo así con IKEv2? Hasta donde sé, fue posible a través de Xauth en IKEv1. Pero para IKEv2 no estoy tan seguro: en una lectura superficial deRFC 5996, sección 2.16, parece que este puede no ser el caso. La autenticación de nombre de usuario y contraseña se realizaría a través de algún método EAP y:
Un iniciador indica su deseo de utilizar EAP omitiendo la carga útil AUTH del primer mensaje en el intercambio IKE_AUTH. (Tenga en cuenta que la carga útil AUTH es necesaria para la autenticación que no es EAP y, por lo tanto, no está marcada como opcional en el resto de este documento).
Eso parece sugerir que el iniciador puede usar solo uno de EAP (nombre de usuario y contraseña) o PSK.
Aunque la pregunta es sobre el protocolo IKEv2, tengo la intención de implementar el extremo del respondedor con strongswan, por lo que agradecería cualquier experiencia adicional.
Respuesta1
La autenticación de cliente y servidor en IKEV2 no está relacionada. Entonces, en teoría, puedes autenticar el servidor con un PSK y el cliente con EAP. sin embargo, elRFC establece lo siguientecon respecto a la autenticación EAP:
Además de la autenticación mediante firmas de clave pública y secretos compartidos, IKE admite la autenticación mediante métodos definidos en RFC 3748 [EAP]. Normalmente, estos métodos son asimétricos (diseñados para que un usuario se autentique en un servidor) y es posible que no sean mutuos. Por este motivo, estos protocolos se utilizan normalmente para autenticar al iniciador ante el respondedor.y DEBE usarse junto con una autenticación basada en firma de clave pública del respondedor al iniciador.
Por lo tanto, combinar la autenticación del servidor PSK con la autenticación del cliente EAP no cumple con el RFC. Sin embargo, es posible configurarlo con strongSwan. Pero tenga en cuenta que la mayoría de los clientes no permitirán esta combinación.
Muchos clientes de roadwarrior en realidad no admiten la autenticación PSK en absoluto, ya que es un riesgo potencial de seguridad en tales escenarios si se usa el mismo PSK con múltiples clientes, porque todos los clientes que conocen el PSK son, en teoría, capaces de hacerse pasar por el servidor.
Tengo una configuración de prueba en la que el respondedor se autentica con un certificado autofirmado.
¿Por qué no usar?Vamos a cifrar?
El iniciador se autentica únicamente mediante un nombre de usuario y una contraseña, por lo que un atacante externo puede intentar adivinar fácilmente contraseñas débiles o comprometidas.
Usar un PSK para autenticar el servidor no cambiará eso. Necesitaría agregar un segundo factor a la autenticación del cliente para hacer algo al respecto (es decir, usar un certificado o PSK primero y luego hacer EAP). Sin embargo, esto requiere apoyo paraRFC 4739, del que carecen muchos clientes (aunque strongSwan lo admite).