Zum Hauptinhalt springen

3. GROUPKEY-PULL-Austausch (GROUPKEY-PULL Exchange)

Ziel des GROUPKEY-PULL-Austauschs ist es, beim Mitglied eine Re-key- und/oder Data-security-SA für eine bestimmte Gruppe einzurichten. Eine Phase-1-SA schützt den GROUPKEY-PULL; für eine gegebene Phase-1-SA MAY es mehrere GROUPKEY-PULL-Austausche geben. Der GROUPKEY-PULL-Austausch lädt die Data-Security-Schlüssel (TEKs) und/oder den Group Key Encrypting Key (KEK) bzw. das KEK-Array unter dem Schutz der Phase-1-SA herunter.

3.1. Autorisierung (Authorization)​

Es gibt zwei alternative Möglichkeiten, die GROUPKEY-PULL-Nachricht zu autorisieren. Erstens kann die Phase-1-Identität verwendet werden, um die Phase-2-Anforderung (GROUPKEY-PULL) eines Gruppenschlüssels zu autorisieren. Zweitens kann in der GROUPKEY-PULL-Anforderung eine neue Identität übergeben werden. Diese neue Identität könnte gruppenspezifisch sein und ein vom Gruppeneigentümer signiertes Zertifikat verwenden, um den Inhaber als autorisiertes Gruppenmitglied auszuweisen. Die Proof-of-Possession-Payload weist nach, dass der Inhaber den zur Phase-2-Identität gehörenden geheimen Schlüssel besitzt.

3.2. Nachrichten (Messages)​

Der GROUPKEY-PULL ist ein Phase-2-Austausch. In Phase 1 wird SKEYID_a berechnet, welches den "Schlüssel" im Keyed Hash darstellt, der in den HASH-Payloads des GROUPKEY-PULL verwendet wird. Bei Verwendung der in diesem Dokument definierten Phase 1 wird SKEYID_a gemäß [RFC2409] abgeleitet. Wie bei der Erzeugung der IKE-HASH-Payload [RFC 2409 Abschnitt 5.5] hasht jede GROUPKEY-PULL-Nachricht einen eindeutig definierten Satz von Werten. Nonces permutieren den HASH und bieten einen gewissen Schutz gegen Replay-Angriffe. Replay-Schutz ist wichtig, um den GCKS vor Angriffen zu schützen, die ein Schlüsselverwaltungsserver zwangsläufig anzieht.

Der GROUPKEY-PULL verwendet Nonces, um "Liveliness" (Lebendigkeit) zu garantieren bzw. um sich gegen das Wiedereinspielen einer kürzlich gesendeten GROUPKEY-PULL-Nachricht zu schützen. Der Replay-Angriff ist nur im Kontext der aktuellen Phase 1 von Nutzen. Wird eine GROUPKEY-PULL-Nachricht auf Basis einer früheren Phase 1 wiedereingespielt, schlägt die HASH-Berechnung aufgrund eines falschen SKEYID_a fehl. Die Verarbeitung der Nachricht scheitert, noch bevor die Nonce überhaupt ausgewertet wird. Damit einer der beiden Peers vom Replay-Schutz profitieren kann, muss er so viel Verarbeitung wie möglich aufschieben, bis er diejenige Nachricht des Protokolls empfängt, die die Lebendigkeit des Peers belegt. Beispielsweise MUST NOT der Responder die gemeinsame Diffie-Hellman-Zahl berechnen (sofern KE-Payloads enthalten waren) oder die neuen SAs installieren, bevor er eine Nachricht empfängt, in der Nr ordnungsgemäß in der HASH-Payload enthalten ist.

Nonces erfordern eine zusätzliche Nachricht im Protokollaustausch, um sicherzustellen, dass der GCKS ein Gruppenmitglied erst dann aufnimmt, wenn dessen Lebendigkeit nachgewiesen ist. Der GROUPKEY-PULL-Initiator (das Mitglied) erwartet, seine Nonce Ni im HASH einer zurückgesendeten Nachricht vorzufinden. Und der GROUPKEY-PULL-Responder (der GCKS) erwartet, seine Nonce Nr im HASH einer zurückgesendeten Nachricht zu sehen, bevor er Gruppenschlüsselmaterial bereitstellt, wie im folgenden Austausch dargestellt.

Initiator (Member)                   Responder (GCKS)
------------------                   ----------------
HDR*, HASH(1), Ni, ID     -->
                          <--     HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I]     -->
   [,CERT] [,POP_I]
                          <--     HDR*, HASH(4),[KE_R,][SEQ,]
                                    KD [,CERT] [,POP_R]

Die Hashes werden wie folgt berechnet:

HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | CERT ] [ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ] KD [ | CERT ] [ | POP_R])

Die POP-Payload wird wie in Abschnitt 5.7 beschrieben konstruiert.

Hinweis: Durch die Phase-1-SA geschützt; die Verschlüsselung erfolgt nach HDR.

HDR ist eine ISAKMP-Header-Payload, die die Phase-1-Cookies und einen Message Identifier (M-ID) verwendet, wie in IKE [RFC2409]. Zu beachten ist, dass die Nonces in den ersten beiden Austauschen enthalten sind, wobei der GCKS vor dem Nachweis der Lebendigkeit lediglich die SA-Policy-Payload zurückgibt. Die HASH-Payloads [RFC2409] belegen, dass der Peer das Phase-1-Geheimnis (SKEYID_a) sowie die Nonce für den durch die Message-ID M-ID identifizierten Austausch besitzt. Sobald die Lebendigkeit festgestellt ist, schließt die letzte Nachricht die eigentliche Verarbeitung des Herunterladens der KD-Payload ab.

Zusätzlich zu den Nonce- und HASH-Payloads gibt der Initiator (das Mitglied) über die ISAKMP-ID-Payload die Gruppe an, der er beitreten möchte. Der GCKS-Responder teilt dem Mitglied den aktuellen Wert der Sequenznummer in der SEQ-Payload mit; die Sequenznummer ordnet die GROUPKEY-PUSH-Datagramme (Abschnitt 4). Das Mitglied MUST prüfen, ob die Sequenznummer größer ist als diejenige in der vorherigen SEQ-Payload, die das Mitglied für die Gruppe vorhält (sofern vorhanden), bevor es neue SAs installiert. Die SEQ-Payload MUST vorhanden sein, wenn die SA-Payload ein SA-KEK-Attribut enthält.

3.2.1. Perfect Forward Secrecy​

Perfect Forward Secrecy (PFS) wird für den GROUPKEY-PULL durch die optionale Aufnahme der Key-Exchange-Payload (KE) erreicht, wie in RFC 2409 beschrieben. Wird das KE verwendet, findet im Rahmen des GROUPKEY-PULL ein Diffie-Hellman-Austausch statt. Dies stellt sicher, dass der TEK oder KEK ohne Zugriff auf die Diffie-Hellman-Schlüsselvereinbarung nicht wiederhergestellt werden kann.

3.2.2. Initialisierung des ISAKMP-Headers (ISAKMP Header Initialization)​

Die HDR-Felder für den GROUPKEY-PULL werden wie folgt initialisiert:

  • Die Cookies stammen aus Phase 1. Jeder GROUPKEY-PULL teilt sich die Phase-1-Cookies.
  • Die Message-ID wird vom Initiator zufällig erzeugt und dient der Zuordnung von REQUEST und REPLY.
  • Die nächste Payload (Next Payload) ist HASH.
  • Der Exchange Type ist GDOI_GROUPKEY_PULL (Wert 32).

3.3. Operationen des Initiators (Initiator Operations)​

Der GROUPKEY-PULL-Initiator MUST eine Nonce Ni erzeugen und alle Nachrichten mit einer Phase-1-SA schützen. Die Phase-1-SA stellt Verschlüsselung und Datenursprungsauthentifizierung für alle GROUPKEY-PULL-Payloads bereit.

3.4. Operationen des Empfängers (Receiver Operations)​

Der GROUPKEY-PULL-Responder (GCKS) MUST alle HASH-Payloads verifizieren und anschließend die nachfolgenden Payloads entschlüsseln. Der GCKS MUST prüfen, dass die Nonces Ni und Nr in den HASH-Berechnungen mit den in den Klartext-Payloads gesendeten Nonces übereinstimmen. Schlägt die Verifikation der HASH-Payload fehl, MUST der GCKS die Nachricht zurückweisen und MAY das Ereignis protokollieren (Audit).

Der GCKS MUST die Autorisierung von Gruppenmitgliedern anhand von Richtlinien validieren, die außerhalb des Geltungsbereichs dieses Dokuments liegen.