Zum Hauptinhalt springen

4.7. GCKS-Operationen (GCKS Operations)

Der GCKS oder sein Delegierter kann aus mehreren Gründen eine Rekey-Nachricht initiieren, z.B. wenn sich die Gruppenmitgliedschaft geändert hat oder Schlüssel ablaufen sollen.

Um das Rekey-Datagramm zu beginnen, erstellt der GCKS einen ISAKMP HDR mit dem korrekten Cookie-Paar und eine SEQ Payload, die eine Sequenznummer enthält, die um eins größer ist als das vorherige Rekey-Datagramm.

Dann wird eine SA Payload hinzugefügt. Diese ist in Struktur und Bedeutung identisch mit einer SA Payload, die in einem GROUPKEY-PULL Austausch gesendet wird. Wenn es Änderungen am KEK gibt (im Fall eines statischen KEK) oder in der Gruppenmitgliedschaft (im Fall von LKH), wird ein SA_KEK-Attribut zur SA hinzugefügt. Wenn es einen oder mehrere neue TEKs gibt, werden SA_TEK-Attribute hinzugefügt, um diese Richtlinie zu beschreiben.

Dann wird eine KD Payload hinzugefügt. Diese ist in Struktur und Bedeutung identisch mit einer KD Payload, die in einem GROUPKEY-PULL Austausch gesendet wird. Wenn ein SA_KEK-Attribut in der SA Payload enthalten war, werden entsprechende KEK-Schlüssel (oder ein KEK-Array) eingefügt. TEK-Schlüssel werden für jedes SA_TEK-Attribut gesendet, das in der SA Payload enthalten ist.

Eine CERT Payload wird hinzugefügt, wenn der Initiator sein Zertifikat bereitstellen muss.

Im vorletzten Schritt hasht der Initiator die Zeichenfolge "rekey", gefolgt von der bereits gebildeten Schlüsselverwaltungsnachricht. Der Hash wird signiert, in einer SIG Payload platziert und dem Datagramm hinzugefügt.

Schließlich werden die Payloads nach dem HDR mit dem aktuellen KEK-Verschlüsselungsschlüssel verschlüsselt. Das Datagramm kann jetzt gesendet werden.