Zum Hauptinhalt springen

1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange

1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange​

The CREATE_CHILD_SA request for rekeying an IKE SA is:

Initiator Responder​

HDR, SK {SA, Ni, KEi} -->

The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, and a Diffie-Hellman value in the KEi payload. The KEi payload MUST be included. A new initiator SPI is supplied in the SPI field of the SA payload. Once a peer receives a request to rekey an IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed.

The CREATE_CHILD_SA response for rekeying an IKE SA is:

                         <--  HDR, SK {SA, Nr, KEr}

The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if the selected cryptographic suite includes that group. A new responder SPI is supplied in the SPI field of the SA payload.

Kaufman, et al. Standards Track [Page 15] RFC 5996 IKEv2bis September 2010

The new IKE SA has its message counters set to 0, regardless of what they were in the earlier IKE SA. The first IKE requests from both sides on the new IKE SA will have Message ID 0. The old IKE SA retains its numbering, so any further requests (for example, to delete the IKE SA) will have consecutive numbering. The new IKE SA also has its window size reset to 1, and the initiator in this rekey exchange is the new "original initiator" of the new IKE SA.

Section 2.18 also covers IKE SA rekeying in detail.

Letztes Update am