2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange (IKE-SA-Rekeying mit CREATE_CHILD_SA)

2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange (IKE-SA-Rekeying mit CREATE_CHILD_SA)

CREATE_CHILD_SA kann eine bestehende IKE SA rekeyen (Abschnitte 1.3.2 und 2.8). Neue Initiator- und Responder-SPI stehen in den SPI-Feldern der Proposal-Strukturen innerhalb der SA-Nutzlasten (nicht im IKE-Header). TS-Nutzlasten entfallen beim Rekeying der IKE SA. SKEYSEED der neuen IKE SA verwendet SK_d der alten:

SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)

g^ir (new) ist das ephemere DH-Secret dieses Austauschs (big-endian, Nullauffüllung), Ni und Nr ohne Header.

Alte und neue IKE SA können unterschiedliche PRFs wählen. Da der Rekey-Austausch zur alten IKE SA gehört, erzeugt die alte PRF SKEYSEED.

Rekeying soll verhindern, dass Kompromittierung alter Schlüssel aktuelle preisgibt und umgekehrt. Implementierungen MÜSSEN beim IKE-SA-Rekey ein neues Diffie-Hellman durchführen. Der Initiator DARF „NONE“ für DH nicht vorschlagen, der Responder DARF es nicht akzeptieren. Erfolgreiches Rekeying umfasst immer KEi/KEr.

Die neue IKE SA MUSS ihre Nachrichtenzähler auf 0 setzen.

SK_d, SK_ai, SK_ar, SK_ei und SK_er werden aus SKEYSEED wie in Abschnitt 2.14 mit SPIi, SPIr, Ni, Nr des neuen Austauschs und der PRF der neuen IKE SA berechnet.