Zusammenfassung

  • In RFC 9594 erlaubt der Authorization Server einem Client den Zugriff auf eine Gruppenmitgliedschaftsressource; erst ein erfolgreicher Join beim KDC erzeugt die Mitgliedschaft und liefert profiliertes Schlüsselmaterial.
  • Ausgestelltes Token, Mitgliederdatensatz, installierte Schlüsselversion und erfolgreiche Gruppenoperation sind getrennte Tatsachen mit getrennten Belegen.

Das Identity-System meldet Erfolg: Signatur gültig, Scope passend, Rolle erlaubt, Ablaufdatum in der Zukunft. In vielen Dashboards würde daraus sofort „aktives Gruppenmitglied“. Tatsächlich könnte der Client das Token noch nicht beim KDC vorgelegt haben. Die gesicherte Verbindung könnte scheitern, der Join abgelehnt oder die Antwort nie installiert werden.

RFC 9594 macht diese Zwischenräume zur Architektur. Die erste Phase folgt ACE zwischen Client, Authorization Server und KDC, der dabei als Resource Server arbeitet. Die zweite Phase verteilt das eigentliche Gruppenschlüsselmaterial zwischen Client und KDC. Eine politische Erlaubnis wird nicht automatisch zum laufenden Zustand.

Die Autorisierung erlaubt den Antrag

Der Authorization Server entscheidet, auf welche Mitgliedschaftsressource ein Client zugreifen und welche Rollen er verlangen darf. Das Token wird typischerweise an /authz-info übertragen. Danach müssen Client und KDC eine gesicherte Beziehung gemäß dem gewählten ACE-Transportprofil verwenden, etwa DTLS nach RFC 9202 oder OSCORE nach RFC 9203.

Der Join folgt mit einem POST auf /ace-group/GROUPNAME. Der KDC gleicht Gruppe, Scope und Rollen mit dem gespeicherten Token ab und führt die Prüfungen der Basisspezifikation sowie des Anwendungsprofils aus. Erst der erfolgreiche Handler nimmt den Client in die aktuelle Mitgliederliste auf und gibt das nötige Material zurück.

Ein Token belegt deshalb weder seine Ankunft beim KDC noch einen lebenden Sicherheitskanal, einen gesendeten Join, passende Rollen, akzeptierte Besitznachweise, eine erzeugte Knotenressource oder die lokale Aktivierung. Es ist ein Beleg für die Entscheidung des Authorization Servers, nicht für die gesamte Kette.

Ein unveränderlicher Name kann veränderlichen Zustand tragen

GROUPNAME bezeichnet die Mitgliedschaftsressource und bleibt nach ihrer Einrichtung unverändert. Knotenname und NODENAME bleiben ebenfalls unverändert und sind unter den aktuellen Mitgliedern eindeutig. Das stabilisiert die Verwaltungsoberfläche.

Der kryptografische Zustand rotiert. num kennzeichnet die Version des aktuellen Gruppenschlüsselmaterials. Gruppenkennungen, individuelles Material, Peer-Credentials und Richtlinien sind im Kontext des Profils und der Version zu lesen. Zwei Clients können denselben Gruppennamen verwenden und vorübergehend in unterschiedlichen Epochen stehen.

Das gemeldete technische Erratum 8239 ergänzt in einem Credential-Abrufbeispiel das erforderliche, aber fehlende num. Erratum 8864 korrigiert die Beschreibung leerer Credential-Filter. Beide waren zum Recherchezeitpunkt gemeldet und sind kein Beleg für einen Produktfehler. Sie zeigen aber, warum Credentials ohne Versionsbezug keinen vollständigen Betriebszustand beweisen.

Das Anwendungsprofil ist Teil des Vertrags

RFC 9594 schreibt nicht ein einziges Gruppenschutzverfahren vor. Die Spezifikation vereinheitlicht KDC-Ressourcen, Operationen, CBOR-Strukturen, Fehler, Medientyp und IANA-Register. Das Anwendungsprofil muss anschließend Schlüsseltyp und Codierung, Gruppen- und Knotenkennungen, Credential-Formate, Besitznachweise, Richtlinien, Rekey-Schutz, angebotene Ressourcen und Client-Fähigkeiten festlegen.

Der Wert ace_groupcomm_profile benennt diese Spezialisierung. Er führt sie nicht aus. „RFC-9594-kompatibel“ ist daher ohne Profil, Parameter, unterstützte Operationen und installierte Version keine belastbare Aussage.

Das folgt der Idee einer minimalen Anfangsspezifikation: Gemeinsam bleibt nur, was Interoperabilität gemeinsam braucht; spezialisierte Entscheidungen werden benannt und prüfbar lokalisiert. Problematisch wird die Delegation, wenn eine Oberfläche das Profil verschweigt und die RFC-Nummer Garantien tragen lässt, die der Basistext bewusst offenließ.

NUM+1 ist nicht gleichzeitig bei allen

Der KDC erneuert abgelaufenes Material und kann regelmäßig erneuern. Rückwärtssicherheit kann bei einem Beitritt neues Material verlangen, Vorwärtssicherheit bei Austritt oder Ausschluss. Vor der Verteilung erhöht der KDC NUM und verteilt NUM+1.

Dafür können mehrere Nachrichten an verschiedene Zielmitglieder nötig sein. RFC 9594 beschreibt ausdrücklich eine zeitweilige Fehlanpassung: Einige Mitglieder besitzen den neuen Zustand, andere noch den alten. Nach Abschluss löscht der KDC altes Material und sollte den neuen Zustand dauerhaft speichern.

Dieser Bericht wiederholt nicht die KEK-TEK-Ausschlussfolge des veröffentlichten RFC-9838-Artikels. Seine eigene Grenze ist allgemeiner: Eine Versionsänderung im KDC beweist nicht Empfang, Prüfung und Aktivierung bei jedem Client. Diese Übergänge brauchen getrennte Quittungen.

Der Dispatcher transportiert, aber entscheidet nicht

Ein Dispatcher verteilt Eins-zu-viele-Nachrichten. Bei Multicast kann die Funktion implizit sein; in Pub-Sub- oder Relay-Architekturen ist sie ein expliziter Vermittler. RFC 9594 behandelt den expliziten Dispatcher wie einen nicht vertrauenswürdigen On-Path-Akteur: Er sieht geschützte Nachrichten und leitet sie weiter, besitzt aber kein Gruppenschlüsselmaterial.

Die Position im Lieferweg schafft keine Mitgliedschaftsautorität. Ein Broker kann an Ziele mit verschiedenen num-Werten weitergeben. Ein Relay kann Zustellung beobachten, ohne Annahme zu beweisen. Die spätere Grenze zwischen geschützter Nachricht und lokaler Aktion gehört bereits zum RFC-10020-Bericht. Hier geht es um den früheren Übergang von Erlaubnis zu Mitgliedschaft und von Mitgliedschaft zu installiertem Zustand.

Übergänge protokollieren, Geheimnisse nicht

Ein Audit-Ledger sollte Token-ID oder Hash, Aussteller, Audience, Scope, Rollen und Ablauf; KDC-Übertragung; Transportprofil; Identität der Sicherheitsbeziehung; Join-ID; GROUPNAME; NODENAME; Anwendungsprofil; num; Credential- und Besitzprüfungen; lokale Installation; Richtlinienversion; Rekey-Beginn und -Ende; Wiederherstellung sowie die letzte bestätigte Nutzung halten. Schlüsselmaterial gehört nicht hinein.

Der AS belegt seine Richtlinienentscheidung, der KDC Aufnahme und Verteilung, der Client Prüfung und Installation, der Dispatcher Weiterleitung und die Anwendung das Ergebnis. Das entspricht Lu Hengs Realitätsebenen: Ein Datensatz beschreibt eine Entscheidung, erschafft aber nicht die nächste operative Wirklichkeit. Laufender Code bleibt der Nachweis, dass ein erlaubter Übergang tatsächlich stattfand.

Quellen