Considerations about IPsec Pre-Shared Keys

Pre-shared keys (PSK) are the most common authentication method for site-to-site IPsec VPN tunnels. So what’s to say about the security of PSKs? What is its role for the network security? How complex should PSKs be? Should they be stored additionally? What happens if an attacker catches my PSKs?

I am listing my best practice steps for generating PSKs.

Pre-Shared Keys in IPsec

The following section is related to site-to-site VPNs only and NOT to remote access VPNs.

1. The pre-shared key is merely used for authentication, not for encryption! IPsec tunnels rely on the ISAKMP/IKE protocols to exchange the keys for encryption, etc. But before IKE can work, both peers need to authenticate each other (mutual authentication). This is the only part in which the PSKs are used (RFC 2409).
2. If static IP addresses are used on both sides (= main mode can be used), an attacker who has the PSK must also spoof/redirect these public addresses over himself in order to establish a VPN connection. That is: Even if an attacker has a PSK, he must spoof a public IP address to use it to authenticate against the other side. This is quite unrealistic for normal persons with common ISP connections. Even skilled hackers must be able to inject falsified BGP routes or to sit nearby the customers default gateway/router.
3. But: If one remote side has only a dynamic IP address, IKE must use the aggressive mode for its authentication. In this scenario, a hash from the PSK traverses the Internet. An attacker can do an offline brute-force attack against this hash. That is: If the PSK is not complex enough, the attacker could succeed and would be able to establish a VPN connection to the network (if he furthermore knows the IDs of the site-to-site VPN peers which is no problem since they traverse through the Internet in plaintext, too).

Best Practice for PSKs

Since the PSKs must be configured on each side only once, it should be no problem to write 20-40 letters on the firewall. Thereby, a really complex key can be generated and used for the authentication of the VPN peer. Here are my tips:

1. Generate a new PSK for every VPN tunnel.
2. Use a password/passphrase generator for the creation of the PSK.
3. Generate a long PSK with at least 30 chars, to resist a brute-force attack. (See my article about password complexity.) To avoid problems, use only alphanumeric chars. Since the PSK with 30 chars is really long, the “small” character set of only 62 alphabets and numerals is no problem. The security level in this example would be round about 178 bit (since ).
   
4. Do NOT send the PSK to your peer over the Internet, but via phone, fax, or SMS.
5. There is no need to store the PSK anywhere else. If it is configured on both sides, you can discard it. In the worst case, you need to generate and transfer a new one.

Further Reading

• RFC 2409: The Internet Key Exchange (IKE)
• RFC 4301: Security Architecture for the Internet Protocol
• Michael Thumann, Enno Rey: PSK Cracking using IKE Aggressive Mode [PDF]
• eTutorials: Attacking IPsec VPNs