Change:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.

Discussion:
Abstract <del> This document defines two optional extensions to the Constrained Application Protocol (CoAP): the Echo option and the Request-Tag option.  Each of these options when integrity protected, such as with DTLS or OSCORE, protects against certain attacks on CoAP message exchanges. The Echo option enables a CoAP server to verify the freshness of a request by requiring the CoAP client to make another request and include a server-provided challenge.  The Request-Tag option allows the CoAP server to match message fragments belonging to the same request message, fragmented using the CoAP Block-Wise Transfer mechanism.  This document also specifies additional processing requirements on Block1 and Block2 options. </del> <ins> This document specifies several security enhancements to the Constrained Application Protocol (CoAP).  Two optional extensions are defined: the Echo option and the Request-Tag option.  Each of these options provide additional features to CoAP and protects against certain attacks.  The document also updates the processing requirements on the Block options and the Token.  The updated Token processing ensures secure binding of responses to requests. </ins> 1. <del> The initial CoAP suite of specifications (RFC7252, RFC7641, RFC7959) was designed with the assumption that security could be provided on a separate layer, in particular by using DTLS (RFC6347).  However, for some use cases, additional functionality or extra processing is needed to support secure CoAP operations. </del> <ins> The initial Constrained Application Protocol (CoAP) suite of specifications (RFC7252, RFC7641, and RFC7959) was designed with the assumption that security could be provided on a separate layer, in particular by using DTLS (RFC6347).  However, for some use cases, additional functionality or extra processing is needed to support secure CoAP operations.  This document specifies several security enhancements to the Constrained Application Protocol (CoAP). </ins> This document specifies two server-oriented CoAP options, the Echo <del> option and the Request-Tag option, addressing the security features request freshness and fragmented message body integrity, respectively.  These options in themselves do not replace the need for a security protocol; they specify the format and processing of data which, when integrity protected in a message, e.g. using DTLS (RFC6347) or OSCORE (I-D.ietf-core-object-security), provide those security features.  The Request-Tag option and also the ETag option are mandatory to use with Block1 and Block2, respectively, to secure blockwise operations with multiple representations of a particular resource as is specified in this document. Additional applications of the options are introduced.  For example, Echo can be used to mitigate amplification attacks. </del> <ins> option and the Request-Tag option, mainly addressing the security features request freshness and fragmented message body integrity, respectively.  The Echo option enables a CoAP server to verify the freshness of a request, verify the aliveness of a client, synchronize state, or force a client to demonstrate reachability at its apparent network address.  The Request-Tag option allows the CoAP server to match message fragments belonging to the same request, fragmented using the CoAP Block-Wise Transfer mechanism, which mitigates attacks and enables concurrent blockwise operations.  These options in themselves do not replace the need for a security protocol; they specify the format and processing of data which, when integrity protected using e.g.  DTLS (RFC6347), TLS (RFC5246), or OSCORE (I- D.ietf-core-object-security), provide the additional security features. The document also updates the processing requirements on the Block1 option, the Block2 option, and the Token.  The updated blockwise processing secure blockwise operations with multiple representations of a particular resource.  The updated Token processing ensures secure binding of responses to requests. </ins> 1.1. <del> A CoAP server receiving a request may not be able to verify when the request was sent by the CoAP client.  This remains true even if the request was protected with a security protocol, such as DTLS.  This makes CoAP requests vulnerable to certain delay attacks which are particularly incriminating in the case of actuators (I-D.mattsson- core-coap-actuators).  Some attacks are possible to mitigate by establishing fresh session keys (e.g. performing the DTLS handshake) for each actuation, but in general this is not a solution suitable for constrained environments. </del> <ins> A CoAP server receiving a request is in general not able to verify when the request was sent by the CoAP client.  This remains true even if the request was protected with a security protocol, such as DTLS. This makes CoAP requests vulnerable to certain delay attacks which are particularly incriminating in the case of actuators (I- D.mattsson-core-coap-actuators).  Some attacks are possible to mitigate by establishing fresh session keys (e.g. performing the DTLS handshake) for each actuation, but in general this is not a solution suitable for constrained environments. </ins> A straightforward mitigation of potential delayed requests is that the CoAP server rejects a request the first time it appears and asks

freshness of a request.  This mechanism is not only important in the case of actuators, or other use cases where the CoAP operations require freshness of requests, but also in general for synchronizing <del> state between CoAP client and server. </del> <ins> state between CoAP client and server and to verify aliveness of the client. </ins> 1.2.

a pair of CoAP options, Block1 and Block2, pertaining to the request and response payload, respectively.  The blockwise functionality does not support the detection of interchanged blocks between different <del> message bodies to the same endpoint having the same block number. </del> <ins> message bodies to the same resource having the same block number. </ins> This remains true even when CoAP is used together with a security protocol such as DTLS or OSCORE, within the replay window (I- D.mattsson-core-coap-actuators), which is a vulnerability of CoAP

1.3. <ins> A fundamental requirement of secure REST operations is that the client can bind a response to a particular request.  In HTTPS this is assured by the ordered and reliable delivery as well as mandating that the server sends responses in the same order that the requests were received. The same is not true for CoAP where the server can return responses in any order.  Concurrent requests are instead differentiated by their Token.  Unfortunately, CoAP RFC7252 does not treat Token as a cryptographically important value and does not give stricter guidelines than that the tokens currently "in use" SHOULD (not SHALL) be unique.  If used with security protocol not providing bindings between requests and responses (e.g.  DTLS and TLS) token reuse may result in situations where a client matches a response to the wrong request (see e.g.  Section 2.3 of I-D.mattsson-core-coap-actuators). Note that mismatches can also happen for other reasons than a malicious attacker, e.g. delayed delivery or a server sending notifications to an uninterested client. A straightforward mitigation is to mandate clients to never reuse tokens until the traffic keys have been replaced.  As there may be any number of responses to a request (see e.g.  RFC7641), the easiest way to accomplish this is to implement the token as a counter and never reuse any tokens at all.  This document updates the Token processing in RFC7252 to always assure a cryptographically secure binding of responses to requests. 1.4. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

"CoAP client" and "CoAP server", respectively, as defined in RFC7252. The terms "payload" and "body" of a message are used as in RFC7959. <del> The complete interchange of a request and a response body is called a </del> <ins> The complete interchange of a request and a response is called a </ins> (REST) "operation".  An operation fragmented using RFC7959 is called <del> a "blockwise operation".  A blockwise operation which is fragmenting the request body is called a "blockwise request operation".  A blockwise operation which is fragmenting the response body is called a "blockwise response operation". </del> <ins> a "blockwise operation". </ins> Two blockwise operations between the same endpoint pair on the same resource are said to be "concurrent" if a block of the second request

The Echo option is a server-driven challenge-response mechanism for CoAP.  The Echo option value is a challenge from the server to the <del> client included in a CoAP response and echoed in a CoAP request. </del> <ins> client included in a CoAP response and echoed in one or more CoAP request. </ins> 2.1. The Echo Option is elective, safe-to-forward, not part of the cache- key, and not repeatable, see echo-table. <del> The value of the Echo option MUST be a (pseudo-)random bit string of a length of at least 64 bits.  A new (pseudo-)random bit string MUST be generated by the server for each use of the Echo option. </del> <ins> [Note to RFC editor: If this document is not released together with OSCORE but before it, the following paragraph and the "E" column above need to move into OSCORE.] The Echo option value is generated by the server, and its content and structure are implementation specific.  Different methods for generating Echo option values are outlined in echo-state.  Clients and intermediaries MUST treat an Echo option value as opaque and make no assumptions about its content or structure. When receiving an Echo option in a request, the server MUST be able to verify that the Echo option value was generated by the server as well as the point in time when the Echo option value was generated. </ins> 2.2. <del> It is important to identify under what conditions a CoAP request to a </del> <ins> The Echo option MAY be included in any request or response (see echo- app for different applications), but the Echo option MUST NOT be used with empty CoAP requests (i.e.  Code=0.00). If the server receives a request which has freshness requirements, the request does not contain a fresh Echo option value, and the server cannot verify the freshness of the request in some other way, the server MUST NOT process the request further and SHOULD send a 4.01 Unauthorized response with an Echo option. The application decides under what conditions a CoAP request to a </ins> resource is required to be fresh.  These conditions can for example include what resource is requested, the request method and other data in the request, and conditions in the environment such as the state of the server or the time of the day. <del> A server MAY include the Echo option in a response.  The Echo option MUST NOT be used with empty CoAP requests (i.e.  Code=0.00).  If the server receives a request which has freshness requirements, and the request does not contain the Echo option, the server SHOULD send a 4.01 Unauthorized response with a Echo option.  The server SHOULD cache the transmitted Echo option value and the response transmit time (here denoted t0). Upon receiving a response with the Echo option within the EXCHANGE_LIFETIME (RFC7252) of the original request, the client SHOULD echo the Echo option with the same value in a new request to the server.  Upon receiving a 4.01 Unauthorized response with the Echo option in response to a request within the EXCHANGE_LIFETIME of the original request, the client SHOULD resend the original request. The client MAY send a different request compared to the original request. If the server receives a request which has freshness requirements, and the request contains the Echo option, the server MUST verify that the option value equals a cached value; otherwise the request is not processed further.  The server MUST calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure. When used to serve freshness requirements, CoAP messages containing the Echo option MUST be integrity protected, e.g. using DTLS or OSCORE (I-D.ietf-core-object-security). If the server loses time synchronization, e.g. due to reboot, it MUST delete all cached Echo option values and response transmission times. Constrained server implementations can use the mechanisms outlined in echo-state to minimize the memory impact of having many unanswered Echo responses. CoAP-CoAP proxies MUST relay the Echo option unmodified, and SHOULD NOT cache responses when a Echo option is present in request or response for more than the exchange.  CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (eg. because it is a PUT or POST); how this is determined is out of scope for this document.  HTTP-CoAP-Proxies SHOULD respond </del> <ins> The server may also include the Echo option in a response to verify the aliveness of a client, to synchronize state, or to force a client to demonstrate reachability at their apparent network address. Upon receiving a 4.01 Unauthorized response with the Echo option, the client SHOULD resend the original request with the addition of an Echo option with the received Echo option value.  The client MAY send a different request compared to the original request.  Upon receiving any other response with the Echo option, the client SHOULD echo the Echo option value in a next request to the server.  The client MAY include the same Echo option value in several different requests to the server. Upon receiving a request with the Echo option, the server determines if the request has freshness requirement.  If the request does not have freshness requirements, the Echo option MAY be ignored.  If the request has freshness requirements and the server cannot verify the freshness of the request in some other way, the server MUST verify that the Echo option value was generated by the server; otherwise the request is not processed further.  The server MUST then calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time and t0 is the transmit time of the response that included the specific Echo option value.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure. When used to serve freshness requirements (including client aliveness and state synchronizing), CoAP requests containing the Echo option MUST be integrity protected, e.g. using DTLS, TLS, or OSCORE (I- D.ietf-core-object-security).  When used to demonstrate reachability at their apparent network address, the Echo option MAY be used without protection. Note that the server does not have to synchronize the time used for the Echo timestamps with any other party.  If the server loses time synchronization, e.g. due to reboot, it MUST reject all Echo values that was created before time synchronization was lost. CoAP-CoAP proxies MUST relay the Echo option unmodified.  The CoAP server side of CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (e.g. because it is a PUT or POST); how this is determined is out of scope for this document.  The CoAP client side of HTTP-CoAP-Proxies SHOULD respond </ins> to Echo challenges themselves if they know from the recent establishing of the connection that the HTTP request is fresh. Otherwise, they SHOULD respond with 503 Service Unavailable, Retry- <del> After: 0 and terminate any underlying Keep-Alive connection.  It MAY also use other mechanisms to establish freshness of the HTTP request that are not specified here. </del> <ins> After: 0 and terminate any underlying Keep-Alive connection.  They MAY also use other mechanisms to establish freshness of the HTTP request that are not specified here. </ins> 2.3. Actuation requests often require freshness guarantees to avoid <del> accidental or malicious delayed actuator actions. </del> <ins> accidental or malicious delayed actuator actions.  In general, all non-safe methods (e.g.  POST, PUT, DELETE) may require freshness guarantees for secure operation. </ins> To avoid additional roundtrips for applications with multiple actuator requests in rapid sequence between the same client and

If a server reboots during operation it may need to synchronize state with requesting clients before continuing the interaction. <del> For example, with OSCORE it is possible to reuse a persistently stored security context by synchronizing the Partial IV (sequence number) using the Echo option. </del> <ins> For example, with OSCORE it is possible to reuse a partly persistently stored security context by synchronizing the Partial IV (sequence number) using the Echo option. </ins> When a device joins a multicast/broadcast group the device may need to synchronize state or time with the sender to ensure that

Section 11.3 of RFC7252 (where an attacker would put a victim's address in the source address of a CoAP request).  For this purpose, the server MAY ask a client to Echo its request to verify <del> its source address.  This needs to be done only once per peer, and </del> <ins> its source address.  This needs to be done only once per peer and </ins> limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. <ins> A server may want to verify the aliveness of a client by responding with an Echo option. </ins> 3. The Request-Tag is intended for use as a short-lived identifier for

body. Note that this mechanism is implicitly implemented when the security <del> layer guarantees ordered delivery (e.g.  CoAP over TLS I- D.tschofenig-core-coap-tcp-tls).  This is because with each message, any earlier operation can be regarded as concluded by the client, so it never needs to set the Request-Tag option unless it wants to perform concurrent operations. </del> <ins> layer guarantees ordered delivery (e.g.  CoAP over TLS RFC8323). This is because with each message, any earlier operation can be regarded as concluded by the client, so it never needs to set the Request-Tag option unless it wants to perform concurrent operations. </ins> 3.3.2.

5. <del> [TBD: Fill out the option templates for Echo and Request-Tag] </del> <ins> This section updates the Token processing in Section 5.3.1 of RFC7252 by adding the following text: When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens until the traffic keys have been replaced.  The easiest way to accomplish this is to implement the Token as a counter, this approach SHOULD be followed. </ins> 6. <del> Servers that store a Echo challenge per client can be attacked for resource exhaustion, and should consider minimizing the state kept per client, e.g. using a mechanism as described in echo-state. </del> <ins> This document adds the following option numbers to the "CoAP Option Numbers" registry defined by RFC7252: 7. Servers SHOULD NOT put any privacy sensitive information in the Echo or Request-Tag option values.  Unencrypted timestamps MAY reveal information about the server such as its system time or location. Servers MUST use a monotonic clock to generate timestamps and compute round-trip times.  Servers SHOULD NOT use their system time for timestamps, as system time is often not monotonic, may reveal that the server will accept expired certificates, or reveal the server's location.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is moved backward.  The server will also reject fresh Echo option values if the clock is moved forward.  An attacker may be able to affect the server's system time in various ways such as setting up a fake NTP server or broadcasting false time signals to radio-controlled clocks. Servers SHOULD use the time since reboot measured in some unit of time.  Servers MAY reset the timer periodically even when not rebooting. The availability of a secure pseudorandom number generator and truly random seeds are essential for the security of the Echo option.  If no true random number generator is available, a truly random seed must be provided from an external source. An Echo value with 64 (pseudo-)random bits gives the same theoretical security level against forgeries as a 64-bit MAC (as used in e.g. AES_128_CCM_8).  In practice, forgery of an Echo option value is much harder as an attacker must also forge the MAC in the security protocol.  The Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to be terminated at the proxies.  The proxies are therefore able to manipulate, inject, delete, or reorder options or packets.  The security claims in such architectures only hold under the assumption that all intermediaries are fully trusted and have not been compromised. Servers that use the List of Cached Random Values and Timestamps method described in echo-state may be vulnerable to resource exhaustion attacks.  On way to minimizing state is to use the Integrity Protected Timestamp method described in echo-state. </ins>