draft-ietf-core-echo-request-tag-13.txt   draft-ietf-core-echo-request-tag-14.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: 13 January 2022 Ericsson AB Expires: 7 April 2022 Ericsson AB
12 July 2021 4 October 2021
CoAP: Echo, Request-Tag, and Token Processing CoAP: Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-13 draft-ietf-core-echo-request-tag-14
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 RFC 7252 with respect to the client request. This document updates RFC 7252 with respect to the client
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 13 January 2022. This Internet-Draft will expire on 7 April 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 3, line 6 skipping to change at page 3, line 6
3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 16 3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 16
3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 17 3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 17
3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 18 3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 18
3.5. Applications of the Request-Tag Option . . . . . . . . . 19 3.5. Applications of the Request-Tag Option . . . . . . . . . 19
3.5.1. Body Integrity Based on Payload Integrity . . . . . . 19 3.5.1. Body Integrity Based on Payload Integrity . . . . . . 19
3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . 21 Proxies . . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Rationale for the Option Properties . . . . . . . . . . . 21 3.6. Rationale for the Option Properties . . . . . . . . . . . 21
3.7. Rationale for Introducing the Option . . . . . . . . . . 22 3.7. Rationale for Introducing the Option . . . . . . . . . . 21
3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 22 3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 22
4. Token Processing for Secure Request-Response Binding . . . . 22 4. Token Processing for Secure Request-Response Binding . . . . 22
4.1. Request-Response Binding . . . . . . . . . . . . . . . . 22 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 22
4.2. Updated Token Processing Requirements for Clients . . . . 23 4.2. Updated Token Processing Requirements for Clients . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 25
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Methods for Generating Echo Option Values . . . . . 30 Appendix A. Methods for Generating Echo Option Values . . . . . 30
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 32 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 32
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The initial Constrained Application Protocol (CoAP) suite of The initial Constrained Application Protocol (CoAP) suite of
specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed
with the assumption that security could be provided on a separate with the assumption that security could be provided on a separate
layer, in particular by using DTLS ([RFC6347]). However, for some layer, in particular by using DTLS ([RFC6347]). However, for some
use cases, additional functionality or extra processing is needed to use cases, additional functionality or extra processing is needed to
support secure CoAP operations. This document specifies security support secure CoAP operations. This document specifies security
enhancements to the Constrained Application Protocol (CoAP). enhancements to the Constrained Application Protocol (CoAP).
skipping to change at page 10, line 16 skipping to change at page 10, line 16
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 be reachability at a claimed network address, the Echo option SHOULD be
a MAC of the claimed address, but MAY be unprotected. Combining a MAC of the claimed address, but MAY be unprotected. Combining
different Echo applications can necessitate different choices, see different Echo applications can necessitate different choices, see
Appendix A item 2 for an example. Appendix A item 2 for an example.
An Echo option MAY be sent with a successful response, i.e., even An Echo option MAY be sent with a successful response, i.e., even
though the request satisfied any freshness requirements on the though the request satisfied any freshness requirements on the
operation. This is occasionally called a "preemptive" Echo value, operation. This is called a "preemptive" Echo value, and useful when
and useful when the server anticipates that the client will need to the server anticipates that the client will need to demonstrate
demonstrate freshness relative to the current response the near freshness relative to the current response the near future.
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
skipping to change at page 11, line 44 skipping to change at page 11, line 44
mechanism only provides a partial order on the messages' mechanism only provides a partial order on the messages'
processing. 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 as Partial IV (sequence number) using the Echo option as
specified in 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
protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be [I-D.ietf-core-groupcomm-bis] protected with OSCORE
required to initially synchronize its replay window state with [I-D.ietf-core-oscore-groupcomm] may be required to initially
a client by using the Echo option in a unicast response to a synchronize its replay window state with a client by using the
multicast request. The client receiving the response with the Echo option in a unicast response to a multicast request. The
Echo option includes the Echo value in a subsequent unicast client receiving the response with the Echo option includes
request to the responding server. the Echo value in a subsequent unicast request to the
responding server.
3. An attacker can perform a denial-of-service attack by putting a 3. An attacker can perform a denial-of-service attack by putting a
victim's address in the source address of a CoAP request and victim's address in the source address of a CoAP request and
sending the request to a resource with a large amplification sending the request to a resource with a large amplification
factor. The amplification factor is the ratio between the size factor. The amplification factor is the ratio between the size
of the request and the total size of the response(s) to that of the request and the total size of the response(s) to that
request. A server that provides a large amplification factor to request. A server that provides a large amplification factor to
an unauthenticated peer SHOULD mitigate amplification attacks as an unauthenticated peer SHOULD mitigate amplification attacks as
described in Section 11.3 of [RFC7252]. One way to mitigate such described in Section 11.3 of [RFC7252]. One way to mitigate such
attacks is that the server responds to the alleged source address attacks is that the server responds to the alleged source address
skipping to change at page 13, line 41 skipping to change at page 13, line 41
event whenever an Echo value is used. This makes the Echo value event whenever an Echo value is used. This makes the Echo value
effectively single-use. effectively single-use.
Event and time based freshness can be combined in a single Echo 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 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 every event to obtain "usable once but only for 5 minutes"-style
semantics. semantics.
2.5.2. Authority over Used Information 2.5.2. Authority over Used Information
The information extracted by the server from the request Echo value Information conveyed to the server in the request Echo value has
has different sources of truth depending on the application. different authority depending on the application. Understanding who
Understanding who or what is the authoritative source of that or what is the authoritative source of that information helps the
information helps the server implementer decide the necessary server implementer decide the necessary protection of the Echo value.
protection of the Echo value.
If all that the server extracts is information which the client is If all that is conveyed to the server is information which the client
authorized to provide arbitrarily, (which is another way of saying is authorized to provide arbitrarily, (which is another way of saying
that the server has to trust the client on whatever Echo is used that the server has to trust the client on whatever Echo is being
for), then the server can issue Echo values that do not need to be used for), then the server can issue Echo values that do not need to
protected on their own. They still need to be covered by the 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 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 value can be just short enough to be unique between this server and
client. client.
For example, the client's OSCORE sender sequence number (as used in For example, the client's OSCORE sender sequence number (as used in
[RFC8613] Appendix B.1.2) is such information. [RFC8613] Appendix B.1.2) is such information.
In most other cases, there are properties extracted of which the In most other cases, there is information conveyed for which the
server is the authority ("The request must not be older than five 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 minutes" is counted on the server's clock, not the client's) or which
even involve the network (as when performing amplification even involve the network (as when performing amplification
mitigation). In these cases, the Echo value itself needs to be mitigation). In these cases, the Echo value itself needs to be
protected against forgery by the client, e.g. by using a sufficiently 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. 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 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 also act as the authority (e.g. when using time based freshness
purely to mitigate request delay attacks); these need careful case- purely to mitigate request delay attacks); these need careful case-
skipping to change at page 14, line 46 skipping to change at page 14, line 46
When the client is the sole authority over the synchronized property, When the client is the sole authority over the synchronized property,
the server can still use time or events to issue new Echo values. 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 Then, the request's Echo value not so much proves the indicated
freshness to the server, but reflects the client's intention to freshness to the server, but reflects the client's intention to
indicate reception of responses containing that value when sending indicate reception of responses containing that value when sending
the later ones. the later ones.
Note that a single Echo value can be used for multiple purposes (e.g. Note that a single Echo value can be used for multiple purposes (e.g.
to get both the sequence number information and perform amplification to get both the sequence number information and perform amplification
mitigation); then, the stricter requirements apply. mitigation). In this case the stricter protection requirements
apply.
2.5.3. Protection by a Security Protocol 2.5.3. Protection by a Security Protocol
For meaningful results, the Echo option needs to be used in For meaningful results, the Echo option needs to be used in
combination with a security protocol in almost all applications. combination with a security protocol in almost all applications.
When the information extracted by the server is only about a part of 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 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 also be used without a security protocol (in case of OSCORE, as an
outer option). outer option).
skipping to change at page 19, line 48 skipping to change at page 19, line 48
replayed. replayed.
When security services are provided by OSCORE, these confirmations When security services are provided by OSCORE, these confirmations
typically result either from the client receiving an OSCORE typically result either from the client receiving an OSCORE
response message matching the request (an empty ACK is response message matching the request (an empty ACK is
insufficient), or because the message's sequence number is old insufficient), or because the message's sequence number is old
enough to be outside the server's receive window. enough to be outside the server's receive window.
When security services are provided by DTLS, this can only be When security services are provided by DTLS, this can only be
confirmed if there was no CoAP retransmission of the request, the confirmed if there was no CoAP retransmission of the request, the
request was responded to, and the server performs replay request was responded to, and the server uses replay protection.
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 subsection's behavior for clients that invited to mandate this subsection's behavior for clients that
execute block-wise interactions over secured transports. In this execute block-wise interactions over secured transports. In this
way, the server can rely on a conforming client to set the Request- way, the server can rely on a conforming client to set the Request-
Tag option when required, and thereby have confidence the integrity Tag option when required, and thereby have confidence in the
of the assembled body. integrity 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
skipping to change at page 28, line 15 skipping to change at page 28, line 4
| Number | Name | Reference | | Number | Name | Reference |
+--------+-------------+-------------------+ +--------+-------------+-------------------+
| TBD252 | Echo | [[this document]] | | TBD252 | Echo | [[this document]] |
| | | | | | | |
| TBD292 | Request-Tag | [[this document]] | | TBD292 | Request-Tag | [[this document]] |
+--------+-------------+-------------------+ +--------+-------------+-------------------+
Figure 5: CoAP Option Numbers Figure 5: CoAP Option Numbers
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://doi.org/10.17487/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/rfc/rfc6347>. January 2012, <https://doi.org/10.17487/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/rfc/rfc7252>. <https://doi.org/10.17487/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/rfc/rfc7959>. <https://doi.org/10.17487/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/rfc/rfc8174>. May 2017, <https://doi.org/10.17487/RFC8174>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>. 2018, <https://doi.org/10.17487/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/rfc/rfc8613>. <https://doi.org/10.17487/RFC8613>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
04, 12 July 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-groupcomm-bis-04>.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and J. Park, "Group OSCORE - Secure Group Communication and J. Park, "Group OSCORE - Secure Group Communication
for CoAP", Work in Progress, Internet-Draft, draft-ietf- for CoAP", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-groupcomm-12, 12 July 2021, core-oscore-groupcomm-12, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-core- <https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-groupcomm-12>. oscore-groupcomm-12>.
[I-D.irtf-pearg-numeric-ids-generation] [I-D.irtf-pearg-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", Work in Progress, Internet-Draft, Numeric Identifiers", Work in Progress, Internet-Draft,
draft-irtf-pearg-numeric-ids-generation-07, 2 February draft-irtf-pearg-numeric-ids-generation-07, 2 February
2021, <https://datatracker.ietf.org/doc/html/draft-irtf- 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-
pearg-numeric-ids-generation-07>. pearg-numeric-ids-generation-07>.
[I-D.mattsson-core-coap-attacks] [I-D.mattsson-core-coap-attacks]
Mattsson, J. P., Fornehed, J., Selander, G., Palombini, Mattsson, J. P., Fornehed, J., Selander, G., Palombini,
F., and C. Amsüss, "Summarizing Known Attacks on CoAP", F., and C. Amsüss, "CoAP Attacks", Work in Progress,
Work in Progress, Internet-Draft, draft-mattsson-core- Internet-Draft, draft-mattsson-core-coap-attacks-01, 27
coap-attacks-00, 16 May 2021, July 2021, <https://datatracker.ietf.org/doc/html/draft-
<https://datatracker.ietf.org/doc/html/draft-mattsson- mattsson-core-coap-attacks-01>.
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
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<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/rfc/rfc7641>. <https://doi.org/10.17487/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/rfc/rfc8323>. <https://doi.org/10.17487/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/rfc/rfc8446>. <https://doi.org/10.17487/RFC8446>.
[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/rfc/rfc8974>. <https://doi.org/10.17487/RFC8974>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://doi.org/10.17487/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 30, line 47 skipping to change at page 30, line 42
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 This method is suitable both for time- and for event-based freshness
(e.g. by clearing the cache when an event occurs), and independent of (e.g. by clearing the cache when an event occurs), and independent of
the client authority. 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 an initialization
included in the Echo option value. vector to be included in the Echo option value, see below.
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
This method is suitable both for time and for event based freshness This method is suitable both for time- and for event-based freshness
(by the server remembering the time at which the event took place), (by the server remembering the time at which the event took place),
and independent of the client authority. and independent of the client authority.
If this method is used to additionally obtain network reachability of If this method is used to additionally obtain network reachability of
the client, the server MUST use the client's network address too, the client, the server MUST use the client's network address too,
e.g. as in "MAC(k, t0, apparent network address)". e.g. as in MAC(k, t0, apparent network address).
3. Persistent Counter. This can be used in OSCORE for sequence 3. Persistent Counter. This can be used in OSCORE for sequence
number recovery per Appendix B.1.2 of [RFC8613]. The Echo option number recovery per Appendix B.1.2 of [RFC8613]. The Echo option
value is a simple counter without integrity protection of its own, value is a simple counter without integrity protection of its own,
serialized in uint format. The counter is incremented in a serialized in uint format. The counter is incremented in a
persistent way every time the state that needs to be synchronized is 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 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 state may have been lost). An example of how such a persistent
counter can be implemented efficiently is the OSCORE server Sender counter can be implemented efficiently is the OSCORE server Sender
Sequence Number mechanism described in Appendix B.1.1 of [RFC8613]. Sequence Number mechanism described in Appendix B.1.1 of [RFC8613].
skipping to change at page 31, line 52 skipping to change at page 31, line 44
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 This method is suitable only if the client is the authority over the
synchronized property. Consequently, it cannot be used to show synchronized property. Consequently, it cannot be used to show
client aliveness. It provides statements from the client similar to client aliveness. It provides statements from the client similar to
event based freshness (but without a proof of freshness). 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 provides additional protection, but typically requires an
(Initialization Vector) to be included in the Echo option value, initialization vector (a.k.a. nonce) as input to the encryption
which adds overhead and makes the specification of such a mechanism algorithm, which adds a slight complication to the procedure as well
slightly more complicated than what is described here. as overhead.
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 and repeated transmission failure; in DTLS, if no packets are lost and
replay protection is active), or when block-wise request operations replay protection is active), or when block-wise request operations
happen rarely (in OSCORE, if there is always only one request block- happen rarely (in OSCORE, if there is always only one request block-
wise operation in the replay window). wise operation in the replay window).
skipping to change at page 32, line 42 skipping to change at page 32, line 39
* 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-13
- Minor editorial fixes.
- Wording enhancements:
o nonce -> initialization vector
o information extracted by the sever -> information conveyed
to the server
- Acknowledgements updated.
- Changelog for -13 added (previous upload just pointed to other
resources).
- Short title is "Echo, Request-Tag, and Token Processing" now
instead of outdated acronym.
- Informative reference to RFC 7390 is now to draft-ietf-core-
groupcomm-bis
* Changes since draft-ietf-core-echo-request-tag-12 (addressing * Changes since draft-ietf-core-echo-request-tag-12 (addressing
comments from IESG review) comments from IESG review)
See CoRE point-to-point responses at https://github.com/core-wg/ See CoRE point-to-point responses at https://github.com/core-wg/
echo-request-tag/blob/master/point-to-point.md echo-request-tag/blob/master/point-to-point.md
(https://github.com/core-wg/echo-request-tag/blob/master/point-to- (https://github.com/core-wg/echo-request-tag/blob/master/point-to-
point.md) and on CoRE mailing list. point.md) and on CoRE mailing list.
- Add subsection "Characterization of Echo Applications".
o Changes in applications and appendices to use the newly
introduced terms.
o In particular, some of the legitimization for using short
Echo values was drawn from the applications being event
based; the concept of the client being the "Authority over
[the] Used Information" now legitimizes these more
precisely.
- Add subsection "Updated Amplification Mitigation Requirements
for Servers". It contains the normative text updating RFC 7252
w/rt recommended mitigation methods, which previously happened
in passing.
- Amplification mitigation:
o Increase precision: Reachability check is performed once per
endpoint (was: peer).
o State that amplification factor applies to the sum of all
(previously: "the size of the", implicitly, single) returned
packets.
o Fix odd wording around how the Echo value would "contain"
the claimed address: was meant to contain in a cryptographic
sense, now clarified in that a MAC is recommended
- Define "preemptive Echo value" that was previously used without
definition; another occurrence of the concept was simplified
using the term.
- Add considerations for the use of DTLS without replay
protection.
- Privacy considerations: Address concerns raised in various
numeric-ids documents.
- Explicitly state expected security modes for Echo applications
and examples.
- Fix of requirements for H-C proxies: They _MUST NOT_ relay
unsafe requests. (Previously, it only said that they SHOULD
use a particular method, but not clearly that some method is
mandated.)
- Clarify that state synchonization is an application of the
freshness results in combination with some transported
application data, and not an immediate result of using Echo
alone.
- Add text to tie together applications and suggested mechanisms
- Restrict C-C proxy allowed behavior: Only safe requests
(incorrectly said "idempotent") may be used to proactively
populate the proxy's cache.
- Justify some "SHOULD"s by outlining justification for different
behavior.
o Normatively require H-C proxies to process Echo if they're
justified to do so, as no alternatives are available.
- Reference updates:
o QUIC is now RFC9000; precise section given as amplification
reference.
o Add note for RFC editor that RFC6347 can be upgraded to DTLS
1.3 if C321 overtakes C280
o Follow the core-coap-actuators to core-coap-attacks update
o RFC8470 reference is now normative (as using what's defined
there has been RECOMMENDED already)
- Editorial fixes
o Rewording of confusing sentences in amplification mitigation
and inner-/outer Echo values
o Replace "blacklist" terminology with "deny-list" where left
after other changes
o Removed sloppy use of Echo as a verb
o Minor clarifications
o Remove duplicate statements
o Typography and spelling fixes
- Fixes that are not editorial but minor
o Freshness is about time, of which round-trip time
(specialization now removed) is only a part.
o Reference how HTTP _1.1_ does it when explaining token
requirements, as that's an easily and widely understood
baseline.
* 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"
- Give more concrete example values in figures 2 and 3 (based on - Give more concrete example values in figures 2 and 3 (based on
the appendix suggestions), highlighting the differences between the appendix suggestions), highlighting the differences between
skipping to change at page 38, line 27 skipping to change at page 41, line 7
- The interaction between the new option and (cross) proxies is - The interaction between the new option and (cross) proxies is
now covered. now covered.
- Two messages being "Request-Tag matchable" was introduced to - Two messages being "Request-Tag matchable" was introduced to
replace the older concept of having a request tag value with replace the older concept of having a request tag value with
its slightly awkward equivalence definition. its slightly awkward equivalence definition.
Acknowledgments Acknowledgments
The authors want to thank Carsten Bormann, Francesca Palombini, and The authors want to thank Carsten Bormann, Roman Danyliw, Benjamin
Jim Schaad for providing valuable input to the draft. Kaduk, Murray Kucherawy, Francesca Palombini and Jim Schaad for
providing valuable input to the draft.
Authors' Addresses Authors' Addresses
Christian Amsüss Christian Amsüss
Email: christian@amsuess.com Email: christian@amsuess.com
John Preuß Mattsson John Preuß Mattsson
Ericsson AB Ericsson AB
 End of changes. 39 change blocks. 
69 lines changed or deleted 194 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/