Zusammenfassung

  • RFC 9668 kombiniert EDHOC message_3 mit der ersten OSCORE-Anfrage und erreicht im vorwärts gerichteten Rollenmodell bei passendem Profil mindestens zwei Round Trips.
  • Der Server kann message_3 erfolgreich prüfen und einen OSCORE Context erzeugen, bevor Replay- oder Integritätsprüfung die eigentliche Anfrage noch verwirft.

Das Serverprotokoll meldete: message_3 gültig, EDHOC abgeschlossen, neuer OSCORE Security Context angelegt. Im Betriebsdashboard wurde daraus „sichere Ersttransaktion erfolgreich“. Wenige Mikrosekunden später verwarf die OSCORE-Schicht die Anfrage. Der Partial IV lag außerhalb des zulässigen Zustands. Die Anwendung hatte nie einen Aufruf gesehen.

Beide Einträge waren wahr. Nur ihre Zusammenfassung war falsch.

Die Optimierung der RFC 9668 beginnt mit einer nützlichen Beobachtung. Nach erfolgreicher Verarbeitung von EDHOC message_2 kann der Initiator den OSCORE Context bereits ableiten. Er muss nicht warten, bis message_3 separat übertragen wurde. Er kann message_3 bilden, die erste CoAP-Anfrage schützen und beide Objekte gemeinsam senden. So lassen sich Schlüsselaustausch und eine geschützte Transaktion von drei auf mindestens zwei Round Trips verkürzen.

Eine gemeinsame Transporthülle hebt die Reihenfolge im Empfänger nicht auf.

Der Context liegt zwischen zwei Prüfungen

Die kombinierte Payload besteht aus dem codierten message_3, gefolgt vom OSCORE-Ciphertext. C_R steht als Sender ID des Clients im kid-Feld der OSCORE-Option. Die leere EDHOC-Option 21 markiert das Format und verpflichtet den Server, den EDHOC-Anteil zuerst zu verarbeiten.

Der Server kontrolliert zunächst Format und OSCORE-Option. Er extrahiert message_3, interpretiert kid als C_R und sucht damit die passende EDHOC-Session. Ein Application Profile, das message_4 zwingend verlangt, macht den kombinierten Weg ungültig. Andernfalls prüft der Server message_3 und leitet bei Erfolg den neuen OSCORE Context ab.

Erst danach nimmt er den Ciphertext, baut die geschützte Anfrage ohne EDHOC-Option wieder auf und führt OSCORE-Verifikation, Entschlüsselung und Replay-Prüfung aus. Nur das Ergebnis dieser zweiten Kette wird an die Anwendung geliefert.

Damit existiert ein legitimer Zwischenzustand: EDHOC ist erfolgreich und der Context besteht, OSCORE hat die Anfrage aber nicht akzeptiert. Wer ausschließlich Context-Erzeugung zählt, überschätzt erfolgreiche Anwendungstransaktionen. Wer ausschließlich HTTP-ähnliche Anwendungsantworten zählt, verliert die Ursache davor.

Die Telemetrie sollte deshalb pro Gate berichten: Session gefunden, Profile konsistent, message_3 geprüft, Context-Generation erzeugt, Ciphertext rekonstruiert, Partial IV bewertet, Integrität bestätigt, Anwendung beliefert. Geheimnisse gehören nicht ins Log; Generationen, Hash-Referenzen und Entscheidungen schon.

Die Kennung trägt zwei Rollen

Im kombinierten Pfad ist kid zugleich OSCORE Sender ID und EDHOC C_R für den Session-Lookup. RFC 9668 verlangt, neue Verbindungskennungen so zu wählen, dass sie nicht mit aktuellen Sessions oder relevanten Contexts kollidieren. Die Kürze der Kennung spart Übertragungsbytes, verlangt aber saubere Zustandsverwaltung.

Ein Logeintrag „kid=01“ ist ohne Generation wertlos. Nach Neustart, Session-Verlust oder Context-Erneuerung kann derselbe kleine Wert eine andere Geschichte haben. Der Beleg muss auf Transcript, Profile, Session-Generation und Context-Generation zeigen. Nur so lässt sich feststellen, ob der Server den richtigen Zustand verwendet hat.

Diese Anforderung ist keine Einladung, Schlüsselmaterial zu sammeln. Im Gegenteil: datensparsame, nicht rückrechenbare Referenzen reichen. Wichtig ist die Kette, nicht das Geheimnis.

Eine geschützte Antwort besitzt begrenzte Autorität

Wenn message_3 und OSCORE-Verarbeitung erfolgreich sind, sendet der Server eine OSCORE-geschützte Antwort. Der Client kann dadurch Responder Key Confirmation erhalten, und die Antwort ist kryptographisch an ihre Anfrage gebunden. Das schließt eine wichtige Beweislücke.

Die Anwendung bleibt dennoch eine eigene Realitätsschicht. Eine bestätigte Konfigurationsänderung kann erst in einer Queue liegen. Ein Aktor kann den Befehl angenommen haben, ohne seine Endlage erreicht zu haben. Ein externer Dienst kann später ablehnen. Die Antwort beweist die geschützte Aussage, die sie enthält; sie beweist nicht automatisch die weiteste denkbare Wirkung.

Definieren Sie daher präzise Receipt-Typen: delivered, authorized, accepted, committed, observed und compensated. Ein Dashboard darf sie nicht zu „done“ normalisieren. Kryptographische Integrität macht eine enge Aussage verlässlich, nicht umfassend.

Retry-Sicherheit endet nicht an der Replay Window

Ein verlorener Rückweg erzeugt Unsicherheit. EDHOC verhindert Mehrfachverarbeitung desselben message_3 in einer Session; OSCORE schützt Anfragen gegen Replay. Das Business-Objekt kann trotzdem zweimal erzeugt werden, wenn ein Client nach Timeout mit neuer Operationsidentität beginnt.

Die erste optimierte Anfrage braucht deshalb eine stabile Idempotency Identity und einen abfragbaren Ergebniszustand, sofern sie eine nicht triviale Wirkung auslöst. Timeout-Behandlung muss den tiefsten bestätigten Schritt kennen. Nach „message_3 unbekannt“ gilt eine andere Strategie als nach „Anwendung committed, response unbekannt“.

Auch Größe beeinflusst diese Strategie. Zertifikatsketten oder EAD können message_3 vergrößern. Überschreitet COMB_PAYLOAD bei Block-wise MAX_UNFRAGMENTED_SIZE, muss der Client den Versuch abbrechen und kann sequentiell fortfahren. Das verändert Timer und Anzahl der Zustandsübergänge.

Die lokale Policy sollte Component-Größen, MTU, Blocknummer, Grenzwert und Fallback-Grund speichern. Zwei Round Trips sind kein unveränderliches Produktversprechen, sondern ein Ergebnis geeigneter Eingaben.

Discovery ist ein Angebot, kein Laufzeitbeleg

Web Links können ed-r und ed-comb-req sowie Methoden, Cipher Suites und Credential-Typen ankündigen. Ein Client erkennt damit grundsätzlich geeignete Ressourcen. Zwischen Discovery und Transaktion können sich Profile oder Konfigurationen jedoch ändern.

Versionieren Sie das Angebot und die tatsächlich aufgelöste Policy zusammen. Wenn message_4-Pflicht und kombinierte Unterstützung gleichzeitig auftreten, liegt ein Konfigurationsfehler vor. Wenn ein bestimmter Credential-Typ regelmäßig in den sequentiellen Pfad fällt, ist die Capability formal wahr, operativ aber begrenzt.

Die Norm schafft eine minimale gemeinsame Sprache. Sie sollte nicht zur Autorität über Anwendungswirkung aufgeblasen werden. Running code zeigt an jedem Gate, was wirklich geschah.

Quellen