Zusammenfassung

  • W prüft U, V weist gegenüber W die Bindung an dasselbe CRED_V nach, das es U gezeigt hat, und der Beleg wird mit H_12, ID_CRED_I und Vs Berechtigungsnachweis verbunden.
  • U offenbart seine Identität absichtlich einem authentisierten V, bevor feststeht, ob W die Aufnahme erlaubt. Ein Abbruch ist kein Nachweis für Löschung oder fehlende Korrelation.
  • Ein Identitätsfreigabe-Beleg sollte Zweck, Empfänger, Aufbewahrung, Ablehnungsfolge und Aktivierung einer getrennten Betriebsidentität festhalten. Er ist Daniel Kades Vorschlag, kein IETF-Element.

Die Reihenfolge lässt sich nicht signieren

draft-ietf-lake-authz-08 beschreibt Lightweight Authorization using EDHOC. Am 8. September 2026 wechselte der Entwurf im LAKE-Arbeitskreis in den WG Last Call; Revision 08 stammt vom 6. Juli. Er ist weiterhin ein Internet-Draft mit Proposed Standard als Ziel, kein veröffentlichter RFC.

Gerät U kennt vorab den statischen öffentlichen Schlüssel PK_W und den Ort LOC_W des Aufnahmeservers W. Domänenauthentisierer V möchte U aufnehmen. W kann vom Hersteller oder einer anderen vertrauenswürdigen Stelle betrieben werden; V kann zu einem Dienstanbieter oder Netzbetreiber gehören.

U startet EDHOC mit ID_CRED_I, das W eindeutig zuordnen kann. V erhält diese Identität und verwendet sie im geschützten Austausch mit W. Dabei nutzt V dasselbe CRED_V, das U gesehen hat, und weist den Besitz beziehungsweise die Schlüsselbindung nach. W wendet eine lokale Autorisierungsrichtlinie an; deren Inhalt liegt ausdrücklich außerhalb des Entwurfs.

Bei Erfolg erhält U einen Beleg: Ws Aussage, V sei autorisiert. H_12 bindet ihn an die aktuelle Transkription, ID_CRED_I an U und CRED_V an V; ein undurchsichtiger Geltungsbereich kann hinzukommen. Ohne erfolgreichen Austausch mit W geht es nicht weiter. Der Abschluss bis message_4 bedeutet, dass U und V unter dem Ergebnis interagieren dürfen.

Diese Bindung verhindert Verwechslung zwischen Sitzungen und spart Nachrichten auf dem knappen Link. Sie ändert aber nicht, dass V die Identität vor dem Urteil kennt. Der Sicherheitsteil sagt es offen: EDHOC schützt Initiatoridentität im Modell vor passiven Beobachtern und nicht authentisierten Peers; ELA legt sie einem authentisierten V bewusst vor dem Autorisierungserfolg offen.

Authentisiert ist keine Speichererlaubnis

Authentisierung zeigt, wer einen Schlüssel kontrolliert. Autorisierung zeigt Ws Entscheidung für U, V und diese Sitzung. Beides legt nicht fest, wie lange die Organisation hinter V eine Ablehnung speichern darf. Ebenso beweist ein gültiger Beleg weder Legitimität noch Aktualität von Ws Richtlinie.

H_12 verhindert einen losgelösten Beleg, setzt aber keinem Protokoll einen Löschtermin. ID_CRED_I hilft W beim Richtlinienabruf, verbietet jedoch keine Verknüpfung mit Herstellerdaten. Eine verschlüsselte, an H_12 gebundene Fehlermeldung kann alternative Vs nennen; sie sagt nichts über den Datensatz beim ersten V.

Damit wird keinem Produkt Fehlverhalten unterstellt. Die Quellen belegen keine konkrete Aufbewahrungspraxis. Sie zeigen nur eine Zuständigkeitsgrenze: Der Entwurf regelt die Sitzung, nicht den institutionellen Datenzyklus.

Eine Aufnahmeidentität braucht ein Ende

U darf laut Entwurf eine Identität nur für die Aufnahme und später eine andere für den Betrieb verwenden. Das kann alltäglichen Verkehr von der Aufnahme lösen. Es ist jedoch eine MAY-Option, keine Pflicht; Rotation je Domäne, Verfallsdatum und Löschung werden nicht vorgeschrieben.

Wird dieselbe Aufnahmeidentität netzübergreifend wiederholt, in Ablehnungsprotokollen aufbewahrt oder mit dem Betriebskonto verbunden, wird „nur zur Aufnahme“ zu einer Etikette. Ein späterer Schlüsselwechsel entfernt keine bereits erzeugte Korrelation.

Vor der Freigabe sollten daher Klasse und Betreiber von V, das konsultierte W, Zweck, Folgeempfänger und Frist feststehen. Nach Erfolg braucht es den Zeitpunkt, an dem die Betriebsidentität aktiv und die Aufnahmeidentität wirkungslos wurde. Nach Ablehnung braucht es eine deklarierte Folge: Rohkennung löschen, ein befristetes Missbrauchsschutz-Token behalten oder eine zugriffsbeschränkte Prüfspur quarantänisieren.

Der Identitätsfreigabe-Beleg

Der vorgeschlagene Identitätsfreigabe-Beleg ersetzt den ELA-Beleg nicht. ELA beweist Ws Autorisierungsentscheidung; der zusätzliche Beleg dokumentiert die Bedingungen, unter denen die dafür benötigte Information freigegeben wurde.

Er enthält Version des U bekannten Vertrauensankers, Identität und Ort von W, Fingerabdruck von CRED_V, Klasse und Rotationsregel der Aufnahmeidentität sowie einen datensparsamen Bezug auf H_12. Hinzu kommen Richtlinienkennung und -version, Zieldomäne, Zweck, zulässige Empfänger, Aufbewahrungsende und Weitergaberegel.

Der Ausgang unterscheidet Genehmigung, Ablehnung, Zeitüberschreitung und Fehler. Bei Genehmigung werden Geltungsbereich und Ablauf des Vouchers sowie der Wechsel zur Betriebsidentität festgehalten. Bei Ablehnung folgen Ursachenkategorie und Nachweis der Löschung oder Quarantäne. Ein Korrekturweg macht eine veraltete Richtlinie anfechtbar, ohne die Historie umzuschreiben.

Die umfangreiche Fassung muss nicht über den eingeschränkten Link laufen. V oder W kann sie prüfbar verwahren und U eine kompakte Referenz geben. Entscheidend ist, Protokollabbruch und Datenlöschung nicht gleichzusetzen.

Verfügbarkeit ist ebenfalls Herrschaft

W muss während des Ablaufs erreichbar sein. Das liefert frische Entscheidungen, schafft aber eine Abhängigkeit. Ablehnung bei Ausfall blockiert Geräte; Warteschlangen verlängern Speicherung; Zulassung ohne W verändert das Vertrauensmodell. Jede Rückfallregel braucht Eigentümer, Dauer und sichtbare Richtlinienversion.

ELA ist stark, weil es seine Grenze benennt. Es schützt vor breiter Beobachtung, authentisiert den unmittelbaren Empfänger und bindet die Entscheidung an die Sitzung. RFC 9528 überlässt Anwendungen ebenfalls die Vertrauens- und Berechtigungsprüfung. BRSKI und RFC 8366 zeigen, dass ein signiertes Voucher-Artefakt nicht sämtliche Anker- und Domänenpolitik regiert.

Der ELA-Beleg kann bestätigen, dass W V in diesem Austausch autorisiert hat. Er kann nicht beweisen, dass die vorherige Offenlegung dem richtigen Zweck folgte, eine Ablehnung keine Spur hinterließ oder die spätere Betriebsidentität praktisch getrennt bleibt. Dafür braucht es eine überprüfbare institutionelle Zusage.

Quellen