idnits 2.17.1 draft-ietf-core-echo-request-tag-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 July 2021) is 1017 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-12 == Outdated reference: A later version (-12) exists of draft-irtf-pearg-numeric-ids-generation-07 == Outdated reference: A later version (-03) exists of draft-mattsson-core-coap-attacks-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Amsuess 3 Internet-Draft 4 Updates: 7252 (if approved) J. Mattsson 5 Intended status: Standards Track G. Selander 6 Expires: 13 January 2022 Ericsson AB 7 12 July 2021 9 CoAP: Echo, Request-Tag, and Token Processing 10 draft-ietf-core-echo-request-tag-13 12 Abstract 14 This document specifies enhancements to the Constrained Application 15 Protocol (CoAP) that mitigate security issues in particular use 16 cases. The Echo option enables a CoAP server to verify the freshness 17 of a request or to force a client to demonstrate reachability at its 18 claimed network address. The Request-Tag option allows the CoAP 19 server to match block-wise message fragments belonging to the same 20 request. This document updates RFC 7252 with respect to the client 21 Token processing requirements, forbidding non-secure reuse of Tokens 22 to ensure binding of response to request when CoAP is used with a 23 security protocol, and with respect to amplification mitigation, 24 where the use of Echo is now recommended. 26 Discussion Venues 28 This note is to be removed before publishing as an RFC. 30 Discussion of this document takes place on the CORE Working Group 31 mailing list (core@ietf.org), which is archived at 32 https://mailarchive.ietf.org/arch/browse/core/. 34 Source for this draft and an issue tracker can be found at 35 https://github.com/core-wg/echo-request-tag. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 13 January 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Request Freshness and the Echo Option . . . . . . . . . . . . 5 73 2.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 5 74 2.2. The Echo Option . . . . . . . . . . . . . . . . . . . . . 5 75 2.2.1. Echo Option Format . . . . . . . . . . . . . . . . . 6 76 2.3. Echo Processing . . . . . . . . . . . . . . . . . . . . . 7 77 2.4. Applications of the Echo Option . . . . . . . . . . . . . 10 78 2.5. Characterization of Echo Applications . . . . . . . . . . 13 79 2.5.1. Time versus Event Based Freshness . . . . . . . . . . 13 80 2.5.2. Authority over Used Information . . . . . . . . . . . 13 81 2.5.3. Protection by a Security Protocol . . . . . . . . . . 14 82 2.6. Updated Amplification Mitigation Requirements for 83 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 3. Protecting Message Bodies using Request Tags . . . . . . . . 15 85 3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 15 86 3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 16 87 3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 16 88 3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 17 89 3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 18 90 3.5. Applications of the Request-Tag Option . . . . . . . . . 19 91 3.5.1. Body Integrity Based on Payload Integrity . . . . . . 19 92 3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 20 93 3.5.3. Simplified Block-Wise Handling for Constrained 94 Proxies . . . . . . . . . . . . . . . . . . . . . . . 21 96 3.6. Rationale for the Option Properties . . . . . . . . . . . 21 97 3.7. Rationale for Introducing the Option . . . . . . . . . . 22 98 3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 22 99 4. Token Processing for Secure Request-Response Binding . . . . 22 100 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 22 101 4.2. Updated Token Processing Requirements for Clients . . . . 23 102 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 103 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 25 104 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 108 8.2. Informative References . . . . . . . . . . . . . . . . . 28 109 Appendix A. Methods for Generating Echo Option Values . . . . . 30 110 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 32 111 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32 112 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 115 1. Introduction 117 The initial Constrained Application Protocol (CoAP) suite of 118 specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed 119 with the assumption that security could be provided on a separate 120 layer, in particular by using DTLS ([RFC6347]). However, for some 121 use cases, additional functionality or extra processing is needed to 122 support secure CoAP operations. This document specifies security 123 enhancements to the Constrained Application Protocol (CoAP). 125 [ Note to RFC editor: If C321 gets published before C280, then the 126 [RFC6347] references can be upgraded to draft-ietf-tls-dtls13-43 127 without the need for further changes; the reference is to 6347 here 128 because that was the stable DTLS reference when the document was last 129 touched by the authors. ] 131 This document specifies two CoAP options, the Echo option and the 132 Request-Tag option: The Echo option enables a CoAP server to verify 133 the freshness of a request, which can be used to synchronize state, 134 or to force a client to demonstrate reachability at its claimed 135 network address. The Request-Tag option allows the CoAP server to 136 match message fragments belonging to the same request, fragmented 137 using the CoAP block-wise transfer mechanism, which mitigates attacks 138 and enables concurrent block-wise operations. These options in 139 themselves do not replace the need for a security protocol; they 140 specify the format and processing of data which, when integrity 141 protected using e.g. DTLS ([RFC6347]), TLS ([RFC8446]), or OSCORE 142 ([RFC8613]), provide the additional security features. 144 This document updates [RFC7252] with a recommendation that servers 145 use the Echo option to mitigate amplification attacks. 147 The document also updates the Token processing requirements for 148 clients specified in [RFC7252]. The updated processing forbids non- 149 secure reuse of Tokens to ensure binding of responses to requests 150 when CoAP is used with security, thus mitigating error cases and 151 attacks where the client may erroneously associate the wrong response 152 to a request. 154 Each of the following sections provides a more detailed introduction 155 to the topic at hand in its first subsection. 157 1.1. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in BCP 162 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 Like [RFC7252], this document is relying on the Representational 166 State Transfer [REST] architecture of the Web. 168 Unless otherwise specified, the terms "client" and "server" refer to 169 "CoAP client" and "CoAP server", respectively, as defined in 170 [RFC7252]. The term "origin server" is used as in [RFC7252]. The 171 term "origin client" is used in this document to denote the client 172 from which a request originates; to distinguish from clients in 173 proxies. 175 A message's "freshness" is a measure of when a message was sent on a 176 time scale of the recipient. A server that receives a request can 177 either verify that the request is fresh or determine that it cannot 178 be verified that the request is fresh. What is considered a fresh 179 message is application dependent; exemplary uses are "no more than 180 one hour ago" or "after this server's last reboot". 182 The terms "payload" and "body" of a message are used as in [RFC7959]. 183 The complete interchange of a request and a response body is called a 184 (REST) "operation". An operation fragmented using [RFC7959] is 185 called a "block-wise operation". A block-wise operation which is 186 fragmenting the request body is called a "block-wise request 187 operation". A block-wise operation which is fragmenting the response 188 body is called a "block-wise response operation". 190 Two request messages are said to be "matchable" if they occur between 191 the same endpoint pair, have the same code, and have the same set of 192 options, with the exception that elective NoCacheKey options and 193 options involved in block-wise transfer (Block1, Block2 and Request- 194 Tag) need not be the same. Two operations are said to be matchable 195 if any of their messages are. 197 Two matchable block-wise operations are said to be "concurrent" if a 198 block of the second request is exchanged even though the client still 199 intends to exchange further blocks in the first operation. 200 (Concurrent block-wise request operations from a single endpoint are 201 impossible with the options of [RFC7959] (see the last paragraphs of 202 Sections 2.4 and 2.5) because the second operation's block overwrites 203 any state of the first exchange.). 205 The Echo and Request-Tag options are defined in this document. 207 2. Request Freshness and the Echo Option 209 2.1. Request Freshness 211 A CoAP server receiving a request is in general not able to verify 212 when the request was sent by the CoAP client. This remains true even 213 if the request was protected with a security protocol, such as DTLS. 214 This makes CoAP requests vulnerable to certain delay attacks which 215 are particularly perilous in the case of actuators 216 ([I-D.mattsson-core-coap-attacks]). Some attacks can be mitigated by 217 establishing fresh session keys, e.g. performing a DTLS handshake for 218 each request, but in general this is not a solution suitable for 219 constrained environments, for example, due to increased message 220 overhead and latency. Additionally, if there are proxies, fresh DTLS 221 session keys between server and proxy does not say anything about 222 when the client made the request. In a general hop-by-hop setting, 223 freshness may need to be verified in each hop. 225 A straightforward mitigation of potential delayed requests is that 226 the CoAP server rejects a request the first time it appears and asks 227 the CoAP client to prove that it intended to make the request at this 228 point in time. 230 2.2. The Echo Option 232 This document defines the Echo option, a lightweight challenge- 233 response mechanism for CoAP that enables a CoAP server to verify the 234 freshness of a request. A fresh request is one whose age has not yet 235 exceeded the freshness requirements set by the server. The freshness 236 requirements are application specific and may vary based on resource, 237 method, and parameters outside of CoAP such as policies. The Echo 238 option value is a challenge from the server to the client included in 239 a CoAP response and echoed back to the server in one or more CoAP 240 requests. 242 This mechanism is not only important in the case of actuators, or 243 other use cases where the CoAP operations require freshness of 244 requests, but also in general for synchronizing state between CoAP 245 client and server, cryptographically verifying the aliveness of the 246 client, or forcing a client to demonstrate reachability at its 247 claimed network address. The same functionality can be provided by 248 echoing freshness indicators in CoAP payloads, but this only works 249 for methods and response codes defined to have a payload. The Echo 250 option provides a convention to transfer freshness indicators that 251 works for all methods and response codes. 253 2.2.1. Echo Option Format 255 The Echo Option is elective, safe-to-forward, not part of the cache- 256 key, and not repeatable, see Figure 1, which extends Table 4 of 257 [RFC7252]). 259 +--------+---+---+---+---+-------------+--------+------+---------+ 260 | No. | C | U | N | R | Name | Format | Len. | Default | 261 +--------+---+---+---+---+-------------+--------+------+---------+ 262 | TBD252 | | | x | | Echo | opaque | 1-40 | (none) | 263 +--------+---+---+---+---+-------------+--------+------+---------+ 265 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 267 Figure 1: Echo Option Summary 269 The Echo option value is generated by a server, and its content and 270 structure are implementation specific. Different methods for 271 generating Echo option values are outlined in Appendix A. Clients 272 and intermediaries MUST treat an Echo option value as opaque and make 273 no assumptions about its content or structure. 275 When receiving an Echo option in a request, the server MUST be able 276 to verify that the Echo option value (a) was generated by the server 277 or some other party that the server trusts, and (b) fulfills the 278 freshness requirements of the application. Depending on the 279 freshness requirements the server may verify exactly when the Echo 280 option value was generated (time-based freshness) or verify that the 281 Echo option was generated after a specific event (event-based 282 freshness). As the request is bound to the Echo option value, the 283 server can determine that the request is not older that the Echo 284 option value. 286 When the Echo option is used with OSCORE [RFC8613] it MAY be an Inner 287 or Outer option, and the Inner and Outer values are independent. 288 OSCORE servers MUST only produce Inner Echo options unless they are 289 merely testing for reachability of the client (the same as proxies 290 may do). The Inner option is encrypted and integrity protected 291 between the endpoints, whereas the Outer option is not protected by 292 OSCORE. As always with OSCORE, outer options are visible to (and may 293 be acted on by) all proxies, and are visible on all links where no 294 additional encryption (like TLS between client and proxy) is used. 296 2.3. Echo Processing 298 The Echo option MAY be included in any request or response (see 299 Section 2.4 for different applications). 301 The application decides under what conditions a CoAP request to a 302 resource is required to be fresh. These conditions can for example 303 include what resource is requested, the request method and other data 304 in the request, and conditions in the environment such as the state 305 of the server or the time of the day. 307 If a certain request is required to be fresh, the request does not 308 contain a fresh Echo option value, and the server cannot verify the 309 freshness of the request in some other way, the server MUST NOT 310 process the request further and SHOULD send a 4.01 Unauthorized 311 response with an Echo option. The server MAY include the same Echo 312 option value in several different response messages and to different 313 clients. Examples of this could be time-based freshness when several 314 responses are sent closely after each other or event-based freshness 315 with no event taking place between the responses. 317 The server may use request freshness provided by the Echo option to 318 verify the aliveness of a client or to synchronize state. The server 319 may also include the Echo option in a response to force a client to 320 demonstrate reachability at its claimed network address. Note that 321 the Echo option does not bind a request to any particular previous 322 response, but provides an indication that the client had access to 323 the previous response at the time when it created the request. 325 Upon receiving a 4.01 Unauthorized response with the Echo option, the 326 client SHOULD resend the original request with the addition of an 327 Echo option with the received Echo option value. The client MAY send 328 a different request compared to the original request. Upon receiving 329 any other response with the Echo option, the client SHOULD echo the 330 Echo option value in the next request to the server. The client MAY 331 include the same Echo option value in several different requests to 332 the server, or discard it at any time (especially to avoid tracking, 333 see Section 6). 335 A client MUST only send Echo values to endpoints it received them 336 from (where as defined in [RFC7252] Section 1.2, the security 337 association is part of the endpoint). In OSCORE processing, that 338 means sending Echo values from Outer options (or from non-OSCORE 339 responses) back in Outer options, and those from Inner options in 340 Inner options in the same security context. 342 Upon receiving a request with the Echo option, the server determines 343 if the request is required to be fresh. If not, the Echo option MAY 344 be ignored. If the request is required to be fresh and the server 345 cannot verify the freshness of the request in some other way, the 346 server MUST use the Echo option to verify that the request is fresh. 347 If the server cannot verify that the request is fresh, the request is 348 not processed further, and an error message MAY be sent. The error 349 message SHOULD include a new Echo option. 351 One way for the server to verify freshness is to bind the Echo value 352 to a specific point in time and verify that the request is not older 353 than a certain threshold T. The server can verify this by checking 354 that (t1 - t0) < T, where t1 is the request receive time and t0 is 355 the time when the Echo option value was generated. An example 356 message flow over DTLS is shown Figure 2. 358 Client Server 359 | | 360 +------>| Code: 0.03 (PUT) 361 | PUT | Token: 0x41 362 | | Uri-Path: lock 363 | | Payload: 0 (Unlock) 364 | | 365 |<------+ Code: 4.01 (Unauthorized) 366 | 4.01 | Token: 0x41 367 | | Echo: 0x00000009437468756c687521 (t0 = 9, +MAC) 368 | | 369 | ... | The round trips take 1 second, time is now t1 = 10. 370 | | 371 +------>| Code: 0.03 (PUT) 372 | PUT | Token: 0x42 373 | | Uri-Path: lock 374 | | Echo: 0x00000009437468756c687521 (t0 = 9, +MAC) 375 | | Payload: 0 (Unlock) 376 | | 377 | | Verify MAC, compare t1 - t0 = 1 < T => permitted. 378 | | 379 |<------+ Code: 2.04 (Changed) 380 | 2.04 | Token: 0x42 381 | | 383 Figure 2: Example Message Flow for Time-Based Freshness using the 384 'Integrity Protected Timestamp' construction of Appendix A 386 Another way for the server to verify freshness is to maintain a cache 387 of values associated to events. The size of the cache is defined by 388 the application. In the following we assume the cache size is 1, in 389 which case freshness is defined as no new event has taken place. At 390 each event a new value is written into the cache. The cache values 391 MUST be different except with negligible probability. The server 392 verifies freshness by checking that e0 equals e1, where e0 is the 393 cached value when the Echo option value was generated, and e1 is the 394 cached value at the reception of the request. An example message 395 flow over DTLS is shown in Figure 3. 397 Client Server 398 | | 399 +------>| Code: 0.03 (PUT) 400 | PUT | Token: 0x41 401 | | Uri-Path: lock 402 | | Payload: 0 (Unlock) 403 | | 404 |<------+ Code: 4.01 (Unauthorized) 405 | 4.01 | Token: 0x41 406 | | Echo: 0x05 (e0 = 5, number of total lock 407 | | operations performed) 408 | | 409 | ... | No alterations happen to the lock state, e1 has the 410 | | same value e1 = 5. 411 | | 412 +------>| Code: 0.03 (PUT) 413 | PUT | Token: 0x42 414 | | Uri-Path: lock 415 | | Echo: 0x05 416 | | Payload: 0 (Unlock) 417 | | 418 | | Compare e1 = e0 => permitted. 419 | | 420 |<------+ Code: 2.04 (Changed) 421 | 2.04 | Token: 0x42 422 | | Echo: 0x06 (e2 = 6, to allow later locking 423 | | without more round-trips) 424 | | 426 Figure 3: Example Message Flow for Event-Based Freshness using 427 the 'Persistent Counter' construction of Appendix A 429 When used to serve freshness requirements (including client aliveness 430 and state synchronizing), the Echo option value MUST be integrity 431 protected between the intended endpoints, e.g. using DTLS, TLS, or an 432 OSCORE Inner option ([RFC8613]). When used to demonstrate 433 reachability at a claimed network address, the Echo option SHOULD be 434 a MAC of the claimed address, but MAY be unprotected. Combining 435 different Echo applications can necessitate different choices, see 436 Appendix A item 2 for an example. 438 An Echo option MAY be sent with a successful response, i.e., even 439 though the request satisfied any freshness requirements on the 440 operation. This is occasionally called a "preemptive" Echo value, 441 and useful when the server anticipates that the client will need to 442 demonstrate freshness relative to the current response the near 443 future. 445 A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on 446 forwarded ones that had no Echo option or ones generated by the proxy 447 (from cache or as an error). If it does so, it MUST remove the Echo 448 option it recognizes as one generated by itself on follow-up 449 requests. When it receives an Echo option in a response, it MAY 450 forward it to the client (and, not recognizing it as an own in future 451 requests, relay it in the other direction as well) or process it on 452 its own. If it does so, it MUST ensure that the client's request was 453 generated (or is re-generated) after the Echo value used to send to 454 the server was first seen. (In most cases, this means that the proxy 455 needs to ask the client to repeat the request with a new Echo value.) 457 The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, 458 especially if they have reason to assume that access may require it 459 (e.g. because it is a PUT or POST); how this is determined is out of 460 scope for this document. The CoAP client side of HTTP-to-CoAP 461 proxies MUST respond to Echo challenges itself if the proxy knows 462 from the recent establishing of the connection that the HTTP request 463 is fresh. Otherwise, it MUST NOT repeat an unsafe request and SHOULD 464 respond with 503 Service Unavailable, Retry-After: 0 and terminate 465 any underlying Keep-Alive connection. If the HTTP request arrived in 466 Early Data, the proxy SHOULD use a 425 Too Early response instead 467 (see [RFC8470]). They MAY also use other mechanisms to establish 468 freshness of the HTTP request that are not specified here. 470 2.4. Applications of the Echo Option 472 Unless otherwise noted, all these applications require a security 473 protocol to be used, and the Echo option to be protected by it. 475 1. Actuation requests often require freshness guarantees to avoid 476 accidental or malicious delayed actuator actions. In general, 477 all non-safe methods (e.g. POST, PUT, DELETE) may require 478 freshness guarantees for secure operation. 480 * The same Echo value may be used for multiple actuation 481 requests to the same server, as long as the total time since 482 the Echo option value was generated is below the freshness 483 threshold. 485 * For actuator applications with low delay tolerance, to avoid 486 additional round-trips for multiple requests in rapid 487 sequence, the server may send preemptive Echo values in 488 successful requests, irrespectively of whether the request 489 contained an Echo option or not. The client then uses the 490 Echo option with the new value in the next actuation request, 491 and the server compares the receive time accordingly. 493 2. A server may use the Echo option to synchronize properties (such 494 as state or time) with a requesting client. A server MUST NOT 495 synchronize a property with a client which is not the authority 496 of the property being synchronized. E.g. if access to a server 497 resource is dependent on time, then server MUST NOT synchronize 498 time with a client requesting access unless the client is time 499 authority for the server. 501 Note that the state to be synchronized is not carried inside the 502 Echo option. Any explicit state information needs to be carried 503 along in the messages the Echo value is sent in; the Echo 504 mechanism only provides a partial order on the messages' 505 processing. 507 * If a server reboots during operation it may need to 508 synchronize state or time before continuing the interaction. 509 For example, with OSCORE it is possible to reuse a partly 510 persistently stored security context by synchronizing the 511 Partial IV (sequence number) using the Echo option as 512 specified in Section 7.5 of [RFC8613]. 514 * A device joining a CoAP group communication [RFC7390] 515 protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be 516 required to initially synchronize its replay window state with 517 a client by using the Echo option in a unicast response to a 518 multicast request. The client receiving the response with the 519 Echo option includes the Echo value in a subsequent unicast 520 request to the responding server. 522 3. An attacker can perform a denial-of-service attack by putting a 523 victim's address in the source address of a CoAP request and 524 sending the request to a resource with a large amplification 525 factor. The amplification factor is the ratio between the size 526 of the request and the total size of the response(s) to that 527 request. A server that provides a large amplification factor to 528 an unauthenticated peer SHOULD mitigate amplification attacks as 529 described in Section 11.3 of [RFC7252]. One way to mitigate such 530 attacks is that the server responds to the alleged source address 531 of the request with an Echo option in short response message 532 (e.g. 4.01 Unauthorized), thereby requesting the client to verify 533 its source address. This needs to be done only once per endpoint 534 and limits the range of potential victims from the general 535 Internet to endpoints that have been previously in contact with 536 the server. For this application, the Echo option can be used in 537 messages that are not integrity protected, for example during 538 discovery. (This is formally recommended in Section 2.6). 540 * In the presence of a proxy, a server will not be able to 541 distinguish different origin client endpoints. Following from 542 the recommendation above, a proxy that provides a large 543 amplification factor to unauthenticated peers SHOULD mitigate 544 amplification attacks. The proxy SHOULD use Echo to verify 545 origin reachability as described in Section 2.3. The proxy 546 MAY forward safe requests immediately to have a cached result 547 available when the client's repeated request arrives. 549 * Amplification mitigation is a trade-off between giving 550 leverage to an attacker and causing overhead. An 551 amplification factor of 3 (i.e., don't send more than three 552 times the number of bytes received until the peer's address is 553 confirmed) is considered acceptable for unconstrained 554 applications in [RFC9000] Section 8. 556 When that limit is applied and no further context is 557 available, a safe default is sending initial responses no 558 larger than 136 Bytes in CoAP serialization. (The number is 559 assuming a 14 + 40 + 8 Bytes Ethernet, IP and UDP header with 560 4 Bytes added for the CoAP header. Triple that minus the non- 561 CoAP headers gives the 136 Bytes). Given the token also takes 562 up space in the request, responding with 132 Bytes after the 563 token is safe as well. 565 * When an Echo response is sent to mitigate amplification, it 566 MUST be sent as a piggybacked or Non-confirmable response, 567 never as a separate one (which would cause amplification due 568 to retransmission). 570 4. A server may want to use the request freshness provided by the 571 Echo to verify the aliveness of a client. Note that in a 572 deployment with hop-by-hop security and proxies, the server can 573 only verify aliveness of the closest proxy. 575 2.5. Characterization of Echo Applications 577 Use cases for the Echo option can be characterized by several 578 criteria that help determine the required properties of the Echo 579 value. These criteria apply both to those listed in Section 2.4 and 580 any novel applications. They provide rationale for the statements in 581 the former, and guidance for the latter. 583 2.5.1. Time versus Event Based Freshness 585 The property a client demonstrates by sending an Echo value is that 586 the request was sent after a certain point in time, or after some 587 event happened on the server. 589 When events are counted, they form something that can be used as a 590 monotonic but very non-uniform time line. With highly regular events 591 and low-resolution time, the distinction between time and event based 592 freshness can be blurred: "No longer than a month ago" is similar to 593 "since the last full moon". 595 In an extreme form of event based freshness, the server can place an 596 event whenever an Echo value is used. This makes the Echo value 597 effectively single-use. 599 Event and time based freshness can be combined in a single Echo 600 value, e.g. by encrypting a timestamp with a key that changes with 601 every event to obtain "usable once but only for 5 minutes"-style 602 semantics. 604 2.5.2. Authority over Used Information 606 The information extracted by the server from the request Echo value 607 has different sources of truth depending on the application. 608 Understanding who or what is the authoritative source of that 609 information helps the server implementer decide the necessary 610 protection of the Echo value. 612 If all that the server extracts is information which the client is 613 authorized to provide arbitrarily, (which is another way of saying 614 that the server has to trust the client on whatever Echo is used 615 for), then the server can issue Echo values that do not need to be 616 protected on their own. They still need to be covered by the 617 security protocol that covers the rest of the message, but the Echo 618 value can be just short enough to be unique between this server and 619 client. 621 For example, the client's OSCORE sender sequence number (as used in 622 [RFC8613] Appendix B.1.2) is such information. 624 In most other cases, there are properties extracted of which the 625 server is the authority ("The request must not be older than five 626 minutes" is counted on the server's clock, not the client's) or which 627 even involve the network (as when performing amplification 628 mitigation). In these cases, the Echo value itself needs to be 629 protected against forgery by the client, e.g. by using a sufficiently 630 large random value or a MAC as described in Appendix A items 1 and 2. 632 For some applications, the server may be able to trust the client to 633 also act as the authority (e.g. when using time based freshness 634 purely to mitigate request delay attacks); these need careful case- 635 by-case evaluation. 637 To issue Echo values without own protection, the server needs to 638 trust the client to never produce requests with attacker controlled 639 Echo values. The provisions of Section 2.3 (saying that an Echo 640 value may only be sent as received from the same server) allow that. 641 The requirement stated there for the client to treat the Echo value 642 as opaque holds for these application like for all others. 644 When the client is the sole authority over the synchronized property, 645 the server can still use time or events to issue new Echo values. 646 Then, the request's Echo value not so much proves the indicated 647 freshness to the server, but reflects the client's intention to 648 indicate reception of responses containing that value when sending 649 the later ones. 651 Note that a single Echo value can be used for multiple purposes (e.g. 652 to get both the sequence number information and perform amplification 653 mitigation); then, the stricter requirements apply. 655 2.5.3. Protection by a Security Protocol 657 For meaningful results, the Echo option needs to be used in 658 combination with a security protocol in almost all applications. 660 When the information extracted by the server is only about a part of 661 the system outside of any security protocol, then the Echo option can 662 also be used without a security protocol (in case of OSCORE, as an 663 outer option). 665 The only known application satisfying this requirement is network 666 address reachability, where unprotected Echo values are used both by 667 servers (e.g. during setup of a security context) and proxies (which 668 do not necessarily have a security association with their clients) 669 for amplification mitigation. 671 2.6. Updated Amplification Mitigation Requirements for Servers 673 This section updates the amplification mitigation requirements for 674 servers in [RFC7252] to recommend use of the Echo option to mitigate 675 amplification attacks. The requirements for clients are not updated. 676 Section 11.3 of [RFC7252] is updated by adding the following text: 678 A CoAP server SHOULD mitigate potential amplification attacks by 679 responding to unauthenticated clients with 4.01 Unauthorized 680 including an Echo option, as described in Section 2.4 item 3 of 681 [[this document]]. 683 3. Protecting Message Bodies using Request Tags 685 3.1. Fragmented Message Body Integrity 687 CoAP was designed to work over unreliable transports, such as UDP, 688 and includes a lightweight reliability feature to handle messages 689 which are lost or arrive out of order. In order for a security 690 protocol to support CoAP operations over unreliable transports, it 691 must allow out-of-order delivery of messages. 693 The block-wise transfer mechanism [RFC7959] extends CoAP by defining 694 the transfer of a large resource representation (CoAP message body) 695 as a sequence of blocks (CoAP message payloads). The mechanism uses 696 a pair of CoAP options, Block1 and Block2, pertaining to the request 697 and response payload, respectively. The block-wise functionality 698 does not support the detection of interchanged blocks between 699 different message bodies to the same resource having the same block 700 number. This remains true even when CoAP is used together with a 701 security protocol such as DTLS or OSCORE, within the replay window 702 ([I-D.mattsson-core-coap-attacks]), which is a vulnerability of CoAP 703 when using RFC7959. 705 A straightforward mitigation of mixing up blocks from different 706 messages is to use unique identifiers for different message bodies, 707 which would provide equivalent protection to the case where the 708 complete body fits into a single payload. The ETag option [RFC7252], 709 set by the CoAP server, identifies a response body fragmented using 710 the Block2 option. 712 3.2. The Request-Tag Option 714 This document defines the Request-Tag option for identifying request 715 bodies, similar to ETag, but ephemeral and set by the CoAP client. 716 The Request-Tag is intended for use as a short-lived identifier for 717 keeping apart distinct block-wise request operations on one resource 718 from one client, addressing the issue described in Section 3.1. It 719 enables the receiving server to reliably assemble request payloads 720 (blocks) to their message bodies, and, if it chooses to support it, 721 to reliably process simultaneous block-wise request operations on a 722 single resource. The requests must be integrity protected if they 723 should protect against interchange of blocks between different 724 message bodies. The Request-Tag option is only used in requests that 725 carry the Block1 option, and in Block2 requests following these. 727 In essence, it is an implementation of the "proxy-safe elective 728 option" used just to "vary the cache key" as suggested in [RFC7959] 729 Section 2.4. 731 3.2.1. Request-Tag Option Format 733 The Request-Tag option is not critical, is safe to forward, 734 repeatable, and part of the cache key, see Figure 4, which extends 735 Table 4 of [RFC7252]). 737 +--------+---+---+---+---+-------------+--------+------+---------+ 738 | No. | C | U | N | R | Name | Format | Len. | Default | 739 +--------+---+---+---+---+-------------+--------+------+---------+ 740 | TBD292 | | | | x | Request-Tag | opaque | 0-8 | (none) | 741 +--------+---+---+---+---+-------------+--------+------+---------+ 743 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 745 Figure 4: Request-Tag Option Summary 747 Request-Tag, like the block options, is both a class E and a class U 748 option in terms of OSCORE processing (see Section 4.1 of [RFC8613]): 749 The Request-Tag MAY be an Inner or Outer option. It influences the 750 Inner or Outer block operation, respectively. The Inner and Outer 751 values are therefore independent of each other. The Inner option is 752 encrypted and integrity protected between client and server, and 753 provides message body identification in case of end-to-end 754 fragmentation of requests. The Outer option is visible to proxies 755 and labels message bodies in case of hop-by-hop fragmentation of 756 requests. 758 The Request-Tag option is only used in the request messages of block- 759 wise operations. 761 The Request-Tag mechanism can be applied independently on the server 762 and client sides of CoAP-to-CoAP proxies as are the block options, 763 though given it is safe to forward, a proxy is free to just forward 764 it when processing an operation. CoAP-to-HTTP proxies and HTTP-to- 765 CoAP proxies can use Request-Tag on their CoAP sides; it is not 766 applicable to HTTP requests. 768 3.3. Request-Tag Processing by Servers 770 The Request-Tag option does not require any particular processing on 771 the server side outside of the processing already necessary for any 772 unknown elective proxy-safe cache-key option: The option varies the 773 properties that distinguish block-wise operations (which includes all 774 options except elective NoCacheKey and except Block1/2), and thus the 775 server cannot treat messages with a different list of Request-Tag 776 options as belonging to the same operation. 778 To keep utilizing the cache, a server (including proxies) MAY discard 779 the Request-Tag option from an assembled block-wise request when 780 consulting its cache, as the option relates to the operation-on-the- 781 wire and not its semantics. For example, a FETCH request with the 782 same body as an older one can be served from the cache if the older's 783 Max-Age has not expired yet, even if the second operation uses a 784 Request-Tag and the first did not. (This is similar to the situation 785 about ETag in that it is formally part of the cache key, but 786 implementations that are aware of its meaning can cache more 787 efficiently, see [RFC7252] Section 5.4.2). 789 A server receiving a Request-Tag MUST treat it as opaque and make no 790 assumptions about its content or structure. 792 Two messages carrying the same Request-Tag is a necessary but not 793 sufficient condition for being part of the same operation. For one, 794 a server may still treat them as independent messages when it sends 795 2.01/2.04 responses for every block. Also, a client that lost 796 interest in an old operation but wants to start over can overwrite 797 the server's old state with a new initial (num=0) Block1 request and 798 the same Request-Tag under some circumstances. Likewise, that 799 results in the new message not being part of the old operation. 801 As it has always been, a server that can only serve a limited number 802 of block-wise operations at the same time can delay the start of the 803 operation by replying with 5.03 (Service unavailable) and a Max-Age 804 indicating how long it expects the existing operation to go on, or it 805 can forget about the state established with the older operation and 806 respond with 4.08 (Request Entity Incomplete) to later blocks on the 807 first operation. 809 3.4. Setting the Request-Tag 811 For each separate block-wise request operation, the client can choose 812 a Request-Tag value, or choose not to set a Request-Tag. It needs to 813 be set to the same value (or unset) in all messages belonging to the 814 same operation, as otherwise they are treated as separate operations 815 by the server. 817 Starting a request operation matchable to a previous operation and 818 even using the same Request-Tag value is called request tag 819 recycling. The absence of a Request-Tag option is viewed as a value 820 distinct from all values with a single Request-Tag option set; 821 starting a request operation matchable to a previous operation where 822 neither has a Request-Tag option therefore constitutes request tag 823 recycling just as well (also called "recycling the absent option"). 825 Clients that use Request-Tag for a particular purpose (like in 826 Section 3.5) MUST NOT recycle a request tag unless the first 827 operation has concluded. What constitutes a concluded operation 828 depends on the purpose, and is defined accordingly; see examples in 829 Section 3.5. 831 When Block1 and Block2 are combined in an operation, the Request-Tag 832 of the Block1 phase is set in the Block2 phase as well for otherwise 833 the request would have a different set of options and would not be 834 recognized any more. 836 Clients are encouraged to generate compact messages. This means 837 sending messages without Request-Tag options whenever possible, and 838 using short values when the absent option cannot be recycled. 840 Note that Request-Tag options can be present in request messages that 841 carry no Block option (for example, because a Request-Tag unaware 842 proxy reassembled them), and MUST be ignored in those. 844 The Request-Tag option MUST NOT be present in response messages. 846 3.5. Applications of the Request-Tag Option 848 3.5.1. Body Integrity Based on Payload Integrity 850 When a client fragments a request body into multiple message 851 payloads, even if the individual messages are integrity protected, it 852 is still possible for an attacker to maliciously replace a later 853 operation's blocks with an earlier operation's blocks (see 854 Section 2.5 of [I-D.mattsson-core-coap-attacks]). Therefore, the 855 integrity protection of each block does not extend to the operation's 856 request body. 858 In order to gain that protection, use the Request-Tag mechanism as 859 follows: 861 * The individual exchanges MUST be integrity protected end-to-end 862 between client and server. 864 * The client MUST NOT recycle a request tag in a new operation 865 unless the previous operation matchable to the new one has 866 concluded. 868 If any future security mechanisms allow a block-wise transfer to 869 continue after an endpoint's details (like the IP address) have 870 changed, then the client MUST consider messages matchable if they 871 were sent to _any_ endpoint address using the new operation's 872 security context. 874 * The client MUST NOT regard a block-wise request operation as 875 concluded unless all of the messages the client has sent in the 876 operation would be regarded as invalid by the server if they were 877 replayed. 879 When security services are provided by OSCORE, these confirmations 880 typically result either from the client receiving an OSCORE 881 response message matching the request (an empty ACK is 882 insufficient), or because the message's sequence number is old 883 enough to be outside the server's receive window. 885 When security services are provided by DTLS, this can only be 886 confirmed if there was no CoAP retransmission of the request, the 887 request was responded to, and the server performs replay 888 protection. 890 Authors of other documents (e.g. applications of [RFC8613]) are 891 invited to mandate this subsection's behavior for clients that 892 execute block-wise interactions over secured transports. In this 893 way, the server can rely on a conforming client to set the Request- 894 Tag option when required, and thereby have confidence the integrity 895 of the assembled body. 897 Note that this mechanism is implicitly implemented when the security 898 layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). 899 This is because with each message, any earlier message cannot be 900 replayed any more, so the client never needs to set the Request-Tag 901 option unless it wants to perform concurrent operations. 903 Body integrity only makes sense in applications that have stateful 904 block-wise transfers. On applications where all the state is in the 905 application (e.g. because rather than POSTing a large representation 906 to a collection in a stateful block-wise transfer, a collection item 907 is created first, then written to once and available when written 908 completely), clients need not concern themselves with body integrity 909 and thus the Request-Tag. 911 Body integrity is largely independent from replay protection: When no 912 replay protection is available (it is optional in DTLS), a full 913 block-wise operation may be replayed, but by adhering to the above, 914 no operations will be mixed up. The only link between body integrity 915 and replay protection is that without replay protection, recycling is 916 not possible. 918 3.5.2. Multiple Concurrent Block-wise Operations 920 CoAP clients, especially CoAP proxies, may initiate a block-wise 921 request operation to a resource, to which a previous one is already 922 in progress, which the new request should not cancel. A CoAP proxy 923 would be in such a situation when it forwards operations with the 924 same cache-key options but possibly different payloads. 926 For those cases, Request-Tag is the proxy-safe elective option 927 suggested in [RFC7959] Section 2.4 last paragraph. 929 When initializing a new block-wise operation, a client has to look at 930 other active operations: 932 * If any of them is matchable to the new one, and the client neither 933 wants to cancel the old one nor postpone the new one, it can pick 934 a Request-Tag value (including the absent option) that is not in 935 use by the other matchable operations for the new operation. 937 * Otherwise, it can start the new operation without setting the 938 Request-Tag option on it. 940 3.5.3. Simplified Block-Wise Handling for Constrained Proxies 942 The Block options were defined to be unsafe to forward because a 943 proxy that would forward blocks as plain messages would risk mixing 944 up clients' requests. 946 In some cases, for example when forwarding block-wise request 947 operations, appending a Request-Tag value unique to the client can 948 satisfy the requirements on the proxy that come from the presence of 949 a block option. 951 This is particularly useful to proxies that strive for stateless 952 operation as described in [RFC8974] Section 4. 954 The precise classification of cases in which such a Request-Tag 955 option is sufficient is not trivial, especially when both request and 956 response body are fragmented, and out of scope for this document. 958 3.6. Rationale for the Option Properties 960 The Request-Tag option can be elective, because to servers unaware of 961 the Request-Tag option, operations with differing request tags will 962 not be matchable. 964 The Request-Tag option can be safe to forward but part of the cache 965 key, because proxies unaware of the Request-Tag option will consider 966 operations with differing request tags unmatchable but can still 967 forward them. 969 The Request-Tag option is repeatable because this easily allows 970 several cascaded stateless proxies to each put in an origin address. 971 They can perform the steps of Section 3.5.3 without the need to 972 create an option value that is the concatenation of the received 973 option and their own value, and can simply add a new Request-Tag 974 option unconditionally. 976 In draft versions of this document, the Request-Tag option used to be 977 critical and unsafe to forward. That design was based on an 978 erroneous understanding of which blocks could be composed according 979 to [RFC7959]. 981 3.7. Rationale for Introducing the Option 983 An alternative that was considered to the Request-Tag option for 984 coping with the problem of fragmented message body integrity 985 (Section 3.5.1) was to update [RFC7959] to say that blocks could only 986 be assembled if their fragments' order corresponded to the sequence 987 numbers. 989 That approach would have been difficult to roll out reliably on DTLS 990 where many implementations do not expose sequence numbers, and would 991 still not prevent attacks like in [I-D.mattsson-core-coap-attacks] 992 Section 2.5.2. 994 3.8. Block2 / ETag Processing 996 The same security properties as in Section 3.5.1 can be obtained for 997 block-wise response operations. The threat model here does not 998 depend on an attacker: a client can construct a wrong representation 999 by assembling it from blocks from different resource states. That 1000 can happen when a resource is modified during a transfer, or when 1001 some blocks are still valid in the client's cache. 1003 Rules stating that response body reassembly is conditional on 1004 matching ETag values are already in place from Section 2.4 of 1005 [RFC7959]. 1007 To gain equivalent protection to Section 3.5.1, a server MUST use the 1008 Block2 option in conjunction with the ETag option ([RFC7252], 1009 Section 5.10.6), and MUST NOT use the same ETag value for different 1010 representations of a resource. 1012 4. Token Processing for Secure Request-Response Binding 1014 4.1. Request-Response Binding 1016 A fundamental requirement of secure REST operations is that the 1017 client can bind a response to a particular request. If this is not 1018 ensured, a client may erroneously associate the wrong response to a 1019 request. The wrong response may be an old response for the same 1020 resource or a response for a completely different resource (see e.g. 1021 Section 2.3 of [I-D.mattsson-core-coap-attacks]). For example, a 1022 request for the alarm status "GET /status" may be associated to a 1023 prior response "on", instead of the correct response "off". 1025 In HTTP/1.1, this type of binding is always assured by the ordered 1026 and reliable delivery as well as mandating that the server sends 1027 responses in the same order that the requests were received. The 1028 same is not true for CoAP where the server (or an attacker) can 1029 return responses in any order and where there can be any number of 1030 responses to a request (see e.g. [RFC7641]). In CoAP, concurrent 1031 requests are differentiated by their Token. Note that the CoAP 1032 Message ID cannot be used for this purpose since those are typically 1033 different for REST request and corresponding response in case of 1034 "separate response", see Section 2.2 of [RFC7252]. 1036 CoAP [RFC7252] does not treat Token as a cryptographically important 1037 value and does not give stricter guidelines than that the Tokens 1038 currently "in use" SHOULD (not SHALL) be unique. If used with a 1039 security protocol not providing bindings between requests and 1040 responses (e.g. DTLS and TLS) Token reuse may result in situations 1041 where a client matches a response to the wrong request. Note that 1042 mismatches can also happen for other reasons than a malicious 1043 attacker, e.g. delayed delivery or a server sending notifications to 1044 an uninterested client. 1046 A straightforward mitigation is to mandate clients to not reuse 1047 Tokens until the traffic keys have been replaced. The following 1048 section formalizes that. 1050 4.2. Updated Token Processing Requirements for Clients 1052 As described in Section 4.1, the client must be able to verify that a 1053 response corresponds to a particular request. This section updates 1054 the Token processing requirements for clients in [RFC7252] to always 1055 assure a cryptographically secure binding of responses to requests 1056 for secure REST operations like "coaps". The Token processing for 1057 servers is not updated. Token processing in Section 5.3.1 of 1058 [RFC7252] is updated by adding the following text: 1060 When CoAP is used with a security protocol not providing bindings 1061 between requests and responses, the Tokens have cryptographic 1062 importance. The client MUST make sure that Tokens are not used in a 1063 way so that responses risk being associated with the wrong request. 1065 One easy way to accomplish this is to implement the Token (or part of 1066 the Token) as a sequence number starting at zero for each new or 1067 rekeyed secure connection. This approach SHOULD be followed. 1069 5. Security Considerations 1071 The freshness assertion of the Echo option comes from the client 1072 reproducing the same value of the Echo option in a request as it 1073 received in a previous response. If the Echo value is a large random 1074 number then there is a high probability that the request is generated 1075 after having seen the response. If the Echo value of the response 1076 can be guessed, e.g. if based on a small random number or a counter 1077 (see Appendix A), then it is possible to compose a request with the 1078 right Echo value ahead of time. Using guessable Echo values is only 1079 permissible in a narrow set of cases described in Section 2.5.2. 1080 Echo values MUST be set by the CoAP server such that the risk 1081 associated with unintended reuse can be managed. 1083 If uniqueness of the Echo value is based on randomness, then the 1084 availability of a secure pseudorandom number generator and truly 1085 random seeds are essential for the security of the Echo option. If 1086 no true random number generator is available, a truly random seed 1087 must be provided from an external source. As each pseudorandom 1088 number must only be used once, an implementation needs to get a new 1089 truly random seed after reboot, or continuously store state in 1090 nonvolatile memory. See ([RFC8613], Appendix B.1.1) for issues and 1091 approaches for writing to nonvolatile memory. 1093 A single active Echo value with 64 (pseudo-)random bits gives the 1094 same theoretical security level as a 64-bit MAC (as used in e.g. 1095 AES_128_CCM_8). If a random unique Echo value is intended, the Echo 1096 option value SHOULD contain 64 (pseudo-)random bits that are not 1097 predictable for any other party than the server. A server MAY use 1098 different security levels for different uses cases (client aliveness, 1099 request freshness, state synchronization, network address 1100 reachability, etc.). 1102 The security provided by the Echo and Request-Tag options depends on 1103 the security protocol used. CoAP and HTTP proxies require (D)TLS to 1104 be terminated at the proxies. The proxies are therefore able to 1105 manipulate, inject, delete, or reorder options or packets. The 1106 security claims in such architectures only hold under the assumption 1107 that all intermediaries are fully trusted and have not been 1108 compromised. 1110 Echo values without the protection of randomness or a MAC are limited 1111 to cases when the client is the trusted source of all derived 1112 properties (as per Section 2.5.2). Using them needs per-application 1113 consideration of both the impact of a malicious client and of 1114 implementation errors in clients. These Echo values are the only 1115 legitimate case for Echo values shorter than four bytes, which are 1116 not necessarily secret. They MUST NOT be used unless the request 1117 Echo values are integrity protected as per Section 2.3. 1119 Servers SHOULD use a monotonic clock to generate timestamps and 1120 compute round-trip times. Use of non-monotonic clocks is not secure 1121 as the server will accept expired Echo option values if the clock is 1122 moved backward. The server will also reject fresh Echo option values 1123 if the clock is moved forward. Non-monotonic clocks MAY be used as 1124 long as they have deviations that are acceptable given the freshness 1125 requirements. If the deviations from a monotonic clock are known, it 1126 may be possible to adjust the threshold accordingly. 1128 An attacker may be able to affect the server's system time in various 1129 ways such as setting up a fake NTP server or broadcasting false time 1130 signals to radio-controlled clocks. 1132 For the purpose of generating timestamps for Echo a server MAY set a 1133 timer at reboot and use the time since reboot, choosing the 1134 granularity such that different requests arrive at different times. 1135 Servers MAY intermittently reset the timer and MAY generate a random 1136 offset applied to all timestamps. When resetting the timer, the 1137 server MUST reject all Echo values that were created before the 1138 reset. 1140 Servers that use the List of Cached Random Values and Timestamps 1141 method described in Appendix A may be vulnerable to resource 1142 exhaustion attacks. One way to minimize state is to use the 1143 Integrity Protected Timestamp method described in Appendix A. 1145 5.1. Token reuse 1147 Reusing Tokens in a way so that responses are guaranteed to not be 1148 associated with the wrong request is not trivial: The server may 1149 process requests in any order, and send multiple responses to the 1150 same request. An attacker may block, delay, and reorder messages. 1151 The use of a sequence number is therefore recommended when CoAP is 1152 used with a security protocol that does not provide bindings between 1153 requests and responses such as DTLS or TLS. 1155 For a generic response to a Confirmable request over DTLS, binding 1156 can only be claimed without out-of-band knowledge if 1158 * the original request was never retransmitted, 1160 * the response was piggybacked in an Acknowledgement message (as a 1161 Confirmable or Non-confirmable response may have been transmitted 1162 multiple times), and 1164 * if observation was used, the same holds for the registration, all 1165 re-registrations, and the cancellation. 1167 (In addition, for observations, any responses using that Token and a 1168 DTLS sequence number earlier than the cancellation Acknowledgement 1169 message need to be discarded. This is typically not supported in 1170 DTLS implementations.) 1172 In some setups, Tokens can be reused without the above constraints, 1173 as a different component in the setup provides the associations: 1175 * In CoAP over TLS, retransmissions are not handled by the CoAP 1176 layer and behaves like a replay window size of 1. When a client 1177 is sending TLS-protected requests without Observe to a single 1178 server, the client can reuse a Token as soon as the previous 1179 response with that Token has been received. 1181 * Requests whose responses are cryptographically bound to the 1182 requests (like in OSCORE) can reuse Tokens indefinitely. 1184 In all other cases, a sequence number approach is RECOMMENDED as per 1185 Section 4. 1187 Tokens that cannot be reused need to be handled appropriately. This 1188 could be solved by increasing the Token as soon as the currently used 1189 Token cannot be reused, or by keeping a list of all Tokens unsuitable 1190 for reuse. 1192 When the Token (or part of the Token) contains a sequence number, the 1193 encoding of the sequence number has to be chosen in a way to avoid 1194 any collisions. This is especially true when the Token contains more 1195 information than just the sequence number, e.g. serialized state as 1196 in [RFC8974]. 1198 6. Privacy Considerations 1200 Implementations SHOULD NOT put any privacy-sensitive information in 1201 the Echo or Request-Tag option values. Unencrypted timestamps could 1202 reveal information about the server such as location or time since 1203 reboot, or that the server will accept expired certificates. 1204 Timestamps MAY be used if Echo is encrypted between the client and 1205 the server, e.g. in the case of DTLS without proxies or when using 1206 OSCORE with an Inner Echo option. 1208 Like HTTP cookies, the Echo option could potentially be abused as a 1209 tracking mechanism that identifies a client across requests. This is 1210 especially true for preemptive Echo values. Servers MUST NOT use the 1211 Echo option to correlate requests for other purposes than freshness 1212 and reachability. Clients only send Echo values to the same server 1213 from which the values were received. Compared to HTTP, CoAP clients 1214 are often authenticated and non-mobile, and servers can therefore 1215 often correlate requests based on the security context, the client 1216 credentials, or the network address. Especially when the Echo option 1217 increases a server's ability to correlate requests, clients MAY 1218 discard all preemptive Echo values. 1220 Publicly visible generated identifiers, even when opaque (as all 1221 defined in this document are), can leak information as described in 1222 [I-D.irtf-pearg-numeric-ids-generation]. To avoid effects described 1223 there, the absent Request-Tag option should be recycled as much as 1224 possible. (That is generally possible as long as a security 1225 mechanism is in place - even in the case of OSCORE outer block-wise 1226 transfers, as the OSCORE option's variation ensures that no matchable 1227 requests are created by different clients). When an unprotected Echo 1228 option is used to demonstrate reachability, the recommended mechanism 1229 of Section 2.3 keeps the effects to a minimum. 1231 7. IANA Considerations 1233 IANA is requested to add the following option numbers to the "CoAP 1234 Option Numbers" registry defined by [RFC7252]: 1236 [ 1238 The editor is asked to suggest the numbers after TBD, as those 1239 satisfy the construction requirements set out in RFC7252: Echo is 1240 NoCacheKey but not Unsafe or Critical, so it needs to end with 11100 1241 in binary representation; Request-Tag has no properties so it needs 1242 to end with 00 and not with 11100). 1244 Request-Tag was picked to not waste the precious space of less-than- 1245 one-byte options, but such that its offset from the Block1 option it 1246 regularly occurs with can still be expressed in an 1-byte offset (27 1247 + (13 + 255) > 292). 1249 Echo was picked to be the shortest it can be in an empty message as a 1250 NoCacheKey option (11100 in binary does not fit in a nibble, and two 1251 lower ones are already taken), and as high as possible to keep room 1252 for other options that might typically occur in pairs and might still 1253 use optimization around low numbers. 1255 ] 1256 +--------+-------------+-------------------+ 1257 | Number | Name | Reference | 1258 +--------+-------------+-------------------+ 1259 | TBD252 | Echo | [[this document]] | 1260 | | | | 1261 | TBD292 | Request-Tag | [[this document]] | 1262 +--------+-------------+-------------------+ 1264 Figure 5: CoAP Option Numbers 1266 8. References 1268 8.1. Normative References 1270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1271 Requirement Levels", BCP 14, RFC 2119, 1272 DOI 10.17487/RFC2119, March 1997, 1273 . 1275 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1276 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1277 January 2012, . 1279 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1280 Application Protocol (CoAP)", RFC 7252, 1281 DOI 10.17487/RFC7252, June 2014, 1282 . 1284 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1285 the Constrained Application Protocol (CoAP)", RFC 7959, 1286 DOI 10.17487/RFC7959, August 2016, 1287 . 1289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1291 May 2017, . 1293 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1294 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1295 2018, . 1297 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1298 "Object Security for Constrained RESTful Environments 1299 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1300 . 1302 8.2. Informative References 1304 [I-D.ietf-core-oscore-groupcomm] 1305 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 1306 and J. Park, "Group OSCORE - Secure Group Communication 1307 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 1308 core-oscore-groupcomm-12, 12 July 2021, 1309 . 1312 [I-D.irtf-pearg-numeric-ids-generation] 1313 Gont, F. and I. Arce, "On the Generation of Transient 1314 Numeric Identifiers", Work in Progress, Internet-Draft, 1315 draft-irtf-pearg-numeric-ids-generation-07, 2 February 1316 2021, . 1319 [I-D.mattsson-core-coap-attacks] 1320 Mattsson, J. P., Fornehed, J., Selander, G., Palombini, 1321 F., and C. Amsüss, "Summarizing Known Attacks on CoAP", 1322 Work in Progress, Internet-Draft, draft-mattsson-core- 1323 coap-attacks-00, 16 May 2021, 1324 . 1327 [REST] Fielding, R., "Architectural Styles and the Design of 1328 Network-based Software Architectures", 2000, 1329 . 1332 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1333 the Constrained Application Protocol (CoAP)", RFC 7390, 1334 DOI 10.17487/RFC7390, October 2014, 1335 . 1337 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1338 Application Protocol (CoAP)", RFC 7641, 1339 DOI 10.17487/RFC7641, September 2015, 1340 . 1342 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1343 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1344 Application Protocol) over TCP, TLS, and WebSockets", 1345 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1346 . 1348 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1349 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1350 . 1352 [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and 1353 Stateless Clients in the Constrained Application Protocol 1354 (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, 1355 . 1357 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1358 Multiplexed and Secure Transport", RFC 9000, 1359 DOI 10.17487/RFC9000, May 2021, 1360 . 1362 Appendix A. Methods for Generating Echo Option Values 1364 The content and structure of the Echo option value are implementation 1365 specific and determined by the server. Two simple mechanisms for 1366 time-based freshness and one for event-based freshness are outlined 1367 in this section, the first is RECOMMENDED in general, and the second 1368 is RECOMMENDED in case the Echo option is encrypted between the 1369 client and the server. 1371 Different mechanisms have different tradeoffs between the size of the 1372 Echo option value, the amount of server state, the amount of 1373 computation, and the security properties offered. A server MAY use 1374 different methods and security levels for different uses cases 1375 (client aliveness, request freshness, state synchronization, network 1376 address reachability, etc.). 1378 1. List of Cached Random Values and Timestamps. The Echo option 1379 value is a (pseudo-)random byte string called r. The server caches a 1380 list containing the random byte strings and their transmission times. 1381 Assuming 72-bit random values and 32-bit timestamps, the size of the 1382 Echo option value is 9 bytes and the amount of server state is 13n 1383 bytes, where n is the number of active Echo Option values. The 1384 security against an attacker guessing echo values is given by s = bit 1385 length of r - log2(n). The length of r and the maximum allowed n 1386 should be set so that the security level is harmonized with other 1387 parts of the deployment, e.g., s >= 64. If the server loses time 1388 continuity, e.g. due to reboot, the entries in the old list MUST be 1389 deleted. 1391 Echo option value: random value r 1392 Server State: random value r, timestamp t0 1394 This method is suitable both for time and for event base freshness 1395 (e.g. by clearing the cache when an event occurs), and independent of 1396 the client authority. 1398 2. Integrity Protected Timestamp. The Echo option value is an 1399 integrity protected timestamp. The timestamp can have different 1400 resolution and range. A 32-bit timestamp can e.g. give a resolution 1401 of 1 second with a range of 136 years. The (pseudo-)random secret 1402 key is generated by the server and not shared with any other party. 1403 The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit 1404 timestamp and a 64-bit MAC, the size of the Echo option value is 12 1405 bytes and the Server state is small and constant. The security 1406 against an attacker guessing echo values is given by the MAC length. 1407 If the server loses time continuity, e.g. due to reboot, the old key 1408 MUST be deleted and replaced by a new random secret key. Note that 1409 the privacy considerations in Section 6 may apply to the timestamp. 1410 Therefore, it might be important to encrypt it. Depending on the 1411 choice of encryption algorithms, this may require a nonce to be 1412 included in the Echo option value. 1414 Echo option value: timestamp t0, MAC(k, t0) 1415 Server State: secret key k 1417 This method is suitable both for time and for event based freshness 1418 (by the server remembering the time at which the event took place), 1419 and independent of the client authority. 1421 If this method is used to additionally obtain network reachability of 1422 the client, the server MUST use the client's network address too, 1423 e.g. as in "MAC(k, t0, apparent network address)". 1425 3. Persistent Counter. This can be used in OSCORE for sequence 1426 number recovery per Appendix B.1.2 of [RFC8613]. The Echo option 1427 value is a simple counter without integrity protection of its own, 1428 serialized in uint format. The counter is incremented in a 1429 persistent way every time the state that needs to be synchronized is 1430 changed (in the B.1.2 case: when a reboot indicates that volatile 1431 state may have been lost). An example of how such a persistent 1432 counter can be implemented efficiently is the OSCORE server Sender 1433 Sequence Number mechanism described in Appendix B.1.1 of [RFC8613]. 1435 Echo option value: counter 1436 Server State: counter 1438 This method is suitable only if the client is the authority over the 1439 synchronized property. Consequently, it cannot be used to show 1440 client aliveness. It provides statements from the client similar to 1441 event based freshness (but without a proof of freshness). 1443 Other mechanisms complying with the security and privacy 1444 considerations may be used. The use of encrypted timestamps in the 1445 Echo option increases security, but typically requires an IV 1446 (Initialization Vector) to be included in the Echo option value, 1447 which adds overhead and makes the specification of such a mechanism 1448 slightly more complicated than what is described here. 1450 Appendix B. Request-Tag Message Size Impact 1452 In absence of concurrent operations, the Request-Tag mechanism for 1453 body integrity (Section 3.5.1) incurs no overhead if no messages are 1454 lost (more precisely: in OSCORE, if no operations are aborted due to 1455 repeated transmission failure; in DTLS, if no packets are lost and 1456 replay protection is active), or when block-wise request operations 1457 happen rarely (in OSCORE, if there is always only one request block- 1458 wise operation in the replay window). 1460 In those situations, no message has any Request-Tag option set, and 1461 that can be recycled indefinitely. 1463 When the absence of a Request-Tag option cannot be recycled any more 1464 within a security context, the messages with a present but empty 1465 Request-Tag option can be used (1 Byte overhead), and when that is 1466 used-up, 256 values from one byte long options (2 Bytes overhead) are 1467 available. 1469 In situations where those overheads are unacceptable (e.g. because 1470 the payloads are known to be at a fragmentation threshold), the 1471 absent Request-Tag value can be made usable again: 1473 * In DTLS, a new session can be established. 1475 * In OSCORE, the sequence number can be artificially increased so 1476 that all lost messages are outside of the replay window by the 1477 time the first request of the new operation gets processed, and 1478 all earlier operations can therefore be regarded as concluded. 1480 Appendix C. Change Log 1482 [ The editor is asked to remove this section before publication. ] 1484 * Changes since draft-ietf-core-echo-request-tag-12 (addressing 1485 comments from IESG review) 1487 See CoRE point-to-point responses at https://github.com/core-wg/ 1488 echo-request-tag/blob/master/point-to-point.md 1489 (https://github.com/core-wg/echo-request-tag/blob/master/point-to- 1490 point.md) and on CoRE mailing list. 1492 * Changes since draft-ietf-core-echo-request-tag-11 (addressing 1493 GenART, TSVART, OpsDir comments) 1494 - Explain the size permissible for responses before amplification 1495 mitigation by referring to the QUIC draft for an OK factor, and 1496 giving the remaining numbers that led to it. The actual number 1497 is reduced from 152 to 136 because the more conservative case 1498 of the attacker not sending a token is considered now. 1500 - Added a definition for "freshness" 1502 - Give more concrete example values in figures 2 and 3 (based on 1503 the appendix suggestions), highlighting the differences between 1504 the figures by telling how they are processed in the examples. 1506 - Figure with option summary: E/U columns removed (for duplicate 1507 headers and generally not contributing) 1509 - MAY capitalization changed for consistency. 1511 - Editorial changes (IV acronym expanded, s/can not/cannot/g) 1513 - Draft ietf-core-stateless has become RFC8974 1515 * Changes since draft-ietf-core-echo-request-tag-10 (Barry's 1516 comments) 1518 - Align terminology on attacker 1520 - A number of clarifications and editorial fixes 1522 - Promote DTLS and OSCORE to normative references 1524 - Add counter-based version to the Methods for Generating Echo 1525 Option Values appendix 1527 - Use 64-bit randomness recommendation throughout (but keep it as 1528 SHOULD so applications with strict requirements can reduce if 1529 if really needed) 1531 - Speling and Capitalization 1533 * Changes since draft-ietf-core-echo-request-tag-09: 1535 - Allow intermediaries to do Echo processing, provided they ask 1536 at least as much freshness as they forward 1538 - Emphasize that clients can forget Echo to further discourage 1539 abuse as cookies 1541 - Emphasize that RESTful application design can avoid the need 1542 for a Request-Tag 1544 - Align with core-oscore-groupcomm-09 1546 - Add interaction with HTTP Early Data / 425 Too Early 1548 - Abstract: Explicitly mention both updates to 7252 1550 - Change requested option number of Echo to 252 (previous 1551 property calculation was erroneous) 1553 * Changes since draft-ietf-core-echo-request-tag-08: 1555 - Make amplification attack mitigation by Echo an RFC7252 1556 updating recommendation 1558 - Give some more concrete guidance to that use case in terms of 1559 sizes and message types 1561 - Allow short (1-3 byte) Echo values for deterministic cases, 1562 with according security considerations 1564 - Point out the tricky parts around Request-Tag for stateless 1565 proxies, and make that purely an outlook example with out-of- 1566 scope details 1568 - Lift ban on Request-Tag options without Block1 (as they can 1569 legitimately be generated by an unaware proxy) 1571 - Suggest concrete numbers for the options 1573 * Changes since draft-ietf-core-echo-request-tag-07 (largely 1574 addressing Francesca's review): 1576 - Request tag: Explicitly limit "MUST NOT recycle" requirement to 1577 particular applications 1579 - Token reuse: upper-case RECOMMEND sequence number approach 1581 - Structure: Move per-topic introductions to respective chapters 1582 (this avoids long jumps by the reader) 1584 - Structure: Group Block2 / ETag section inside new fragmentation 1585 (formerly Request-Tag) section 1587 - More precise references into other documents 1588 - "concurrent operations": Emphasise that all here only matters 1589 between endpoint pairs 1591 - Freshness: Generalize wording away from time-based freshness 1593 - Echo: Emphasise that no binding between any particular pair of 1594 responses and requests is established 1596 - Echo: Add event-based example 1598 - Echo: Clarify when protection is needed 1600 - Request tag: Enhance wording around "not sufficient condition" 1602 - Request tag: Explicitly state when a tag needs to be set 1604 - Request tag: Clarification about permissibility of leaving the 1605 option absent 1607 - Security considerations: wall clock time -> system time (and 1608 remove inaccurate explanations) 1610 - Token reuse: describe deny-listing in a more implementation- 1611 independent way 1613 * Changes since draft-ietf-core-echo-request-tag-06: 1615 - Removed visible comment that should not be visible in Token 1616 reuse considerations. 1618 * Changes since draft-ietf-core-echo-request-tag-05: 1620 - Add privacy considerations on cookie-style use of Echo values 1622 - Add security considerations for token reuse 1624 - Add note in security considerations on use of nonvolatile 1625 memory when dealing with pseudorandom numbers 1627 - Appendix on echo generation: add a few words on up- and 1628 downsides of the encrypted timestamp alternative 1630 - Clarifications around Outer Echo: 1632 o Could be generated by the origin server to prove network 1633 reachability (but for most applications it MUST be inner) 1635 o Could be generated by intermediaries 1636 o Is answered by the client to the endpoint from which it 1637 received it (ie. Outer if received as Outer) 1639 - Clarification that a server can send Echo preemtively 1641 - Refer to stateless to explain what "more information than just 1642 the sequence number" could be 1644 - Remove explanations around 0.00 empty messags 1646 - Rewordings: 1648 o the attack: from "forging" to "guessing" 1650 o "freshness tokens" to "freshness indicators" (to avoid 1651 confusion with the Token) 1653 - Editorial fixes: 1655 o Abstract and introduction mention what is updated in RFC7252 1657 o Reference updates 1659 o Capitalization, spelling, terms from other documents 1661 * Changes since draft-ietf-core-echo-request-tag-04: 1663 - Editorial fixes 1665 o Moved paragraph on collision-free encoding of data in the 1666 Token to Security Considerations and rephrased it 1668 o "easiest" -> "one easy" 1670 * Changes since draft-ietf-core-echo-request-tag-03: 1672 - Mention Token processing changes in title 1674 - Abstract reworded 1676 - Clarify updates to Token processing 1678 - Describe security levels from Echo length 1680 - Allow non-monotonic clocks under certain conditions for 1681 freshness 1683 - Simplify freshness expressions 1684 - Describe when a Request-Tag can be set 1686 - Add note on application-level freshness mechanisms 1688 - Minor editorial changes 1690 * Changes since draft-ietf-core-echo-request-tag-02: 1692 - Define "freshness" 1694 - Note limitations of "aliveness" 1696 - Clarify proxy and OSCORE handling in presence of "echo" 1698 - Clarify when Echo values may be reused 1700 - Update security considerations 1702 - Various minor clarifications 1704 - Minor editorial changes 1706 * Major changes since draft-ietf-core-echo-request-tag-01: 1708 - Follow-up changes after the "relying on block-wise" change in 1709 -01: 1711 o Simplify the description of Request-Tag and matchability 1713 o Do not update RFC7959 any more 1715 - Make Request-Tag repeatable. 1717 - Add rationale on not relying purely on sequence numbers. 1719 * Major changes since draft-ietf-core-echo-request-tag-00: 1721 - Reworded the Echo section. 1723 - Added rules for Token processing. 1725 - Added security considerations. 1727 - Added actual IANA section. 1729 - Made Request-Tag optional and safe-to-forward, relying on 1730 block-wise to treat it as part of the cache-key 1732 - Dropped use case about OSCORE Outer-block-wise (the case went 1733 away when its Partial IV was moved into the Object-Security 1734 option) 1736 * Major changes since draft-amsuess-core-repeat-request-tag-00: 1738 - The option used for establishing freshness was renamed from 1739 "Repeat" to "Echo" to reduce confusion about repeatable 1740 options. 1742 - The response code that goes with Echo was changed from 4.03 to 1743 4.01 because the client needs to provide better credentials. 1745 - The interaction between the new option and (cross) proxies is 1746 now covered. 1748 - Two messages being "Request-Tag matchable" was introduced to 1749 replace the older concept of having a request tag value with 1750 its slightly awkward equivalence definition. 1752 Acknowledgments 1754 The authors want to thank Carsten Bormann, Francesca Palombini, and 1755 Jim Schaad for providing valuable input to the draft. 1757 Authors' Addresses 1759 Christian Amsüss 1761 Email: christian@amsuess.com 1763 John Preuß Mattsson 1764 Ericsson AB 1766 Email: john.mattsson@ericsson.com 1768 Göran Selander 1769 Ericsson AB 1771 Email: goran.selander@ericsson.com