IKEv1 vs IKEv2 Pre-Shared Key Authentication: What Differs

Two gateways configured with the same pre-shared key complete a handshake, and a packet capture shows no secret crossing the wire. That is the part people remember. The interesting part is what each version actually computes to prove the secret is known, because IKEv1 and IKEv2 build that proof from different inputs and expose different information while doing it. Read the two traces side by side and the difference stops being cosmetic.

What the proof has to accomplish

Diffie-Hellman gives both peers a shared value that anyone watching can also compute the public halves of. By itself that proves nothing about identity: an attacker who completes a key exchange has the same shared value as your gateway. The authentication step exists to bind that exchange to a secret that only the intended peers hold, and to the identities and parameters they agreed on.

That binding is why the hash covers more than the key. If it covered only the secret, an attacker could replay it into a different exchange with different identities or proposals.

IKEv1 Main Mode: derive SKEYID, then prove it

Main Mode runs six messages. The first pair negotiates the security association, the second exchanges Diffie-Hellman public values and nonces, and the third carries identities plus authentication hashes under encryption that was just established. RFC 2409 defines the construction: with pre-shared key authentication, SKEYID is derived from the secret and both nonces, and the later keying material is derived from SKEYID, the Diffie-Hellman shared value, the cookies and constants.

The hash in messages five and six is computed over the Diffie-Hellman value, the two cookies, the proposal and the sender's identity, keyed by SKEYID. The receiver recomputes it with its own configured secret. A mismatch ends the exchange, and at no point is the secret itself a payload.

Aggressive Mode compresses the same work into three messages, which means identities and the authentication hash travel before an encrypted channel exists. That is a real exposure for a guessable secret, and it is separate from the question of whether the secret was transmitted. IKEv1 is deprecated by RFC 9395, so a legacy trace is a diagnostic exercise rather than a deployment target.

IKEv2: a different derivation and a different AUTH payload

IKEv2 does not reuse the IKEv1 key schedule. The initial IKE keys come from a seed built from the nonces and the Diffie-Hellman shared value, and the child security associations derive from that. The pre-shared key does not feed the seed at all.

Authentication then appears as an AUTH payload. For shared-key authentication, RFC 7296 specifies a padded form of the secret, produced by hashing the secret with the fixed string Key Pad for IKEv2, and then hashing the signed exchange data and the identity with that padded key. The verifier can rebuild the same value; an observer cannot, without the secret.

Notice what changed. In IKEv1 the secret is baked into the key schedule before the authentication hash exists; in IKEv2 the key schedule is independent of the secret and the proof is a distinct payload tied to the signed octets. Same conceptual guarantee, different machinery, and that is why parameter names and captures do not map one to one.

What an observer actually learns

Diffie-Hellman public values, proposals, nonces and cookies are visible in both versions. Identities are visible in IKEv1 Aggressive Mode and protected in the other cases. The secret is never visible.

That last sentence has a limit worth stating. A weak, human-chosen secret can be attacked by guessing: the attacker computes what the authentication value would be for a candidate secret and compares. IKEv1 Aggressive Mode makes this cheapest because the evidence is in the clear, and the standards warn about low-entropy secrets in general. Never transmitting the secret is not the same as making a bad secret safe.

What to do with the comparison

Use one unique secret per peer pair, generate it from a random source, and rotate it through the same provisioning path that distributed it. If the secret is stored in a configuration template that ships to every branch, a compromise at one site is a compromise everywhere.

Prefer certificate-based authentication where the operational cost is acceptable, since it removes the shared-secret guessing problem and gives each peer a distinct identity. Where a pre-shared key stays, keep it long, scope it narrowly and treat the IKE version as a security decision rather than an interoperability detail.