idnits 2.17.1 draft-amsuess-core-cachable-oscore-01.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 February 2021) is 1149 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 (-10) exists of draft-ietf-core-groupcomm-bis-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-10 == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-14 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-11 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-09 == Outdated reference: A later version (-05) exists of draft-tiloca-core-observe-multicast-notifications-04 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Amsüss 3 Internet-Draft 4 Intended status: Standards Track M. Tiloca 5 Expires: 26 August 2021 RISE AB 6 22 February 2021 8 Cacheable OSCORE 9 draft-amsuess-core-cachable-oscore-01 11 Abstract 13 Group communication with the Constrained Application Protocol (CoAP) 14 can be secured end-to-end using Group Object Security for Constrained 15 RESTful Environments (Group OSCORE), also across untrusted 16 intermediary proxies. However, this sidesteps the proxies' abilities 17 to cache responses from the origin server(s). This specification 18 restores cachability of protected responses at proxies, by 19 introducing consensus requests which any client in a group can send 20 to one server or multiple servers in the same group. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Discussion of this document takes place on the CORE Working Group 27 mailing list (core@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/core/. 30 Source for this draft and an issue tracker can be found at 31 https://gitlab.com/chrysn/core-cachable-oscore/. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 26 August 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Deterministic Requests . . . . . . . . . . . . . . . . . . . 5 70 2.1. Design Considerations . . . . . . . . . . . . . . . . . . 6 71 2.2. Request-Hash . . . . . . . . . . . . . . . . . . . . . . 7 72 2.3. Use of Deterministic Requests . . . . . . . . . . . . . . 8 73 2.3.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 8 74 2.3.2. Client Processing of Deterministic Request . . . . . 9 75 2.3.3. Server Processing of Deterministic Request . . . . . 10 76 2.3.4. Response to a Deterministic Request . . . . . . . . . 12 77 2.3.5. Deterministic Requests to Multiple Servers . . . . . 13 78 3. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 4.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 15 81 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 5.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 5.2. Informative References . . . . . . . . . . . . . . . . . 17 84 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 18 85 Appendix B. Padding . . . . . . . . . . . . . . . . . . . . . . 18 86 B.1. Definition of the Padding Option . . . . . . . . . . . . 18 87 B.2. Using and processing the Padding option . . . . . . . . . 19 88 Appendix C. Simple Cachability using Ticket Requests . . . . . . 19 89 Appendix D. Application for more efficient end-to-end protected 90 multicast notifications . . . . . . . . . . . . . . . . . 20 91 Appendix E. Open questions . . . . . . . . . . . . . . . . . . . 21 92 Appendix F. Unsorted further ideas . . . . . . . . . . . . . . . 21 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 The Constrained Application Protocol (CoAP) [RFC7252] supports also 99 group communication, for instance over UDP and IP multicast 100 [I-D.ietf-core-groupcomm-bis]. In a group communication environment, 101 exchanged messages can be secured end-to-end by using Group Object 102 Security for Constrained RESTful Environments (Group OSCORE) 103 [I-D.ietf-core-oscore-groupcomm]. 105 Requests and responses protected with the group mode of Group OSCORE 106 can be read by all group members, i.e. not only by the intended 107 recipient(s), thus achieving group-level confidentiality. 109 This allows a trusted intermediary proxy which is also a member of 110 the OSCORE group to populate its cache with responses from origin 111 servers. Later on, the proxy can possibly reply to a request in the 112 group with a response from its cache, if recognized as an eligible 113 server by the client. 115 However, an untrusted proxy which is not member of the OSCORE group 116 only sees protected responses as opaque, uncacheable ciphertext. In 117 particular, different clients in the group that originate a same 118 plain CoAP request would send different protected requests, as a 119 result of their Group OSCORE processing. Such protected requests 120 cannot yield a cache hit at the proxy, which makes the whole caching 121 of protected responses pointless. 123 This document addresses this complication and enables cachability of 124 protected responses, also for proxies that are not members of the 125 OSCORE group and are unaware of OSCORE in general. To this end, it 126 builds on the concept of "consensus request" initially considered in 127 [I-D.tiloca-core-observe-multicast-notifications], and defines 128 "deterministic request" as a convenient incarnation of such concept. 130 Intuitively, given a GET or FETCH plain CoAP request, all clients 131 wishing to send that request are able to deterministically compute 132 the same protected request, using a variation on the pairwise mode of 133 Group OSCORE. It follows that cache hits become possible at the 134 proxy, which can thus serve clients in the group from its cache. 135 Like in [I-D.tiloca-core-observe-multicast-notifications], this 136 requires that clients and servers are already members of a suitable 137 OSCORE group. 139 Cachability of protected responses is useful also in applications 140 where several clients wish to retrieve the same object. Some 141 security properties of OSCORE are dispensed with to gain other 142 desirable properties. 144 1.1. Use cases 146 When firmware updates are delivered using CoAP, many similar devices 147 fetch large representations at the same time. Collecting them at a 148 proxy not only keeps the traffic low, but also lets the clients ride 149 single file to hide their numbers[SW:EPIV]. 151 When fanning out multicast data delivery, deterministic requests 152 allow for a more efficient setup (Appendix D). 154 1.2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 Readers are expected to be familiar with terms and concepts of CoAP 163 [RFC7252] and its method FETCH [RFC8132], group communication for 164 CoAP [I-D.ietf-core-groupcomm-bis], COSE 165 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], 166 OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 168 This document introduces the following new terms. 170 * Consensus Request: a Group OSCORE request that can be used 171 repeatedly to access a particular resource, hosted at one or more 172 servers in the OSCORE group. 174 A Consensus Request has all the properties relevant to caching, 175 but its transport dependent properties (e.g. Token or Message ID) 176 are not defined. Thus, different requests on the wire can both be 177 said to "be the same Consensus Request" even if they have 178 different Tokens or client addresses. 180 The Consensus Request is the reference for request-response 181 binding. Hence, if it does not generate a Consensus Request by 182 itself, the client has still to be able to read and verify any 183 obtained Consensus Request, before using it to verify a bound 184 response. 186 * Deterministic Client: a fictitious member of an OSCORE group, 187 having no Sender Sequence Number, no asymmetric key pair, and no 188 Recipient Context. 190 The Group Manager sets up the Deterministic Client, and assigns it 191 a unique Sender ID as for other group members. Furthermore, the 192 Deterministic Client has only the minimum common set of privileges 193 shared by all group members. 195 * Deterministic Request: a Consensus Request generated by the 196 Deterministic Client. The use of Deterministic Requests is 197 defined in Section 2. 199 * Ticket Request: a Consensus Request generated by the server 200 itself. 202 This term is not used in the main document, but is useful in 203 comparison with other applications of consensus requests that are 204 generated in a different way than as a Deterministic Request. The 205 prototypical Ticket Request is the Phantom Request defined in 206 [I-D.tiloca-core-observe-multicast-notifications]. 208 In Appendix C, the term is used bridge the gap to that draft. 210 2. Deterministic Requests 212 This section defines a method for clients starting from a same plain 213 CoAP request to independently arrive at a same Deterministic Request 214 protected with Group OSCORE. 216 While the first client sending the Deterministic Request actually 217 reaches the origin server, the response can be cached by an 218 intermediary proxy. Later on, a different client with the same plain 219 CoAP request would send the same Deterministic Request, which will be 220 served from the proxy's cache. 222 Clients build the unprotected Deterministic Request in a way which is 223 as much reproducible as possible. This document does not set out 224 full guidelines for minimizing the variation, but considered starting 225 points are: 227 * Set the inner Observe option to 0 if the requested resource is 228 described as observable, even if no observation is intended (and 229 no outer Observe is set). Thus, both observing and non-observing 230 requsts can be aggregated into a single request, that is 231 upstreamed as an observation at latest when any observing request 232 reaches the proxy. 234 * Avoid setting the ETag option in requests on a whim. Only set it 235 when there was a recent response with that ETag. When obtaining 236 later blocks, do not send the known-stale ETag. 238 * In block-wise transfer, maximally sized large inner blocks (szx=6) 239 should be selected. This serves not only to align the clients on 240 consistent cache entries, but also helps amortize the additional 241 data transferred in the per-message signatures. 243 Outer block-wise transfer can then be used if these messages 244 excede a hop's efficiently usable MTU size. 246 (If BERT [RFC8323] is usable with OSCORE, its use is fine as well; 247 in that case, the server picks a consistent block size for all 248 clients anyway). 250 * If padding (see Appendix B) is used to limit an adversary's 251 ability to deduce requests' content from their length, the length 252 requests are padded to should be agreed on among all users of a 253 security context. 255 These only serve to ensure that cache entries are utilized; failure 256 to follow them has no more severe consequences than decreasing the 257 utility of a cache. 259 2.1. Design Considerations 261 The hard part is arriving at a consensus pair (key, nonce) to be used 262 with the AEAD cipher for encrypting the Deterministic Request, while 263 also avoiding reuse of the same (key, nonce) pair across different 264 requests. 266 Diversity can conceptually be enforced by applying a cryptographic 267 hash function to the complete input of the encryption operation over 268 the plain CoAP request (i.e., the AAD and the plaintext of the COSE 269 object), and then using the result as source of uniqueness. Any non- 270 malleable cryptographically secure hash of sufficient length to make 271 collisions sufficiently unlikely is suitable for this purpose. 273 A tempting possibility is to use a fixed key, and use the hash as a 274 deterministic AEAD nonce for each Deterministic Request throught the 275 Partial IV component (see Section 5.2 of [RFC8613]). However, the 40 276 bit available for the Partial IV are by far insufficient to ensure 277 that the deterministic nonce is not reused across different 278 Deterministic Requests. Even if the full deterministic AEAD nonce 279 could be set, the sizes used by common algorithms would still be too 280 small. 282 As a consequence, the proposed method takes the opposite approach, by 283 considering a fixed deterministic AEAD nonce, while generating a 284 different deterministic encryption key for each Deterministic 285 Request. That is, the hash computed over the plain CoAP request is 286 taken as input to the key generation. As an advantage, this approach 287 does not require to transport the computed hash in the OSCORE option. 289 [ Note: This has a further positive side effect arising with version 290 -11 of Group OSCORE. That is, since the full encoded OSCORE option 291 is part of the AAD, it avoids a circular dependency from feeding the 292 AAD into the hash computation, which in turn needs crude workarounds 293 like building the full AAD twice, or zeroing out the hash-to-be. ] 295 2.2. Request-Hash 297 In order to transport the hash of the plain CoAP request, a new CoAP 298 option is defined, which MUST be supported by clients and servers 299 that support Deterministic Requests. 301 The option is called Request-Hash. As summarized in Figure 1, the 302 Request-Hash option is elective, safe to forward, part of the cache 303 key and repeatable. 305 +------+---+---+---+---+--------------+--------+--------+---------+ 306 | No. | C | U | N | R | Name | Format | Length | Default | 307 +------+---+---+---+---+--------------+--------+--------+---------+ 308 | TBD1 | | | | x | Request-Hash | opaque | any | (none) | 309 +------+---+---+---+---+--------------+--------+--------+---------+ 311 Figure 1: Request-Hash Option 313 The Request-Hash option is identical in all its properties to the 314 Request-Tag option defined in [I-D.ietf-core-echo-request-tag], with 315 the following exceptions: 317 * It may be arbitrarily long. 319 Implementations can limit its length to that of the longest output 320 of the supported hash functions. 322 * A proxy MAY use any fresh cached response from the selected server 323 to respond to a request with the same Request-Hash (or possibly 324 even if the new request's Request-Hash is a prefix of the cached 325 one). 327 This is a potential future optimization which is not mentioned 328 anywhere else yet, and allows clients to elide all other options 329 and payload if it has reason to believe that it can produce a 330 cache hit with the abbreviated request alone. 332 * When used with a Deterministic Request, this option is created at 333 message protection time by the client, and used before message 334 unprotection by the server. Therefore, when used in a 335 Deterministic Request, this option is treated as Class U for 336 OSCORE [RFC8613]. Other uses of this option can put it into 337 different classes for OSCORE the processing. 339 2.3. Use of Deterministic Requests 341 This section defines how a Deterministic Request is built on the 342 client side and then processed on the server side. 344 2.3.1. Pre-Conditions 346 The use of Deterministic Requests in an OSCORE group requires that 347 the interested group members are aware of the Deterministic Client in 348 the group. In particular, they need to know: 350 * The Sender ID of the Deterministic Client, to be used as 'kid' 351 parameter for the Deterministic Requests. This allows all group 352 members to compute the Sender Key of the Deterministic Client. 354 * The hash algorithm to use for computing the hash of a plain CoAP 355 request, when producing the associated Deterministic Request. 357 * Optionally, a creation timestamp associated to the Deterministic 358 Client. This is aligned with the Group Manager that might replace 359 the current Deterministic Client with a new one with a different 360 Sender ID, e.g. to enforce freshness indications without rekeying 361 the whole group. 363 Group members have to obtain this information from the Group Manager. 364 A group member can do that, for instance, when obtaining the group 365 key material upon joining the OSCORE group, or later on as an active 366 member by sending a request to a dedicated resource at the Group 367 Manager. In either case, information on the latest Deterministic 368 Client is returned. 370 The Group Manager defined in [I-D.ietf-ace-key-groupcomm-oscore] can 371 be easily extended to support the provisioning of information about 372 the Deterministic Client; no such extension has been drafted as of 373 the publication of this draft. 375 2.3.2. Client Processing of Deterministic Request 377 In order to build a Deterministic Request, the client protects the 378 plain CoAP request using the pairwise mode of Group OSCORE (see 379 Section 9 of [I-D.ietf-core-oscore-groupcomm]), with the following 380 alterations. 382 1. When preparing the OSCORE option, the AAD and the AEAD nonce: 384 * The used Sender ID is the Deterministic Client's Sender ID. 386 * The used Partial IV is 0, hence it does not need to be set in 387 the OSCORE option. 389 2. The client uses the hash function indicated for the Deterministic 390 Client, and computes a hash H over the following input: the 391 Sender Key of the Deterministic Client, concatenated with the AAD 392 from step 1, concatenated with the COSE plaintext. 394 Note that the payload of the plain CoAP request (if any) is not 395 self-delimiting, and thus hash functions are limited to non- 396 malleable ones. 398 3. The client derives the Pairwise Sender Key K as defined in 399 Section 2.3.1 of [I-D.ietf-core-oscore-groupcomm], with the 400 following differences: 402 * The Sender Key of the Deterministic Client is used as first 403 argument of the HKDF. 405 * The hash H from step 2 is used as second argument of the HKDF, 406 i.e. as "Shared Secret" computable by all the group members. 408 An actual Diffie-Hellman secret cannot be obtained, as there 409 is no public key associated with the deterministic client. 411 * The Sender ID of the Deterministic Client is used as value for 412 the 'id' element of the 'info' parameter used as third 413 argument of the HKDF. 415 4. The client includes a Request-Hash option in the request to 416 protect, with value set to the hash H from Step 2. 418 5. The client updates the value of the 'request_kid' field in the 419 AAD, and sets it to the hash H from step 2. 421 (This step is still under active debate: While setting it like that 422 makes the request and response AADs consistent, it is also means that 423 implementations which build the AAD in memory need to do so twice). 425 1. The client protects the request using the pairwise mode of Group 426 OSCORE as defined in Section 9.3 of 427 [I-D.ietf-core-oscore-groupcomm], using the AEAD nonce from step 428 1, the AEAD encryption key from step 3, and the finalized AAD 429 from step 5. 431 2. The client sets FETCH as the outer code of the protected request 432 to make it usable for a proxy's cache, even if no observation is 433 requested [RFC7641]. 435 The result is the Deterministic Request to be sent. 437 Since the encryption key K is derived using material from the whole 438 plain CoAP request, this (key, nonce) pair is only used for this very 439 message, which is deterministically encrypted unless there is a hash 440 collision between two Deterministic Requests. 442 The deterministic encryption requires the used AEAD algorithm to be 443 deterministic in itself. This is the case for all the AEAD 444 algorithms currently registered with COSE in [COSE.Algorithms]. For 445 future algorithms, a flag in the COSE registry is to be added. 447 Note that, while the process defined above is based on the pairwise 448 mode of Group OSCORE, no information about the server takes part to 449 the key derivation or is included in the AAD. This is intentional, 450 since it allows for sending a deterministic request to multiple 451 servers at once (see Section 2.3.5). On the other hand, it requires 452 later checks at the client when verifying a response to a 453 Deterministic Request (see Section 2.3.4). 455 2.3.3. Server Processing of Deterministic Request 457 Upon receiving a Deterministic Request, a server performs the 458 following actions. 460 A server that does not support Deterministic Requests would not be 461 able to create the necessary Recipient Context, and thus will fail 462 decrypting the request. 464 1. If not already available, the server retrieves the information 465 about the Deterministic Client from the Group Manager, and 466 derives the Sender Key of the Deterministic Client. 468 2. The server actually recognizes the request to be a Deterministic 469 Request, due to the presence of the Request-Hash option and to 470 the 'kid' parameter of the OSCORE option set to the Sender ID of 471 the Deterministic Client. 473 If the 'kid' parameter of the OSCORE option specifies a different 474 Sender ID than the one of the Deterministic Client, the server 475 MUST NOT take the following steps, and instead processes the 476 request as per Section 9.4 of [I-D.ietf-core-oscore-groupcomm]. 478 3. The server retrieves the hash H from the Request-Hash option. 480 4. The server derives a Recipient Context for processing the 481 Deterministic Request. In particular: 483 * The Recipient ID is the Sender ID of the Deterministic Client. 485 * The Recipient Key is derived as the key K in step 3 of 486 Section 2.3.2, with the hash H retrieved at the previous step. 488 5. The server verifies the request using the pairwise mode of Group 489 OSCORE, as defined in Section 9.4 of 490 [I-D.ietf-core-oscore-groupcomm], using the Recipient Context 491 from step 4, with the following differences. 493 * The server sets the value of the 'request_kid' field in the 494 AAD to be the hash H from step 3. 496 * The server does not perform replay checks against a Replay 497 Window (see below). 499 In case of successful verification, the server MUST also perform the 500 following actions, before possibly delivering the request to the 501 application. 503 * Starting from the recovered plain CoAP request, the server MUST 504 recompute the same hash that the client computed at step 2 of 505 Section 2.3.2. 507 If the recomputed hash value differs from the value retrieved from 508 the Request-Hash option at step 3, the server MUST treat the 509 request as invalid and MAY reply with an unprotected 4.00 (Bad 510 Request) error response. The server MAY set an Outer Max-Age 511 option with value zero. The diagnostic payload MAY contain the 512 string "Decryption failed". 514 This prevents an attacker that guessed a valid authentication tag 515 for a given Request-Hash value to poison caches with incorrect 516 responses. 518 * The server MUST verify that the unprotected request is safe to be 519 processed in the REST sense, i.e. that it has no side effects. If 520 verification fails, the server MUST discard the message and SHOULD 521 reply with a protected 4.01 (Unauthorized) error response. 523 Note that some CoAP implementations may not be able to prevent 524 that an application produces side effects from a safe request. 525 This may incur checking whether the particular resource handler is 526 explicitly marked as eligible for processing deterministic 527 requests. An implementation may also have a configured list of 528 requests that are known to be side effect free, or even a pre- 529 built list of valid hashes for all sensible requests for them, and 530 reject any other request. 532 These checks replace the otherwise present requirement that the 533 server needs to check the Replay Window of the Recipient Context 534 (see step 5 above), which is inapplicable with the Recipient 535 Context derived at step 4 from the value of the Request-Hash 536 option. The reasoning is analogous to the one in 537 [I-D.amsuess-lwig-oscore] to treat the potential replay as 538 answerable, if the handled request is side effect free. 540 2.3.4. Response to a Deterministic Request 542 Both when protecting and unprotecting the response, the 'request_kid' 543 field of the external AAD is replaced with the Request-Hash value. 544 This creates the request-response binding ensuring that no mismatched 545 responses can be successfully unprotected. 547 [ Note: Mismatching this with the actual request's 'request_kid' 548 (that stays the Deterministic Client's Sender ID) is ugly, but also 549 the only way to avoid any zeroing/rebuilding of the AAD. ] 551 [ Suggestion for any OSCORE v2: avoid request details in the 552 request's AAD as individual elements. Rather than having 553 'request_kid', 'request_piv' and (in Group OSCORE) 554 'request_kid_context' as separate fields, they can better be 555 something more pluggable. ] 557 When preparing the response, the server performs the following 558 actions. 560 * The server sets a non-zero Max-Age option, thus making the 561 Deterministic Request usable for the proxy cache. 563 * The server MUST protect the response using the group mode of Group 564 OSCORE, as defined in Section 8.3 of 565 [I-D.ietf-core-oscore-groupcomm]. This is required to ensure that 566 the client can verify source authentication of the response, since 567 the "pairwise" key used for the Deterministic Request is actually 568 shared among all the group members. 570 In particular, the server sets the value of the 'request_kid' 571 field in the AAD to be the hash H retrieved from the Request-Hash 572 option of the Deterministic Request (see step 3 in Section 2.3.3). 574 * The server MUST use its own Sender Sequence Number as Partial IV 575 to protect the response, and include it as Partial IV in the 576 OSCORE option of the response. This is required since the server 577 does not perform replay protection on the Deterministic Request 578 (see Section 2.3.4). 580 * The server uses 2.05 (Content) as outer code even though it is not 581 necessarily an Observe notification [RFC7641], in order to make 582 the response cacheable. 584 Upon receiving the response, the client performs the following 585 actions. 587 * In case the response includes a 'kid' in the OSCORE option and 588 unless responses from multiple servers are expected (see 589 Section 2.3.5), the client MUST verify it to be exactly the 'kid' 590 of the server to which the Deterministic Request was sent. 592 * The client verifies the response using the group mode of Group 593 OSCORE, as defined in Section 8.4 of 594 [I-D.ietf-core-oscore-groupcomm]. In particular, the client 595 verifies the counter signature in the response, based on the 'kid' 596 of the server it sent the request to. 598 2.3.5. Deterministic Requests to Multiple Servers 600 A Deterministic Request _can_ be sent to a CoAP group, e.g. over UDP 601 and IP multicast [I-D.ietf-core-groupcomm-bis], thus targeting 602 multiple servers at once. 604 To simplify key derivation, such a Deterministic Request is still 605 created in the same way as a one-to-one request and still protected 606 with the pairwise mode of Group OSCORE, as defined in Section 2.3.2. 608 [ Note: If it was protected with the group mode, the request hash 609 would need to be fed into the group key derivation just for this 610 corner case. Furthermore, there would need to be a signature from 611 the absent public key. ] 613 When a server receives a request from the Deterministic Client as 614 addressed to a CoAP group, the server MUST include its own Sender ID 615 in the response, as 'kid' parameter of the OSCORE option. 617 Although it is normally optional for the server to include its Sender 618 ID when replying to a request protected in pairwise mode, it is 619 required in this case for allowing the client to retrieve the 620 Recipient Context associated to the server originating the response. 622 3. Security Considerations 624 The same security considerations from [RFC7252][I-D.ietf-core-groupco 625 mm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this 626 document. 628 Compared to Group OSCORE, deterministic requests dispense with some 629 of OSCORE's security properties by just so much as to make caching 630 possible: 632 * Receiving a response to a deterministic request does not mean that 633 the response was generated after the request was sent. 635 It still contains two freshness statements, though: 637 - It is more recent than any other response from the same group 638 member that has a smaller sequence number. 640 - It is more recent than the original creation of the 641 deterministic security context. 643 * Request confidentiality is limited. 645 An intermediary can determine that two requests from different 646 clients are identical, and associate the different responses 647 generated for them. Padding is suggested for responses where 648 necessary. 650 * Source authentication for requests is lost. 652 Instead, the server must verify that the request (precisely: its 653 handler) is side effect free. The distinct semantics of the CoAP 654 request codes can help the server make that assessment. 656 [ More on the verification of the Deterministic Request ] 658 4. IANA Considerations 660 This document has the following actions for IANA. 662 4.1. CoAP Option Numbers Registry 664 IANA is asked to enter the following option numbers to the "CoAP 665 Option Numbers" registry defined in [RFC7252] within the "CoRE 666 Parameters" registry. 668 +--------+--------------+-------------------+ 669 | Number | Name | Reference | 670 +--------+--------------+-------------------+ 671 | TBD1 | Request-Hash | [[this document]] | 672 +--------+--------------+-------------------+ 673 | TBD2 | Padding | [[this document]] | 674 +--------+--------------+-------------------+ 676 Figure 2: CoAP Option Numbers 678 [ 680 For the Request-Hash option, the number suggested to IANA is 548. 682 For the Padding option, the option number is picked to be the highest 683 number in the Experts Review range; the high option number allows it 684 to follow practically all other options, and thus to be set when the 685 final unpadded message length including all options is known. 686 Therefore, the number suggested to IANA is 64988. 688 Applications that make use of the "Experimental use" range and want 689 to preserve that property are invited to pick the largest suitable 690 experimental number (65532) 692 Note that unless other high options are used, this means that padding 693 a message adds an overhead of at least 3 bytes, i.e. 1 byte for 694 option delta/length and two more bytes of extended option delta. 695 This is considered acceptable overhead, given that the application 696 has already chosen to prefer the privacy gains of padding over wire 697 transfer length. 699 ] 701 5. References 703 5.1. Normative References 705 [I-D.ietf-core-groupcomm-bis] 706 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 707 for the Constrained Application Protocol (CoAP)", Work in 708 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 709 02, 2 November 2020, . 712 [I-D.ietf-core-oscore-groupcomm] 713 Tiloca, M., Selander, G., Palombini, F., and J. Park, 714 "Group OSCORE - Secure Group Communication for CoAP", Work 715 in Progress, Internet-Draft, draft-ietf-core-oscore- 716 groupcomm-10, 2 November 2020, . 719 [I-D.ietf-cose-rfc8152bis-struct] 720 Schaad, J., "CBOR Object Signing and Encryption (COSE): 721 Structures and Process", Work in Progress, Internet-Draft, 722 draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020, 723 . 726 [I-D.ietf-cose-rfc8152bis-algs] 727 Schaad, J., "CBOR Object Signing and Encryption (COSE): 728 Initial Algorithms", Work in Progress, Internet-Draft, 729 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 730 . 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, 735 DOI 10.17487/RFC2119, March 1997, 736 . 738 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 739 Application Protocol (CoAP)", RFC 7252, 740 DOI 10.17487/RFC7252, June 2014, 741 . 743 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 744 FETCH Methods for the Constrained Application Protocol 745 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 746 . 748 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 749 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 750 May 2017, . 752 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 753 "Object Security for Constrained RESTful Environments 754 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 755 . 757 [COSE.Algorithms] 758 IANA, "COSE Algorithms", 759 . 762 5.2. Informative References 764 [RFC7641] Hartke, K., "Observing Resources in the Constrained 765 Application Protocol (CoAP)", RFC 7641, 766 DOI 10.17487/RFC7641, September 2015, 767 . 769 [I-D.ietf-core-echo-request-tag] 770 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 771 Request-Tag, and Token Processing", Work in Progress, 772 Internet-Draft, draft-ietf-core-echo-request-tag-11, 2 773 November 2020, . 776 [I-D.ietf-ace-key-groupcomm-oscore] 777 Tiloca, M., Park, J., and F. Palombini, "Key Management 778 for OSCORE Groups in ACE", Work in Progress, Internet- 779 Draft, draft-ietf-ace-key-groupcomm-oscore-09, 2 November 780 2020, . 783 [I-D.amsuess-lwig-oscore] 784 Amsuess, C., "OSCORE Implementation Guidance", Work in 785 Progress, Internet-Draft, draft-amsuess-lwig-oscore-00, 29 786 April 2020, . 789 [I-D.tiloca-core-observe-multicast-notifications] 790 Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, 791 "Observe Notifications as CoAP Multicast Responses", Work 792 in Progress, Internet-Draft, draft-tiloca-core-observe- 793 multicast-notifications-04, 2 November 2020, 794 . 797 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 798 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 799 Application Protocol) over TCP, TLS, and WebSockets", 800 RFC 8323, DOI 10.17487/RFC8323, February 2018, 801 . 803 Appendix A. Change log 805 Since -00: 807 * More precise specification of the hashing (guided by first 808 implementations) 810 * Focus shifted to deterministic requests (where it should have been 811 in the first place; all the build-up of Token Requests was moved 812 to a motivating appendix) 814 * Aligned with draft-tiloca-core-observe-responses-multicast-05 (not 815 submitted at the time of submission) 817 * List the security properties lost compared to OSCORE 819 Appendix B. Padding 821 As discussed in Section 3, information can be leaked by the length of 822 a response or, in different contexts, of a request. 824 In order to hide such information and mitigate the impact on privacy, 825 the following Padding option is defined, to allow increasing a 826 message's length without changing its meaning. 828 The option can be used with any CoAP transport, but is especially 829 useful with OSCORE as that does not provide any padding of its own. 831 Before choosing to pad a message by using the Padding option, 832 application designers should consider whether they can arrange for 833 common message variants to have the same length by picking a suitable 834 content representation; the canonical example here is expressing 835 "yes" and "no" with "y" and "n", respectively. 837 B.1. Definition of the Padding Option 839 As summarized in Figure 3, the Padding option is elective, safe to 840 forward and not part of the cache key; these follow from the usage 841 instructions. The option may be repeated, as that may be the only 842 way to achieve a certain total length for the padded message. 844 +------+---+---+---+---+---------+--------+--------+---------+ 845 | No. | C | U | N | R | Name | Format | Length | Default | 846 +------+---+---+---+---+---------+--------+--------+---------+ 847 | TBD2 | | | x | x | Padding | opaque | any | (none) | 848 +------+---+---+---+---+---------+--------+--------+---------+ 850 Figure 3: Padding Option 852 B.2. Using and processing the Padding option 854 A client may set the Padding option, specifying any content of any 855 length as its value. 857 A server MUST ignore the option. 859 Proxies are free to keep the Padding option on a message, to remove 860 it or to add further padding of their own. 862 Appendix C. Simple Cachability using Ticket Requests 864 Building on the concept of Phantom Requests and Informative Responses 865 defined in [I-D.tiloca-core-observe-multicast-notifications], basic 866 caching is already possible without building a Deterministic Request. 868 This appendix is not provided for application (for it is only 869 efficient when dealing with very large representations and no OSCORE 870 inner Block-Wise mode, which is inefficient for other reasons, and 871 for observations which are already well covered in 872 [I-D.tiloca-core-observe-multicast-notifications]). It is more 873 provided as a "mental exercise" for the authors and interested 874 readers to bridge the gap between these documents. 876 That is, instead of replying to a client with a regular response, a 877 server can send an Informative Response, defined as a protected 5.03 878 (Service Unavailable) error message. The payload of the Informative 879 Response contains the Phantom Request, which is a Ticket Request in 880 this document's broader terminology. 882 Unlike a Deterministic Request, a Phantom Request is protected in 883 Group Mode. Instead of verifying a hash, the client can see from the 884 signature that this was indeed the request the server is answering. 885 The client also verifies that the request URI is identical between 886 the original request and the Ticket Request. 888 The remaining exchange largely plays out like in 889 [I-D.tiloca-core-observe-multicast-notifications]'s "Example with a 890 Proxy and Group OSCORE": The client sends the Phantom Request to the 891 proxy (but, lacking a "tp_info", without a Listen-To-Multicast- 892 Responses option), which forwards it to the server for lack of the 893 option. 895 The server then produces a regular response and includes a non-zero 896 Max-Age option as an outer CoAP option. Note that there is no point 897 in including in an inner Max-Age option, as the client could not pin 898 it in time. 900 When a second, different client later asks for the same resource at 901 the same server, its new request uses a different 'kid' and 'Partial 902 IV' than the first client's. Thus, the new request produces a cache 903 miss at the proxy and is forwarded to the server, which responds with 904 the same Ticket Request provided to the first client. After that, 905 when the second client sends the Ticket Request, a cache hit at the 906 proxy will be produced, and the Ticket Request can be served from the 907 proxy's cache. 909 When multiple proxies are in use, or the response has expired from 910 the proxy's cache, the server receives the Ticket Request multiple 911 times. It is a matter of perspective whether the server treats that 912 as an acceptable replay (given that this whole mechansim only makes 913 sense on requests free of side effects), or whether it is 914 conceptualized as having an internal proxy where the request produces 915 a cache hit. 917 Appendix D. Application for more efficient end-to-end protected 918 multicast notifications 920 Comparing the "Example with a Proxy" and the "Example with a Proxy 921 and Group OSCORE" in 922 [I-D.tiloca-core-observe-multicast-notifications] shows that with 923 OSCORE, more requests than without need to hit the server. This is 924 because every client originally protects their request individually 925 and thus needs a custom response served to send the Phantom Request 926 as a Ticket Request. 928 If the clients send their deterministic requests in a deterministic 929 way, and the server uses these requests as Ticket Requests as well, 930 then there is no need for a Phantom Request to be sent back to the 931 client. 933 Instead, the server can send an unprotected Informative Response very 934 much like in the example without OSCORE, setting the proxy up and 935 giving the latest response along the way. 937 The proxy can thus be configured by the server with the first 938 request, and has an active observation and a fresh cache entry in 939 time for the second client to arrive. 941 Appendix E. Open questions 943 * Is "deterministic encryption" something worthwhile to consider in 944 COSE? 946 COSE would probably specify something more elaborate for the KDF 947 (the current KDF round is the pairwise mode's; COSE would probably 948 run through KDF with a KDF context structure). 950 COSE would give a header parameter name to the Request-Hash (which 951 for the purpose of OSCORE deterministic requests would put back 952 into Request-Hash by extending the option compression function 953 across the two options). 955 Conceptually, they should align well, and the implementation 956 changes are likely limited to how the KDF is run. 958 * An unprotection failure from a mismatched hash will not be part of 959 the ideally constant-time code paths that otherwise lead to AEAD 960 unprotect failures. Is that a problem? 962 After all, it does tell the attacker that they did succeed in 963 producing a valid MAC (it's just not doing it any good, because 964 this key is only used for deterministic requests and thus also 965 needs to pass the Request-Hash check). 967 Appendix F. Unsorted further ideas 969 * All or none of the deterministic requests should have an inner 970 observe option. Preferably none - that makes messages shorter, 971 and clients need to ignore that option either way when checking 972 whether a Consensus Request matches their intended request. 974 Acknowledgments 976 The authors sincerely thank Jim Schaad for his comments and feedback. 978 The work on this document has been partly supported by VINNOVA and 979 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 980 (Grant agreement 952652). 982 Authors' Addresses 983 Christian Amsüss 984 Austria 986 Email: christian@amsuess.com 988 Marco Tiloca 989 RISE AB 990 Isafjordsgatan 22 991 SE-16440 Stockholm Kista 992 Sweden 994 Email: marco.tiloca@ri.se