Draft: draft-ietf-core-echo-request-tag

Commentary: 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 the missing IANA section . I 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 ca n't just push your changes , I 'm afraid you 'll have to ask  to add you to the team at 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 .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
This document specifies two server-oriented CoAP options, the Echo
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.
Paragraph (version A):
Additional applications of the options are introduced.  For example,
Echo can be used to mitigate amplification attacks.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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).
Paragraph (version B):
This document specifies two server-oriented CoAP options, the Echo
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
A straightforward mitigation of potential delayed requests is that
the CoAP server rejects a request the first time it appears and asks
the CoAP client to prove that it intended to make the request at this
point in time.  The Echo option, defined in this document, specifies
such a mechanism which thereby enables the CoAP server to verify the
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
state between CoAP client and server.
Paragraph (version B):
A straightforward mitigation of potential delayed requests is that
the CoAP server rejects a request the first time it appears and asks
the CoAP client to prove that it intended to make the request at this
point in time.  The Echo option, defined in this document, specifies
such a mechanism which thereby enables the CoAP server to verify the
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
state between CoAP client and server and to verify aliveness of the
client.
Paragraph (version A):
The Block-Wise Transfer mechanism RFC7959 extends CoAP by defining
the transfer of a large resource representation (CoAP message body)
as a sequence of blocks (CoAP message payloads).  The mechanism uses
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
message bodies to the same endpoint having the same block number.
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
when using RFC7959.
Paragraph (version B):
The Block-Wise Transfer mechanism RFC7959 extends CoAP by defining
the transfer of a large resource representation (CoAP message body)
as a sequence of blocks (CoAP message payloads).  The mechanism uses
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
message bodies to the same resource having the same block number.
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
when using RFC7959.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
The terms "payload" and "body" of a message are used as in RFC7959.
The complete interchange of a request and a response body is called a
(REST) "operation".  An operation fragmented using RFC7959 is called
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".
Paragraph (version B):
The terms "payload" and "body" of a message are used as in RFC7959.
The complete interchange of a request and a response is called a
(REST) "operation".  An operation fragmented using RFC7959 is called
a "blockwise operation".
Paragraph (version A):
The Echo option is a server-driven challenge-response mechanism for
CoAP.  The Echo option value is a challenge from the server to the
client included in a CoAP response and echoed in a CoAP request.
Paragraph (version A):
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.
Paragraph (version A):
It is important to identify under what conditions a CoAP request to a
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.
Paragraph (version A):
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).
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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).
Paragraph (version A):
If the server loses time synchronization, e.g. due to reboot, it MUST
delete all cached Echo option values and response transmission times.
Paragraph (version A):
Constrained server implementations can use the mechanisms outlined in
echo-state to minimize the memory impact of having many unanswered
Echo responses.
Paragraph (version A):
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
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-
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.
Paragraph (version A):
Actuation requests often require freshness guarantees to avoid
accidental or malicious delayed actuator actions.
Paragraph (version B):
The Echo option is a server-driven challenge-response mechanism for
CoAP.  The Echo option value is a challenge from the server to the
client included in a CoAP response and echoed in one or more CoAP
request.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version B):
The application decides under what conditions a CoAP request to a
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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
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-
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.
Paragraph (version B):
Actuation requests often require freshness guarantees to avoid
accidental or malicious delayed actuator actions.  In general, all
non-safe methods (e.g.  POST, PUT, DELETE) may require freshness
guarantees for secure operation.
Paragraph (version A):
If a server reboots during operation it may need to synchronize
state with requesting clients before continuing the interaction.
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.
Paragraph (version B):
If a server reboots during operation it may need to synchronize
state with requesting clients before continuing the interaction.
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.
Paragraph (version A):
A server that sends large responses to unauthenticated peers
SHOULD mitigate amplification attacks such as described in
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
its source address.  This needs to be done only once per peer, and
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.
Paragraph (version B):
A server that sends large responses to unauthenticated peers
SHOULD mitigate amplification attacks such as described in
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
its source address.  This needs to be done only once per peer and
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.
Paragraph (version B):
A server may want to verify the aliveness of a client by
responding with an Echo option.
Paragraph (version A):
Note that this mechanism is implicitly implemented when the security
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.
Paragraph (version B):
Note that this mechanism is implicitly implemented when the security
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.).
Paragraph (version B):
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.