IPSEC connection attempt to rogue server -- is my PSK compromised?

Question

I am setting up an IPSec connection between two sites using Ubiquiti EdgeOS-based equipment. Using a DDNS service (a static IP is unavailable from the ISP), they can be found at east.example.net and west.example.net.

The use of DDNS presents a problem. Let's say the west site is down. The ISP gives the address to a potentially rogue server before the west site is able to update the DDNS. When the east site attempts to restore the connection, it is attempting to negotiate with this rogue server.

Given the implementation of IPSec while using a PSK, is the secrecy of my PSK now compromised after this attempt?

Answer 1

The PSK is still secure even if your server attempted to connect to a rogue server.

The PSK isn't actually sent to the other party, it is used as an input to generate cryptographic material. Unless the rogue server already has the PSK, it will not be able to decrypt any messages from your server

For further reading:

https://crypto.stackexchange.com/questions/9926/what-is-the-shared-secret-used-for-in-ipsec-vpn

RFC2409 (IKEv1)

RFC4306 (IKEv2)

Answer 2

If your PSK is strong (e.g. 128-bit of entropy) you don't have to worry, as attacking it with brute force or a dictionary attacks won't be feasible.

However, weak PSKs can be attacked by a rogue server.

For IKEv2 (RFC 7296, section 2.15), the PSK is not mixed into the key material used to encrypt the IKE_AUTH request and the AUTH payload provided by the client, which incorporates the PSK via a PRF, is sent before the server is authenticated (that's different for username/password-based EAP authentication, where the server is first authenticated with a certificate). A rogue server can, therefore, attack weak PSKs relatively easily after getting that AUTH payload. The request is encrypted, though, so a passive listener can't attack it.

With IKEv1 (RFC 2409, section 5.4) in Main Mode, the PSK is additionally mixed into the key material used to encrypt the third request by the client. But a rogue server can still attack weak PSKs by trying to decrypt the third request with different PSKs until the decrypted data can be parsed as IKE message and the HASH_I payload can be verified with the same PSK (something similar has sometimes to be done by legitimate servers that have multiple PSKs available for the same client IP). As with IKEv2, a passive listener can't attack the PSK due to the encryption.

Now, for IKEv1 in Aggressive Mode, the server has to provide HASH_R, which incorporates the PSK, first to prove it knows the PSK, so for your scenario it's safer, as the client won't continue if the rogue server responds with an incorrect hash. However, in general, it is not safe at all, because the hashes are exchanged without encryption and can, therefore, be attacked by a passive listener.