Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing
updates
- rfc-7252 — The Constrained Application Protocol (CoAP)
Extracted elements (30)
An alternative to Request-Tag (updating RFC 7959 to require block assembly in sequence-number order) was rejected because many DTLS implementations do not expose sequence numbers and it would still not prevent block-swapping attacks identified in COAP-ATTACKS.
The Echo option is introduced rather than relying on echoing freshness indicators in CoAP payloads because payload-based approaches only work for methods and response codes that have a defined payload. The Echo option provides a convention that works for all methods and response codes.
The Request-Tag option is elective and safe-to-forward (not critical/unsafe) because servers unaware of it will treat differing Request-Tag values as separate operations — the correct safe behavior — and proxies can still forward such operations without interference.
The Request-Tag option is repeatable to allow cascaded stateless proxies to each append their own origin address without needing to concatenate values; each proxy simply adds a new Request-Tag option unconditionally.
When Block1 and Block2 are combined in a single operation, the Request-Tag value set during the Block1 phase must also be set in the Block2 phase; otherwise the request would have a different option set and would not be recognized as the same operation.
When CoAP over TLS (RFC 8323) is used, the Request-Tag mechanism for body integrity is implicitly satisfied because TLS guarantees ordered delivery, making earlier messages unreplayable as each new message arrives. Clients using TLS without Observe can reuse a Token as soon as the previous response with that Token has been received.
A client MUST only send Echo option values to endpoints it received them from, where the security association is part of the endpoint identity. In OSCORE, Outer Echo values must go back in Outer options and Inner Echo values in Inner options within the same security context.
A CoAP server SHOULD mitigate potential amplification attacks by responding to unauthenticated clients with 4.01 (Unauthorized) including an Echo option. This updates RFC 7252 Section 11.3.
Clients and intermediaries MUST treat an Echo option value as opaque and make no assumptions about its content or structure. Similarly, a server receiving a Request-Tag MUST treat it as opaque.
Echo option values MUST be set by the CoAP server such that the risk associated with unintended reuse can be managed. If uniqueness relies on randomness, a secure PRNG and truly random seeds are essential; pseudorandom numbers must not be reused after reboot without fresh seeds or persistent state.
For block-wise body integrity, the client MUST NOT recycle a request tag in a new operation unless the previous matchable operation has concluded, defined as all messages sent in the operation being invalid if replayed by the server.
For block-wise response body integrity, a server MUST use the Block2 option in conjunction with the ETag option and MUST NOT use the same ETag value for different representations of a resource.
If a request is required to be fresh and the server cannot verify freshness through the Echo option or another means, the server MUST NOT process the request further and SHOULD send a 4.01 (Unauthorized) response with an Echo option.
OSCORE servers MUST only produce Inner Echo options unless they are merely testing for reachability of the client. The Inner option is encrypted and integrity protected end-to-end; the Outer option is visible to proxies and unprotected by OSCORE.
The HTTP-to-CoAP proxy MUST respond to Echo challenges itself if it knows from recent connection establishment that the HTTP request is fresh; otherwise it MUST NOT repeat an unsafe request and SHOULD respond with 503 (Service Unavailable) with Retry-After of 0 seconds.
Upon receiving a 4.01 (Unauthorized) response with the Echo option, the client SHOULD resend the original request with an Echo option containing the received value. Upon receiving any other response with the Echo option, the client SHOULD echo the value in the next request to the server.
When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or Non-confirmable response, never as a separate response (which would cause amplification due to retransmission).
When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST ensure Tokens are not reused in a way that risks responses being associated with the wrong request. Implementing the Token as a sequence number starting at zero per connection SHOULD be followed.
When the Echo option is used to serve freshness requirements (including client aliveness and state synchronization), the Echo option value MUST be integrity protected between the intended endpoints, e.g., using DTLS, TLS, or an OSCORE Inner option.
Implementations SHOULD NOT put privacy-sensitive information in Echo or Request-Tag option values. Unencrypted timestamps can reveal server location, time since reboot, or certificate expiry tolerance. Timestamps MAY be used only when the Echo option is encrypted end-to-end (e.g., DTLS without proxies or OSCORE Inner option).
Like HTTP cookies, Echo option values could be abused as tracking identifiers across requests, especially preemptive values. Servers MUST NOT use the Echo option to correlate requests for purposes other than freshness and reachability. Clients MAY discard all preemptive Echo option values to limit tracking exposure.
The Echo option (number 252) is elective, safe to forward, NoCacheKey, and not repeatable. Its format is opaque with length 1–40 bytes and no default value. It carries a server-generated challenge value that clients must echo back to prove freshness or network reachability.
The Request-Tag option (number 292) is elective, safe to forward, repeatable, and part of the cache key. Its format is opaque with length 0–8 bytes and no default value. It is set by the CoAP client to distinguish concurrent block-wise request operations on the same resource.
IANA has added two entries to the 'CoAP Option Numbers' registry defined by RFC 7252: number 252 (Echo) and number 292 (Request-Tag), both referencing RFC 9175.
A random unique Echo option value SHOULD contain at least 64 pseudorandom bits unpredictable to any party other than the server, providing security equivalent to a 64-bit MAC. Guessable Echo values (based on small random numbers or counters) are only permissible in the narrow set of cases described in Section 2.5.2 where the client is the sole authority.
Servers SHOULD use a monotonic clock for timestamps used in Echo option values. Non-monotonic clocks are not secure because a backward clock shift causes the server to accept expired Echo values; when resetting a timer, the server MUST reject all Echo option values created before the reset.
Token reuse is non-trivial under DTLS/TLS: binding to the correct request can only be claimed without out-of-band knowledge when the original request was never retransmitted and the response was piggybacked in an Acknowledgement. A sequence number approach is RECOMMENDED in all other cases.
Echo challenge-response flow: server receives request → if freshness required and not verifiable, reject with 4.01+Echo → client resends original request with echoed Echo value → server verifies freshness (time-based: t1−t0 < T; or event-based: e0 = e1) → server processes request or sends new Echo on failure.
Echo option: option number 252, format opaque, length 1–40 bytes, no default. Encoded as a standard CoAP option with properties C=0, U=0, N=1, R=0.
Request-Tag option: option number 292, format opaque, length 0–8 bytes, no default. Encoded as a standard CoAP option with properties C=0, U=0, N=0, R=1 (repeatable to allow cascaded proxies to each append their own value).