Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
updates
Extracted elements (26)
A server supporting this extension must handle large tokens far enough through its processing pipeline to return an error response (5.03 or 4.00) rather than a Reset. Returning a Reset would incorrectly signal that the server has no support at all for extended tokens.
Non-confirmable messages are better suited than Confirmable messages for stateless CoAP-over-UDP clients because Confirmable messages require the client to retain message-exchange state for retransmission and to handle ACK/Reset replies.
Serializing per-request state into the token itself allows a client to avoid storing per-request state locally: when the server echoes the token back, the client recovers its state from the token rather than a local store. This trades increased message size for reduced client memory use.
The trial-and-error discovery mechanism deliberately omits any indication of the maximum supported token length. Because a stateless client chooses the shortest token that satisfies its use case, it would likely be unable to reduce the token length further even if the server signaled a lower limit, making the information useless.
RFC 7252 requires an intermediary to return a 5.04 (Gateway Timeout) if it cannot get a response within a timeout, but a stateless intermediary that does not retain client information cannot satisfy this requirement.
Tokens are hop-by-hop: each token is scoped to one client–server exchange. An intermediary is not required to forward the client's token to an upstream server, and extended-token-length discovery must be performed independently for each hop.
When using block-wise transfers, a stateless intermediary may cause a server to conflate blocks from different clients. Intermediaries must use mechanisms such as the Request-Tag Option to keep distinct block-wise operations separate.
A client SHOULD NOT assume that extended token lengths are supported by a server for an unlimited duration. Unless additional information is available, address (and therefore token-length support) validity should be assumed for a minimum of 1800 s and a maximum of 86400 s.
A stateless client MUST handle all three response types: for a piggybacked or separate response that fails token integrity/freshness checks, it discards or rejects the response portion; for a Non-confirmable response that fails, it rejects the message per Section 4.3 of RFC 7252.
A stateless client SHOULD implement replay protection (e.g., sequence numbers with a replay window) to prevent an attacker from making the client believe it received the same response twice.
A stateless client SHOULD protect the integrity of the state information serialized in its token. If replay protection is used, integrity protection is REQUIRED.
An intermediary MUST NOT include an Observe Option in requests it sends unless it keeps both per-request state for its outgoing requests and client information for the incoming requests, because aggregating observations is required by RFC 7641 and impossible without state.
Discovery of extended-token-length support MUST be performed in a stateful way (i.e., the client keeps state for the discovery request). A stateless discovery cannot work because a Reset response carries only the Message ID, so there is no token to recover state from.
If a server receives a request with a token within the advertised limit but is unable to handle it, it MUST NOT treat the request as a message-format error; instead it SHOULD return a 5.03 (Service Unavailable) response.
Intermediaries SHOULD limit the size of client information they serialize into their own tokens, for example by capping the extended token lengths they accept from clients or by falling back to stateful operation when client information exceeds the limit.
The Extended-Token-Length Option value MUST NOT be less than 8 or greater than 65804. If a value less than 8 is received, the option MUST be ignored; if greater than 65804, the option value MUST be treated as 65804.
TKL field value 15 MUST NOT be sent and MUST be processed as a message-format error.
To avoid ambiguity during trial-and-error discovery, it is RECOMMENDED that clients send a request that has no other potential message-format error besides the extended token length (e.g., a GET with only an If-None-Match option).
To reliably discover extended token support via trial and error in CoAP over UDP, clients are REQUIRED to use a Confirmable message, because only Confirmable messages with format errors are guaranteed to elicit a Reset reply.
Serialized state embedded in a token may be privacy-sensitive. A client SHOULD encrypt the serialized state if it contains information an attacker would not otherwise obtain.
The Extended-Token-Length Capability Option (option number 6) is an elective CSM signaling option with format uint, length 0–3 bytes, and base value 8. A server uses it to advertise the maximum token length (in bytes) it can accept in requests; the base value (8) applies when the option is absent.
RFC 8974 adds option number 6 (Extended-Token-Length) to the IANA 'CoAP Signaling Option Numbers' registry within 'CoRE Parameters'. It applies to CSM (7.01) messages.
Serialized state in tokens is vulnerable to replay, modification, and injection by on-path attackers or rogue servers. AES-CCM with a 64-bit tag combined with a sequence number and replay window is recommended; where confidentiality is not needed, HMAC-SHA-256 with a replay window may be used instead.
Tokens significantly larger than 8 bytes can enable denial-of-service attacks on constrained-memory nodes: an on-path attacker or malicious client can send large tokens to exhaust the node's memory. Implementations must be prepared to handle such messages.
When using a nonce-based cipher such as AES-CCM for token encryption, nonce reuse under the same key catastrophically breaks confidentiality. Constrained devices with low-quality entropy sources must use a nonce-generation mechanism guaranteeing uniqueness (e.g., following the OSCORE sender-sequence-number model from RFC 8613 Appendix B.1.1).
The 4-bit TKL field is extended: values 0–12 give the token length directly; value 13 means an 8-bit unsigned integer immediately precedes the Token field and encodes length minus 13; value 14 means a 16-bit unsigned integer in network byte order precedes the Token field and encodes length minus 269; value 15 is reserved. The maximum representable token length is thereby 65804 bytes.