In IKEv2, how does pre-shared-key authentication differ from certificate signature authentication in what AUTH proves and what the operator must protect?
answer
- both cover the first exchange
- keyed prf versus private-key signature
- "Key Pad for IKEv2"
- offline guessing is not prevented
- the ID must match the certificate
basics
~20 sBoth compute AUTH over the sender's IKE_SA_INIT message, the peer's nonce and its own ID. A pre-shared key makes AUTH a keyed prf, guessable offline if the secret is weak; a signature uses a private key a certificate binds to the ID.
solid answer
~50 sIn `IKE_AUTH` each side sends an `AUTH` payload computed over its own `IKE_SA_INIT` message, the other side's nonce and a prf of its own ID payload, so the proof is bound to this exchange and this identity. With **Shared Key Message Integrity Code**, `AUTH = prf(prf(Shared Secret, "Key Pad for IKEv2"), <signed octets>)`. An active attacker who completes `IKE_SA_INIT` as the responder receives the initiator's `AUTH` and can test guesses offline — RFC 7296 says this method does not prevent dictionary attacks — so the key must be as unpredictable as the strongest key negotiated, never a password. With **signatures** (RSA, ECDSA or RFC 7427's generic Digital Signature) the private key never leaves the gateway, `CERT` carries the certificate whose key verifies `AUTH`, and RFC 4945 requires checking that the ID matches the certificate — an FQDN against its subjectAltName `dNSName`. The two directions may use different methods.
go deeper
Recall that IKEv2 peers authenticate in IKE_AUTH with either a pre-shared key or a signature backed by a certificate, and that each side sends its own AUTH payload.
Explain the signed octets, the keyed prf with the Key Pad string, and how the first CERT payload and the ID payload tie a signature to an identity.
Show why encryption of IKE_AUTH does not save a weak pre-shared key from an active attacker, and how ID-to-certificate mismatches surface as authentication failures between gateways.
Weigh per-peer secret distribution against running a certificate lifecycle, including where each private key or secret lives and what a single compromise exposes.
## What AUTH proves in either method In IKEv2 (RFC 7296) authentication happens in `IKE_AUTH`, the second exchange, inside the encrypted channel built by `IKE_SA_INIT`. Each side sends an **`AUTH` payload** computed over a block RFC 7296 calls the **signed octets**: 1. the sender's own `IKE_SA_INIT` message, from the first SPI to the last payload; 2. the **other side's nonce** (`Nr` for the initiator, `Ni` for the responder); 3. a prf of the sender's own ID payload, keyed by `SK_pi` or `SK_pr`. Signing the peer's fresh nonce makes the proof unusable in any other exchange; covering the unprotected first message means a tampered proposal list is detected; covering the ID binds the proof to the identity claimed. Only the *function* applied to the signed octets differs between methods. ## Pre-shared keys: a MAC under a shared secret With the method RFC 7296 calls **Shared Key Message Integrity Code**: `AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <signed octets> )` - The pad string is 17 ASCII characters. It exists so an implementation can store `prf(Shared Secret, "Key Pad for IKEv2")` rather than the secret, a value useless as a password for any other protocol. - The management interface MUST accept ASCII strings of at least 64 octets, MUST NOT add a null terminator, and MUST accept a hex encoding. - RFC 7296 calls a key derived only from a user-chosen password common but insecure: dictionary attacks are **not prevented** by this method. An active attacker who answers `IKE_SA_INIT` itself shares keys with the initiator, receives its `AUTH`, and holds every other input to the prf, so it can test guesses offline. Hence the rule that the pre-shared key carry as much unpredictability as the strongest key negotiated. - The responder finds the right key by the identity in `IDi`; the ID names must correspond to the key used. ## Signatures and certificates With a signature method the sender signs the signed octets with its **private key**. The first `CERT` payload must contain the public key that verifies `AUTH`; `CERTREQ` tells the peer which trust anchors are acceptable. RFC 8247 sets the implementation requirements: | Auth Method | Description | RFC 8247 status | |---|---|---| | 1 | RSA Digital Signature | MUST | | 2 | Shared Key Message Integrity Code | MUST | | 3 | DSS Digital Signature | SHOULD NOT | | 9, 10, 11 | ECDSA on P-256, P-384, P-521 | SHOULD | | 14 | Digital Signature (RFC 7427) | SHOULD | RFC 7427's generic **Digital Signature** method adds hash and algorithm agility, and RFC 8247 expects it to replace the per-algorithm methods. For the identity, RFC 4945 requires implementations to check that the ID matches the certificate — for `ID_FQDN`, the `dNSName` in the subjectAltName extension — and to do so by default. Whether the certificate itself chains to a trusted anchor is certificate path validation, a PKI subject rather than an IKE one. ## Side by side | | Pre-shared key | Signature with certificate | |---|---|---| | What AUTH is | prf keyed by the shared secret | signature by a private key | | Secret held by | both peers | the signer only | | Exposure if AUTH is captured | offline guessing of a weak key | none for the private key | | Identity binding | ID looked up to find the key | ID checked against the certificate | | Per-peer setup | a secret to distribute to each pair | a certificate to issue and trust | RFC 7296 allows the two directions to differ: an initiator may use a shared key while the responder signs. EAP methods (section 2.16) are typically used to authenticate the initiator and MUST be combined with signature authentication of the responder. ## The IKEv1 version of the same choice In IKEv1 Main Mode a pre-shared key can only be selected by the peer's IP address, because the identity arrives under keys that already depend on the key. Aggressive Mode sends the responder's hash in the clear, computed from on-the-wire values plus the key, which exposes a weak key to offline guessing without any man in the middle. RFC 9395 deprecates IKEv1, while noting that its use of pre-shared keys resists quantum-computer attacks in a way IKEv2's does not without a post-quantum preshared key extension. ## What an operator protects - With pre-shared keys: the secret on both ends, its length and randomness, and one secret per peer relationship. - With certificates: the private key on the gateway, the trust anchors each peer accepts, and an ID that matches the certificate.
- Why does an IKEv2 AUTH payload include the other side's nonce?Because the nonce is fresh for this exchange, so a proof that covers it cannot be replayed into another one. RFC 7296 calls it critical to the security of the exchange that each side sign the other side's nonce. Together with the sender's own `IKE_SA_INIT` message, it binds the proof to this negotiation, so an attacker cannot reuse an `AUTH` captured elsewhere.
- Can one IKEv2 peer authenticate with a pre-shared key while the other uses a certificate?Yes. RFC 7296 places no requirement that both sides use the same algorithms; each signs or MACs with whatever its key type dictates, named in the Auth Method field of its own `AUTH` payload. An initiator may use a shared key while the responder has a signature key and certificate. EAP is the constrained case: it must be paired with signature authentication of the responder.
saying these in an interview costs you the question
- With a pre-shared key, AUTH is a hash of the key the peer can compare.
- A memorable password makes a fine pre-shared key for a tunnel.
- Pre-shared keys are safe because the IKE_AUTH exchange is encrypted.
- Certificates make the ID payload irrelevant to policy.
- Both IKEv2 peers must use the same authentication method.