Zusammenfassung

  • Im grundlegenden Forward-Access-Control-Ablauf von RFC 9838 erzeugt die Mitgliedschaftsänderung zuerst eine neue KEK. Erst ein weiterer Rekey liefert neue TEK-Richtlinien und Schlüssel unter diesem Schutz.
  • Multicast-GSA_REKEY wird nicht bestätigt und kann verloren gehen. Identische Wiederholungen und GSA_NEXT_SPI unterstützen die Wiederherstellung, belegen aber keinen installierten Zustand jedes Mitglieds.
  • ATD verzögert die Nutzung neuer SAs, DTD die Löschung alter SAs. Der Ausschlussnachweis muss dieses Überlappungsfenster abdecken.

Der Administrator hat das Mitglied entfernt. Der Schlüsselserver muss diese Entscheidung erst in verteilte Wirklichkeit verwandeln.

RFC 9838 standardisiert Group Key Management Using IKEv2. Der RFC-Editor-Eintrag nennt November 2025, Standards Track und die Ablösung von RFC 6407. Dokumentstatus ist kein Betriebsnachweis.

Die Grundlage bilden die MSEC-Architekturen aus RFC 3740, RFC 4046 und RFC 5374. Ein GCKS authentisiert und autorisiert Gruppenmitglieder und verteilt eine Group Security Association mit Richtlinien und Schlüsseln für Data-Security SAs sowie gegebenenfalls eine Multicast-Rekey-SA.

IKEv2 liefert die bilaterale Beziehung; IPsec, AH und ESP liefern SA- und Paketschutzsemantik. G-IKEv2 überträgt sie auf eine Gruppe, deren Empfänger keinen gemeinsamen Empfangsbeleg erzeugen.

Der erste Wechsel gehört noch zur alten Vertrauenswelt

Forward Access Control entzieht einem ausgeschlossenen Mitglied den Zugang zum nächsten Gruppenschlüssel. Backward Access Control hält alte Schlüssel von neuen Mitgliedern fern. Beides ist laut RFC nicht mit Perfect Forward Secrecy gleichzusetzen.

Die Nachricht, die die Mitgliedschaft ändert, ist noch mit der aktuellen KEK geschützt. Würde sie neue TEK-Richtlinie und Schlüssel mitführen, könnte das zu entfernende Mitglied sie lesen. Deshalb darf diese erste Nachricht bei gefordertem Vorwärtsausschluss kein neues TEK-Material enthalten. Eine zweite Nachricht liefert es unter der neuen KEK.

Soll auch die geänderte Richtlinie verborgen bleiben, müssen zwei aufeinanderfolgende Rekeys jeweils die KEK ändern. Der erste schafft eine KEK außerhalb des alten Mitglieds, der zweite ändert KEK und Richtlinie erneut. Eine Richtlinienänderung ohne neue KEK ist verboten.

Andere künftige Verfahren dürfen die Mehrfachnachrichten vermeiden, wenn sie Forward Access Control in einer Nachricht sauber definieren. RFC 2627 erläutert die logische Schlüsselhierarchie. Zwei Wechsel sind daher die zu prüfende Basissequenz, kein Dogma über jeden Algorithmus.

Senden ist nicht Installieren

Neben Unicast-Inband-Rekeying kennt G-IKEv2 den einseitigen Multicast-GSA_REKEY. Er wird nicht bestätigt. Verlust kann berechtigte Mitglieder im alten Zustand lassen.

Der GCKS darf mehrere bitweise identische verschlüsselte Kopien in wenigen Sekunden senden. GSA_NEXT_SPI kann künftige SPIs ankündigen, damit Empfänger Lücken erkennen und sich erholen. Beides steigert Zustellwahrscheinlichkeit, erzeugt aber keine Mitglied-für-Mitglied-Bestätigung.

Bei Fragmentierung gilt dieselbe Grenze. RFC 7383 hilft bei großen IKE-Nachrichten, doch Multicast erlaubt weder einen unfragmentierten Testlauf noch antwortbasiertes PMTU. Ein vorkonfigurierter Schwellwert entscheidet. Gruppengröße und Schlüsselbaum werden damit Teil des Ausschlussrisikos.

Zwei Verzögerungen schaffen eine reale Übergangszone

ATD bestimmt, wann Sender neue SAs verwenden. DTD bestimmt, wann Mitglieder alte SAs löschen. Die Überlappung schützt Verfügbarkeit, hält aber alte Wirkung absichtlich eine Zeit lang am Leben.

Ein brauchbarer Nachweis trennt Entzug der Autorisierung, Erzeugung der neuen KEK, Installation der neuen TEK, Aktivierung der neuen SA und Löschung der alten SA. Ein Verkehrsversuch mit dem entfernten Berechtigungsnachweis begrenzt den letzten tatsächlich erfolgreichen Zugriff.

Zählermodi verlangen zusätzlich eindeutige Sender-IDs und Nonce-Disziplin. Auf Basis von RFC 6054 werden bei jeder Registrierung neue Sender-IDs vergeben, weil der GCKS verbrauchte Nonces nicht zuverlässig kennt. Bei Erschöpfung muss er alle Mitglieder ausschließen und mit neuen Data-Security SAs registrieren lassen. RFC 8221 und RFC 8750 ändern diese Zustandsverantwortung nicht.

Replay-Schutz ist ebenfalls nicht pauschal. Viele Sender in einer SA erhöhen Sequenznummern unabhängig; ein gemeinsames Replay-Fenster kann unmöglich werden. Empfänger entscheiden lokal über die Prüfung. Der GCKS kann Sender auf getrennte SAs verteilen und dafür mehr Zustand tragen.

Das IANA-IKEv2-Register, die Normsprache aus RFC 8174 und der Vorgänger RFC 6407 dokumentieren Protokoll und Geschichte, nicht den installierten Bestand.

Heng Lus Prinzip einer minimalen Anfangsspezifikation mit lokalisierten späteren Entscheidungen weist die Rollen richtig zu: gemeinsame Semantik im Standard, Ausschlussziel und Messung beim Betreiber. Running-Code-Primat stellt installierte Schlüssel über Ticketstatus. Realität als Produkt verhindert, dass Standards Track als Einsatzgarantie ausgegeben wird.

Quellen