draft-ietf-core-echo-request-tag-12.txt   draft-ietf-core-echo-request-tag-13.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: 5 August 2021 Ericsson AB Expires: 13 January 2022 Ericsson AB
1 February 2021 12 July 2021
CoAP: Echo, Request-Tag, and Token Processing CoAP: Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-12 draft-ietf-core-echo-request-tag-13
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 RFC 7252 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 a to ensure binding of response to request when CoAP is used with a
security protocol, and with respect to amplification mitigation, security protocol, and with respect to amplification mitigation,
where the use of Echo is now recommended. where the use of Echo is now recommended.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the CORE Working Group Discussion of this document takes place on the CORE Working Group
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 5 August 2021. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 36 skipping to change at page 2, line 36
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Request Freshness and the Echo Option . . . . . . . . . . . . 5 2. Request Freshness and the Echo Option . . . . . . . . . . . . 5
2.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 5 2.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 5
2.2. The Echo Option . . . . . . . . . . . . . . . . . . . . . 5 2.2. The Echo Option . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Echo Option Format . . . . . . . . . . . . . . . . . 6 2.2.1. Echo Option Format . . . . . . . . . . . . . . . . . 6
2.3. Echo Processing . . . . . . . . . . . . . . . . . . . . . 7 2.3. Echo Processing . . . . . . . . . . . . . . . . . . . . . 7
2.4. Applications of the Echo Option . . . . . . . . . . . . . 10 2.4. Applications of the Echo Option . . . . . . . . . . . . . 10
3. Protecting Message Bodies using Request Tags . . . . . . . . 12 2.5. Characterization of Echo Applications . . . . . . . . . . 13
3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 12 2.5.1. Time versus Event Based Freshness . . . . . . . . . . 13
3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 13 2.5.2. Authority over Used Information . . . . . . . . . . . 13
3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 13 2.5.3. Protection by a Security Protocol . . . . . . . . . . 14
3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 14 2.6. Updated Amplification Mitigation Requirements for
3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 15 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Applications of the Request-Tag Option . . . . . . . . . 16 3. Protecting Message Bodies using Request Tags . . . . . . . . 15
3.5.1. Body Integrity Based on Payload Integrity . . . . . . 16 3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 15
3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 17 3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 16
3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 16
3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 17
3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 18
3.5. Applications of the Request-Tag Option . . . . . . . . . 19
3.5.1. Body Integrity Based on Payload Integrity . . . . . . 19
3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 20
3.5.3. Simplified Block-Wise Handling for Constrained 3.5.3. Simplified Block-Wise Handling for Constrained
Proxies . . . . . . . . . . . . . . . . . . . . . . . 18 Proxies . . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Rationale for the Option Properties . . . . . . . . . . . 18
3.7. Rationale for Introducing the Option . . . . . . . . . . 19
3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 19
4. Token Processing for Secure Request-Response Binding . . . . 19
4.1. Request-Response Binding . . . . . . . . . . . . . . . . 19
4.2. Updated Token Processing Requirements for Clients . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 3.6. Rationale for the Option Properties . . . . . . . . . . . 21
5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 22 3.7. Rationale for Introducing the Option . . . . . . . . . . 22
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 4. Token Processing for Secure Request-Response Binding . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 4.2. Updated Token Processing Requirements for Clients . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
Appendix A. Methods for Generating Echo Option Values . . . . . 26 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 28 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Methods for Generating Echo Option Values . . . . . 30
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 32
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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).
[ Note to RFC editor: If C321 gets published before C280, then the
[RFC6347] references can be upgraded to draft-ietf-tls-dtls13-43
without the need for further changes; the reference is to 6347 here
because that was the stable DTLS reference when the document was last
touched by the authors. ]
This document specifies two CoAP options, the Echo option and the This document specifies two CoAP options, the Echo option and the
Request-Tag option: The Echo option enables a CoAP server to verify Request-Tag option: The Echo option enables a CoAP server to verify
the freshness of a request, synchronize state, or force a client to the freshness of a request, which can be used to synchronize state,
demonstrate reachability at its claimed network address. The or to force a client to demonstrate reachability at its claimed
Request-Tag option allows the CoAP server to match message fragments network address. The Request-Tag option allows the CoAP server to
belonging to the same request, fragmented using the CoAP block-wise match message fragments belonging to the same request, fragmented
Transfer mechanism, which mitigates attacks and enables concurrent using the CoAP block-wise transfer mechanism, which mitigates attacks
block-wise operations. These options in themselves do not replace and enables concurrent block-wise operations. These options in
the need for a security protocol; they specify the format and themselves do not replace the need for a security protocol; they
processing of data which, when integrity protected using e.g. DTLS specify the format and processing of data which, when integrity
([RFC6347]), TLS ([RFC8446]), or OSCORE ([RFC8613]), provide the protected using e.g. DTLS ([RFC6347]), TLS ([RFC8446]), or OSCORE
additional security features. ([RFC8613]), provide the additional security features.
This document updates [RFC7252] with a recommendation that servers This document updates [RFC7252] with a recommendation that servers
use the Echo option to mitigate amplification attacks. 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.
skipping to change at page 4, line 27 skipping to change at page 4, line 40
"CoAP client" and "CoAP server", respectively, as defined in "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.
A message's "freshness" is a measure of when a message was sent on a A message's "freshness" is a measure of when a message was sent on a
time scale of the recipient. A server that receives a request can time scale of the recipient. A server that receives a request can
either verify that the request is fresh or determine that it cannot either verify that the request is fresh or determine that it cannot
be verified that the request is fresh. What is considered a fresh be verified that the request is fresh. What is considered a fresh
message is application dependent; examplary uses are "no more than message is application dependent; exemplary uses are "no more than
one hour ago" or "after this server's last reboot". one hour ago" or "after this server's last reboot".
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".
skipping to change at page 5, line 16 skipping to change at page 5, line 31
2. Request Freshness and the Echo Option 2. Request Freshness and the Echo Option
2.1. Request Freshness 2.1. Request Freshness
A CoAP server receiving a request is in general not able to verify A CoAP server receiving a request is in general not able to verify
when the request was sent by the CoAP client. This remains true even when the request was sent by the CoAP client. This remains true even
if the request was protected with a security protocol, such as DTLS. if the request was protected with a security protocol, such as DTLS.
This makes CoAP requests vulnerable to certain delay attacks which This makes CoAP requests vulnerable to certain delay attacks which
are particularly perilous in the case of actuators are particularly perilous in the case of actuators
([I-D.mattsson-core-coap-actuators]). Some attacks can be mitigated ([I-D.mattsson-core-coap-attacks]). Some attacks can be mitigated by
by establishing fresh session keys, e.g. performing a DTLS handshake establishing fresh session keys, e.g. performing a DTLS handshake for
for each request, but in general this is not a solution suitable for each request, but in general this is not a solution suitable for
constrained environments, for example, due to increased message constrained environments, for example, due to increased message
overhead and latency. Additionally, if there are proxies, fresh DTLS overhead and latency. Additionally, if there are proxies, fresh DTLS
session keys between server and proxy does not say anything about session keys between server and proxy does not say anything about
when the client made the request. In a general hop-by-hop setting, when the client made the request. In a general hop-by-hop setting,
freshness may need to be verified in each hop. freshness may need to be verified in each hop.
A straightforward mitigation of potential delayed requests is that A straightforward mitigation of potential delayed requests is that
the CoAP server rejects a request the first time it appears and asks the CoAP server rejects a request the first time it appears and asks
the CoAP client to prove that it intended to make the request at this the CoAP client to prove that it intended to make the request at this
point in time. point in time.
skipping to change at page 5, line 40 skipping to change at page 6, line 6
2.2. The Echo Option 2.2. The Echo Option
This document defines the Echo option, a lightweight challenge- This document defines the Echo option, a lightweight challenge-
response mechanism for CoAP that enables a CoAP server to verify the response mechanism for CoAP that enables a CoAP server to verify the
freshness of a request. A fresh request is one whose age has not yet freshness of a request. A fresh request is one whose age has not yet
exceeded the freshness requirements set by the server. The freshness exceeded the freshness requirements set by the server. The freshness
requirements are application specific and may vary based on resource, requirements are application specific and may vary based on resource,
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.
freshness indicators that works for all CoAP methods and response
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 verifying the aliveness of the client and server, cryptographically verifying the aliveness of the
client, or forcing a client to demonstrate reachability at its client, or forcing a client to demonstrate reachability at its
claimed network address. The same functionality can be provided by claimed network address. The same functionality can be provided by
echoing freshness indicators in CoAP payloads, but this only works echoing freshness indicators in CoAP payloads, but this only works
for 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
skipping to change at page 7, line 6 skipping to change at page 7, line 11
freshness). As the request is bound to the Echo option value, the freshness). As the request is bound to the Echo option value, the
server can determine that the request is not older that the Echo server can determine that the request is not older that the Echo
option value. option value.
When the Echo option is used with OSCORE [RFC8613] it MAY be an Inner When the Echo option is used with OSCORE [RFC8613] it MAY be an Inner
or Outer option, and the Inner and Outer values are independent. or Outer option, and the Inner and Outer values are independent.
OSCORE servers MUST only produce Inner Echo options unless they are OSCORE servers MUST only produce Inner Echo options unless they are
merely testing for reachability of the client (the same as proxies merely testing for reachability of the client (the same as proxies
may do). The Inner option is encrypted and integrity protected may do). The Inner option is encrypted and integrity protected
between the endpoints, whereas the Outer option is not protected by between the endpoints, whereas the Outer option is not protected by
OSCORE and visible between the endpoints to the extent it is not OSCORE. As always with OSCORE, outer options are visible to (and may
protected by some other security protocol. E.g. in the case of DTLS be acted on by) all proxies, and are visible on all links where no
hop-by-hop between the endpoints, the Outer option is visible to additional encryption (like TLS between client and proxy) is used.
proxies along the path.
2.3. Echo Processing 2.3. Echo Processing
The Echo option MAY be included in any request or response (see The Echo option MAY be included in any request or response (see
Section 2.4 for different applications). Section 2.4 for different applications).
The application decides under what conditions a CoAP request to a The application decides under what conditions a CoAP request to a
resource is required to be fresh. These conditions can for example resource is required to be fresh. These conditions can for example
include what resource is requested, the request method and other data include what resource is requested, the request method and other data
in the request, and conditions in the environment such as the state in the request, and conditions in the environment such as the state
skipping to change at page 7, line 47 skipping to change at page 7, line 51
response, but provides an indication that the client had access to response, but provides an indication that the client had access to
the previous response at the time when it created the request. the previous response at the time when it created the request.
Upon receiving a 4.01 Unauthorized response with the Echo option, the Upon receiving a 4.01 Unauthorized response with the Echo option, the
client SHOULD resend the original request with the addition of an client SHOULD resend the original request with the addition of an
Echo option with the received Echo option value. The client MAY send Echo option with the received Echo option value. The client MAY send
a different request compared to the original request. Upon receiving a different request compared to the original request. Upon receiving
any other response with the Echo option, the client SHOULD echo the any other response with the Echo option, the client SHOULD echo the
Echo option value in the next request to the server. The client MAY Echo option value in the next request to the server. The client MAY
include the same Echo option value in several different requests to include the same Echo option value in several different requests to
the server. the server, or discard it at any time (especially to avoid tracking,
see Section 6).
A client MUST only send Echo values to endpoints it received them A client MUST only send Echo values to endpoints it received them
from (where as defined in [RFC7252] Section 1.2, the security from (where as defined in [RFC7252] Section 1.2, the security
association is part of the endpoint). In OSCORE processing, that association is part of the endpoint). In OSCORE processing, that
means sending Echo values from Outer options (or from non-OSCORE means sending Echo values from Outer options (or from non-OSCORE
responses) back in Outer options, and those from Inner options in responses) back in Outer options, and those from Inner options in
Inner options in the same security context. Inner options in the same security context.
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
skipping to change at page 8, line 22 skipping to change at page 8, line 26
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 to bind the Echo value One way for the server to verify freshness is to bind the Echo value
to a specific point in time and verify that the request is not older to a specific point in time and verify that the request is not older
than a certain threshold T. The server can verify this by checking than a certain threshold T. The server can verify this by checking
that (t1 - t0) < T, where t1 is the request receive time and t0 is that (t1 - t0) < T, where t1 is the request receive time and 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 over DTLS is shown 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)
| 4.01 | Token: 0x41 | 4.01 | Token: 0x41
skipping to change at page 9, line 10 skipping to change at page 9, line 13
| | | |
Figure 2: Example Message Flow for Time-Based Freshness using the Figure 2: Example Message Flow for Time-Based Freshness using the
'Integrity Protected Timestamp' construction of Appendix A 'Integrity Protected Timestamp' construction of Appendix A
Another way for the server to verify freshness is to maintain a cache Another way for the server to verify freshness is to maintain a cache
of values associated to events. The size of the cache is defined by of values associated to events. The size of the cache is defined by
the application. In the following we assume the cache size is 1, in the application. In the following we assume the cache size is 1, in
which case freshness is defined as no new event has taken place. At which case freshness is defined as no new event has taken place. At
each event a new value is written into the cache. The cache values each event a new value is written into the cache. The cache values
MUST be different for all practical purposes. The server verifies MUST be different except with negligible probability. The server
freshness by checking that e0 equals e1, where e0 is the cached value verifies freshness by checking that e0 equals e1, where e0 is the
when the Echo option value was generated, and e1 is the cached value cached value when the Echo option value was generated, and e1 is the
at the reception of the request. An example message flow is shown in cached value at the reception of the request. An example message
Figure 3. flow over DTLS is shown in Figure 3.
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)
| 4.01 | Token: 0x41 | 4.01 | Token: 0x41
skipping to change at page 10, line 9 skipping to change at page 10, line 9
| | without more round-trips) | | without more round-trips)
| | | |
Figure 3: Example Message Flow for Event-Based Freshness using Figure 3: Example Message Flow for Event-Based Freshness using
the 'Persistent Counter' construction of Appendix A the 'Persistent Counter' construction of Appendix A
When used to serve freshness requirements (including client aliveness When used to serve freshness requirements (including client aliveness
and state synchronizing), the Echo option value MUST be integrity and state synchronizing), the Echo option value MUST be integrity
protected between the intended endpoints, e.g. using DTLS, TLS, or an protected between the intended endpoints, e.g. using DTLS, TLS, or an
OSCORE Inner option ([RFC8613]). When used to demonstrate OSCORE Inner option ([RFC8613]). When used to demonstrate
reachability at a claimed network address, the Echo option SHOULD reachability at a claimed network address, the Echo option SHOULD be
contain the client's network address, but MAY be unprotected. a MAC of the claimed address, but MAY be unprotected. Combining
different Echo applications can necessitate different choices, see
Appendix A item 2 for an example.
An Echo option MAY be sent with a successful response, i.e., even
though the request satisfied any freshness requirements on the
operation. This is occasionally called a "preemptive" Echo value,
and useful when the server anticipates that the client will need to
demonstrate freshness relative to the current response the near
future.
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 MUST respond to Echo challenges itself if the proxy knows
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, it MUST NOT repeat an unsafe request and SHOULD
Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive respond with 503 Service Unavailable, Retry-After: 0 and terminate
connection. If the HTTP request arrived in Early Data, the proxy any underlying Keep-Alive connection. If the HTTP request arrived in
SHOULD use a 425 Too Early response instead (see [RFC8470]). They Early Data, the proxy SHOULD use a 425 Too Early response instead
MAY also use other mechanisms to establish freshness of the HTTP (see [RFC8470]). They MAY also use other mechanisms to establish
request that are not specified here. freshness of the HTTP request that are not specified here.
2.4. Applications of the Echo Option 2.4. Applications of the Echo Option
Unless otherwise noted, all these applications require a security
protocol to be used, and the Echo option to be protected by it.
1. Actuation requests often require freshness guarantees to avoid 1. Actuation requests often require freshness guarantees to avoid
accidental or malicious delayed actuator actions. In general, accidental or malicious delayed actuator actions. In general,
all non-safe methods (e.g. POST, PUT, DELETE) may require all non-safe methods (e.g. POST, PUT, DELETE) may require
freshness guarantees for secure operation. freshness guarantees for secure operation.
* The same Echo value may be used for multiple actuation * The same Echo value may be used for multiple actuation
requests to the same server, as long as the total round-trip requests to the same server, as long as the total time since
time since the Echo option value was generated is below the the Echo option value was generated is below the freshness
freshness threshold. threshold.
* For actuator applications with low delay tolerance, to avoid * For actuator applications with low delay tolerance, to avoid
additional round-trips for multiple requests in rapid additional round-trips for multiple requests in rapid
sequence, the server may include the Echo option with a new sequence, the server may send preemptive Echo values in
value even in a successful response to a request, successful requests, irrespectively of whether the request
irrespectively of whether the request contained an Echo option contained an Echo option or not. The client then uses the
or not. The client then uses the Echo option with the new Echo option with the new value in the next actuation request,
value in the next actuation request, and the server compares and the server compares the receive time accordingly.
the receive time accordingly.
2. A server may use the Echo option to synchronize properties (such 2. A server may use the Echo option to synchronize properties (such
as state or time) with a requesting client. A server MUST NOT as state or time) with a requesting client. A server MUST NOT
synchronize a property with a client which is not the authority synchronize a property with a client which is not the authority
of the property being synchronized. E.g. if access to a server of the property being synchronized. E.g. if access to a server
resource is dependent on time, then server MUST NOT synchronize resource is dependent on time, then server MUST NOT synchronize
time with a client requesting access unless it is time authority time with a client requesting access unless the client is time
for the server. authority for the server.
Note that the state to be synchronized is not carried inside the
Echo option. Any explicit state information needs to be carried
along in the messages the Echo value is sent in; the Echo
mechanism only provides a partial order on the messages'
processing.
* If a server reboots during operation it may need to * If a server reboots during operation it may need to
synchronize state or time before continuing the interaction. synchronize state or time before continuing the interaction.
For example, with OSCORE it is possible to reuse a partly For example, with OSCORE it is possible to reuse a partly
persistently stored security context by synchronizing the persistently stored security context by synchronizing the
Partial IV (sequence number) using the Echo option, see Partial IV (sequence number) using the Echo option as
Section 7.5 of [RFC8613]. specified in Section 7.5 of [RFC8613].
* A device joining a CoAP group communication [RFC7390] * A device joining a CoAP group communication [RFC7390]
protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be
required to initially verify freshness and synchronize state required to initially synchronize its replay window state with
or time with a client by using the Echo option in a unicast a client by using the Echo option in a unicast response to a
response to a multicast request. The client receiving the multicast request. The client receiving the response with the
response with the Echo option includes the Echo value in a Echo option includes the Echo value in a subsequent unicast
subsequent unicast request to the responding server. request to the responding server.
3. A server that sends large responses to unauthenticated peers 3. An attacker can perform a denial-of-service attack by putting a
SHOULD mitigate amplification attacks such as described in victim's address in the source address of a CoAP request and
Section 11.3 of [RFC7252] (where an attacker would put a victim's sending the request to a resource with a large amplification
address in the source address of a CoAP request). The factor. The amplification factor is the ratio between the size
RECOMMENDED way to do this is to ask a client to Echo its request of the request and the total size of the response(s) to that
to verify its source address. This needs to be done only once request. A server that provides a large amplification factor to
per peer and limits the range of potential victims from the an unauthenticated peer SHOULD mitigate amplification attacks as
general Internet to endpoints that have been previously in described in Section 11.3 of [RFC7252]. One way to mitigate such
contact with the server. For this application, the Echo option attacks is that the server responds to the alleged source address
can be used in messages that are not integrity protected, for of the request with an Echo option in short response message
example during discovery. (e.g. 4.01 Unauthorized), thereby requesting the client to verify
its source address. This needs to be done only once per endpoint
and limits the range of potential victims from the general
Internet to endpoints that have been previously in contact with
the server. For this application, the Echo option can be used in
messages that are not integrity protected, for example during
discovery. (This is formally recommended in Section 2.6).
* 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 provides a large
to unauthenticated peers SHOULD mitigate amplification amplification factor to unauthenticated peers SHOULD mitigate
attacks. The proxy SHOULD use Echo to verify origin amplification attacks. The proxy SHOULD use Echo to verify
reachability as described in Section 2.3. The proxy MAY origin reachability as described in Section 2.3. The proxy
forward idempotent requests immediately to have a cached MAY forward safe requests immediately to have a cached result
result available when the client's Echoed request arrives. available when the client's repeated request arrives.
* Amplification mitigation is a trade-off between giving * Amplification mitigation is a trade-off between giving
leverage to an attacker and causing overheads. An leverage to an attacker and causing overhead. An
amplification factor of 3 (i.e., don't send more than three amplification factor of 3 (i.e., don't send more than three
times the number of bytes received until the peer's address is times the number of bytes received until the peer's address is
confirmed) is considered acceptable for unconstrained confirmed) is considered acceptable for unconstrained
applications [I-D.ietf-quic-transport]. applications in [RFC9000] Section 8.
When that limit is applied and no further context is When that limit is applied and no further context is
available, a safe default is sending initial responses no available, a safe default is sending initial responses no
larger than 136 Bytes in CoAP serialization. (The number is larger than 136 Bytes in CoAP serialization. (The number is
assuming a 14 + 40 + 8 Bytes Ethernet, IP and UDP header with assuming a 14 + 40 + 8 Bytes Ethernet, IP and UDP header with
4 Bytes added for the CoAP header. Triple that minus the non- 4 Bytes added for the CoAP header. Triple that minus the non-
CoAP headers gives the 136 Bytes). Given the token also takes CoAP headers gives the 136 Bytes). Given the token also takes
up space in the request, responding with 132 Bytes after the up space in the request, responding with 132 Bytes after the
token is safe as well. token is safe as well.
* 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.
2.5. Characterization of Echo Applications
Use cases for the Echo option can be characterized by several
criteria that help determine the required properties of the Echo
value. These criteria apply both to those listed in Section 2.4 and
any novel applications. They provide rationale for the statements in
the former, and guidance for the latter.
2.5.1. Time versus Event Based Freshness
The property a client demonstrates by sending an Echo value is that
the request was sent after a certain point in time, or after some
event happened on the server.
When events are counted, they form something that can be used as a
monotonic but very non-uniform time line. With highly regular events
and low-resolution time, the distinction between time and event based
freshness can be blurred: "No longer than a month ago" is similar to
"since the last full moon".
In an extreme form of event based freshness, the server can place an
event whenever an Echo value is used. This makes the Echo value
effectively single-use.
Event and time based freshness can be combined in a single Echo
value, e.g. by encrypting a timestamp with a key that changes with
every event to obtain "usable once but only for 5 minutes"-style
semantics.
2.5.2. Authority over Used Information
The information extracted by the server from the request Echo value
has different sources of truth depending on the application.
Understanding who or what is the authoritative source of that
information helps the server implementer decide the necessary
protection of the Echo value.
If all that the server extracts is information which the client is
authorized to provide arbitrarily, (which is another way of saying
that the server has to trust the client on whatever Echo is used
for), then the server can issue Echo values that do not need to be
protected on their own. They still need to be covered by the
security protocol that covers the rest of the message, but the Echo
value can be just short enough to be unique between this server and
client.
For example, the client's OSCORE sender sequence number (as used in
[RFC8613] Appendix B.1.2) is such information.
In most other cases, there are properties extracted of which the
server is the authority ("The request must not be older than five
minutes" is counted on the server's clock, not the client's) or which
even involve the network (as when performing amplification
mitigation). In these cases, the Echo value itself needs to be
protected against forgery by the client, e.g. by using a sufficiently
large random value or a MAC as described in Appendix A items 1 and 2.
For some applications, the server may be able to trust the client to
also act as the authority (e.g. when using time based freshness
purely to mitigate request delay attacks); these need careful case-
by-case evaluation.
To issue Echo values without own protection, the server needs to
trust the client to never produce requests with attacker controlled
Echo values. The provisions of Section 2.3 (saying that an Echo
value may only be sent as received from the same server) allow that.
The requirement stated there for the client to treat the Echo value
as opaque holds for these application like for all others.
When the client is the sole authority over the synchronized property,
the server can still use time or events to issue new Echo values.
Then, the request's Echo value not so much proves the indicated
freshness to the server, but reflects the client's intention to
indicate reception of responses containing that value when sending
the later ones.
Note that a single Echo value can be used for multiple purposes (e.g.
to get both the sequence number information and perform amplification
mitigation); then, the stricter requirements apply.
2.5.3. Protection by a Security Protocol
For meaningful results, the Echo option needs to be used in
combination with a security protocol in almost all applications.
When the information extracted by the server is only about a part of
the system outside of any security protocol, then the Echo option can
also be used without a security protocol (in case of OSCORE, as an
outer option).
The only known application satisfying this requirement is network
address reachability, where unprotected Echo values are used both by
servers (e.g. during setup of a security context) and proxies (which
do not necessarily have a security association with their clients)
for amplification mitigation.
2.6. Updated Amplification Mitigation Requirements for Servers
This section updates the amplification mitigation requirements for
servers in [RFC7252] to recommend use of the Echo option to mitigate
amplification attacks. The requirements for clients are not updated.
Section 11.3 of [RFC7252] is updated by adding the following text:
A CoAP server SHOULD mitigate potential amplification attacks by
responding to unauthenticated clients with 4.01 Unauthorized
including an Echo option, as described in Section 2.4 item 3 of
[[this document]].
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
CoAP was designed to work over unreliable transports, such as UDP, CoAP was designed to work over unreliable transports, such as UDP,
and include a lightweight reliability feature to handle messages and includes a lightweight reliability feature to handle messages
which are lost or arrive out of order. In order for a security which are lost or arrive out of order. In order for a security
protocol to support CoAP operations over unreliable transports, it protocol to support CoAP operations over unreliable transports, it
must allow out-of-order delivery of messages using e.g. a sliding must allow out-of-order delivery of messages.
replay window such as described in Section 4.1.2.6 of DTLS
([RFC6347]).
The block-wise transfer mechanism [RFC7959] extends CoAP by defining The block-wise transfer mechanism [RFC7959] extends CoAP by defining
the transfer of a large resource representation (CoAP message body) the transfer of a large resource representation (CoAP message body)
as a sequence of blocks (CoAP message payloads). The mechanism uses as a sequence of blocks (CoAP message payloads). The mechanism uses
a pair of CoAP options, Block1 and Block2, pertaining to the request a pair of CoAP options, Block1 and Block2, pertaining to the request
and response payload, respectively. The block-wise functionality and response payload, respectively. The block-wise functionality
does not support the detection of interchanged blocks between does not support the detection of interchanged blocks between
different message bodies to the same resource having the same block different message bodies to the same resource having the same block
number. This remains true even when CoAP is used together with a number. This remains true even when CoAP is used together with a
security protocol such as DTLS or OSCORE, within the replay window security protocol such as DTLS or OSCORE, within the replay window
([I-D.mattsson-core-coap-actuators]), which is a vulnerability of ([I-D.mattsson-core-coap-attacks]), which is a vulnerability of CoAP
CoAP when using RFC7959. when using RFC7959.
A straightforward mitigation of mixing up blocks from different A straightforward mitigation of mixing up blocks from different
messages is to use unique identifiers for different message bodies, messages is to use unique identifiers for different message bodies,
which would provide equivalent protection to the case where the which would provide equivalent protection to the case where the
complete body fits into a single payload. The ETag option [RFC7252], complete body fits into a single payload. The ETag option [RFC7252],
set by the CoAP server, identifies a response body fragmented using set by the CoAP server, identifies a response body fragmented using
the Block2 option. the Block2 option.
3.2. The Request-Tag Option 3.2. The Request-Tag Option
skipping to change at page 16, line 28 skipping to change at page 19, line 15
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 an attacker to maliciously replace a later is still possible for an attacker to maliciously replace a 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-attacks]). 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:
* The individual exchanges MUST be integrity protected end-to-end * The individual exchanges MUST be integrity protected end-to-end
between client and server. between client and server.
* The client MUST NOT recycle a request tag in a new operation * 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 matchable if they
endpoint address using the new operation's security context. were sent to _any_ endpoint address using the new operation's
security context.
* The client MUST NOT regard a block-wise request operation as * 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 has sent in the
the operation have been confirmed by the message integrity operation would be regarded as invalid by the server if they were
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 When security services are provided by OSCORE, these confirmations
the client receiving an OSCORE response message matching the typically result either from the client receiving an OSCORE
request (an empty ACK is insufficient), or because the message's response message matching the request (an empty ACK is
sequence number is old enough to be outside the server's receive insufficient), or because the message's sequence number is old
window. enough to be outside the server's receive window.
In DTLS, this can only be confirmed if the request message was not When security services are provided by DTLS, this can only be
retransmitted, and was responded to. confirmed if there was no CoAP retransmission of the request, the
request was responded to, and the server performs replay
protection.
Authors of other documents (e.g. applications of [RFC8613]) are Authors of other documents (e.g. applications of [RFC8613]) are
invited to mandate this behavior for clients that execute block-wise invited to mandate this subsection's behavior for clients that
interactions over secured transports. In this way, the server can execute block-wise interactions over secured transports. In this
rely on a conforming client to set the Request-Tag option when way, the server can rely on a conforming client to set the Request-
required, and thereby conclude on the integrity of the assembled Tag option when required, and thereby have confidence the integrity
body. of the assembled body.
Note that this mechanism is implicitly implemented when the security Note that this mechanism is implicitly implemented when the security
layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]).
This is because with each message, any earlier message cannot be This is because with each message, any earlier message cannot be
replayed any more, so the client never needs to set the Request-Tag replayed any more, so the client never needs to set the Request-Tag
option unless it wants to perform concurrent operations. option unless it wants to perform concurrent operations.
Body integrity only makes sense in applications that have stateful Body integrity only makes sense in applications that have stateful
block-wise transfers. On applications where all the state is in the block-wise transfers. On applications where all the state is in the
application (e.g. because rather than POSTing a large representation application (e.g. because rather than POSTing a large representation
to a collection in a stateful block-wise transfer, a collection item to a collection in a stateful block-wise transfer, a collection item
is created first, then written to once and available when written is created first, then written to once and available when written
completely), clients need not concern themselves with body integrity completely), clients need not concern themselves with body integrity
and thus the Request-Tag. and thus the Request-Tag.
Body integrity is largely independent from replay protection: When no
replay protection is available (it is optional in DTLS), a full
block-wise operation may be replayed, but by adhering to the above,
no operations will be mixed up. The only link between body integrity
and replay protection is that without replay protection, recycling is
not possible.
3.5.2. Multiple Concurrent Block-wise Operations 3.5.2. Multiple Concurrent Block-wise Operations
CoAP clients, especially CoAP proxies, may initiate a block-wise CoAP clients, especially CoAP proxies, may initiate a block-wise
request operation to a resource, to which a previous one is already request operation to a resource, to which a previous one is already
in progress, which the new request should not cancel. A CoAP proxy in progress, which the new request should not cancel. A CoAP proxy
would be in such a situation when it forwards operations with the would be in such a situation when it forwards operations with the
same cache-key options but possibly different payloads. same cache-key options but possibly different payloads.
For those cases, Request-Tag is the proxy-safe elective option For those cases, Request-Tag is the proxy-safe elective option
suggested in [RFC7959] Section 2.4 last paragraph. suggested in [RFC7959] Section 2.4 last paragraph.
skipping to change at page 19, line 15 skipping to change at page 22, line 15
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
(Section 3.5.1) was to update [RFC7959] to say that blocks could only (Section 3.5.1) was to update [RFC7959] to say that blocks could only
be assembled if their fragments' order corresponded to the sequence be assembled if their fragments' order corresponded to the sequence
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-attacks]
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
block-wise response operations. The threat model here does not block-wise response operations. The threat model here does not
depend on an attacker: a client can construct a wrong representation depend on an attacker: a client can construct a wrong representation
by assembling it from blocks from different resource states. That by assembling it from blocks from different resource states. That
can happen when a resource is modified during a transfer, or when can happen when a resource is modified during a transfer, or when
some blocks are still valid in the client's cache. some blocks are still valid in the client's cache.
skipping to change at page 19, line 45 skipping to change at page 22, line 45
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 a response 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-attacks]). 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 HTTP/1.1, this type of binding is always assured by the ordered
reliable delivery as well as mandating that the server sends and 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
requests are differentiated by their Token. Note that the CoAP requests are differentiated by their Token. Note that the CoAP
Message ID cannot be used for this purpose since those are typically Message ID cannot be used for this purpose since those are typically
different for REST request and corresponding response in case of different for REST request and corresponding response in case of
"separate response", see Section 2.2 of [RFC7252]. "separate response", see Section 2.2 of [RFC7252].
CoAP [RFC7252] does not treat Token as a cryptographically important CoAP [RFC7252] does not treat Token as a cryptographically important
skipping to change at page 20, line 47 skipping to change at page 23, line 47
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 freshness assertion of the Echo option comes from the client The freshness assertion of the Echo option comes from the client
reproducing the same value of the Echo option in a request as in a reproducing the same value of the Echo option in a request as it
previous response. If the Echo value is a large random number then received in a previous response. If the Echo value is a large random
there is a high probability that the request is generated after number then there is a high probability that the request is generated
having seen the response. If the Echo value of the response can be after having seen the response. If the Echo value of the response
guessed, e.g. if based on a small random number or a counter (see can be guessed, e.g. if based on a small random number or a counter
Appendix A), then it is possible to compose a request with the right (see Appendix A), then it is possible to compose a request with the
Echo value ahead of time. However, this may not be an issue if the right Echo value ahead of time. Using guessable Echo values is only
communication is integrity protected against third parties and the permissible in a narrow set of cases described in Section 2.5.2.
client is trusted not misusing this capability. Echo values MUST be Echo values MUST be set by the CoAP server such that the risk
set by the CoAP server such that the risk associated with unintended associated with unintended reuse can be managed.
reuse can be managed.
If uniqueness of the Echo value is based on randomness, then the If uniqueness of the Echo value is based on randomness, then the
availability of a secure pseudorandom number generator and truly 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. If
no true random number generator is available, a truly random seed no true random number generator is available, a truly random seed
must be provided from an external source. As each pseudorandom must be provided from an external source. As each pseudorandom
number must only be used once, an implementation needs to get a new number must only be used once, an implementation needs to get a new
truly random seed after reboot, or continuously store state in truly random seed after reboot, or continuously store state in
nonvolatile memory. See ([RFC8613], Appendix B.1.1) for issues and nonvolatile memory. See ([RFC8613], Appendix B.1.1) for issues and
solution approaches for writing to nonvolatile memory. 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). If a random unique Echo value is intended, the Echo AES_128_CCM_8). If a random unique Echo value is intended, the Echo
option value SHOULD contain 64 (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. A server MAY use predictable for any other party than the server. A server MAY use
different security levels for different uses cases (client aliveness, different security levels for different uses cases (client aliveness,
request freshness, state synchronization, network address request freshness, state 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.
Counter Echo values can only be used to show freshness relative to Echo values without the protection of randomness or a MAC are limited
numbered events, and are the legitimate case for Echo values shorter to cases when the client is the trusted source of all derived
than four bytes, which are not necessarily secret. They MUST NOT be properties (as per Section 2.5.2). Using them needs per-application
used unless the request Echo values are integrity protected as per consideration of both the impact of a malicious client and of
Section 2.3. implementation errors in clients. These Echo values are the only
legitimate case for Echo values shorter than four bytes, which are
not necessarily secret. They MUST NOT be 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.
For the purpose of generating timestamps for Echo a server MAY set a For the purpose of generating timestamps for Echo a server MAY set a
timer at reboot and use the time since reboot, in a unit such that timer at reboot and use the time since reboot, choosing the
different requests arrive at different times. Servers MAY granularity such that different requests arrive at different times.
intermittently reset the timer and MAY generate a random offset Servers MAY intermittently reset the timer and MAY generate a random
applied to all timestamps. When resetting the timer, the server MUST offset applied to all timestamps. When resetting the timer, the
reject all Echo values that were created before the reset. 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: The server may associated with the wrong request is not trivial: The server may
skipping to change at page 23, line 19 skipping to change at page 26, line 27
response with that Token has been received. response with that Token has been received.
* Requests whose responses are cryptographically bound to the * 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 Tokens unsuitable
Tokens. for reuse.
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 [RFC8974]. in [RFC8974].
6. Privacy Considerations 6. Privacy Considerations
Implementations SHOULD NOT put any privacy-sensitive information in Implementations SHOULD NOT put any privacy-sensitive information in
skipping to change at page 24, line 5 skipping to change at page 27, line 9
especially true for preemptive Echo values. Servers MUST NOT use the especially true for preemptive Echo values. Servers MUST NOT use the
Echo option to correlate requests for other purposes than freshness Echo option to correlate requests for other purposes than freshness
and reachability. Clients only send Echo values to the same server and reachability. Clients only send Echo values to the same server
from which the values 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 preemptive Echo values. discard all preemptive Echo values.
Publicly visible generated identifiers, even when opaque (as all
defined in this document are), can leak information as described in
[I-D.irtf-pearg-numeric-ids-generation]. To avoid effects described
there, the absent Request-Tag option should be recycled as much as
possible. (That is generally possible as long as a security
mechanism is in place - even in the case of OSCORE outer block-wise
transfers, as the OSCORE option's variation ensures that no matchable
requests are created by different clients). When an unprotected Echo
option is used to demonstrate reachability, the recommended mechanism
of Section 2.3 keeps the effects to a minimum.
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
NoCacheKey but not Unsafe or Critical, so it needs to end with 11100 NoCacheKey but not Unsafe or Critical, so it needs to end with 11100
skipping to change at page 24, line 48 skipping to change at page 28, line 21
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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[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/rfc/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/rfc/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/rfc/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/rfc/rfc8174>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/rfc/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., Mattsson, J. P.,
"Group OSCORE - Secure Group Communication for CoAP", Work and J. Park, "Group OSCORE - Secure Group Communication
in Progress, Internet-Draft, draft-ietf-core-oscore- for CoAP", Work in Progress, Internet-Draft, draft-ietf-
groupcomm-10, 2 November 2020, <http://www.ietf.org/ core-oscore-groupcomm-12, 12 July 2021,
internet-drafts/draft-ietf-core-oscore-groupcomm-10.txt>. <https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-groupcomm-12>.
[I-D.ietf-quic-transport] [I-D.irtf-pearg-numeric-ids-generation]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Gont, F. and I. Arce, "On the Generation of Transient
and Secure Transport", Work in Progress, Internet-Draft, Numeric Identifiers", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-34, 14 January 2021, draft-irtf-pearg-numeric-ids-generation-07, 2 February
<http://www.ietf.org/internet-drafts/draft-ietf-quic- 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-
transport-34.txt>. pearg-numeric-ids-generation-07>.
[I-D.mattsson-core-coap-actuators] [I-D.mattsson-core-coap-attacks]
Mattsson, J., Fornehed, J., Selander, G., Palombini, F., Mattsson, J. P., Fornehed, J., Selander, G., Palombini,
and C. Amsuess, "Controlling Actuators with CoAP", Work in F., and C. Amsüss, "Summarizing Known Attacks on CoAP",
Progress, Internet-Draft, draft-mattsson-core-coap- Work in Progress, Internet-Draft, draft-mattsson-core-
actuators-06, 17 September 2018, <http://www.ietf.org/ coap-attacks-00, 16 May 2021,
internet-drafts/draft-mattsson-core-coap-actuators- <https://datatracker.ietf.org/doc/html/draft-mattsson-
06.txt>. core-coap-attacks-00>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, Network-based Software Architectures", 2000,
<https://www.ics.uci.edu/~fielding/pubs/dissertation/ <https://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>. 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/rfc/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/rfc/rfc7641>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/rfc/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/rfc/rfc8446>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and
Stateless Clients in the Constrained Application Protocol Stateless Clients in the Constrained Application Protocol
(CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,
<https://www.rfc-editor.org/info/rfc8974>. <https://www.rfc-editor.org/rfc/rfc8974>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
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 and one for event-based freshness are outlined time-based freshness and one for event-based freshness are outlined
in this section, the first is RECOMMENDED in general, and the second in this section, the first is RECOMMENDED in general, and the second
is RECOMMENDED in case the Echo option is encrypted between the is RECOMMENDED in case the Echo option is encrypted between the
client and the server. client and the server.
skipping to change at page 27, line 18 skipping to change at page 30, line 47
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.
Echo option value: random value r Echo option value: random value r
Server State: random value r, timestamp t0 Server State: random value r, timestamp t0
This method is suitable both for time and for event base freshness
(e.g. by clearing the cache when an event occurs), and independent of
the client authority.
2. Integrity Protected Timestamp. The Echo option value is an 2. Integrity Protected Timestamp. The Echo option value is an
integrity protected timestamp. The timestamp can have different integrity protected timestamp. The timestamp can have different
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.
Therefore, it might be important to encrypt it. 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 This method is suitable both for time and for event based freshness
usable for state synchronization (for example after volatile state (by the server remembering the time at which the event took place),
has been lost), and cannot be used for client aliveness. It requires and independent of the client authority.
that the client can be trusted to not spuriously produce Echo values.
The Echo option value is a simple counter without integrity If this method is used to additionally obtain network reachability of
protection of its own, serialized in uint format. The counter is the client, the server MUST use the client's network address too,
incremented in a persistent way every time the state that needs to be e.g. as in "MAC(k, t0, apparent network address)".
synchronized is changed (in the aforementioned example: when a reboot
indicates that volatile state may have been lost). An example of how 3. Persistent Counter. This can be used in OSCORE for sequence
such a persistent counter can be implemented efficiently is the number recovery per Appendix B.1.2 of [RFC8613]. The Echo option
OSCORE server Sender Sequence Number mechanism described in value is a simple counter without integrity protection of its own,
Appendix B.1.1 of [RFC8613]. 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 B.1.2 case: 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 Echo option value: counter
Server State: counter Server State: counter
This method is suitable only if the client is the authority over the
synchronized property. Consequently, it cannot be used to show
client aliveness. It provides statements from the client similar to
event based freshness (but without a proof of freshness).
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 Echo option increases security, but typically requires an IV
(Initialization Vector) to be included in the Echo option value, (Initialization Vector) to be included in the Echo option value,
which adds overhead and makes the specification of such a mechanism which adds overhead and makes the specification of such a mechanism
slightly more complicated than the two time-based mechanisms slightly more complicated than what is described here.
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 packets are lost), or repeated transmission failure; in DTLS, if no packets are lost and
when block-wise request operations happen rarely (in OSCORE, if there replay protection is active), or when block-wise request operations
is always only one request block-wise operation in the replay happen rarely (in OSCORE, if there is always only one request block-
window). wise operation in the replay 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 cannot be recycled any more When the absence of a Request-Tag option cannot 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
used-up, 256 values from one byte long options (2 Bytes overhead) are used-up, 256 values from one byte long options (2 Bytes overhead) are
available. available.
skipping to change at page 28, line 47 skipping to change at page 32, line 42
* In OSCORE, the sequence number can be artificially increased so * 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. ]
* Changes since draft-ietf-core-echo-request-tag-12 (addressing
comments from IESG review)
See CoRE point-to-point responses at https://github.com/core-wg/
echo-request-tag/blob/master/point-to-point.md
(https://github.com/core-wg/echo-request-tag/blob/master/point-to-
point.md) and on CoRE mailing list.
* Changes since draft-ietf-core-echo-request-tag-11 (addressing * Changes since draft-ietf-core-echo-request-tag-11 (addressing
GenART, TSVART, OpsDir comments) GenART, TSVART, OpsDir comments)
- Explain the size permissible for responses before amplification - Explain the size permissible for responses before amplification
mitigation by referring to the QUIC draft for an OK factor, and mitigation by referring to the QUIC draft for an OK factor, and
giving the remaining numbers that led to it. The actual number giving the remaining numbers that led to it. The actual number
is reduced from 152 to 136 because the more conservative case is reduced from 152 to 136 because the more conservative case
of the attacker not sending a token is considered now. of the attacker not sending a token is considered now.
- Added a definition for "freshness" - Added a definition for "freshness"
skipping to change at page 31, line 26 skipping to change at page 35, line 26
- Request tag: Enhance wording around "not sufficient condition" - Request tag: Enhance wording around "not sufficient condition"
- Request tag: Explicitly state when a tag needs to be set - Request tag: Explicitly state when a tag needs to be set
- Request tag: Clarification about permissibility of leaving the - Request tag: Clarification about permissibility of leaving the
option absent option absent
- Security considerations: wall clock time -> system time (and - Security considerations: wall clock time -> system time (and
remove inaccurate explanations) remove inaccurate explanations)
- Token reuse: describe blacklisting in a more implementation- - Token reuse: describe deny-listing in a more implementation-
independent way independent way
* Changes since draft-ietf-core-echo-request-tag-06: * Changes since draft-ietf-core-echo-request-tag-06:
- Removed visible comment that should not be visible in Token - Removed visible comment that should not be visible in Token
reuse considerations. reuse considerations.
* Changes since draft-ietf-core-echo-request-tag-05: * Changes since draft-ietf-core-echo-request-tag-05:
- Add privacy considerations on cookie-style use of Echo values - Add privacy considerations on cookie-style use of Echo values
 End of changes. 70 change blocks. 
212 lines changed or deleted 401 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/