Si tu PSK es fuerte (por ejemplo, 128 bits de entropía) no tienes que preocuparte, ya que atacarlo con fuerza bruta o un ataque de diccionario no será posible.
Sin embargo, los PSK débiles pueden ser atacados por un servidor no autorizado.
Para IKEv2 ( RFC 7296, sección 2.15 ), el PSK no está mezclado con el material clave utilizado para cifrar la solicitud IKE_AUTH y la carga útil AUTH proporcionada por el cliente, que incorpora el PSK a través de un PRF, se envía antes de que el servidor se autentique (que es diferente para la autenticación EAP basada en el nombre de usuario / contraseña, donde el servidor está Primero autenticado con un certificado). Por lo tanto, un servidor no autorizado puede atacar a los PSK débiles con relativa facilidad después de obtener esa carga útil AUTH. Sin embargo, la solicitud está encriptada, por lo que un oyente pasivo no puede atacarla.
Con IKEv1 ( RFC 2409, sección 5.4 ) en el Modo principal, el PSK se mezcla adicionalmente en El material clave utilizado para cifrar la tercera solicitud por parte del cliente. Pero un servidor no autorizado aún puede atacar PSK débiles al intentar descifrar la tercera solicitud con diferentes PSK hasta que los datos descifrados puedan analizarse como mensaje IKE y la carga útil HASH_I pueda verificarse con el mismo PSK (a veces se debe hacer algo similar) por servidores legítimos que tienen varios PSK disponibles para la misma IP de cliente). Al igual que con IKEv2, un oyente pasivo no puede atacar el PSK debido al cifrado.
Ahora, para IKEv1 en Modo Agresivo, el servidor debe proporcionar HASH_R , que incorpora el PSK, primero para demostrar que conoce el PSK, por lo que para su escenario es más seguro, ya que el cliente no continuará si el pícaro El servidor responde con un hash incorrecto. Sin embargo, en general, no es seguro en absoluto, porque los hash se intercambian sin cifrado y, por lo tanto, pueden ser atacados por un oyente pasivo.