idnits 2.17.1 draft-ietf-core-echo-request-tag-02.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC7252]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 (June 29, 2018) is 2121 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) == Missing Reference: 'RFC XXXX' is mentioned on line 702, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-13 == Outdated reference: A later version (-06) exists of draft-ietf-lwig-coap-05 == Outdated reference: A later version (-06) exists of draft-mattsson-core-coap-actuators-05 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: December 31, 2018 Ericsson AB 7 June 29, 2018 9 Echo and Request-Tag 10 draft-ietf-core-echo-request-tag-02 12 Abstract 14 This document specifies several security enhancements to the 15 Constrained Application Protocol (CoAP). Two optional extensions are 16 defined: the Echo option and the Request-Tag option. Each of these 17 options provide additional features to CoAP and protects against 18 certain attacks. The document also updates the processing 19 requirements on the Token of [RFC7252]. The updated Token processing 20 ensures secure binding of responses to requests. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 31, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Fragmented Message Body Integrity . . . . . . . . . . . . 3 59 1.3. Request-Response Binding . . . . . . . . . . . . . . . . 4 60 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. The Echo Option . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2. Echo Processing . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Applications . . . . . . . . . . . . . . . . . . . . . . 9 65 3. The Request-Tag Option . . . . . . . . . . . . . . . . . . . 10 66 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. Request-Tag processing by servers . . . . . . . . . . . . 11 68 3.3. Setting the Request-Tag . . . . . . . . . . . . . . . . . 12 69 3.4. Applications . . . . . . . . . . . . . . . . . . . . . . 12 70 3.4.1. Body Integrity Based on Payload Integrity . . . . . . 12 71 3.4.2. Multiple Concurrent Blockwise Operations . . . . . . 13 72 3.4.3. Simplified block-wise Handling for constrained 73 proxies . . . . . . . . . . . . . . . . . . . . . . . 14 74 3.5. Rationale for the option properties . . . . . . . . . . . 14 75 3.6. Rationale for introducing the option . . . . . . . . . . 15 76 4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 15 77 5. Token Processing . . . . . . . . . . . . . . . . . . . . . . 15 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 8.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Appendix A. Methods for Generating Echo Option Values . . . . . 18 84 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 19 85 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 The initial Constrained Application Protocol (CoAP) suite of 91 specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed 92 with the assumption that security could be provided on a separate 93 layer, in particular by using DTLS ([RFC6347]). However, for some 94 use cases, additional functionality or extra processing is needed to 95 support secure CoAP operations. This document specifies several 96 security enhancements to the Constrained Application Protocol (CoAP). 98 This document specifies two server-oriented CoAP options, the Echo 99 option and the Request-Tag option, mainly addressing the security 100 features request freshness and fragmented message body integrity, 101 respectively. The Echo option enables a CoAP server to verify the 102 freshness of a request, verify the aliveness of a client, synchronize 103 state, or force a client to demonstrate reachability at its apparent 104 network address. The Request-Tag option allows the CoAP server to 105 match message fragments belonging to the same request, fragmented 106 using the CoAP Block-Wise Transfer mechanism, which mitigates attacks 107 and enables concurrent blockwise operations. These options in 108 themselves do not replace the need for a security protocol; they 109 specify the format and processing of data which, when integrity 110 protected using e.g. DTLS ([RFC6347]), TLS ([RFC5246]), or OSCORE 111 ([I-D.ietf-core-object-security]), provide the additional security 112 features. 114 The document also updates the processing requirements on the Token. 115 The updated processing ensures secure binding of responses to 116 requests. 118 1.1. Request Freshness 120 A CoAP server receiving a request is in general not able to verify 121 when the request was sent by the CoAP client. This remains true even 122 if the request was protected with a security protocol, such as DTLS. 123 This makes CoAP requests vulnerable to certain delay attacks which 124 are particularly incriminating in the case of actuators 125 ([I-D.mattsson-core-coap-actuators]). Some attacks are possible to 126 mitigate by establishing fresh session keys (e.g. performing the DTLS 127 handshake) for each actuation, but in general this is not a solution 128 suitable for constrained environments. 130 A straightforward mitigation of potential delayed requests is that 131 the CoAP server rejects a request the first time it appears and asks 132 the CoAP client to prove that it intended to make the request at this 133 point in time. The Echo option, defined in this document, specifies 134 such a mechanism which thereby enables the CoAP server to verify the 135 freshness of a request. This mechanism is not only important in the 136 case of actuators, or other use cases where the CoAP operations 137 require freshness of requests, but also in general for synchronizing 138 state between CoAP client and server and to verify aliveness of the 139 client. 141 1.2. Fragmented Message Body Integrity 143 CoAP was designed to work over unreliable transports, such as UDP, 144 and include a lightweight reliability feature to handle messages 145 which are lost or arrive out of order. In order for a security 146 protocol to support CoAP operations over unreliable transports, it 147 must allow out-of-order delivery of messages using e.g. a sliding 148 replay window such as described in Section 4.1.2.6 of DTLS 149 ([RFC6347]). 151 The Block-Wise Transfer mechanism [RFC7959] extends CoAP by defining 152 the transfer of a large resource representation (CoAP message body) 153 as a sequence of blocks (CoAP message payloads). The mechanism uses 154 a pair of CoAP options, Block1 and Block2, pertaining to the request 155 and response payload, respectively. The blockwise functionality does 156 not support the detection of interchanged blocks between different 157 message bodies to the same resource having the same block number. 158 This remains true even when CoAP is used together with a security 159 protocol such as DTLS or OSCORE, within the replay window 160 ([I-D.mattsson-core-coap-actuators]), which is a vulnerability of 161 CoAP when using RFC7959. 163 A straightforward mitigation of mixing up blocks from different 164 messages is to use unique identifiers for different message bodies, 165 which would provide equivalent protection to the case where the 166 complete body fits into a single payload. The ETag option [RFC7252], 167 set by the CoAP server, identifies a response body fragmented using 168 the Block2 option. This document defines the Request-Tag option for 169 identifying the request body fragmented using the Block1 option, 170 similar to ETag, but ephemeral and set by the CoAP client. 172 1.3. Request-Response Binding 174 A fundamental requirement of secure REST operations is that the 175 client can bind a response to a particular request. In HTTPS this is 176 assured by the ordered and reliable delivery as well as mandating 177 that the server sends responses in the same order that the requests 178 were received. 180 The same is not true for CoAP where the server can return responses 181 in any order. Concurrent requests are instead differentiated by 182 their Token. Unfortunately, CoAP [RFC7252] does not treat Token as a 183 cryptographically important value and does not give stricter 184 guidelines than that the tokens currently "in use" SHOULD (not SHALL) 185 be unique. If used with security protocol not providing bindings 186 between requests and responses (e.g. DTLS and TLS) token reuse may 187 result in situations where a client matches a response to the wrong 188 request (see e.g. Section 2.3 of 189 [I-D.mattsson-core-coap-actuators]). Note that mismatches can also 190 happen for other reasons than a malicious attacker, e.g. delayed 191 delivery or a server sending notifications to an uninterested client. 193 A straightforward mitigation is to mandate clients to never reuse 194 tokens until the traffic keys have been replaced. As there may be 195 any number of responses to a request (see e.g. [RFC7641]), the 196 easiest way to accomplish this is to implement the token as a counter 197 and never reuse any tokens at all. This document updates the Token 198 processing in [RFC7252] to always assure a cryptographically secure 199 binding of responses to requests. 201 1.4. Terminology 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in BCP 206 14 [RFC2119] [RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 Unless otherwise specified, the terms "client" and "server" refers to 210 "CoAP client" and "CoAP server", respectively, as defined in 211 [RFC7252]. 213 The terms "payload" and "body" of a message are used as in [RFC7959]. 214 The complete interchange of a request and a response body is called a 215 (REST) "operation". An operation fragmented using [RFC7959] is 216 called a "blockwise operation". A blockwise operation which is 217 fragmenting the request body is called a "blockwise request 218 operation". A blockwise operation which is fragmenting the response 219 body is called a "blockwise response operation". 221 Two request messages are said to be "matchable" if they occur between 222 the same endpoint pair, have the same code and the same set of 223 options except for elective NoCacheKey options and options involved 224 in bock-wise transfer (Block1, Block2 and Request-Tag). Two 225 operations are said to be matchable if any of their messages are. 227 Two matchable blockwise operations are said to be "concurrent" if a 228 block of the second request is exchanged even though the client still 229 intends to exchange further blocks in the first operation. 230 (Concurrent blockwise request operations are impossible with the 231 options of [RFC7959] because the second operation's block overwrites 232 any state of the first exchange.). 234 The Echo and Request-Tag options are defined in this document. 236 2. The Echo Option 238 The Echo option is a server-driven challenge-response mechanism for 239 CoAP. The Echo option value is a challenge from the server to the 240 client included in a CoAP response and echoed in one or more CoAP 241 request. 243 2.1. Option Format 245 The Echo Option is elective, safe-to-forward, not part of the cache- 246 key, and not repeatable, see Figure 1, which extends Table 4 of 247 [RFC7252]). 249 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 250 | No. | C | U | N | R | Name | Format | Length | Default | E | 251 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 252 | TBD | | | x | | Echo | opaque | 4-40 | (none) | x | 253 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 255 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 256 E = Encrypt and Integrity Protect (when using OSCORE) 258 Figure 1: Echo Option Summary 260 [ Note to RFC editor: If this document is released before core- 261 object-security, the following paragraph and the "E" column above 262 need to move into OSCORE. ] 264 The Echo option value is generated by the server, and its content and 265 structure are implementation specific. Different methods for 266 generating Echo option values are outlined in Appendix A. Clients 267 and intermediaries MUST treat an Echo option value as opaque and make 268 no assumptions about its content or structure. 270 When receiving an Echo option in a request, the server MUST be able 271 to verify that the Echo option value was generated by the server as 272 well as the point in time when the Echo option value was generated. 274 2.2. Echo Processing 276 The Echo option MAY be included in any request or response (see 277 Section 2.3 for different applications), but the Echo option MUST NOT 278 be used with empty CoAP requests (i.e. Code=0.00). 280 If the server receives a request which has freshness requirements, 281 the request does not contain a fresh Echo option value, and the 282 server cannot verify the freshness of the request in some other way, 283 the server MUST NOT process the request further and SHOULD send a 284 4.01 Unauthorized response with an Echo option. 286 The application decides under what conditions a CoAP request to a 287 resource is required to be fresh. These conditions can for example 288 include what resource is requested, the request method and other data 289 in the request, and conditions in the environment such as the state 290 of the server or the time of the day. 292 The server may also include the Echo option in a response to verify 293 the aliveness of a client, to synchronize state, or to force a client 294 to demonstrate reachability at their apparent network address. 296 Upon receiving a 4.01 Unauthorized response with the Echo option, the 297 client SHOULD resend the original request with the addition of an 298 Echo option with the received Echo option value. The client MAY send 299 a different request compared to the original request. Upon receiving 300 any other response with the Echo option, the client SHOULD echo the 301 Echo option value in the next request to the server. The client MAY 302 include the same Echo option value in several different requests to 303 the server. 305 Upon receiving a request with the Echo option, the server determines 306 if the request has freshness requirement. If the request does not 307 have freshness requirements, the Echo option MAY be ignored. If the 308 request has freshness requirements and the server cannot verify the 309 freshness of the request in some other way, the server MUST verify 310 that the Echo option value was generated by the server; otherwise the 311 request is not processed further. The server MUST then calculate the 312 round-trip time RTT = (t1 - t0), where t1 is the request receive time 313 and t0 is the transmit time of the response that included the 314 specific Echo option value. The server MUST only accept requests 315 with a round-trip time below a certain threshold T, i.e. RTT < T, 316 otherwise the request is not processed further, and an error message 317 MAY be sent. The threshold T is application specific, its value 318 depends e.g. on the freshness requirements of the request. An 319 example message flow is illustrated in Figure 2. 321 Client Server 322 | | 323 +------>| Code: 0.03 (PUT) 324 | PUT | Token: 0x41 325 | | Uri-Path: lock 326 | | Payload: 0 (Unlock) 327 | | 328 |<------+ t0 Code: 4.01 (Unauthorized) 329 | 4.01 | Token: 0x41 330 | | Echo: 0x437468756c687521 331 | | 332 +------>| t1 Code: 0.03 (PUT) 333 | PUT | Token: 0x42 334 | | Uri-Path: lock 335 | | Echo: 0x437468756c687521 336 | | Payload: 0 (Unlock) 337 | | 338 |<------+ Code: 2.04 (Changed) 339 | 2.04 | Token: 0x42 340 | | 342 Figure 2: Example Echo Option Message Flow 344 When used to serve freshness requirements (including client aliveness 345 and state synchronizing), CoAP requests containing the Echo option 346 MUST be integrity protected, e.g. using DTLS, TLS, or OSCORE 347 ([I-D.ietf-core-object-security]). When used to demonstrate 348 reachability at their apparent network address, the Echo option MAY 349 be used without protection. 351 Note that the server does not have to synchronize the time used for 352 the Echo timestamps with any other party. If the server loses time 353 synchronization, e.g. due to reboot, it MUST reject all Echo values 354 that was created before time synchronization was lost. 356 CoAP-CoAP proxies MUST relay the Echo option unmodified. The CoAP 357 server side of CoAP-HTTP proxies MAY request freshness, especially if 358 they have reason to assume that access may require it (e.g. because 359 it is a PUT or POST); how this is determined is out of scope for this 360 document. The CoAP client side of HTTP-CoAP-Proxies SHOULD respond 361 to Echo challenges themselves if they know from the recent 362 establishing of the connection that the HTTP request is fresh. 363 Otherwise, they SHOULD respond with 503 Service Unavailable, Retry- 364 After: 0 and terminate any underlying Keep-Alive connection. They 365 MAY also use other mechanisms to establish freshness of the HTTP 366 request that are not specified here. 368 2.3. Applications 370 1. Actuation requests often require freshness guarantees to avoid 371 accidental or malicious delayed actuator actions. In general, 372 all non-safe methods (e.g. POST, PUT, DELETE) may require 373 freshness guarantees for secure operation. 375 2. To avoid additional roundtrips for applications with multiple 376 actuator requests in rapid sequence between the same client and 377 server, the server may use the Echo option (with a new value) in 378 response to a request containing the Echo option. The client 379 then uses the Echo option with the new value in the next 380 actuation request, and the server compares the receive time 381 accordingly. 383 3. If a server reboots during operation it may need to synchronize 384 state with requesting clients before continuing the interaction. 385 For example, with OSCORE it is possible to reuse a partly 386 persistently stored security context by synchronizing the Partial 387 IV (sequence number) using the Echo option. 389 4. When a device joins a multicast/broadcast group the device may 390 need to synchronize state or time with the sender to ensure that 391 the received message is fresh. By synchronizing time with the 392 broadcaster, time can be used for synchronizing subsequent 393 broadcast messages. A server MUST NOT synchronize state or time 394 with clients which are not the authority of the property being 395 synchronized. E.g. if access to a server resource is dependent 396 on time, then the client MUST NOT set the time of the server. 398 5. A server that sends large responses to unauthenticated peers 399 SHOULD mitigate amplification attacks such as described in 400 Section 11.3 of [RFC7252] (where an attacker would put a victim's 401 address in the source address of a CoAP request). For this 402 purpose, the server MAY ask a client to Echo its request to 403 verify its source address. This needs to be done only once per 404 peer and limits the range of potential victims from the general 405 Internet to endpoints that have been previously in contact with 406 the server. For this application, the Echo option can be used in 407 messages that are not integrity protected, for example during 408 discovery. 410 6. A server may want to verify the aliveness of a client by 411 responding with an Echo option. 413 3. The Request-Tag Option 415 The Request-Tag is intended for use as a short-lived identifier for 416 keeping apart distinct blockwise request operations on one resource 417 from one client. It enables the receiving server to reliably 418 assemble request payloads (blocks) to their message bodies, and, if 419 it chooses to support it, to reliably process simultaneous blockwise 420 request operations on a single resource. The requests must be 421 integrity protected in order to protect against interchange of blocks 422 between different message bodies. 424 In essence, it is an implementation of the "proxy-safe elective 425 option" used just to "vary the cache key" as suggested in [RFC7959] 426 Section 2.4. 428 3.1. Option Format 430 The Request-Tag option is not critical, is safe to forward, 431 repeatable, and part of the cache key, see Figure 3, which extends 432 Table 4 of [RFC7252]). 434 +-----+---+---+---+---+-------------+--------+--------+---------+---+---+ 435 | No. | C | U | N | R | Name | Format | Length | Default | E | U | 436 +-----+---+---+---+---+-------------+--------+--------+---------+---+---+ 437 | TBD | | | | x | Request-Tag | opaque | 0-8 | (none) | x | x | 438 +-----+---+---+---+---+-------------+--------+--------+---------+---+---+ 440 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 441 E = Encrypt and Integrity Protect (when using OSCORE) 443 Figure 3: Request-Tag Option Summary 445 [ Note to RFC editor: If this document is released before core- 446 object-security, the following paragraph and the "E"/"U" columns 447 above need to move into OSCORE. ] 449 Request-Tag, like the block options, is both a class E and a class U 450 option in terms of OSCORE processing (see Section 4.1 of 451 [I-D.ietf-core-object-security]): The Request-Tag MAY be an inner or 452 outer option. The inner option is encrypted and integrity protected 453 between client and server, and provides message body identification 454 in case of end-to-end fragmentation of requests. The outer option is 455 visible to proxies and labels message bodies in case of hop-by-hop 456 fragmentation of requests. 458 The Request-Tag option is only used in the request messages of 459 blockwise operations. 461 The Request-Tag mechanism can be applied independently on the server 462 and client sides of CoAP-CoAP proxies as are the block options, 463 though given it is safe to forward, a proxy is free to just forward 464 it when processing an operation. CoAP-HTTP proxies and HTTP-CoAP 465 proxies can use Request-Tag on their CoAP sides; it is not applicable 466 to HTTP requests. 468 3.2. Request-Tag processing by servers 470 The Request-Tag option does not require any particular processing on 471 the server side: As it varies the set of options that distinguish 472 blockwise operations (ie. is neither Block1 or Block2 nor elective 473 NoCacheKey), the server can not treat their messages as belonging to 474 the same operation. 476 To keep utilizing the cache, a server (including proxies) MAY discard 477 the Request-Tag option from an assembled block-wise request when 478 consulting its cache, as the option describes the individual blocks 479 but not the operation as a whole. For example, a FETCH request with 480 the same body can have a fresh response even if they were requested 481 using different request tags. (This is similar to the situation 482 about ETag in that it is formally part of the cache key, but 483 implementations that are aware of its meaning can cache more 484 efficiently, see [RFC7252] Section 5.4.2). 486 A server receiving a Request-Tag MUST treat it as opaque and make no 487 assumptions about its content or structure. 489 Two messages carrying the same Request-Tag is a necessary but not 490 sufficient condition for being part of the same operation. They can 491 still be treated as independent messages by the server (e.g. when it 492 sends 2.01/2.04 responses for every block), or initiate a new 493 operation (overwriting kept context) when the later message carries 494 Block1 number 0. 496 [ The following paragraph might be better placed in lwig-coap, but 497 was left here until lwig-coap has decided on its fate there. ] 499 As it has always been, a server that can only serve a limited number 500 of block-wise operations at the same time can delay the start of the 501 operation by replying with 5.03 (Service unavailable) and a Max-Age 502 indicating how long it expects the existing operation to go on, or it 503 can forget about the state established with the older operation and 504 respond with 4.08 (Request Entity Incompelte) to later blocks on the 505 first operation. 507 Especially, that is the case for any correctly implemented proxy that 508 does not know how to use Request-Tag in requests and has only one 509 client endpoint. When it receives concurrent incoming requests on 510 the same resource, it needs to make that very choice: either send a 511 5.03 with Max-Age (holding off the second operation), or to commence 512 the second operation and reject any further requests on the first 513 operation with 4.08 Request Entity Incompelte errors without 514 forwarding them. (Alternatively, it could spool the second request, 515 but the unpredictable nature of the timeouts involved often makes 516 that an unsuitable choice.) 518 3.3. Setting the Request-Tag 520 For each separate blockwise request operation, the client can choose 521 a Request-Tag value, or choose not to set a Request-Tag. Starting a 522 request operation matchable to a previous operation and even using 523 the same Request-Tag value is called request tag recycling. Clients 524 MUST NOT recycle a request tag unless the first operation has 525 concluded. What constitutes a concluded operation depends on the 526 application, and is outlined individually in Section 3.4. 528 When Block1 and Block2 are combined in an operation, the Request-Tag 529 of the Block1 phase is set in the Block2 phase as well for otherwise 530 the request would have a different set of options and would not be 531 recognized any more. 533 Clients are encouraged to generate compact messages. This means 534 sending messages without Request-Tag options whenever possible, and 535 using short values when the absent option can not be recycled. 537 3.4. Applications 539 3.4.1. Body Integrity Based on Payload Integrity 541 When a client fragments a request body into multiple message 542 payloads, even if the individual messages are integrity protected, it 543 is still possible for a man-in-the-middle to maliciously replace a 544 later operation's blocks with an earlier operation's blocks (see 545 Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the 546 integrity protection of each block does not extend to the operation's 547 request body. 549 In order to gain that protection, use the Request-Tag mechanism as 550 follows: 552 o The individual exchanges MUST be integrity protected end-to-end 553 between client and server. 555 o The client MUST NOT recycle a request tag in a new operation 556 unless the previous operation matchable to the new one has 557 concluded. 559 When considering previous operations in protocols where the 560 security association is not tightly bound to an end point (eg. 561 OSCORE), the client MUST consider messages sent to _any_ endpoint 562 with the new operation's security context. 564 o The client MUST NOT regard a blockwise request operation as 565 concluded unless all of the messages the client previously sent in 566 the operation have been confirmed by the message integrity 567 protection mechanism, or are considered invalid by the server if 568 replayed. 570 Typically, in OSCORE, these confirmations can result either from 571 the client receiving an OSCORE response message matching the 572 request (an empty ACK is insufficient), or because the message's 573 sequence number is old enough to be outside the server's receive 574 window. 576 In DTLS, this can only be confirmed if the request message was not 577 retransmitted, and was responded to. 579 Authors of other documents (e.g. [I-D.ietf-core-object-security]) 580 are invited to mandate this behavior for clients that execute 581 blockwise interactions over secured transports. In this way, the 582 server can rely on a conforming client to set the Request-Tag option 583 when required, and thereby conclude on the integrity of the assembled 584 body. 586 Note that this mechanism is implicitly implemented when the security 587 layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). 588 This is because with each message, any earlier message can not be 589 replayed any more, so the client never needs to set the Request-Tag 590 option unless it wants to perform concurrent operations. 592 3.4.2. Multiple Concurrent Blockwise Operations 594 CoAP clients, especially CoAP proxies, may initiate a blockwise 595 request operation to a resource, to which a previous one is already 596 in progress, which the new request should not cancel. A CoAP proxy 597 would be in such a situation when it forwards operations with the 598 same cache-key options but possibly different payloads. 600 For those cases, Request-Tag is the proxy-safe elective option 601 suggested in [RFC7959] Section 2.4 last paragraph. 603 When initializing a new blockwise operation, a client has to look at 604 other active operations: 606 o If any of them is matchable to the new one, and the client neither 607 wants to cancel the old one nor postpone the new one, it can pick 608 a Request-Tag value that is not in use by the other matchable 609 operations for the new operation. 611 o Otherwise, it can start the new operation without setting the 612 Request-Tag option on it. 614 3.4.3. Simplified block-wise Handling for constrained proxies 616 The Block options were defined to be unsafe to forward because a 617 proxy that woud forward blocks as plain messages would risk mixing up 618 clients' requests. 620 The Request-Tag option provides a very simple way for a proxy to keep 621 them separate: if it appends a Request-Tag that is particular to the 622 requesting endpoint to all request carrying any Block option, it does 623 not need to keep track of any further block state. 624 [I-D.ietf-lwig-coap] Section TBD provides further details. 626 [ Note to reviewers and co-authors: That section was so far only 627 syggested in input for lwig-coap. If it does not get into the 628 document, we should drop it here (for I don't want to explain all 629 this case's details and security considerations here), but if the 630 reference works, this section shows why Request-Tag has become 631 repeatable. ] 633 3.5. Rationale for the option properties 635 [ This section needs to be reworked after assuming our RFC7959 636 interpretation. ] 638 The Request-Tag option can be elective, because to servers unaware of 639 the Request-Tag option, operations with differing request tags will 640 not be matchable. 642 The Request-Tag option can be safe to forward but part of the cache 643 key, because to proxies unaware of the Request-Tag option will 644 consider operations with differing request tags unmatchable but can 645 still forward them. 647 In earlier versions of this draft, the Request-Tag option used to be 648 critical and unsafe to forward. That design was based on an 649 erroneous understanding of which blocks could be composed according 650 to [RFC7959]. 652 3.6. Rationale for introducing the option 654 An alternative that was considered to the Request-Tag option for 655 coping with the problem of fragmented message body integrity 656 (Section 3.4.1) was to update [RFC7959] to say that blocks could only 657 be assembled if their fragments' order corresponded to the sequence 658 numbers. 660 That approach would have been difficult to roll out reliably on DTLS 661 where many implementations do not expose sequence numbers, and would 662 still not prevent attacks like in [I-D.mattsson-core-coap-actuators] 663 Section 2.5.2. 665 4. Block2 / ETag Processing 667 The same security properties as in Section 3.4.1 can be obtained for 668 blockwise response operations. The threat model here is not an 669 attacker (because the response is made sure to belong to the current 670 request by the security layer), but blocks in the client's cache. 672 Rules stating that response body reassembly is conditional on 673 matching ETag values are already in place from Section 2.4 of 674 [RFC7959]. 676 To gain equivalent protection to Section 3.4.1, a server MUST use the 677 Block2 option in conjunction with the ETag option ([RFC7252], 678 Section 5.10.6), and MUST NOT use the same ETag value for different 679 representations of a resource. 681 5. Token Processing 683 This section updates the Token processing in Section 5.3.1 of 684 [RFC7252] by adding the following text: 686 When CoAP is used with a security protocol not providing bindings 687 between requests and responses, the client MUST NOT reuse tokens 688 until the traffic keys have been replaced. The easiest way to 689 accomplish this is to implement the Token as a counter, this approach 690 SHOULD be followed. 692 6. IANA Considerations 694 This document adds the following option numbers to the "CoAP Option 695 Numbers" registry defined by [RFC7252]: 697 +--------+-------------+------------+ 698 | Number | Name | Reference | 699 +--------+-------------+------------+ 700 | TBD1 | Echo | [RFC XXXX] | 701 | | | | 702 | TBD2 | Request-Tag | [RFC XXXX] | 703 +--------+-------------+------------+ 705 Figure 4: CoAP Option Numbers 707 7. Security Considerations 709 Implementations SHOULD NOT put any privacy sensitive information in 710 the Echo or Request-Tag option values. Unencrypted timestamps MAY 711 reveal information about the server such as its wall clock time or 712 location. Servers MUST use a monotonic clock to generate timestamps 713 and compute round-trip times. Servers SHOULD NOT use wall clock time 714 for timestamps, as wall clock time is not monotonic, may reveal that 715 the server will accept expired certificates, or reveal the server's 716 location. Use of non-monotonic clocks is not secure as the server 717 will accept expired Echo option values if the clock is moved 718 backward. The server will also reject fresh Echo option values if 719 the clock is moved forward. An attacker may be able to affect the 720 server's wall clock time in various ways such as setting up a fake 721 NTP server or broadcasting false time signals to radio-controlled 722 clocks. Servers MAY use the time since reboot measured in some unit 723 of time. Servers MAY reset the timer periodically. When resetting 724 the timer, the server MUST reject all Echo values that was created 725 before the reset. 727 The availability of a secure pseudorandom number generator and truly 728 random seeds are essential for the security of the Echo option. If 729 no true random number generator is available, a truly random seed 730 must be provided from an external source. 732 An Echo value with 64 (pseudo-)random bits gives the same theoretical 733 security level against forgeries as a 64-bit MAC (as used in e.g. 734 AES_128_CCM_8). In practice, forgery of an Echo option value is much 735 harder as an attacker must also forge the MAC in the security 736 protocol. The Echo option value MUST contain 32 (pseudo-)random bits 737 that are not predictable for any other party than the server, and 738 SHOULD contain 64 (pseudo-)random bits. A server MAY use different 739 security levels for different uses cases (client aliveness, request 740 freshness, state synchronization, network address reachability, 741 etc.). 743 The security provided by the Echo and Request-Tag options depends on 744 the security protocol used. CoAP and HTTP proxies require (D)TLS to 745 be terminated at the proxies. The proxies are therefore able to 746 manipulate, inject, delete, or reorder options or packets. The 747 security claims in such architectures only hold under the assumption 748 that all intermediaries are fully trusted and have not been 749 compromised. 751 Servers that use the List of Cached Random Values and Timestamps 752 method described in Appendix A may be vulnerable to resource 753 exhaustion attacks. On way to minimizing state is to use the 754 Integrity Protected Timestamp method described in Appendix A. 756 8. References 758 8.1. Normative References 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, 762 DOI 10.17487/RFC2119, March 1997, 763 . 765 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 766 Application Protocol (CoAP)", RFC 7252, 767 DOI 10.17487/RFC7252, June 2014, 768 . 770 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 771 the Constrained Application Protocol (CoAP)", RFC 7959, 772 DOI 10.17487/RFC7959, August 2016, 773 . 775 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 776 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 777 May 2017, . 779 8.2. Informative References 781 [I-D.ietf-core-object-security] 782 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 783 "Object Security for Constrained RESTful Environments 784 (OSCORE)", draft-ietf-core-object-security-13 (work in 785 progress), June 2018. 787 [I-D.ietf-lwig-coap] 788 Kovatsch, M., Bergmann, O., and C. Bormann, "CoAP 789 Implementation Guidance", draft-ietf-lwig-coap-05 (work in 790 progress), October 2017. 792 [I-D.mattsson-core-coap-actuators] 793 Mattsson, J., Fornehed, J., Selander, G., Palombini, F., 794 and C. Amsuess, "Controlling Actuators with CoAP", draft- 795 mattsson-core-coap-actuators-05 (work in progress), March 796 2018. 798 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 799 (TLS) Protocol Version 1.2", RFC 5246, 800 DOI 10.17487/RFC5246, August 2008, 801 . 803 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 804 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 805 January 2012, . 807 [RFC7641] Hartke, K., "Observing Resources in the Constrained 808 Application Protocol (CoAP)", RFC 7641, 809 DOI 10.17487/RFC7641, September 2015, 810 . 812 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 813 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 814 Application Protocol) over TCP, TLS, and WebSockets", 815 RFC 8323, DOI 10.17487/RFC8323, February 2018, 816 . 818 Appendix A. Methods for Generating Echo Option Values 820 The content and structure of the Echo option value are implementation 821 specific and determined by the server. Use of one of the mechanisms 822 outlined in this section is RECOMMENDED. 824 Different mechanisms have different tradeoffs between the size of the 825 Echo option value, the amount of server state, the amount of 826 computation, and the security properties offered. 828 o Integrity Protected Timestamp. One method is to construct the 829 Echo option value as an integrity protected timestamp. The 830 timestamp can have different resolution and range. A 32-bit 831 timestamp can e.g. give a resolution of 1 second with a range of 832 136 years. The (pseudo-)random secret key is generated by the 833 server and not shared with any other party. The use of truncated 834 HMAC-SHA-256 is RECOMMENDED. With a 32-bit timestamp and a 64-bit 835 MAC, the size of the Echo option value is 12 bytes and the Server 836 state is small and constant. If the server loses time 837 synchronization, e.g. due to reboot, the old key MUST be deleted 838 and replaced by a new random secret key. A server MAY also want 839 to encrypt its timestamps, depending on the choice of encryption 840 algorithms, this may require a nonce to be included in the Echo 841 option value. 843 Echo option value: timestamp t0, MAC(k, t0) 844 Server State: secret key k 846 o List of Cached Random Values and Timestamps. An alternative 847 method is to construct the Echo option value as a (pseudo-)random 848 byte string. The server caches a list containing the random byte 849 strings and their transmission times. Assuming 64-bit random 850 values and 32-bit timestamps, the size of the Echo option value is 851 8 bytes and the amount of server state is 12n bytes, where n is 852 the number of active Echo Option values. If the server loses time 853 synchronization, e.g. due to reboot, the entries in the old list 854 MUST be deleted. 856 Echo option value: random value r 857 Server State: random value r, timestamp t0 859 A server MAY use different methods and security levels for different 860 uses cases (client aliveness, request freshness, state 861 synchronization, network address reachability, etc.). 863 Appendix B. Request-Tag Message Size Impact 865 In absence of concurrent operations, the Request-Tag mechanism for 866 body integrity (Section 3.4.1) incurs no overhead if no messages are 867 lost (more precisely: in OSCORE, if no operations are aborted due to 868 repeated transmission failure; in DTLS, if no packages are lost), or 869 when blockwise request operations happen rarely (in OSCORE, if there 870 is always only one request blockwise operation in the replay window). 872 In those situations, no message has any Request-Tag option set, and 873 that can be recycled indefinitely. 875 When the absence of a Request-Tag option can not be recycled any more 876 within a security context, the messages with a present but empty 877 Request-Tag option can be used (1 Byte overhead), and when that is 878 used-up, 256 values from one byte long options (2 Bytes overhead) are 879 available. 881 In situations where those overheads are unacceptable (e.g. because 882 the payloads are known to be at a fragmentation threshold), the 883 absent Request-Tag value can be made usable again: 885 o In DTLS, a new session can be established. 887 o In OSCORE, the sequence number can be artificially increased so 888 that all lost messages are outside of the replay window by the 889 time the first request of the new operation gets processed, and 890 all earlier operations can therefore be regarded as concluded. 892 Appendix C. Change Log 894 [ The editor is asked to remove this section before publication. ] 896 o Major changes since draft-ietf-core-echo-request-tag-01: 898 * Follow-up changes after the "relying on blockwise" change in 899 -01: 901 + Simplify the description of Request-Tag and matchability 903 + Do not update RFC7959 any more 905 * Make Request-Tag repeatable. 907 * Add rationale on not relying purely on sequence numbers. 909 o Major changes since draft-ietf-core-echo-request-tag-00: 911 * Reworded the Echo section. 913 * Added rules for Token processing. 915 * Added security considerations. 917 * Added actual IANA section. 919 * Made Request-Tag optional and safe-to-forward, relying on 920 blockwise to treat it as part of the cache-key 922 * Dropped use case about OSCORE outer-blockwise (the case went 923 away when its Partial IV was moved into the Object-Security 924 option) 926 o Major changes since draft-amsuess-core-repeat-request-tag-00: 928 * The option used for establishing freshness was renamed from 929 "Repeat" to "Echo" to reduce confusion about repeatable 930 options. 932 * The response code that goes with Echo was changed from 4.03 to 933 4.01 because the client needs to provide better credentials. 935 * The interaction between the new option and (cross) proxies is 936 now covered. 938 * Two messages being "Request-Tag matchable" was introduced to 939 replace the older concept of having a request tag value with 940 its slightly awkward equivalence definition. 942 Authors' Addresses 944 Christian Amsuess 946 Email: christian@amsuess.com 948 John Mattsson 949 Ericsson AB 951 Email: john.mattsson@ericsson.com 953 Goeran Selander 954 Ericsson AB 956 Email: goran.selander@ericsson.com