4. GROUPKEY-PUSH Nachricht (GROUPKEY-PUSH Message)

GDOI sendet Steuerungsinformationen sicher über Gruppenkommunikation. Typischerweise erfolgt dies über die IP-Multicast-Verteilung einer GROUPKEY-PUSH Nachricht, kann aber auch über Unicast-Zustellung „gepusht" werden, wenn IP-Multicast nicht möglich ist. Die GROUPKEY-PUSH Nachricht ersetzt einen Re-key SA KEK oder KEK-Array und/oder erstellt eine neue Datensicherheits-SA.

Mitglied                             GCKS oder Delegat
------                               ----------------

                    <---- HDR*, SEQ, SA, KD, [CERT,] SIG

Hinweis: Geschützt durch den Re-key SA KEK; Verschlüsselung erfolgt nach HDR

HDR ist unten definiert. Die SEQ Payload ist im Abschnitt Payloads definiert. Die SA definiert die Richtlinie (z.B. Schutz-Suite) und Attribute (z.B. SPI) für Re-key- und/oder Datensicherheits-SAs. Der GCKS oder Delegat stellt optional eine CERT Payload zur Verifizierung der SIG bereit. KD ist die Schlüssel-Download-Payload, wie im Abschnitt Payloads beschrieben.

Die SIG Payload ist eine Signatur eines Hashes der gesamten Nachricht vor der Verschlüsselung (einschließlich Header und ohne die SIG Payload selbst), mit der Zeichenfolge „rekey" als Präfix. Die Präfix-Zeichenfolge stellt sicher, dass die Signatur des Rekey-Datagramms nicht für einen anderen Zweck im GDOI-Protokoll verwendet werden kann.

Wenn die SA ein LKH KEK-Array oder einen einzelnen KEK definiert, enthält KD einen KEK oder ein KEK-Array für eine neue Re-key SA, die ein neues Cookie-Paar hat. Wenn die KD Payload ein neues SA KEK Attribut trägt (Abschnitt 5.3), wird eine Re-key SA durch eine neue SA ersetzt, die denselben Gruppenidentifikator hat (ID, die in Nachricht 1 von Abschnitt 3.2 angegeben ist) und denselben Sequenzzähler inkrementiert, der in Nachricht 4 von Abschnitt 3.2 initialisiert wird. Wenn die SA eine SA TEK Payload definiert, informiert dies das Mitglied, dass eine neue Datensicherheits-SA erstellt wurde, mit Schlüsselmaterial, das in KD getragen wird (Abschnitt 5.5).

Wenn die SA ein großes LKH KEK-Array definiert (z.B. während der Gruppeninitialisierung und Batch-Rekeying), können (MAY) Teile des Arrays in verschiedenen eindeutigen GROUPKEY-PUSH Datagrammen gesendet werden. Jedes der GROUPKEY-PUSH Datagramme muss (MUST) jedoch ein vollständig geformtes GROUPKEY-PUSH Datagramm sein. Dies führt dazu, dass jedes Datagramm eine Sequenznummer und die Richtlinie in der SA Payload enthält, die dem KEK-Array-Teil entspricht, der in der KD Payload gesendet wird.

4.1. Perfekte Vorwärtsgeheimhaltung (Perfect Forward Secrecy, PFS)

Die GROUPKEY-PUSH Nachricht wird durch den Gruppen-KEK geschützt, obwohl in allen Fällen die GROUPKEY-PUSH Nachricht neben anderen Informationen neue Schlüssel-Downloads trägt. Ein frisch generiertes Geheimnis muss (MUST) den Schlüssel-Download schützen, damit die GROUPKEY-PUSH Nachricht PFS hat. Dieses Thema ist Gegenstand weiterer Untersuchungen.

4.2. Vorwärts- und Rückwärtszugriffskontrolle (Forward and Backward Access Control)

Durch GROUPKEY-PUSH unterstützt GDOI Algorithmen wie LKH, die die Eigenschaft haben, den Zugriff auf einen neuen Gruppenschlüssel durch ein aus der Gruppe entferntes Mitglied zu verweigern (Vorwärtszugriffskontrolle) und auf einen alten Gruppenschlüssel durch ein zur Gruppe hinzugefügtes Mitglied (Rückwärtszugriffskontrolle). Ein von PFS unabhängiger Begriff, „Vorwärtszugriffskontrolle" und „Rückwärtszugriffskontrolle" wurden in der Literatur [RFC2627] als „perfekte Vorwärtssicherheit" und „perfekte Rückwärtssicherheit" bezeichnet.

Gruppenverwaltungsalgorithmen, die Vorwärts- und Rückwärtszugriffskontrolle bieten, außer LKH wurden in der Literatur vorgeschlagen, einschließlich OFT [OFT] und Subset Difference [NNL]. Diese Algorithmen könnten mit GDOI verwendet werden, sind aber nicht als Teil dieses Dokuments spezifiziert.

Die Unterstützung für Gruppenverwaltungsalgorithmen wird über das KEY_MANAGEMENT_ALGORITHM Attribut unterstützt, das in der SA_KEK Payload gesendet wird. GDOI spezifiziert eine Methode, durch die LKH für Vorwärts- und Rückwärtszugriffskontrolle verwendet werden kann. Andere Methoden zur Verwendung von LKH sowie andere Gruppenverwaltungsalgorithmen wie OFT oder Subset Difference können (MAY) zu GDOI als Teil eines späteren Dokuments hinzugefügt werden. Jede solche Hinzufügung muss (MUST) auf eine Standards Action gemäß [RFC2434] zurückzuführen sein.

4.2.1. Anforderungen an die Vorwärtszugriffskontrolle (Forward Access Control Requirements)

Wenn die Gruppenmitgliedschaft mithilfe eines Gruppenverwaltungsalgorithmus geändert wird, sind normalerweise auch neue SA_TEKs (und ihre zugehörigen Schlüssel) erforderlich. Neue SAs und Schlüssel stellen sicher, dass Mitglieder, denen der Zugriff verweigert wurde, nicht mehr an der Gruppe teilnehmen können.

Wenn Vorwärtszugriffskontrolle eine gewünschte Eigenschaft der Gruppe ist, dürfen (MUST NOT) neue SA_TEKs und die zugehörigen Schlüsselpakete in der KD Payload nicht in eine GROUPKEY-PUSH Nachricht aufgenommen werden, die die Gruppenmitgliedschaft ändert. Dies ist erforderlich, da die SA_TEK Richtlinie und die zugehörigen Schlüsselpakete in der KD Payload nicht mit dem neuen KEK geschützt sind. Eine zweite GROUPKEY-PUSH Nachricht kann die neuen SA_TEKS und ihre zugehörigen Schlüssel liefern, da sie mit dem neuen KEK geschützt wird und somit für die Mitglieder, denen der Zugriff verweigert wurde, nicht sichtbar ist.

Wenn die Vorwärtszugriffskontrollrichtlinie für die Gruppe das Fernhalten von Gruppenrichtlinienänderungen von Mitgliedern einschließt, denen der Zugriff auf die Gruppe verweigert wird, dann müssen (MUST) zwei sequenzielle GROUPKEY-PUSH Nachrichten, die den Gruppen-KEK ändern, vom GCKS gesendet werden. Die erste GROUPKEY-PUSH Nachricht erstellt einen neuen KEK für die Gruppe. Gruppenmitglieder, denen der Zugriff verweigert wird, können nicht auf den neuen KEK zugreifen, sehen aber die Gruppenrichtlinie, da die GROUPKEY-PUSH Nachricht unter dem aktuellen KEK geschützt ist. Eine nachfolgende GROUPKEY-PUSH Nachricht, die die geänderte Gruppenrichtlinie enthält und erneut den KEK ändert, ermöglicht vollständige Vorwärtszugriffskontrolle. Eine GROUPKEY-PUSH Nachricht darf (MUST NOT) die Richtlinie nicht ändern, ohne einen neuen KEK zu erstellen.

Wenn andere Methoden zur Verwendung von LKH oder andere Gruppenverwaltungsalgorithmen zu GDOI hinzugefügt werden, können (MAY) diese Methoden die oben genannten Einschränkungen aufheben, die mehrere GROUPKEY-PUSH Nachrichten erfordern, vorausgesetzt, diese Methoden spezifizieren, wie die Vorwärtszugriffskontrollrichtlinie innerhalb einer einzelnen GROUPKEY-PUSH Nachricht beibehalten wird.

4.3. Delegation der Schlüsselverwaltung (Delegation of Key Management)

GDOI unterstützt die Delegation von GROUPKEY-PUSH Datagrammen durch die Delegationsfähigkeiten der PKI. GDOI spezifiziert jedoch nicht explizit, wie der GCKS Delegaten identifiziert, sondern überlässt dies der PKI, die von einer bestimmten GDOI-Implementierung verwendet wird.

4.4. Verwendung von Signaturschlüsseln (Use of Signature Keys)

Der GCKS sollte nicht (SHOULD NOT) denselben Schlüssel zum Signieren der SIG Payload in der GROUPKEY-PUSH Nachricht verwenden wie für die Autorisierung in der GROUPKEY-PULL POP Payload. Wenn derselbe Schlüssel verwendet werden muss, sollte (SHOULD) eine andere Hash-Funktion als Basis für die POP Payload verwendet werden als für die SIG Payload.