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.

This is one of many VPN tutorials on my blog. –> Have a look at this full list. <–

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/different 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 log_{2}(62^{30})=178).
  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

Featured image: “Scrabble” by Wasili is licensed under CC BY-NC-ND 2.0.

15 thoughts on “Considerations about IPsec Pre-Shared Keys

    1. What exactly do you mean? A kind of expiration timer that automatically blocks the VPN if the same PSK is used for x days? This must be a firewall feature, but I have not heard of a feature like that.

      Or do you mean whether it is a security issue if the PSK is never changed? Well, as long as both sites use static IPs, and as long as the PSK is complex enough, there is no reason to change the PSK. However, if it is never changed, this is not “good” either. Maybe it is exposed through another way (social engineering, etc.). So, in my opinion, a PSK change every 3-5 years is a good choice. But even more it is relevant to check every 3-5 years if appropriate security algorithms (ciphers) are used for phase 1 and phase 2. If you are still using “no-DH” or “DH-2”, this is NOT secure anymore.

      That is: Change your PSK every 3-5 years AND review your P1 and P2 proposals. ;)

  1. Hello,

    What do you mean by “Generate a new PSK for every VPN tunnel”? Do the communicating parties need to exchange a nonce/random everytime (with which they generate a new PSK)?

    Imagine that we have several embedded devices that they need to authenticate whenever they want to communicate with each other. Do you think that authentication with PSK is a good idea ? Do you know of any mechanism with which we can securely distribute the PSK to all these devices? Or should we configure the PSK seperately on each device?

    Thanks

    1. Well, it depends. If you have multiple embedded devices, you should consider using authentication via certificates. There are options to distribute certificates automatically.

      Concerning “Generate a new PSK for every VPN tunnel”: If you are a company that has 10-50 static VPN tunnels that do not change that often (i.e., the IP addresses of the partners do not change that ofen), you can use PSKs for authentication. The PSK must be configured only once (!) during the setup of the VPN. It must not be changed later on.
      But if you have a few VPNs coming from dynamic IP addresses, I do not recommend to use the same PSK for these VPNs, but to use a different/new PSK for each of these. If one PSK is exposed, it can be deleted without the need for a change of the PSKs from the other VPNs.

    1. So instead of worrying if a third party might know your PSK, you definately know a third party knows it [you]?

      :P

  2. Can you speak to the plausibility of an attack on a main-mode Phase 1 Internet Key Exchange IF the attacker can snoop on the traffic and if s/he ALSO knows the pre-shared key?

    I’m thinking that in thinking that in main-mode, If one were 100% certain that your IP address were not being spoofed by an attacker (impossible, I know, but this is a thought experiment), that absolutely NO phase 1 key would be needed at all, is that right? The Diffie Hellman key exchange itself guarantees that the key is exchanged privately. The key, as you say, is only used for validating the identity of the remote parties.

    1. Hey Karlfife.
      I am not sure whether I am understanding your question correctly. You’re asking about a passive attacker that 1) has the PSK and 2) is only listening but NO man-in-the-middle, correct?

      If so, he is NOT able to read anything in plain text because of Diffie-Hellman. You’re assumption is correct. DH guarantees a secure key exchange. (To be correct, it is a “key agreement” rather than a “key exchange” since both parties have their input rather than one party transmitting the key). However, DH does NOT authenticate the peers. That’s what the PSK is used for.

      Hence in theory, if no one spoofes your IP connection you can simply trust in your connection (as authentication) and must not use any PSK. However, I would definitely NOT suggest that! ;)

    2. Can you speak to the plausibility of an attack on a main-mode Phase 1 Internet Key Exchange IF the attacker can snoop on the traffic and if s/he ALSO knows the pre-shared key?

      I’m thinking that in thinking that in main-mode, If one were 100% certain that your IP address were not being spoofed by an attacker (impossible, I know, but this is a thought experiment), that absolutely NO phase 1 key would be needed at all, is that right? The Diffie Hellman key exchange itself guarantees that the key is exchanged privately. The key, as you say, is only used for validating the identity of the remote parties.

      1. Yes, AFAIK, this is correct. If you are (in theory) 100 % certain, that your IP as well as the IP address from the other side are *not* spoofed then you can make the PSK public. ;) Indeed, Diffie Hellman is used to generate the session keys.

  3. I never have understood the difference between ike and isakmp .why it is used interchangeably .What i have seen in wireshark 6 main + 3(2) quick all are exchnaged using isakmp only .User data is encrypted with ESP protocol .So my question where do we see ike ?????

    1. Hey Deepak. To be honest: I am always a little bit confused about these namings here. That’s why IPsec VPNs are a little difficult to establish, since there are that many different things and namings and synonyms to remember.

      As far as I know, the IKE definition uses the ISAKMP protocol for some of its parts. The main protocol used is indeed ISAKMP. That’s why it is dissected as “isakmp” within Wireshark. I don’t know why it is called IKE anyway and not ISAKMP directly…

Leave a Reply to Saghar Cancel reply

Your email address will not be published. Required fields are marked *