idnits 2.17.1 draft-ietf-core-echo-request-tag-12.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 3 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 (1 February 2021) is 1179 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-10 Summary: 1 error (**), 0 flaws (~~), 3 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: 5 August 2021 Ericsson AB 7 1 February 2021 9 CoAP: Echo, Request-Tag, and Token Processing 10 draft-ietf-core-echo-request-tag-12 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 RFC7252 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 5 August 2021. 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 3. Protecting Message Bodies using Request Tags . . . . . . . . 12 79 3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 12 80 3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 13 81 3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 13 82 3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 14 83 3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 15 84 3.5. Applications of the Request-Tag Option . . . . . . . . . 16 85 3.5.1. Body Integrity Based on Payload Integrity . . . . . . 16 86 3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 17 87 3.5.3. Simplified Block-Wise Handling for Constrained 88 Proxies . . . . . . . . . . . . . . . . . . . . . . . 18 89 3.6. Rationale for the Option Properties . . . . . . . . . . . 18 90 3.7. Rationale for Introducing the Option . . . . . . . . . . 19 91 3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 19 92 4. Token Processing for Secure Request-Response Binding . . . . 19 93 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 19 94 4.2. Updated Token Processing Requirements for Clients . . . . 20 96 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 97 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 22 98 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 102 8.2. Informative References . . . . . . . . . . . . . . . . . 25 103 Appendix A. Methods for Generating Echo Option Values . . . . . 26 104 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 28 105 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 28 106 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 109 1. Introduction 111 The initial Constrained Application Protocol (CoAP) suite of 112 specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed 113 with the assumption that security could be provided on a separate 114 layer, in particular by using DTLS ([RFC6347]). However, for some 115 use cases, additional functionality or extra processing is needed to 116 support secure CoAP operations. This document specifies security 117 enhancements to the Constrained Application Protocol (CoAP). 119 This document specifies two CoAP options, the Echo option and the 120 Request-Tag option: The Echo option enables a CoAP server to verify 121 the freshness of a request, synchronize state, or force a client to 122 demonstrate reachability at its claimed network address. The 123 Request-Tag option allows the CoAP server to match message fragments 124 belonging to the same request, fragmented using the CoAP block-wise 125 Transfer mechanism, which mitigates attacks and enables concurrent 126 block-wise operations. These options in themselves do not replace 127 the need for a security protocol; they specify the format and 128 processing of data which, when integrity protected using e.g. DTLS 129 ([RFC6347]), TLS ([RFC8446]), or OSCORE ([RFC8613]), provide the 130 additional security features. 132 This document updates [RFC7252] with a recommendation that servers 133 use the Echo option to mitigate amplification attacks. 135 The document also updates the Token processing requirements for 136 clients specified in [RFC7252]. The updated processing forbids non- 137 secure reuse of Tokens to ensure binding of responses to requests 138 when CoAP is used with security, thus mitigating error cases and 139 attacks where the client may erroneously associate the wrong response 140 to a request. 142 Each of the following sections provides a more detailed introduction 143 to the topic at hand in its first subsection. 145 1.1. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 Like [RFC7252], this document is relying on the Representational 154 State Transfer [REST] architecture of the Web. 156 Unless otherwise specified, the terms "client" and "server" refer to 157 "CoAP client" and "CoAP server", respectively, as defined in 158 [RFC7252]. The term "origin server" is used as in [RFC7252]. The 159 term "origin client" is used in this document to denote the client 160 from which a request originates; to distinguish from clients in 161 proxies. 163 A message's "freshness" is a measure of when a message was sent on a 164 time scale of the recipient. A server that receives a request can 165 either verify that the request is fresh or determine that it cannot 166 be verified that the request is fresh. What is considered a fresh 167 message is application dependent; examplary uses are "no more than 168 one hour ago" or "after this server's last reboot". 170 The terms "payload" and "body" of a message are used as in [RFC7959]. 171 The complete interchange of a request and a response body is called a 172 (REST) "operation". An operation fragmented using [RFC7959] is 173 called a "block-wise operation". A block-wise operation which is 174 fragmenting the request body is called a "block-wise request 175 operation". A block-wise operation which is fragmenting the response 176 body is called a "block-wise response operation". 178 Two request messages are said to be "matchable" if they occur between 179 the same endpoint pair, have the same code, and have the same set of 180 options, with the exception that elective NoCacheKey options and 181 options involved in block-wise transfer (Block1, Block2 and Request- 182 Tag) need not be the same. Two operations are said to be matchable 183 if any of their messages are. 185 Two matchable block-wise operations are said to be "concurrent" if a 186 block of the second request is exchanged even though the client still 187 intends to exchange further blocks in the first operation. 188 (Concurrent block-wise request operations from a single endpoint are 189 impossible with the options of [RFC7959] (see the last paragraphs of 190 Sections 2.4 and 2.5) because the second operation's block overwrites 191 any state of the first exchange.). 193 The Echo and Request-Tag options are defined in this document. 195 2. Request Freshness and the Echo Option 197 2.1. Request Freshness 199 A CoAP server receiving a request is in general not able to verify 200 when the request was sent by the CoAP client. This remains true even 201 if the request was protected with a security protocol, such as DTLS. 202 This makes CoAP requests vulnerable to certain delay attacks which 203 are particularly perilous in the case of actuators 204 ([I-D.mattsson-core-coap-actuators]). Some attacks can be mitigated 205 by establishing fresh session keys, e.g. performing a DTLS handshake 206 for each request, but in general this is not a solution suitable for 207 constrained environments, for example, due to increased message 208 overhead and latency. Additionally, if there are proxies, fresh DTLS 209 session keys between server and proxy does not say anything about 210 when the client made the request. In a general hop-by-hop setting, 211 freshness may need to be verified in each hop. 213 A straightforward mitigation of potential delayed requests is that 214 the CoAP server rejects a request the first time it appears and asks 215 the CoAP client to prove that it intended to make the request at this 216 point in time. 218 2.2. The Echo Option 220 This document defines the Echo option, a lightweight challenge- 221 response mechanism for CoAP that enables a CoAP server to verify the 222 freshness of a request. A fresh request is one whose age has not yet 223 exceeded the freshness requirements set by the server. The freshness 224 requirements are application specific and may vary based on resource, 225 method, and parameters outside of CoAP such as policies. The Echo 226 option value is a challenge from the server to the client included in 227 a CoAP response and echoed back to the server in one or more CoAP 228 requests. The Echo option provides a convention to transfer 229 freshness indicators that works for all CoAP methods and response 230 codes. 232 This mechanism is not only important in the case of actuators, or 233 other use cases where the CoAP operations require freshness of 234 requests, but also in general for synchronizing state between CoAP 235 client and server, cryptographically verifying the aliveness of the 236 client, or forcing a client to demonstrate reachability at its 237 claimed network address. The same functionality can be provided by 238 echoing freshness indicators in CoAP payloads, but this only works 239 for methods and response codes defined to have a payload. The Echo 240 option provides a convention to transfer freshness indicators that 241 works for all methods and response codes. 243 2.2.1. Echo Option Format 245 The Echo Option is elective, safe-to-forward, not part of the cache- 246 key, and not repeatable, see Figure 1, which extends Table 4 of 247 [RFC7252]). 249 +--------+---+---+---+---+-------------+--------+------+---------+ 250 | No. | C | U | N | R | Name | Format | Len. | Default | 251 +--------+---+---+---+---+-------------+--------+------+---------+ 252 | TBD252 | | | x | | Echo | opaque | 1-40 | (none) | 253 +--------+---+---+---+---+-------------+--------+------+---------+ 255 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 257 Figure 1: Echo Option Summary 259 The Echo option value is generated by a server, and its content and 260 structure are implementation specific. Different methods for 261 generating Echo option values are outlined in Appendix A. Clients 262 and intermediaries MUST treat an Echo option value as opaque and make 263 no assumptions about its content or structure. 265 When receiving an Echo option in a request, the server MUST be able 266 to verify that the Echo option value (a) was generated by the server 267 or some other party that the server trusts, and (b) fulfills the 268 freshness requirements of the application. Depending on the 269 freshness requirements the server may verify exactly when the Echo 270 option value was generated (time-based freshness) or verify that the 271 Echo option was generated after a specific event (event-based 272 freshness). As the request is bound to the Echo option value, the 273 server can determine that the request is not older that the Echo 274 option value. 276 When the Echo option is used with OSCORE [RFC8613] it MAY be an Inner 277 or Outer option, and the Inner and Outer values are independent. 278 OSCORE servers MUST only produce Inner Echo options unless they are 279 merely testing for reachability of the client (the same as proxies 280 may do). The Inner option is encrypted and integrity protected 281 between the endpoints, whereas the Outer option is not protected by 282 OSCORE and visible between the endpoints to the extent it is not 283 protected by some other security protocol. E.g. in the case of DTLS 284 hop-by-hop between the endpoints, the Outer option is visible to 285 proxies along the path. 287 2.3. Echo Processing 289 The Echo option MAY be included in any request or response (see 290 Section 2.4 for different applications). 292 The application decides under what conditions a CoAP request to a 293 resource is required to be fresh. These conditions can for example 294 include what resource is requested, the request method and other data 295 in the request, and conditions in the environment such as the state 296 of the server or the time of the day. 298 If a certain request is required to be fresh, the request does not 299 contain a fresh Echo option value, and the server cannot verify the 300 freshness of the request in some other way, the server MUST NOT 301 process the request further and SHOULD send a 4.01 Unauthorized 302 response with an Echo option. The server MAY include the same Echo 303 option value in several different response messages and to different 304 clients. Examples of this could be time-based freshness when several 305 responses are sent closely after each other or event-based freshness 306 with no event taking place between the responses. 308 The server may use request freshness provided by the Echo option to 309 verify the aliveness of a client or to synchronize state. The server 310 may also include the Echo option in a response to force a client to 311 demonstrate reachability at its claimed network address. Note that 312 the Echo option does not bind a request to any particular previous 313 response, but provides an indication that the client had access to 314 the previous response at the time when it created the request. 316 Upon receiving a 4.01 Unauthorized response with the Echo option, the 317 client SHOULD resend the original request with the addition of an 318 Echo option with the received Echo option value. The client MAY send 319 a different request compared to the original request. Upon receiving 320 any other response with the Echo option, the client SHOULD echo the 321 Echo option value in the next request to the server. The client MAY 322 include the same Echo option value in several different requests to 323 the server. 325 A client MUST only send Echo values to endpoints it received them 326 from (where as defined in [RFC7252] Section 1.2, the security 327 association is part of the endpoint). In OSCORE processing, that 328 means sending Echo values from Outer options (or from non-OSCORE 329 responses) back in Outer options, and those from Inner options in 330 Inner options in the same security context. 332 Upon receiving a request with the Echo option, the server determines 333 if the request is required to be fresh. If not, the Echo option MAY 334 be ignored. If the request is required to be fresh and the server 335 cannot verify the freshness of the request in some other way, the 336 server MUST use the Echo option to verify that the request is fresh. 337 If the server cannot verify that the request is fresh, the request is 338 not processed further, and an error message MAY be sent. The error 339 message SHOULD include a new Echo option. 341 One way for the server to verify freshness is to bind the Echo value 342 to a specific point in time and verify that the request is not older 343 than a certain threshold T. The server can verify this by checking 344 that (t1 - t0) < T, where t1 is the request receive time and t0 is 345 the time when the Echo option value was generated. An example 346 message flow is shown in Figure 2. 348 Client Server 349 | | 350 +------>| Code: 0.03 (PUT) 351 | PUT | Token: 0x41 352 | | Uri-Path: lock 353 | | Payload: 0 (Unlock) 354 | | 355 |<------+ Code: 4.01 (Unauthorized) 356 | 4.01 | Token: 0x41 357 | | Echo: 0x00000009437468756c687521 (t0 = 9, +MAC) 358 | | 359 | ... | The round trips take 1 second, time is now t1 = 10. 360 | | 361 +------>| Code: 0.03 (PUT) 362 | PUT | Token: 0x42 363 | | Uri-Path: lock 364 | | Echo: 0x00000009437468756c687521 (t0 = 9, +MAC) 365 | | Payload: 0 (Unlock) 366 | | 367 | | Verify MAC, compare t1 - t0 = 1 < T => permitted. 368 | | 369 |<------+ Code: 2.04 (Changed) 370 | 2.04 | Token: 0x42 371 | | 373 Figure 2: Example Message Flow for Time-Based Freshness using the 374 'Integrity Protected Timestamp' construction of Appendix A 376 Another way for the server to verify freshness is to maintain a cache 377 of values associated to events. The size of the cache is defined by 378 the application. In the following we assume the cache size is 1, in 379 which case freshness is defined as no new event has taken place. At 380 each event a new value is written into the cache. The cache values 381 MUST be different for all practical purposes. The server verifies 382 freshness by checking that e0 equals e1, where e0 is the cached value 383 when the Echo option value was generated, and e1 is the cached value 384 at the reception of the request. An example message flow is shown in 385 Figure 3. 387 Client Server 388 | | 389 +------>| Code: 0.03 (PUT) 390 | PUT | Token: 0x41 391 | | Uri-Path: lock 392 | | Payload: 0 (Unlock) 393 | | 394 |<------+ Code: 4.01 (Unauthorized) 395 | 4.01 | Token: 0x41 396 | | Echo: 0x05 (e0 = 5, number of total lock 397 | | operations performed) 398 | | 399 | ... | No alterations happen to the lock state, e1 has the 400 | | same value e1 = 5. 401 | | 402 +------>| Code: 0.03 (PUT) 403 | PUT | Token: 0x42 404 | | Uri-Path: lock 405 | | Echo: 0x05 406 | | Payload: 0 (Unlock) 407 | | 408 | | Compare e1 = e0 => permitted. 409 | | 410 |<------+ Code: 2.04 (Changed) 411 | 2.04 | Token: 0x42 412 | | Echo: 0x06 (e2 = 6, to allow later locking 413 | | without more round-trips) 414 | | 416 Figure 3: Example Message Flow for Event-Based Freshness using 417 the 'Persistent Counter' construction of Appendix A 419 When used to serve freshness requirements (including client aliveness 420 and state synchronizing), the Echo option value MUST be integrity 421 protected between the intended endpoints, e.g. using DTLS, TLS, or an 422 OSCORE Inner option ([RFC8613]). When used to demonstrate 423 reachability at a claimed network address, the Echo option SHOULD 424 contain the client's network address, but MAY be unprotected. 426 A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on 427 forwarded ones that had no Echo option or ones generated by the proxy 428 (from cache or as an error). If it does so, it MUST remove the Echo 429 option it recognizes as one generated by itself on follow-up 430 requests. When it receives an Echo option in a response, it MAY 431 forward it to the client (and, not recognizing it as an own in future 432 requests, relay it in the other direction as well) or process it on 433 its own. If it does so, it MUST ensure that the client's request was 434 generated (or is re-generated) after the Echo value used to send to 435 the server was first seen. (In most cases, this means that the proxy 436 needs to ask the client to repeat the request with a new Echo value.) 438 The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, 439 especially if they have reason to assume that access may require it 440 (e.g. because it is a PUT or POST); how this is determined is out of 441 scope for this document. The CoAP client side of HTTP-to-CoAP 442 proxies SHOULD respond to Echo challenges themselves if they know 443 from the recent establishing of the connection that the HTTP request 444 is fresh. Otherwise, they SHOULD respond with 503 Service 445 Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive 446 connection. If the HTTP request arrived in Early Data, the proxy 447 SHOULD use a 425 Too Early response instead (see [RFC8470]). They 448 MAY also use other mechanisms to establish freshness of the HTTP 449 request that are not specified here. 451 2.4. Applications of the Echo Option 453 1. Actuation requests often require freshness guarantees to avoid 454 accidental or malicious delayed actuator actions. In general, 455 all non-safe methods (e.g. POST, PUT, DELETE) may require 456 freshness guarantees for secure operation. 458 * The same Echo value may be used for multiple actuation 459 requests to the same server, as long as the total round-trip 460 time since the Echo option value was generated is below the 461 freshness threshold. 463 * For actuator applications with low delay tolerance, to avoid 464 additional round-trips for multiple requests in rapid 465 sequence, the server may include the Echo option with a new 466 value even in a successful response to a request, 467 irrespectively of whether the request contained an Echo option 468 or not. The client then uses the Echo option with the new 469 value in the next actuation request, and the server compares 470 the receive time accordingly. 472 2. A server may use the Echo option to synchronize properties (such 473 as state or time) with a requesting client. A server MUST NOT 474 synchronize a property with a client which is not the authority 475 of the property being synchronized. E.g. if access to a server 476 resource is dependent on time, then server MUST NOT synchronize 477 time with a client requesting access unless it is time authority 478 for the server. 480 * If a server reboots during operation it may need to 481 synchronize state or time before continuing the interaction. 482 For example, with OSCORE it is possible to reuse a partly 483 persistently stored security context by synchronizing the 484 Partial IV (sequence number) using the Echo option, see 485 Section 7.5 of [RFC8613]. 487 * A device joining a CoAP group communication [RFC7390] 488 protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be 489 required to initially verify freshness and synchronize state 490 or time with a client by using the Echo option in a unicast 491 response to a multicast request. The client receiving the 492 response with the Echo option includes the Echo value in a 493 subsequent unicast request to the responding server. 495 3. A server that sends large responses to unauthenticated peers 496 SHOULD mitigate amplification attacks such as described in 497 Section 11.3 of [RFC7252] (where an attacker would put a victim's 498 address in the source address of a CoAP request). The 499 RECOMMENDED way to do this is to ask a client to Echo its request 500 to verify its source address. This needs to be done only once 501 per peer and limits the range of potential victims from the 502 general Internet to endpoints that have been previously in 503 contact with the server. For this application, the Echo option 504 can be used in messages that are not integrity protected, for 505 example during discovery. 507 * In the presence of a proxy, a server will not be able to 508 distinguish different origin client endpoints. Following from 509 the recommendation above, a proxy that sends large responses 510 to unauthenticated peers SHOULD mitigate amplification 511 attacks. The proxy SHOULD use Echo to verify origin 512 reachability as described in Section 2.3. The proxy MAY 513 forward idempotent requests immediately to have a cached 514 result available when the client's Echoed request arrives. 516 * Amplification mitigation is a trade-off between giving 517 leverage to an attacker and causing overheads. An 518 amplification factor of 3 (i.e., don't send more than three 519 times the number of bytes received until the peer's address is 520 confirmed) is considered acceptable for unconstrained 521 applications [I-D.ietf-quic-transport]. 523 When that limit is applied and no further context is 524 available, a safe default is sending initial responses no 525 larger than 136 Bytes in CoAP serialization. (The number is 526 assuming a 14 + 40 + 8 Bytes Ethernet, IP and UDP header with 527 4 Bytes added for the CoAP header. Triple that minus the non- 528 CoAP headers gives the 136 Bytes). Given the token also takes 529 up space in the request, responding with 132 Bytes after the 530 token is safe as well. 532 * When an Echo response is sent to mitigate amplification, it 533 MUST be sent as a piggybacked or Non-confirmable response, 534 never as a separate one (which would cause amplification due 535 to retransmission). 537 4. A server may want to use the request freshness provided by the 538 Echo to verify the aliveness of a client. Note that in a 539 deployment with hop-by-hop security and proxies, the server can 540 only verify aliveness of the closest proxy. 542 3. Protecting Message Bodies using Request Tags 544 3.1. Fragmented Message Body Integrity 546 CoAP was designed to work over unreliable transports, such as UDP, 547 and include a lightweight reliability feature to handle messages 548 which are lost or arrive out of order. In order for a security 549 protocol to support CoAP operations over unreliable transports, it 550 must allow out-of-order delivery of messages using e.g. a sliding 551 replay window such as described in Section 4.1.2.6 of DTLS 552 ([RFC6347]). 554 The block-wise transfer mechanism [RFC7959] extends CoAP by defining 555 the transfer of a large resource representation (CoAP message body) 556 as a sequence of blocks (CoAP message payloads). The mechanism uses 557 a pair of CoAP options, Block1 and Block2, pertaining to the request 558 and response payload, respectively. The block-wise functionality 559 does not support the detection of interchanged blocks between 560 different message bodies to the same resource having the same block 561 number. This remains true even when CoAP is used together with a 562 security protocol such as DTLS or OSCORE, within the replay window 563 ([I-D.mattsson-core-coap-actuators]), which is a vulnerability of 564 CoAP when using RFC7959. 566 A straightforward mitigation of mixing up blocks from different 567 messages is to use unique identifiers for different message bodies, 568 which would provide equivalent protection to the case where the 569 complete body fits into a single payload. The ETag option [RFC7252], 570 set by the CoAP server, identifies a response body fragmented using 571 the Block2 option. 573 3.2. The Request-Tag Option 575 This document defines the Request-Tag option for identifying request 576 bodies, similar to ETag, but ephemeral and set by the CoAP client. 577 The Request-Tag is intended for use as a short-lived identifier for 578 keeping apart distinct block-wise request operations on one resource 579 from one client, addressing the issue described in Section 3.1. It 580 enables the receiving server to reliably assemble request payloads 581 (blocks) to their message bodies, and, if it chooses to support it, 582 to reliably process simultaneous block-wise request operations on a 583 single resource. The requests must be integrity protected if they 584 should protect against interchange of blocks between different 585 message bodies. The Request-Tag option is only used in requests that 586 carry the Block1 option, and in Block2 requests following these. 588 In essence, it is an implementation of the "proxy-safe elective 589 option" used just to "vary the cache key" as suggested in [RFC7959] 590 Section 2.4. 592 3.2.1. Request-Tag Option Format 594 The Request-Tag option is not critical, is safe to forward, 595 repeatable, and part of the cache key, see Figure 4, which extends 596 Table 4 of [RFC7252]). 598 +--------+---+---+---+---+-------------+--------+------+---------+ 599 | No. | C | U | N | R | Name | Format | Len. | Default | 600 +--------+---+---+---+---+-------------+--------+------+---------+ 601 | TBD292 | | | | x | Request-Tag | opaque | 0-8 | (none) | 602 +--------+---+---+---+---+-------------+--------+------+---------+ 604 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 606 Figure 4: Request-Tag Option Summary 608 Request-Tag, like the block options, is both a class E and a class U 609 option in terms of OSCORE processing (see Section 4.1 of [RFC8613]): 610 The Request-Tag MAY be an Inner or Outer option. It influences the 611 Inner or Outer block operation, respectively. The Inner and Outer 612 values are therefore independent of each other. The Inner option is 613 encrypted and integrity protected between client and server, and 614 provides message body identification in case of end-to-end 615 fragmentation of requests. The Outer option is visible to proxies 616 and labels message bodies in case of hop-by-hop fragmentation of 617 requests. 619 The Request-Tag option is only used in the request messages of block- 620 wise operations. 622 The Request-Tag mechanism can be applied independently on the server 623 and client sides of CoAP-to-CoAP proxies as are the block options, 624 though given it is safe to forward, a proxy is free to just forward 625 it when processing an operation. CoAP-to-HTTP proxies and HTTP-to- 626 CoAP proxies can use Request-Tag on their CoAP sides; it is not 627 applicable to HTTP requests. 629 3.3. Request-Tag Processing by Servers 631 The Request-Tag option does not require any particular processing on 632 the server side outside of the processing already necessary for any 633 unknown elective proxy-safe cache-key option: The option varies the 634 properties that distinguish block-wise operations (which includes all 635 options except elective NoCacheKey and except Block1/2), and thus the 636 server cannot treat messages with a different list of Request-Tag 637 options as belonging to the same operation. 639 To keep utilizing the cache, a server (including proxies) MAY discard 640 the Request-Tag option from an assembled block-wise request when 641 consulting its cache, as the option relates to the operation-on-the- 642 wire and not its semantics. For example, a FETCH request with the 643 same body as an older one can be served from the cache if the older's 644 Max-Age has not expired yet, even if the second operation uses a 645 Request-Tag and the first did not. (This is similar to the situation 646 about ETag in that it is formally part of the cache key, but 647 implementations that are aware of its meaning can cache more 648 efficiently, see [RFC7252] Section 5.4.2). 650 A server receiving a Request-Tag MUST treat it as opaque and make no 651 assumptions about its content or structure. 653 Two messages carrying the same Request-Tag is a necessary but not 654 sufficient condition for being part of the same operation. For one, 655 a server may still treat them as independent messages when it sends 656 2.01/2.04 responses for every block. Also, a client that lost 657 interest in an old operation but wants to start over can overwrite 658 the server's old state with a new initial (num=0) Block1 request and 659 the same Request-Tag under some circumstances. Likewise, that 660 results in the new message not being part of the old operation. 662 As it has always been, a server that can only serve a limited number 663 of block-wise operations at the same time can delay the start of the 664 operation by replying with 5.03 (Service unavailable) and a Max-Age 665 indicating how long it expects the existing operation to go on, or it 666 can forget about the state established with the older operation and 667 respond with 4.08 (Request Entity Incomplete) to later blocks on the 668 first operation. 670 3.4. Setting the Request-Tag 672 For each separate block-wise request operation, the client can choose 673 a Request-Tag value, or choose not to set a Request-Tag. It needs to 674 be set to the same value (or unset) in all messages belonging to the 675 same operation, as otherwise they are treated as separate operations 676 by the server. 678 Starting a request operation matchable to a previous operation and 679 even using the same Request-Tag value is called request tag 680 recycling. The absence of a Request-Tag option is viewed as a value 681 distinct from all values with a single Request-Tag option set; 682 starting a request operation matchable to a previous operation where 683 neither has a Request-Tag option therefore constitutes request tag 684 recycling just as well (also called "recycling the absent option"). 686 Clients that use Request-Tag for a particular purpose (like in 687 Section 3.5) MUST NOT recycle a request tag unless the first 688 operation has concluded. What constitutes a concluded operation 689 depends on the purpose, and is defined accordingly; see examples in 690 Section 3.5. 692 When Block1 and Block2 are combined in an operation, the Request-Tag 693 of the Block1 phase is set in the Block2 phase as well for otherwise 694 the request would have a different set of options and would not be 695 recognized any more. 697 Clients are encouraged to generate compact messages. This means 698 sending messages without Request-Tag options whenever possible, and 699 using short values when the absent option cannot be recycled. 701 Note that Request-Tag options can be present in request messages that 702 carry no Block option (for example, because a Request-Tag unaware 703 proxy reassembled them), and MUST be ignored in those. 705 The Request-Tag option MUST NOT be present in response messages. 707 3.5. Applications of the Request-Tag Option 709 3.5.1. Body Integrity Based on Payload Integrity 711 When a client fragments a request body into multiple message 712 payloads, even if the individual messages are integrity protected, it 713 is still possible for an attacker to maliciously replace a later 714 operation's blocks with an earlier operation's blocks (see 715 Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the 716 integrity protection of each block does not extend to the operation's 717 request body. 719 In order to gain that protection, use the Request-Tag mechanism as 720 follows: 722 * The individual exchanges MUST be integrity protected end-to-end 723 between client and server. 725 * The client MUST NOT recycle a request tag in a new operation 726 unless the previous operation matchable to the new one has 727 concluded. 729 If any future security mechanisms allow a block-wise transfer to 730 continue after an endpoint's details (like the IP address) have 731 changed, then the client MUST consider messages sent to _any_ 732 endpoint address using the new operation's security context. 734 * The client MUST NOT regard a block-wise request operation as 735 concluded unless all of the messages the client previously sent in 736 the operation have been confirmed by the message integrity 737 protection mechanism, or the client can determine that the server 738 would not consider the messages to be valid if they were replayed. 740 Typically, in OSCORE, these confirmations can result either from 741 the client receiving an OSCORE response message matching the 742 request (an empty ACK is insufficient), or because the message's 743 sequence number is old enough to be outside the server's receive 744 window. 746 In DTLS, this can only be confirmed if the request message was not 747 retransmitted, and was responded to. 749 Authors of other documents (e.g. applications of [RFC8613]) are 750 invited to mandate this behavior for clients that execute block-wise 751 interactions over secured transports. In this way, the server can 752 rely on a conforming client to set the Request-Tag option when 753 required, and thereby conclude on the integrity of the assembled 754 body. 756 Note that this mechanism is implicitly implemented when the security 757 layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). 758 This is because with each message, any earlier message cannot be 759 replayed any more, so the client never needs to set the Request-Tag 760 option unless it wants to perform concurrent operations. 762 Body integrity only makes sense in applications that have stateful 763 block-wise transfers. On applications where all the state is in the 764 application (e.g. because rather than POSTing a large representation 765 to a collection in a stateful block-wise transfer, a collection item 766 is created first, then written to once and available when written 767 completely), clients need not concern themselves with body integrity 768 and thus the Request-Tag. 770 3.5.2. Multiple Concurrent Block-wise Operations 772 CoAP clients, especially CoAP proxies, may initiate a block-wise 773 request operation to a resource, to which a previous one is already 774 in progress, which the new request should not cancel. A CoAP proxy 775 would be in such a situation when it forwards operations with the 776 same cache-key options but possibly different payloads. 778 For those cases, Request-Tag is the proxy-safe elective option 779 suggested in [RFC7959] Section 2.4 last paragraph. 781 When initializing a new block-wise operation, a client has to look at 782 other active operations: 784 * If any of them is matchable to the new one, and the client neither 785 wants to cancel the old one nor postpone the new one, it can pick 786 a Request-Tag value (including the absent option) that is not in 787 use by the other matchable operations for the new operation. 789 * Otherwise, it can start the new operation without setting the 790 Request-Tag option on it. 792 3.5.3. Simplified Block-Wise Handling for Constrained Proxies 794 The Block options were defined to be unsafe to forward because a 795 proxy that would forward blocks as plain messages would risk mixing 796 up clients' requests. 798 In some cases, for example when forwarding block-wise request 799 operations, appending a Request-Tag value unique to the client can 800 satisfy the requirements on the proxy that come from the presence of 801 a block option. 803 This is particularly useful to proxies that strive for stateless 804 operation as described in [RFC8974] Section 4. 806 The precise classification of cases in which such a Request-Tag 807 option is sufficient is not trivial, especially when both request and 808 response body are fragmented, and out of scope for this document. 810 3.6. Rationale for the Option Properties 812 The Request-Tag option can be elective, because to servers unaware of 813 the Request-Tag option, operations with differing request tags will 814 not be matchable. 816 The Request-Tag option can be safe to forward but part of the cache 817 key, because proxies unaware of the Request-Tag option will consider 818 operations with differing request tags unmatchable but can still 819 forward them. 821 The Request-Tag option is repeatable because this easily allows 822 several cascaded stateless proxies to each put in an origin address. 823 They can perform the steps of Section 3.5.3 without the need to 824 create an option value that is the concatenation of the received 825 option and their own value, and can simply add a new Request-Tag 826 option unconditionally. 828 In draft versions of this document, the Request-Tag option used to be 829 critical and unsafe to forward. That design was based on an 830 erroneous understanding of which blocks could be composed according 831 to [RFC7959]. 833 3.7. Rationale for Introducing the Option 835 An alternative that was considered to the Request-Tag option for 836 coping with the problem of fragmented message body integrity 837 (Section 3.5.1) was to update [RFC7959] to say that blocks could only 838 be assembled if their fragments' order corresponded to the sequence 839 numbers. 841 That approach would have been difficult to roll out reliably on DTLS 842 where many implementations do not expose sequence numbers, and would 843 still not prevent attacks like in [I-D.mattsson-core-coap-actuators] 844 Section 2.5.2. 846 3.8. Block2 / ETag Processing 848 The same security properties as in Section 3.5.1 can be obtained for 849 block-wise response operations. The threat model here does not 850 depend on an attacker: a client can construct a wrong representation 851 by assembling it from blocks from different resource states. That 852 can happen when a resource is modified during a transfer, or when 853 some blocks are still valid in the client's cache. 855 Rules stating that response body reassembly is conditional on 856 matching ETag values are already in place from Section 2.4 of 857 [RFC7959]. 859 To gain equivalent protection to Section 3.5.1, a server MUST use the 860 Block2 option in conjunction with the ETag option ([RFC7252], 861 Section 5.10.6), and MUST NOT use the same ETag value for different 862 representations of a resource. 864 4. Token Processing for Secure Request-Response Binding 866 4.1. Request-Response Binding 868 A fundamental requirement of secure REST operations is that the 869 client can bind a response to a particular request. If this is not 870 ensured, a client may erroneously associate the wrong response to a 871 request. The wrong response may be an old response for the same 872 resource or a response for a completely different resource (see e.g. 873 Section 2.3 of [I-D.mattsson-core-coap-actuators]). For example, a 874 request for the alarm status "GET /status" may be associated to a 875 prior response "on", instead of the correct response "off". 877 In HTTPS, this type of binding is always assured by the ordered and 878 reliable delivery as well as mandating that the server sends 879 responses in the same order that the requests were received. The 880 same is not true for CoAP where the server (or an attacker) can 881 return responses in any order and where there can be any number of 882 responses to a request (see e.g. [RFC7641]). In CoAP, concurrent 883 requests are differentiated by their Token. Note that the CoAP 884 Message ID cannot be used for this purpose since those are typically 885 different for REST request and corresponding response in case of 886 "separate response", see Section 2.2 of [RFC7252]. 888 CoAP [RFC7252] does not treat Token as a cryptographically important 889 value and does not give stricter guidelines than that the Tokens 890 currently "in use" SHOULD (not SHALL) be unique. If used with a 891 security protocol not providing bindings between requests and 892 responses (e.g. DTLS and TLS) Token reuse may result in situations 893 where a client matches a response to the wrong request. Note that 894 mismatches can also happen for other reasons than a malicious 895 attacker, e.g. delayed delivery or a server sending notifications to 896 an uninterested client. 898 A straightforward mitigation is to mandate clients to not reuse 899 Tokens until the traffic keys have been replaced. The following 900 section formalizes that. 902 4.2. Updated Token Processing Requirements for Clients 904 As described in Section 4.1, the client must be able to verify that a 905 response corresponds to a particular request. This section updates 906 the Token processing requirements for clients in [RFC7252] to always 907 assure a cryptographically secure binding of responses to requests 908 for secure REST operations like "coaps". The Token processing for 909 servers is not updated. Token processing in Section 5.3.1 of 910 [RFC7252] is updated by adding the following text: 912 When CoAP is used with a security protocol not providing bindings 913 between requests and responses, the Tokens have cryptographic 914 importance. The client MUST make sure that Tokens are not used in a 915 way so that responses risk being associated with the wrong request. 917 One easy way to accomplish this is to implement the Token (or part of 918 the Token) as a sequence number starting at zero for each new or 919 rekeyed secure connection. This approach SHOULD be followed. 921 5. Security Considerations 923 The freshness assertion of the Echo option comes from the client 924 reproducing the same value of the Echo option in a request as in a 925 previous response. If the Echo value is a large random number then 926 there is a high probability that the request is generated after 927 having seen the response. If the Echo value of the response can be 928 guessed, e.g. if based on a small random number or a counter (see 929 Appendix A), then it is possible to compose a request with the right 930 Echo value ahead of time. However, this may not be an issue if the 931 communication is integrity protected against third parties and the 932 client is trusted not misusing this capability. Echo values MUST be 933 set by the CoAP server such that the risk associated with unintended 934 reuse can be managed. 936 If uniqueness of the Echo value is based on randomness, then the 937 availability of a secure pseudorandom number generator and truly 938 random seeds are essential for the security of the Echo option. If 939 no true random number generator is available, a truly random seed 940 must be provided from an external source. As each pseudorandom 941 number must only be used once, an implementation needs to get a new 942 truly random seed after reboot, or continuously store state in 943 nonvolatile memory. See ([RFC8613], Appendix B.1.1) for issues and 944 solution approaches for writing to nonvolatile memory. 946 A single active Echo value with 64 (pseudo-)random bits gives the 947 same theoretical security level as a 64-bit MAC (as used in e.g. 948 AES_128_CCM_8). If a random unique Echo value is intended, the Echo 949 option value SHOULD contain 64 (pseudo-)random bits that are not 950 predictable for any other party than the server. A server MAY use 951 different security levels for different uses cases (client aliveness, 952 request freshness, state synchronization, network address 953 reachability, etc.). 955 The security provided by the Echo and Request-Tag options depends on 956 the security protocol used. CoAP and HTTP proxies require (D)TLS to 957 be terminated at the proxies. The proxies are therefore able to 958 manipulate, inject, delete, or reorder options or packets. The 959 security claims in such architectures only hold under the assumption 960 that all intermediaries are fully trusted and have not been 961 compromised. 963 Counter Echo values can only be used to show freshness relative to 964 numbered events, and are the legitimate case for Echo values shorter 965 than four bytes, which are not necessarily secret. They MUST NOT be 966 used unless the request Echo values are integrity protected as per 967 Section 2.3. 969 Servers SHOULD use a monotonic clock to generate timestamps and 970 compute round-trip times. Use of non-monotonic clocks is not secure 971 as the server will accept expired Echo option values if the clock is 972 moved backward. The server will also reject fresh Echo option values 973 if the clock is moved forward. Non-monotonic clocks MAY be used as 974 long as they have deviations that are acceptable given the freshness 975 requirements. If the deviations from a monotonic clock are known, it 976 may be possible to adjust the threshold accordingly. 978 An attacker may be able to affect the server's system time in various 979 ways such as setting up a fake NTP server or broadcasting false time 980 signals to radio-controlled clocks. 982 For the purpose of generating timestamps for Echo a server MAY set a 983 timer at reboot and use the time since reboot, in a unit such that 984 different requests arrive at different times. Servers MAY 985 intermittently reset the timer and MAY generate a random offset 986 applied to all timestamps. When resetting the timer, the server MUST 987 reject all Echo values that were created before the reset. 989 Servers that use the List of Cached Random Values and Timestamps 990 method described in Appendix A may be vulnerable to resource 991 exhaustion attacks. One way to minimize state is to use the 992 Integrity Protected Timestamp method described in Appendix A. 994 5.1. Token reuse 996 Reusing Tokens in a way so that responses are guaranteed to not be 997 associated with the wrong request is not trivial: The server may 998 process requests in any order, and send multiple responses to the 999 same request. An attacker may block, delay, and reorder messages. 1000 The use of a sequence number is therefore recommended when CoAP is 1001 used with a security protocol that does not provide bindings between 1002 requests and responses such as DTLS or TLS. 1004 For a generic response to a Confirmable request over DTLS, binding 1005 can only be claimed without out-of-band knowledge if 1007 * the original request was never retransmitted, 1009 * the response was piggybacked in an Acknowledgement message (as a 1010 Confirmable or Non-confirmable response may have been transmitted 1011 multiple times), and 1013 * if observation was used, the same holds for the registration, all 1014 re-registrations, and the cancellation. 1016 (In addition, for observations, any responses using that Token and a 1017 DTLS sequence number earlier than the cancellation Acknowledgement 1018 message need to be discarded. This is typically not supported in 1019 DTLS implementations.) 1021 In some setups, Tokens can be reused without the above constraints, 1022 as a different component in the setup provides the associations: 1024 * In CoAP over TLS, retransmissions are not handled by the CoAP 1025 layer and behaves like a replay window size of 1. When a client 1026 is sending TLS-protected requests without Observe to a single 1027 server, the client can reuse a Token as soon as the previous 1028 response with that Token has been received. 1030 * Requests whose responses are cryptographically bound to the 1031 requests (like in OSCORE) can reuse Tokens indefinitely. 1033 In all other cases, a sequence number approach is RECOMMENDED as per 1034 Section 4. 1036 Tokens that cannot be reused need to be handled appropriately. This 1037 could be solved by increasing the Token as soon as the currently used 1038 Token cannot be reused, or by keeping a list of all blacklisted 1039 Tokens. 1041 When the Token (or part of the Token) contains a sequence number, the 1042 encoding of the sequence number has to be chosen in a way to avoid 1043 any collisions. This is especially true when the Token contains more 1044 information than just the sequence number, e.g. serialized state as 1045 in [RFC8974]. 1047 6. Privacy Considerations 1049 Implementations SHOULD NOT put any privacy-sensitive information in 1050 the Echo or Request-Tag option values. Unencrypted timestamps could 1051 reveal information about the server such as location or time since 1052 reboot, or that the server will accept expired certificates. 1053 Timestamps MAY be used if Echo is encrypted between the client and 1054 the server, e.g. in the case of DTLS without proxies or when using 1055 OSCORE with an Inner Echo option. 1057 Like HTTP cookies, the Echo option could potentially be abused as a 1058 tracking mechanism that identifies a client across requests. This is 1059 especially true for preemptive Echo values. Servers MUST NOT use the 1060 Echo option to correlate requests for other purposes than freshness 1061 and reachability. Clients only send Echo values to the same server 1062 from which the values were received. Compared to HTTP, CoAP clients 1063 are often authenticated and non-mobile, and servers can therefore 1064 often correlate requests based on the security context, the client 1065 credentials, or the network address. Especially when the Echo option 1066 increases a server's ability to correlate requests, clients MAY 1067 discard all preemptive Echo values. 1069 7. IANA Considerations 1071 IANA is requested to add the following option numbers to the "CoAP 1072 Option Numbers" registry defined by [RFC7252]: 1074 [ 1076 The editor is asked to suggest the numbers after TBD, as those 1077 satisfy the construction requirements set out in RFC7252: Echo is 1078 NoCacheKey but not Unsafe or Critical, so it needs to end with 11100 1079 in binary representation; Request-Tag has no properties so it needs 1080 to end with 00 and not with 11100). 1082 Request-Tag was picked to not waste the precious space of less-than- 1083 one-byte options, but such that its offset from the Block1 option it 1084 regularly occurs with can still be expressed in an 1-byte offset (27 1085 + (13 + 255) > 292). 1087 Echo was picked to be the shortest it can be in an empty message as a 1088 NoCacheKey option (11100 in binary does not fit in a nibble, and two 1089 lower ones are already taken), and as high as possible to keep room 1090 for other options that might typically occur in pairs and might still 1091 use optimization around low numbers. 1093 ] 1095 +--------+-------------+-------------------+ 1096 | Number | Name | Reference | 1097 +--------+-------------+-------------------+ 1098 | TBD252 | Echo | [[this document]] | 1099 | | | | 1100 | TBD292 | Request-Tag | [[this document]] | 1101 +--------+-------------+-------------------+ 1103 Figure 5: CoAP Option Numbers 1105 8. References 1107 8.1. Normative References 1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, 1111 DOI 10.17487/RFC2119, March 1997, 1112 . 1114 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1115 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1116 January 2012, . 1118 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1119 Application Protocol (CoAP)", RFC 7252, 1120 DOI 10.17487/RFC7252, June 2014, 1121 . 1123 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1124 the Constrained Application Protocol (CoAP)", RFC 7959, 1125 DOI 10.17487/RFC7959, August 2016, 1126 . 1128 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1129 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1130 May 2017, . 1132 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1133 "Object Security for Constrained RESTful Environments 1134 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1135 . 1137 8.2. Informative References 1139 [I-D.ietf-core-oscore-groupcomm] 1140 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1141 "Group OSCORE - Secure Group Communication for CoAP", Work 1142 in Progress, Internet-Draft, draft-ietf-core-oscore- 1143 groupcomm-10, 2 November 2020, . 1146 [I-D.ietf-quic-transport] 1147 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1148 and Secure Transport", Work in Progress, Internet-Draft, 1149 draft-ietf-quic-transport-34, 14 January 2021, 1150 . 1153 [I-D.mattsson-core-coap-actuators] 1154 Mattsson, J., Fornehed, J., Selander, G., Palombini, F., 1155 and C. Amsuess, "Controlling Actuators with CoAP", Work in 1156 Progress, Internet-Draft, draft-mattsson-core-coap- 1157 actuators-06, 17 September 2018, . 1161 [REST] Fielding, R., "Architectural Styles and the Design of 1162 Network-based Software Architectures", 2000, 1163 . 1166 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1167 the Constrained Application Protocol (CoAP)", RFC 7390, 1168 DOI 10.17487/RFC7390, October 2014, 1169 . 1171 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1172 Application Protocol (CoAP)", RFC 7641, 1173 DOI 10.17487/RFC7641, September 2015, 1174 . 1176 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1177 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1178 Application Protocol) over TCP, TLS, and WebSockets", 1179 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1180 . 1182 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1183 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1184 . 1186 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1187 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1188 2018, . 1190 [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and 1191 Stateless Clients in the Constrained Application Protocol 1192 (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, 1193 . 1195 Appendix A. Methods for Generating Echo Option Values 1197 The content and structure of the Echo option value are implementation 1198 specific and determined by the server. Two simple mechanisms for 1199 time-based freshness and one for event-based freshness are outlined 1200 in this section, the first is RECOMMENDED in general, and the second 1201 is RECOMMENDED in case the Echo option is encrypted between the 1202 client and the server. 1204 Different mechanisms have different tradeoffs between the size of the 1205 Echo option value, the amount of server state, the amount of 1206 computation, and the security properties offered. A server MAY use 1207 different methods and security levels for different uses cases 1208 (client aliveness, request freshness, state synchronization, network 1209 address reachability, etc.). 1211 1. List of Cached Random Values and Timestamps. The Echo option 1212 value is a (pseudo-)random byte string called r. The server caches a 1213 list containing the random byte strings and their transmission times. 1215 Assuming 72-bit random values and 32-bit timestamps, the size of the 1216 Echo option value is 9 bytes and the amount of server state is 13n 1217 bytes, where n is the number of active Echo Option values. The 1218 security against an attacker guessing echo values is given by s = bit 1219 length of r - log2(n). The length of r and the maximum allowed n 1220 should be set so that the security level is harmonized with other 1221 parts of the deployment, e.g., s >= 64. If the server loses time 1222 continuity, e.g. due to reboot, the entries in the old list MUST be 1223 deleted. 1225 Echo option value: random value r 1226 Server State: random value r, timestamp t0 1228 2. Integrity Protected Timestamp. The Echo option value is an 1229 integrity protected timestamp. The timestamp can have different 1230 resolution and range. A 32-bit timestamp can e.g. give a resolution 1231 of 1 second with a range of 136 years. The (pseudo-)random secret 1232 key is generated by the server and not shared with any other party. 1233 The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit 1234 timestamp and a 64-bit MAC, the size of the Echo option value is 12 1235 bytes and the Server state is small and constant. The security 1236 against an attacker guessing echo values is given by the MAC length. 1237 If the server loses time continuity, e.g. due to reboot, the old key 1238 MUST be deleted and replaced by a new random secret key. Note that 1239 the privacy considerations in Section 6 may apply to the timestamp. 1240 Therefore, it might be important to encrypt it. Depending on the 1241 choice of encryption algorithms, this may require a nonce to be 1242 included in the Echo option value. 1244 Echo option value: timestamp t0, MAC(k, t0) 1245 Server State: secret key k 1247 3. Persistent Counter. This is an event-based freshness method 1248 usable for state synchronization (for example after volatile state 1249 has been lost), and cannot be used for client aliveness. It requires 1250 that the client can be trusted to not spuriously produce Echo values. 1251 The Echo option value is a simple counter without integrity 1252 protection of its own, serialized in uint format. The counter is 1253 incremented in a persistent way every time the state that needs to be 1254 synchronized is changed (in the aforementioned example: when a reboot 1255 indicates that volatile state may have been lost). An example of how 1256 such a persistent counter can be implemented efficiently is the 1257 OSCORE server Sender Sequence Number mechanism described in 1258 Appendix B.1.1 of [RFC8613]. 1260 Echo option value: counter 1261 Server State: counter 1263 Other mechanisms complying with the security and privacy 1264 considerations may be used. The use of encrypted timestamps in the 1265 Echo option increases security, but typically requires an IV 1266 (Initialization Vector) to be included in the Echo option value, 1267 which adds overhead and makes the specification of such a mechanism 1268 slightly more complicated than the two time-based mechanisms 1269 specified here. 1271 Appendix B. Request-Tag Message Size Impact 1273 In absence of concurrent operations, the Request-Tag mechanism for 1274 body integrity (Section 3.5.1) incurs no overhead if no messages are 1275 lost (more precisely: in OSCORE, if no operations are aborted due to 1276 repeated transmission failure; in DTLS, if no packets are lost), or 1277 when block-wise request operations happen rarely (in OSCORE, if there 1278 is always only one request block-wise operation in the replay 1279 window). 1281 In those situations, no message has any Request-Tag option set, and 1282 that can be recycled indefinitely. 1284 When the absence of a Request-Tag option cannot be recycled any more 1285 within a security context, the messages with a present but empty 1286 Request-Tag option can be used (1 Byte overhead), and when that is 1287 used-up, 256 values from one byte long options (2 Bytes overhead) are 1288 available. 1290 In situations where those overheads are unacceptable (e.g. because 1291 the payloads are known to be at a fragmentation threshold), the 1292 absent Request-Tag value can be made usable again: 1294 * In DTLS, a new session can be established. 1296 * In OSCORE, the sequence number can be artificially increased so 1297 that all lost messages are outside of the replay window by the 1298 time the first request of the new operation gets processed, and 1299 all earlier operations can therefore be regarded as concluded. 1301 Appendix C. Change Log 1303 [ The editor is asked to remove this section before publication. ] 1305 * Changes since draft-ietf-core-echo-request-tag-11 (addressing 1306 GenART, TSVART, OpsDir comments) 1307 - Explain the size permissible for responses before amplification 1308 mitigation by referring to the QUIC draft for an OK factor, and 1309 giving the remaining numbers that led to it. The actual number 1310 is reduced from 152 to 136 because the more conservative case 1311 of the attacker not sending a token is considered now. 1313 - Added a definition for "freshness" 1315 - Give more concrete example values in figures 2 and 3 (based on 1316 the appendix suggestions), highlighting the differences between 1317 the figures by telling how they are processed in the examples. 1319 - Figure with option summary: E/U columns removed (for duplicate 1320 headers and generally not contributing) 1322 - MAY capitalization changed for consistency. 1324 - Editorial changes (IV acronym expanded, s/can not/cannot/g) 1326 - Draft ietf-core-stateless has become RFC8974 1328 * Changes since draft-ietf-core-echo-request-tag-10 (Barry's 1329 comments) 1331 - Align terminology on attacker 1333 - A number of clarifications and editorial fixes 1335 - Promote DTLS and OSCORE to normative references 1337 - Add counter-based version to the Methods for Generating Echo 1338 Option Values appendix 1340 - Use 64-bit randomness recommendation throughout (but keep it as 1341 SHOULD so applications with strict requirements can reduce if 1342 if really needed) 1344 - Speling and Capitalization 1346 * Changes since draft-ietf-core-echo-request-tag-09: 1348 - Allow intermediaries to do Echo processing, provided they ask 1349 at least as much freshness as they forward 1351 - Emphasize that clients can forget Echo to further discourage 1352 abuse as cookies 1354 - Emphasize that RESTful application design can avoid the need 1355 for a Request-Tag 1357 - Align with core-oscore-groupcomm-09 1359 - Add interaction with HTTP Early Data / 425 Too Early 1361 - Abstract: Explicitly mention both updates to 7252 1363 - Change requested option number of Echo to 252 (previous 1364 property calculation was erroneous) 1366 * Changes since draft-ietf-core-echo-request-tag-08: 1368 - Make amplification attack mitigation by Echo an RFC7252 1369 updating recommendation 1371 - Give some more concrete guidance to that use case in terms of 1372 sizes and message types 1374 - Allow short (1-3 byte) Echo values for deterministic cases, 1375 with according security considerations 1377 - Point out the tricky parts around Request-Tag for stateless 1378 proxies, and make that purely an outlook example with out-of- 1379 scope details 1381 - Lift ban on Request-Tag options without Block1 (as they can 1382 legitimately be generated by an unaware proxy) 1384 - Suggest concrete numbers for the options 1386 * Changes since draft-ietf-core-echo-request-tag-07 (largely 1387 addressing Francesca's review): 1389 - Request tag: Explicitly limit "MUST NOT recycle" requirement to 1390 particular applications 1392 - Token reuse: upper-case RECOMMEND sequence number approach 1394 - Structure: Move per-topic introductions to respective chapters 1395 (this avoids long jumps by the reader) 1397 - Structure: Group Block2 / ETag section inside new fragmentation 1398 (formerly Request-Tag) section 1400 - More precise references into other documents 1401 - "concurrent operations": Emphasise that all here only matters 1402 between endpoint pairs 1404 - Freshness: Generalize wording away from time-based freshness 1406 - Echo: Emphasise that no binding between any particular pair of 1407 responses and requests is established 1409 - Echo: Add event-based example 1411 - Echo: Clarify when protection is needed 1413 - Request tag: Enhance wording around "not sufficient condition" 1415 - Request tag: Explicitly state when a tag needs to be set 1417 - Request tag: Clarification about permissibility of leaving the 1418 option absent 1420 - Security considerations: wall clock time -> system time (and 1421 remove inaccurate explanations) 1423 - Token reuse: describe blacklisting in a more implementation- 1424 independent way 1426 * Changes since draft-ietf-core-echo-request-tag-06: 1428 - Removed visible comment that should not be visible in Token 1429 reuse considerations. 1431 * Changes since draft-ietf-core-echo-request-tag-05: 1433 - Add privacy considerations on cookie-style use of Echo values 1435 - Add security considerations for token reuse 1437 - Add note in security considerations on use of nonvolatile 1438 memory when dealing with pseudorandom numbers 1440 - Appendix on echo generation: add a few words on up- and 1441 downsides of the encrypted timestamp alternative 1443 - Clarifications around Outer Echo: 1445 o Could be generated by the origin server to prove network 1446 reachability (but for most applications it MUST be inner) 1448 o Could be generated by intermediaries 1449 o Is answered by the client to the endpoint from which it 1450 received it (ie. Outer if received as Outer) 1452 - Clarification that a server can send Echo preemtively 1454 - Refer to stateless to explain what "more information than just 1455 the sequence number" could be 1457 - Remove explanations around 0.00 empty messags 1459 - Rewordings: 1461 o the attack: from "forging" to "guessing" 1463 o "freshness tokens" to "freshness indicators" (to avoid 1464 confusion with the Token) 1466 - Editorial fixes: 1468 o Abstract and introduction mention what is updated in RFC7252 1470 o Reference updates 1472 o Capitalization, spelling, terms from other documents 1474 * Changes since draft-ietf-core-echo-request-tag-04: 1476 - Editorial fixes 1478 o Moved paragraph on collision-free encoding of data in the 1479 Token to Security Considerations and rephrased it 1481 o "easiest" -> "one easy" 1483 * Changes since draft-ietf-core-echo-request-tag-03: 1485 - Mention Token processing changes in title 1487 - Abstract reworded 1489 - Clarify updates to Token processing 1491 - Describe security levels from Echo length 1493 - Allow non-monotonic clocks under certain conditions for 1494 freshness 1496 - Simplify freshness expressions 1497 - Describe when a Request-Tag can be set 1499 - Add note on application-level freshness mechanisms 1501 - Minor editorial changes 1503 * Changes since draft-ietf-core-echo-request-tag-02: 1505 - Define "freshness" 1507 - Note limitations of "aliveness" 1509 - Clarify proxy and OSCORE handling in presence of "echo" 1511 - Clarify when Echo values may be reused 1513 - Update security considerations 1515 - Various minor clarifications 1517 - Minor editorial changes 1519 * Major changes since draft-ietf-core-echo-request-tag-01: 1521 - Follow-up changes after the "relying on block-wise" change in 1522 -01: 1524 o Simplify the description of Request-Tag and matchability 1526 o Do not update RFC7959 any more 1528 - Make Request-Tag repeatable. 1530 - Add rationale on not relying purely on sequence numbers. 1532 * Major changes since draft-ietf-core-echo-request-tag-00: 1534 - Reworded the Echo section. 1536 - Added rules for Token processing. 1538 - Added security considerations. 1540 - Added actual IANA section. 1542 - Made Request-Tag optional and safe-to-forward, relying on 1543 block-wise to treat it as part of the cache-key 1545 - Dropped use case about OSCORE Outer-block-wise (the case went 1546 away when its Partial IV was moved into the Object-Security 1547 option) 1549 * Major changes since draft-amsuess-core-repeat-request-tag-00: 1551 - The option used for establishing freshness was renamed from 1552 "Repeat" to "Echo" to reduce confusion about repeatable 1553 options. 1555 - The response code that goes with Echo was changed from 4.03 to 1556 4.01 because the client needs to provide better credentials. 1558 - The interaction between the new option and (cross) proxies is 1559 now covered. 1561 - Two messages being "Request-Tag matchable" was introduced to 1562 replace the older concept of having a request tag value with 1563 its slightly awkward equivalence definition. 1565 Acknowledgments 1567 The authors want to thank Carsten Bormann, Francesca Palombini, and 1568 Jim Schaad for providing valuable input to the draft. 1570 Authors' Addresses 1572 Christian Amsüss 1574 Email: christian@amsuess.com 1576 John Preuß Mattsson 1577 Ericsson AB 1579 Email: john.mattsson@ericsson.com 1581 Göran Selander 1582 Ericsson AB 1584 Email: goran.selander@ericsson.com