RFC 3547 - Die Group Domain of Interpretation (The Group Domain of Interpretation)

• Status: Proposed Standard
• Veröffentlicht: July 2003
• Stream: IETF
• Ersetzt durch: RFC6407
• Errata: Keine Errata

---

Zusammenfassung (Abstract)

Dieses Dokument stellt eine ISAKMP Domain of Interpretation (DOI) für die Gruppenschlüsselverwaltung vor, um sichere Gruppenkommunikation zu unterstützen. Das GDOI verwaltet Gruppen-Security-Associations, die von IPsec und möglicherweise weiteren Data-Security-Protokollen auf IP- oder Anwendungsebene genutzt werden. Diese Security Associations schützen einen oder mehrere Key-Encrypting Keys, Traffic-Encrypting Keys oder Daten, die von Gruppenmitgliedern gemeinsam genutzt werden.

---

Inhaltsverzeichnis (Table of Contents)

• 1. Einleitung
  • 1.1. GDOI-Anwendungen
  • 1.2. Erweiterung von GDOI
• 2. GDOI Phase-1-Protokoll
  • 2.1. ISAKMP Phase-1-Protokoll
    • 2.1.1. DOI-Wert
    • 2.1.2. UDP-Port
• 3. GROUPKEY-PULL-Austausch
  • 3.1. Autorisierung
  • 3.2. Nachrichten
    • 3.2.1. Perfect Forward Secrecy
    • 3.2.2. Initialisierung des ISAKMP-Headers
  • 3.3. Operationen des Initiators
  • 3.4. Operationen des Empfängers
• 4. GROUPKEY-PUSH-Nachricht
  • 4.1. Perfect Forward Secrecy (PFS)
  • 4.2. Vorwärts- und Rückwärts-Zugriffskontrolle
    • 4.2.1. Anforderungen an die Vorwärts-Zugriffskontrolle
  • 4.3. Delegation der Schlüsselverwaltung
  • 4.4. Verwendung von Signaturschlüsseln
  • 4.5. Initialisierung des ISAKMP-Headers
  • 4.6. Löschung von SAs
  • 4.7. GCKS-Operationen
  • 4.8. Operationen der Gruppenmitglieder
• 5. Payloads und definierte Werte
  • 5.1. Identification Payload
    • 5.1.1. Werte des Identification Type
  • 5.2. Security Association Payload
  • 5.3. SA KEK Payload
  • 5.4. SA TEK Payload
  • 5.5. Key Download Payload
  • 5.6. Sequence Number Payload
  • 5.7. Proof of Possession
  • 5.8. Nonce
• 6. Sicherheitsbetrachtungen
  • 6.1. ISAKMP Phase 1
  • 6.2. GROUPKEY-PULL-Austausch
  • 6.3. GROUPKEY-PUSH-Austausch
• 7. IANA-Betrachtungen
• 8. Erklärung zu Rechten des geistigen Eigentums
• 9. Danksagungen
• 10. Referenzen
  • 10.1. Normative Referenzen
  • 10.2. Informative Referenzen

Anhänge (Appendices)

• Anhang A: Alternative GDOI Phase-1-Protokolle
  • A.1. IKEv2 Phase-1-Protokoll
  • A.2. KINK-Protokoll

---

Weiterführende Ressourcen (Related Resources)

• Offizieller Text: RFC 3547 (TXT)
• Offizielle Seite: RFC 3547 DataTracker
• Errata: RFC Editor Errata

---

5.1.1. Werte des Identification Type (Identification Type Values)

Die folgende Tabelle listet die zugewiesenen Werte für das Feld Identification Type (Identifikationstyp) in der Identification Payload auf.

ID-Typ (ID Type)	Wert (Value)
RESERVED	0 - 10
ID_KEY_ID	11
RESERVED	12 - 127
Private Use	128 - 255

5.1.1.1. ID_KEY_ID

Im Kontext einer GDOI-ID-Payload gibt ID_KEY_ID eine vier (4) Oktett lange Gruppenkennung (group identifier) an.

Hinweise zur Verwendung

• Wert von ID_KEY_ID: 11
• Länge: 4 Oktette
• Zweck: eindeutige Identifizierung einer GDOI-Gruppe
• Anwendungsfall: wird im GROUPKEY-PULL-Austausch und in GROUPKEY-PUSH-Nachrichten verwendet, um die Zielgruppe zu identifizieren

Erläuterung der reservierten Werte

• 0 - 10: für zukünftige Verwendung reserviert
• 12 - 127: für zukünftige Standardisierung reserviert
• 128 - 255: für private Implementierungen oder experimentelle Erweiterungen nutzbar

Überlegungen zur Interoperabilität

Implementierungen müssen ID_KEY_ID (Wert 11) unterstützen, um die grundlegende Interoperabilität des GDOI-Protokolls sicherzustellen. Nicht erkannte ID-Typ-Werte sollten ignoriert oder gemäß der ISAKMP-Spezifikation behandelt werden.