Zusammenfassung

  • Am 8. September 2026 wechselte draft-ietf-lake-edhoc-psk im Datatracker zu „WG Consensus: Waiting for Write-Up“; Revision 09 erschien noch am selben Tag. Das Dokument ist weiterhin ein Internet-Draft, kein RFC und nicht vom IESG gebilligt.
  • Laut Revision 09 kann ein ID_CRED_PSK einen oder mehrere PSK-Kandidaten samt zugehörigen Credentials liefern. Der Responder probiert sie, bis CIPHERTEXT_3B authentifiziert wird oder die Menge erschöpft ist.
  • Eine Aufzeichnung nur der kompakten Kennung belegt nicht mehr, welcher lokale Credential-Kontext den Peer authentifiziert hat.
  • Daniel Kade schlägt deshalb eine nicht geheime Aufzeichnung von Kandidatenmengenversion, gewählter Credential-Version und Versuchsergebnis vor. Dies ist eine redaktionelle Empfehlung, keine Vorgabe des Entwurfs.

Die Mehrzahl ist nicht Teil der Nachricht. Der Initiator legt ID_CRED_PSK in den geschützten Teil von EDHOC message_3; die Kennung kann so knapp wie ein COSE kid sein. Erst der Responder verwendet sie als lokalen Suchschlüssel. Ein einzelner Wert auf der Leitung kann somit eine Liste im Backend adressieren.

Revision 09 beschreibt den Ablauf ausdrücklich. Die Suche liefert eine oder mehrere PSKs und die Informationen, die für ihre EDHOC-Verarbeitung nötig sind. Der Responder wählt zunächst den ersten Kandidaten, leitet K_3 und IV_3 ab und prüft CIPHERTEXT_3B per AEAD. Schlägt die Prüfung fehl, nimmt er einen weiteren Kandidaten. Erst wenn alle scheitern, gilt die Verarbeitung als fehlerhaft oder manipuliert. Eine erfolgreiche Prüfung weist den Besitz der PSK dieses Kandidaten und die aktive Teilnahme am Austausch nach.

In Revision 08 hieß es noch, die Kennung diene zum Abruf „der richtigen PSK“. Eine eindeutige oder stochastisch eindeutige Zuordnung wurde empfohlen, um Mehrdeutigkeit und Versuche mit mehreren Schlüsseln zu vermeiden. Der offizielle Vergleich zeigt nun: Die Empfehlung zur eindeutigen Zuordnung bleibt, doch der zuvor vermiedene Mehrfachfall wird zu einem geregelten Verarbeitungspfad. Eins-zu-eins ist weiterhin der einfache Fall, aber nicht mehr der einzige beschriebene.

Zur Auswahl steht ein vollständiger Credential-Kontext

Wer im Betriebsmodell nur von „mehreren Schlüsseln“ spricht, verliert einen Teil des Zustands. Ein Kandidat umfasst laut Entwurf die PSK, CRED_I, CRED_R und weitere Angaben für den ausgehandelten EDHOC-Kontext. Die Credentials von Initiator und Responder müssen verschieden sein, um Reflexion und Fehlbindung entgegenzuwirken. Auch der Hash-Kontext muss zur gewählten Cipher Suite passen. Getestet werden folglich vollständige Authentisierungskontexte, nicht beliebig austauschbare geheime Bytefolgen.

Die EDHOC-Basisspezifikation RFC 9528 trennt bereits kurze Credential-Verweise von den abgerufenen Credentials. RFC 9052 behandelt ein COSE kid als Hinweis für den Empfänger, nicht als global eindeutigen Namen. RFC 8392 bietet eine mögliche Darstellung der zugehörigen Claims. Die PSK-Erweiterung macht diese Trennung für die Nachweisführung bedeutsamer: Hinter demselben Verweis können mehrere lokale Identitäts- und Verarbeitungsstände liegen.

Die Kandidatenprüfung ist auch keine Passwortsuche. Revision 09 verlangt für externe PSKs mindestens 128 Bit Entropie und eine Länge von mindestens 128 Bit. Passwörter und andere Quellen geringer Entropie sind als Grundlage des gemeinsamen Geheimnisses ausgeschlossen. Es geht um provisionierte Authentisierungskontexte mit einem gemeinsamen Suchgriff, nicht um das Durchprobieren schwacher Eingaben.

Überlappung schützt Verfügbarkeit — und verlagert Kontrolle

Weshalb ein Betreiber mehrere Kandidaten behält, schreibt der Entwurf nicht vor. Eine Rotation mit alter und neuer Version, kurzzeitig auseinanderlaufende Provisionierungsdatenbanken, wiederverwendete Kurzkennungen in getrennten Bereichen oder ein vorübergehender Rückfallkontext sind plausible Einsatzmotive. Sie bleiben Schlussfolgerungen; das eingefrorene Quellenpaket belegt keine produktive Installation mit Mehrfachzuordnung.

Der Nutzen liegt dennoch nahe. Ein beschränktes Gerät muss kein größeres Identitätsobjekt übertragen, und eine Flotte muss nicht in einem einzigen Moment umschalten. Im Gegenzug wandert die entscheidende Policy in die Tabelle des Responders. Mitgliedschaft, Reihenfolge, Ausmusterung und Versuchslimit der Kandidaten sind für den Initiator unsichtbar.

Zwei Responder, die dieselbe Policy abbilden sollten, könnten dieselbe Kennung empfangen und denselben Peer akzeptieren, aber an unterschiedlichen Positionen ihrer Listen Erfolg haben. Wenn beide lediglich ID_CRED_PSK speichern, sehen ihre späteren Einträge gleich aus. Sie verraten nicht, ob zuerst ein abgelaufenes Credential geprüft wurde, die neue Version bereits vorherrscht oder noch ein Fallback greift.

Hier beginnt die Governance-Frage. „Authentisiert“ ist ein gültiges Ergebnis, und die empfangene Kennung ist eine gültige Eingabe. Keine der beiden Angaben beschreibt allein die lokale Auswahl, die sie verbunden hat. Eine Kurzkennung nachträglich wie den eindeutigen Namen des akzeptierten Credentials zu behandeln, würde ihr mehr Beweiskraft geben, als der Entwurf vorsieht.

Konsens der Arbeitsgruppe ist noch kein Standard

Der Aufruf zum Working Group Last Call und die Review-Antwort setzten für Revision 08 ein Fenster vom 1. bis 15. Juli. In der archivierten Diskussion zur Kandidatenauswahl wurde vorgeschlagen, nach einer fehlgeschlagenen AEAD-Prüfung einen neuen Kandidaten zu verwenden; diese Schritte finden sich in Revision 09.

Die Datatracker-Historie verzeichnet am 8. September den Übergang von In WG Last Call zu „WG Consensus: Waiting for Write-Up“, Marco Tiloca als Document Shepherd und die neue Revision. Der aktuelle Dokumenteintrag bezeichnet weiterhin einen aktiven LAKE-Entwurf mit angestrebtem Standards Track. Shepherd Write-up, IESG-Prüfung, mögliche weitere Fassungen, Billigung und RFC-Veröffentlichung sind noch getrennte Schritte.

Die Auswahl festhalten, nicht das Geheimnis

Eine angemessene Prüfspur braucht weder PSK-Bytes noch eine öffentliche Geräteidentität. Sie muss eine begrenzte Frage beantworten: Welchen nicht geheimen lokalen Credential-Kontext akzeptierte dieser Responder bei genau dieser Suche?

Eine solche Aufzeichnung kann den Fingerabdruck des empfangenen ID_CRED_PSK, Version oder Digest der Kandidatenmenge, Kandidatenzahl, gewählte nicht geheime Credential-Version, EDHOC-Suite und Hash-Kontext, Versuchszahl, Ergebnis, Policy-Version und Zeitpunkt verbinden. Bei Erschöpfung zeigt dieselbe Struktur, dass kein Kandidat bestand, ohne dessen Inhalt offenzulegen. Latenz und Erschöpfung lassen sich nach Größenklassen aggregieren.

Damit wird Rotation auch im Betrieb nachvollziehbar. Steigt der Erfolg beim zweiten Kandidaten kurzfristig, kann eine Umstellung laufen; bleibt er nach dem Ausmusterungstermin hoch, hat sich alter Zustand festgesetzt. Melden eigentlich gleich konfigurierte Responder unterschiedliche Mengenversionen, wird die Abweichung sichtbar, bevor eine Untersuchung nur noch „PSK fehlgeschlagen“ vorfindet.

Dieses Schema ist Daniel Kades redaktioneller Vorschlag. Revision 09 verlangt es nicht, und es ist kein dokumentierter Konsens der Arbeitsgruppe. Ein Protokollentwurf darf die Kryptoverarbeitung festlegen und Aufbewahrung sowie Datenschutz den Anwendungsprofilen überlassen. Doch eine plural gewordene Suche weiterhin wie eine singuläre Tatsache zu protokollieren, wäre keine neutrale Entscheidung.

Quellen