Zusammenfassung

  • Die IETF-Arbeitsgruppe LAKE eröffnete am 8. September 2026 den Working Group Last Call für draft-ietf-lake-authz-08; Stellungnahmen sind bis 22. September möglich.
  • Im regulären ELA-Ablauf sendet Gerät U ID_CRED_I in EDHOC-Nachricht 3. V leitet die Kennung an Enrollment-Server W weiter; dessen Voucher erreicht U in Nachricht 4.
  • Der Entwurf weist ausdrücklich darauf hin, dass U seine Identität einem authentisierten V offenlegt, bevor U weiß, ob die ELA-Autorisierung gelingt. Eine reine Enrollment-Identität ist als mögliche Begrenzung genannt.
  • Daniel Kade schlägt einen datensparsamen Beleg für Authentisierung, W-Entscheidung, Ablehnung und Identitätswechsel vor. Er ist Analyse, keine Vorgabe des Entwurfs.

Die Last-Call-Nachricht fordert bis zum 22. September Unterstützung oder begründete Einwände samt Lösungsvorschlägen an. Die Datatracker-Historie verzeichnet am 8. September den Wechsel von WG Document zu In WG Last Call. Damit beginnt eine Entscheidungsphase; ihr Ausgang steht nicht fest. Die aktuelle Dokumentseite führt Revision 08 weiterhin als Internet-Draft mit Ziel Proposed Standard, nicht als RFC oder IESG-Beschluss.

ELA steht für Lightweight Authorization using EDHOC. Das Verfahren bringt drei Rollen zusammen: das eingeschränkte Gerät U, den Domain-Authenticator V und den hinter V erreichbaren Enrollment-Server W. Auf der knappen U–V-Verbindung läuft EDHOC. Die aufwendigere Kommunikation mit W findet auf der weniger eingeschränkten Seite statt. So können Authentisierung und Autorisierung überlappen, statt zwei vollständige Abläufe nacheinander zu verlangen.

Die Revision 08 setzt zwei verschiedene Vorbeziehungen voraus. U kennt W bereits durch dessen öffentlichen Schlüssel und Standort. V und W verfügen über eine implizite Vertrauensbeziehung, etwa über die Web-PKI. U und V brauchen keine frühere Beziehung. Aus den ersten beiden soll die dritte entstehen.

Nachricht 3 setzt die Identität in Bewegung

In EDHOC-Nachricht 2 weist V gegenüber U den Besitz des Schlüssels zu seinem Credential nach. Danach sendet U Nachricht 3. Sie enthält ID_CRED_I als Kennung des Geräte-Credentials. External Authorization Data liefert außerdem den Standort von W und frisches DH- oder KEM-Material für den gesonderten Schutz des späteren Vouchers.

V stellt daraus eine Voucher-Anfrage an W zusammen. Darin stehen die gewählte Cipher Suite, H_12 als Bindung an die ersten beiden EDHOC-Nachrichten, das ephemere Material, ID_CRED_I und ein Schalter für die Rückgabe des vollständigen U-Credentials. W ordnet Sitzungs-Hash und Kennung einander zu, sucht die Autorisierungsregel für U und setzt sie durch. Die Regel kann Identitäten, Zeitfenster oder erlaubte V begrenzen; ihre inhaltliche Ausgestaltung ist ausdrücklich nicht Teil des Entwurfs.

Der Voucher beantwortet eine andere Frage. Er ist die Aussage von W an U, dass W dieses V autorisiert hat. Seine Integritätsbindung umfasst die laufende Sitzung, die U-Kennung und das Credential von V. Ein optionaler Scope bleibt für V undurchsichtig, kann aber von U und W gelesen werden. V transportiert den Voucher in Nachricht 4 zurück.

Im Basisprotokoll macht RFC 9528 die vierte EDHOC-Nachricht optional. Im regulären ELA-Ablauf ist sie zwingend, weil dort der Voucher ankommt. Erst nach ihrer Verarbeitung nennt der Entwurf U und V autorisiert, miteinander zu interagieren.

Zwischen Nachricht 2 und 4 gelten daher verschiedene Zustände. U hat den Schlüsselbesitz von V authentisiert, aber W's Autorisierung von V noch nicht empfangen. Gleichzeitig hat U seine Kennung bereits an V und über V an W gegeben. Schlüsselbesitz, Drittfreigabe und endgültige Interaktionsberechtigung sind nicht dieselbe Aussage.

Identitätsschutz hat einen legitimen Empfänger

Der Befund behauptet keinen Bruch des EDHOC-Identitätsschutzes. Lauscher und nicht authentisierte Gegenstellen erhalten die Kennung nicht offen; die Kanäle sind geschützt. ELA beschreibt die Grenze genauer: U gibt seine Identität an ein authentisiertes V preis, bevor U weiß, ob der gesamte Autorisierungsablauf erfolgreich endet.

Der Entwurf erlaubt deshalb eine Enrollment-only Identity. Nach Aufbau des sicheren Kanals kann U für den Betrieb eine andere Identität verwenden. Eine abgelehnte Anfrage oder ein falsches V muss damit nicht sofort die dauerhafte Betriebskennung erfahren. Offen bleiben jedoch die Aufbewahrung bei V und W, die Nachweisführung beim Wechsel und die Frage, ob eine Zuordnung zwischen alter und neuer Identität bestehen bleibt.

Auch der Begriff Voucher ist nicht formatneutral. RFC 8366 definiert ein vom Hersteller signiertes Artefakt, das ein Gerät einem Eigentümer zuordnet und ein Domain-Zertifikat festlegt. ELA übernimmt eine ähnliche Funktion in kompakter Form, aber nicht dieses Artefaktformat. RFC 8995 beschreibt BRSKI mit Pledge, Registrar und Herstellerautorität und behandelt Audit sowie Datenschutz als eigene Betriebsflächen. RFC 9031 zeigt einen anderen Beitritt in eingeschränkten Netzen. Diese RFCs erklären die Familie des Problems; die konkrete Reihenfolge stammt aus ELA.

Eine Ablehnung ist ein abgeschlossener Politikschritt

W kann ID_CRED_I kennen und den Beitritt dennoch wegen der Regel ablehnen. Dann liefert die Schnittstelle HTTP 403 oder CoAP 4.03. W kann U außerdem verschlüsselte, handlungsfähige Hinweise senden—etwa einen anderen V zum Ausprobieren—die V in einem EDHOC-Fehler Access denied weiterreicht.

Dieser Vorgang ist nicht bloß ein Verbindungsfehler. Eine Regelablehnung unterscheidet sich vom fehlgeschlagenen Credential-Abruf, einer ungültigen Voucher-Prüfung, einem W-Timeout oder einer falschen Eintrittsstelle. In jeder Variante wurde die Gerätekennung bis zu einem anderen Punkt verarbeitet. Ein gemeinsamer Fehlerzähler verschleiert sowohl Ursache als auch Datenspuren.

Das LAKE-Protokoll von IETF 126 hält fest, dass getrennte ephemere Schlüssel für EDHOC und ELA beibehalten wurden, einige Anwesende Bereitschaft für den Last Call signalisierten und die Vorsitzenden dessen Start ankündigten. Die LAKE-Arbeitsgruppe beurteilt nun den gemeinsamen Text. Über die lokale Erinnerung einer abgelehnten Anmeldung entscheidet weiterhin der Betreiber.

Ein Beleg mit eingebautem Vergessen

Ein angemessener Enrollment-Beleg braucht kein rohes ID_CRED_I. Er kann einen nicht umkehrbaren Versuchshandle, den Fingerabdruck von V's Credential, Versionen von W-Vertrauensanker und Endpunkt, H_12, die Policy-Version, die verwendete Identitätsklasse und ein begrenztes Ergebnis speichern: Voucher akzeptiert, Regel abgelehnt, Umleitung, Credential-Fehler oder Timeout.

Beim Wechsel von Enrollment- zu Betriebsidentität sollte der Beleg den vollzogenen Übergang zeigen, aber keine exportierbare Zuordnungstabelle behalten. Aufbewahrungsfrist und Löschbestätigung gehören zum Ergebnis. Vollständige Zertifikate, Voucher-Klartext und domänenübergreifend korrelierbare Kennungen gehören nicht ins allgemeine Betriebsprotokoll.

Dieses Schema ist Daniel Kades redaktioneller Vorschlag. Revision 08 verlangt es nicht und nimmt die Autorisierungsregeln aus ihrem Geltungsbereich aus. Gerade deshalb muss der Einsatz Authentisierung, Autorisierung durch W, die Entscheidung über U und das Löschen der Identität als getrennte Tatsachen behandeln.

Quellen