--- 1/draft-ietf-core-echo-request-tag-13.txt 2021-10-04 06:15:06.717222407 -0700 +++ 2/draft-ietf-core-echo-request-tag-14.txt 2021-10-04 06:15:06.797224412 -0700 @@ -1,20 +1,20 @@ CoRE Working Group C. Amsuess Internet-Draft Updates: 7252 (if approved) J. Mattsson Intended status: Standards Track G. Selander -Expires: 13 January 2022 Ericsson AB - 12 July 2021 +Expires: 7 April 2022 Ericsson AB + 4 October 2021 CoAP: Echo, Request-Tag, and Token Processing - draft-ietf-core-echo-request-tag-13 + draft-ietf-core-echo-request-tag-14 Abstract This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the client @@ -42,21 +42,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -87,37 +87,37 @@ 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 Proxies . . . . . . . . . . . . . . . . . . . . . . . 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 4. Token Processing for Secure Request-Response Binding . . . . 22 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 22 4.2. Updated Token Processing Requirements for Clients . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 25 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 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 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction The initial Constrained Application Protocol (CoAP) suite of specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed with the assumption that security could be provided on a separate layer, in particular by using DTLS ([RFC6347]). However, for some use cases, additional functionality or extra processing is needed to support secure CoAP operations. This document specifies security enhancements to the Constrained Application Protocol (CoAP). @@ -430,24 +430,23 @@ and state synchronizing), the Echo option value MUST be integrity protected between the intended endpoints, e.g. using DTLS, TLS, or an OSCORE Inner option ([RFC8613]). When used to demonstrate reachability at a claimed network address, the Echo option SHOULD be 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. + operation. This is 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 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 option it recognizes as one generated by itself on follow-up 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 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 generated (or is re-generated) after the Echo value used to send to @@ -504,27 +503,28 @@ mechanism only provides a partial order on the messages' processing. * If a server reboots during operation it may need to synchronize state or time before continuing the interaction. For example, with OSCORE it is possible to reuse a partly persistently stored security context by synchronizing the Partial IV (sequence number) using the Echo option as specified in Section 7.5 of [RFC8613]. - * A device joining a CoAP group communication [RFC7390] - protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be - required to initially synchronize its replay window state with - a client by using the Echo option in a unicast response to a - multicast request. The client receiving the response with the - Echo option includes the Echo value in a subsequent unicast - request to the responding server. + * A device joining a CoAP group communication + [I-D.ietf-core-groupcomm-bis] protected with OSCORE + [I-D.ietf-core-oscore-groupcomm] may be required to initially + synchronize its replay window state with a client by using the + Echo option in a unicast response to a multicast request. The + client receiving the response with the Echo option includes + the Echo value in a subsequent unicast request to the + responding server. 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 sending the request to a resource with a large amplification factor. The amplification factor is the ratio between the size of the request and the total size of the response(s) to that request. A server that provides a large amplification factor to an unauthenticated peer SHOULD mitigate amplification attacks as described in Section 11.3 of [RFC7252]. One way to mitigate such attacks is that the server responds to the alleged source address @@ -596,39 +596,38 @@ 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. + Information conveyed to the server in the request Echo value has + different authority 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 + If all that is conveyed to the server 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 being + 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 + In most other cases, there is information conveyed for 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- @@ -643,21 +642,22 @@ 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. + mitigation). In this case the stricter protection 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). @@ -877,29 +877,28 @@ replayed. When security services are provided by OSCORE, these confirmations typically result either from the client receiving an OSCORE response message matching the request (an empty ACK is insufficient), or because the message's sequence number is old enough to be outside the server's receive window. When security services are provided by DTLS, this can only be confirmed if there was no CoAP retransmission of the request, the - request was responded to, and the server performs replay - protection. + request was responded to, and the server uses replay protection. Authors of other documents (e.g. applications of [RFC8613]) are invited to mandate this subsection's behavior for clients that execute block-wise interactions over secured transports. In this way, the server can rely on a conforming client to set the Request- - Tag option when required, and thereby have confidence the integrity - of the assembled body. + Tag option when required, and thereby have confidence in the + integrity of the assembled body. Note that this mechanism is implicitly implemented when the security layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). This is because with each message, any earlier message cannot be replayed any more, so the client never needs to set the Request-Tag option unless it wants to perform concurrent operations. Body integrity only makes sense in applications that have stateful block-wise transfers. On applications where all the state is in the application (e.g. because rather than POSTing a large representation @@ -1257,114 +1257,114 @@ | Number | Name | Reference | +--------+-------------+-------------------+ | TBD252 | Echo | [[this document]] | | | | | | TBD292 | Request-Tag | [[this document]] | +--------+-------------+-------------------+ Figure 5: CoAP Option Numbers 8. References - 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, - January 2012, . + January 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, - . + . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, - . + . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . + May 2017, . [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September - 2018, . + 2018, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, - . + . 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, . + [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, Internet-Draft, draft-ietf- core-oscore-groupcomm-12, 12 July 2021, . [I-D.irtf-pearg-numeric-ids-generation] Gont, F. and I. Arce, "On the Generation of Transient Numeric Identifiers", Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-07, 2 February 2021, . [I-D.mattsson-core-coap-attacks] Mattsson, J. P., Fornehed, J., Selander, G., Palombini, - F., and C. Amsüss, "Summarizing Known Attacks on CoAP", - Work in Progress, Internet-Draft, draft-mattsson-core- - coap-attacks-00, 16 May 2021, - . + F., and C. Amsüss, "CoAP Attacks", Work in Progress, + Internet-Draft, draft-mattsson-core-coap-attacks-01, 27 + July 2021, . [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000, . - [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for - the Constrained Application Protocol (CoAP)", RFC 7390, - DOI 10.17487/RFC7390, October 2014, - . - [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, - . + . [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, - . + . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, - . + . [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, - . + . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, - . + . Appendix A. Methods for Generating Echo Option Values The content and structure of the Echo option value are implementation specific and determined by the server. Two simple mechanisms for time-based freshness and one for event-based freshness are outlined in this section, the first is RECOMMENDED in general, and the second is RECOMMENDED in case the Echo option is encrypted between the client and the server. @@ -1384,50 +1384,50 @@ 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 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 continuity, e.g. due to reboot, the entries in the old list MUST be deleted. Echo option value: random value r 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 the client authority. 2. Integrity Protected Timestamp. The Echo option value is an integrity protected timestamp. The timestamp can have different 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 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 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 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 MUST be deleted and replaced by a new random secret key. Note that the privacy considerations in Section 6 may apply to the timestamp. Therefore, it might be important to encrypt it. Depending on the - choice of encryption algorithms, this may require a nonce to be - included in the Echo option value. + choice of encryption algorithms, this may require an initialization + vector to be included in the Echo option value, see below. Echo option value: timestamp t0, MAC(k, t0) 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), and independent of the client authority. If this method is used to additionally obtain network reachability of 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 number recovery per Appendix B.1.2 of [RFC8613]. The Echo option value is a simple counter without integrity protection of its own, serialized in uint format. The counter is incremented in a persistent way every time the state that needs to be synchronized is changed (in the 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]. @@ -1435,24 +1435,24 @@ Echo option value: 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 considerations may be used. The use of encrypted timestamps in the - Echo option increases security, but typically requires an IV - (Initialization Vector) to be included in the Echo option value, - which adds overhead and makes the specification of such a mechanism - slightly more complicated than what is described here. + Echo option provides additional protection, but typically requires an + initialization vector (a.k.a. nonce) as input to the encryption + algorithm, which adds a slight complication to the procedure as well + as overhead. Appendix B. Request-Tag Message Size Impact In absence of concurrent operations, the Request-Tag mechanism for 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 repeated transmission failure; in DTLS, if no packets are lost and replay protection is active), or when block-wise request operations happen rarely (in OSCORE, if there is always only one request block- wise operation in the replay window). @@ -1474,30 +1474,155 @@ * In OSCORE, the sequence number can be artificially increased so that all lost messages are outside of the replay window by the time the first request of the new operation gets processed, and all earlier operations can therefore be regarded as concluded. Appendix C. Change Log [ 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 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. + - 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 GenART, TSVART, OpsDir comments) + - Explain the size permissible for responses before amplification mitigation by referring to the QUIC draft for an OK factor, and giving the remaining numbers that led to it. The actual number is reduced from 152 to 136 because the more conservative case of the attacker not sending a token is considered now. - Added a definition for "freshness" - Give more concrete example values in figures 2 and 3 (based on the appendix suggestions), highlighting the differences between @@ -1744,22 +1870,23 @@ - The interaction between the new option and (cross) proxies is now covered. - Two messages being "Request-Tag matchable" was introduced to replace the older concept of having a request tag value with its slightly awkward equivalence definition. Acknowledgments - The authors want to thank Carsten Bormann, Francesca Palombini, and - Jim Schaad for providing valuable input to the draft. + The authors want to thank Carsten Bormann, Roman Danyliw, Benjamin + Kaduk, Murray Kucherawy, Francesca Palombini and Jim Schaad for + providing valuable input to the draft. Authors' Addresses Christian Amsüss Email: christian@amsuess.com John Preuß Mattsson Ericsson AB