skip to content

In IKEv2, what do the IKE_SA_INIT and IKE_AUTH exchanges each carry, and why is the first pair sent unencrypted?

level: middleimportance: must knowfreq 38%

answer

  1. two round trips, four messages
  2. proposals, key exchange values, nonces
  3. keys exist only after the first pair
  4. AUTH covers the other side's nonce
  5. first Child SA rides along

basics

~20 s

IKE_SA_INIT negotiates the IKE SA's algorithms and exchanges Diffie-Hellman values and nonces in the clear, because no keys exist yet. IKE_AUTH, encrypted under the derived keys, carries identities, AUTH proofs, and the first Child SA's proposal and traffic selectors.

solid answer

~40 s

IKEv2 (RFC 7296) sets a tunnel up in two request/response pairs. `IKE_SA_INIT` carries `SAi1`/`SAr1` (the initiator's proposals and the responder's choice), `KEi`/`KEr` (Diffie-Hellman public values) and `Ni`/`Nr` (nonces). It cannot be encrypted because nothing has been agreed yet; after it, both sides compute `SKEYSEED` and from it `SK_e`, `SK_a` and `SK_d`. `IKE_AUTH` then travels inside the Encrypted payload: `IDi`/`IDr`, optional `CERT` and `CERTREQ`, the `AUTH` payload proving each side holds its secret, and `SAi2`, `TSi`, `TSr` for the first Child SA. If the responder wants another group it replies `INVALID_KE_PAYLOAD` and the initiator retries; under load it may first demand a `COOKIE`. Four messages produce the IKE SA and one Child SA.

go deeper

for a junior

Recall the two exchange names, their order, and that four messages give both the IKE SA and the first Child SA.

for a middle

Walk through each payload in both pairs, explain why keys can only exist after IKE_SA_INIT, and say what AUTH signs and why it includes the peer's nonce.

for a senior

Read failures by exchange: INVALID_KE_PAYLOAD and COOKIE are normal retries, a Child SA notify in IKE_AUTH leaves the IKE SA up, and AUTHENTICATION_FAILED leaves nothing.

for a principal

Explain how the design spends one round trip in the clear to buy identity protection, downgrade resistance through AUTH, and stateless cookie defence against floods.

## What the first four messages accomplish IKEv2, specified in RFC 7296, organises everything as **exchanges**: a request and its response. The first two exchanges are always `IKE_SA_INIT` and then `IKE_AUTH`. In the common case they are four messages in total, and when they finish both peers hold: - an **IKE SA** — the authenticated, encrypted control channel used for every later IKE message; - the **first Child SA** — the ESP (or AH) security association pair that carries user traffic. Every `IKE_SA_INIT` exchange must complete before any other type, then every `IKE_AUTH`, and only then may `CREATE_CHILD_SA` and `INFORMATIONAL` exchanges run, in any order. ## IKE_SA_INIT: agreeing algorithms and a shared secret in the clear The initiator sends `HDR, SAi1, KEi, Ni` and the responder answers `HDR, SAr1, KEr, Nr, [CERTREQ]`. | Payload | Meaning | |---|---| | `HDR` | IKE header: both IKE SPIs (the responder's is zero in the first request), version, exchange type, Message ID, flags | | `SAi1` / `SAr1` | the initiator's proposals for the IKE SA's suite, and the single suite the responder chose | | `KEi` / `KEr` | each side's Diffie-Hellman public value, in the group the initiator guessed | | `Ni` / `Nr` | fresh random nonces | | `CERTREQ` | optional: which trust anchors the responder would accept certificates from | Nothing here can be encrypted: the two peers have not agreed any algorithm or key yet. Once the pair is complete, each side computes **`SKEYSEED`** from the nonces and the Diffie-Hellman shared secret, and derives `SK_e` (encryption) and `SK_a` (integrity) for each direction, `SK_d` for Child SA keys, and `SK_pi`/`SK_pr` used in authentication. How Diffie-Hellman itself works belongs to the cryptography foundations; what matters here is that the IKE SA's protection exists only after this pair. ## IKE_AUTH: identities and proof, under encryption The initiator sends `HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}`; the responder answers `HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}`. `SK {...}` means the payloads are encrypted and integrity-protected with that direction's keys. - `IDi` / `IDr` — identities (an address, an FQDN, an email-style name, a distinguished name or a key ID). The optional `IDr` in the request names which of the responder's identities the initiator wants. - `CERT` — optional certificates; the first one must contain the public key that verifies `AUTH`. - `AUTH` — the proof. Each side signs, or MACs with a shared secret, its own `IKE_SA_INIT` message plus the **other side's nonce** plus a prf of its own ID. That binds the unprotected first exchange to the authenticated identities, so tampering with `IKE_SA_INIT` is caught here. - `SAi2` / `SAr2`, `TSi` / `TSr` — the first Child SA's proposal and **traffic selectors**, in the same form a later `CREATE_CHILD_SA` uses. `IKE_AUTH` carries no KE payload, so this Child SA's keys come from `SK_d` and the `IKE_SA_INIT` nonces. ## Two retries the first exchange may need `IKE_SA_INIT` can take more than one round trip: 1. **`INVALID_KE_PAYLOAD`.** The initiator must guess the group when it sends `KEi`. If the responder selects a different group, it answers with this notify naming the group it wants. The initiator retries with a `KEi` in that group and **must re-offer its full set of suites**, because the rejection was unauthenticated and narrowing on it would let an attacker push both sides to a weaker suite. 2. **`COOKIE`.** A responder that sees many half-open IKE SAs replies with a `COOKIE` notify and keeps no state. The initiator repeats its request with the cookie as the first payload, proving it can receive at the address it claims. The Message IDs of these retried messages stay zero. Both can occur in one setup; the AUTH payload then signs the latest version of the first message. ## What can fail separately The IKE SA and the Child SA are created by the same messages but fail independently. If creating the Child SA in `IKE_AUTH` fails — `NO_PROPOSAL_CHOSEN`, `TS_UNACCEPTABLE`, `SINGLE_PAIR_REQUIRED`, `INTERNAL_ADDRESS_FAILURE` or `FAILED_CP_REQUIRED` — the IKE SA is still created. If authentication fails (`AUTHENTICATION_FAILED`), no IKE SA is created at all. ## Common misreadings - `IKE_SA_INIT` is not protected by the pre-shared key; it is plain, and `AUTH` protects it afterwards. - Identities are hidden from passive eavesdroppers, but RFC 7296 notes that an active man in the middle who cannot complete `IKE_AUTH` can still see the initiator's identity. - The first Child SA needs no extra exchange; it rides in `IKE_AUTH`.

  • If IKEv2's IKE_AUTH rejects the Child SA proposal, is the IKE SA lost as well?
    No. RFC 7296 says the IKE SA is still created when the Child SA fails in `IKE_AUTH`; notifies such as `NO_PROPOSAL_CHOSEN`, `TS_UNACCEPTABLE`, `SINGLE_PAIR_REQUIRED`, `INTERNAL_ADDRESS_FAILURE` and `FAILED_CP_REQUIRED` leave it standing. Only a failure of the IKE SA itself, such as `AUTHENTICATION_FAILED`, prevents it, so you can see an authenticated IKE SA with no Child SA carrying traffic.
  • Why must an IKEv2 initiator re-propose every suite after INVALID_KE_PAYLOAD instead of just the named group?
    The `INVALID_KE_PAYLOAD` reply arrives in the unencrypted, unauthenticated first exchange. If the initiator narrowed its offer to whatever that reply asked for, an active attacker could forge rejections and steer both peers to a weaker suite than they would choose. RFC 7296 therefore requires the retry to carry the full set of acceptable suites, with only the KE payload moved to the requested group.
  • Are IKEv2 identities hidden from every attacker?
    From passive eavesdroppers, yes: `IDi` and `IDr` travel inside the Encrypted payload. But those keys come from a Diffie-Hellman exchange that is not yet authenticated, so an active man in the middle who answers `IKE_SA_INIT` itself can decrypt the initiator's `IKE_AUTH` and read `IDi` before failing to complete the exchange; RFC 7296 states this limit.

saying these in an interview costs you the question

  • IKE_SA_INIT is encrypted with the pre-shared key.
  • The first Child SA needs its own CREATE_CHILD_SA exchange.
  • INVALID_KE_PAYLOAD means the tunnel failed and must be reconfigured.
  • IKE_AUTH is where the IKE SA's encryption algorithm is chosen.
  • IKEv2 hides the initiator's identity even from an active man in the middle.