idnits 2.17.1 draft-ietf-core-echo-request-tag-08.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7252, but the abstract doesn't seem to directly say this. It does mention RFC7252 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1633 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) == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-05 == Outdated reference: A later version (-08) exists of draft-ietf-core-stateless-03 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). 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: May 7, 2020 Ericsson AB 7 November 04, 2019 9 CoAP: Echo, Request-Tag, and Token Processing 10 draft-ietf-core-echo-request-tag-08 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. The update to the client Token processing requirements of 21 RFC 7252 forbids non-secure reuse of Tokens to ensure binding of 22 responses to requests when CoAP is used with security. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Request Freshness and the Echo Option . . . . . . . . . . . . 4 61 2.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 4 62 2.2. The Echo Option . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.1. Echo Option Format . . . . . . . . . . . . . . . . . 5 64 2.3. Echo Processing . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Applications of the Echo Option . . . . . . . . . . . . . 10 66 3. Protecting Message Bodies using Request Tags . . . . . . . . 11 67 3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 11 68 3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 12 69 3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 12 70 3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 13 71 3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 14 72 3.5. Applications of the Request-Tag Option . . . . . . . . . 15 73 3.5.1. Body Integrity Based on Payload Integrity . . . . . . 15 74 3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 16 75 3.5.3. Simplified Block-Wise Handling for Constrained 76 Proxies . . . . . . . . . . . . . . . . . . . . . . . 16 77 3.6. Rationale for the Option Properties . . . . . . . . . . . 16 78 3.7. Rationale for Introducing the Option . . . . . . . . . . 17 79 3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 17 80 4. Token Processing for Secure Request-Response Binding . . . . 18 81 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 18 82 4.2. Updated Token Processing Requirements for Clients . . . . 18 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 20 85 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 89 8.2. Informative References . . . . . . . . . . . . . . . . . 22 90 Appendix A. Methods for Generating Echo Option Values . . . . . 23 91 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 25 92 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 25 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 96 1. Introduction 98 The initial Constrained Application Protocol (CoAP) suite of 99 specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed 100 with the assumption that security could be provided on a separate 101 layer, in particular by using DTLS ([RFC6347]). However, for some 102 use cases, additional functionality or extra processing is needed to 103 support secure CoAP operations. This document specifies security 104 enhancements to the Constrained Application Protocol (CoAP). 106 This document specifies two CoAP options, the Echo option and the 107 Request-Tag option: The Echo option enables a CoAP server to verify 108 the freshness of a request, synchronize state, or force a client to 109 demonstrate reachability at its claimed network address. The 110 Request-Tag option allows the CoAP server to match message fragments 111 belonging to the same request, fragmented using the CoAP block-wise 112 Transfer mechanism, which mitigates attacks and enables concurrent 113 block-wise operations. These options in themselves do not replace 114 the need for a security protocol; they specify the format and 115 processing of data which, when integrity protected using e.g. DTLS 116 ([RFC6347]), TLS ([RFC8446]), or OSCORE ([RFC8613]), provide the 117 additional security features. 119 The document also updates the Token processing requirements for 120 clients specified in [RFC7252]. The updated processing forbids non- 121 secure reuse of Tokens to ensure binding of responses to requests 122 when CoAP is used with security, thus mitigating error cases and 123 attacks where the client may erroneously associate the wrong response 124 to a request. 126 Each of the following sections provides a more detailed introduction 127 to the topic at hand in its first subsection. 129 1.1. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 Unless otherwise specified, the terms "client" and "server" refers to 138 "CoAP client" and "CoAP server", respectively, as defined in 139 [RFC7252]. The term "origin server" is used as in [RFC7252]. The 140 term "origin client" is used in this document to denote the client 141 from which a request originates; to distinguish from clients in 142 proxies. 144 The terms "payload" and "body" of a message are used as in [RFC7959]. 145 The complete interchange of a request and a response body is called a 146 (REST) "operation". An operation fragmented using [RFC7959] is 147 called a "block-wise operation". A block-wise operation which is 148 fragmenting the request body is called a "block-wise request 149 operation". A block-wise operation which is fragmenting the response 150 body is called a "block-wise response operation". 152 Two request messages are said to be "matchable" if they occur between 153 the same endpoint pair, have the same code and the same set of 154 options except for elective NoCacheKey options and options involved 155 in block-wise transfer (Block1, Block2 and Request-Tag). Two 156 operations are said to be matchable if any of their messages are. 158 Two matchable block-wise operations are said to be "concurrent" if a 159 block of the second request is exchanged even though the client still 160 intends to exchange further blocks in the first operation. 161 (Concurrent block-wise request operations from a single endpoint are 162 impossible with the options of [RFC7959] (see the last paragraphs of 163 Sections 2.4 and 2.5) because the second operation's block overwrites 164 any state of the first exchange.). 166 The Echo and Request-Tag options are defined in this document. 168 2. Request Freshness and the Echo Option 170 2.1. Request Freshness 172 A CoAP server receiving a request is in general not able to verify 173 when the request was sent by the CoAP client. This remains true even 174 if the request was protected with a security protocol, such as DTLS. 175 This makes CoAP requests vulnerable to certain delay attacks which 176 are particularly perilous in the case of actuators 177 ([I-D.mattsson-core-coap-actuators]). Some attacks can be mitigated 178 by establishing fresh session keys, e.g. performing a DTLS handshake 179 for each request, but in general this is not a solution suitable for 180 constrained environments, for example, due to increased message 181 overhead and latency. Additionally, if there are proxies, fresh DTLS 182 session keys between server and proxy does not say anything about 183 when the client made the request. In a general hop-by-hop setting, 184 freshness may need to be verified in each hop. 186 A straightforward mitigation of potential delayed requests is that 187 the CoAP server rejects a request the first time it appears and asks 188 the CoAP client to prove that it intended to make the request at this 189 point in time. 191 2.2. The Echo Option 193 This document defines the Echo option, a a lightweight challenge- 194 response mechanism for CoAP that enables a CoAP server to verify the 195 freshness of a request. A fresh request is one whose age has not yet 196 exceeded the freshness requirements set by the server. The freshness 197 requirements are application specific and may vary based on resource, 198 method, and parameters outside of CoAP such as policies. The Echo 199 option value is a challenge from the server to the client included in 200 a CoAP response and echoed back to the server in one or more CoAP 201 requests. The Echo option provides a convention to transfer 202 freshness indicators that works for all CoAP methods and response 203 codes. 205 This mechanism is not only important in the case of actuators, or 206 other use cases where the CoAP operations require freshness of 207 requests, but also in general for synchronizing state between CoAP 208 client and server, cryptographically verify the aliveness of the 209 client, or force a client to demonstrate reachability at its claimed 210 network address. The same functionality can be provided by echoing 211 freshness indicators in CoAP payloads, but this only works for 212 methods and response codes defined to have a payload. The Echo 213 option provides a convention to transfer freshness indicators that 214 works for all methods and response codes. 216 2.2.1. Echo Option Format 218 The Echo Option is elective, safe-to-forward, not part of the cache- 219 key, and not repeatable, see Figure 1, which extends Table 4 of 220 [RFC7252]). 222 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 223 | No. | C | U | N | R | Name | Format | Len. | Default | E | U | 224 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 225 | TBD | | | x | | Echo | opaque | 4-40 | (none) | x | x | 226 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 228 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 229 E = Encrypt and Integrity Protect (when using OSCORE) 231 Figure 1: Echo Option Summary 233 The Echo option value is generated by a server, and its content and 234 structure are implementation specific. Different methods for 235 generating Echo option values are outlined in Appendix A. Clients 236 and intermediaries MUST treat an Echo option value as opaque and make 237 no assumptions about its content or structure. 239 When receiving an Echo option in a request, the server MUST be able 240 to verify that the Echo option value (a) was generated by the server 241 or some other party that the server trusts, and (b) fulfills the 242 freshness requirements of the application. Depending on the 243 freshness requirements the server may verify exactly when the Echo 244 option value was generated (time-based freshness) or verify that the 245 Echo option was generated after a specific event (event-based 246 freshness). As the request is bound to the Echo option value, the 247 server can determine that the request is not older that the Echo 248 option value. 250 When the Echo option is used with OSCORE [RFC8613] it MAY be an Inner 251 or Outer option, and the Inner and Outer values are independent. 252 OSCORE servers MUST only produce Inner Echo options unless they are 253 merely testing for reachability of the client (the same as proxies 254 may do). The Inner option is encrypted and integrity protected 255 between the endpoints, whereas the Outer option is not protected by 256 OSCORE and visible between the endpoints to the extent it is not 257 protected by some other security protocol. E.g. in the case of DTLS 258 hop-by-hop between the endpoints, the Outer option is visible to 259 proxies along the path. 261 2.3. Echo Processing 263 The Echo option MAY be included in any request or response (see 264 Section 2.4 for different applications). 266 The application decides under what conditions a CoAP request to a 267 resource is required to be fresh. These conditions can for example 268 include what resource is requested, the request method and other data 269 in the request, and conditions in the environment such as the state 270 of the server or the time of the day. 272 If a certain request is required to be fresh, the request does not 273 contain a fresh Echo option value, and the server cannot verify the 274 freshness of the request in some other way, the server MUST NOT 275 process the request further and SHOULD send a 4.01 Unauthorized 276 response with an Echo option. The server MAY include the same Echo 277 option value in several different response messages and to different 278 clients. Examples of this could be time-based freshness when several 279 responses are sent closely after each other or event-based freshness 280 with no event taking place between the responses. 282 The server may use request freshness provided by the Echo option to 283 verify the aliveness of a client or to synchronize state. The server 284 may also include the Echo option in a response to force a client to 285 demonstrate reachability at its claimed network address. Note that 286 the Echo option does not bind a request to any particular previous 287 response, but provides an indication that the client had access to 288 the previous response at the time when it created the request. 290 Upon receiving a 4.01 Unauthorized response with the Echo option, the 291 client SHOULD resend the original request with the addition of an 292 Echo option with the received Echo option value. The client MAY send 293 a different request compared to the original request. Upon receiving 294 any other response with the Echo option, the client SHOULD echo the 295 Echo option value in the next request to the server. The client MAY 296 include the same Echo option value in several different requests to 297 the server. 299 A client MUST only send Echo values to endpoints it received them 300 from (where as defined in [RFC7252] Section 1.2, the security 301 association is part of the endpoint). In OSCORE processing, that 302 means sending Echo values from Outer options (or from non-OSCORE 303 responses) back in Outer options, and those from Inner options in 304 Inner options in the same security context. 306 Upon receiving a request with the Echo option, the server determines 307 if the request is required to be fresh. If not, the Echo option MAY 308 be ignored. If the request is required to be fresh and the server 309 cannot verify the freshness of the request in some other way, the 310 server MUST use the Echo option to verify that the request is fresh. 311 If the server cannot verify that the request is fresh, the request is 312 not processed further, and an error message MAY be sent. The error 313 message SHOULD include a new Echo option. 315 One way for the server to verify freshness is that to bind the Echo 316 value to a specific point in time and verify that the request is not 317 older than a certain threshold T. The server can verify this by 318 checking that (t1 - t0) < T, where t1 is the request receive time and 319 t0 is the time when the Echo option value was generated. An example 320 message flow is shown in Figure 2. 322 Client Server 323 | | 324 +------>| Code: 0.03 (PUT) 325 | PUT | Token: 0x41 326 | | Uri-Path: lock 327 | | Payload: 0 (Unlock) 328 | | 329 |<------+ Code: 4.01 (Unauthorized) 330 | 4.01 | Token: 0x41 331 | | Echo: 0x437468756c687521 (t0) 332 | | 333 +------>| t1 Code: 0.03 (PUT) 334 | PUT | Token: 0x42 335 | | Uri-Path: lock 336 | | Echo: 0x437468756c687521 (t0) 337 | | Payload: 0 (Unlock) 338 | | 339 |<------+ Code: 2.04 (Changed) 340 | 2.04 | Token: 0x42 341 | | 343 Figure 2: Example Message Flow for Time-Based Freshness 345 Another way for the server to verify freshness is to maintain a cache 346 of values associated to events. The size of the cache is defined by 347 the application. In the following we assume the cache size is 1, in 348 which case freshness is defined as no new event has taken place. At 349 each event a new value is written into the cache. The cache values 350 MUST be different for all practical purposes. The server verifies 351 freshness by checking that e0 equals e1, where e0 is the cached value 352 when the Echo option value was generated, and e1 is the cached value 353 at the reception of the request. An example message flow is shown in 354 Figure 3. 356 Client Server 357 | | 358 +------>| Code: 0.03 (PUT) 359 | PUT | Token: 0x41 360 | | Uri-Path: lock 361 | | Payload: 0 (Unlock) 362 | | 363 |<------+ Code: 4.01 (Unauthorized) 364 | 4.01 | Token: 0x41 365 | | Echo: 0x436F6D69632053616E73 (e0) 366 | | 367 +------>| e1 Code: 0.03 (PUT) 368 | PUT | Token: 0x42 369 | | Uri-Path: lock 370 | | Echo: 0x436F6D69632053616E73 (e0) 371 | | Payload: 0 (Unlock) 372 | | 373 |<------+ Code: 2.04 (Changed) 374 | 2.04 | Token: 0x42 375 | | 377 Figure 3: Example Message Flow for Event-Based Freshness 379 When used to serve freshness requirements (including client aliveness 380 and state synchronizing), the Echo option value MUST be integrity 381 protected between the intended endpoints, e.g. using DTLS, TLS, or an 382 OSCORE Inner option ([RFC8613]). When used to demonstrate 383 reachability at a claimed network address, the Echo option SHOULD 384 contain the client's network address, but MAY be unprotected. 386 A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on 387 forwarded ones that had no Echo option or ones generated by the proxy 388 (from cache or as an error). If it does so, it MUST remove the Echo 389 option it recognizes as one generated by itself on follow-up 390 requests. However, it MUST relay the Echo option of responses 391 unmodified, and MUST relay the Echo option of requests it does not 392 recognize as generated by itself unmodified. 394 The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, 395 especially if they have reason to assume that access may require it 396 (e.g. because it is a PUT or POST); how this is determined is out of 397 scope for this document. The CoAP client side of HTTP-to-CoAP 398 proxies SHOULD respond to Echo challenges themselves if they know 399 from the recent establishing of the connection that the HTTP request 400 is fresh. Otherwise, they SHOULD respond with 503 Service 401 Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive 402 connection. They MAY also use other mechanisms to establish 403 freshness of the HTTP request that are not specified here. 405 2.4. Applications of the Echo Option 407 1. Actuation requests often require freshness guarantees to avoid 408 accidental or malicious delayed actuator actions. In general, 409 all non-safe methods (e.g. POST, PUT, DELETE) may require 410 freshness guarantees for secure operation. 412 * The same Echo value may be used for multiple actuation 413 requests to the same server, as long as the total round-trip 414 time since the Echo option value was generated is below the 415 freshness threshold. 417 * For actuator applications with low delay tolerance, to avoid 418 additional round-trips for multiple requests in rapid 419 sequence, the server may include the Echo option with a new 420 value even in a successful response to a request, 421 irrespectively of whether the request contained an Echo option 422 or not. The client then uses the Echo option with the new 423 value in the next actuation request, and the server compares 424 the receive time accordingly. 426 2. A server may use the Echo option to synchronize properties (such 427 as state or time) with a requesting client. A server MUST NOT 428 synchronize a property with a client which is not the authority 429 of the property being synchronized. E.g. if access to a server 430 resource is dependent on time, then server MUST NOT synchronize 431 time with a client requesting access unless it is time authority 432 for the server. 434 * If a server reboots during operation it may need to 435 synchronize state or time before continuing the interaction. 436 For example, with OSCORE it is possible to reuse a partly 437 persistently stored security context by synchronizing the 438 Partial IV (sequence number) using the Echo option, see 439 Section 7.5 of [RFC8613]. 441 * A device joining a CoAP group communication [RFC7390] 442 protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be 443 required to initially verify freshness and synchronize state 444 or time with a client by using the Echo option in a unicast 445 response to a multicast request. The client receiving the 446 response with the Echo option includes the Echo option with 447 the same value in a request, either in a unicast request to 448 the responding server, or in a subsequent group request. In 449 the latter case, the Echo option will be ignored except by the 450 responding server. 452 3. A server that sends large responses to unauthenticated peers 453 SHOULD mitigate amplification attacks such as described in 454 Section 11.3 of [RFC7252] (where an attacker would put a victim's 455 address in the source address of a CoAP request). For this 456 purpose, a server MAY ask a client to Echo its request to verify 457 its source address. This needs to be done only once per peer and 458 limits the range of potential victims from the general Internet 459 to endpoints that have been previously in contact with the 460 server. For this application, the Echo option can be used in 461 messages that are not integrity protected, for example during 462 discovery. 464 * In the presence of a proxy, a server will not be able to 465 distinguish different origin client endpoints. Following from 466 the recommendation above, a proxy that sends large responses 467 to unauthenticated peers SHOULD mitigate amplification 468 attacks. The proxy MAY use Echo to verify origin reachability 469 as described in Section 2.3. The proxy MAY forward idempotent 470 requests immediately to have a cached result available when 471 the client's Echoed request arrives. 473 4. A server may want to use the request freshness provided by the 474 Echo to verify the aliveness of a client. Note that in a 475 deployment with hop-by-hop security and proxies, the server can 476 only verify aliveness of the closest proxy. 478 3. Protecting Message Bodies using Request Tags 480 3.1. Fragmented Message Body Integrity 482 CoAP was designed to work over unreliable transports, such as UDP, 483 and include a lightweight reliability feature to handle messages 484 which are lost or arrive out of order. In order for a security 485 protocol to support CoAP operations over unreliable transports, it 486 must allow out-of-order delivery of messages using e.g. a sliding 487 replay window such as described in Section 4.1.2.6 of DTLS 488 ([RFC6347]). 490 The block-wise transfer mechanism [RFC7959] extends CoAP by defining 491 the transfer of a large resource representation (CoAP message body) 492 as a sequence of blocks (CoAP message payloads). The mechanism uses 493 a pair of CoAP options, Block1 and Block2, pertaining to the request 494 and response payload, respectively. The block-wise functionality 495 does not support the detection of interchanged blocks between 496 different message bodies to the same resource having the same block 497 number. This remains true even when CoAP is used together with a 498 security protocol such as DTLS or OSCORE, within the replay window 499 ([I-D.mattsson-core-coap-actuators]), which is a vulnerability of 500 CoAP when using RFC7959. 502 A straightforward mitigation of mixing up blocks from different 503 messages is to use unique identifiers for different message bodies, 504 which would provide equivalent protection to the case where the 505 complete body fits into a single payload. The ETag option [RFC7252], 506 set by the CoAP server, identifies a response body fragmented using 507 the Block2 option. 509 3.2. The Request-Tag Option 511 This document defines the Request-Tag option for identifying request 512 bodies, similar to ETag, but ephemeral and set by the CoAP client. 513 The Request-Tag is intended for use as a short-lived identifier for 514 keeping apart distinct block-wise request operations on one resource 515 from one client, addressing the issue described in Section 3.1. It 516 enables the receiving server to reliably assemble request payloads 517 (blocks) to their message bodies, and, if it chooses to support it, 518 to reliably process simultaneous block-wise request operations on a 519 single resource. The requests must be integrity protected if they 520 should protect against interchange of blocks between different 521 message bodies. The Request-Tag option is only used in requests that 522 carry the Block1 option, and in Block2 requests following these. 524 In essence, it is an implementation of the "proxy-safe elective 525 option" used just to "vary the cache key" as suggested in [RFC7959] 526 Section 2.4. 528 3.2.1. Request-Tag Option Format 530 The Request-Tag option is not critical, is safe to forward, 531 repeatable, and part of the cache key, see Figure 4, which extends 532 Table 4 of [RFC7252]). 534 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 535 | No. | C | U | N | R | Name | Format | Len. | Default | E | U | 536 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 537 | TBD | | | | x | Request-Tag | opaque | 0-8 | (none) | x | x | 538 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 540 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 541 E = Encrypt and Integrity Protect (when using OSCORE) 543 Figure 4: Request-Tag Option Summary 545 Request-Tag, like the block options, is both a class E and a class U 546 option in terms of OSCORE processing (see Section 4.1 of [RFC8613]): 548 The Request-Tag MAY be an Inner or Outer option. It influences the 549 Inner or Outer block operation, respectively. The Inner and Outer 550 values are therefore independent of each other. The Inner option is 551 encrypted and integrity protected between client and server, and 552 provides message body identification in case of end-to-end 553 fragmentation of requests. The Outer option is visible to proxies 554 and labels message bodies in case of hop-by-hop fragmentation of 555 requests. 557 The Request-Tag option is only used in the request messages of block- 558 wise operations. 560 The Request-Tag mechanism can be applied independently on the server 561 and client sides of CoAP-to-CoAP proxies as are the block options, 562 though given it is safe to forward, a proxy is free to just forward 563 it when processing an operation. CoAP-to-HTTP proxies and HTTP-to- 564 CoAP proxies can use Request-Tag on their CoAP sides; it is not 565 applicable to HTTP requests. 567 3.3. Request-Tag Processing by Servers 569 The Request-Tag option does not require any particular processing on 570 the server side outside of the processing already necessary for any 571 unknown elective proxy-safe cache-key option: The option varies the 572 properties that distinguish block-wise operations (which includes all 573 options except elective NoCacheKey and except Block1/2), and thus the 574 server can not treat messages with a different list of Request-Tag 575 options as belonging to the same operation. 577 To keep utilizing the cache, a server (including proxies) MAY discard 578 the Request-Tag option from an assembled block-wise request when 579 consulting its cache, as the option relates to the operation-on-the- 580 wire and not its semantics. For example, a FETCH request with the 581 same body as an older one can be served from the cache if the older's 582 Max-Age has not expired yet, even if the second operation uses a 583 Request-Tag and the first did not. (This is similar to the situation 584 about ETag in that it is formally part of the cache key, but 585 implementations that are aware of its meaning can cache more 586 efficiently, see [RFC7252] Section 5.4.2). 588 A server receiving a Request-Tag MUST treat it as opaque and make no 589 assumptions about its content or structure. 591 Two messages carrying the same Request-Tag is a necessary but not 592 sufficient condition for being part of the same operation. For one, 593 a server may still treat them as independent messages when it sends 594 2.01/2.04 responses for every block. Also, a client that lost 595 interest in an old operation but wants to start over can overwrite 596 the server's old state with a new initial (num=0) Block1 request and 597 the same Request-Tag under some circumstances. Likewise, that 598 results in the new message not being part of he old operation. 600 As it has always been, a server that can only serve a limited number 601 of block-wise operations at the same time can delay the start of the 602 operation by replying with 5.03 (Service unavailable) and a Max-Age 603 indicating how long it expects the existing operation to go on, or it 604 can forget about the state established with the older operation and 605 respond with 4.08 (Request Entity Incomplete) to later blocks on the 606 first operation. 608 3.4. Setting the Request-Tag 610 For each separate block-wise request operation, the client can choose 611 a Request-Tag value, or choose not to set a Request-Tag. It needs to 612 be set to the same value (or unset) in all messages belonging to the 613 same operation, as otherwise they are treated as separate operations 614 by the server. 616 Starting a request operation matchable to a previous operation and 617 even using the same Request-Tag value is called request tag 618 recycling. The absence of a Request-Tag option is viewed as a value 619 distinct from all values with a single Request-Tag option set; 620 starting a request operation matchable to a previous operation where 621 neither has a Request-Tag option therefore constitutes request tag 622 recycling just as well (also called "recycling the absent option"). 624 Clients that use Request-Tag for a particular purpose (like in 625 Section 3.5) MUST NOT recycle a request tag unless the first 626 operation has concluded. What constitutes a concluded operation 627 depends on that purpose, and is defined there. 629 When Block1 and Block2 are combined in an operation, the Request-Tag 630 of the Block1 phase is set in the Block2 phase as well for otherwise 631 the request would have a different set of options and would not be 632 recognized any more. 634 Clients are encouraged to generate compact messages. This means 635 sending messages without Request-Tag options whenever possible, and 636 using short values when the absent option can not be recycled. 638 The Request-Tag options MAY be present in request messages that carry 639 a Block2 option even if those messages are not part of a blockwise 640 request operation (this is to allow the operation described in 641 Section 3.5.3). The Request-Tag option MUST NOT be present in 642 response messages, and MUST NOT be present if neither the Block1 nor 643 the Block2 option is present. 645 3.5. Applications of the Request-Tag Option 647 3.5.1. Body Integrity Based on Payload Integrity 649 When a client fragments a request body into multiple message 650 payloads, even if the individual messages are integrity protected, it 651 is still possible for a man-in-the-middle to maliciously replace a 652 later operation's blocks with an earlier operation's blocks (see 653 Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the 654 integrity protection of each block does not extend to the operation's 655 request body. 657 In order to gain that protection, use the Request-Tag mechanism as 658 follows: 660 o The individual exchanges MUST be integrity protected end-to-end 661 between client and server. 663 o The client MUST NOT recycle a request tag in a new operation 664 unless the previous operation matchable to the new one has 665 concluded. 667 If any future security mechanisms allow a block-wise transfer to 668 continue after an endpoint's details (like the IP address) have 669 changed, then the client MUST consider messages sent to _any_ 670 endpoint address within the new operation's security context. 672 o The client MUST NOT regard a block-wise request operation as 673 concluded unless all of the messages the client previously sent in 674 the operation have been confirmed by the message integrity 675 protection mechanism, or are considered invalid by the server if 676 replayed. 678 Typically, in OSCORE, these confirmations can result either from 679 the client receiving an OSCORE response message matching the 680 request (an empty ACK is insufficient), or because the message's 681 sequence number is old enough to be outside the server's receive 682 window. 684 In DTLS, this can only be confirmed if the request message was not 685 retransmitted, and was responded to. 687 Authors of other documents (e.g. applications of [RFC8613]) are 688 invited to mandate this behavior for clients that execute block-wise 689 interactions over secured transports. In this way, the server can 690 rely on a conforming client to set the Request-Tag option when 691 required, and thereby conclude on the integrity of the assembled 692 body. 694 Note that this mechanism is implicitly implemented when the security 695 layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). 696 This is because with each message, any earlier message can not be 697 replayed any more, so the client never needs to set the Request-Tag 698 option unless it wants to perform concurrent operations. 700 3.5.2. Multiple Concurrent Block-wise Operations 702 CoAP clients, especially CoAP proxies, may initiate a block-wise 703 request operation to a resource, to which a previous one is already 704 in progress, which the new request should not cancel. A CoAP proxy 705 would be in such a situation when it forwards operations with the 706 same cache-key options but possibly different payloads. 708 For those cases, Request-Tag is the proxy-safe elective option 709 suggested in [RFC7959] Section 2.4 last paragraph. 711 When initializing a new block-wise operation, a client has to look at 712 other active operations: 714 o If any of them is matchable to the new one, and the client neither 715 wants to cancel the old one nor postpone the new one, it can pick 716 a Request-Tag value (including the absent option) that is not in 717 use by the other matchable operations for the new operation. 719 o Otherwise, it can start the new operation without setting the 720 Request-Tag option on it. 722 3.5.3. Simplified Block-Wise Handling for Constrained Proxies 724 The Block options were defined to be unsafe to forward because a 725 proxy that would forward blocks as plain messages would risk mixing 726 up clients' requests. 728 The Request-Tag option provides a very simple way for a proxy to keep 729 them separate: if it appends a Request-Tag that is particular to the 730 requesting endpoint to all request carrying any Block option, it does 731 not need to keep track of any further block state. 733 This is particularly useful to proxies that strive for stateless 734 operation as described in [I-D.ietf-core-stateless] Section 3.1. 736 3.6. Rationale for the Option Properties 738 The Request-Tag option can be elective, because to servers unaware of 739 the Request-Tag option, operations with differing request tags will 740 not be matchable. 742 The Request-Tag option can be safe to forward but part of the cache 743 key, because to proxies unaware of the Request-Tag option will 744 consider operations with differing request tags unmatchable but can 745 still forward them. 747 The Request-Tag option is repeatable because this easily allows 748 stateless proxies to "chain" their origin address. They can perform 749 the steps of Section 3.5.3 without the need to create an option value 750 that is the concatenation of the received option and their own value, 751 and can simply add a new Request-Tag option unconditionally. 753 In draft versions of this document, the Request-Tag option used to be 754 critical and unsafe to forward. That design was based on an 755 erroneous understanding of which blocks could be composed according 756 to [RFC7959]. 758 3.7. Rationale for Introducing the Option 760 An alternative that was considered to the Request-Tag option for 761 coping with the problem of fragmented message body integrity 762 (Section 3.5.1) was to update [RFC7959] to say that blocks could only 763 be assembled if their fragments' order corresponded to the sequence 764 numbers. 766 That approach would have been difficult to roll out reliably on DTLS 767 where many implementations do not expose sequence numbers, and would 768 still not prevent attacks like in [I-D.mattsson-core-coap-actuators] 769 Section 2.5.2. 771 3.8. Block2 / ETag Processing 773 The same security properties as in Section 3.5.1 can be obtained for 774 blockwise response operations. The threat model here is not an 775 attacker (because the response is made sure to belong to the current 776 request by the security layer), but blocks in the client's cache. 778 Rules stating that response body reassembly is conditional on 779 matching ETag values are already in place from Section 2.4 of 780 [RFC7959]. 782 To gain equivalent protection to Section 3.5.1, a server MUST use the 783 Block2 option in conjunction with the ETag option ([RFC7252], 784 Section 5.10.6), and MUST NOT use the same ETag value for different 785 representations of a resource. 787 4. Token Processing for Secure Request-Response Binding 789 4.1. Request-Response Binding 791 A fundamental requirement of secure REST operations is that the 792 client can bind a response to a particular request. If this is not 793 ensured, a client may erroneously associate the wrong response to a 794 request. The wrong response may be an old response for the same 795 resource or for a completely different resource (see e.g. 796 Section 2.3 of [I-D.mattsson-core-coap-actuators]). For example, a 797 request for the alarm status "GET /status" may be associated to a 798 prior response "on", instead of the correct response "off". 800 In HTTPS, this type of binding is always assured by the ordered and 801 reliable delivery as well as mandating that the server sends 802 responses in the same order that the requests were received. The 803 same is not true for CoAP where the server (or an attacker) can 804 return responses in any order and where there can be any number of 805 responses to a request (see e.g. [RFC7641]). In CoAP, concurrent 806 requests are differentiated by their Token. Note that the CoAP 807 Message ID cannot be used for this purpose since those are typically 808 different for REST request and corresponding response in case of 809 "separate response", see Section 2.2 of [RFC7252]. 811 CoAP [RFC7252] does not treat Token as a cryptographically important 812 value and does not give stricter guidelines than that the Tokens 813 currently "in use" SHOULD (not SHALL) be unique. If used with a 814 security protocol not providing bindings between requests and 815 responses (e.g. DTLS and TLS) Token reuse may result in situations 816 where a client matches a response to the wrong request. Note that 817 mismatches can also happen for other reasons than a malicious 818 attacker, e.g. delayed delivery or a server sending notifications to 819 an uninterested client. 821 A straightforward mitigation is to mandate clients to not reuse 822 Tokens until the traffic keys have been replaced. One easy way to 823 accomplish this is to implement the Token as a counter starting at 824 zero for each new or rekeyed secure connection. 826 4.2. Updated Token Processing Requirements for Clients 828 As described in Section 4.1, the client must be able to verify that a 829 response corresponds to a particular request. This section updates 830 the Token processing requirements for clients in [RFC7252] to always 831 assure a cryptographically secure binding of responses to requests 832 for secure REST operations like "coaps". The Token processing for 833 servers is not updated. Token processing in Section 5.3.1 of 834 [RFC7252] is updated by adding the following text: 836 When CoAP is used with a security protocol not providing bindings 837 between requests and responses, the Tokens have cryptographic 838 importance. The client MUST make sure that Tokens are not used in a 839 way so that responses risk being associated with the wrong request. 840 One easy way to accomplish this is to implement the Token (or part of 841 the Token) as a sequence number starting at zero for each new or 842 rekeyed secure connection, this approach SHOULD be followed. 844 5. Security Considerations 846 The availability of a secure pseudorandom number generator and truly 847 random seeds are essential for the security of the Echo option. If 848 no true random number generator is available, a truly random seed 849 must be provided from an external source. As each pseudoranom number 850 must only be used once, an implementation need to get a new truly 851 random seed after reboot, or continously store state in nonvolatile 852 memory, see ([RFC8613], Appendix B.1.1) for issues and solution 853 approaches for writing to nonvolatile memory. 855 A single active Echo value with 64 (pseudo-)random bits gives the 856 same theoretical security level as a 64-bit MAC (as used in e.g. 857 AES_128_CCM_8). The Echo option value MUST contain 32 858 (pseudo-)random bits that are not predictable for any other party 859 than the server, and SHOULD contain 64 (pseudo-)random bits. A 860 server MAY use different security levels for different uses cases 861 (client aliveness, request freshness, state synchronization, network 862 address reachability, etc.). 864 The security provided by the Echo and Request-Tag options depends on 865 the security protocol used. CoAP and HTTP proxies require (D)TLS to 866 be terminated at the proxies. The proxies are therefore able to 867 manipulate, inject, delete, or reorder options or packets. The 868 security claims in such architectures only hold under the assumption 869 that all intermediaries are fully trusted and have not been 870 compromised. 872 Servers SHOULD use a monotonic clock to generate timestamps and 873 compute round-trip times. Use of non-monotonic clocks is not secure 874 as the server will accept expired Echo option values if the clock is 875 moved backward. The server will also reject fresh Echo option values 876 if the clock is moved forward. Non-monotonic clocks MAY be used as 877 long as they have deviations that are acceptable given the freshness 878 requirements. If the deviations from a monotonic clock are known, it 879 may be possible to adjust the threshold accordingly. 881 An attacker may be able to affect the server's system time in various 882 ways such as setting up a fake NTP server or broadcasting false time 883 signals to radio-controlled clocks. 885 Servers MAY use the time since reboot measured in some unit of time. 886 Servers MAY reset the timer at certain times and MAY generate a 887 random offset applied to all timestamps. When resetting the timer, 888 the server MUST reject all Echo values that was created before the 889 reset. 891 Servers that use the List of Cached Random Values and Timestamps 892 method described in Appendix A may be vulnerable to resource 893 exhaustion attacks. One way to minimize state is to use the 894 Integrity Protected Timestamp method described in Appendix A. 896 5.1. Token reuse 898 Reusing Tokens in a way so that responses are guaranteed to not be 899 associated with the wrong request is not trivial as on-path attackers 900 may block, delay, and reorder messages, requests may be sent to 901 several servers, and servers may process requests in any order and 902 send many responses to the same request. The use of a sequence 903 number is therefore recommended when CoAP is used with a security 904 protocol that does not providing bindings between requests and 905 responses such as DTLS or TLS. 907 For a generic response to a confirmable request over DTLS, binding 908 can only be claimed without out-of-band knowledge if 910 o the original request was never retransmitted, 912 o the response was piggybacked in an Acknowledgement message (as a 913 confirmable or non-confirmable response may have been transmitted 914 multiple times), and 916 o if observation was used, the same holds for the registration, all 917 re-registrations, and the cancellation. 919 (In addition, for observations, any responses using that Token and a 920 DTLS sequence number earlier than the cancellation Acknowledgement 921 message need to be discarded. This is typically not supported in 922 DTLS implementations.) 924 In some setups, Tokens can be reused without the above constraints, 925 as a different component in the setup provides the associations: 927 o In CoAP over TLS, retransmissions are not handled by the CoAP 928 layer and the replay window size is always exactly 1. When a 929 client is sending TLS protected requests without Observe to a 930 single server, the client can reuse a Token as soon as the 931 previous response with that Token has been received. 933 o Requests whose responses are cryptographically bound to the 934 requests (like in OSCORE) can reuse Tokens indefinitely. 936 In all other cases, a sequence number approach is RECOMMENDED as per 937 Section 4. 939 Tokens that cannot be reused need to be handled appropriately. This 940 could be solved by increasing the Token as soon as the currently used 941 Token cannot be reused, or by keeping a list of all blacklisted 942 Tokens. 944 When the Token (or part of the Token) contains a sequence number, the 945 encoding of the sequence number has to be chosen in a way to avoid 946 any collisions. This is especially true when the Token contains more 947 information than just the sequence number, e.g. serialized state as 948 in [I-D.ietf-core-stateless]. 950 6. Privacy Considerations 952 Implementations SHOULD NOT put any privacy sensitive information in 953 the Echo or Request-Tag option values. Unencrypted timestamps MAY 954 reveal information about the server such as location or time since 955 reboot, or that the server will accept expired certificates. 956 Timestamps MAY be used if Echo is encrypted between the client and 957 the server, e.g. in the case of DTLS without proxies or when using 958 OSCORE with an Inner Echo option. 960 Like HTTP cookies, the Echo option could potentially be abused as a 961 tracking mechanism to link to different requests to the same client. 962 This is especially true for pre-emptive Echo values. Servers MUST 963 NOT use the Echo option to correlate requests for other purposes than 964 freshness and reachability. Clients only send Echo to the same from 965 which they were received. Compared to HTTP, CoAP clients are often 966 authenticated and non-mobile, and servers can therefore often 967 correlate requests based on the security context, the client 968 credentials, or the network address. When the Echo option increases 969 a server's ability to correlate requests, clients MAY discard all 970 pre-emptive Echo values. 972 7. IANA Considerations 974 This document adds the following option numbers to the "CoAP Option 975 Numbers" registry defined by [RFC7252]: 977 +--------+-------------+-------------------+ 978 | Number | Name | Reference | 979 +--------+-------------+-------------------+ 980 | TBD1 | Echo | [[this document]] | 981 | | | | 982 | TBD2 | Request-Tag | [[this document]] | 983 +--------+-------------+-------------------+ 985 Figure 5: CoAP Option Numbers 987 8. References 989 8.1. Normative References 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels", BCP 14, RFC 2119, 993 DOI 10.17487/RFC2119, March 1997, 994 . 996 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 997 Application Protocol (CoAP)", RFC 7252, 998 DOI 10.17487/RFC7252, June 2014, 999 . 1001 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1002 the Constrained Application Protocol (CoAP)", RFC 7959, 1003 DOI 10.17487/RFC7959, August 2016, 1004 . 1006 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1007 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1008 May 2017, . 1010 8.2. Informative References 1012 [I-D.ietf-core-oscore-groupcomm] 1013 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1014 "Group OSCORE - Secure Group Communication for CoAP", 1015 draft-ietf-core-oscore-groupcomm-05 (work in progress), 1016 July 2019. 1018 [I-D.ietf-core-stateless] 1019 Hartke, K., "Extended Tokens and Stateless Clients in the 1020 Constrained Application Protocol (CoAP)", draft-ietf-core- 1021 stateless-03 (work in progress), October 2019. 1023 [I-D.mattsson-core-coap-actuators] 1024 Mattsson, J., Fornehed, J., Selander, G., Palombini, F., 1025 and C. Amsuess, "Controlling Actuators with CoAP", draft- 1026 mattsson-core-coap-actuators-06 (work in progress), 1027 September 2018. 1029 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1030 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1031 January 2012, . 1033 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1034 the Constrained Application Protocol (CoAP)", RFC 7390, 1035 DOI 10.17487/RFC7390, October 2014, 1036 . 1038 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1039 Application Protocol (CoAP)", RFC 7641, 1040 DOI 10.17487/RFC7641, September 2015, 1041 . 1043 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1044 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1045 Application Protocol) over TCP, TLS, and WebSockets", 1046 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1047 . 1049 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1050 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1051 . 1053 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1054 "Object Security for Constrained RESTful Environments 1055 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1056 . 1058 Appendix A. Methods for Generating Echo Option Values 1060 The content and structure of the Echo option value are implementation 1061 specific and determined by the server. Two simple mechanisms for 1062 time-based freshness are outlined in this section, the first is 1063 RECOMMENDED in general, and the second is RECOMMENDED in case the 1064 Echo option is encrypted between the client and the server. 1066 Different mechanisms have different tradeoffs between the size of the 1067 Echo option value, the amount of server state, the amount of 1068 computation, and the security properties offered. A server MAY use 1069 different methods and security levels for different uses cases 1070 (client aliveness, request freshness, state synchronization, network 1071 address reachability, etc.). 1073 1. List of Cached Random Values and Timestamps. The Echo option 1074 value is a (pseudo-)random byte string. The server caches a list 1075 containing the random byte strings and their transmission times. 1076 Assuming 72-bit random values and 32-bit timestamps, the size of the 1077 Echo option value is 9 bytes and the amount of server state is 13n 1078 bytes, where n is the number of active Echo Option values. The 1079 security against an attacker guessing echo values is given by s = bit 1080 length of r - log2(n). The length of r and the maximum allowed n 1081 should be set so that the security level is harmonized with other 1082 parts of the deployment, e.g., s >= 64. If the server loses time 1083 continuity, e.g. due to reboot, the entries in the old list MUST be 1084 deleted. 1086 Echo option value: random value r 1087 Server State: random value r, timestamp t0 1089 2. Integrity Protected Timestamp. The Echo option value is an 1090 integrity protected timestamp. The timestamp can have different 1091 resolution and range. A 32-bit timestamp can e.g. give a resolution 1092 of 1 second with a range of 136 years. The (pseudo-)random secret 1093 key is generated by the server and not shared with any other party. 1094 The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit 1095 timestamp and a 64-bit MAC, the size of the Echo option value is 12 1096 bytes and the Server state is small and constant. The security 1097 against an attacker guessing echo values is given by the MAC length. 1098 If the server loses time continuity, e.g. due to reboot, the old key 1099 MUST be deleted and replaced by a new random secret key. Note that 1100 the privacy considerations in Section 6 may apply to the timestamp. 1101 A server MAY want to encrypt its timestamps, and, depending on the 1102 choice of encryption algorithms, this may require a nonce to be 1103 included in the Echo option value. 1105 Echo option value: timestamp t0, MAC(k, t0) 1106 Server State: secret key k 1108 Other mechanisms complying with the security and privacy 1109 considerations may be used. The use of encrypted timestamps in the 1110 Echo option increases security, but typically requires an IV to be 1111 included in the Echo option value, which adds overhead and makes the 1112 specification of such a mechanism slightly more complicated than the 1113 two mechanisms specified here. 1115 Appendix B. Request-Tag Message Size Impact 1117 In absence of concurrent operations, the Request-Tag mechanism for 1118 body integrity (Section 3.5.1) incurs no overhead if no messages are 1119 lost (more precisely: in OSCORE, if no operations are aborted due to 1120 repeated transmission failure; in DTLS, if no packages are lost), or 1121 when block-wise request operations happen rarely (in OSCORE, if there 1122 is always only one request block-wise operation in the replay 1123 window). 1125 In those situations, no message has any Request-Tag option set, and 1126 that can be recycled indefinitely. 1128 When the absence of a Request-Tag option can not be recycled any more 1129 within a security context, the messages with a present but empty 1130 Request-Tag option can be used (1 Byte overhead), and when that is 1131 used-up, 256 values from one byte long options (2 Bytes overhead) are 1132 available. 1134 In situations where those overheads are unacceptable (e.g. because 1135 the payloads are known to be at a fragmentation threshold), the 1136 absent Request-Tag value can be made usable again: 1138 o In DTLS, a new session can be established. 1140 o In OSCORE, the sequence number can be artificially increased so 1141 that all lost messages are outside of the replay window by the 1142 time the first request of the new operation gets processed, and 1143 all earlier operations can therefore be regarded as concluded. 1145 Appendix C. Change Log 1147 [ The editor is asked to remove this section before publication. ] 1149 o Changes since draft-ietf-core-echo-request-tag-07 (largely 1150 addressing Francesca's review): 1152 * Request tag: Explicitly limit "MUST NOT recycle" requirement to 1153 particular applications 1155 * Token reuse: upper-case RECOMMEND sequence number approach 1157 * Structure: Move per-topic introductions to respective chapters 1158 (this avoids long jumps by the reader) 1160 * Structure: Group Block2 / ETag section inside new fragmentation 1161 (formerly Request-Tag) section 1163 * More precise references into other documents 1165 * "concurrent operations": Emphasise that all here only matters 1166 between endpoint pairs 1168 * Freshness: Generalize wording away from time-based freshness 1170 * Echo: Emphasise that no binding between any particular pair of 1171 responses and requests is established 1173 * Echo: Add event-based example 1175 * Echo: Clarify when protection is needed 1177 * Request tag: Enhance wording around "not sufficient condition" 1179 * Request tag: Explicitly state when a tag needs to be set 1181 * Request tag: Clarification about permissibility of leaving the 1182 option absent 1184 * Security considerations: wall clock time -> system time (and 1185 remove inaccurate explanations) 1187 * Token reuse: describe blacklisting in a more implementation- 1188 independent way 1190 o Changes since draft-ietf-core-echo-request-tag-06: 1192 * Removed visible comment that should not be visible in Token 1193 reuse considerations. 1195 o Changes since draft-ietf-core-echo-request-tag-05: 1197 * Add privacy considerations on cookie-style use of Echo values 1199 * Add security considerations for token reuse 1201 * Add note in security considerations on use of nonvolatile 1202 memory when dealing with pseudorandom numbers 1204 * Appendix on echo generation: add a few words on up- and 1205 downsides of the encrypted timestamp alternative 1207 * Clarifications around Outer Echo: 1209 + Could be generated by the origin server to prove network 1210 reachability (but for most applications it MUST be inner) 1212 + Could be generated by intermediaries 1214 + Is answered by the client to the endpoint from which it 1215 received it (ie. Outer if received as Outer) 1217 * Clarification that a server can send Echo preemtively 1219 * Refer to stateless to explain what "more information than just 1220 the sequence number" could be 1222 * Remove explanations around 0.00 empty messags 1224 * Rewordings: 1226 + the attack: from "forging" to "guessing" 1228 + "freshness tokens" to "freshness indicators" (to avoid 1229 confusion with the Token) 1231 * Editorial fixes: 1233 + Abstract and introduction mention what is updated in RFC7252 1235 + Reference updates 1237 + Capitalization, spelling, terms from other documents 1239 o Changes since draft-ietf-core-echo-request-tag-04: 1241 * Editorial fixes 1243 + Moved paragraph on collision-free encoding of data in the 1244 Token to Security Considerations and rephrased it 1246 + "easiest" -> "one easy" 1248 o Changes since draft-ietf-core-echo-request-tag-03: 1250 * Mention Token processing changes in title 1252 * Abstract reworded 1254 * Clarify updates to Token processing 1256 * Describe security levels from Echo length 1258 * Allow non-monotonic clocks under certain conditions for 1259 freshness 1261 * Simplify freshness expressions 1263 * Describe when a Request-Tag can be set 1265 * Add note on application-level freshness mechanisms 1267 * Minor editorial changes 1269 o Changes since draft-ietf-core-echo-request-tag-02: 1271 * Define "freshness" 1273 * Note limitations of "aliveness" 1275 * Clarify proxy and OSCORE handling in presence of "echo" 1277 * Clarify when Echo values may be reused 1279 * Update security considerations 1281 * Various minor clarifications 1283 * Minor editorial changes 1285 o Major changes since draft-ietf-core-echo-request-tag-01: 1287 * Follow-up changes after the "relying on block-wise" change in 1288 -01: 1290 + Simplify the description of Request-Tag and matchability 1292 + Do not update RFC7959 any more 1294 * Make Request-Tag repeatable. 1296 * Add rationale on not relying purely on sequence numbers. 1298 o Major changes since draft-ietf-core-echo-request-tag-00: 1300 * Reworded the Echo section. 1302 * Added rules for Token processing. 1304 * Added security considerations. 1306 * Added actual IANA section. 1308 * Made Request-Tag optional and safe-to-forward, relying on 1309 block-wise to treat it as part of the cache-key 1311 * Dropped use case about OSCORE Outer-block-wise (the case went 1312 away when its Partial IV was moved into the Object-Security 1313 option) 1315 o Major changes since draft-amsuess-core-repeat-request-tag-00: 1317 * The option used for establishing freshness was renamed from 1318 "Repeat" to "Echo" to reduce confusion about repeatable 1319 options. 1321 * The response code that goes with Echo was changed from 4.03 to 1322 4.01 because the client needs to provide better credentials. 1324 * The interaction between the new option and (cross) proxies is 1325 now covered. 1327 * Two messages being "Request-Tag matchable" was introduced to 1328 replace the older concept of having a request tag value with 1329 its slightly awkward equivalence definition. 1331 Acknowledgments 1333 The authors want to thank Carsten Bormann, Francesca Palombini, and 1334 Jim Schaad for providing valuable input to the draft. 1336 Authors' Addresses 1338 Christian Amsuess 1340 Email: christian@amsuess.com 1342 John Preuss Mattsson 1343 Ericsson AB 1345 Email: john.mattsson@ericsson.com 1347 Goeran Selander 1348 Ericsson AB 1350 Email: goran.selander@ericsson.com