idnits 2.17.1 draft-ietf-core-echo-request-tag-04.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 mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2019) is 1853 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-04 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 2 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: September 25, 2019 Ericsson AB 7 March 24, 2019 9 CoAP: Echo, Request-Tag, and Token Processing 10 draft-ietf-core-echo-request-tag-04 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 updated Token processing requirements for clients 21 ensure secure binding of responses to requests when CoAP is used with 22 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 September 25, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Fragmented Message Body Integrity . . . . . . . . . . . . 4 61 1.3. Request-Response Binding . . . . . . . . . . . . . . . . 4 62 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. The Echo Option . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2. Echo Processing . . . . . . . . . . . . . . . . . . . . . 7 66 2.3. Applications . . . . . . . . . . . . . . . . . . . . . . 10 67 3. The Request-Tag Option . . . . . . . . . . . . . . . . . . . 11 68 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 11 69 3.2. Request-Tag Processing by Servers . . . . . . . . . . . . 12 70 3.3. Setting the Request-Tag . . . . . . . . . . . . . . . . . 13 71 3.4. Applications . . . . . . . . . . . . . . . . . . . . . . 14 72 3.4.1. Body Integrity Based on Payload Integrity . . . . . . 14 73 3.4.2. Multiple Concurrent Blockwise Operations . . . . . . 15 74 3.4.3. Simplified Block-Wise Handling for Constrained 75 Proxies . . . . . . . . . . . . . . . . . . . . . . . 16 76 3.5. Rationale for the Option Properties . . . . . . . . . . . 16 77 3.6. Rationale for Introducing the Option . . . . . . . . . . 16 78 4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 17 79 5. Token Processing . . . . . . . . . . . . . . . . . . . . . . 17 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 85 9.2. Informative References . . . . . . . . . . . . . . . . . 19 86 Appendix A. Methods for Generating Echo Option Values . . . . . 20 87 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 22 88 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22 89 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Introduction 94 The initial Constrained Application Protocol (CoAP) suite of 95 specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed 96 with the assumption that security could be provided on a separate 97 layer, in particular by using DTLS ([RFC6347]). However, for some 98 use cases, additional functionality or extra processing is needed to 99 support secure CoAP operations. This document specifies security 100 enhancements to the Constrained Application Protocol (CoAP). 102 This document specifies two CoAP options, the Echo option and the 103 Request-Tag option: The Echo option enables a CoAP server to verify 104 the freshness of a request, synchronize state, or force a client to 105 demonstrate reachability at its claimed network address. The 106 Request-Tag option allows the CoAP server to match message fragments 107 belonging to the same request, fragmented using the CoAP Block-Wise 108 Transfer mechanism, which mitigates attacks and enables concurrent 109 blockwise operations. These options in themselves do not replace the 110 need for a security protocol; they specify the format and processing 111 of data which, when integrity protected using e.g. DTLS ([RFC6347]), 112 TLS ([RFC8446]), or OSCORE ([I-D.ietf-core-object-security]), provide 113 the additional security features. 115 The document also updates the Token processing requirements for 116 clients specified in [RFC7252]. The updated processing ensures 117 secure binding of responses to requests when CoAP is used with 118 security, thus mitigating error cases and attacks where the client 119 may erroneously associate the wrong response to a request. 121 1.1. Request Freshness 123 A CoAP server receiving a request is in general not able to verify 124 when the request was sent by the CoAP client. This remains true even 125 if the request was protected with a security protocol, such as DTLS. 126 This makes CoAP requests vulnerable to certain delay attacks which 127 are particularly perilous in the case of actuators 128 ([I-D.mattsson-core-coap-actuators]). Some attacks can be mitigated 129 by establishing fresh session keys, e.g. performing a DTLS handshake 130 for each request, but in general this is not a solution suitable for 131 constrained environments, for example, due to increased message 132 overhead and latency. Additionally, if there are proxies, fresh DTLS 133 session keys between server and proxy does not say anything about 134 when the client made the request. In a general hop-by-hop setting, 135 freshness may need to be verified in each hop. 137 A straightforward mitigation of potential delayed requests is that 138 the CoAP server rejects a request the first time it appears and asks 139 the CoAP client to prove that it intended to make the request at this 140 point in time. The Echo option, defined in this document, specifies 141 such a mechanism which thereby enables a CoAP server to verify the 142 freshness of a request. This mechanism is not only important in the 143 case of actuators, or other use cases where the CoAP operations 144 require freshness of requests, but also in general for synchronizing 145 state between CoAP client and server, verify aliveness of the client, 146 or force a client to demonstrate reachability at its claimed network 147 address. The same functionality can be provided by echoing freshness 148 tokens in CoAP payloads, but this only works for methods and response 149 codes defined to have a payload. The Echo option provides a 150 convention to transfer freshness tokens that works for all methods 151 and response codes. 153 1.2. Fragmented Message Body Integrity 155 CoAP was designed to work over unreliable transports, such as UDP, 156 and include a lightweight reliability feature to handle messages 157 which are lost or arrive out of order. In order for a security 158 protocol to support CoAP operations over unreliable transports, it 159 must allow out-of-order delivery of messages using e.g. a sliding 160 replay window such as described in Section 4.1.2.6 of DTLS 161 ([RFC6347]). 163 The Block-Wise Transfer mechanism [RFC7959] extends CoAP by defining 164 the transfer of a large resource representation (CoAP message body) 165 as a sequence of blocks (CoAP message payloads). The mechanism uses 166 a pair of CoAP options, Block1 and Block2, pertaining to the request 167 and response payload, respectively. The blockwise functionality does 168 not support the detection of interchanged blocks between different 169 message bodies to the same resource having the same block number. 170 This remains true even when CoAP is used together with a security 171 protocol such as DTLS or OSCORE, within the replay window 172 ([I-D.mattsson-core-coap-actuators]), which is a vulnerability of 173 CoAP when using RFC7959. 175 A straightforward mitigation of mixing up blocks from different 176 messages is to use unique identifiers for different message bodies, 177 which would provide equivalent protection to the case where the 178 complete body fits into a single payload. The ETag option [RFC7252], 179 set by the CoAP server, identifies a response body fragmented using 180 the Block2 option. This document defines the Request-Tag option for 181 identifying request bodies, similar to ETag, but ephemeral and set by 182 the CoAP client. The Request-Tag option is only used in requests 183 that carry the Block1 option, and in Block2 requests following these. 185 1.3. Request-Response Binding 187 A fundamental requirement of secure REST operations is that the 188 client can bind a response to a particular request. If this is not 189 ensured, a client may erroneously associate the wrong response to a 190 request. The wrong response may be an old response for the same 191 resource or for a completely different resource (see e.g. 192 Section 2.3 of [I-D.mattsson-core-coap-actuators]). For example, a 193 request for the alarm status "GET /status" may be associated to a 194 prior response "on", instead of the correct response "off". 196 In HTTPS, this type of binding is always assured by the ordered and 197 reliable delivery as well as mandating that the server sends 198 responses in the same order that the requests were received. The 199 same is not true for CoAP where the server (or an attacker) can 200 return responses in any order and where there can be any number of 201 responses to a request (see e.g. [RFC7641]). In CoAP, concurrent 202 requests are differentiated by their Token. Note that the CoAP 203 Message ID cannot be used for this purpose since those are typically 204 different for REST request and corresponding response in case of 205 "separate response", see Section 2.2 of [RFC7252]. 207 CoAP [RFC7252] does not treat Token as a cryptographically important 208 value and does not give stricter guidelines than that the tokens 209 currently "in use" SHOULD (not SHALL) be unique. If used with a 210 security protocol not providing bindings between requests and 211 responses (e.g. DTLS and TLS) token reuse may result in situations 212 where a client matches a response to the wrong request. Note that 213 mismatches can also happen for other reasons than a malicious 214 attacker, e.g. delayed delivery or a server sending notifications to 215 an uninterested client. 217 A straightforward mitigation is to mandate clients to not reuse 218 tokens until the traffic keys have been replaced. The easiest way to 219 accomplish this is to implement the token as a counter starting at 220 zero for each new or rekeyed secure connection. This document 221 updates the Token processing in [RFC7252] to always assure a 222 cryptographically secure binding of responses to requests for secure 223 REST operations like "coaps". 225 1.4. Terminology 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 229 "OPTIONAL" in this document are to be interpreted as described in BCP 230 14 [RFC2119] [RFC8174] when, and only when, they appear in all 231 capitals, as shown here. 233 Unless otherwise specified, the terms "client" and "server" refers to 234 "CoAP client" and "CoAP server", respectively, as defined in 235 [RFC7252]. The term "origin server" is used as in [RFC7252]. The 236 term "origin client" is used in this document to denote the client 237 from which a request originates; to distinguish from clients in 238 proxies. 240 The terms "payload" and "body" of a message are used as in [RFC7959]. 241 The complete interchange of a request and a response body is called a 242 (REST) "operation". An operation fragmented using [RFC7959] is 243 called a "blockwise operation". A blockwise operation which is 244 fragmenting the request body is called a "blockwise request 245 operation". A blockwise operation which is fragmenting the response 246 body is called a "blockwise response operation". 248 Two request messages are said to be "matchable" if they occur between 249 the same endpoint pair, have the same code and the same set of 250 options except for elective NoCacheKey options and options involved 251 in block-wise transfer (Block1, Block2 and Request-Tag). Two 252 operations are said to be matchable if any of their messages are. 254 Two matchable blockwise operations are said to be "concurrent" if a 255 block of the second request is exchanged even though the client still 256 intends to exchange further blocks in the first operation. 257 (Concurrent blockwise request operations are impossible with the 258 options of [RFC7959] because the second operation's block overwrites 259 any state of the first exchange.). 261 The Echo and Request-Tag options are defined in this document. 263 2. The Echo Option 265 A fresh request is one whose age has not yet exceeded the freshness 266 requirements set by the server. The freshness requirements are 267 application specific and may vary based on resource, method, and 268 parameters outside of coap such as policies. The Echo option is a 269 lightweight challenge-response mechanism for CoAP, motivated by a 270 need for a server to verify freshness of a request as described in 271 Section 1.1. The Echo option value is a challenge from the server to 272 the client included in a CoAP response and echoed back to the server 273 in one or more CoAP requests. The Echo option provides a convention 274 to transfer freshness tokens that works for all CoAP methods and 275 response codes. 277 2.1. Option Format 279 The Echo Option is elective, safe-to-forward, not part of the cache- 280 key, and not repeatable, see Figure 1, which extends Table 4 of 281 [RFC7252]). 283 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 284 | No. | C | U | N | R | Name | Format | Len. | Default | E | U | 285 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 286 | TBD | | | x | | Echo | opaque | 4-40 | (none) | x | x | 287 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 289 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 290 E = Encrypt and Integrity Protect (when using OSCORE) 292 Figure 1: Echo Option Summary 294 [ Note to RFC editor: If this document is released before core- 295 object-security, then the following paragraph and the "E"/"U" columns 296 above need to move into core-object-security, as they are defined in 297 that draft. ] 299 The Echo option value is generated by a server, and its content and 300 structure are implementation specific. Different methods for 301 generating Echo option values are outlined in Appendix A. Clients 302 and intermediaries MUST treat an Echo option value as opaque and make 303 no assumptions about its content or structure. 305 When receiving an Echo option in a request, the server MUST be able 306 to verify when the Echo option value was generated. This implies 307 that the server MUST be able to verify that the Echo option value was 308 generated by the server or some other party that the server trusts. 309 Depending on the freshness requirements the server may verify exactly 310 when the Echo option value was generated (time-based freshness) or 311 verify that the Echo option was generated after a specific event 312 (event-based freshness). As the request is bound to the Echo option 313 value, the server can determine that the request is not older that 314 the Echo option value. 316 When the Echo option is used with OSCORE 317 [I-D.ietf-core-object-security] it MAY be an Inner or Outer option, 318 and the Inner and Outer values are independent. The Inner option is 319 encrypted and integrity protected between the endpoints, whereas the 320 Outer option is not protected by OSCORE and visible between the 321 endpoints to the extent it is not protected by some other security 322 protocol. E.g. in the case of DTLS hop-by-hop between the endpoints, 323 the Outer option is visible to proxies along the path. 325 2.2. Echo Processing 327 The Echo option MAY be included in any request or response (see 328 Section 2.3 for different applications), but the Echo option MUST NOT 329 be used with empty CoAP requests (i.e., Code=0.00). 331 The application decides under what conditions a CoAP request to a 332 resource is required to be fresh. These conditions can for example 333 include what resource is requested, the request method and other data 334 in the request, and conditions in the environment such as the state 335 of the server or the time of the day. 337 If a certain request is required to be fresh, the request does not 338 contain a fresh Echo option value, and the server cannot verify the 339 freshness of the request in some other way, the server MUST NOT 340 process the request further and SHOULD send a 4.01 Unauthorized 341 response with an Echo option. The server MAY include the same Echo 342 option value in several different responses and to different clients. 344 The server may use request freshness provided by the Echo option to 345 verify the aliveness of a client or to synchronize state. The server 346 may also include the Echo option in a response to force a client to 347 demonstrate reachability at its claimed network address. 349 Upon receiving a 4.01 Unauthorized response with the Echo option, the 350 client SHOULD resend the original request with the addition of an 351 Echo option with the received Echo option value. The client MAY send 352 a different request compared to the original request. Upon receiving 353 any other response with the Echo option, the client SHOULD echo the 354 Echo option value in the next request to the server. The client MAY 355 include the same Echo option value in several different requests to 356 the server. 358 Upon receiving a request with the Echo option, the server determines 359 if the request is required to be fresh. If not, the Echo option MAY 360 be ignored. If the request is required to be fresh and the server 361 cannot verify the freshness of the request in some other way, the 362 server MUST use the Echo option to verify that the request is fresh 363 enough. If the server cannot verify that the request is fresh 364 enough, the request is not processed further, and an error message 365 MAY be sent. The error message SHOULD include a new Echo option. 367 One way for the server to verify freshness is that to bind the Echo 368 value to a specific point in time and verify that the request is not 369 older than a certain threshold T. The server can verify this by 370 checking that (t1 - t0) < T, where t1 is the request receive time and 371 t0 is the time when the Echo option value was generated. An example 372 message flow is illustrated in Figure 2. 374 Client Server 375 | | 376 +------>| Code: 0.03 (PUT) 377 | PUT | Token: 0x41 378 | | Uri-Path: lock 379 | | Payload: 0 (Unlock) 380 | | 381 |<------+ Code: 4.01 (Unauthorized) 382 | 4.01 | Token: 0x41 383 | | Echo: 0x437468756c687521 (t0) 384 | | 385 +------>| t1 Code: 0.03 (PUT) 386 | PUT | Token: 0x42 387 | | Uri-Path: lock 388 | | Echo: 0x437468756c687521 (t0) 389 | | Payload: 0 (Unlock) 390 | | 391 |<------+ Code: 2.04 (Changed) 392 | 2.04 | Token: 0x42 393 | | 395 Figure 2: Example Echo Option Message Flow 397 When used to serve freshness requirements (including client aliveness 398 and state synchronizing), CoAP messages containing the Echo option 399 MUST be integrity protected between the intended endpoints, e.g. 400 using DTLS, TLS, or an OSCORE Inner option 401 ([I-D.ietf-core-object-security]). When used to demonstrate 402 reachability at a claimed network address, the Echo option SHOULD 403 contain the client's network address, but MAY be unprotected. 405 A CoAP-to-CoAP proxy MAY respond to requests with 4.01 with an Echo 406 option to ensure the client's reachability at its claimed address, 407 and MUST remove the Echo option it recognizes as one generated by 408 itself on follow-up requests. However, it MUST relay the Echo option 409 of responses unmodified, and MUST relay the Echo option of requests 410 it does not recognize as generated by itself unmodified. 412 The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, 413 especially if they have reason to assume that access may require it 414 (e.g. because it is a PUT or POST); how this is determined is out of 415 scope for this document. The CoAP client side of HTTP-to-CoAP 416 proxies SHOULD respond to Echo challenges themselves if they know 417 from the recent establishing of the connection that the HTTP request 418 is fresh. Otherwise, they SHOULD respond with 503 Service 419 Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive 420 connection. They MAY also use other mechanisms to establish 421 freshness of the HTTP request that are not specified here. 423 2.3. Applications 425 1. Actuation requests often require freshness guarantees to avoid 426 accidental or malicious delayed actuator actions. In general, 427 all non-safe methods (e.g. POST, PUT, DELETE) may require 428 freshness guarantees for secure operation. 430 * The same Echo value may be used for multiple actuation 431 requests to the same server, as long as the total round-trip 432 time since the Echo option value was generated is below the 433 freshness threshold. 435 * For actuator applications with low delay tolerance, to avoid 436 additional round-trips for multiple requests in rapid 437 sequence, the server may include the Echo option with a new 438 value in response to a request containing the Echo option. 439 The client then uses the Echo option with the new value in the 440 next actuation request, and the server compares the receive 441 time accordingly. 443 2. A server may use the Echo option to synchronize state or time 444 with a requesting client. A server MUST NOT synchronize state or 445 time with clients which are not the authority of the property 446 being synchronized. E.g. if access to a server resource is 447 dependent on time, then the client MUST NOT set the time of the 448 server. 450 * If a server reboots during operation it may need to 451 synchronize state or time before continuing the interaction. 452 For example, with OSCORE it is possible to reuse a partly 453 persistently stored security context by synchronizing the 454 Partial IV (sequence number) using the Echo option, see 455 Section 7.5 of [I-D.ietf-core-object-security]. 457 * A device joining a CoAP group communication [RFC7390] 458 protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be 459 required to initially verify freshness and synchronize state 460 or time with a client by using the Echo option in a unicast 461 response to a multicast request. The client receiving the 462 response with the Echo option includes the Echo option with 463 the same value in a request, either in a unicast request to 464 the responding server, or in a subsequent group request. In 465 the latter case, the Echo option will be ignored expect by 466 responding server. 468 3. A server that sends large responses to unauthenticated peers 469 SHOULD mitigate amplification attacks such as described in 470 Section 11.3 of [RFC7252] (where an attacker would put a victim's 471 address in the source address of a CoAP request). For this 472 purpose, a server MAY ask a client to Echo its request to verify 473 its source address. This needs to be done only once per peer and 474 limits the range of potential victims from the general Internet 475 to endpoints that have been previously in contact with the 476 server. For this application, the Echo option can be used in 477 messages that are not integrity protected, for example during 478 discovery. 480 * In the presence of a proxy, a server will not be able to 481 distinguish different origin client endpoints. Following from 482 the recommendation above, a proxy that sends large responses 483 to unauthenticated peers SHOULD mitigate amplification 484 attacks. The proxy MAY use Echo to verify origin reachability 485 as described in Section 2.2. The proxy MAY forward idempotent 486 requests immediately to have a cached result available when 487 the client's Echoed request arrives. 489 4. A server may want to use the request freshness provided by the 490 Echo to verify the aliveness of a client. Note that in a 491 deployment with hop-by-hop security and proxies, the server can 492 only verify aliveness of the closest proxy. 494 3. The Request-Tag Option 496 The Request-Tag is intended for use as a short-lived identifier for 497 keeping apart distinct blockwise request operations on one resource 498 from one client, addressing the issue described in Section 1.2. It 499 enables the receiving server to reliably assemble request payloads 500 (blocks) to their message bodies, and, if it chooses to support it, 501 to reliably process simultaneous blockwise request operations on a 502 single resource. The requests must be integrity protected in order 503 to protect against interchange of blocks between different message 504 bodies. 506 In essence, it is an implementation of the "proxy-safe elective 507 option" used just to "vary the cache key" as suggested in [RFC7959] 508 Section 2.4. 510 3.1. Option Format 512 The Request-Tag option is not critical, is safe to forward, 513 repeatable, and part of the cache key, see Figure 3, which extends 514 Table 4 of [RFC7252]). 516 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 517 | No. | C | U | N | R | Name | Format | Len. | Default | E | U | 518 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 519 | TBD | | | | x | Request-Tag | opaque | 0-8 | (none) | x | x | 520 +-----+---+---+---+---+-------------+--------+------+---------+---+---+ 522 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 523 E = Encrypt and Integrity Protect (when using OSCORE) 525 Figure 3: Request-Tag Option Summary 527 [ Note to RFC editor: If this document is released before core- 528 object-security, then the following paragraph and the "E"/"U" columns 529 above need to move into core-object-security, as they are defined in 530 that draft. ] 532 Request-Tag, like the block options, is both a class E and a class U 533 option in terms of OSCORE processing (see Section 4.1 of 534 [I-D.ietf-core-object-security]): The Request-Tag MAY be an inner or 535 outer option. It influences the inner or outer block operation, 536 respectively. The inner and outer values are therefore independent 537 of each other. The inner option is encrypted and integrity protected 538 between client and server, and provides message body identification 539 in case of end-to-end fragmentation of requests. The outer option is 540 visible to proxies and labels message bodies in case of hop-by-hop 541 fragmentation of requests. 543 The Request-Tag option is only used in the request messages of 544 blockwise operations. 546 The Request-Tag mechanism can be applied independently on the server 547 and client sides of CoAP-to-CoAP proxies as are the block options, 548 though given it is safe to forward, a proxy is free to just forward 549 it when processing an operation. CoAP-to-HTTP proxies and HTTP-to- 550 CoAP proxies can use Request-Tag on their CoAP sides; it is not 551 applicable to HTTP requests. 553 3.2. Request-Tag Processing by Servers 555 The Request-Tag option does not require any particular processing on 556 the server side outside of the processing already necessary for any 557 unknown elective proxy-safe cache-key option: The option varies the 558 properties that distinguish blockwise operations (which includes all 559 options except elective NoCacheKey and except Block1/2), and thus the 560 server can not treat messages with a different list of Request-Tag 561 options as belonging to the same operation. 563 To keep utilizing the cache, a server (including proxies) MAY discard 564 the Request-Tag option from an assembled block-wise request when 565 consulting its cache, as the option relates to the operation-on-the- 566 wire and not its semantics. For example, a FETCH request with the 567 same body as an older one can be served from the cache if the older's 568 Max-Age has not expired yet, even if the second operation uses a 569 Request-Tag and the first did not. (This is similar to the situation 570 about ETag in that it is formally part of the cache key, but 571 implementations that are aware of its meaning can cache more 572 efficiently, see [RFC7252] Section 5.4.2). 574 A server receiving a Request-Tag MUST treat it as opaque and make no 575 assumptions about its content or structure. 577 Two messages carrying the same Request-Tag is a necessary but not 578 sufficient condition for being part of the same operation. They can 579 still be treated as independent messages by the server (e.g. when it 580 sends 2.01/2.04 responses for every block), or initiate a new 581 operation (overwriting kept context) when the later message carries 582 Block1 number 0. 584 As it has always been, a server that can only serve a limited number 585 of block-wise operations at the same time can delay the start of the 586 operation by replying with 5.03 (Service unavailable) and a Max-Age 587 indicating how long it expects the existing operation to go on, or it 588 can forget about the state established with the older operation and 589 respond with 4.08 (Request Entity Incomplete) to later blocks on the 590 first operation. 592 3.3. Setting the Request-Tag 594 For each separate blockwise request operation, the client can choose 595 a Request-Tag value, or choose not to set a Request-Tag. Starting a 596 request operation matchable to a previous operation and even using 597 the same Request-Tag value is called request tag recycling. The 598 absence of a Request-Tag option is viewed as a value distinct from 599 all values with a single Request-Tag option set; starting a request 600 operation matchable to a previous operation where neither has a 601 Request-Tag option therefore constitutes request tag recycling just 602 as well (also called "recycling the absent option"). 604 Clients MUST NOT recycle a request tag unless the first operation has 605 concluded. What constitutes a concluded operation depends on the 606 application, and is outlined individually in Section 3.4. 608 When Block1 and Block2 are combined in an operation, the Request-Tag 609 of the Block1 phase is set in the Block2 phase as well for otherwise 610 the request would have a different set of options and would not be 611 recognized any more. 613 Clients are encouraged to generate compact messages. This means 614 sending messages without Request-Tag options whenever possible, and 615 using short values when the absent option can not be recycled. 617 The Request-Tag options MAY be present in request messages that carry 618 a Block2 option even if those messages are not part of a blockwise 619 request operation (this is to allow the operation described in 620 Section 3.4.3). The Request-Tag option MUST NOT be present in 621 response messages, and MUST NOT be present if neither the Block1 nor 622 the Block2 option is present. 624 3.4. Applications 626 3.4.1. Body Integrity Based on Payload Integrity 628 When a client fragments a request body into multiple message 629 payloads, even if the individual messages are integrity protected, it 630 is still possible for a man-in-the-middle to maliciously replace a 631 later operation's blocks with an earlier operation's blocks (see 632 Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the 633 integrity protection of each block does not extend to the operation's 634 request body. 636 In order to gain that protection, use the Request-Tag mechanism as 637 follows: 639 o The individual exchanges MUST be integrity protected end-to-end 640 between client and server. 642 o The client MUST NOT recycle a request tag in a new operation 643 unless the previous operation matchable to the new one has 644 concluded. 646 If any future security mechanisms allow a block-wise transfer to 647 continue after an endpoint's details (like the IP address) have 648 changed, then the client MUST consider messages sent to _any_ 649 endpoint address within the new operation's security context. 651 o The client MUST NOT regard a blockwise request operation as 652 concluded unless all of the messages the client previously sent in 653 the operation have been confirmed by the message integrity 654 protection mechanism, or are considered invalid by the server if 655 replayed. 657 Typically, in OSCORE, these confirmations can result either from 658 the client receiving an OSCORE response message matching the 659 request (an empty ACK is insufficient), or because the message's 660 sequence number is old enough to be outside the server's receive 661 window. 663 In DTLS, this can only be confirmed if the request message was not 664 retransmitted, and was responded to. 666 Authors of other documents (e.g. [I-D.ietf-core-object-security]) 667 are invited to mandate this behavior for clients that execute 668 blockwise interactions over secured transports. In this way, the 669 server can rely on a conforming client to set the Request-Tag option 670 when required, and thereby conclude on the integrity of the assembled 671 body. 673 Note that this mechanism is implicitly implemented when the security 674 layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). 675 This is because with each message, any earlier message can not be 676 replayed any more, so the client never needs to set the Request-Tag 677 option unless it wants to perform concurrent operations. 679 3.4.2. Multiple Concurrent Blockwise Operations 681 CoAP clients, especially CoAP proxies, may initiate a blockwise 682 request operation to a resource, to which a previous one is already 683 in progress, which the new request should not cancel. A CoAP proxy 684 would be in such a situation when it forwards operations with the 685 same cache-key options but possibly different payloads. 687 For those cases, Request-Tag is the proxy-safe elective option 688 suggested in [RFC7959] Section 2.4 last paragraph. 690 When initializing a new blockwise operation, a client has to look at 691 other active operations: 693 o If any of them is matchable to the new one, and the client neither 694 wants to cancel the old one nor postpone the new one, it can pick 695 a Request-Tag value that is not in use by the other matchable 696 operations for the new operation. 698 o Otherwise, it can start the new operation without setting the 699 Request-Tag option on it. 701 3.4.3. Simplified Block-Wise Handling for Constrained Proxies 703 The Block options were defined to be unsafe to forward because a 704 proxy that would forward blocks as plain messages would risk mixing 705 up clients' requests. 707 The Request-Tag option provides a very simple way for a proxy to keep 708 them separate: if it appends a Request-Tag that is particular to the 709 requesting endpoint to all request carrying any Block option, it does 710 not need to keep track of any further block state. 712 This is particularly useful to proxies that strive for stateless 713 operation as described in [I-D.hartke-core-stateless] Section 3.1. 715 3.5. Rationale for the Option Properties 717 The Request-Tag option can be elective, because to servers unaware of 718 the Request-Tag option, operations with differing request tags will 719 not be matchable. 721 The Request-Tag option can be safe to forward but part of the cache 722 key, because to proxies unaware of the Request-Tag option will 723 consider operations with differing request tags unmatchable but can 724 still forward them. 726 The Request-Tag option is repeatable because this easily allows 727 stateless proxies to "chain" their origin address. They can perform 728 the steps of Section 3.4.3 without the need to create an option value 729 that is the concatenation of the received option and their own value, 730 and can simply add a new Request-Tag option unconditionally. 732 In draft versions of this document, the Request-Tag option used to be 733 critical and unsafe to forward. That design was based on an 734 erroneous understanding of which blocks could be composed according 735 to [RFC7959]. 737 3.6. Rationale for Introducing the Option 739 An alternative that was considered to the Request-Tag option for 740 coping with the problem of fragmented message body integrity 741 (Section 3.4.1) was to update [RFC7959] to say that blocks could only 742 be assembled if their fragments' order corresponded to the sequence 743 numbers. 745 That approach would have been difficult to roll out reliably on DTLS 746 where many implementations do not expose sequence numbers, and would 747 still not prevent attacks like in [I-D.mattsson-core-coap-actuators] 748 Section 2.5.2. 750 4. Block2 / ETag Processing 752 The same security properties as in Section 3.4.1 can be obtained for 753 blockwise response operations. The threat model here is not an 754 attacker (because the response is made sure to belong to the current 755 request by the security layer), but blocks in the client's cache. 757 Rules stating that response body reassembly is conditional on 758 matching ETag values are already in place from Section 2.4 of 759 [RFC7959]. 761 To gain equivalent protection to Section 3.4.1, a server MUST use the 762 Block2 option in conjunction with the ETag option ([RFC7252], 763 Section 5.10.6), and MUST NOT use the same ETag value for different 764 representations of a resource. 766 5. Token Processing 768 As described in Section 1.3, the client must be able to verify that a 769 response corresponds to a particular request. This section updates 770 the CoAP Token processing requirements for clients. The Token 771 processing for servers is not updated. Token processing in 772 Section 5.3.1 of [RFC7252] is updated by adding the following text: 774 When CoAP is used with a security protocol not providing bindings 775 between requests and responses, the tokens have cryptographic 776 importance. The client MUST make sure that tokens are not used in a 777 way so that responses risk being associated with the wrong request. 778 The easiest way to accomplish this is to implement the Token (or part 779 of the Token) as a sequence number starting at zero for each new or 780 rekeyed secure connection, this approach SHOULD be followed. To 781 avoid collisions the sequence number can be encoded with a fixed 782 length or with some length-value encoding. 784 6. Security Considerations 786 The availability of a secure pseudorandom number generator and truly 787 random seeds are essential for the security of the Echo option. If 788 no true random number generator is available, a truly random seed 789 must be provided from an external source. 791 A single active Echo value with 64 (pseudo-)random bits gives the 792 same theoretical security level against forgeries as a 64-bit MAC (as 793 used in e.g. AES_128_CCM_8). In practice, forgery of an Echo option 794 value is much harder as an attacker must also forge the MAC in the 795 security protocol. The Echo option value MUST contain 32 796 (pseudo-)random bits that are not predictable for any other party 797 than the server, and SHOULD contain 64 (pseudo-)random bits. A 798 server MAY use different security levels for different uses cases 799 (client aliveness, request freshness, state synchronization, network 800 address reachability, etc.). 802 The security provided by the Echo and Request-Tag options depends on 803 the security protocol used. CoAP and HTTP proxies require (D)TLS to 804 be terminated at the proxies. The proxies are therefore able to 805 manipulate, inject, delete, or reorder options or packets. The 806 security claims in such architectures only hold under the assumption 807 that all intermediaries are fully trusted and have not been 808 compromised. 810 Servers SHOULD use a monotonic clock to generate timestamps and 811 compute round-trip times. Use of non-monotonic clocks is not secure 812 as the server will accept expired Echo option values if the clock is 813 moved backward. The server will also reject fresh Echo option values 814 if the clock is moved forward. Non-monotonic clocks MAY be used as 815 long as they have deviations that are acceptable given the freshness 816 requirements. If the deviations from a monotonic clock are known, it 817 may be possible to adjust the threshold accordingly. 819 Servers SHOULD NOT use wall clock time for timestamps, as wall clock 820 time have large deviations from a monotonic clock. Furthermore, an 821 attacker may be able to affect the server's wall clock time in 822 various ways such as setting up a fake NTP server or broadcasting 823 false time signals to radio-controlled clocks. 825 Servers MAY use the time since reboot measured in some unit of time. 826 Servers MAY reset the timer at certain times and MAY generate a 827 random offset applied to all timestamps. When resetting the timer, 828 the server MUST reject all Echo values that was created before the 829 reset. 831 Servers that use the List of Cached Random Values and Timestamps 832 method described in Appendix A may be vulnerable to resource 833 exhaustion attacks. One way to minimize state is to use the 834 Integrity Protected Timestamp method described in Appendix A. 836 7. Privacy Considerations 838 Implementations SHOULD NOT put any privacy sensitive information in 839 the Echo or Request-Tag option values. Unencrypted timestamps MAY 840 reveal information about the server such as location or time since 841 reboot. The use of wall clock time is not allowed (see Section 6) 842 and there also privacy reasons, e.g. it may reveal that the server 843 will accept expired certificates. Timestamps MAY be used if Echo is 844 encrypted between the client and the server, e.g. in the case of DTLS 845 without proxies or when using OSCORE with an Inner Echo option. 847 8. IANA Considerations 849 This document adds the following option numbers to the "CoAP Option 850 Numbers" registry defined by [RFC7252]: 852 +--------+-------------+-------------------+ 853 | Number | Name | Reference | 854 +--------+-------------+-------------------+ 855 | TBD1 | Echo | [[this document]] | 856 | | | | 857 | TBD2 | Request-Tag | [[this document]] | 858 +--------+-------------+-------------------+ 860 Figure 4: CoAP Option Numbers 862 9. References 864 9.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, 868 DOI 10.17487/RFC2119, March 1997, 869 . 871 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 872 Application Protocol (CoAP)", RFC 7252, 873 DOI 10.17487/RFC7252, June 2014, 874 . 876 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 877 the Constrained Application Protocol (CoAP)", RFC 7959, 878 DOI 10.17487/RFC7959, August 2016, 879 . 881 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 882 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 883 May 2017, . 885 9.2. Informative References 887 [I-D.hartke-core-stateless] 888 Hartke, K., "Extended Tokens and Stateless Clients in the 889 Constrained Application Protocol (CoAP)", draft-hartke- 890 core-stateless-02 (work in progress), October 2018. 892 [I-D.ietf-core-object-security] 893 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 894 "Object Security for Constrained RESTful Environments 895 (OSCORE)", draft-ietf-core-object-security-16 (work in 896 progress), March 2019. 898 [I-D.ietf-core-oscore-groupcomm] 899 Tiloca, M., Selander, G., Palombini, F., and J. Park, 900 "Group OSCORE - Secure Group Communication for CoAP", 901 draft-ietf-core-oscore-groupcomm-04 (work in progress), 902 March 2019. 904 [I-D.mattsson-core-coap-actuators] 905 Mattsson, J., Fornehed, J., Selander, G., Palombini, F., 906 and C. Amsuess, "Controlling Actuators with CoAP", draft- 907 mattsson-core-coap-actuators-06 (work in progress), 908 September 2018. 910 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 911 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 912 January 2012, . 914 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 915 the Constrained Application Protocol (CoAP)", RFC 7390, 916 DOI 10.17487/RFC7390, October 2014, 917 . 919 [RFC7641] Hartke, K., "Observing Resources in the Constrained 920 Application Protocol (CoAP)", RFC 7641, 921 DOI 10.17487/RFC7641, September 2015, 922 . 924 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 925 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 926 Application Protocol) over TCP, TLS, and WebSockets", 927 RFC 8323, DOI 10.17487/RFC8323, February 2018, 928 . 930 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 931 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 932 . 934 Appendix A. Methods for Generating Echo Option Values 936 The content and structure of the Echo option value are implementation 937 specific and determined by the server. Two simple mechanisms are 938 outlined in this section, the first is RECOMMENDED in general, and 939 the second is RECOMMENDED in case the Echo option is encrypted 940 between the client and the server. 942 Different mechanisms have different tradeoffs between the size of the 943 Echo option value, the amount of server state, the amount of 944 computation, and the security properties offered. A server MAY use 945 different methods and security levels for different uses cases 946 (client aliveness, request freshness, state synchronization, network 947 address reachability, etc.). 949 1. List of Cached Random Values and Timestamps. The Echo option 950 value is a (pseudo-)random byte string. The server caches a list 951 containing the random byte strings and their transmission times. 952 Assuming 72-bit random values and 32-bit timestamps, the size of the 953 Echo option value is 9 bytes and the amount of server state is 13n 954 bytes, where n is the number of active Echo Option values. The 955 security against forged echo values is given by s = bit length of r - 956 log2(n). The length of r and the maximum allowed n should be set so 957 that the security level is harmonized with other parts of the 958 deployment, e.g., s >= 64. If the server loses time continuity, e.g. 959 due to reboot, the entries in the old list MUST be deleted. 961 Echo option value: random value r 962 Server State: random value r, timestamp t0 964 2. Integrity Protected Timestamp. The Echo option value is an 965 integrity protected timestamp. The timestamp can have different 966 resolution and range. A 32-bit timestamp can e.g. give a resolution 967 of 1 second with a range of 136 years. The (pseudo-)random secret 968 key is generated by the server and not shared with any other party. 969 The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit 970 timestamp and a 64-bit MAC, the size of the Echo option value is 12 971 bytes and the Server state is small and constant. The security 972 against forged echo values is given by the MAC length. If the server 973 loses time continuity, e.g. due to reboot, the old key MUST be 974 deleted and replaced by a new random secret key. Note that the 975 privacy considerations in Section 7 may apply to the timestamp. A 976 server MAY want to encrypt its timestamps, and, depending on the 977 choice of encryption algorithms, this may require a nonce to be 978 included in the Echo option value. 980 Echo option value: timestamp t0, MAC(k, t0) 981 Server State: secret key k 983 Other mechanisms complying with the security and privacy 984 considerations may be used. The use of encrypted timestamps in the 985 Echo option typically requires an IV to be included in the Echo 986 option value, which adds overhead and makes the specification of such 987 a mechanism slightly more complicated than the two mechanisms 988 specified here. 990 Appendix B. Request-Tag Message Size Impact 992 In absence of concurrent operations, the Request-Tag mechanism for 993 body integrity (Section 3.4.1) incurs no overhead if no messages are 994 lost (more precisely: in OSCORE, if no operations are aborted due to 995 repeated transmission failure; in DTLS, if no packages are lost), or 996 when blockwise request operations happen rarely (in OSCORE, if there 997 is always only one request blockwise operation in the replay window). 999 In those situations, no message has any Request-Tag option set, and 1000 that can be recycled indefinitely. 1002 When the absence of a Request-Tag option can not be recycled any more 1003 within a security context, the messages with a present but empty 1004 Request-Tag option can be used (1 Byte overhead), and when that is 1005 used-up, 256 values from one byte long options (2 Bytes overhead) are 1006 available. 1008 In situations where those overheads are unacceptable (e.g. because 1009 the payloads are known to be at a fragmentation threshold), the 1010 absent Request-Tag value can be made usable again: 1012 o In DTLS, a new session can be established. 1014 o In OSCORE, the sequence number can be artificially increased so 1015 that all lost messages are outside of the replay window by the 1016 time the first request of the new operation gets processed, and 1017 all earlier operations can therefore be regarded as concluded. 1019 Appendix C. Change Log 1021 [ The editor is asked to remove this section before publication. ] 1023 o Changes since draft-ietf-core-echo-request-tag-03: 1025 * Mention token processing changes in title 1027 * Abstract reworded 1029 * Clarify updates to token processing 1031 * Describe security levels from Echo length 1033 * Allow non-monotonic clocks under certain conditions for 1034 freshness 1036 * Simplify freshness expressions 1038 * Describe when a Request-Tag can be set 1040 * Add note on application-level freshness mechanisms 1042 * Minor editorial changes 1044 o Changes since draft-ietf-core-echo-request-tag-02: 1046 * Define "freshness" 1048 * Note limitations of "aliveness" 1050 * Clarify proxy and OSCORE handling in presence of "echo" 1052 * Clarify when Echo values may be reused 1054 * Update security considerations 1056 * Various minor clarifications 1058 * Minor editorial changes 1060 o Major changes since draft-ietf-core-echo-request-tag-01: 1062 * Follow-up changes after the "relying on blockwise" change in 1063 -01: 1065 + Simplify the description of Request-Tag and matchability 1067 + Do not update RFC7959 any more 1069 * Make Request-Tag repeatable. 1071 * Add rationale on not relying purely on sequence numbers. 1073 o Major changes since draft-ietf-core-echo-request-tag-00: 1075 * Reworded the Echo section. 1077 * Added rules for Token processing. 1079 * Added security considerations. 1081 * Added actual IANA section. 1083 * Made Request-Tag optional and safe-to-forward, relying on 1084 blockwise to treat it as part of the cache-key 1086 * Dropped use case about OSCORE outer-blockwise (the case went 1087 away when its Partial IV was moved into the Object-Security 1088 option) 1090 o Major changes since draft-amsuess-core-repeat-request-tag-00: 1092 * The option used for establishing freshness was renamed from 1093 "Repeat" to "Echo" to reduce confusion about repeatable 1094 options. 1096 * The response code that goes with Echo was changed from 4.03 to 1097 4.01 because the client needs to provide better credentials. 1099 * The interaction between the new option and (cross) proxies is 1100 now covered. 1102 * Two messages being "Request-Tag matchable" was introduced to 1103 replace the older concept of having a request tag value with 1104 its slightly awkward equivalence definition. 1106 Acknowledgments 1108 The authors want to thank Jim Schaad and Carsten Bormann for 1109 providing valuable input to the draft. 1111 Authors' Addresses 1113 Christian Amsuess 1115 Email: christian@amsuess.com 1117 John Mattsson 1118 Ericsson AB 1120 Email: john.mattsson@ericsson.com 1122 Goeran Selander 1123 Ericsson AB 1125 Email: goran.selander@ericsson.com