1.3.3. Neu-Schlüsseln von Child SAs mit dem CREATE_CHILD_SA-Austausch
1.3.3. Neu-Schlüsseln von Child SAs mit dem CREATE_CHILD_SA-Austausch
Die CREATE_CHILD_SA-Anfrage zum Neu-Schlüsseln einer Child SA lautet:
Initiator Responder
HDR, SK {N(REKEY_SA), SA, Ni, [KEi], TSi, TSr} -->
Der Initiator sendet SA-Angebote im SA-Payload, einen Nonce im Ni-Payload, optional einen Diffie-Hellman-Wert im KEi-Payload und die vorgeschlagenen Traffic Selectors für die vorgeschlagene Child SA in den TSi- und TSr- Payloads.
Die in Abschnitt 1.3.1 beschriebenen Benachrichtigungen können ebenfalls in einem Neu-Schlüssel-Austausch gesendet werden. Üblicherweise sind dies dieselben Benachrichtigungen, die im ursprünglichen Austausch verwendet wurden; beim Neu-Schlüsseln einer Transportmodus-SA wird beispielsweise die USE_TRANSPORT_MODE-Benachrichtigung verwendet.
Die REKEY_SA-Benachrichtigung MUSS in einem CREATE_CHILD_SA-Austausch enthalten sein, wenn der Zweck des Austauschs darin besteht, eine bestehende ESP- oder AH-SA zu ersetzen. Die neu zu schlüsselnde SA wird durch das SPI-Feld im Notify-Payload identifiziert; dies ist das SPI, das der Austausch-Initiator in eingehenden ESP- oder AH-Paketen erwarten würde. Es sind keine Daten mit diesem Notify-Nachrichtentyp verbunden. Das Protocol-ID-Feld der REKEY_SA-Benachrichtigung wird so gesetzt, dass es dem Protokoll der SA entspricht, die wir neu schlüsseln, zum Beispiel 3 für ESP und 2 für AH.
Die CREATE_CHILD_SA-Antwort zum Neu-Schlüsseln einer Child SA lautet:
<-- HDR, SK {SA, Nr, [KEr],
TSi, TSr}
Der Responder antwortet (mit derselben Message ID) mit dem akzeptierten Angebot in einem SA-Payload und einem Diffie-Hellman-Wert im KEr-Payload, falls KEi in der Anfrage enthalten war und die ausgewählte kryptografische Suite diese Gruppe umfasst.
Die Traffic Selectors für den Datenverkehr, der auf dieser SA gesendet werden soll, werden in den TS-Payloads in der Antwort angegeben, die eine Teilmenge dessen sein können, was der Initiator der Child SA vorgeschlagen hat.