idnits 2.17.1 draft-ietf-core-echo-request-tag-01.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. -- The draft header indicates that this document updates RFC7959, 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 05, 2018) is 2241 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 656, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-09 == Outdated reference: A later version (-06) exists of draft-mattsson-core-coap-actuators-04 -- 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: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 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, 7959 (if approved) J. Mattsson 5 Intended status: Standards Track G. Selander 6 Expires: September 6, 2018 Ericsson AB 7 March 05, 2018 9 Echo and Request-Tag 10 draft-ietf-core-echo-request-tag-01 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 Block options and the Token. The updated Token 20 processing 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 September 6, 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 . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Echo Processing . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Applications . . . . . . . . . . . . . . . . . . . . . . 8 65 3. The Request-Tag Option . . . . . . . . . . . . . . . . . . . 9 66 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2. Request-Tag Processing . . . . . . . . . . . . . . . . . 10 68 3.3. Applications . . . . . . . . . . . . . . . . . . . . . . 11 69 3.3.1. Body Integrity Based on Payload Integrity . . . . . . 11 70 3.3.2. Multiple Concurrent Blockwise Operations . . . . . . 12 71 3.4. Rationale for the option properties . . . . . . . . . . . 13 72 4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 14 73 5. Token Processing . . . . . . . . . . . . . . . . . . . . . . 14 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 8.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Appendix A. Methods for Generating Echo Option Values . . . . . 17 80 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 18 81 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 The initial Constrained Application Protocol (CoAP) suite of 87 specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed 88 with the assumption that security could be provided on a separate 89 layer, in particular by using DTLS ([RFC6347]). However, for some 90 use cases, additional functionality or extra processing is needed to 91 support secure CoAP operations. This document specifies several 92 security enhancements to the Constrained Application Protocol (CoAP). 94 This document specifies two server-oriented CoAP options, the Echo 95 option and the Request-Tag option, mainly addressing the security 96 features request freshness and fragmented message body integrity, 97 respectively. The Echo option enables a CoAP server to verify the 98 freshness of a request, verify the aliveness of a client, synchronize 99 state, or force a client to demonstrate reachability at its apparent 100 network address. The Request-Tag option allows the CoAP server to 101 match message fragments belonging to the same request, fragmented 102 using the CoAP Block-Wise Transfer mechanism, which mitigates attacks 103 and enables concurrent blockwise operations. These options in 104 themselves do not replace the need for a security protocol; they 105 specify the format and processing of data which, when integrity 106 protected using e.g. DTLS ([RFC6347]), TLS ([RFC5246]), or OSCORE 107 ([I-D.ietf-core-object-security]), provide the additional security 108 features. 110 The document also updates the processing requirements on the Block1 111 option, the Block2 option, and the Token. The updated blockwise 112 processing secure blockwise operations with multiple representations 113 of a particular resource. The updated Token processing ensures 114 secure binding of responses to requests. 116 1.1. Request Freshness 118 A CoAP server receiving a request is in general not able to verify 119 when the request was sent by the CoAP client. This remains true even 120 if the request was protected with a security protocol, such as DTLS. 121 This makes CoAP requests vulnerable to certain delay attacks which 122 are particularly incriminating in the case of actuators 123 ([I-D.mattsson-core-coap-actuators]). Some attacks are possible to 124 mitigate by establishing fresh session keys (e.g. performing the DTLS 125 handshake) for each actuation, but in general this is not a solution 126 suitable for constrained environments. 128 A straightforward mitigation of potential delayed requests is that 129 the CoAP server rejects a request the first time it appears and asks 130 the CoAP client to prove that it intended to make the request at this 131 point in time. The Echo option, defined in this document, specifies 132 such a mechanism which thereby enables the CoAP server to verify the 133 freshness of a request. This mechanism is not only important in the 134 case of actuators, or other use cases where the CoAP operations 135 require freshness of requests, but also in general for synchronizing 136 state between CoAP client and server and to verify aliveness of the 137 client. 139 1.2. Fragmented Message Body Integrity 141 CoAP was designed to work over unreliable transports, such as UDP, 142 and include a lightweight reliability feature to handle messages 143 which are lost or arrive out of order. In order for a security 144 protocol to support CoAP operations over unreliable transports, it 145 must allow out-of-order delivery of messages using e.g. a sliding 146 replay window such as described in Section 4.1.2.6 of DTLS 147 ([RFC6347]). 149 The Block-Wise Transfer mechanism [RFC7959] extends CoAP by defining 150 the transfer of a large resource representation (CoAP message body) 151 as a sequence of blocks (CoAP message payloads). The mechanism uses 152 a pair of CoAP options, Block1 and Block2, pertaining to the request 153 and response payload, respectively. The blockwise functionality does 154 not support the detection of interchanged blocks between different 155 message bodies to the same resource having the same block number. 156 This remains true even when CoAP is used together with a security 157 protocol such as DTLS or OSCORE, within the replay window 158 ([I-D.mattsson-core-coap-actuators]), which is a vulnerability of 159 CoAP when using RFC7959. 161 A straightforward mitigation of mixing up blocks from different 162 messages is to use unique identifiers for different message bodies, 163 which would provide equivalent protection to the case where the 164 complete body fits into a single payload. The ETag option [RFC7252], 165 set by the CoAP server, identifies a response body fragmented using 166 the Block2 option. This document defines the Request-Tag option for 167 identifying the request body fragmented using the Block1 option, 168 similar to ETag, but ephemeral and set by the CoAP client. 170 1.3. Request-Response Binding 172 A fundamental requirement of secure REST operations is that the 173 client can bind a response to a particular request. In HTTPS this is 174 assured by the ordered and reliable delivery as well as mandating 175 that the server sends responses in the same order that the requests 176 were received. 178 The same is not true for CoAP where the server can return responses 179 in any order. Concurrent requests are instead differentiated by 180 their Token. Unfortunately, CoAP [RFC7252] does not treat Token as a 181 cryptographically important value and does not give stricter 182 guidelines than that the tokens currently "in use" SHOULD (not SHALL) 183 be unique. If used with security protocol not providing bindings 184 between requests and responses (e.g. DTLS and TLS) token reuse may 185 result in situations where a client matches a response to the wrong 186 request (see e.g. Section 2.3 of 187 [I-D.mattsson-core-coap-actuators]). Note that mismatches can also 188 happen for other reasons than a malicious attacker, e.g. delayed 189 delivery or a server sending notifications to an uninterested client. 191 A straightforward mitigation is to mandate clients to never reuse 192 tokens until the traffic keys have been replaced. As there may be 193 any number of responses to a request (see e.g. [RFC7641]), the 194 easiest way to accomplish this is to implement the token as a counter 195 and never reuse any tokens at all. This document updates the Token 196 processing in [RFC7252] to always assure a cryptographically secure 197 binding of responses to requests. 199 1.4. Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in [RFC2119]. 205 Unless otherwise specified, the terms "client" and "server" refers to 206 "CoAP client" and "CoAP server", respectively, as defined in 207 [RFC7252]. 209 The terms "payload" and "body" of a message are used as in [RFC7959]. 210 The complete interchange of a request and a response body is called a 211 (REST) "operation". An operation fragmented using [RFC7959] is 212 called a "blockwise operation". A blockwise operation which is 213 fragmenting the request body is called a "blockwise request 214 operation". A blockwise operation which is fragmenting the response 215 body is called a "blockwise response operation". 217 Two blockwise operations between the same endpoint pair on the same 218 resource are said to be "concurrent" if a block of the second request 219 is exchanged even though the client still intends to exchange further 220 blocks in the first operation. (Concurrent blockwise request 221 operations are impossible with the options of [RFC7959] because the 222 second operation's block overwrites any state of the first 223 exchange.). 225 The Echo and Request-Tag options are defined in this document. The 226 concept of two messages being "Request-Tag-matchable" is defined in 227 Section 3.1. 229 2. The Echo Option 231 The Echo option is a server-driven challenge-response mechanism for 232 CoAP. The Echo option value is a challenge from the server to the 233 client included in a CoAP response and echoed in one or more CoAP 234 request. 236 2.1. Option Format 238 The Echo Option is elective, safe-to-forward, not part of the cache- 239 key, and not repeatable, see Figure 1. 241 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 242 | No. | C | U | N | R | Name | Format | Length | Default | E | 243 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 244 | TBD | | | x | | Echo | opaque | 4-40 | (none) | x | 245 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 247 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 248 E = Encrypt and Integrity Protect (when using OSCORE) 250 Figure 1: Echo Option Summary 252 [Note to RFC editor: If this document is not released together with 253 OSCORE but before it, the following paragraph and the "E" column 254 above need to move into OSCORE.] 256 The Echo option value is generated by the server, and its content and 257 structure are implementation specific. Different methods for 258 generating Echo option values are outlined in Appendix A. Clients 259 and intermediaries MUST treat an Echo option value as opaque and make 260 no assumptions about its content or structure. 262 When receiving an Echo option in a request, the server MUST be able 263 to verify that the Echo option value was generated by the server as 264 well as the point in time when the Echo option value was generated. 266 2.2. Echo Processing 268 The Echo option MAY be included in any request or response (see 269 Section 2.3 for different applications), but the Echo option MUST NOT 270 be used with empty CoAP requests (i.e. Code=0.00). 272 If the server receives a request which has freshness requirements, 273 the request does not contain a fresh Echo option value, and the 274 server cannot verify the freshness of the request in some other way, 275 the server MUST NOT process the request further and SHOULD send a 276 4.01 Unauthorized response with an Echo option. 278 The application decides under what conditions a CoAP request to a 279 resource is required to be fresh. These conditions can for example 280 include what resource is requested, the request method and other data 281 in the request, and conditions in the environment such as the state 282 of the server or the time of the day. 284 The server may also include the Echo option in a response to verify 285 the aliveness of a client, to synchronize state, or to force a client 286 to demonstrate reachability at their apparent network address. 288 Upon receiving a 4.01 Unauthorized response with the Echo option, the 289 client SHOULD resend the original request with the addition of an 290 Echo option with the received Echo option value. The client MAY send 291 a different request compared to the original request. Upon receiving 292 any other response with the Echo option, the client SHOULD echo the 293 Echo option value in a next request to the server. The client MAY 294 include the same Echo option value in several different requests to 295 the server. 297 Upon receiving a request with the Echo option, the server determines 298 if the request has freshness requirement. If the request does not 299 have freshness requirements, the Echo option MAY be ignored. If the 300 request has freshness requirements and the server cannot verify the 301 freshness of the request in some other way, the server MUST verify 302 that the Echo option value was generated by the server; otherwise the 303 request is not processed further. The server MUST then calculate the 304 round-trip time RTT = (t1 - t0), where t1 is the request receive time 305 and t0 is the transmit time of the response that included the 306 specific Echo option value. The server MUST only accept requests 307 with a round-trip time below a certain threshold T, i.e. RTT < T, 308 otherwise the request is not processed further, and an error message 309 MAY be sent. The threshold T is application specific, its value 310 depends e.g. on the freshness requirements of the request. An 311 example message flow is illustrated in Figure 2. 313 Client Server 314 | | 315 +------>| Code: 0.03 (PUT) 316 | PUT | Token: 0x41 317 | | Uri-Path: lock 318 | | Payload: 0 (Unlock) 319 | | 320 |<------+ t0 Code: 4.01 (Unauthorized) 321 | 4.01 | Token: 0x41 322 | | Echo: 0x437468756c687521 323 | | 324 +------>| t1 Code: 0.03 (PUT) 325 | PUT | Token: 0x42 326 | | Uri-Path: lock 327 | | Echo: 0x437468756c687521 328 | | Payload: 0 (Unlock) 329 | | 330 |<------+ Code: 2.04 (Changed) 331 | 2.04 | Token: 0x42 332 | | 334 Figure 2: Example Echo Option Message Flow 336 When used to serve freshness requirements (including client aliveness 337 and state synchronizing), CoAP requests containing the Echo option 338 MUST be integrity protected, e.g. using DTLS, TLS, or OSCORE 339 ([I-D.ietf-core-object-security]). When used to demonstrate 340 reachability at their apparent network address, the Echo option MAY 341 be used without protection. 343 Note that the server does not have to synchronize the time used for 344 the Echo timestamps with any other party. If the server loses time 345 synchronization, e.g. due to reboot, it MUST reject all Echo values 346 that was created before time synchronization was lost. 348 CoAP-CoAP proxies MUST relay the Echo option unmodified. The CoAP 349 server side of CoAP-HTTP proxies MAY request freshness, especially if 350 they have reason to assume that access may require it (e.g. because 351 it is a PUT or POST); how this is determined is out of scope for this 352 document. The CoAP client side of HTTP-CoAP-Proxies SHOULD respond 353 to Echo challenges themselves if they know from the recent 354 establishing of the connection that the HTTP request is fresh. 355 Otherwise, they SHOULD respond with 503 Service Unavailable, Retry- 356 After: 0 and terminate any underlying Keep-Alive connection. They 357 MAY also use other mechanisms to establish freshness of the HTTP 358 request that are not specified here. 360 2.3. Applications 362 1. Actuation requests often require freshness guarantees to avoid 363 accidental or malicious delayed actuator actions. In general, 364 all non-safe methods (e.g. POST, PUT, DELETE) may require 365 freshness guarantees for secure operation. 367 2. To avoid additional roundtrips for applications with multiple 368 actuator requests in rapid sequence between the same client and 369 server, the server may use the Echo option (with a new value) in 370 response to a request containing the Echo option. The client 371 then uses the Echo option with the new value in the next 372 actuation request, and the server compares the receive time 373 accordingly. 375 3. If a server reboots during operation it may need to synchronize 376 state with requesting clients before continuing the interaction. 377 For example, with OSCORE it is possible to reuse a partly 378 persistently stored security context by synchronizing the Partial 379 IV (sequence number) using the Echo option. 381 4. When a device joins a multicast/broadcast group the device may 382 need to synchronize state or time with the sender to ensure that 383 the received message is fresh. By synchronizing time with the 384 broadcaster, time can be used for synchronizing subsequent 385 broadcast messages. A server MUST NOT synchronize state or time 386 with clients which are not the authority of the property being 387 synchronized. E.g. if access to a server resource is dependent 388 on time, then the client MUST NOT set the time of the server. 390 5. A server that sends large responses to unauthenticated peers 391 SHOULD mitigate amplification attacks such as described in 392 Section 11.3 of [RFC7252] (where an attacker would put a victim's 393 address in the source address of a CoAP request). For this 394 purpose, the server MAY ask a client to Echo its request to 395 verify its source address. This needs to be done only once per 396 peer and limits the range of potential victims from the general 397 Internet to endpoints that have been previously in contact with 398 the server. For this application, the Echo option can be used in 399 messages that are not integrity protected, for example during 400 discovery. 402 6. A server may want to verify the aliveness of a client by 403 responding with an Echo option. 405 3. The Request-Tag Option 407 The Request-Tag is intended for use as a short-lived identifier for 408 keeping apart distinct blockwise request operations on one resource 409 from one client. It enables the receiving server to reliably 410 assemble request payloads (blocks) to their message bodies, and, if 411 it chooses to support it, to reliably process simultaneous blockwise 412 request operations on a single resource. The requests must be 413 integrity protected in order to protect against interchange of blocks 414 between different message bodies. 416 3.1. Option Format 418 The Request-Tag option is not critical, safe to forward, and part of 419 the cache key as illustrated in Figure 3. 421 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 422 | No. | C | U | N | R | Name | Format | Length | Default | E | 423 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 424 | TBD | | | | | Request-Tag | opaque | 0-8 | (none) | * | 425 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 427 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 428 E = Encrypt and Integrity Protect (when using OSCORE) 430 Figure 3: Request-Tag Option Summary 432 [Note to RFC editor: If this document is not released together with 433 OSCORE but before it, the following paragraph and the "E" column 434 above need to move into OSCORE.] 436 Request-Tag, like the block options, is a special class E option in 437 terms of OSCORE processing (see Section 4.3.1.2 of 438 [I-D.ietf-core-object-security]): The Request-Tag MAY be an inner or 439 outer option. The inner option is encrypted and integrity protected 440 between client and server, and provides message body identification 441 in case of end-to-end fragmentation of requests. The outer option is 442 visible to proxies and labels message bodies in case of hop-by-hop 443 fragmentation of requests. 445 The Request-Tag option is only used in the request messages of 446 blockwise request operations. 448 Two messages are defined to be Request-Tag-matchable if and only if 449 they are sent from and to the same end points (including security 450 associations), and target the same URI (precisely: target the same 451 endpoint and cache-key except for cache-key options that are related 452 to blockwise), and if either neither carries a Request-Tag option, or 453 both carry exactly one Request-Tag option and the option values are 454 of same length and content. 456 The Request-Tag mechanism is applied independently on the server and 457 client sides of CoAP-CoAP proxies as are the block options, though 458 given it is safe to forward, a proxy is free to just forward it when 459 processing an operation. CoAP-HTTP proxies and HTTP-CoAP proxies can 460 use Request-Tag on their CoAP sides; it is not applicable to HTTP 461 requests. 463 For each separate blockwise request operation, the client can choose 464 a Request-Tag value, or choose not to set a Request-Tag. Creating a 465 new request operation whose messages are Request-Tag-matchable to a 466 previous operation is called request tag recycling. Clients MUST NOT 467 recycle a request tag unless the first operation has concluded. What 468 constitutes a concluded operation depends on the application, and is 469 outlined individually in Section 3.3. 471 Clients are encouraged to generate compact messages. This means 472 sending messages without Request-Tag options whenever possible, and 473 using short values when the absent option can not be recycled. 475 3.2. Request-Tag Processing 477 A server MUST NOT act on any two blocks in the same blockwise request 478 operation that are not Request-Tag-matchable. This rule applies 479 independent of whether the request actually carries a Request-Tag 480 option (if not, the request can only be acted on together with other 481 messages not carrying the option, as per matchability definition). 483 As not all messages from the same source can be combined any more, a 484 block not matchable to the first Block1 cannot overwrite context kept 485 for an operation under a different tag (cf. [RFC7959] Section 2.5). 486 The server is still under no obligation to keep state of more than 487 one transaction. When an operation is in progress and a second one 488 cannot be served at the same time, the server SHOULD respond to the 489 second request with a 5.03 (Service Unavailable) response code and 490 indicate the time it is willing to wait for additional blocks in the 491 first operation using the Max-Age option, as specified in 492 Section 5.9.3.4 of [RFC7252]. (Alternatively, the server can cancel 493 the original operation, especially if it is already likely to time 494 out. Cancelling it unconditionally is the behavior that could be 495 expected of a Request-Tag unaware server.) 497 A server receiving a Request-Tag MUST treat it as opaque and make no 498 assumptions about its content or structure. 500 Two messages being Request-Tag-matchable is a necessary but not 501 sufficient condition for being part of the same operation. They can 502 still be treated as independent messages by the server (e.g. when it 503 sends 2.01/2.04 responses for every block), or initiate a new 504 operation (overwriting kept context) when the later message carries 505 Block1 number 0. 507 Note that RFC 7959 already implies that the cache key is the element 508 that binds exchanges together to operations (together with the 509 request's source endpoint), but is not explicit about it; therefore, 510 the above rules are spelt out here. 512 3.3. Applications 514 3.3.1. Body Integrity Based on Payload Integrity 516 When a client fragments a request body into multiple message 517 payloads, even if the individual messages are integrity protected, it 518 is still possible for a man-in-the-middle to maliciously replace 519 later operation's blocks with earlier operation's blocks (see 520 Section 2.5 of [I-D.mattsson-core-coap-actuators]). Therefore, the 521 integrity protection of each block does not extend to the operation's 522 request body. 524 In order to gain that protection, use the Request-Tag mechanism as 525 follows: 527 o The individual exchanges MUST be integrity protected end-to-end 528 between client and server. 530 o The client MUST NOT recycle a request tag unless the previous 531 blockwise request operation that used matchable Request-Tags has 532 concluded. 534 o The client MUST NOT regard a blockwise request operation as 535 concluded unless all of the messages the client previously sent in 536 the operation have been confirmed by the message integrity 537 protection mechanism, or are considered invalid by the server if 538 replayed. 540 Typically, in OSCORE, these confirmations can result either from 541 the client receiving an OSCORE response message matching the 542 request (an empty ACK is insufficient), or because the message's 543 sequence number is old enough to be outside the server's receive 544 window. 546 In DTLS, this can only be confirmed if the request message was not 547 retransmitted, and was responded to. 549 Authors of other documents (e.g. [I-D.ietf-core-object-security]) 550 are invited to mandate this behavior for clients that execute 551 blockwise interactions over secured transports. In this way, the 552 server can rely on a conforming client to set the Request-Tag option 553 when required, and thereby conclude on the integrity of the assembled 554 body. 556 Note that this mechanism is implicitly implemented when the security 557 layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). 558 This is because with each message, any earlier operation can be 559 regarded as concluded by the client, so it never needs to set the 560 Request-Tag option unless it wants to perform concurrent operations. 562 3.3.2. Multiple Concurrent Blockwise Operations 564 CoAP clients, especially CoAP proxies, may initiate a blockwise 565 request operation to a resource, to which a previous one is already 566 in progress, and which the new request should not cancel. A CoAP 567 proxy would be in such a situation when it forwards operations with 568 the same cache-key options but possibly different payloads. 570 When a client fragments an initial message as part of a blockwise 571 request operation, it can do so without a Request-Tag option set. 572 For this application, an operation can be regarded as concluded when 573 a final Block1 option has been sent and acknowledged, or when the 574 client chose not to continue with the operation (e.g. by user choice, 575 or in the case of a proxy when it decides not to take any further 576 messages in the operation due to a timeout). When another concurrent 577 blockwise request operation is made (i.e. before the operation is 578 concluded), the client can not recycle the request tag, and has to 579 pick a new one. The possible outcomes are: 581 o The server responds with a successful code. 583 The second concurrent blockwise operations can then continue. 585 The first operation might have been cancelled by that (typical of 586 servers that only support a single blockwise operation), in which 587 case its resumption will result in a 4.08 Request Entity 588 Incomplete error. 590 o The server responds 5.03 Service Unavailable with a Max-Age option 591 to indicate when it is likely to be available again. 593 This can indicate that the server supports Request-Tag, but still 594 is not prepared to handle concurrent requests. The client should 595 wait for as long as the response is valid, and then retry the 596 operation, which may not need to carry a Request-Tag option by 597 then any more. 599 In this, the proxy can indicate the anticipated delay by sending a 600 5.03 Service Unavailable response itself. 602 Note that a correctly implemented Request-Tag unaware proxy in the 603 same situation would need to make a choice to either send a 5.03 with 604 Max-Age by itself (holding off the second operation), or to commence 605 the second operation and reject any further requests on the first 606 operation with 4.08 Request Entity Incompelte errors by itself 607 without forwarding them. 609 3.4. Rationale for the option properties 611 The Request-Tag option used to be critical and unsafe to forward in 612 earlier revisions of this draft. 614 Given that supporting it will be mandated for where it is used for 615 its security properties, the choice of whether it is mandatory or 616 safe to forward can be made as required for the multiple concurrent 617 operations use case. For those cases, Request-Tag is the proxy-safe 618 elective option suggested in [RFC7959] Section 2.4 last paragraph. 620 4. Block2 / ETag Processing 622 The same security properties as in Section 3.3.1 can be obtained for 623 blockwise response operations. The threat model here is not an 624 attacker (because the response is made sure to belong to the current 625 request by the security layer), but blocks in the client's cache. 627 Analogous rules to Section 3.2 are already in place for assembling a 628 response body in Section 2.4 of [RFC7959]. 630 To gain equivalent protection to Section 3.3.1, a server MUST use the 631 Block2 option in conjunction with the ETag option ([RFC7252], 632 Section 5.10.6), and MUST NOT use the same ETag value for different 633 representations of a resource. 635 5. Token Processing 637 This section updates the Token processing in Section 5.3.1 of 638 [RFC7252] by adding the following text: 640 When CoAP is used with a security protocol not providing bindings 641 between requests and responses, the client MUST NOT reuse tokens 642 until the traffic keys have been replaced. The easiest way to 643 accomplish this is to implement the Token as a counter, this approach 644 SHOULD be followed. 646 6. IANA Considerations 648 This document adds the following option numbers to the "CoAP Option 649 Numbers" registry defined by [RFC7252]: 651 +--------+-------------+------------+ 652 | Number | Name | Reference | 653 +--------+-------------+------------+ 654 | TBD1 | Echo | [RFC XXXX] | 655 | | | | 656 | TBD2 | Request-Tag | [RFC XXXX] | 657 +--------+-------------+------------+ 659 Figure 4: CoAP Option Numbers 661 7. Security Considerations 663 Servers SHOULD NOT put any privacy sensitive information in the Echo 664 or Request-Tag option values. Unencrypted timestamps MAY reveal 665 information about the server such as its wall clock time or location. 666 Servers MUST use a monotonic clock to generate timestamps and compute 667 round-trip times. Servers SHOULD NOT use wall clock time for 668 timestamps, as wall clock time is not monotonic, may reveal that the 669 server will accept expired certificates, or reveal the server's 670 location. Use of non-monotonic clocks is not secure as the server 671 will accept expired Echo option values if the clock is moved 672 backward. The server will also reject fresh Echo option values if 673 the clock is moved forward. An attacker may be able to affect the 674 server's wall clock time in various ways such as setting up a fake 675 NTP server or broadcasting false time signals to radio-controlled 676 clocks. Servers SHOULD use the time since reboot measured in some 677 unit of time. Servers MAY reset the timer periodically even when not 678 rebooting. 680 The availability of a secure pseudorandom number generator and truly 681 random seeds are essential for the security of the Echo option. If 682 no true random number generator is available, a truly random seed 683 must be provided from an external source. 685 An Echo value with 64 (pseudo-)random bits gives the same theoretical 686 security level against forgeries as a 64-bit MAC (as used in e.g. 687 AES_128_CCM_8). In practice, forgery of an Echo option value is much 688 harder as an attacker must also forge the MAC in the security 689 protocol. The Echo option value MUST contain 32 (pseudo-)random bits 690 that are not predictable for any other party than the server, and 691 SHOULD contain 64 (pseudo-)random bits. A server MAY use different 692 security levels for different uses cases (client aliveness, request 693 freshness, state synchronization, network address reachability, 694 etc.). 696 The security provided by the Echo and Request-Tag options depends on 697 the security protocol used. CoAP and HTTP proxies require (D)TLS to 698 be terminated at the proxies. The proxies are therefore able to 699 manipulate, inject, delete, or reorder options or packets. The 700 security claims in such architectures only hold under the assumption 701 that all intermediaries are fully trusted and have not been 702 compromised. 704 Servers that use the List of Cached Random Values and Timestamps 705 method described in Appendix A may be vulnerable to resource 706 exhaustion attacks. On way to minimizing state is to use the 707 Integrity Protected Timestamp method described in Appendix A. 709 8. References 711 8.1. Normative References 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, 715 DOI 10.17487/RFC2119, March 1997, 716 . 718 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 719 Application Protocol (CoAP)", RFC 7252, 720 DOI 10.17487/RFC7252, June 2014, 721 . 723 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 724 the Constrained Application Protocol (CoAP)", RFC 7959, 725 DOI 10.17487/RFC7959, August 2016, 726 . 728 8.2. Informative References 730 [I-D.ietf-core-object-security] 731 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 732 "Object Security for Constrained RESTful Environments 733 (OSCORE)", draft-ietf-core-object-security-09 (work in 734 progress), March 2018. 736 [I-D.mattsson-core-coap-actuators] 737 Mattsson, J., Fornehed, J., Selander, G., Palombini, F., 738 and C. Amsuess, "Controlling Actuators with CoAP", draft- 739 mattsson-core-coap-actuators-04 (work in progress), March 740 2018. 742 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 743 (TLS) Protocol Version 1.2", RFC 5246, 744 DOI 10.17487/RFC5246, August 2008, 745 . 747 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 748 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 749 January 2012, . 751 [RFC7641] Hartke, K., "Observing Resources in the Constrained 752 Application Protocol (CoAP)", RFC 7641, 753 DOI 10.17487/RFC7641, September 2015, 754 . 756 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 757 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 758 Application Protocol) over TCP, TLS, and WebSockets", 759 RFC 8323, DOI 10.17487/RFC8323, February 2018, 760 . 762 Appendix A. Methods for Generating Echo Option Values 764 The content and structure of the Echo option value are implementation 765 specific and determined by the server. Use of one of the mechanisms 766 outlined in this section is RECOMMENDED. 768 Different mechanisms have different tradeoffs between the size of the 769 Echo option value, the amount of server state, the amount of 770 computation, and the security properties offered. 772 o Integrity Protected Timestamp. One method is to construct the 773 Echo option value as an integrity protected timestamp. The 774 timestamp can have different resolution and range. A 32-bit 775 timestamp can e.g. give a resolution of 1 second with a range of 776 136 years. The (pseudo-)random secret key is generated by the 777 server and not shared with any other party. The use of truncated 778 HMAC-SHA-256 is RECOMMENDED. With a 32-bit timestamp and a 64-bit 779 MAC, the size of the Echo option value is 12 bytes and the Server 780 state is small and constant. If the server loses time 781 synchronization, e.g. due to reboot, the old key MUST be deleted 782 and replaced by a new random secret key. A server MAY also want 783 to encrypt its timestamps, depending on the choice of encryption 784 algorithms, this may require a nonce to be included in the Echo 785 option value. 787 Echo option value: timestamp t0, MAC(k, t0) 788 Server State: secret key k 790 o List of Cached Random Values and Timestamps. An alternative 791 method is to construct the Echo option value as a (pseudo-)random 792 byte string. The server caches a list containing the random byte 793 strings and their transmission times. Assuming 64-bit random 794 values and 32-bit timestamps, the size of the Echo option value is 795 8 bytes and the amount of server state is 12n bytes, where n is 796 the number of active Echo Option values. If the server loses time 797 synchronization, e.g. due to reboot, the entries in the old list 798 MUST be deleted. 800 Echo option value: random value r 801 Server State: random value r, timestamp t0 803 A server MAY use different methods and security levels for different 804 uses cases (client aliveness, request freshness, state 805 synchronization, network address reachability, etc.). 807 Appendix B. Request-Tag Message Size Impact 809 In absence of concurrent operations, the Request-Tag mechanism for 810 body integrity (Section 3.3.1) incurs no overhead if no messages are 811 lost (more precisely: in OSCORE, if no operations are aborted due to 812 repeated transmission failure; in DTLS, if no packages are lost), or 813 when blockwise request operations happen rarely (in OSCORE, if only 814 one request operation with losses within the replay window). 816 In those situations, no message has any Request-Tag option set, and 817 that can be recycled indefinitely. 819 When the absence of a Request-Tag option can not be recycled any more 820 within a security context, the messages with a present but empty 821 Request-Tag option can be used (1 Byte overhead), and when that is 822 used-up, 256 values from one byte long options (2 Bytes overhead) are 823 available. 825 In situations where those overheads are unacceptable (e.g. because 826 the payloads are known to be at a fragmentation threshold), the 827 absent Request-Tag value can be made usable again: 829 o In DTLS, a new session can be established. 831 o In OSCORE, the sequence number can be artificially increased so 832 that all lost messages are outside of the replay window by the 833 time the first request of the new operation gets processed, and 834 all earlier operations can therefore be regarded as concluded. 836 Appendix C. Change Log 838 [ The editor is asked to remove this section before publication. ] 840 o Major changes since draft-ietf-core-echo-request-tag-00: 842 * Reworded the Echo section. 844 * Added rules for Token processing. 846 * Added security considerations. 848 * Added actual IANA section. 850 * Made Request-Tag optional and safe-to-forward, relying on 851 blockwise to treat it as part of the cache-key 853 * Dropped use case about OSCORE outer-blockwise (the case went 854 away when its Partial IV was moved into the Object-Security 855 option) 857 o Major changes since draft-amsuess-core-repeat-request-tag-00: 859 * The option used for establishing freshness was renamed from 860 "Repeat" to "Echo" to reduce confusion about repeatable 861 options. 863 * The response code that goes with Echo was changed from 4.03 to 864 4.01 because the client needs to provide better credentials. 866 * The interaction between the new option and (cross) proxies is 867 now covered. 869 * Two messages being "Request-Tag matchable" was introduced to 870 replace the older concept of having a request tag value with 871 its slightly awkward equivalence definition. 873 Authors' Addresses 875 Christian Amsuess 877 Email: christian@amsuess.com 879 John Mattsson 880 Ericsson AB 882 Email: john.mattsson@ericsson.com 884 Goeran Selander 885 Ericsson AB 887 Email: goran.selander@ericsson.com