draft-ietf-core-echo-request-tag-08.txt   draft-ietf-core-echo-request-tag-09.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: May 7, 2020 Ericsson AB Expires: September 10, 2020 Ericsson AB
November 04, 2019 March 09, 2020
CoAP: Echo, Request-Tag, and Token Processing CoAP: Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-08 draft-ietf-core-echo-request-tag-09
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; it is now the recommeded way to mitigate
server to match block-wise message fragments belonging to the same amplification attacks. The Request-Tag option allows the CoAP server
request. The update to the client Token processing requirements of to match block-wise message fragments belonging to the same request.
RFC 7252 forbids non-secure reuse of Tokens to ensure binding of The update to the client Token processing requirements of RFC 7252
responses to requests when CoAP is used with security. forbids non-secure reuse of Tokens to ensure binding of responses to
requests when CoAP is used with security.
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 May 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 33
3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 11 3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . 16 Proxies . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Rationale for the Option Properties . . . . . . . . . . . 16 3.6. Rationale for the Option Properties . . . . . . . . . . . 17
3.7. Rationale for Introducing the Option . . . . . . . . . . 17 3.7. Rationale for Introducing the Option . . . . . . . . . . 17
3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 17 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 . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Methods for Generating Echo Option Values . . . . . 23 Appendix A. Methods for Generating Echo Option Values . . . . . 24
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 25 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 25
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 28 skipping to change at page 3, line 28
demonstrate reachability at its claimed network address. The demonstrate reachability at its claimed network address. The
Request-Tag option allows the CoAP server to match message fragments Request-Tag option allows the CoAP server to match message fragments
belonging to the same request, fragmented using the CoAP block-wise belonging to the same request, fragmented using the CoAP block-wise
Transfer mechanism, which mitigates attacks and enables concurrent Transfer mechanism, which mitigates attacks and enables concurrent
block-wise operations. These options in themselves do not replace block-wise operations. These options in themselves do not replace
the need for a security protocol; they specify the format and the need for a security protocol; they specify the format and
processing of data which, when integrity protected using e.g. DTLS processing of data which, when integrity protected using e.g. DTLS
([RFC6347]), TLS ([RFC8446]), or OSCORE ([RFC8613]), provide the ([RFC6347]), TLS ([RFC8446]), or OSCORE ([RFC8613]), provide the
additional security features. additional security features.
This document updates [RFC7252] with a recommendation that servers
use the Echo option to mitigate amplification attacks.
The document also updates the Token processing requirements for The document also updates the Token processing requirements for
clients specified in [RFC7252]. The updated processing forbids non- clients specified in [RFC7252]. The updated processing forbids non-
secure reuse of Tokens to ensure binding of responses to requests secure reuse of Tokens to ensure binding of responses to requests
when CoAP is used with security, thus mitigating error cases and when CoAP is used with security, thus mitigating error cases and
attacks where the client may erroneously associate the wrong response attacks where the client may erroneously associate the wrong response
to a request. to a request.
Each of the following sections provides a more detailed introduction Each of the following sections provides a more detailed introduction
to the topic at hand in its first subsection. to the topic at hand in its first subsection.
skipping to change at page 5, line 36 skipping to change at page 5, line 38
methods and response codes defined to have a payload. The Echo 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]).
+-----+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
| No. | C | U | N | R | Name | Format | Len. | Default | E | U | | No. | C | U | N | R | Name | Format | Len. | Default | E | U |
+-----+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
| TBD | | | x | | Echo | opaque | 4-40 | (none) | x | x | | TBD248 | | | x | | Echo | opaque | 1-40 | (none) | x | x |
+-----+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable,
E = Encrypt and Integrity Protect (when using OSCORE) E = Encrypt and Integrity Protect (when using OSCORE)
Figure 1: Echo Option Summary Figure 1: Echo Option Summary
The Echo option value is generated by a server, and its content and The Echo option value is generated by a server, and its content and
structure are implementation specific. Different methods for structure are implementation specific. Different methods for
generating Echo option values are outlined in Appendix A. Clients generating Echo option values are outlined in Appendix A. Clients
and intermediaries MUST treat an Echo option value as opaque and make and intermediaries MUST treat an Echo option value as opaque and make
no assumptions about its content or structure. no assumptions about its content or structure.
When receiving an Echo option in a request, the server MUST be able When receiving an Echo option in a request, the server MUST be able
skipping to change at page 11, line 8 skipping to change at page 11, line 8
response to a multicast request. The client receiving the response to a multicast request. The client receiving the
response with the Echo option includes the Echo option with response with the Echo option includes the Echo option with
the same value in a request, either in a unicast request to the same value in a request, either in a unicast request to
the responding server, or in a subsequent group request. In the responding server, or in a subsequent group request. In
the latter case, the Echo option will be ignored except by the the latter case, the Echo option will be ignored except by the
responding server. responding server.
3. A server that sends large responses to unauthenticated peers 3. A server that sends large responses to unauthenticated peers
SHOULD mitigate amplification attacks such as described in SHOULD mitigate amplification attacks such as described in
Section 11.3 of [RFC7252] (where an attacker would put a victim's Section 11.3 of [RFC7252] (where an attacker would put a victim's
address in the source address of a CoAP request). For this address in the source address of a CoAP request). The
purpose, a server MAY ask a client to Echo its request to verify RECOMMENDED way to do this is to ask a client to Echo its request
its source address. This needs to be done only once per peer and to verify its source address. This needs to be done only once
limits the range of potential victims from the general Internet per peer and limits the range of potential victims from the
to endpoints that have been previously in contact with the general Internet to endpoints that have been previously in
server. For this application, the Echo option can be used in contact with the server. For this application, the Echo option
messages that are not integrity protected, for example during can be used in messages that are not integrity protected, for
discovery. example during discovery.
* In the presence of a proxy, a server will not be able to * In the presence of a proxy, a server will not be able to
distinguish different origin client endpoints. Following from distinguish different origin client endpoints. Following from
the recommendation above, a proxy that sends large responses the recommendation above, a proxy that sends large responses
to unauthenticated peers SHOULD mitigate amplification to unauthenticated peers SHOULD mitigate amplification
attacks. The proxy MAY use Echo to verify origin reachability attacks. The proxy SHOULD use Echo to verify origin
as described in Section 2.3. The proxy MAY forward idempotent reachability as described in Section 2.3. The proxy MAY
requests immediately to have a cached result available when forward idempotent requests immediately to have a cached
the client's Echoed request arrives. result available when the client's Echoed request arrives.
* Amplification mitigation should be used when the the response
would be more than three times the size of the request,
considering the complete frame on the wire as it is typically
sent across the Internet. In practice, this allows UDP data
of at least 152 Bytes without further checks.
* When an Echo response is sent to mitigate amplification, it
MUST be sent as a piggybacked or non-confirmable response,
never as a separate one (which would cause amplification due
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
3.1. Fragmented Message Body Integrity 3.1. Fragmented Message Body Integrity
skipping to change at page 12, line 39 skipping to change at page 13, line 5
In essence, it is an implementation of the "proxy-safe elective In essence, it is an implementation of the "proxy-safe elective
option" used just to "vary the cache key" as suggested in [RFC7959] option" used just to "vary the cache key" as suggested in [RFC7959]
Section 2.4. Section 2.4.
3.2.1. Request-Tag Option Format 3.2.1. Request-Tag Option Format
The Request-Tag option is not critical, is safe to forward, The Request-Tag option is not critical, is safe to forward,
repeatable, and part of the cache key, see Figure 4, which extends repeatable, and part of the cache key, see Figure 4, which extends
Table 4 of [RFC7252]). Table 4 of [RFC7252]).
+-----+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
| No. | C | U | N | R | Name | Format | Len. | Default | E | U | | No. | C | U | N | R | Name | Format | Len. | Default | E | U |
+-----+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
| TBD | | | | x | Request-Tag | opaque | 0-8 | (none) | x | x | | TBD292 | | | | x | Request-Tag | opaque | 0-8 | (none) | x | x |
+-----+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable,
E = Encrypt and Integrity Protect (when using OSCORE) E = Encrypt and Integrity Protect (when using OSCORE)
Figure 4: Request-Tag Option Summary Figure 4: Request-Tag Option Summary
Request-Tag, like the block options, is both a class E and a class U 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]): 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 The Request-Tag MAY be an Inner or Outer option. It influences the
Inner or Outer block operation, respectively. The Inner and Outer Inner or Outer block operation, respectively. The Inner and Outer
values are therefore independent of each other. The Inner option is values are therefore independent of each other. The Inner option is
encrypted and integrity protected between client and server, and encrypted and integrity protected between client and server, and
provides message body identification in case of end-to-end provides message body identification in case of end-to-end
fragmentation of requests. The Outer option is visible to proxies fragmentation of requests. The Outer option is visible to proxies
and labels message bodies in case of hop-by-hop fragmentation of and labels message bodies in case of hop-by-hop fragmentation of
requests. requests.
The Request-Tag option is only used in the request messages of block- The Request-Tag option is only used in the request messages of block-
skipping to change at page 14, line 19 skipping to change at page 14, line 32
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
For each separate block-wise request operation, the client can choose For each separate block-wise request operation, the client can choose
a Request-Tag value, or choose not to set a Request-Tag. It needs to a Request-Tag value, or choose not to set a Request-Tag. It needs to
be set to the same value (or unset) in all messages belonging to the be set to the same value (or unset) in all messages belonging to the
same operation, as otherwise they are treated as separate operations same operation, as otherwise they are treated as separate operations
by the server. by the server.
Starting a request operation matchable to a previous operation and Starting a request operation matchable to a previous operation and
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
skipping to change at page 14, line 47 skipping to change at page 15, line 12
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 The Request-Tag options MAY be present in request messages that carry
a Block2 option even if those messages are not part of a blockwise no Block option (for example, because a Request-Tag unaware proxy
request operation (this is to allow the operation described in reassembled them), and MUST be ignored in those.
Section 3.5.3). The Request-Tag option MUST NOT be present in
response messages, and MUST NOT be present if neither the Block1 nor The Request-Tag option MUST NOT be present in response messages.
the Block2 option is present.
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 a man-in-the-middle to maliciously replace a
later operation's blocks with an earlier operation's blocks (see later 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
skipping to change at page 16, line 39 skipping to change at page 17, line 5
o Otherwise, it can start the new operation without setting the o Otherwise, it can start the new operation without setting the
Request-Tag option on it. Request-Tag option on it.
3.5.3. Simplified Block-Wise Handling for Constrained Proxies 3.5.3. Simplified Block-Wise Handling for Constrained Proxies
The Block options were defined to be unsafe to forward because a The Block options were defined to be unsafe to forward because a
proxy that would forward blocks as plain messages would risk mixing proxy that would forward blocks as plain messages would risk mixing
up clients' requests. up clients' requests.
The Request-Tag option provides a very simple way for a proxy to keep In some cases, for example when forwarding block-wise request
them separate: if it appends a Request-Tag that is particular to the operations, appending a Request-Tag value unique to the client can
requesting endpoint to all request carrying any Block option, it does satisfy the requirements on the proxy that come from the presence of
not need to keep track of any further block state. a block option.
This is particularly useful to proxies that strive for stateless This is particularly useful to proxies that strive for stateless
operation as described in [I-D.ietf-core-stateless] Section 3.1. operation as described in [I-D.ietf-core-stateless] Section 4.
The precise classification of cases in which such a Request-Tag
option is sufficient is not trivial, especially when both request and
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 to proxies unaware of the Request-Tag option will
consider operations with differing request tags unmatchable but can consider operations with differing request tags unmatchable but can
skipping to change at page 19, line 16 skipping to change at page 19, line 33
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 availability of a secure pseudorandom number generator and truly
random seeds are essential for the security of the Echo option. If random seeds are essential for the security of the Echo option
no true random number generator is available, a truly random seed (except when using counting Echo values). If no true random number
must be provided from an external source. As each pseudoranom number generator is available, a truly random seed must be provided from an
must only be used once, an implementation need to get a new truly external source. As each pseudoranom number must only be used once,
random seed after reboot, or continously store state in nonvolatile an implementation need to get a new truly random seed after reboot,
memory, see ([RFC8613], Appendix B.1.1) for issues and solution or continously store state in nonvolatile memory, see ([RFC8613],
approaches for writing to nonvolatile memory. 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). The Echo option value MUST contain 32 AES_128_CCM_8). Unless a counting Echo value is used, the Echo
(pseudo-)random bits that are not predictable for any other party option value MUST contain 32 (pseudo-)random bits that are not
than the server, and SHOULD contain 64 (pseudo-)random bits. A predictable for any other party than the server, and SHOULD contain
server MAY use different security levels for different uses cases 64 (pseudo-)random bits. A server MAY use different security levels
(client aliveness, request freshness, state synchronization, network for different uses cases (client aliveness, request freshness, state
address reachability, etc.). synchronization, network address 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
numbered events, and are the legitimate case for Echo values shorter
than four bytes, which are not necessarily secret. They MUST only be
used when the request Echo values are integrity protected.
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
skipping to change at page 21, line 46 skipping to change at page 22, line 23
freshness and reachability. Clients only send Echo to the same from freshness and reachability. Clients only send Echo to the same from
which they were received. Compared to HTTP, CoAP clients are often which they were received. Compared to HTTP, CoAP clients are often
authenticated and non-mobile, and servers can therefore often authenticated and non-mobile, and servers can therefore often
correlate requests based on the security context, the client correlate requests based on the security context, the client
credentials, or the network address. When the Echo option increases credentials, or the network address. When the Echo option increases
a server's ability to correlate requests, clients MAY discard all a server's ability to correlate requests, clients MAY discard all
pre-emptive Echo values. pre-emptive Echo values.
7. IANA Considerations 7. IANA Considerations
This document adds the following option numbers to the "CoAP Option IANA is requested to add the following option numbers to the "CoAP
Numbers" registry defined by [RFC7252]: Option Numbers" registry defined by [RFC7252]:
[
The editor is asked to suggest the numbers after TBD, as those satisfy the construction requirements set out in RFC7252:
Echo is NoCacheKey but not Unsafe or Critical, so it needs to end with 11100 in binary representation;
Request-Tag has no properties so it needs to end with 00 and not with 11100).
Request-Tag are picked to not waste the precious space of less-than-one-byte options,
but such that its offset from the Block1 option it regularly occurs with can still be expressed in an 1-byte offset (27 + (13 + 255) > 292).
Echo was picked to be the shortest it can be in an empty message as a NoCacheKey option
(11100 in binary does not fit in a nibble, and two lower ones are already taken),
and as high as possible to keep room for other options that might typically occur in pairs and might still use optimization around low numbers.
]
+--------+-------------+-------------------+ +--------+-------------+-------------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+-------------+-------------------+ +--------+-------------+-------------------+
| TBD1 | Echo | [[this document]] | | TBD248 | Echo | [[this document]] |
| | | | | | | |
| TBD2 | Request-Tag | [[this document]] | | TBD292 | Request-Tag | [[this document]] |
+--------+-------------+-------------------+ +--------+-------------+-------------------+
Figure 5: CoAP Option Numbers Figure 5: CoAP Option Numbers
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,
skipping to change at page 22, line 43 skipping to change at page 23, line 33
[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>.
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-05 (work in progress), draft-ietf-core-oscore-groupcomm-06 (work in progress),
July 2019. November 2019.
[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-03 (work in progress), October 2019. stateless-04 (work in progress), December 2019.
[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 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
skipping to change at page 25, line 39 skipping to change at page 26, line 26
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-08:
* Make amplification attack mitigation by Echo an RFC7252
updating recommendation
* Give some more concrete guidance to that use case in terms of
sizes and message types
* Allow short (1-3 byte) Echo values for deterministic cases,
with according security considerations
* Point out the tricky parts around Request-Tag for stateless
proxies, and make that purely an outlook example with out-of-
scope details
* Lift ban on Request-Tag options without Block1 (as they can
legitimately be generated by an unaware proxy)
* Suggest concrete numbers for the options
o Changes since draft-ietf-core-echo-request-tag-07 (largely o Changes since draft-ietf-core-echo-request-tag-07 (largely
addressing Francesca's review): addressing Francesca's review):
* Request tag: Explicitly limit "MUST NOT recycle" requirement to * Request tag: Explicitly limit "MUST NOT recycle" requirement to
particular applications particular applications
* Token reuse: upper-case RECOMMEND sequence number approach * Token reuse: upper-case RECOMMEND sequence number approach
* Structure: Move per-topic introductions to respective chapters * Structure: Move per-topic introductions to respective chapters
(this avoids long jumps by the reader) (this avoids long jumps by the reader)
* Structure: Group Block2 / ETag section inside new fragmentation * Structure: Group Block2 / ETag section inside new fragmentation
(formerly Request-Tag) section (formerly Request-Tag) section
* More precise references into other documents * More precise references into other documents
* "concurrent operations": Emphasise that all here only matters * "concurrent operations": Emphasise that all here only matters
between endpoint pairs between endpoint pairs
 End of changes. 32 change blocks. 
80 lines changed or deleted 137 lines changed or added

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