Zum Hauptinhalt springen

1. Einleitung (Introduction)

Dieses Dokument stellt eine ISAKMP Domain of Interpretation (DOI) für die Gruppenschlüsselverwaltung vor, die als "Group Domain of Interpretation" (GDOI) bezeichnet wird. In diesem Modell der Gruppenschlüsselverwaltung wird das GDOI-Protokoll zwischen einem Gruppenmitglied und einem "Group Controller/Key Server" (GCKS) ausgeführt, der Security Associations [Abschnitt 4.6.2 RFC2401] zwischen autorisierten Gruppenmitgliedern einrichtet. ISAKMP definiert zwei "Phasen" der Aushandlung [S. 16 RFC2408]. Das GDOI MUST durch eine Phase-1-Security-Association geschützt werden. Dieses Dokument übernimmt die Definition der Phase-1-Security-Association (SA) aus der Internet DOI [RFC2407, RFC2409]. Weitere mögliche Typen von Phase-1-Security-Associations sind in Anhang A aufgeführt. Der Phase-2-Austausch wird in diesem Dokument definiert und schlägt neue Payloads und Austausche gemäß dem ISAKMP-Standard [S. 14 RFC2408] vor.

Es gibt sechs neue Payloads:

  1. GDOI SA
  2. SA KEK (SAK), die auf die SA-Payload folgt
  3. SA TEK (SAT), die auf die SA-Payload folgt
  4. Key Download Array (KD)
  5. Sequence Number (SEQ)
  6. Proof of Possession (POP)

Es gibt zwei neue Austausche.

1) Ein Phase-2-Austausch erzeugt Re-key- und Data-Security-Protocol-SAs.

Der neue Phase-2-Austausch mit der Bezeichnung "GROUPKEY-PULL" lädt Schlüssel für die "Re-key"-SA und/oder die "Data-security"-SA einer Gruppe herunter. Die Re-key-SA umfasst einen Key Encrypting Key (KEK), der für die gesamte Gruppe gilt; eine Data-security-SA umfasst einen Datenverschlüsselungsschlüssel (TEK), der von einem Data-Security-Protokoll zur Ver- oder Entschlüsselung des Datenverkehrs verwendet wird [Abschnitt 2.1 RFC2407]. Die SA für den KEK oder TEK umfasst Authentifizierungsschlüssel, Verschlüsselungsschlüssel, kryptografische Richtlinien und Attribute. Der GROUPKEY-PULL-Austausch verwendet ein "Pull"-Verhalten, da das Mitglied den Abruf dieser SAs von einem GCKS initiiert.

2) Ein Datagramm richtet anschließend zusätzliche Re-key- und/oder Data-Security-Protocol-SAs ein.

Das GROUPKEY-PUSH-Datagramm wird vom GCKS an die Mitglieder "gepusht", um eine Re-key- oder Data-security-SA zu erzeugen oder zu aktualisieren. Eine Re-key-SA schützt GROUPKEY-PUSH-Nachrichten. Daher ist ein GROUPKEY-PULL erforderlich, um mindestens eine Re-key-SA einzurichten, damit nachfolgende GROUPKEY-PUSH-Nachrichten geschützt werden können. Der GCKS verschlüsselt die GROUPKEY-PUSH-Nachricht mit der KEK-Re-key-SA. GDOI unterstützt die Verwendung von KEK-Arrays für Algorithmen zur Gruppenschlüsselverwaltung, die den Logical Key Hierarchy (LKH)-Algorithmus einsetzen, um Gruppenmitglieder effizient hinzuzufügen und zu entfernen [RFC2627]. Die Implementierung des LKH-Algorithmus ist OPTIONAL.

Obwohl das in diesem Dokument spezifizierte GROUPKEY-PUSH zur Auffrischung einer Re-key-SA verwendet werden kann, besteht der häufigste Einsatz von GROUPKEY-PUSH darin, eine Data-security-SA für ein Data-Security-Protokoll einzurichten. GDOI kann künftige Erweiterungen zur Unterstützung einer Vielzahl von Data-Security-Protokollen aufnehmen. Dieses Dokument spezifiziert Data-security-SAs nur für ein Sicherheitsprotokoll, nämlich IPsec ESP. Ein separates RFC wird die Unterstützung anderer Data-Security-Protokolle wie eines künftigen sicheren Real-time Transport Protocol spezifizieren. Ein Sicherheitsprotokoll verwendet den TEK und "besitzt" die Data-security-SA in derselben Weise, in der IPsec ESP die IKE-Phase-2-Schlüssel verwendet und die Phase-2-SA besitzt; bei GDOI verwendet IPsec ESP den TEK.

GDOI ist somit ein Protokoll zur Verwaltung von Gruppen-Security-Associations: Alle GDOI-Nachrichten dienen dazu, Security Associations für eine Gruppe zu erzeugen, zu pflegen oder zu löschen. Wie oben beschrieben, schützen diese Security Associations einen oder mehrere Key-Encrypting Keys, Traffic-Encrypting Keys oder Daten, die von Gruppenmitgliedern für Multicast- und Gruppensicherheitsanwendungen gemeinsam genutzt werden.

Die Schlüsselwörter MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY und OPTIONAL sind, wenn sie in diesem Dokument erscheinen, gemäß BCP 14, RFC 2119 [RFC2119] zu interpretieren.

1.1. GDOI-Anwendungen (GDOI Applications)​

Zu den sicheren Multicast-Anwendungen zählen Videoübertragung (Video Broadcast) und Multicast-Dateiübertragung. In einer Unternehmensumgebung erfordern viele dieser Anwendungen Netzwerksicherheit und können IPsec ESP zur Absicherung ihres Datenverkehrs einsetzen. Abschnitt 5.4.1 spezifiziert, wie GDOI die benötigten SA-Parameter für ESP transportiert. Auf diese Weise unterstützt GDOI Multicast-ESP mit Gruppenauthentifizierung von ESP-Paketen unter Verwendung des gemeinsamen Gruppenschlüssels (eine Authentifizierung einzelner Quellen von ESP-Paketen ist nicht möglich).

GDOI kann auch Gruppenanwendungen absichern, die keinen Multicast-Transport verwenden, wie etwa Video-on-Demand. Beispielsweise kann die GROUPKEY-PUSH-Nachricht eine paarweise IPsec-ESP-SA für ein Mitglied einer Abonnementgruppe einrichten, ohne dass Schlüsselverwaltungsaustausche und kostspielige asymmetrische Kryptografie erforderlich sind.

1.2. Erweiterung von GDOI (Extending GDOI)​

Nicht alle sicheren Multicast- oder Multimedia-Anwendungen können IPsec ESP verwenden. Beispielsweise benötigen viele Anwendungen des Real Time Transport Protocol Sicherheit oberhalb der IP-Schicht, um die Effizienz der RTP-Header-Komprimierung und die Transportunabhängigkeit zu bewahren [RFC3550]. Ein künftiges RTP-Sicherheitsprotokoll könnte davon profitieren, GDOI zur Einrichtung von Gruppen-SAs zu nutzen.

Um ein neues Data-Security-Protokoll hinzuzufügen, MUST ein neues RFC die Data-security-SA-Parameter spezifizieren, die GDOI für dieses Sicherheitsprotokoll transportiert; diese Parameter sind in Abschnitt 5.4.2 dieses Dokuments aufgeführt.

Eine Data-Security-Protocol-SA MUST Gruppenverkehr schützen. GDOI legt keine Einschränkung dahingehend fest, ob dieser Gruppenverkehr als Unicast- oder Multicast-Pakete zugestellt wird. GDOI MUST NOT jedoch von einem Data-Security-Protokoll als Schlüsselverwaltungsmechanismus verwendet werden, wenn die durch die Data-security-SA geschützten Pakete privat bleiben sollen und niemals Teil einer Gruppenkommunikation sein werden.