An exploration of the Intenet Key Exchange (IKE) version 1, IKE version 2, and the different modes in which it operates, aggressive, main and quick.
At the time of this writing, it is pretty much a well established fact that IKEv1 using Aggressive Mode and pre-shared keys is not a strong form of protection for a IPSEC connection or service. The reason for this is the fact that during the exchange the authentication hash sent from the responder in the second packet of the exchange is unencrypted.
This weakness is well documented: PSK Cracking using IKE Aggressive Mode, IKECrack, http://www.sersc.org/journals/IJAST/vol8/2.pdf. RFC2408 and RFC2409 hint at some of it's weaknesses, stating repeatedly
that identity protection is not provided. strongSwan will not function in aggresssive mode unless the configuration
directive charon.i_dont_care_about_security_and_use_aggressive_mode_psk=yes
is used in the strongswan.conf
file. When this configuration directive is used, strongSwan says it changes it's name to weakSwan (Note: I couldn't get
it to do this with strongSwan 4.5.2 despite the claims in the FAQ.)
The crux of the problem is that the hash that is sent in the clear can be subjected to a brute force or password guessing attack to recover the pre-shared key. The hash can be captured by a rogue entity simply probing the IPSEC responder requesting access, or from an actual packet that is captured on the wire.
Once this pre-shared key is known, it can be used to gain network access, used to snoop on protected traffic (as long as PFS is not used), and for man-in-the-middle attacks. If further authentication is in use via extended authentication (xauth), a guessing attack can be launched against the xauth credentials, or a man-in-the-middle attack can be used to capture xauth credentials.
There are several ways to mitigate this weakness.