idnits 2.17.1 draft-amsuess-core-repeat-request-tag-00.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 01, 2017) is 2490 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 (-16) exists of draft-ietf-core-object-security-03 == Outdated reference: A later version (-06) exists of draft-mattsson-core-coap-actuators-02 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Amsuess 3 Internet-Draft Energy Harvesting Solutions 4 Updates: RFC7959 (if approved) J. Mattsson 5 Intended status: Standards Track G. Selander 6 Expires: January 2, 2018 Ericsson AB 7 July 01, 2017 9 Repeat And Request-Tag 10 draft-amsuess-core-repeat-request-tag-00 12 Abstract 14 This document defines two optional extensions to the Constrained 15 Application Protocol (CoAP): the Repeat option and the Request-Tag 16 option. Each of these options when integrity protected, such as with 17 DTLS or OSCOAP, protects against certain attacks on CoAP message 18 exchanges. 20 The Repeat option enables a CoAP server to verify the freshness of a 21 request by requiring the CoAP client to make another request and 22 include a server-provided challenge. The Request-Tag option allows 23 the CoAP server to match message fragments belonging to the same 24 request message, fragmented using the CoAP Block-Wise Transfer 25 mechanism. This document also specifies additional processing 26 requirements on Block1 and Block2 options. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 2, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Request Freshness . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Fragmented Message Body Integrity . . . . . . . . . . . . 3 65 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. The Repeat Option . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 68 2.2. Repeat Processing . . . . . . . . . . . . . . . . . . . . 5 69 2.3. Applications . . . . . . . . . . . . . . . . . . . . . . 7 70 3. The Request-Tag Option . . . . . . . . . . . . . . . . . . . 8 71 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 72 3.2. Request-Tag Processing . . . . . . . . . . . . . . . . . 9 73 3.3. Applications . . . . . . . . . . . . . . . . . . . . . . 10 74 3.3.1. Body Integrity Based on Payload Integrity . . . . . . 10 75 3.3.2. Multiple Concurrent Blockwise Operations . . . . . . 11 76 4. Block2 / ETag Processing . . . . . . . . . . . . . . . . . . 12 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 7.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Appendix A. Performance Impact When Using the Repeat Option . . 14 83 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The initial CoAP suite of specifications ([RFC7252], [RFC7641], 89 [RFC7959]) was designed with the assumption that security could be 90 provided on a separate layer, in particular by using DTLS 91 ([RFC6347]). However, for some use cases, additional functionality 92 or extra processing is needed to support secure CoAP operations. 94 This document specifies two server-oriented CoAP options, the Repeat 95 option and the Request-Tag option, addressing the security features 96 request freshness and fragmented message body integrity, 97 respectively. These options in themselves do not replace the need 98 for a security protocol; they specify the format and processing of 99 data which, when integrity protected in a message, e.g. using DTLS 100 ([RFC6347]) or OSCOAP ([I-D.ietf-core-object-security]), provide 101 those security features. The Request-Tag option and also the ETag 102 option are mandatory to use with Block1 and Block2, respectively, to 103 secure blockwise operations with multiple representations of a 104 particular resource as is specified in this document. 106 1.1. Request Freshness 108 A CoAP server receiving a request may not be able to verify when the 109 request was sent by the CoAP client. This remains true even if the 110 request was protected with a security protocol, such as DTLS. This 111 makes CoAP requests vulnerable to certain delay attacks which are 112 particularly incriminating in the case of actuators 113 ([I-D.mattsson-core-coap-actuators]). Some attacks are possible to 114 mitigate by establishing fresh session keys (e.g. performing the DTLS 115 handshake) for each actuation, but in general this is not a solution 116 suitable for constrained environments. 118 A straightforward mitigation of potential delayed requests is that 119 the CoAP server rejects a request the first time it appears and asks 120 the CoAP client to prove that it intended to make the request at this 121 point in time. The Repeat option, defined in this document, 122 specifies such a mechanism which thereby enables the CoAP server to 123 verify the freshness of a request. This mechanism is not only 124 important in the case of actuators, or other use cases where the CoAP 125 operations require freshness of requests, but also in general for 126 synchronizing state between CoAP client and server. 128 1.2. Fragmented Message Body Integrity 130 CoAP was designed to work over unreliable transports, such as UDP, 131 and include a lightweight reliability feature to handle messages 132 which are lost or arrive out of order. In order for a security 133 protocol to support CoAP operations over unreliable transports, it 134 must allow out-of-order delivery of messages using e.g. a sliding 135 replay window such as described in Section 4.1.2.6 of DTLS 136 ([RFC6347]). 138 The Block-Wise Transfer mechanism [RFC7959] extends CoAP by defining 139 the transfer of a large resource representation (CoAP message body) 140 as a sequence of blocks (CoAP message payloads). The mechanism uses 141 a pair of CoAP options, Block1 and Block2, pertaining to the request 142 and response payload, respectively. The blockwise functionality does 143 not support the detection of interchanged blocks between different 144 message bodies to the same endpoint having the same block number. 145 This remains true even when CoAP is used together with a security 146 protocol such as DTLS or OSCOAP, within the replay window 147 ([I-D.amsuess-core-request-tag]), which is a vulnerability of CoAP 148 when using RFC7959. 150 A straightforward mitigation of mixing up blocks from different 151 messages is to use unique identifiers for different message bodies, 152 which would provide equivalent protection to the case where the 153 complete body fits into a single payload. The ETag option [RFC7252], 154 set by the CoAP server, identifies a response body fragmented using 155 the Block2 option. This document defines the Request-Tag option for 156 identifying the request body fragmented using the Block1 option, 157 similar to ETag, but ephemeral and set by the CoAP client. 159 1.3. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 Unless otherwise specified, the terms "client" and "server" refers to 166 "CoAP client" and "CoAP server", respectively, as defined in 167 [RFC7252]. 169 The terms "payload" and "body" of a message are used as in [RFC7959]. 170 The complete interchange of a request and a response body is called a 171 (REST) "operation", while a request and response message (as matched 172 by their tokens) is called an "exchange". An operation fragmented 173 using [RFC7959] is called a "blockwise operation". A blockwise 174 operation which is fragmenting the request body is called a 175 "blockwise request operation". A blockwise operation which is 176 fragmenting the response body is called a "blockwise response 177 operation". 179 Two blockwise operations between the same endpoint pair on the same 180 resource are said to be "concurrent" if a block of the second request 181 is exchanged even though the client still intends to exchange further 182 blocks in the first operation. (Concurrent blockwise request 183 operations are impossible with the options of [RFC7959] because the 184 second operation's block overwrites any state of the first 185 exchange.). 187 The Repeat and Request-Tag options are defined in this document. The 188 concept "Request-Tag value" is defined in Section 3.1. 190 2. The Repeat Option 192 The Repeat option is a server-driven challenge-response mechanism for 193 CoAP. The Repeat option value is a challenge from the server to the 194 client included in a CoAP response and echoed in a CoAP request. 196 2.1. Option Format 198 The Repeat Option is elective, safe-to-forward, not part of the 199 cache-key, and not repeatable, see Figure 1. Note that the Repeat 200 option has nothing to do with the property of an option being 201 repeatable, i.e. be allowed to occur more than once in a message, as 202 defined in Section 5.4.5 of [RFC7252]. 204 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 205 | No. | C | U | N | R | Name | Format | Length | Default | E | 206 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 207 | TBD | | | | | Repeat | opaque | 8-40 | (none) | x | 208 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 210 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, 211 E=Encrypt and Integrity Protect (when using OSCOAP) 213 Figure 1: Repeat Option Summary 215 The value of the Repeat option MUST be a (pseudo-)random bit string 216 of a length of at least 64 bits. A new (pseudo-)random bit string 217 MUST be generated by the server for each use of the Repeat option. 219 2.2. Repeat Processing 221 It is important to identify under what conditions a CoAP request to a 222 resource is required to be fresh. These conditions can for example 223 include what resource is requested, the request method and other data 224 in the request, and conditions in the environment such as the state 225 of the server or the time of the day. 227 A server MAY include the Repeat option in a response. The Repeat 228 option MUST NOT be used with empty CoAP requests. If the server 229 receives a request which has freshness requirements, and the request 230 does not contain the Repeat option, the server SHOULD send a 4.03 231 Forbidden response with a Repeat option. The server SHOULD cache the 232 transmitted Repeat option value and the response transmit time (here 233 denoted t0). 235 Upon receiving a response with the Repeat option within the 236 EXCHANGE_LIFETIME ([RFC7252]) of the original request, the client 237 SHOULD echo the Repeat option with the same value in a new request to 238 the server. Upon receiving a 4.03 Forbidden response with the Repeat 239 option in response to a request within the EXCHANGE_LIFETIME of the 240 original request, the client SHOULD resend the original request. The 241 client MAY send a different request compared to the original request. 243 If the server receives a request which has freshness requirements, 244 and the request contains the Repeat option, the server MUST verify 245 that the option value equals a cached value; otherwise the request is 246 not processed further. The server MUST calculate the round-trip time 247 RTT = (t1 - t0), where t1 is the request receive time. The server 248 MUST only accept requests with a round-trip time below a certain 249 threshold T, i.e. RTT < T, otherwise the request is not processed 250 further, and an error message MAY be sent. The threshold T is 251 application specific, its value depends e.g. on the freshness 252 requirements of the request. An example message flow is illustrated 253 in Figure 2. 255 When used to serve freshness requirements, CoAP messages containing 256 the Repeat option MUST be integrity protected, e.g. using DTLS or 257 OSCOAP ([I-D.ietf-core-object-security]). 259 If the server loses time synchronization, e.g. due to reboot, it MUST 260 delete all cached Repeat option values and response transmission 261 times. 263 Client Server 264 | | 265 +----->| Code: 0.03 (PUT) 266 | PUT | Token: 0x41 267 | | Uri-Path: lock 268 | | Payload: 0 (Unlock) 269 | | 270 |<-----+ t0 Code: 4.03 (Forbidden) 271 | 4.03 | Token: 0x41 272 | | Repeat: 0x6c880d41167ba807 273 | | 274 +----->| t1 Code: 0.03 (PUT) 275 | PUT | Token: 0x42 276 | | Uri-Path: lock 277 | | Repeat: 0x6c880d41167ba807 278 | | Payload: 0 (Unlock) 279 | | 280 |<-----+ Code: 2.04 (Changed) 281 | 2.04 | Token: 0x42 282 | | 284 Figure 2: Repeat option message flow 286 Constrained server implementations can use the mechanisms outlined in 287 Appendix A to minimize the memory impact of having many unanswered 288 Repeat responses. 290 2.3. Applications 292 1. Actuation requests often require freshness guarantees to avoid 293 accidental or malicious delayed actuator actions. 295 2. To avoid additional roundtrips for applications with multiple 296 actuator requests in rapid sequence between the same client and 297 server, the server may use the Repeat option (with a new value) 298 in response to a request containing the Repeat option. The 299 client then uses the Repeat option with the new value in the next 300 actuation request, and the server compares the receive time 301 accordingly. 303 3. If a server reboots during operation it may need to synchronize 304 state with requesting clients before continuing the interaction. 305 For example, with OSCOAP it is possible to reuse a persistently 306 stored security context by synchronizing the Partial IV (sequence 307 number) using the Repeat option. 309 4. When a device joins a multicast/broadcast group the device may 310 need to synchronize state or time with the sender to ensure that 311 the received message is fresh. By synchronizing time with the 312 broadcaster, time can be used for synchronizing subsequent 313 broadcast messages. A server MUST NOT synchronize state or time 314 with clients which are not the authority of the property being 315 synchronized. E.g. if access to a server resource is dependent 316 on time, then the client MUST NOT set the time of the server. 318 5. A server that sends large responses to unauthenticated peers and 319 wants to mitigate the amplification attacks described in 320 Section 11.3 of [RFC7252] (where an attacker would put a victim's 321 address in the source address of a CoAP request) can ask a client 322 to Repeat its request to verify the source address. This needs 323 to be done only once per peer, and limits the range of potential 324 victims from the general Internet to endpoints that have been 325 previously in contact with the server. For this application, the 326 Repeat option can be used in messages that are not integrity 327 protected, for example during discovery. 329 3. The Request-Tag Option 331 The Request-Tag is intended for use as a short-lived identifier for 332 keeping apart distinct blockwise request operations on one resource 333 from one client. It enables the receiving server to reliably 334 assemble request payloads (blocks) to their message bodies, and, if 335 it chooses to support it, to reliably process simultaneous blockwise 336 request operations on a single resource. The requests must be be 337 integrity protected in order to protect against interchange of blocks 338 between different message bodies. 340 3.1. Option Format 342 The Request-Tag option has the same properties as the Block1 option: 343 it is critical, unsafe, not part of the cache-key, and not 344 repeatable, see Figure 3. 346 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 347 | No. | C | U | N | R | Name | Format | Length | Default | E | 348 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 349 | TBD | x | x | - | | Request-Tag | opaque | 0-8 | (none) | * | 350 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 352 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, 353 E=Encrypt and Integrity Protect (when using OSCOAP) 355 Figure 3: Request-Tag Option Summary 357 [Note to RFC editor: If this document is not released together with 358 OSCOAP but before it, the following paragraph and the "E" column 359 above need to move into OSCOAP.] 361 Request-Tag, like the Block1 option, is a special class E option in 362 terms of OSCOAP processing (see Section 4.3.1.2 of 363 [I-D.ietf-core-object-security]): The Request-Tag MAY be an inner or 364 outer option. The inner option is encrypted and integrity protected 365 between client and server, and provides message body identification 366 in case of end-to-end fragmentation of requests. The outer option is 367 visible to proxies and labels message bodies in case of hop-by-hop 368 fragmentation of requests. 370 Every message in which the Block1 option is set is considered to 371 carry a "Request-Tag value" that can be compared for equality with 372 the value of any other such message. Absence of the Request-Tag 373 option implies a value that is distinct from any value of a message 374 with the Request-Tag option set, and equal to that of any other 375 message without the Request-Tag option. Messages with the Request- 376 Tag option set have equal Request-Tag values if and only if their 377 option lengths and option values are equal. 379 The value of the Request-Tag option is generated by the client for 380 every blockwise request operation. Clients are encouraged to 381 generate compact Request-Tag values. It MUST be different from any 382 other Request-Tag value used in the same security context on the same 383 resource, but MAY be reused when all earlier operations with the same 384 value are concluded. What constitutes a concluded operation depends 385 on the application, and is outlined individually in Section 3.3. 387 3.2. Request-Tag Processing 389 A server MUST NOT act on any two blocks in the same blockwise request 390 operation that have different Request-Tag values. This also means 391 that a block cannot overwrite kept context when the Request-Tag does 392 not match (cf. [RFC7959] Section 2.5). The server is still under no 393 obligation to keep state of more than one transaction. When an 394 operation is in progress and a second one cannot be served at the 395 same time, the server MUST respond to the second request with a 5.03 396 (Service Unavailable) response code and SHOULD indicate the time it 397 is willing to wait for additional blocks in the first operation using 398 the Max-Age option, as specified in Section 5.9.3.4 of [RFC7252]. 400 A server receiving a Request-Tag MUST treat it as opaque and make no 401 assumptions about its content or structure. 403 Two messages arriving at the server with the same Request-Tag value 404 do not necessarily belong to the same operation. They can still be 405 treated as independent messages by the server (e.g. when it sends 406 2.01/2.04 responses for every block), or initiate a new operation 407 (overwriting kept context) when sending the first block again. 409 The Request-Tag option is not used in responses. 411 If a request that uses Request-Tag is rejected with 4.02 Bad Option, 412 the client MAY retry the operation without it, but then it MUST 413 serialize all operations that affect the same resource. Security 414 requirements can forbid dropping the Request-Tag option. 416 3.3. Applications 418 3.3.1. Body Integrity Based on Payload Integrity 420 When a client fragments a request body into multiple message 421 payloads, even if the individual messages are integrity protected, it 422 is still possible for a man-in-the-middle to maliciously replace 423 later operation's blocks with earlier operation's blocks (see 424 Section 3.2 of [I-D.amsuess-core-request-tag]). Therefore, the 425 integrity protection of each block does not extend to the operation's 426 request body. 428 In order to gain that protection, use the Request-Tag mechanism as 429 follows: 431 o The message payloads MUST be integrity protected end-to-end 432 between client and server. 434 o The client MUST NOT reuse a Request-Tag value within a security 435 association unless all previous blockwise request operations on 436 the same resource that used the same Request-Tag value have 437 concluded. 439 Note that the server needs to verify that all blocks within an 440 operation come from the same security association, because the 441 security association is a part of the endpoint as per [RFC7252]. 443 o The client MUST NOT regard a blockwise request operation as 444 concluded unless all of the messages the client previously sent in 445 the operation have been confirmed by the message integrity 446 protection mechanism, or are considered invalid by the server if 447 replayed. 449 Typically, in OSCOAP, these confirmations can result either from 450 the client receiving an OSCOAP response message matching the 451 request (an empty ACK is insufficient), or because the message's 452 sequence number is old enough to be outside the server's receive 453 window. 455 In DTLS, this can only be confirmed if the request message was not 456 retransmitted, and was responded to. 458 Authors of other documents (e.g. [I-D.ietf-core-object-security]) 459 are invited to mandate this behavior for clients that execute 460 blockwise interactions over secured transports. In this way, the 461 server can rely on a conforming client to set the Request-Tag option 462 when required, and thereby conclude on the integrity of the assembled 463 body. 465 Note that this mechanism is implicitly implemented when the security 466 layer guarantees ordered delivery (e.g. CoAP over TLS 467 [I-D.tschofenig-core-coap-tcp-tls]). This is because with each 468 message, any earlier operation can be regarded as concluded by the 469 client, so it never needs to set the Request-Tag option unless it 470 wants to perform concurrent operations. 472 3.3.2. Multiple Concurrent Blockwise Operations 474 CoAP clients, especially CoAP proxies, may initiate a blockwise 475 request operation to a resource, to which a previous one is already 476 in progress, and which the new request should not cancel. One 477 example is when a CoAP proxy fragments an OSCOAP messages using 478 blockwise (so-called "outer" blockwise, see Section 4.3.1. of 479 [I-D.ietf-core-object-security])), where the Uri-Path is hidden 480 inside the encrypted message, and all the proxy sees is the server's 481 "/" path. 483 When a client fragments a message as part of a blockwise request 484 operation, it can do so without a Request-Tag option set. For this 485 application, an operation can be regarded as concluded when a final 486 Block1 option has been sent and acknowledged, or when the client 487 chose not to continue with the operation (e.g. by user choice, or in 488 the case of a proxy when it decides not to take any further messages 489 in the operation due to a timeout). When another concurrent 490 blockwise request operation is made (i.e. before the operation is 491 concluded), the client can use a different Request-Tag value (as 492 specified in Section 3.1). The possible outcomes are: 494 o The server responds with a successful code. 496 The concurrent blockwise operations can then continue. 498 o The server responds 4.02 Bad Option. 500 This can indicate that the server does not support Request-Tag. 501 The client should wait for the first operation to conclude, and 502 then try the same request without a Request-Tag option. 504 o The server responds 5.03 Service Unavailable with a Max-Age option 505 to indicate when it is likely to be available again. 507 This can indicate that the server supports Request-Tag, but still 508 is not prepared to handle concurrent requests. The client should 509 wait for as long as the response is valid, and then retry the 510 operation, which may not need to carry a Request-Tag option by 511 then any more. 513 In the cases where a CoAP proxy receives an error code, it can 514 indicate the anticipated delay by sending a 5.03 Service Unavailable 515 response itself. Note that this behavior is no different from what a 516 CoAP proxy would need to do were it unaware of the Request-Tag 517 option. 519 4. Block2 / ETag Processing 521 The same security properties as in Section 3.3.1 can be obtained for 522 blockwise response operations. The threat model here is not an 523 attacker (because the response is made sure to belong to the current 524 request by the security layer), but blocks in the client's cache. 526 Analogous rules to Section 3.2 are already in place for assembling a 527 response body in Section 2.4 of [RFC7959]. 529 To gain equivalent protection to Section 3.3.1, a server MUST use the 530 Block2 option in conjunction with the ETag option ([RFC7252], 531 Section 5.10.6), and MUST NOT use the same ETag value for different 532 representations of a resource. 534 5. IANA Considerations 536 [TBD: Fill out the option templates for Repeat and Request-Tag] 538 6. Security Considerations 540 Servers that store a Repeat challenge per client can be attacked for 541 resource exhaustion, and should consider minimizing the state kept 542 per client, e.g. using a mechanism as described in Appendix A. 544 7. References 546 7.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, 550 DOI 10.17487/RFC2119, March 1997, 551 . 553 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 554 Application Protocol (CoAP)", RFC 7252, 555 DOI 10.17487/RFC7252, June 2014, 556 . 558 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 559 the Constrained Application Protocol (CoAP)", RFC 7959, 560 DOI 10.17487/RFC7959, August 2016, 561 . 563 7.2. Informative References 565 [I-D.amsuess-core-request-tag] 566 Amsuess, C., "Request-Tag option", draft-amsuess-core- 567 request-tag-00 (work in progress), March 2017. 569 [I-D.ietf-core-object-security] 570 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 571 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 572 object-security-03 (work in progress), May 2017. 574 [I-D.mattsson-core-coap-actuators] 575 Mattsson, J., Fornehed, J., Selander, G., and F. 576 Palombini, "Controlling Actuators with CoAP", draft- 577 mattsson-core-coap-actuators-02 (work in progress), 578 November 2016. 580 [I-D.tschofenig-core-coap-tcp-tls] 581 Bormann, C., Lemay, S., Technologies, Z., and H. 582 Tschofenig, "A TCP and TLS Transport for the Constrained 583 Application Protocol (CoAP)", draft-tschofenig-core-coap- 584 tcp-tls-05 (work in progress), November 2015. 586 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 587 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 588 January 2012, . 590 [RFC7641] Hartke, K., "Observing Resources in the Constrained 591 Application Protocol (CoAP)", RFC 7641, 592 DOI 10.17487/RFC7641, September 2015, 593 . 595 Appendix A. Performance Impact When Using the Repeat Option 597 The Repeat option requires the server to keep some state in order to 598 later verify the repeated request. 600 Instead of caching Repeat option values and response transmission 601 times, the server MAY use the encryption of the response transmit 602 time t0 as Repeat option value. Such a scheme needs to ensure that 603 the server can detect a replay of a previous encrypted response 604 transmit time. 606 For example, the server MAY encrypt t0 with AES-CCM-128-64-64 using a 607 (pseudo-)random secret key k generated and cached by the server. A 608 unique IV MUST be used with each encryption, e.g. using a sequence 609 number. If the server loses time synchronization, e.g. due to 610 reboot, then k MUST be deleted and replaced by a new random secret 611 key. When using encrypted response transmit times, the Repeat 612 processing is modified in the following way: The verification of 613 cached option value in the server processing is replaced by the 614 verification of the integrity of the encrypted option value using the 615 cached key and IV (e.g. sequence number). 617 The two methods - (a) the list of cached values, and (b) the 618 encryption of transmit time - have different impact on the 619 implementation: 621 o size of cached data (list of cached values vs. key and IV) 623 o size of message (typically larger with encrypted time) 625 o computation (encryption + decryption vs. generation new nonce + 626 cache + lookup) 628 In general, the encryption of transmission times is most useful if 629 the number of concurrent requests is high. 631 A hybrid scheme is also possible: the first Repeat option values are 632 cached, and if the number of concurrent requests reach a certain 633 threshold, then encrypted times are used until there is space for 634 storing new values in the list. In that case, the server may need to 635 make both verifications - either that the Repeat value is in the 636 list, or that it verifies in decryption - and in either case that the 637 transmission time is valid. 639 Appendix B. Request-Tag Message Size Impact 641 In absence of concurrent operations, the Request-Tag mechanism for 642 body integrity (Section 3.3.1) incurs no overhead if no messages are 643 lost (more precisely: in OSCOAP, if no operations are aborted due to 644 repeated transmission failure; in DTLS, if no packages are lost), or 645 when blockwise request operations happen rarely (in OSCOAP, if only 646 one request operation with losses within the replay window). 648 In those situations, the Request-Tag value of no Request-Tag option 649 present can be reused over and over again. 651 When the "no-Request-Tag value" is used-up within a security context, 652 the Request-Tag value of a present but empty option can be used (1 653 Byte overhead), and when that is used-up, 256 values from one byte 654 long options (2 Bytes overhead) can be used. 656 In situations where those overheads are unacceptable (e.g. because 657 the payloads are known to be at a fragmentation threshold), the 658 absent Request-Tag value can be made usable again: 660 o In DTLS, a new session can be established. 662 o In OSCOAP, the sequence number can be artificially increased so 663 that all lost messages are outside of the replay window by the 664 time the first request of the new operation gets processed, and 665 all earlier operations can therefore be regarded as concluded. 667 Authors' Addresses 669 Christian Amsuess 670 Energy Harvesting Solutions 672 Email: c.amsuess@energyharvesting.at 674 John Mattsson 675 Ericsson AB 677 Email: john.mattsson@ericsson.com 679 Goeran Selander 680 Ericsson AB 682 Email: goran.selander@ericsson.com