Zusammenfassung

  • Bei CoAP über UDP dient die Message ID der Duplikaterkennung und der Zuordnung von ACK/Reset. Der Token ordnet zusammen mit dem Endpunktkontext eine Antwort einer noch offenen Anfrage zu.
  • Eine Token-Übereinstimmung ist kein Nachweis für eine Person, den Gerätehalter, einen authentisierten Principal, eine Berechtigung, den aktuellen Ressourcenzustand oder den Vollzug einer Anwendungshandlung.

Eine Quittung ist dann belastbar, wenn auf ihr steht, wofür sie gilt. CoAP besitzt zwei kurze Felder, die oft wie zwei Versionen derselben Transaktionsnummer aussehen. Tatsächlich quittieren sie verschiedene Vorgänge.

RFC 7252 nennt Zach Shelby, Klaus Hartke und Carsten Bormann als Autoren. Das Dokument definiert die Message ID auf der Nachrichtenschicht und den Token auf der Anfrage-Antwort-Schicht. RFC 8323, mit Bormann an erster Stelle der Autoren, überträgt CoAP auf TCP, TLS und WebSockets. Dort übernehmen zuverlässige Transporte Wiederholung und Duplikatbehandlung. Type und Message ID werden gestrichen; der Token bleibt.

Dieser Umbau liefert eine klare Beweisgrenze. Die Message ID war nie die Identität einer Anwendungstransaktion. Der Token ist es ebenfalls nicht. Er erfüllt nur eine andere, weiterhin benötigte Korrelationsaufgabe.

Die Message ID gehört zu einem zeitlich begrenzten Austausch

Eine Confirmable-Nachricht über UDP wird erneut gesendet, wenn ihre Bestätigung ausbleibt. Der Empfänger kann deshalb innerhalb von EXCHANGE_LIFETIME dieselbe Message ID vom selben Quellendpunkt mehrfach sehen. Er soll jede Kopie bestätigen, die enthaltene Anfrage oder Antwort jedoch normalerweise nur einmal verarbeiten.

ACK und Reset übernehmen die 16-Bit-ID der Nachricht, auf die sie sich beziehen. Für einen Treffer müssen außerdem die betreffenden Endpunkte übereinstimmen. Dieselbe ID darf während der Austauschlebensdauer gegenüber demselben Endpunkt nicht wiederverwendet werden.

Der Nachweis lautet also: Diese Nachricht wurde in diesem Endpunkt- und Zeitkontext bereits gesehen; dieses ACK oder Reset gehört zu ihr. Er lautet nicht: Derselbe Benutzer hat gehandelt. Ein NAT, ein Prozessneustart, eine neue Quellportwahl oder ein anderer Endpunkt verändern den Kontext, ohne dass sich die Person dahinter klären muss.

Auch die Anwendung bleibt eigenständig. Ein dupliziertes Datagramm kann nur eine Absicht transportieren. Zwei Anwendungsvorgänge können mehrere CoAP-Austausche erzeugen. Wer Message ID und Geschäfts-ID gleichsetzt, verliert die Möglichkeit, Netzwerkduplikat und doppelte Wirkung zu unterscheiden.

Der Token gehört in die offene Anfragetabelle

Der Client erzeugt den Token, der Server muss ihn in jeder daraus entstehenden Antwort unverändert zurückgeben. Der Client verwendet Wert und Endpunktinformation, um die zugehörige offene Anfrage zu finden. RFC 7252 beschreibt ihn als client-lokale Kennung und merkt an, man hätte ihn „request ID“ nennen können.

Aktive Tokens sollen für ein Quell-Ziel-Endpunktpaar eindeutig sein. Das ist keine globale Eindeutigkeit. Bei unterschiedlichen Endpunkten kann derselbe Wert wiederkehren. Bei streng serieller Kommunikation kann ein leerer Token zulässig sein. Ein Endpunkt, der den Token nicht selbst erzeugt hat, muss ihn als undurchsichtig behandeln und darf keine Struktur annehmen.

Damit ist ausgeschlossen, dass der Server durch das Echo automatisch einen Kontoinhaber, ein Gerät oder eine Berechtigung bestätigt. Selbst wenn der Client eigene Zustandsdaten hineinlegt, interpretiert der Server sie nicht.

Bei einer piggybacked Antwort stimmen Message ID des ACK und Token der Antwort mit der Confirmable-Anfrage überein. Bei einer separaten Antwort folgt der Token weiter der Anfrage, während die neue Nachricht eine eigene Message ID besitzt. Ein allgemeines Feld correlationId lässt genau diese Ursache-Wirkungs-Trennung verschwinden.

Ein Transportwechsel wird zum Diagnosetest

TCP liefert einen zuverlässigen geordneten Bytestrom. RFC 8323 braucht deshalb in CoAP weder die UDP-Nachrichtentypen noch die Message ID. Eine Längenangabe trennt Frames im Strom. Der Token bleibt erhalten, weil der Transport nicht weiß, welche semantische Antwort welche gleichzeitige CoAP-Anfrage erfüllt.

Betreiber können diese Variante als Differentialtest nutzen. Ein Fehler nur über UDP verweist zunächst auf Message-ID-Erzeugung, Wiederverwendung, Duplikatcache, Zeitgeber oder ACK/Reset. Ein Fehler über UDP und zuverlässige Transporte verweist eher auf Token, offene Anfragen, Endpunkt- beziehungsweise Verbindungsbindung, Vermittler oder Antwortlogik.

TLS kann je nach Konfiguration den Peer authentisieren. Diese Aussage stammt aus der Sicherheitsverbindung. Der Token verknüpft innerhalb dieses Kontexts eine Anfrage. Beide Belege können getrennt ablaufen, erneuert und widerrufen werden. Ein Datenmodell, das sie zusammen als verifiedToken speichert, kann ihre unterschiedlichen Lebensdauern nicht darstellen.

Zufall schützt gegen blindes Raten

Ohne Transportsicherheit empfiehlt RFC 7252 einen nicht trivialen zufälligen Token. Für einen Client am allgemeinen Internet werden mindestens 32 Bit Zufall empfohlen. Ein Angreifer außerhalb des Pfades soll den Wert einer offenen Anfrage nicht leicht erraten und eine falsche Antwort einschleusen können.

Die Message ID trägt wenig zu diesem Schutz bei, weil sie häufig fortlaufend und damit vorhersagbar ist. Zudem kann eine separate Antwort die ID der ursprünglichen Nachricht umgehen. Token-Zufall ist daher ein gezielter Schutz der Antwortkorrelation.

Er ist keine Authentisierung. Ein Beobachter auf dem Pfad kennt den Wert. Ein Proxy kennt ihn auf seinem Hop. Ein fehlerhafter Zufallsgenerator wiederholt ihn. Veralteter Clientzustand kann eine verspätete Antwort fälschlich akzeptieren.

Der Beleg braucht Tokenlänge, Erzeugungsregel, Wiederverwendungsbereich, offene Lebensdauer, Endpunkt, Beobachtungspunkt und Sicherheitsmodus. Rohwerte müssen nicht breit veröffentlicht werden; ein geschützter Digest kann die notwendige Verknüpfung erhalten. Aber die Bedrohungsannahme darf nicht durch das Etikett „Auth Token“ ersetzt werden.

Hinter einem Vermittler beginnt ein neuer Namensraum

CoAP-Tokens gelten hop-by-hop. Ein Vermittler speichert Client-Token und Transportadresse, erzeugt für seine Anfrage zum Ursprung einen eigenen Token und ordnet die Antwort später wieder dem Client zu.

Der am Server beobachtete Token kann also ausschließlich vom Proxy stammen. Um den ursprünglichen Clientbezug nachzuweisen, werden der untere und obere Datensatz sowie die lokale Zuordnung des Vermittlers benötigt. Schnittstelle, Zeit, Ablauf und Softwareversion gehören dazu.

Eine Observability-Plattform darf daraus eine globale UUID bilden. Sie muss sie jedoch als abgeleitetes Objekt kennzeichnen. Die UUID ist nur so zuverlässig wie Zuordnungscode, Uhr, Speicher und Zugriffskontrolle. CoAP hat sie nicht Ende-zu-Ende übertragen.

Diese Grenze verhindert auch Machtkonzentration. Ein Korrelationsdienst verwaltet Beziehungen zwischen Belegen. Er authentisiert nicht automatisch den Peer, erteilt keine Anwendungsberechtigung und bestätigt keinen physischen Vollzug.

„Zustandslos“ bedeutet nicht ohne Zustand

RFC 8974 beschreibt, wie ein Client Teile seines Anfragezustands in einen erweiterten Token serialisiert und nach dem Echo wiederherstellt. Verfasst wurde der RFC von Klaus Hartke und Michael Richardson, nicht von Bormann. Hier dient er als spätere Belastungsprobe für das Token-Modell.

Das Dokument nennt „stateless“ ausdrücklich eine Vereinfachung. Zustand je Server, Token-Erzeugung und Überlastkontrolle bleiben bestehen. Confirmable-Nachrichten über UDP benötigen außerdem Austauschzustand. Wer auf erweiterte Tokens angewiesen ist, muss die Unterstützung zunächst zustandsbehaftet ermitteln, sofern sie nicht anderweitig verlässlich garantiert wird.

Mit dem serialisierten Zustand reisen neue Risiken: Manipulation, Replay, Alter, private Information und Formatwechsel. Integrität, Replay-Schutz, Frische und gegebenenfalls Verschlüsselung werden erforderlich. Große Tokens können knappen Speicher füllen; mehrere zustandsarme Vermittler können den Wert bei jedem Hop vergrößern.

Der Server bestätigt den Inhalt nicht. Er gibt undurchsichtige Bytes zurück. Der Client gewinnt seinen eigenen Zustand unter seiner eigenen Schutzregel zurück. Der Speicherort hat sich geändert, nicht der Ursprung der Aussage.

Eine prüfbare Quittung hat mehrere Aussteller

Zuerst werden Beobachtungspunkt und Zeit festgehalten. Dann Transport und Endpunkt beziehungsweise Verbindung. Der Sicherheitsmodus, die Sitzung und eine Peer-Behauptung erhalten ein eigenes Feld.

Für UDP folgen Type, Message ID, Wiederholung und Duplikatentscheidung. Für alle Transporte folgen Tokenlänge und geschützte Darstellung, Methode, Ziel, offene Anfrage, Antwortform und Code. Ein Vermittler fügt seine Hop-Zuordnung hinzu.

Danach kommen die Entscheidungen oberhalb des Protokolls: Autorisierung, Ressourcenversion und Frische, Anwendungscommit, Queue-Beleg oder unabhängige Rückmeldung eines Aktors. Eine erfolgreiche CoAP-Antwort kann korrekt sein, obwohl die physische Wirkung später scheitert.

Jeder Beleg besitzt einen anderen Aussteller. Client, Transport, Sicherheitskomponente, Proxy, Server, Anwendung und Gerätehalter können ihre jeweilige Aussage wahr machen. Das IETF legt interoperable Bedingungen fest, betreibt aber keines dieser Systeme.

Auch die Zuschreibung an Bormann bleibt begrenzt

Das am 30. August 2026 geprüfte IETF-Profil führt für Carsten Bormann 65 RFCs sowie aktuelle Rollen als Vorsitzender von CoRE und der Thing-to-Thing Research Group auf. Diese Angaben können sich ändern.

Stabil belegt sind seine Rollen in den Dokumenten: Mitautor von RFC 7252 und erstgenannter Autor von RFC 8323. Beide Standards sind kollektive IETF-Produkte. Sie belegen weder die Konformität eines bestimmten Geräts noch ermächtigen sie einen Autor, über die Risikopolitik eines Betreibers zu entscheiden.

Laufender Code, Konfiguration, Capture, Zustand und Anwendungsergebnis zeigen, was tatsächlich übernommen wurde. Autorenschaft ist Beleg einer Mitwirkung, kein Mandat. Genauso ist die Token-Übereinstimmung Beleg einer Korrelation, keine Identität.

Die Antwort wurde zugeordnet. Für jede weitere Aussage braucht es die passende Quittung.

Quellen