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

Commentary: Most of this is described in my response to -- the most controversial is probably , but I 'd appreciate eyes on the rest as well . 
 I 'm happy with the changes except for those points already discussed per mail ( text on clients using an Echo value on other links , and issues with the token reuse considerations for DTLS ) . Merging this to now to keep the changes more managable ( ie . newer commits can go into new branches ) .
Mailing list commentary: Here are some comments : 1 . The Abstract needs to say that it updates RFC 7252 - and it would be nice if it summarized what it updated . 2 . You can clean up the text dealing with core - object - security 3 . In section 2.1 - It is not clear to me why one would use an outer option for the echo option . The inner one would be end - to - end and thus does the freshness thing . What does the outer one do ? 4 . In section 2.1 ( or section 2.2 ) - There needs to be some text about where the echo options should be reflected in the event that either both inner and outer options are returned or just an outer is returned . Can you use an inner w/o security for a new request ? I.e. is the inner echo value considered to be a security value ? 5 . Not sure if it is permissible for a proxy to modify the request in response to a 4.01 with an echo option or not . Clarification might be useful on this topic . I think I understand the paragraphs about proxies as servers . 6 . In section 2.3 - item 1 star 2 - I would think that a server could proactively return an echo option even if the request did not come with one . Thus GET - Content w/ echo - PUT w/ echo 7 . In section 2.3 - item 2 - star 2 - s / expect / except/ 8 . In section 3 it says that the requests must be integrity protected , but in section 3.1 it says that this may be an outer option and is of class E not class  ( And I recognize that it can not be class I. ) I think that section 3 is probably the incorrect one . 9 . I think that section 3.4.1 is missing something , but I have not figure out what it is yet . I 'll continue to mull this one over . 10 . Section 3.4.2 - I think that it would be reasonable to highlight that two OSCORE blockwise operations meet these conditions as the path is hidden by security . 11 . Section 6 - I am having problems with the idea of a forgery of an Echo option , if the option is visible to an attacker why would they need to forge it ? 12 . Appendix A - I think we have a different definition of forgery for list item 1 . I would have labeled this as guessing not forgery . That is probably my security background talking . 13 . Appendix A - point 2 - The security is even higher if encryption rather than integrity is used here .
Paragraph (version A):
This document specifies enhancements to the Constrained Application
Protocol (CoAP) that mitigate security issues in particular use
cases.  The Echo option enables a CoAP server to verify the freshness
of a request or to force a client to demonstrate reachability at its
claimed network address.  The Request-Tag option allows the CoAP
server to match Block-Wise message fragments belonging to the same
request.  The updated Token processing requirements for clients
ensure secure binding of responses to requests when CoAP is used with
security.
Paragraph (version B):
This document specifies enhancements to the Constrained Application
Protocol (CoAP) that mitigate security issues in particular use
cases.  The Echo option enables a CoAP server to verify the freshness
of a request or to force a client to demonstrate reachability at its
claimed network address.  The Request-Tag option allows the CoAP
server to match block-wise message fragments belonging to the same
request.  The update to the client Token processing requirements of
RFC 7252 forbids non-secure reuse of Tokens to ensure binding of
responses to requests when CoAP is used with security.
Paragraph (version A):
This document specifies two CoAP options, the Echo option and the
Request-Tag option: The Echo option enables a CoAP server to verify
the freshness of a request, synchronize state, or force a client to
demonstrate reachability at its claimed 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 (RFC8446), or OSCORE (I-D.ietf-core-object-security), provide the
additional security features.
Paragraph (version A):
The document also updates the Token processing requirements for
clients specified in RFC7252.  The updated processing ensures secure
binding of responses to requests when CoAP is used with security,
thus mitigating error cases and attacks where the client may
erroneously associate the wrong response to a request.
Paragraph (version B):
This document specifies two CoAP options, the Echo option and the
Request-Tag option: The Echo option enables a CoAP server to verify
the freshness of a request, synchronize state, or force a client to
demonstrate reachability at its claimed 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
block-wise 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 (RFC8446), or OSCORE (RFC8613), provide the additional
security features.
Paragraph (version B):
The document also updates the Token processing requirements for
clients specified in RFC7252.  The updated processing forbids non-
secure reuse of Tokens to ensure binding of responses to requests
when CoAP is used with security, thus mitigating error cases and
attacks where the client may erroneously associate the wrong response
to a request.
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 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):
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 block-wise 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 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 body is called a
(REST) "operation".  An operation fragmented using RFC7959 is called
a "block-wise operation".  A block-wise operation which is
fragmenting the request body is called a "block-wise request
operation".  A block-wise operation which is fragmenting the response
body is called a "block-wise response operation".
Paragraph (version A):
Two matchable blockwise operations are said to be "concurrent" if a
block of the second request is exchanged even though the client still
intends to exchange further blocks in the first operation.
(Concurrent blockwise request operations are impossible with the
options of RFC7959 because the second operation's block overwrites
any state of the first exchange.).
Paragraph (version B):
Two matchable block-wise operations are said to be "concurrent" if a
block of the second request is exchanged even though the client still
intends to exchange further blocks in the first operation.
(Concurrent block-wise request operations are impossible with the
options of RFC7959 because the second operation's block overwrites
any state of the first exchange.).
Paragraph (version A):
When the Echo option is used with OSCORE I-D.ietf-core-object-
security it MAY be an Inner or Outer option, and the Inner and Outer
values are independent.  The Inner option is encrypted and integrity
protected between the endpoints, whereas the Outer option is not
protected by OSCORE and visible between the endpoints to the extent
it is not protected by some other security protocol.  E.g. in the
case of DTLS hop-by-hop between the endpoints, the Outer option is
visible to proxies along the path.
Paragraph (version B):
When the Echo option is used with OSCORE RFC8613 it MAY be an Inner
or Outer option, and the Inner and Outer values are independent.
Paragraph (version B):
OSCORE servers MUST only produce Inner Echo options, but clients need
to use Outer Echo as well, as reaction to a proxy testing
reachability of the client using a CoAP error message including Echo
in response to a previous OSCORE message from the client.  The Inner
option is encrypted and integrity protected between the endpoints,
whereas the Outer option is not protected by OSCORE and visible
between the endpoints to the extent it is not protected by some other
security protocol.  E.g. in the case of DTLS hop-by-hop between the
endpoints, the Outer option is visible to proxies along the path.
Paragraph (version B):
When OSCORE is used, client and server MUST process Inner (Class E
use) and Outer (Class U use) Echo options independently.  That is, a
client MUST NOT echo an Inner response value in an Outer request
value or vice versa, and the server MUST NOT accept Echo values from
a different class than where it sent them.
Paragraph (version A):
When used to serve freshness requirements (including client aliveness
and state synchronizing), CoAP messages containing the Echo option
MUST be integrity protected between the intended endpoints, e.g.
using DTLS, TLS, or an OSCORE Inner option (I-D.ietf-core-object-
security).  When used to demonstrate reachability at a claimed
network address, the Echo option SHOULD contain the client's network
address, but MAY be unprotected.
Paragraph (version B):
When used to serve freshness requirements (including client aliveness
and state synchronizing), CoAP messages containing the Echo option
MUST be integrity protected between the intended endpoints, e.g.
using DTLS, TLS, or an OSCORE Inner option (RFC8613).  When used to
demonstrate reachability at a claimed network address, the Echo
option SHOULD contain the client's network address, but MAY be
unprotected.
Paragraph (version A):
For actuator applications with low delay tolerance, to avoid
additional round-trips for multiple requests in rapid sequence,
the server may include 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):
For actuator applications with low delay tolerance, to avoid
additional round-trips for multiple requests in rapid sequence,
the server may include the Echo option with a new value even in
a successful response to a request, irrespectively of whether
the request contained an Echo option or not.  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 A):
If a server reboots during operation it may need to synchronize
state or time 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, see Section 7.5 of I-
D.ietf-core-object-security.
Paragraph (version B):
If a server reboots during operation it may need to synchronize
state or time 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, see Section 7.5 of
RFC8613.
Paragraph (version A):
A device joining a CoAP group communication RFC7390 protected
with OSCORE I-D.ietf-core-oscore-groupcomm may be required to
initially verify freshness and synchronize state or time with a
client by using the Echo option in a unicast response to a
multicast request.  The client receiving the response with the
Echo option includes the Echo option with the same value in a
request, either in a unicast request to the responding server,
or in a subsequent group request.  In the latter case, the Echo
option will be ignored expect by responding server.
Paragraph (version B):
A device joining a CoAP group communication RFC7390 protected
with OSCORE I-D.ietf-core-oscore-groupcomm may be required to
initially verify freshness and synchronize state or time with a
client by using the Echo option in a unicast response to a
multicast request.  The client receiving the response with the
Echo option includes the Echo option with the same value in a
request, either in a unicast request to the responding server,
or in a subsequent group request.  In the latter case, the Echo
option will be ignored except by the responding server.
Paragraph (version A):
The Request-Tag is intended for use as a short-lived identifier for
keeping apart distinct blockwise request operations on one resource
from one client, addressing the issue described in body-int.  It
enables the receiving server to reliably assemble request payloads
(blocks) to their message bodies, and, if it chooses to support it,
to reliably process simultaneous blockwise request operations on a
single resource.  The requests must be integrity protected in order
to protect against interchange of blocks between different message
bodies.
Paragraph (version B):
The Request-Tag is intended for use as a short-lived identifier for
keeping apart distinct block-wise request operations on one resource
from one client, addressing the issue described in body-int.  It
enables the receiving server to reliably assemble request payloads
(blocks) to their message bodies, and, if it chooses to support it,
to reliably process simultaneous block-wise request operations on a
single resource.  The requests must be integrity protected if they
should protect against interchange of blocks between different
message bodies.
Paragraph (version A):
Request-Tag, like the block options, is both a class E and a class U
option in terms of OSCORE processing (see Section 4.1 of I-D.ietf-
core-object-security): The Request-Tag MAY be an inner or outer
option.  It influences the inner or outer block operation,
respectively.  The inner and outer values are therefore independent
of each other.  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):
The Request-Tag option is only used in the request messages of
blockwise operations.
Paragraph (version B):
Request-Tag, like the block options, is both a class E and a class U
option in terms of OSCORE processing (see Section 4.1 of RFC8613):
The Request-Tag MAY be an inner or outer option.  It influences the
inner or outer block operation, respectively.  The inner and outer
values are therefore independent of each other.  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):
The Request-Tag option is only used in the request messages of block-
wise operations.
Paragraph (version A):
The Request-Tag option does not require any particular processing on
the server side outside of the processing already necessary for any
unknown elective proxy-safe cache-key option: The option varies the
properties that distinguish blockwise operations (which includes all
options except elective NoCacheKey and except Block1/2), and thus the
server can not treat messages with a different list of Request-Tag
options as belonging to the same operation.
Paragraph (version B):
The Request-Tag option does not require any particular processing on
the server side outside of the processing already necessary for any
unknown elective proxy-safe cache-key option: The option varies the
properties that distinguish block-wise operations (which includes all
options except elective NoCacheKey and except Block1/2), and thus the
server can not treat messages with a different list of Request-Tag
options as belonging to the same operation.
Paragraph (version A):
For each separate blockwise request operation, the client can choose
a Request-Tag value, or choose not to set a Request-Tag.  Starting a
request operation matchable to a previous operation and even using
the same Request-Tag value is called request tag recycling.  The
absence of a Request-Tag option is viewed as a value distinct from
all values with a single Request-Tag option set; starting a request
operation matchable to a previous operation where neither has a
Request-Tag option therefore constitutes request tag recycling just
as well (also called "recycling the absent option").
Paragraph (version B):
For each separate block-wise request operation, the client can choose
a Request-Tag value, or choose not to set a Request-Tag.  Starting a
request operation matchable to a previous operation and even using
the same Request-Tag value is called request tag recycling.  The
absence of a Request-Tag option is viewed as a value distinct from
all values with a single Request-Tag option set; starting a request
operation matchable to a previous operation where neither has a
Request-Tag option therefore constitutes request tag recycling just
as well (also called "recycling the absent option").
Paragraph (version A):
The client MUST NOT regard a blockwise request operation as
concluded unless all of the messages the client previously sent in
the operation have been confirmed by the message integrity
protection mechanism, or are considered invalid by the server if
replayed.
Paragraph (version B):
The client MUST NOT regard a block-wise request operation as
concluded unless all of the messages the client previously sent in
the operation have been confirmed by the message integrity
protection mechanism, or are considered invalid by the server if
replayed.
Paragraph (version A):
Authors of other documents (e.g.  I-D.ietf-core-object-security) are
invited to mandate this behavior for clients that execute blockwise
interactions over secured transports.  In this way, the server can
rely on a conforming client to set the Request-Tag option when
required, and thereby conclude on the integrity of the assembled
body.
Paragraph (version B):
Authors of other documents (e.g. applications of RFC8613) are invited
to mandate this behavior for clients that execute block-wise
interactions over secured transports.  In this way, the server can
rely on a conforming client to set the Request-Tag option when
required, and thereby conclude on the integrity of the assembled
body.
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, which the new request should not cancel.  A CoAP proxy
would be in such a situation when it forwards operations with the
same cache-key options but possibly different payloads.
Paragraph (version B):
CoAP clients, especially CoAP proxies, may initiate a block-wise
request operation to a resource, to which a previous one is already
in progress, which the new request should not cancel.  A CoAP proxy
would be in such a situation when it forwards operations with the
same cache-key options but possibly different payloads.
Paragraph (version A):
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 A):
A single active 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 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.  As each pseudoranom number
must only be used once, an implementation need to get a new truly
random seed after reboot, or continously store state in nonvolatile
memory, see (RFC8613, Appendix B.1.1) for issues and solution
approaches for writing to nonvolatile memory.
Paragraph (version B):
A single active Echo value with 64 (pseudo-)random bits gives the
same theoretical security level as a 64-bit MAC (as used in e.g.
AES_128_CCM_8).  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 A):
When the Token (or part of the Token) contains a sequence number, the
encoding of the sequence number has to be chosen in a way to avoid
any collisions.  This is especially true when the Token contains more
information than just the sequence number (e.g. serialized state).
Paragraph (version B):
Reusing Tokens in a way so that responses are guaranteed to not be
associated with the wrong request is not trivial as on-path attackers
may block, delay, and reorder messages, requests may be send to
several servers, and servers may process requests in any order and
send many responses to the same request.  The use of a sequence
number is therefore recommended when CoAP is used with a security
protocol that does not providing bindings between requests and
responses such as DTLS or TLS.
Paragraph (version B):
Even when a client is sending DTLS protected requests without Observe
to a single server, the client cannot reuse a Token simply because a
response has been received as the server may have retransmitted the
response.  The client would need to determine when the server
received the request, how long after receival the server may send a
response, and then make sure that it has received least (client
replay window size) many responses sent after that.  This is in
general not possible and Token reuse with DTLS is therefore strongly
not recommended.
Paragraph (version B):
Token reuse for TLS is much easier to do securely as retransmissions
are not handled by the CoAP layer and the replay window size is
always exactly 1.  When a client is sending TLS protected requests
without Observe to a single server, the client can reuse a Token as
soon as the previous response with that Token has been received.
Paragraph (version B):
When using Observe, the Token used for registration cannot be reused
until the client can confirm that the server has cancelled the
registration and that all notifications (including retransmissions)
will be blocked by the clients replay window.
Paragraph (version B):
When the Token (or part of the Token) contains a sequence number, the
encoding of the sequence number has to be chosen in a way to avoid
any collisions.  This is especially true when the Token contains more
information than just the sequence number, e.g. serialized state as
in I-D.ietf-core-stateless.
Paragraph (version B):
Like HTTP cookies, the Echo option could potentially be abused as a
tracking mechanism to link to different requests to the same client.
This is especially true for pre-emptive Echo values.  Servers MUST
NOT use the Echo option to correlate requests for other purposes than
freshness and reachability.  Clients SHOULD only send Echo to the
same from which they were received.  Compared to HTTP, CoAP clients
are often authenticated and non-mobile, and servers can therefore
often correlate requests based on the security context, the client
credentials, or the network address.  When the Echo option increases
a server's ability to correlate requests, clients MAY discard all
pre-emptive Echo values.