Zusammenfassung

  • Revision 01 lässt den Initiator den Responder erst nach Prüfung von message_4_KEM authentifizieren; der Responder authentifiziert den Initiator erst nach message_5_KEM.
  • Nachricht 3 kann vertraulich und integritätsgeschützt sein, ohne den Initiator zu authentifizieren. Der endgültige Anwendungsschlüssel muss auf gegenseitige Authentifizierung, Transcript-Integrität, echte Credentials und Besitznachweis warten.

In der Mitte sieht der Vorgang schon fertig aus

Nach der dritten Nachricht besitzt ein Betriebsdashboard viele grüne Signale. Der ephemere KEM-Austausch hat ein Geheimnis geliefert. Der Initiator hat ein Credential des Responders geprüft, an dessen statischen öffentlichen Schlüssel gekapselt und das eigene Credential geschützt gesendet. Der Responder konnte entkapseln und entschlüsseln.

Dieser Beleg kommt zu früh.

Revision 01 von KEM-based Authentication for EDHOC, eingereicht am 28. September 2026, sagt ausdrücklich, dass der Schutz von Nachricht 3 den Initiator nicht authentifiziert. Der Responder hat den MAC für seine eigene Authentifizierung noch nicht gesendet; der Initiator ebenso wenig. Ein Besitzer eines statischen KEM-Schlüssels braucht zunächst eine vom Peer für seinen Public Key erzeugte Kapselung, bevor er den passenden Private Key nachweisen kann. Daher fügt der Entwurf zwei Nachrichten hinzu.

Der Datatracker führt das Dokument als aktiven LAKE-WG-Internet-Draft mit dem IESG-Zustand I-D Exists. Der Text strebt Standards Track an, ist aber kein RFC, kein angenommener Standard und kein Implementierungsnachweis. Ohne Ersetzung oder Fortschritt läuft diese Fassung am 1. April 2027 ab.

Zwei Richtungen, zwei Abschlusskanten

Nachricht 1 enthält den ephemeren KEM Public Key. Der Responder kapselt dorthin und liefert in Nachricht 2 das Ciphertext sowie seine Credential-Kennung. Bevor der Initiator das eigene Credential offenlegt, muss er das des Responders beschaffen, validieren und nach lokaler Policy akzeptieren. Kryptografische Gültigkeit genügt nicht: Ein gültiges Credential kann zu einer nicht vertrauenswürdigen oder unbeabsichtigten Gegenstelle gehören.

In Nachricht 3 kapselt der Initiator an den statischen KEM-Schlüssel des Responders und übermittelt die eigenen Credential-Daten geschützt. Erfolgreiche Entkapselung schließt die Identitätsbindung nicht. message_4_KEM enthält den expliziten MAC des Responders. Erst nach dessen Prüfung darf der Initiator den Peer authentifizieren und PRK_out oder Anwendungsschlüssel dauerhaft speichern.

Die Gegenrichtung bleibt offen. Erst der MAC in message_5_KEM erlaubt dem Responder, den Initiator zu authentifizieren. Der Entwurf räumt ein, dass eine mögliche Fehlbindung bis zu diesen beiden letzten Prüfungen unentdeckt bleiben kann. EAD gilt vorher als ungeschützt; Schlüsselmaterial soll nicht persistent werden.

Ein einziges Feld authenticated=true kann dieses asymmetrische Zeitfenster nicht darstellen. Ebenso wenig beantwortet eine Entkapselung, welche Identität, Trust Policy, welcher Transcript und welche Anwendungsbefugnis zu dem Geheimnis gehören.

Postquantenfest heißt nicht wiederverwendbar

Der Key Schedule mischt einen frischen ephemeren Beitrag mit zwei an statische KEM-Schlüssel gebundenen Geheimnissen. Für jede Sitzung sind neue Kapselungen vorgeschrieben. ss_I, ss_R und die zugehörigen Ciphertexts dürfen nicht wiederverwendet werden. Der KEM muss außerdem IND-CCA2 erfüllen und das abgeleitete Geheimnis kryptografisch an den Empfänger-Public-Key binden; IND-CCA2 allein schließt Re-Encapsulation und Unknown-Key-Share nicht aus.

RFC 9935 und FIPS 203 definieren ML-KEM, nicht die Autorität einer Organisation. SP 800-227 beschreibt sicheren KEM-Einsatz, RFC 9528 bleibt die EDHOC-Basis. Der neue Entwurf liefert einen vorgeschlagenen LAKE-Transcript, Credentials und Prüfkanten – keinen Nachweis für Deployment, Interoperabilität oder Leistung.

Auch Non-Repudiation wird ausgeschlossen. Die Methode bietet einen impliziten Beteiligungsnachweis. Ein authentifizierter LAKE-Peer darf deshalb nicht automatisch eine Route ändern, Software installieren, Geld bewegen oder ein Gerät betätigen. Das Betriebsledger muss Methode und Suite, lokale Credential-Prüfung, Zustände der Nachrichten 2 bis 5, MAC_2 und MAC_3, eine geheimnisfreie Freshness-Kennung, den Übergang zur Schlüsselpersistenz, Autorisierung, geschützte Anfrage und Antwort sowie den beobachteten Effekt getrennt führen.

Die frühere BTW-Analyse zu RFC 9668 behandelte eine andere Grenze: EDHOC-Nachricht 3 und erste OSCORE-Anfrage in einem Paket beweisen keine Anwendungsausführung. Hier liegt die Grenze davor. In dieser KEM-Methode ist nach Nachricht 3 nicht einmal die Authentifizierung abgeschlossen.

Running-Code Primacy verlangt, Nachrichten 4 und 5 tatsächlich abzubrechen, Kapselungen zu wiederholen, Credentials auszutauschen und den verbleibenden Zustand zu beobachten. Minimum Initial Specification stützt ein schmales gemeinsames Invariant: explizite Abschlusszustände und Freshness pro Sitzung, während die Trust Policy lokal bleibt. Reality Layers trennt Schlüsselbesitz, vertrauenswürdige Identität, Autorisierung und Wirkung.

Quellen