draft-ietf-core-echo-request-tag-10.txt   draft-ietf-core-echo-request-tag-11.txt 
CoRE Working Group C. Amsuess CoRE Working Group C. Amsuess
Internet-Draft Internet-Draft
Updates: 7252 (if approved) J. Mattsson Updates: 7252 (if approved) J. Mattsson
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: January 14, 2021 Ericsson AB Expires: May 6, 2021 Ericsson AB
July 13, 2020 November 02, 2020
CoAP: Echo, Request-Tag, and Token Processing CoAP: Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-10 draft-ietf-core-echo-request-tag-11
Abstract Abstract
This document specifies enhancements to the Constrained Application This document specifies enhancements to the Constrained Application
Protocol (CoAP) that mitigate security issues in particular use Protocol (CoAP) that mitigate security issues in particular use
cases. The Echo option enables a CoAP server to verify the freshness 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 of a request or to force a client to demonstrate reachability at its
claimed network address. The Request-Tag option allows the CoAP claimed network address. The Request-Tag option allows the CoAP
server to match block-wise message fragments belonging to the same server to match block-wise message fragments belonging to the same
request. This document updates RFC7252 with respect to the client request. This document updates RFC7252 with respect to the client
Token processing requirements, forbidding non-secure reuse of Tokens Token processing requirements, forbidding non-secure reuse of Tokens
to ensure binding of response to request when CoAP is used with to ensure binding of response to request when CoAP is used with a
security, and with respect to amplification mitigation, where the use security protocol, and with respect to amplification mitigation,
of Echo is now recommended. where the use of Echo is now recommended.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 12 3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 12
3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 12 3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 12
3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 13 3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 13
3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 14 3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 14
3.5. Applications of the Request-Tag Option . . . . . . . . . 15 3.5. Applications of the Request-Tag Option . . . . . . . . . 15
3.5.1. Body Integrity Based on Payload Integrity . . . . . . 15 3.5.1. Body Integrity Based on Payload Integrity . . . . . . 15
3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 16 3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 16
3.5.3. Simplified Block-Wise Handling for Constrained 3.5.3. Simplified Block-Wise Handling for Constrained
Proxies . . . . . . . . . . . . . . . . . . . . . . . 17 Proxies . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Rationale for the Option Properties . . . . . . . . . . . 17 3.6. Rationale for the Option Properties . . . . . . . . . . . 17
3.7. Rationale for Introducing the Option . . . . . . . . . . 17 3.7. Rationale for Introducing the Option . . . . . . . . . . 18
3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 18 3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 18
4. Token Processing for Secure Request-Response Binding . . . . 18 4. Token Processing for Secure Request-Response Binding . . . . 18
4.1. Request-Response Binding . . . . . . . . . . . . . . . . 18 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 18
4.2. Updated Token Processing Requirements for Clients . . . . 19 4.2. Updated Token Processing Requirements for Clients . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 21
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Methods for Generating Echo Option Values . . . . . 24 Appendix A. Methods for Generating Echo Option Values . . . . . 25
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 26 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 26
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The initial Constrained Application Protocol (CoAP) suite of The initial Constrained Application Protocol (CoAP) suite of
specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed
with the assumption that security could be provided on a separate with the assumption that security could be provided on a separate
layer, in particular by using DTLS ([RFC6347]). However, for some layer, in particular by using DTLS ([RFC6347]). However, for some
use cases, additional functionality or extra processing is needed to use cases, additional functionality or extra processing is needed to
support secure CoAP operations. This document specifies security support secure CoAP operations. This document specifies security
enhancements to the Constrained Application Protocol (CoAP). enhancements to the Constrained Application Protocol (CoAP).
skipping to change at page 3, line 50 skipping to change at page 3, line 50
to the topic at hand in its first subsection. to the topic at hand in its first subsection.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Unless otherwise specified, the terms "client" and "server" refers to Like [RFC7252], this document is relying on the Representational
"CoAP client" and "CoAP server", respectively, as defined in State Transfer [REST] architecture of the Web.
Unless otherwise specified, the terms "client" and "server" refer to
"CoAP client" and "CoAP server", respectively, as defined in
[RFC7252]. The term "origin server" is used as in [RFC7252]. The [RFC7252]. The term "origin server" is used as in [RFC7252]. The
term "origin client" is used in this document to denote the client term "origin client" is used in this document to denote the client
from which a request originates; to distinguish from clients in from which a request originates; to distinguish from clients in
proxies. proxies.
The terms "payload" and "body" of a message are used as in [RFC7959]. 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 The complete interchange of a request and a response body is called a
(REST) "operation". An operation fragmented using [RFC7959] is (REST) "operation". An operation fragmented using [RFC7959] is
called a "block-wise operation". A block-wise operation which is called a "block-wise operation". A block-wise operation which is
fragmenting the request body is called a "block-wise request fragmenting the request body is called a "block-wise request
operation". A block-wise operation which is fragmenting the response operation". A block-wise operation which is fragmenting the response
body is called a "block-wise response operation". body is called a "block-wise response operation".
Two request messages are said to be "matchable" if they occur between Two request messages are said to be "matchable" if they occur between
the same endpoint pair, have the same code and the same set of the same endpoint pair, have the same code, and have the same set of
options except for elective NoCacheKey options and options involved options, with the exception that elective NoCacheKey options and
in block-wise transfer (Block1, Block2 and Request-Tag). Two options involved in block-wise transfer (Block1, Block2 and Request-
operations are said to be matchable if any of their messages are. Tag) need not be the same. Two operations are said to be matchable
if any of their messages are.
Two matchable block-wise operations are said to be "concurrent" if a Two matchable block-wise operations are said to be "concurrent" if a
block of the second request is exchanged even though the client still block of the second request is exchanged even though the client still
intends to exchange further blocks in the first operation. intends to exchange further blocks in the first operation.
(Concurrent block-wise request operations from a single endpoint are (Concurrent block-wise request operations from a single endpoint are
impossible with the options of [RFC7959] (see the last paragraphs of impossible with the options of [RFC7959] (see the last paragraphs of
Sections 2.4 and 2.5) because the second operation's block overwrites Sections 2.4 and 2.5) because the second operation's block overwrites
any state of the first exchange.). any state of the first exchange.).
The Echo and Request-Tag options are defined in this document. The Echo and Request-Tag options are defined in this document.
skipping to change at page 5, line 27 skipping to change at page 5, line 29
method, and parameters outside of CoAP such as policies. The Echo method, and parameters outside of CoAP such as policies. The Echo
option value is a challenge from the server to the client included in option value is a challenge from the server to the client included in
a CoAP response and echoed back to the server in one or more CoAP a CoAP response and echoed back to the server in one or more CoAP
requests. The Echo option provides a convention to transfer requests. The Echo option provides a convention to transfer
freshness indicators that works for all CoAP methods and response freshness indicators that works for all CoAP methods and response
codes. codes.
This mechanism is not only important in the case of actuators, or This mechanism is not only important in the case of actuators, or
other use cases where the CoAP operations require freshness of other use cases where the CoAP operations require freshness of
requests, but also in general for synchronizing state between CoAP requests, but also in general for synchronizing state between CoAP
client and server, cryptographically verify the aliveness of the client and server, cryptographically verifying the aliveness of the
client, or force a client to demonstrate reachability at its claimed client, or forcing a client to demonstrate reachability at its
network address. The same functionality can be provided by echoing claimed network address. The same functionality can be provided by
freshness indicators in CoAP payloads, but this only works for echoing freshness indicators in CoAP payloads, but this only works
methods and response codes defined to have a payload. The Echo for methods and response codes defined to have a payload. The Echo
option provides a convention to transfer freshness indicators that option provides a convention to transfer freshness indicators that
works for all methods and response codes. works for all methods and response codes.
2.2.1. Echo Option Format 2.2.1. Echo Option Format
The Echo Option is elective, safe-to-forward, not part of the cache- The Echo Option is elective, safe-to-forward, not part of the cache-
key, and not repeatable, see Figure 1, which extends Table 4 of key, and not repeatable, see Figure 1, which extends Table 4 of
[RFC7252]). [RFC7252]).
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
skipping to change at page 7, line 38 skipping to change at page 7, line 50
Upon receiving a request with the Echo option, the server determines Upon receiving a request with the Echo option, the server determines
if the request is required to be fresh. If not, the Echo option MAY if the request is required to be fresh. If not, the Echo option MAY
be ignored. If the request is required to be fresh and the server be ignored. If the request is required to be fresh and the server
cannot verify the freshness of the request in some other way, the cannot verify the freshness of the request in some other way, the
server MUST use the Echo option to verify that the request is fresh. server MUST use the Echo option to verify that the request is fresh.
If the server cannot verify that the request is fresh, the request is If the server cannot verify that the request is fresh, the request is
not processed further, and an error message MAY be sent. The error not processed further, and an error message MAY be sent. The error
message SHOULD include a new Echo option. message SHOULD include a new Echo option.
One way for the server to verify freshness is that to bind the Echo One way for the server to verify freshness is to bind the Echo value
value to a specific point in time and verify that the request is not to a specific point in time and verify that the request is not older
older than a certain threshold T. The server can verify this by than a certain threshold T. The server can verify this by checking
checking that (t1 - t0) < T, where t1 is the request receive time and that (t1 - t0) < T, where t1 is the request receive time and t0 is
t0 is the time when the Echo option value was generated. An example the time when the Echo option value was generated. An example
message flow is shown in Figure 2. message flow is shown in Figure 2.
Client Server Client Server
| | | |
+------>| Code: 0.03 (PUT) +------>| Code: 0.03 (PUT)
| PUT | Token: 0x41 | PUT | Token: 0x41
| | Uri-Path: lock | | Uri-Path: lock
| | Payload: 0 (Unlock) | | Payload: 0 (Unlock)
| | | |
|<------+ Code: 4.01 (Unauthorized) |<------+ Code: 4.01 (Unauthorized)
skipping to change at page 9, line 45 skipping to change at page 9, line 45
A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on
forwarded ones that had no Echo option or ones generated by the proxy forwarded ones that had no Echo option or ones generated by the proxy
(from cache or as an error). If it does so, it MUST remove the Echo (from cache or as an error). If it does so, it MUST remove the Echo
option it recognizes as one generated by itself on follow-up option it recognizes as one generated by itself on follow-up
requests. When it receives an Echo option in a response, it may requests. When it receives an Echo option in a response, it may
forward it to the client (and, not recognizing it as an own in future forward it to the client (and, not recognizing it as an own in future
requests, relay it in the other direction as well) or process it on requests, relay it in the other direction as well) or process it on
its own. If it does so, it MUST ensure that the client's request was its own. If it does so, it MUST ensure that the client's request was
generated (or is re-generated) after the Echo value used to send to generated (or is re-generated) after the Echo value used to send to
the server was first seen. (In most cases, this means that the proxy the server was first seen. (In most cases, this means that the proxy
needs to ask the client to repeat the request with a new Echo value). needs to ask the client to repeat the request with a new Echo value.)
The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, The CoAP server side of CoAP-to-HTTP proxies MAY request freshness,
especially if they have reason to assume that access may require it 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 (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-to-CoAP scope for this document. The CoAP client side of HTTP-to-CoAP
proxies SHOULD respond to Echo challenges themselves if they know proxies SHOULD respond to Echo challenges themselves if they know
from the recent establishing of the connection that the HTTP request from the recent establishing of the connection that the HTTP request
is fresh. Otherwise, they SHOULD respond with 503 Service is fresh. Otherwise, they SHOULD respond with 503 Service
Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive
connection. If the HTTP request arrived in Early Data, the proxy connection. If the HTTP request arrived in Early Data, the proxy
skipping to change at page 11, line 35 skipping to change at page 11, line 35
forward idempotent requests immediately to have a cached forward idempotent requests immediately to have a cached
result available when the client's Echoed request arrives. result available when the client's Echoed request arrives.
* Amplification mitigation should be used when the response * Amplification mitigation should be used when the response
would be more than three times the size of the request, would be more than three times the size of the request,
considering the complete frame on the wire as it is typically considering the complete frame on the wire as it is typically
sent across the Internet. In practice, this allows UDP data sent across the Internet. In practice, this allows UDP data
of at least 152 Bytes without further checks. of at least 152 Bytes without further checks.
* When an Echo response is sent to mitigate amplification, it * When an Echo response is sent to mitigate amplification, it
MUST be sent as a piggybacked or non-confirmable response, MUST be sent as a piggybacked or Non-confirmable response,
never as a separate one (which would cause amplification due never as a separate one (which would cause amplification due
to retransmission). to retransmission).
4. A server may want to use the request freshness provided by the 4. A server may want to use the request freshness provided by the
Echo to verify the aliveness of a client. Note that in a Echo to verify the aliveness of a client. Note that in a
deployment with hop-by-hop security and proxies, the server can deployment with hop-by-hop security and proxies, the server can
only verify aliveness of the closest proxy. only verify aliveness of the closest proxy.
3. Protecting Message Bodies using Request Tags 3. Protecting Message Bodies using Request Tags
skipping to change at page 14, line 19 skipping to change at page 14, line 19
A server receiving a Request-Tag MUST treat it as opaque and make no A server receiving a Request-Tag MUST treat it as opaque and make no
assumptions about its content or structure. assumptions about its content or structure.
Two messages carrying the same Request-Tag is a necessary but not Two messages carrying the same Request-Tag is a necessary but not
sufficient condition for being part of the same operation. For one, sufficient condition for being part of the same operation. For one,
a server may still treat them as independent messages when it sends a server may still treat them as independent messages when it sends
2.01/2.04 responses for every block. Also, a client that lost 2.01/2.04 responses for every block. Also, a client that lost
interest in an old operation but wants to start over can overwrite interest in an old operation but wants to start over can overwrite
the server's old state with a new initial (num=0) Block1 request and the server's old state with a new initial (num=0) Block1 request and
the same Request-Tag under some circumstances. Likewise, that the same Request-Tag under some circumstances. Likewise, that
results in the new message not being part of he old operation. results in the new message not being part of the old operation.
As it has always been, a server that can only serve a limited number As it has always been, a server that can only serve a limited number
of block-wise operations at the same time can delay the start of the of block-wise operations at the same time can delay the start of the
operation by replying with 5.03 (Service unavailable) and a Max-Age operation by replying with 5.03 (Service unavailable) and a Max-Age
indicating how long it expects the existing operation to go on, or it indicating how long it expects the existing operation to go on, or it
can forget about the state established with the older operation and can forget about the state established with the older operation and
respond with 4.08 (Request Entity Incomplete) to later blocks on the respond with 4.08 (Request Entity Incomplete) to later blocks on the
first operation. first operation.
3.4. Setting the Request-Tag 3.4. Setting the Request-Tag
skipping to change at page 14, line 48 skipping to change at page 14, line 48
even using the same Request-Tag value is called request tag even using the same Request-Tag value is called request tag
recycling. The absence of a Request-Tag option is viewed as a value recycling. The absence of a Request-Tag option is viewed as a value
distinct from all values with a single Request-Tag option set; distinct from all values with a single Request-Tag option set;
starting a request operation matchable to a previous operation where starting a request operation matchable to a previous operation where
neither has a Request-Tag option therefore constitutes request tag neither has a Request-Tag option therefore constitutes request tag
recycling just as well (also called "recycling the absent option"). recycling just as well (also called "recycling the absent option").
Clients that use Request-Tag for a particular purpose (like in Clients that use Request-Tag for a particular purpose (like in
Section 3.5) MUST NOT recycle a request tag unless the first Section 3.5) MUST NOT recycle a request tag unless the first
operation has concluded. What constitutes a concluded operation operation has concluded. What constitutes a concluded operation
depends on that purpose, and is defined there. depends on the purpose, and is defined accordingly; see examples in
Section 3.5.
When Block1 and Block2 are combined in an operation, the Request-Tag When Block1 and Block2 are combined in an operation, the Request-Tag
of the Block1 phase is set in the Block2 phase as well for otherwise of the Block1 phase is set in the Block2 phase as well for otherwise
the request would have a different set of options and would not be the request would have a different set of options and would not be
recognized any more. recognized any more.
Clients are encouraged to generate compact messages. This means Clients are encouraged to generate compact messages. This means
sending messages without Request-Tag options whenever possible, and sending messages without Request-Tag options whenever possible, and
using short values when the absent option can not be recycled. using short values when the absent option can not be recycled.
The Request-Tag options MAY be present in request messages that carry Note that Request-Tag options can be present in request messages that
no Block option (for example, because a Request-Tag unaware proxy carry no Block option (for example, because a Request-Tag unaware
reassembled them), and MUST be ignored in those. proxy reassembled them), and MUST be ignored in those.
The Request-Tag option MUST NOT be present in response messages. The Request-Tag option MUST NOT be present in response messages.
3.5. Applications of the Request-Tag Option 3.5. Applications of the Request-Tag Option
3.5.1. Body Integrity Based on Payload Integrity 3.5.1. Body Integrity Based on Payload Integrity
When a client fragments a request body into multiple message When a client fragments a request body into multiple message
payloads, even if the individual messages are integrity protected, it payloads, even if the individual messages are integrity protected, it
is still possible for a man-in-the-middle to maliciously replace a is still possible for an attacker to maliciously replace a later
later operation's blocks with an earlier operation's blocks (see operation's blocks with an earlier operation's blocks (see
Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the
integrity protection of each block does not extend to the operation's integrity protection of each block does not extend to the operation's
request body. request body.
In order to gain that protection, use the Request-Tag mechanism as In order to gain that protection, use the Request-Tag mechanism as
follows: follows:
o The individual exchanges MUST be integrity protected end-to-end o The individual exchanges MUST be integrity protected end-to-end
between client and server. between client and server.
o The client MUST NOT recycle a request tag in a new operation o The client MUST NOT recycle a request tag in a new operation
unless the previous operation matchable to the new one has unless the previous operation matchable to the new one has
concluded. concluded.
If any future security mechanisms allow a block-wise transfer to If any future security mechanisms allow a block-wise transfer to
continue after an endpoint's details (like the IP address) have continue after an endpoint's details (like the IP address) have
changed, then the client MUST consider messages sent to _any_ changed, then the client MUST consider messages sent to _any_
endpoint address within the new operation's security context. endpoint address using the new operation's security context.
o The client MUST NOT regard a block-wise request operation as o The client MUST NOT regard a block-wise request operation as
concluded unless all of the messages the client previously sent in concluded unless all of the messages the client previously sent in
the operation have been confirmed by the message integrity the operation have been confirmed by the message integrity
protection mechanism, or are considered invalid by the server if protection mechanism, or the client can determine that the server
replayed. would not consider the messages to be valid if they were replayed.
Typically, in OSCORE, these confirmations can result either from Typically, in OSCORE, these confirmations can result either from
the client receiving an OSCORE response message matching the the client receiving an OSCORE response message matching the
request (an empty ACK is insufficient), or because the message's request (an empty ACK is insufficient), or because the message's
sequence number is old enough to be outside the server's receive sequence number is old enough to be outside the server's receive
window. window.
In DTLS, this can only be confirmed if the request message was not In DTLS, this can only be confirmed if the request message was not
retransmitted, and was responded to. retransmitted, and was responded to.
skipping to change at page 17, line 33 skipping to change at page 17, line 33
option is sufficient is not trivial, especially when both request and option is sufficient is not trivial, especially when both request and
response body are fragmented, and out of scope for this document. response body are fragmented, and out of scope for this document.
3.6. Rationale for the Option Properties 3.6. Rationale for the Option Properties
The Request-Tag option can be elective, because to servers unaware of The Request-Tag option can be elective, because to servers unaware of
the Request-Tag option, operations with differing request tags will the Request-Tag option, operations with differing request tags will
not be matchable. not be matchable.
The Request-Tag option can be safe to forward but part of the cache The Request-Tag option can be safe to forward but part of the cache
key, because to proxies unaware of the Request-Tag option will key, because proxies unaware of the Request-Tag option will consider
consider operations with differing request tags unmatchable but can operations with differing request tags unmatchable but can still
still forward them. forward them.
The Request-Tag option is repeatable because this easily allows The Request-Tag option is repeatable because this easily allows
stateless proxies to "chain" their origin address. They can perform several cascaded stateless proxies to each put in an origin address.
the steps of Section 3.5.3 without the need to create an option value They can perform the steps of Section 3.5.3 without the need to
that is the concatenation of the received option and their own value, create an option value that is the concatenation of the received
and can simply add a new Request-Tag option unconditionally. option and their own value, and can simply add a new Request-Tag
option unconditionally.
In draft versions of this document, the Request-Tag option used to be In draft versions of this document, the Request-Tag option used to be
critical and unsafe to forward. That design was based on an critical and unsafe to forward. That design was based on an
erroneous understanding of which blocks could be composed according erroneous understanding of which blocks could be composed according
to [RFC7959]. to [RFC7959].
3.7. Rationale for Introducing the Option 3.7. Rationale for Introducing the Option
An alternative that was considered to the Request-Tag option for An alternative that was considered to the Request-Tag option for
coping with the problem of fragmented message body integrity coping with the problem of fragmented message body integrity
skipping to change at page 18, line 15 skipping to change at page 18, line 21
numbers. numbers.
That approach would have been difficult to roll out reliably on DTLS That approach would have been difficult to roll out reliably on DTLS
where many implementations do not expose sequence numbers, and would where many implementations do not expose sequence numbers, and would
still not prevent attacks like in [I-D.mattsson-core-coap-actuators] still not prevent attacks like in [I-D.mattsson-core-coap-actuators]
Section 2.5.2. Section 2.5.2.
3.8. Block2 / ETag Processing 3.8. Block2 / ETag Processing
The same security properties as in Section 3.5.1 can be obtained for The same security properties as in Section 3.5.1 can be obtained for
blockwise response operations. The threat model here is not an block-wise response operations. The threat model here does not
attacker (because the response is made sure to belong to the current depend on an attacker: a client can construct a wrong representation
request by the security layer), but blocks in the client's cache. by assembling it from blocks from different resource states. That
can happen when a resource is modified during a transfer, or when
some blocks are still valid in the client's cache.
Rules stating that response body reassembly is conditional on Rules stating that response body reassembly is conditional on
matching ETag values are already in place from Section 2.4 of matching ETag values are already in place from Section 2.4 of
[RFC7959]. [RFC7959].
To gain equivalent protection to Section 3.5.1, a server MUST use the To gain equivalent protection to Section 3.5.1, a server MUST use the
Block2 option in conjunction with the ETag option ([RFC7252], Block2 option in conjunction with the ETag option ([RFC7252],
Section 5.10.6), and MUST NOT use the same ETag value for different Section 5.10.6), and MUST NOT use the same ETag value for different
representations of a resource. representations of a resource.
4. Token Processing for Secure Request-Response Binding 4. Token Processing for Secure Request-Response Binding
4.1. Request-Response Binding 4.1. Request-Response Binding
A fundamental requirement of secure REST operations is that the A fundamental requirement of secure REST operations is that the
client can bind a response to a particular request. If this is not client can bind a response to a particular request. If this is not
ensured, a client may erroneously associate the wrong response to a ensured, a client may erroneously associate the wrong response to a
request. The wrong response may be an old response for the same request. The wrong response may be an old response for the same
resource or for a completely different resource (see e.g. resource or a response for a completely different resource (see e.g.
Section 2.3 of [I-D.mattsson-core-coap-actuators]). For example, a Section 2.3 of [I-D.mattsson-core-coap-actuators]). For example, a
request for the alarm status "GET /status" may be associated to a request for the alarm status "GET /status" may be associated to a
prior response "on", instead of the correct response "off". prior response "on", instead of the correct response "off".
In HTTPS, this type of binding is always assured by the ordered and In HTTPS, this type of binding is always assured by the ordered and
reliable delivery as well as mandating that the server sends reliable delivery as well as mandating that the server sends
responses in the same order that the requests were received. The responses in the same order that the requests were received. The
same is not true for CoAP where the server (or an attacker) can same is not true for CoAP where the server (or an attacker) can
return responses in any order and where there can be any number of return responses in any order and where there can be any number of
responses to a request (see e.g. [RFC7641]). In CoAP, concurrent responses to a request (see e.g. [RFC7641]). In CoAP, concurrent
skipping to change at page 19, line 16 skipping to change at page 19, line 22
value and does not give stricter guidelines than that the Tokens value and does not give stricter guidelines than that the Tokens
currently "in use" SHOULD (not SHALL) be unique. If used with a currently "in use" SHOULD (not SHALL) be unique. If used with a
security protocol not providing bindings between requests and security protocol not providing bindings between requests and
responses (e.g. DTLS and TLS) Token reuse may result in situations responses (e.g. DTLS and TLS) Token reuse may result in situations
where a client matches a response to the wrong request. Note that where a client matches a response to the wrong request. Note that
mismatches can also happen for other reasons than a malicious mismatches can also happen for other reasons than a malicious
attacker, e.g. delayed delivery or a server sending notifications to attacker, e.g. delayed delivery or a server sending notifications to
an uninterested client. an uninterested client.
A straightforward mitigation is to mandate clients to not reuse A straightforward mitigation is to mandate clients to not reuse
Tokens until the traffic keys have been replaced. One easy way to Tokens until the traffic keys have been replaced. The following
accomplish this is to implement the Token as a counter starting at section formalizes that.
zero for each new or rekeyed secure connection.
4.2. Updated Token Processing Requirements for Clients 4.2. Updated Token Processing Requirements for Clients
As described in Section 4.1, the client must be able to verify that a As described in Section 4.1, the client must be able to verify that a
response corresponds to a particular request. This section updates response corresponds to a particular request. This section updates
the Token processing requirements for clients in [RFC7252] to always the Token processing requirements for clients in [RFC7252] to always
assure a cryptographically secure binding of responses to requests assure a cryptographically secure binding of responses to requests
for secure REST operations like "coaps". The Token processing for for secure REST operations like "coaps". The Token processing for
servers is not updated. Token processing in Section 5.3.1 of servers is not updated. Token processing in Section 5.3.1 of
[RFC7252] is updated by adding the following text: [RFC7252] is updated by adding the following text:
skipping to change at page 19, line 34 skipping to change at page 19, line 39
the Token processing requirements for clients in [RFC7252] to always the Token processing requirements for clients in [RFC7252] to always
assure a cryptographically secure binding of responses to requests assure a cryptographically secure binding of responses to requests
for secure REST operations like "coaps". The Token processing for for secure REST operations like "coaps". The Token processing for
servers is not updated. Token processing in Section 5.3.1 of servers is not updated. Token processing in Section 5.3.1 of
[RFC7252] is updated by adding the following text: [RFC7252] is updated by adding the following text:
When CoAP is used with a security protocol not providing bindings When CoAP is used with a security protocol not providing bindings
between requests and responses, the Tokens have cryptographic between requests and responses, the Tokens have cryptographic
importance. The client MUST make sure that Tokens are not used in a importance. The client MUST make sure that Tokens are not used in a
way so that responses risk being associated with the wrong request. way so that responses risk being associated with the wrong request.
One easy way to accomplish this is to implement the Token (or part of One easy way to accomplish this is to implement the Token (or part of
the Token) as a sequence number starting at zero for each new or the Token) as a sequence number starting at zero for each new or
rekeyed secure connection, this approach SHOULD be followed. rekeyed secure connection. This approach SHOULD be followed.
5. Security Considerations 5. Security Considerations
The availability of a secure pseudorandom number generator and truly The freshness assertion of the Echo option comes from the client
random seeds are essential for the security of the Echo option reproducing the same value of the Echo option in a request as in a
(except when using counting Echo values). If no true random number previous response. If the Echo value is a large random number then
generator is available, a truly random seed must be provided from an there is a high probability that the request is generated after
external source. As each pseudoranom number must only be used once, having seen the response. If the Echo value of the response can be
an implementation need to get a new truly random seed after reboot, guessed, e.g. if based on a small random number or a counter (see
or continously store state in nonvolatile memory, see ([RFC8613], Appendix A), then it is possible to compose a request with the right
Appendix B.1.1) for issues and solution approaches for writing to Echo value ahead of time. However, this may not be an issue if the
nonvolatile memory. communication is integrity protected against third parties and the
client is trusted not misusing this capability. Echo values MUST be
set by the CoAP server such that the risk associated with unintended
reuse can be managed.
If uniqueness of the Echo value is based on randomness, then 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 pseudorandom
number must only be used once, an implementation needs to get a new
truly random seed after reboot, or continuously store state in
nonvolatile memory. See ([RFC8613], Appendix B.1.1) for issues and
solution approaches for writing to nonvolatile memory.
A single active Echo value with 64 (pseudo-)random bits gives the 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. same theoretical security level as a 64-bit MAC (as used in e.g.
AES_128_CCM_8). Unless a counting Echo value is used, the Echo AES_128_CCM_8). If a random unique Echo value is intended, the Echo
option value MUST contain 32 (pseudo-)random bits that are not option value SHOULD contain 64 (pseudo-)random bits that are not
predictable for any other party than the server, and SHOULD contain predictable for any other party than the server. A server MAY use
64 (pseudo-)random bits. A server MAY use different security levels different security levels for different uses cases (client aliveness,
for different uses cases (client aliveness, request freshness, state request freshness, state synchronization, network address
synchronization, network address reachability, etc.). reachability, etc.).
The security provided by the Echo and Request-Tag options depends on The security provided by the Echo and Request-Tag options depends on
the security protocol used. CoAP and HTTP proxies require (D)TLS to the security protocol used. CoAP and HTTP proxies require (D)TLS to
be terminated at the proxies. The proxies are therefore able to be terminated at the proxies. The proxies are therefore able to
manipulate, inject, delete, or reorder options or packets. The manipulate, inject, delete, or reorder options or packets. The
security claims in such architectures only hold under the assumption security claims in such architectures only hold under the assumption
that all intermediaries are fully trusted and have not been that all intermediaries are fully trusted and have not been
compromised. compromised.
Counting Echo values can only be used to show freshness relative to Counter Echo values can only be used to show freshness relative to
numbered events, and are the legitimate case for Echo values shorter numbered events, and are the legitimate case for Echo values shorter
than four bytes, which are not necessarily secret. They MUST only be than four bytes, which are not necessarily secret. They MUST NOT be
used when the request Echo values are integrity protected. used unless the request Echo values are integrity protected as per
Section 2.3.
Servers SHOULD use a monotonic clock to generate timestamps and Servers SHOULD use a monotonic clock to generate timestamps and
compute round-trip times. Use of non-monotonic clocks is not secure compute round-trip times. Use of non-monotonic clocks is not secure
as the server will accept expired Echo option values if the clock is as the server will accept expired Echo option values if the clock is
moved backward. The server will also reject fresh Echo option values moved backward. The server will also reject fresh Echo option values
if the clock is moved forward. Non-monotonic clocks MAY be used as if the clock is moved forward. Non-monotonic clocks MAY be used as
long as they have deviations that are acceptable given the freshness long as they have deviations that are acceptable given the freshness
requirements. If the deviations from a monotonic clock are known, it requirements. If the deviations from a monotonic clock are known, it
may be possible to adjust the threshold accordingly. may be possible to adjust the threshold accordingly.
An attacker may be able to affect the server's system time in various 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 ways such as setting up a fake NTP server or broadcasting false time
signals to radio-controlled clocks. signals to radio-controlled clocks.
Servers MAY use the time since reboot measured in some unit of time. For the purpose of generating timestamps for Echo a server MAY set a
Servers MAY reset the timer at certain times and MAY generate a timer at reboot and use the time since reboot, in a unit such that
random offset applied to all timestamps. When resetting the timer, different requests arrive at different times. Servers MAY
the server MUST reject all Echo values that was created before the intermittently reset the timer and MAY generate a random offset
reset. applied to all timestamps. When resetting the timer, the server MUST
reject all Echo values that were created before the reset.
Servers that use the List of Cached Random Values and Timestamps Servers that use the List of Cached Random Values and Timestamps
method described in Appendix A may be vulnerable to resource method described in Appendix A may be vulnerable to resource
exhaustion attacks. One way to minimize state is to use the exhaustion attacks. One way to minimize state is to use the
Integrity Protected Timestamp method described in Appendix A. Integrity Protected Timestamp method described in Appendix A.
5.1. Token reuse 5.1. Token reuse
Reusing Tokens in a way so that responses are guaranteed to not be 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 associated with the wrong request is not trivial: The server may
may block, delay, and reorder messages, requests may be sent to process requests in any order, and send multiple responses to the
several servers, and servers may process requests in any order and same request. An attacker may block, delay, and reorder messages.
send many responses to the same request. The use of a sequence The use of a sequence number is therefore recommended when CoAP is
number is therefore recommended when CoAP is used with a security used with a security protocol that does not provide bindings between
protocol that does not provide bindings between requests and requests and responses such as DTLS or TLS.
responses such as DTLS or TLS.
For a generic response to a confirmable request over DTLS, binding For a generic response to a Confirmable request over DTLS, binding
can only be claimed without out-of-band knowledge if can only be claimed without out-of-band knowledge if
o the original request was never retransmitted, o the original request was never retransmitted,
o the response was piggybacked in an Acknowledgement message (as a o the response was piggybacked in an Acknowledgement message (as a
confirmable or non-confirmable response may have been transmitted Confirmable or Non-confirmable response may have been transmitted
multiple times), and multiple times), and
o if observation was used, the same holds for the registration, all o if observation was used, the same holds for the registration, all
re-registrations, and the cancellation. re-registrations, and the cancellation.
(In addition, for observations, any responses using that Token and a (In addition, for observations, any responses using that Token and a
DTLS sequence number earlier than the cancellation Acknowledgement DTLS sequence number earlier than the cancellation Acknowledgement
message need to be discarded. This is typically not supported in message need to be discarded. This is typically not supported in
DTLS implementations.) DTLS implementations.)
In some setups, Tokens can be reused without the above constraints, In some setups, Tokens can be reused without the above constraints,
as a different component in the setup provides the associations: as a different component in the setup provides the associations:
o In CoAP over TLS, retransmissions are not handled by the CoAP o In CoAP over TLS, retransmissions are not handled by the CoAP
layer and the replay window size is always exactly 1. When a layer and behaves like a replay window size of 1. When a client
client is sending TLS protected requests without Observe to a is sending TLS-protected requests without Observe to a single
single server, the client can reuse a Token as soon as the server, the client can reuse a Token as soon as the previous
previous response with that Token has been received. response with that Token has been received.
o Requests whose responses are cryptographically bound to the o Requests whose responses are cryptographically bound to the
requests (like in OSCORE) can reuse Tokens indefinitely. requests (like in OSCORE) can reuse Tokens indefinitely.
In all other cases, a sequence number approach is RECOMMENDED as per In all other cases, a sequence number approach is RECOMMENDED as per
Section 4. Section 4.
Tokens that cannot be reused need to be handled appropriately. This Tokens that cannot be reused need to be handled appropriately. This
could be solved by increasing the Token as soon as the currently used could be solved by increasing the Token as soon as the currently used
Token cannot be reused, or by keeping a list of all blacklisted Token cannot be reused, or by keeping a list of all blacklisted
Tokens. Tokens.
When the Token (or part of the Token) contains a sequence number, the 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 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 any collisions. This is especially true when the Token contains more
information than just the sequence number, e.g. serialized state as information than just the sequence number, e.g. serialized state as
in [I-D.ietf-core-stateless]. in [I-D.ietf-core-stateless].
6. Privacy Considerations 6. Privacy Considerations
Implementations SHOULD NOT put any privacy sensitive information in Implementations SHOULD NOT put any privacy-sensitive information in
the Echo or Request-Tag option values. Unencrypted timestamps MAY the Echo or Request-Tag option values. Unencrypted timestamps could
reveal information about the server such as location or time since reveal information about the server such as location or time since
reboot, or that the server will accept expired certificates. reboot, or that the server will accept expired certificates.
Timestamps MAY be used if Echo is encrypted between the client and Timestamps MAY be used if Echo is encrypted between the client and
the server, e.g. in the case of DTLS without proxies or when using the server, e.g. in the case of DTLS without proxies or when using
OSCORE with an Inner Echo option. OSCORE with an Inner Echo option.
Like HTTP cookies, the Echo option could potentially be abused as a Like HTTP cookies, the Echo option could potentially be abused as a
tracking mechanism to link to different requests to the same client. tracking mechanism that identifies a client across requests. This is
This is especially true for pre-emptive Echo values. Servers MUST especially true for preemptive Echo values. Servers MUST NOT use the
NOT use the Echo option to correlate requests for other purposes than Echo option to correlate requests for other purposes than freshness
freshness and reachability. Clients only send Echo to the same and reachability. Clients only send Echo values to the same server
server from which they were received. Compared to HTTP, CoAP clients from which the values were received. Compared to HTTP, CoAP clients
are often authenticated and non-mobile, and servers can therefore are often authenticated and non-mobile, and servers can therefore
often correlate requests based on the security context, the client often correlate requests based on the security context, the client
credentials, or the network address. Especially when the Echo option credentials, or the network address. Especially when the Echo option
increases a server's ability to correlate requests, clients MAY increases a server's ability to correlate requests, clients MAY
discard all pre-emptive Echo values. discard all preemptive Echo values.
7. IANA Considerations 7. IANA Considerations
IANA is requested to add the following option numbers to the "CoAP IANA is requested to add the following option numbers to the "CoAP
Option Numbers" registry defined by [RFC7252]: Option Numbers" registry defined by [RFC7252]:
[ [
The editor is asked to suggest the numbers after TBD, as those The editor is asked to suggest the numbers after TBD, as those
satisfy the construction requirements set out in RFC7252: Echo is satisfy the construction requirements set out in RFC7252: Echo is
skipping to change at page 23, line 23 skipping to change at page 23, line 45
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-09 (work in progress), draft-ietf-core-oscore-groupcomm-09 (work in progress),
June 2020. June 2020.
[I-D.ietf-core-stateless] [I-D.ietf-core-stateless]
Hartke, K., "Extended Tokens and Stateless Clients in the Hartke, K., "Extended Tokens and Stateless Clients in the
Constrained Application Protocol (CoAP)", draft-ietf-core- Constrained Application Protocol (CoAP)", draft-ietf-core-
stateless-06 (work in progress), April 2020. stateless-06 (work in progress), April 2020.
[I-D.mattsson-core-coap-actuators] [I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., Palombini, F., Mattsson, J., Fornehed, J., Selander, G., Palombini, F.,
and C. Amsuess, "Controlling Actuators with CoAP", draft- and C. Amsuess, "Controlling Actuators with CoAP", draft-
mattsson-core-coap-actuators-06 (work in progress), mattsson-core-coap-actuators-06 (work in progress),
September 2018. September 2018.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [REST] Fielding, R., "Architectural Styles and the Design of
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Network-based Software Architectures", 2000,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. <https://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390, the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014, DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>. <https://www.rfc-editor.org/info/rfc7390>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
skipping to change at page 24, line 39 skipping to change at page 25, line 19
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
Appendix A. Methods for Generating Echo Option Values Appendix A. Methods for Generating Echo Option Values
The content and structure of the Echo option value are implementation The content and structure of the Echo option value are implementation
specific and determined by the server. Two simple mechanisms for specific and determined by the server. Two simple mechanisms for
time-based freshness are outlined in this section, the first is time-based freshness and one for event-based freshness are outlined
RECOMMENDED in general, and the second is RECOMMENDED in case the in this section, the first is RECOMMENDED in general, and the second
Echo option is encrypted between the client and the server. is RECOMMENDED in case the Echo option is encrypted between the
client and the server.
Different mechanisms have different tradeoffs between the size of the Different mechanisms have different tradeoffs between the size of the
Echo option value, the amount of server state, the amount of Echo option value, the amount of server state, the amount of
computation, and the security properties offered. A server MAY use computation, and the security properties offered. A server MAY use
different methods and security levels for different uses cases different methods and security levels for different uses cases
(client aliveness, request freshness, state synchronization, network (client aliveness, request freshness, state synchronization, network
address reachability, etc.). address reachability, etc.).
1. List of Cached Random Values and Timestamps. The Echo option 1. List of Cached Random Values and Timestamps. The Echo option
value is a (pseudo-)random byte string. The server caches a list value is a (pseudo-)random byte string called r. The server caches a
containing the random byte strings and their transmission times. list containing the random byte strings and their transmission times.
Assuming 72-bit random values and 32-bit timestamps, the size of the Assuming 72-bit random values and 32-bit timestamps, the size of the
Echo option value is 9 bytes and the amount of server state is 13n Echo option value is 9 bytes and the amount of server state is 13n
bytes, where n is the number of active Echo Option values. The bytes, where n is the number of active Echo Option values. The
security against an attacker guessing echo values is given by s = bit security against an attacker guessing echo values is given by s = bit
length of r - log2(n). The length of r and the maximum allowed n length of r - log2(n). The length of r and the maximum allowed n
should be set so that the security level is harmonized with other should be set so that the security level is harmonized with other
parts of the deployment, e.g., s >= 64. If the server loses time parts of the deployment, e.g., s >= 64. If the server loses time
continuity, e.g. due to reboot, the entries in the old list MUST be continuity, e.g. due to reboot, the entries in the old list MUST be
deleted. deleted.
skipping to change at page 25, line 40 skipping to change at page 26, line 14
resolution and range. A 32-bit timestamp can e.g. give a resolution resolution and range. A 32-bit timestamp can e.g. give a resolution
of 1 second with a range of 136 years. The (pseudo-)random secret of 1 second with a range of 136 years. The (pseudo-)random secret
key is generated by the server and not shared with any other party. key is generated by the server and not shared with any other party.
The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit
timestamp and a 64-bit MAC, the size of the Echo option value is 12 timestamp and a 64-bit MAC, the size of the Echo option value is 12
bytes and the Server state is small and constant. The security bytes and the Server state is small and constant. The security
against an attacker guessing echo values is given by the MAC length. against an attacker guessing echo values is given by the MAC length.
If the server loses time continuity, e.g. due to reboot, the old key If the server loses time continuity, e.g. due to reboot, the old key
MUST be deleted and replaced by a new random secret key. Note that MUST be deleted and replaced by a new random secret key. Note that
the privacy considerations in Section 6 may apply to the timestamp. the privacy considerations in Section 6 may apply to the timestamp.
A server MAY want to encrypt its timestamps, and, depending on the Therefore, it might be important to encrypt it. Depending on the
choice of encryption algorithms, this may require a nonce to be choice of encryption algorithms, this may require a nonce to be
included in the Echo option value. included in the Echo option value.
Echo option value: timestamp t0, MAC(k, t0) Echo option value: timestamp t0, MAC(k, t0)
Server State: secret key k Server State: secret key k
3. Persistent Counter. This is an event-based freshness method
usable for state synchronization (for example after volatile state
has been lost), and cannot be used for client aliveness. It requires
that the client can be trusted to not spuriously produce Echo values.
The Echo option value is a simple counter without integrity
protection of its own, serialized in uint format. The counter is
incremented in a persistent way every time the state that needs to be
synchronized is changed (in the aforementioned example: when a reboot
indicates that volatile state may have been lost). An example of how
such a persistent counter can be implemented efficiently is the
OSCORE server Sender Sequence Number mechanism described in
Appendix B.1.1 of [RFC8613].
Echo option value: counter
Server State: counter
Other mechanisms complying with the security and privacy Other mechanisms complying with the security and privacy
considerations may be used. The use of encrypted timestamps in the considerations may be used. The use of encrypted timestamps in the
Echo option increases security, but typically requires an IV to be Echo option increases security, but typically requires an IV to be
included in the Echo option value, which adds overhead and makes the included in the Echo option value, which adds overhead and makes the
specification of such a mechanism slightly more complicated than the specification of such a mechanism slightly more complicated than the
two mechanisms specified here. two time-based mechanisms specified here.
Appendix B. Request-Tag Message Size Impact Appendix B. Request-Tag Message Size Impact
In absence of concurrent operations, the Request-Tag mechanism for In absence of concurrent operations, the Request-Tag mechanism for
body integrity (Section 3.5.1) incurs no overhead if no messages are body integrity (Section 3.5.1) incurs no overhead if no messages are
lost (more precisely: in OSCORE, if no operations are aborted due to lost (more precisely: in OSCORE, if no operations are aborted due to
repeated transmission failure; in DTLS, if no packages are lost), or repeated transmission failure; in DTLS, if no packets are lost), or
when block-wise request operations happen rarely (in OSCORE, if there when block-wise request operations happen rarely (in OSCORE, if there
is always only one request block-wise operation in the replay is always only one request block-wise operation in the replay
window). window).
In those situations, no message has any Request-Tag option set, and In those situations, no message has any Request-Tag option set, and
that can be recycled indefinitely. that can be recycled indefinitely.
When the absence of a Request-Tag option can not be recycled any more When the absence of a Request-Tag option can not be recycled any more
within a security context, the messages with a present but empty within a security context, the messages with a present but empty
Request-Tag option can be used (1 Byte overhead), and when that is Request-Tag option can be used (1 Byte overhead), and when that is
skipping to change at page 26, line 39 skipping to change at page 27, line 31
o In OSCORE, the sequence number can be artificially increased so o In OSCORE, the sequence number can be artificially increased so
that all lost messages are outside of the replay window by the that all lost messages are outside of the replay window by the
time the first request of the new operation gets processed, and time the first request of the new operation gets processed, and
all earlier operations can therefore be regarded as concluded. all earlier operations can therefore be regarded as concluded.
Appendix C. Change Log Appendix C. Change Log
[ The editor is asked to remove this section before publication. ] [ The editor is asked to remove this section before publication. ]
o Changes since draft-ietf-core-echo-request-tag-10 (Barry's
comments)
* Align terminology on attacker
* A number of clarifications and editorial fixes
* Promote DTLS and OSCORE to normative references
* Add counter-based version to the Methods for Generating Echo
Option Values appendix
* Use 64-bit randomness recommendation throughout (but keep it as
SHOULD so applications with strict requirements can reduce if
if really needed)
* Speling and Capitalization
o Changes since draft-ietf-core-echo-request-tag-09: o Changes since draft-ietf-core-echo-request-tag-09:
* Allow intermediaries to do Echo processing, provided they ask * Allow intermediaries to do Echo processing, provided they ask
at least as much freshness as they forward at least as much freshness as they forward
* Emphasize that clients can forget Echo to further discourage * Emphasize that clients can forget Echo to further discourage
abuse as cookies abuse as cookies
* Emphasize that RESTful application design can avoid the need * Emphasize that RESTful application design can avoid the need
for a Request-Tag for a Request-Tag
 End of changes. 51 change blocks. 
117 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/