Key exchange during IKE_AUTH phase of IKEv2

Question

This is what a casual IKEv2 handshake looks like :

  Initiator                                                       Responder
  |                                                                      |
 1|-----------------------> HDR, SAi1, KEi, Ni ------------------------->|
 2|<----------------- HDR, SAr1, KEr, Nr, [CERTREQ] <--------------------|
 3|----> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}-->| 
 4|<------------ HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} <-----------|
  |                                                                      |

Where messages (1) and (2) belong to IKE_SA_INIT exchange and messages (3) and (4) belong to IKE_AUTH exchange. I have analyzed a wireshark trace of this exchange and it seems to me that during IKE_AUTH (SAi2, SAr2), the initiator/the responder advertise the set of security algorithms he supports/he chooses respectively (encryption, authentication, integrity protection, diffie-hellman group). However neither of both does advertise its DH value. So there is no actual key exchange here. My question is for what purpose does the (SAi2, SAr2) security association negotiation serve? and why do we even need to have a second key exchange since the protocol already achieved one during IKE_SA_INIT (In other words why do we need to negotiate new keys) ?

You might want to close your [cross-post in crypto.stackexchange.com](https://crypto.stackexchange.com/questions/50164/key-exchange-during-ike-auth-phase-of-ikev2). — ecdsa, Jul 17 '17 at 08:31

score 1 · Accepted Answer · edited Oct 07 '21 at 07:59

The SAi2/SAr2 payloads, together with the TSi/TSr payloads, are used to negotiate the initial Child SA. As per RFC 7296, section 1.2:

The initiator begins negotiation of a Child SA using the SAi2 payload. The final fields (starting with SAi2) are described in the description of the CREATE_CHILD_SA exchange.

However, the key material for this Child SA is derived from the IKE key material (established with the KE payloads during IKE_SA_INIT), so there is no separate key exchange. DH groups are explicitly not included in the SA payloads during IKE_AUTH. From the same section as above:

Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman group) with any value other than NONE. Implementations SHOULD omit the whole transform substructure instead of sending value NONE.

An IKEv2 implementation that supports RFC 6023 (Childless IKEv2 Initiation) can omit these SA/TS payloads and create an IKE SA without initial Child SA.

When creating or rekeying Child SAs later with CREATE_CHILD_SA exchanges the peers may optionally negotiate a DH group and exchange their public DH factors using KE payloads (if that's not done the keys for the new Child SA are again derived from the IKE SA key material). This serves the purpose of separating the IKE from the Child SA keys and the Child SA keys from each other (this is usually referred to as Perfect Forward Secrecy or PFS).

Thank you for your reply. I have one more question though : If the keys relative to the first SA child are derived from IKE_SA_INIT material, why do SAi2 and SAr2 contain advertisement of (encryption, authentication, integrity protection, diffie-hellman group) algorithms ? — sasuke_X220, Jul 19 '17 at 11:45
As I explained, there are no DH groups contained in the proposals in these SA payloads (also see the second excerpt from the RFC), the remaining algorithms in the proposals are part of the negotiation of the initial Child SA that's created with the IKE_SA. — ecdsa, Jul 19 '17 at 14:50

Key exchange during IKE_AUTH phase of IKEv2

1 Answers1