Zum Hauptinhalt springen

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

Das Ziel des GROUPKEY-PULL Austauschs ist es, beim Mitglied für eine bestimmte Gruppe Re-key- und/oder Datensicherheits-SAs einzurichten. Eine Phase 1 SA schützt den GROUPKEY-PULL; es kann (MAY) mehrere GROUPKEY-PULL Austausche für eine gegebene Phase 1 SA geben. Der GROUPKEY-PULL Austausch lädt die Datensicherheitsschlüssel (TEKs) und/oder den Gruppenschlüssel-Verschlüsselungsschlüssel (KEK) oder das KEK-Array unter dem Schutz der Phase 1 SA herunter.

3.1. Autorisierung (Authorization)​

Es gibt zwei alternative Mittel zur Autorisierung der GROUPKEY-PULL Nachricht. Erstens kann die Phase 1 Identität verwendet werden, um die Phase 2 (GROUPKEY-PULL) Anfrage für einen Gruppenschlüssel zu autorisieren. Zweitens kann eine neue Identität in der GROUPKEY-PULL Anfrage übergeben werden. Die neue Identität könnte gruppenspezifisch sein und ein Zertifikat verwenden, das vom Gruppenbesitzer signiert ist, um den Inhaber als autorisiertes Gruppenmitglied zu identifizieren. Die Proof-of-Possession Payload (Besitznachweis-Nutzlast) validiert, dass der Inhaber den geheimen Schlüssel besitzt, der mit der Phase 2 Identität verbunden ist.

3.2. Nachrichten (Messages)​

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

Der GROUPKEY-PULL verwendet Nonces, um „Lebendigkeit" (Liveliness) zu garantieren, oder gegen Replay einer kürzlichen GROUPKEY-PULL Nachricht. Der Replay-Angriff ist nur im Kontext der aktuellen Phase 1 nützlich. Wenn eine GROUPKEY-PULL Nachricht basierend auf einer vorherigen Phase 1 wiederholt wird, schlägt die HASH-Berechnung aufgrund eines falschen SKEYID_a fehl. Die Nachricht schlägt bei der Verarbeitung fehl, bevor die Nonce jemals ausgewertet wird. Damit einer der Peers von dem Replay-Schutz profitieren kann, muss er so viel Verarbeitung wie möglich verschieben, bis er die Nachricht im Protokoll empfängt, die beweist, dass der Peer lebendig ist. Zum Beispiel darf der Responder nicht (MUST NOT) die gemeinsame Diffie-Hellman Zahl berechnen (falls KE Payloads enthalten waren) oder die neuen SAs installieren, bis er eine Nachricht mit korrekt in der HASH Payload enthalteneם Nr empfängt.

Nonces erfordern eine zusätzliche Nachricht im Protokollaustausch, um sicherzustellen, dass der GCKS kein Gruppenmitglied hinzufügt, bis es die Lebendigkeit beweist. Der GROUPKEY-PULL Mitglied-Initiator erwartet, seine Nonce, Ni, im HASH einer zurückgegebenen Nachricht zu finden. Und der GROUPKEY-PULL GCKS Responder erwartet, seine Nonce, Nr, im HASH einer zurückgegebenen Nachricht zu sehen, bevor er Gruppenschlüsselmaterial bereitstellt, wie im folgenden Austausch.

Initiator (Mitglied)                 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]

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: Geschützt durch die Phase 1 SA, erfolgt die Verschlüsselung nach HDR

HDR ist eine ISAKMP Header Payload, die die Phase 1 Cookies und eine Nachrichtenkennung (M-ID) wie in IKE [RFC2409] verwendet. Beachten Sie, dass Nonces in den ersten beiden Austauschen enthalten sind, wobei der GCKS nur die SA-Richtlinien-Payload zurückgibt, bevor die Lebendigkeit bewiesen ist. Die HASH Payloads [RFC2409] beweisen, dass der Peer das Phase 1 Geheimnis (SKEYID_a) und die Nonce für den durch die Nachrichten-ID, M-ID, identifizierten Austausch besitzt. Sobald die Lebendigkeit etabliert ist, vervollständigt die letzte Nachricht die tatsächliche Verarbeitung des Herunterladens der KD Payload.

Zusätzlich zu den Nonce- und HASH-Payloads identifiziert der Mitglied-Initiator die Gruppe, der er beitreten möchte, über die ISAKMP ID Payload. Der GCKS Responder informiert das Mitglied über den aktuellen Wert der Sequenznummer in der SEQ Payload; die Sequenznummer ordnet die GROUPKEY-PUSH Datagramme (Abschnitt 4); das Mitglied muss (MUST) überprüfen, dass die Sequenznummer größer ist als in der vorherigen SEQ Payload, die das Mitglied für die Gruppe hält (falls es eine hält), bevor es neue SAs installiert. Die SEQ Payload muss (MUST) vorhanden sein, wenn die SA Payload ein SA KEK Attribut enthält.

3.2.1. Perfekte Vorwärtsgeheimhaltung (Perfect Forward Secrecy)​

Perfekte Vorwärtsgeheimhaltung (Perfect Forward Secrecy, PFS) für den GROUPKEY-PULL wird durch die optionale Einbeziehung der Key Exchange (KE) Payload erreicht, wie in RFC 2409 beschrieben. Wenn KE verwendet wird, gibt es einen Diffie-Hellman Austausch als Teil des GROUPKEY-PULL. Dies stellt sicher, dass der TEK oder KEK nicht ohne Zugriff auf die Diffie-Hellman Schlüsselvereinbarung wiederhergestellt werden kann.

3.2.2. ISAKMP Header Initialisierung (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 die Phase 1 Cookies.
  • Die Nachrichten-ID wird vom Initiator zufällig generiert und dient zum Abgleich von REQUEST und REPLY.
  • Die nächste Payload ist HASH.
  • Der Austauschtyp ist GDOI_GROUPKEY_PULL (Wert 32).

3.3. Initiator-Operationen (Initiator Operations)​

Der GROUPKEY-PULL Initiator muss (MUST) eine Nonce, Ni, generieren und alle Nachrichten mit einer Phase 1 SA schützen. Die Phase 1 SA bietet Verschlüsselung und Datenursprungsauthentifizierung für alle GROUPKEY-PULL Payloads.

3.4. Empfänger-Operationen (Receiver Operations)​

Der GROUPKEY-PULL Responder (GCKS) muss (MUST) alle HASH Payloads verifizieren und dann nachfolgende Payloads entschlüsseln. Der GCKS muss (MUST) überprüfen, dass die Nonces, Ni und Nr, in den HASH-Berechnungen mit den in den Klartext-Payloads gesendeten Nonces übereinstimmen. Wenn die HASH Payload Verifizierung fehlschlägt, muss (MUST) der GCKS die Nachricht ablehnen und kann (MAY) das Ereignis auditieren.

Der GCKS muss (MUST) die Autorisierung von Gruppenmitgliedern durch eine Richtlinie validieren, die außerhalb des Geltungsbereichs dieses Dokuments liegt.

Letztes Update am