Draft: draft-amsuess-core-repeat-request-tag

Commentary: As suggested by  . The semantics match Unauthorized pretty well : " should not repeat the request without first improving its authentication status " ; like with the WWW - Authenticate header in HTTP , the server gives a way how to do so in the response . [ 1 ] : 
 I 'm fine with 4.01
Paragraph (version A):
This document defines two optional extensions to the Constrained
Application Protocol (CoAP): the Repeat option and the Request-Tag
option.  Each of these options when integrity protected, such as with
DTLS or OSCOAP, protects against certain attacks on CoAP message
exchanges.
Paragraph (version B):
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):
This document specifies two server-oriented CoAP options, the Repeat
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 OSCOAP (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 B):
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):
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 Repeat 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.
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 OSCOAP, within the replay window (I-
D.amsuess-core-request-tag), 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 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.amsuess-core-request-tag), which is a vulnerability of CoAP when
using RFC7959.
Paragraph (version A):
The Repeat and Request-Tag options are defined in this document.  The
concept of two messages being "Request-Tag-matchable" is defined in
req-tag-format.
Paragraph (version A):
The Repeat option is a server-driven challenge-response mechanism for
CoAP.  The Repeat 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 Repeat Option is elective, safe-to-forward, not part of the
cache-key, and not repeatable, see repeat-table.  Note that the
Repeat option has nothing to do with the property of an option being
repeatable, i.e. be allowed to occur more than once in a message, as
defined in Section 5.4.5 of RFC7252.
Paragraph (version A):
The value of the Repeat 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 Repeat option.
Paragraph (version B):
The Echo and Request-Tag options are defined in this document.  The
concept of two messages being "Request-Tag-matchable" is defined in
req-tag-format.
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 a CoAP request.
Paragraph (version B):
The Echo Option is elective, safe-to-forward, not part of the cache-
key, and not repeatable, see echo-table.
Paragraph (version B):
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):
A server MAY include the Repeat option in a response.  The Repeat
option MUST NOT be used with empty CoAP requests.  If the server
receives a request which has freshness requirements, and the request
does not contain the Repeat option, the server SHOULD send a 4.01
Unauthorized response with a Repeat option.  The server SHOULD cache
the transmitted Repeat option value and the response transmit time
(here denoted t0).
Paragraph (version A):
Upon receiving a response with the Repeat option within the
EXCHANGE_LIFETIME (RFC7252) of the original request, the client
SHOULD echo the Repeat option with the same value in a new request to
the server.  Upon receiving a 4.01 Unauthorized response with the
Repeat 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 Repeat 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 repeat-figure.
Paragraph (version A):
When used to serve freshness requirements, CoAP messages containing
the Repeat option MUST be integrity protected, e.g. using DTLS or
OSCOAP (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 Repeat option values and response transmission
times.
Paragraph (version A):
Constrained server implementations can use the mechanisms outlined in
repeat-state to minimize the memory impact of having many unanswered
Repeat responses.
Paragraph (version B):
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
cache the transmitted Echo option value and the response transmit
time (here denoted t0).
Paragraph (version B):
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 B):
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 B):
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 B):
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 B):
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):
To avoid additional roundtrips for applications with multiple
actuator requests in rapid sequence between the same client and
server, the server may use the Repeat option (with a new value) in
response to a request containing the Repeat option.  The client
then uses the Repeat option with the new value in the next
actuation request, and the server compares the receive time
accordingly.
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 OSCOAP it is possible to reuse a persistently
stored security context by synchronizing the Partial IV (sequence
number) using the Repeat option.
Paragraph (version B):
To avoid additional roundtrips for applications with multiple
actuator requests in rapid sequence between the same client and
server, the server may use the Echo option (with a new value) in
response to a request containing the Echo option.  The client then
uses the Echo option with the new value in the next actuation
request, and the server compares the receive time accordingly.
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 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 and
wants to mitigate the amplification attacks described in
Section 11.3 of RFC7252 (where an attacker would put a victim's
address in the source address of a CoAP request) can ask a client
to Repeat its request to verify the 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
Repeat 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 and
wants to mitigate the amplification attacks described in
Section 11.3 of RFC7252 (where an attacker would put a victim's
address in the source address of a CoAP request) can ask a client
to Echo its request to verify the 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 A):
Request-Tag, like the Block1 option, is a special class E option in
terms of OSCOAP processing (see Section 4.3.1.2 of I-D.ietf-core-
object-security): The Request-Tag MAY be an inner or outer option.
The inner option is encrypted and integrity protected between client
and server, and provides message body identification in case of end-
to-end fragmentation of requests.  The outer option is visible to
proxies and labels message bodies in case of hop-by-hop fragmentation
of requests.
Paragraph (version B):
Request-Tag, like the Block1 option, is a special class E option in
terms of OSCORE processing (see Section 4.3.1.2 of I-D.ietf-core-
object-security): The Request-Tag MAY be an inner or outer option.
The inner option is encrypted and integrity protected between client
and server, and provides message body identification in case of end-
to-end fragmentation of requests.  The outer option is visible to
proxies and labels message bodies in case of hop-by-hop fragmentation
of requests.
Paragraph (version A):
A server MUST NOT act on any two blocks in the same blockwise request
operation that are not Request-Tag-matchable.  This also means that a
block cannot overwrite kept context when the Request-Tag does not
match (cf.  RFC7959 Section 2.5).  The server is still under no
obligation to keep state of more than one transaction.  When an
operation is in progress and a second one cannot be served at the
same time, the server MUST respond to the second request with a 5.03
(Service Unavailable) response code and SHOULD indicate the time it
is willing to wait for additional blocks in the first operation using
the Max-Age option, as specified in Section 5.9.3.4 of RFC7252.
Paragraph (version B):
A server MUST NOT act on any two blocks in the same blockwise request
operation that are not Request-Tag-matchable.  This rule applies
independent of whether the request actually carries a Request-Tag
option (in this case, the request can only be acted on together with
other messages not carrying the option, as per matchability
definition).
Paragraph (version B):
As not all messages from the same source can be combined any more, a
block not matchable to the first Block1 cannot overwrite context kept
for an operation under a different tag (cf.  RFC7959 Section 2.5).
The server is still under no obligation to keep state of more than
one transaction.  When an operation is in progress and a second one
cannot be served at the same time, the server MUST respond to the
second request with a 5.03 (Service Unavailable) response code and
SHOULD indicate the time it is willing to wait for additional blocks
in the first operation using the Max-Age option, as specified in
Section 5.9.3.4 of RFC7252.
Paragraph (version A):
If a request that uses Request-Tag is rejected with 4.02 Bad Option,
the client MAY retry the operation without it, but then it MUST
serialize all operations that affect the same resource.  Security
requirements can forbid dropping the Request-Tag option.
Paragraph (version B):
If a request that uses Request-Tag is rejected with 4.02 Bad Option,
the client MAY retry the operation without it, but then it MUST
serialize all operations that affect the same resource.  Security
requirements can forbid dropping the use of Request-Tag mechanism.
Paragraph (version A):
Typically, in OSCOAP, these confirmations can result either from
the client receiving an OSCOAP response message matching the
request (an empty ACK is insufficient), or because the message's
sequence number is old enough to be outside the server's receive
window.
Paragraph (version B):
Typically, in OSCORE, these confirmations can result either from
the client receiving an OSCORE response message matching the
request (an empty ACK is insufficient), or because the message's
sequence number is old enough to be outside the server's receive
window.
Paragraph (version A):
CoAP clients, especially CoAP proxies, may initiate a blockwise
request operation to a resource, to which a previous one is already
in progress, and which the new request should not cancel.  One
example is when a CoAP proxy fragments an OSCOAP messages using
blockwise (so-called "outer" blockwise, see Section 4.3.1. of I-
D.ietf-core-object-security)), where the Uri-Path is hidden inside
the encrypted message, and all the proxy sees is the server's "/"
path.
Paragraph (version B):
CoAP clients, especially CoAP proxies, may initiate a blockwise
request operation to a resource, to which a previous one is already
in progress, and which the new request should not cancel.  One
example is when a CoAP proxy fragments an OSCORE messages using
blockwise (so-called "outer" blockwise, see Section 4.3.1. of I-
D.ietf-core-object-security)), where the Uri-Path is hidden inside
the encrypted message, and all the proxy sees is the server's "/"
path.