Zusammenfassung

  • Ein erfolgreicher EAP-Methodenlauf und der Export des MSK beenden in RFC 9820 den geschützten Sitzungsnachweis nicht. Der Authenticator sendet Schritt 7 unter OSCORE; der Peer prüft ihn und antwortet mit dem ebenfalls geschützten Schritt 8 2.04 Changed.
  • Ein gemeinsamer Schutzkontext gewährt keinen pauschalen Ressourcenzugang. Bootstrap-Autorisierung, Anwendungsrichtlinie, Lebensdauer, Reauthentifizierung, Generationswechsel und erzwungene Löschung haben getrennte Entscheider und Abschlussnachweise.
  • Ein belastbarer Beleg verbindet CoAP-Ressourcengenerationen, EAP-Ergebnis, geheimnisfreie Ableitungslinie, Aushandlung, Recipient IDs, die Prüfungen 7/8, wirksame Richtlinie, Löschbestätigungen und beobachteten Verkehr, ohne den MSK zu protokollieren.

Zwei gültige lokale Rechnungen ergaben keinen gemeinsamen Zustand

Im hypothetischen Vorfall lag nicht zwingend ein schwacher Algorithmus vor. Der Authenticator hatte einen Aushandlungswert in seiner Mitschrift, der Peer einen anderen. Beide führten die vorgesehene Ableitung aus. Die resultierenden Kontexte waren intern schlüssig und untereinander inkompatibel.

RFC 9820 definiert einen Authentifizierungsdienst, der EAP über CoAP trägt. Das eingeschränkte Gerät ist EAP Peer und zugleich CoAP Server. Der Controller ist EAP Authenticator und sendet als CoAP Client. Im Pass-through-Betrieb kann ein Backend-AAA-Server die Methode ausführen oder Autorisierungsdaten liefern.

Schon die Rollenverteilung verlangt präzise Sprache. „Der Client ist authentifiziert“ kann den CoAP Client, den EAP Peer, das Gerät oder dessen Organisation meinen. Der Nachweis muss Protokollrolle, Instanz, Policy Principal und die Anwendung benennen, die über die letzte Handlung entscheidet.

Die Informationsseite des RFC Editor und der Datatracker-Eintrag führen RFC 9820 als IETF Standards Track, veröffentlicht im September 2025 nach der Arbeit der ACE Working Group. Dieser Status gilt für die Spezifikation. Er belegt weder Implementierung noch Konformität, Einsatz, Aufnahme eines Geräts oder Ressourcenergebnis.

Flüchtige Ressourcen machen Reihenfolge explizit

Der Austausch läuft nicht hinter einer dauerhaften URL mit unsichtbarem Zähler. Der Peer erzeugt für den nächsten Schritt eine neue CoAP-Ressource und löscht die vorherige. Location-Path oder Location-Query weist auf den nächsten zulässigen Ort.

Damit gehört die Ressourcengeneration zum Transcript. Eine verspätete Nachricht an eine gelöschte Generation wird nicht wieder aktuell. Ein doppelter Step 0 während laufender Authentifizierung ist still zu verwerfen. Ein alter Trigger nach Sitzungsende kann für den Authenticator wie ein Neubeginn aussehen, während der Peer die erwartete Ressource nicht kennt.

RFC 7252 liefert CoAP-Anforderungs-, Antwort- und Zuverlässigkeitssemantik. RFC 4137 beschreibt EAP-Zustandsmaschinen. RFC 9820 komponiert beide; eine Sitzungstabelle darf keine davon durch ein Boolean ersetzen.

Ein Receipt benötigt Peer und Authenticator in ihren Rollen, aktuelle und entfernte Generation, Request/Response IDs, EAP-Übergang, CoAP-Ergebnis, Transportbeobachtung und Zeit. Landet ein Retry auf einer anderen Generation, muss feststehen, ob er abgelehnt, verworfen oder als neue Authentifizierung behandelt wurde.

Der MSK ist Material, noch kein gemeinsamer Beweis

Nach erfolgreicher Methode erhält der Authenticator in Schritt 7 den exportierten MSK, EAP Success und Angaben wie Session-Lifetime. RFC 5247 definiert das EAP Key Management Framework. RFC 9820 verlangt eine Methode, die MSK und EMSK von mindestens 64 Octets exportiert.

Der MSK auf einer Seite beweist keinen kompatiblen installierten Kontext. RFC 9820 leitet OSCORE Master Secret und Master Salt aus MSK, Cipher-Suite-Transcript und festgelegten Context Strings ab. Zuvor ausgetauschte Recipient IDs bestimmen Sende- und Empfangsrichtung. RFC 5869 definiert HKDF; RFC 8613 OSCORE.

Der Authenticator sendet EAP Success in einem OSCORE-geschützten POST. Der Peer erhält seinen MSK, leitet mit seinen Inputs ab und muss diesen Request prüfen. Schritt 7 ist daher kein nachträglicher Schutzumschlag. Er testet, ob das lokale Ergebnis des Authenticators beim Peer als kompatibel geschützter Zustand ankommt.

Für Audit reichen Transcript-Fingerprint, Methoden- und Suite-Kennung, Recipient IDs, Ableitungsgeneration, Softwareversion und Prüfergebnis. Den MSK selbst zu loggen, würde aus der Beweisspeicherung ein Geheimnisdepot machen.

Erst Schritt 8 bringt den Gegenbeleg zurück

Nach EAP-Erfolg und erfolgreicher Prüfung von Schritt 7 antwortet der Peer mit OSCORE-geschütztem 2.04 Changed. Prüft der Authenticator Schritt 8, erhält er den Nachweis, dass der Peer denselben Master Secret verwenden konnte.

Fünf Ereignisse bleiben auseinander: Methodenergebnis, MSK-Export, lokale Ableitung, Prüfung von Schritt 7 beim Peer, Prüfung von Schritt 8 beim Authenticator. Ein Verlust der Rückantwort macht frühere Ereignisse nicht falsch, verhindert aber die Aussage „bilateral bestätigt“.

Weil das Aushandlungs-Transcript in die Ableitung eingeht, führen manipulierte oder abweichende Werte zu unterschiedlichen Kontexten. Die geschützten Nachrichten schlagen dann fehl. Die Register IANA CoRE Parameters und IANA EAP Parameters ordnen Codepoints zu; sie belegen nicht die Auswahl oder Ausführung eines laufenden Endpunkts.

Der Betrieb sollte deshalb nicht nur Methodenerfolg zählen. Er muss zeigen, wie viele Peers Schritt 7 und wie viele Authenticatoren Schritt 8 verifizierten. Die Differenz ist ein offener Zustandsraum.

Gemeinsame Kryptografie ist keine allgemeine Vollmacht

Nach Schritt 8 ist die letzte CoAP-EAP-Ressource mit OSCORE zu schützen. Derselbe Kontext darf weitere Ressourcen schützen, sofern die Anwendungsrichtlinie es erlaubt. Das „sofern“ erhält die Zuständigkeit der Ressource.

Authentifizierung bewertet den Peer unter einer Methode. Schlüsselbestätigung bewertet kompatiblen Besitz. Autorisierung entscheidet, ob dieser Peer diese Ressource jetzt nutzen darf. Outcome beschreibt die ausgeführte Wirkung. Ein gemeinsamer Identifier darf die Ebenen verbinden, aber nicht ihre Mandate verschmelzen.

Mit AAA können Autorisierungsdaten der verantwortlichen Organisation über RADIUS oder Diameter kommen; standalone liegen sie beim Authenticator. Nach dem Bootstrap kann feinere Autorisierung folgen. RFC 9200 definiert OAuth für ACE, doch eine Referenz darauf beweist weder Tokenprüfung noch Ressourcengenehmigung.

Ein Controller mit MSK besitzt nicht die Organisationspolicy. Ein AAA-Attribut beweist keine Enforcement-Entscheidung. Ein gültiger OSCORE Request beweist nicht, dass die Zielressource freigegeben war. Der Beleg muss Policy-Version, Principal, Entscheidung, Request und Wirkung zusammenführen.

Während der Authentifizierung darf die nötige IP-Konnektivität bestehen, ungeschützter Verkehr soll aber auf CoAP-EAP begrenzt bleiben. Eine breite Firewall-Freigabe nach EAP Success dehnt den Methodenbefund in eine nicht erteilte Netzvollmacht aus.

Reauthentifizierung erzeugt vorübergehend zwei Gegenwarten

Fehlt Session-Lifetime, nutzt RFC 9820 gemäß RFC 5247 einen Default von acht Stunden. Das ist kein universelles Sicherheitsziel und kein Beweis für eine reale Einstellung.

Während der Reauthentifizierung bestehen der aktuelle Zustand und ein neuer Kandidat parallel. Der alte wird erst ersetzt, wenn der neue vollständig erfolgreich ist. Schlägt der Versuch fehl, kann der alte bis zum Ablauf oder einer späteren Erneuerung nutzbar bleiben.

Erneuerungsbeginn ist nicht Aktivierung. Der Zustandsgraph braucht alte Generation, Kandidat, Methode, Schritt 7/8, Policy, Aktivierung, letzte alte Nutzung, Retirement und Expiry. Akzeptieren zwei Generationen Verkehr, muss feststehen, ob die Überlappung beabsichtigt ist und welche irreversiblen Aktionen gesperrt sind.

Eine Control Plane kann „ersetzt“ melden, während ein laufender Resource Server den alten Kontext weiter akzeptiert. Running-Code Primacy verlangt, den tatsächlich ausgeführten Übergang zu verfolgen.

Timeout-Löschung konvergiert zunächst nur lokal

Beim erzwungenen Entzug sendet der Authenticator ein OSCORE-geschütztes DELETE an die letzte Zustandsressource. Der Peer antwortet geschützt mit 2.02 Deleted. Fehlt die Antwort bis EXCHANGE_LIFETIME, entfernt der Authenticator seinen lokalen Zustand.

Lokales Aufräumen ist vernünftig, beweist aber keinen Empfang und keine Löschung beim Peer. In einer Partition kann der Controller „entfernt“ anzeigen, während Peer, Policy Cache oder Netzpfad Restzustand behalten.

Die Kette umfasst Entscheider, Grund, Generation, gesendetes DELETE, bekannten Peer-Empfang, Peer-Ergebnis, geschützte Antwort, Authenticator-Prüfung, Timeout, lokales Cleanup, Cache-Invalidierung, spätere Ablehnungen und beobachtetes Verkehrsende. „Gelöscht“ braucht immer Actor und Layer.

Vertrauensursprung liegt vor dem grünen Status

Die Discovery des Authenticators oder eines Intermediary liegt außerhalb von RFC 9820. Einen Dienst zu finden beweist nicht, die vorgesehene Autorität gefunden zu haben. RFC 6677 bietet EAP Channel Binding und Lower-Layer Identifiers, die Abweichungen über Methode und AAA-Pfad sichtbar machen können; die konkrete Konfiguration und ihr Ergebnis bleiben dennoch zu belegen.

Der Peer kann einem Authenticator mit MSK vertrauen, weil sein AAA Server diesem Authenticator vertraute. Das ist eine begrenzte Delegationskette, keine dauerhafte Eigenschaft „trusted controller“.

Gefälschte Step-0-Nachrichten können zudem Zustand verbrauchen. RFC 9820 empfiehlt Rate Limiting und wenig Zustand vor EAP-Response/Identity. Ein Zähler belegt Lastbegrenzung, nicht legitime Identität.

Das Experiment muss die Transcripts auseinanderziehen

Der Mindestaufbau enthält Peer, Authenticator, AAA-Pfad, zwei Anwendungen mit verschiedenen Policies und einen unabhängigen Paketbeobachter. Neben dem Happy Path verändert er die Suite-Mitschrift, verliert Schritt 7, verliert Schritt 8, spielt eine alte Generation ein, dupliziert Step 0, lässt Reauthentifizierung scheitern, misst Overlap, verweigert die zweite Ressource und löscht mit sowie ohne Bestätigung.

Jeder Lauf vergleicht EAP State, CoAP Generation, OSCORE Verification, Application Policy und beobachtete Wirkung. Ein einziges success oder failure ist kein ausreichendes Ergebnis.

Der entscheidende Negativtest gibt beiden Seiten unterschiedliche Transcripts bei identischem Sitzungsnamen. Er beweist, dass Namensgleichheit und lokaler Erfolg keinen gemeinsamen Schlüsselzustand erzeugen.

Was die Quellen nicht belegen

RFC 9820 nennt kein Produkt, keinen Betreiber und keine Implementierung. Es liefert keine Messwerte zu Energie, Latenz, Verlust, Aufnahmezahlen, Angriffen oder Interoperabilität. Seine Szenarien erklären das Protokoll.

Die Datatracker-Historie, verweisende Dokumente und Referenzen aus RFC 9820 zeigen Dokumentbeziehungen. Die Errata-Suche zeigt redaktionellen Status, keinen Sicherheitswert.

RFC 3748 definiert den breiteren EAP-Rahmen. Aus der Existenz der Standards lässt sich weder Identität noch Autorität, Zustand oder Ergebnis eines konkreten Geräts ableiten.

Quellen

  1. IETF Datatracker: RFC 9820
  2. Historie von RFC 9820
  3. Dokumente mit Verweis auf RFC 9820
  4. Referenzen aus RFC 9820
  5. Heng Lu: minimale Anfangsspezifikation
  6. Heng Lu: Realitätsebenen
  7. Heng Lu: Primat des laufenden Codes
  8. IANA CoRE Parameters
  9. IANA EAP Parameters
  10. Errata zu RFC 9820
  11. RFC Editor: RFC 9820
  12. RFC 3748
  13. RFC 4137
  14. RFC 5247
  15. RFC 5869
  16. RFC 6677
  17. RFC 7252
  18. RFC 8613
  19. RFC 9200
  20. RFC 9820