idnits 2.17.1 draft-amsuess-core-cachable-oscore-02.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(852): 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 5 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 (13 July 2021) is 1010 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-04 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-12 -- 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-13 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-11 == Outdated reference: A later version (-08) exists of draft-ietf-core-observe-multicast-notifications-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-43 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: 14 January 2022 RISE AB 6 13 July 2021 8 Cacheable OSCORE 9 draft-amsuess-core-cachable-oscore-02 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 cacheability 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 14 January 2022. 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. Deterministic Unprotected Request . . . . . . . . . . . . 5 71 2.2. Design Considerations . . . . . . . . . . . . . . . . . . 6 72 2.3. Request-Hash . . . . . . . . . . . . . . . . . . . . . . 7 73 2.4. Use of Deterministic Requests . . . . . . . . . . . . . . 8 74 2.4.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 8 75 2.4.2. Client Processing of Deterministic Request . . . . . 9 76 2.4.3. Server Processing of Deterministic Request . . . . . 10 77 2.4.4. Response to a Deterministic Request . . . . . . . . . 12 78 2.4.5. Deterministic Requests to Multiple Servers . . . . . 14 79 3. Obtaining Information about the Deterministic Client . . . . 14 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 5.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 16 83 5.2. OSCORE Security Context Parameters Registry . . . . . . . 17 84 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 6.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20 88 Appendix B. Padding . . . . . . . . . . . . . . . . . . . . . . 21 89 B.1. Definition of the Padding Option . . . . . . . . . . . . 21 90 B.2. Using and processing the Padding option . . . . . . . . . 22 91 Appendix C. Simple Cacheability using Ticket Requests . . . . . 22 92 Appendix D. Application for More Efficient End-to-End Protected 93 Multicast Notifications . . . . . . . . . . . . . . . . . 23 94 Appendix E. Open questions . . . . . . . . . . . . . . . . . . . 24 95 Appendix F. Unsorted further ideas . . . . . . . . . . . . . . . 24 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 99 1. Introduction 101 The Constrained Application Protocol (CoAP) [RFC7252] supports also 102 group communication, for instance over UDP and IP multicast 103 [I-D.ietf-core-groupcomm-bis]. In a group communication environment, 104 exchanged messages can be secured end-to-end by using Group Object 105 Security for Constrained RESTful Environments (Group OSCORE) 106 [I-D.ietf-core-oscore-groupcomm]. 108 Requests and responses protected with the group mode of Group OSCORE 109 can be read by all group members, i.e. not only by the intended 110 recipient(s), thus achieving group-level confidentiality. 112 This allows a trusted intermediary proxy which is also a member of 113 the OSCORE group to populate its cache with responses from origin 114 servers. Later on, the proxy can possibly reply to a request in the 115 group with a response from its cache, if recognized as an eligible 116 server by the client. 118 However, an untrusted proxy which is not member of the OSCORE group 119 only sees protected responses as opaque, uncacheable ciphertext. In 120 particular, different clients in the group that originate a same 121 plain CoAP request would send different protected requests, as a 122 result of their Group OSCORE processing. Such protected requests 123 cannot yield a cache hit at the proxy, which makes the whole caching 124 of protected responses pointless. 126 This document addresses this complication and enables cacheability of 127 protected responses, also for proxies that are not members of the 128 OSCORE group and are unaware of OSCORE in general. To this end, it 129 builds on the concept of "consensus request" initially considered in 130 [I-D.ietf-core-observe-multicast-notifications], and defines 131 "deterministic request" as a convenient incarnation of such concept. 133 All clients wishing to send a particular GET or FETCH request are 134 able to deterministically compute the same protected request, using a 135 variation on the pairwise mode of Group OSCORE. It follows that 136 cache hits become possible at the proxy, which can thus serve clients 137 in the group from its cache. Like in 138 [I-D.ietf-core-observe-multicast-notifications], this requires that 139 clients and servers are already members of a suitable OSCORE group. 141 Cacheability of protected responses is useful also in applications 142 where several clients wish to retrieve the same object from a single 143 server. Some security properties of OSCORE are dispensed with to 144 gain other desirable properties. 146 1.1. Use cases 148 When firmware updates are delivered using CoAP, many similar devices 149 fetch large representations at the same time. Collecting them at a 150 proxy not only keeps the traffic low, but also lets the clients ride 151 single file to hide their numbers[SW-EPIV] and identities. 153 When relying on intermediaries to fan out the delivery of multicast 154 data protected end-to-end as in 155 [I-D.ietf-core-observe-multicast-notifications], deterministic 156 requests allow for a more efficient setup, by reducing the amount of 157 message exchanges and enabling early population of cache entries (see 158 Appendix D). 160 1.2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 Readers are expected to be familiar with terms and concepts of CoAP 169 [RFC7252] and its method FETCH [RFC8132], group communication for 170 CoAP [I-D.ietf-core-groupcomm-bis], COSE 171 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], 172 OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 174 This document introduces the following new terms. 176 * Consensus Request: a CoAP request protected with Group OSCORE that 177 can be used repeatedly to access a particular resource, hosted at 178 one or more servers in the OSCORE group. 180 A Consensus Request has all the properties relevant to caching, 181 but its transport dependent properties (e.g. Token or Message ID) 182 are not defined. Thus, different requests on the wire can be said 183 to "be the same Consensus Request" even if they have different 184 Tokens or source addresses. 186 The Consensus Request is the reference for request-response 187 binding. In general, a client processing a response to a 188 consensus request did not generate (and thus sign) the consensus 189 request. The client not only needs to decrypt the Consensus 190 Request to understand a response to it (for example to tell which 191 path was requested), it also needs to verify that this is the only 192 Consensus Request that could elicit this response. 194 * Deterministic Client: a fictitious member of an OSCORE group, 195 having no Sender Sequence Number, no asymmetric key pair, and no 196 Recipient Context. 198 The Group Manager sets up the Deterministic Client, and assigns it 199 a unique Sender ID as for other group members. Furthermore, the 200 Deterministic Client has only the minimum common set of privileges 201 shared by all group members. 203 * Deterministic Request: a Consensus Request generated by the 204 Deterministic Client. The use of Deterministic Requests is 205 defined in Section 2. 207 * Ticket Request: a Consensus Request generated by the server 208 itself. 210 This term is not used in the main document, but is useful in 211 comparison with other applications of consensus requests that are 212 generated in a different way than as a Deterministic Request. The 213 prototypical Ticket Request is the Phantom Request defined in 214 [I-D.ietf-core-observe-multicast-notifications]. 216 In Appendix C, the term is used to bridge the gap to that draft. 218 2. Deterministic Requests 220 This section defines a method for clients starting from a same plain 221 CoAP request to independently arrive at a same Deterministic Request 222 protected with Group OSCORE. 224 2.1. Deterministic Unprotected Request 226 Clients build the unprotected Deterministic Request in a way which is 227 as much reproducible as possible. This document does not set out 228 full guidelines for minimizing the variation, but considered starting 229 points are: 231 * Set the inner Observe option to 0 if the requested resource is 232 described as observable, even if no observation is intended (and 233 no outer Observe is set). Thus, both observing and non-observing 234 requests can be aggregated into a single request, that is 235 upstreamed as an observation at the latest when any observing 236 request reaches the proxy. 238 * Avoid setting the ETag option in requests on a whim. Only set it 239 when there was a recent response with that ETag. When obtaining 240 later blocks, do not send the known-stale ETag. 242 * In block-wise transfer, maximally sized large inner blocks (szx=6) 243 should be selected. This serves not only to align the clients on 244 consistent cache entries, but also helps amortize the additional 245 data transferred in the per-message signatures. 247 Outer block-wise transfer can then be used if these messages excede a 248 hop's efficiently usable MTU size. 250 (If BERT [RFC8323] is usable with OSCORE, its use is fine as well; in 251 that case, the server picks a consistent block size for all clients 252 anyway). 254 * If padding (see Appendix B) is used to limit an adversary's 255 ability to deduce requests' content from their length, the 256 requests are padded to reach a total length that should be agreed 257 on among all users of a security context. 259 These only serve to ensure that cache entries are utilized; failure 260 to follow them has no more severe consequences than decreasing the 261 utility and effectiveness of a cache. 263 2.2. Design Considerations 265 The hard part is arriving at a consensus pair (key, nonce) to be used 266 with the AEAD cipher for encrypting the Deterministic Request, while 267 also avoiding reuse of the same (key, nonce) pair across different 268 requests. 270 Diversity can conceptually be enforced by applying a cryptographic 271 hash function to the complete input of the encryption operation over 272 the plain CoAP request (i.e., the AAD and the plaintext of the COSE 273 object), and then using the result as source of uniqueness. Any non- 274 malleable cryptographically secure hash of sufficient length to make 275 collisions sufficiently unlikely is suitable for this purpose. 277 A tempting possibility is to use a fixed key, and use the hash as a 278 deterministic AEAD nonce for each Deterministic Request throught the 279 Partial IV component (see Section 5.2 of [RFC8613]). However, the 40 280 bit available for the Partial IV are by far insufficient to ensure 281 that the deterministic nonce is not reused across different 282 Deterministic Requests. Even if the full deterministic AEAD nonce 283 could be set, the sizes used by common algorithms would still be too 284 small. 286 As a consequence, the proposed method takes the opposite approach, by 287 considering a fixed deterministic AEAD nonce, while generating a 288 different deterministic encryption key for each Deterministic 289 Request. That is, the hash computed over the plain CoAP request is 290 taken as input to the key generation. As an advantage, this approach 291 does not require to transport the computed hash in the OSCORE option. 293 [ Note: This has a further positive side effect arising with version 294 -11 of Group OSCORE. That is, since the full encoded OSCORE option 295 is part of the AAD, it avoids a circular dependency from feeding the 296 AAD into the hash computation, which in turn needs crude workarounds 297 like building the full AAD twice, or zeroing out the hash-to-be. ] 299 2.3. Request-Hash 301 In order to transport the hash of the plain CoAP request, a new CoAP 302 option is defined, which MUST be supported by clients and servers 303 that support Deterministic Requests. 305 The option is called Request-Hash. As summarized in Figure 1, the 306 Request-Hash option is elective, safe to forward, part of the cache 307 key and repeatable. 309 +------+---+---+---+---+--------------+--------+--------+---------+ 310 | No. | C | U | N | R | Name | Format | Length | Default | 311 +------+---+---+---+---+--------------+--------+--------+---------+ 312 | TBD1 | | | | x | Request-Hash | opaque | any | (none) | 313 +------+---+---+---+---+--------------+--------+--------+---------+ 315 Figure 1: Request-Hash Option 317 The Request-Hash option is identical in all its properties to the 318 Request-Tag option defined in [I-D.ietf-core-echo-request-tag], with 319 the following exceptions: 321 * It may be arbitrarily long. 323 Implementations can limit its length to that of the longest output 324 of the supported hash functions. 326 * A proxy MAY use any fresh cached response from the selected server 327 to respond to a request with the same Request-Hash (or possibly 328 even if the new request's Request-Hash is a prefix of the cached 329 one). 331 This is a potential future optimization which is not mentioned 332 anywhere else yet, and allows clients to elide all other options 333 and payload if it has reason to believe that it can produce a 334 cache hit with the abbreviated request alone. 336 * It may be present in responses (TBD: Does this affect any other 337 properties?). 339 * When used with a Deterministic Request, this option is created at 340 message protection time by the sender, and used before message 341 unprotection by the recipient. Therefore, in this use case, it is 342 treated as Class U for OSCORE [RFC8613] in requests. In the same 343 application, for responses, it is treated as Class I, and often 344 elided from sending (but reconstructed at the receiver). Other 345 uses of this option can put it into different classes for the 346 OSCORE processing. 348 2.4. Use of Deterministic Requests 350 This section defines how a Deterministic Request is built on the 351 client side and then processed on the server side. 353 2.4.1. Pre-Conditions 355 The use of Deterministic Requests in an OSCORE group requires that 356 the interested group members are aware of the Deterministic Client in 357 the group. In particular, they need to know: 359 * The Sender ID of the Deterministic Client, to be used as 'kid' 360 parameter for the Deterministic Requests. This allows all group 361 members to compute the Sender Key of the Deterministic Client. 363 The Sender ID of the Deterministic Client is immutable throughout 364 the lifetime of the OSCORE group. That is, it is not relinquished 365 and it does not change upon changes of the group keying material 366 following a group rekeying performed by the Group Manager. 368 * The hash algorithm to use for computing the hash of a plain CoAP 369 request, when producing the associated Deterministic Request. 371 Group members have to obtain this information from the Group Manager. 372 A group member can do that, for instance, when obtaining the group 373 keying material upon joining the OSCORE group, or later on as an 374 active member by sending a request to a dedicated resource at the 375 Group Manager. 377 The joining process based on the Group Manager defined in 378 [I-D.ietf-ace-key-groupcomm-oscore] can be easily extended to support 379 the provisioning of information about the Deterministic Client. Such 380 an extension is defined in Section 3 of this document. 382 2.4.2. Client Processing of Deterministic Request 384 In order to build a Deterministic Request, the client protects the 385 plain CoAP request using the pairwise mode of Group OSCORE (see 386 Section 9 of [I-D.ietf-core-oscore-groupcomm]), with the following 387 alterations. 389 1. When preparing the OSCORE option, the external_aad and the AEAD 390 nonce: 392 * The used Sender ID is the Deterministic Client's Sender ID. 394 * The used Partial IV is 0. 396 When preparing the external_aad, the element 'sender_public_key' 397 in the aad_array takes the empty CBOR byte string. 399 2. The client uses the hash function indicated for the Deterministic 400 Client, and computes a hash H over the following input: the 401 Sender Key of the Deterministic Client, concatenated with the 402 external_aad from step 1, concatenated with the COSE plaintext. 404 Note that the payload of the plain CoAP request (if any) is not 405 self-delimiting, and thus hash functions are limited to non- 406 malleable ones. 408 3. The client derives the deterministic Pairwise Sender Key K as 409 defined in Section 2.3.1 of [I-D.ietf-core-oscore-groupcomm], 410 with the following differences: 412 * The Sender Key of the Deterministic Client is used as first 413 argument of the HKDF. 415 * The hash H from step 2 is used as second argument of the HKDF, 416 i.e. as a pseudo IKM-Sender computable by all the group 417 members. 419 Note that an actual IKM-Sender cannot be obtained, since there 420 is no public key associated with the deterministic client, to 421 be used as Sender Public Key and for computing an actual 422 Diffie-Hellman Shared Secret. 424 * The Sender ID of the Deterministic Client is used as value for 425 the 'id' element of the 'info' parameter used as third 426 argument of the HKDF. 428 4. The client includes a Request-Hash option in the request to 429 protect, with value set to the hash H from Step 2. 431 5. The client protects the request using the pairwise mode of Group 432 OSCORE as defined in Section 9.3 of 433 [I-D.ietf-core-oscore-groupcomm], using the AEAD nonce from step 434 1, the deterministic Pairwise Sender Key K from step 3 as AEAD 435 encryption key, and the finalized AAD. 437 6. The client sets FETCH as the outer code of the protected request 438 to make it usable for a proxy's cache, even if no observation is 439 requested [RFC7641]. 441 The result is the Deterministic Request to be sent. 443 Since the encryption key K is derived using material from the whole 444 plain CoAP request, this (key, nonce) pair is only used for this very 445 message, which is deterministically encrypted unless there is a hash 446 collision between two Deterministic Requests. 448 The deterministic encryption requires the used AEAD algorithm to be 449 deterministic in itself. This is the case for all the AEAD 450 algorithms currently registered with COSE in [COSE.Algorithms]. For 451 future algorithms, a flag in the COSE registry is to be added. 453 Note that, while the process defined above is based on the pairwise 454 mode of Group OSCORE, no information about the server takes part to 455 the key derivation or is included in the AAD. This is intentional, 456 since it allows for sending a deterministic request to multiple 457 servers at once (see Section 2.4.5). On the other hand, it requires 458 later checks at the client when verifying a response to a 459 Deterministic Request (see Section 2.4.4). 461 2.4.3. Server Processing of Deterministic Request 463 Upon receiving a Deterministic Request, a server performs the 464 following actions. 466 A server that does not support Deterministic Requests would not be 467 able to create the necessary Recipient Context, and thus will fail 468 decrypting the request. 470 1. If not already available, the server retrieves the information 471 about the Deterministic Client from the Group Manager, and 472 derives the Sender Key of the Deterministic Client. 474 2. The server actually recognizes the request to be a Deterministic 475 Request, due to the presence of the Request-Hash option and to 476 the 'kid' parameter of the OSCORE option set to the Sender ID of 477 the Deterministic Client. 479 If the 'kid' parameter of the OSCORE option specifies a different 480 Sender ID than the one of the Deterministic Client, the server 481 MUST NOT take the following steps, and instead processes the 482 request as per Section 9.4 of [I-D.ietf-core-oscore-groupcomm]. 484 3. The server retrieves the hash H from the Request-Hash option. 486 4. The server derives a Recipient Context for processing the 487 Deterministic Request. In particular: 489 * The Recipient ID is the Sender ID of the Deterministic Client. 491 * The Recipient Key is derived as the key K in step 3 of 492 Section 2.4.2, with the hash H retrieved at the previous step. 494 5. The server verifies the request using the pairwise mode of Group 495 OSCORE, as defined in Section 9.4 of 496 [I-D.ietf-core-oscore-groupcomm], using the Recipient Context 497 from step 4, with the following differences. 499 * The server does not perform replay checks against a Replay 500 Window (see below). 502 In case of successful verification, the server MUST also perform the 503 following actions, before possibly delivering the request to the 504 application. 506 * Starting from the recovered plain CoAP request, the server MUST 507 recompute the same hash that the client computed at step 2 of 508 Section 2.4.2. 510 If the recomputed hash value differs from the value retrieved from 511 the Request-Hash option at step 3, the server MUST treat the 512 request as invalid and MAY reply with an unprotected 4.00 (Bad 513 Request) error response. The server MAY set an Outer Max-Age 514 option with value zero. The diagnostic payload MAY contain the 515 string "Decryption failed". 517 This prevents an attacker that guessed a valid authentication tag 518 for a given Request-Hash value to poison caches with incorrect 519 responses. 521 * The server MUST verify that the unprotected request is safe to be 522 processed in the REST sense, i.e. that it has no side effects. If 523 verification fails, the server MUST discard the message and SHOULD 524 reply with a protected 4.01 (Unauthorized) error response. 526 Note that some CoAP implementations may not be able to prevent 527 that an application produces side effects from a safe request. 528 This may incur checking whether the particular resource handler is 529 explicitly marked as eligible for processing deterministic 530 requests. An implementation may also have a configured list of 531 requests that are known to be side effect free, or even a pre- 532 built list of valid hashes for all sensible requests for them, and 533 reject any other request. 535 These checks replace the otherwise present requirement that the 536 server needs to check the Replay Window of the Recipient Context 537 (see step 5 above), which is inapplicable with the Recipient 538 Context derived at step 4 from the value of the Request-Hash 539 option. The reasoning is analogous to the one in 540 [I-D.amsuess-lwig-oscore] to treat the potential replay as 541 answerable, if the handled request is side effect free. 543 2.4.4. Response to a Deterministic Request 545 When treating a response to a deterministic request, the Request-Hash 546 option is treated as a Class I option. This creates the request- 547 response binding ensuring that no mismatched responses can be 548 successfully unprotected. The option does not actually need to be 549 present in the message as transported (the server SHOULD elide it for 550 compactness). The client MUST replace any Request-Hash values 551 present in the response with the Request-Hash it sent in the request 552 before any OSCORE processing. 554 [ Suggestion for any OSCORE v2: avoid request details in the 555 request's AAD as individual elements. Rather than having 556 'request_kid', 'request_piv' and (in Group OSCORE) 557 'request_kid_context' as separate fields, they can better be 558 something more pluggable. This would avoid the need to make up an 559 option before processing. ] 561 When preparing the response, the server performs the following 562 actions. 564 * The server sets a non-zero Max-Age option, thus making the 565 Deterministic Request usable for the proxy cache. 567 * The server preliminarily sets the Request-Hash option with the 568 full request hash. 570 * The server MUST protect the response using the group mode of Group 571 OSCORE, as defined in Section 8.3 of 572 [I-D.ietf-core-oscore-groupcomm]. This is required to ensure that 573 the client can verify source authentication of the response, since 574 the "pairwise" key used for the Deterministic Request is actually 575 shared among all the group members. 577 Note that the Request-Hash option is treated as Class I here. 579 * The server MUST use its own Sender Sequence Number as Partial IV 580 to protect the response, and include it as Partial IV in the 581 OSCORE option of the response. This is required since the server 582 does not perform replay protection on the Deterministic Request 583 (see Section 2.4.4). 585 * The server uses 2.05 (Content) as outer code even though it is not 586 necessarily an Observe notification [RFC7641], in order to make 587 the response cacheable. 589 * The server SHOULD remove the Request-Hash option from the message 590 before sending. 592 Upon receiving the response, the client performs the following 593 actions. 595 * In case the response includes a 'kid' in the OSCORE option and 596 unless responses from multiple servers are expected (see 597 Section 2.4.5), the client MUST verify it to be exactly the 'kid' 598 of the server to which the Deterministic Request was sent. 600 * The client removes any Request-Hash options from the response, and 601 inserts a Request-Hash option with the full request hash in their 602 place. 604 * The client verifies the response using the group mode of Group 605 OSCORE, as defined in Section 8.4 of 606 [I-D.ietf-core-oscore-groupcomm]. In particular, the client 607 verifies the counter signature in the response, based on the 'kid' 608 of the server it sent the request to. When verifying the 609 response, the Request-Hash option is treated as a Class I option. 611 2.4.5. Deterministic Requests to Multiple Servers 613 A Deterministic Request _can_ be sent to a CoAP group, e.g. over UDP 614 and IP multicast [I-D.ietf-core-groupcomm-bis], thus targeting 615 multiple servers at once. 617 To simplify key derivation, such a Deterministic Request is still 618 created in the same way as a one-to-one request and still protected 619 with the pairwise mode of Group OSCORE, as defined in Section 2.4.2. 621 [ Note: If it was protected with the group mode, the request hash 622 would need to be fed into the group key derivation just for this 623 corner case. Furthermore, there would need to be a signature from 624 the absent public key. ] 626 When a server receives a request from the Deterministic Client as 627 addressed to a CoAP group, the server proceeds as defined in 628 Section 2.4.3, with the difference that it MUST include its own 629 Sender ID in the response, as 'kid' parameter of the OSCORE option. 631 Although it is normally optional for the server to include its Sender 632 ID when replying to a request protected in pairwise mode, it is 633 required in this case for allowing the client to retrieve the 634 Recipient Context associated to the server originating the response. 636 3. Obtaining Information about the Deterministic Client 638 This section extends the Joining Process defined in 639 [I-D.ietf-ace-key-groupcomm-oscore], and based on the ACE framework 640 for Authentication and Authorization [I-D.ietf-ace-oauth-authz]. 641 Upon joining the OSCORE group, this enables a new group member to 642 obtain from the Group Manager the required information about the 643 Deterministic Client (see Section 2.4.1). 645 With reference to the 'key' parameter of the Joining Response defined 646 in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], the 647 Group_OSCORE_Input_Material object specified as its value contains 648 also the two additional parameters 'det_senderId' and 'det_hash_alg'. 649 These are defined in Section 5.2 of this document. In particular: 651 * The 'det_senderId' parameter, if present, has as value the OSCORE 652 Sender ID assigned to the Deterministic Client by the Group 653 Manager. This parameter MUST be present if the OSCORE group uses 654 deterministic requests as defined in this document. Otherwise, 655 this parameter MUST NOT be present. 657 * The 'det_hash_alg' parameter, if present, has as value the hash 658 algorithm to use for computing the hash of a plain CoAP request, 659 when producing the associated Deterministic Request. This 660 parameter takes values from the "Value" column of the "COSE 661 Algorithms" Registry [COSE.Algorithms]. This parameter MUST be 662 present if the OSCORE group uses deterministic requests as defined 663 in this document. Otherwise, this parameter MUST NOT be present. 665 The same extension above applies also to the 'key' parameter when 666 included in a Key Distribution Response (see Sections 8.1 and 8.2 of 667 [I-D.ietf-ace-key-groupcomm-oscore]) and in a Signature Verification 668 Data Response (see Section 13 of 669 [I-D.ietf-ace-key-groupcomm-oscore]). 671 4. Security Considerations 673 The same security considerations from [RFC7252][I-D.ietf-core-groupco 674 mm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this 675 document. 677 Compared to Group OSCORE, deterministic requests dispense with some 678 of OSCORE's security properties by just so much as to make caching 679 possible: 681 * Receiving a response to a deterministic request does not mean that 682 the response was generated after the request was sent. 684 It still contains two freshness statements, though: 686 - It is more recent than any other response from the same group 687 member that has a smaller sequence number. 689 - It is more recent than the original creation of the 690 deterministic security context. 692 * Request confidentiality is limited. 694 An intermediary can determine that two requests from different 695 clients are identical, and associate the different responses 696 generated for them. Padding is suggested for responses where 697 necessary. 699 * Source authentication for requests is lost. 701 Instead, the server must verify that the request (precisely: its 702 handler) is side effect free. The distinct semantics of the CoAP 703 request codes can help the server make that assessment. 705 [ More on the verification of the Deterministic Request ] 707 5. IANA Considerations 709 This document has the following actions for IANA. 711 5.1. CoAP Option Numbers Registry 713 IANA is asked to enter the following option numbers to the "CoAP 714 Option Numbers" registry defined in [RFC7252] within the "CoRE 715 Parameters" registry. 717 +--------+--------------+-------------------+ 718 | Number | Name | Reference | 719 +--------+--------------+-------------------+ 720 | TBD1 | Request-Hash | [[this document]] | 721 +--------+--------------+-------------------+ 722 | TBD2 | Padding | [[this document]] | 723 +--------+--------------+-------------------+ 725 Figure 2: CoAP Option Numbers 727 [ 729 For the Request-Hash option, the number suggested to IANA is 548. 731 For the Padding option, the option number is picked to be the highest 732 number in the Experts Review range; the high option number allows it 733 to follow practically all other options, and thus to be set when the 734 final unpadded message length including all options is known. 735 Therefore, the number suggested to IANA is 64988. 737 Applications that make use of the "Experimental use" range and want 738 to preserve that property are invited to pick the largest suitable 739 experimental number (65532) 741 Note that unless other high options are used, this means that padding 742 a message adds an overhead of at least 3 bytes, i.e. 1 byte for 743 option delta/length and two more bytes of extended option delta. 744 This is considered acceptable overhead, given that the application 745 has already chosen to prefer the privacy gains of padding over wire 746 transfer length. 748 ] 750 5.2. OSCORE Security Context Parameters Registry 752 IANA is asked to register the following entries in the "OSCORE 753 Security Context Parameters" Registry defined in Section 9.4 of 754 [I-D.ietf-ace-oscore-profile]. 756 * Name: det_senderId 758 * CBOR Label: TBD3 760 * CBOR Type: bstr 762 * Registry: - 764 * Description: OSCORE Sender ID assigned to the Deterministic Client 765 of an OSCORE group 767 * Reference: [[this document]] (Section 3) 769 * Name: det_hash_alg 771 * CBOR Label: TBD4 773 * CBOR Type: int / tstr 775 * Registry: - 777 * Description: Hash algorithm to use in an OSCORE group when 778 producing a Deterministic Request 780 * Reference: [[this document]] (Section 3) 782 6. References 784 6.1. Normative References 786 [I-D.ietf-core-groupcomm-bis] 787 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 788 for the Constrained Application Protocol (CoAP)", Work in 789 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 790 04, 12 July 2021, . 793 [I-D.ietf-core-oscore-groupcomm] 794 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 795 and J. Park, "Group OSCORE - Secure Group Communication 796 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 797 core-oscore-groupcomm-12, 12 July 2021, 798 . 801 [I-D.ietf-cose-rfc8152bis-struct] 802 Schaad, J., "CBOR Object Signing and Encryption (COSE): 803 Structures and Process", Work in Progress, Internet-Draft, 804 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 805 . 808 [I-D.ietf-cose-rfc8152bis-algs] 809 Schaad, J., "CBOR Object Signing and Encryption (COSE): 810 Initial Algorithms", Work in Progress, Internet-Draft, 811 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 812 . 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, 817 DOI 10.17487/RFC2119, March 1997, 818 . 820 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 821 Application Protocol (CoAP)", RFC 7252, 822 DOI 10.17487/RFC7252, June 2014, 823 . 825 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 826 FETCH Methods for the Constrained Application Protocol 827 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 828 . 830 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 831 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 832 May 2017, . 834 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 835 "Object Security for Constrained RESTful Environments 836 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 837 . 839 [COSE.Algorithms] 840 IANA, "COSE Algorithms", 841 . 844 6.2. Informative References 846 [RFC7641] Hartke, K., "Observing Resources in the Constrained 847 Application Protocol (CoAP)", RFC 7641, 848 DOI 10.17487/RFC7641, September 2015, 849 . 851 [I-D.ietf-core-echo-request-tag] 852 Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, 853 Request-Tag, and Token Processing", Work in Progress, 854 Internet-Draft, draft-ietf-core-echo-request-tag-13, 12 855 July 2021, . 858 [I-D.ietf-ace-key-groupcomm-oscore] 859 Tiloca, M., Park, J., and F. Palombini, "Key Management 860 for OSCORE Groups in ACE", Work in Progress, Internet- 861 Draft, draft-ietf-ace-key-groupcomm-oscore-11, 12 July 862 2021, . 865 [I-D.amsuess-lwig-oscore] 866 Amsüss, C., "OSCORE Implementation Guidance", Work in 867 Progress, Internet-Draft, draft-amsuess-lwig-oscore-00, 29 868 April 2020, . 871 [I-D.ietf-core-observe-multicast-notifications] 872 Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini, 873 "Observe Notifications as CoAP Multicast Responses", Work 874 in Progress, Internet-Draft, draft-ietf-core-observe- 875 multicast-notifications-01, 12 July 2021, 876 . 879 [I-D.ietf-ace-oauth-authz] 880 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 881 H. Tschofenig, "Authentication and Authorization for 882 Constrained Environments (ACE) using the OAuth 2.0 883 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 884 draft-ietf-ace-oauth-authz-43, 10 July 2021, 885 . 888 [I-D.ietf-ace-oscore-profile] 889 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 890 "OSCORE Profile of the Authentication and Authorization 891 for Constrained Environments Framework", Work in Progress, 892 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 893 2021, . 896 [SW-EPIV] Lucas, G., "Star Wars", Lucasfilm Ltd. , 1977. 898 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 899 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 900 Application Protocol) over TCP, TLS, and WebSockets", 901 RFC 8323, DOI 10.17487/RFC8323, February 2018, 902 . 904 Appendix A. Change log 906 Since -01: 908 * Not meddling with request_kid any more. 910 Instead, Request-Hash in responses is treated as Class I, but 911 typically elided. 913 In requests, this removes the need to compute the external_aad 914 twice. 916 * Derivation of the hash now uses the external_aad, rather than the 917 full AAD. This is good enough because AAD is a function only of 918 the external_aad, and the external_aad is easier to get your hands 919 on if COSE manages all the rest. 921 * The Sender ID of the Deterministic Client is immutable throughout 922 the group lifetime. Hence, no need for any related expiration/ 923 creation time and mechanisms to perform its update in the group. 925 * Extension to the ACE Group Manager of ace-key-groupcomm-oscore to 926 provide required info about the Deterministic Client to new group 927 members when joining the group. 929 * Alignment with changes in core-oscore-groupcomm-12. 931 * Editorial improvements. 933 Since -00: 935 * More precise specification of the hashing (guided by first 936 implementations) 938 * Focus shifted to deterministic requests (where it should have been 939 in the first place; all the build-up of Token Requests was moved 940 to a motivating appendix) 942 * Aligned with draft-tiloca-core-observe-responses-multicast-05 (not 943 submitted at the time of submission) 945 * List the security properties lost compared to OSCORE 947 Appendix B. Padding 949 As discussed in Section 4, information can be leaked by the length of 950 a response or, in different contexts, of a request. 952 In order to hide such information and mitigate the impact on privacy, 953 the following Padding option is defined, to allow increasing a 954 message's length without changing its meaning. 956 The option can be used with any CoAP transport, but is especially 957 useful with OSCORE as that does not provide any padding of its own. 959 Before choosing to pad a message by using the Padding option, 960 application designers should consider whether they can arrange for 961 common message variants to have the same length by picking a suitable 962 content representation; the canonical example here is expressing 963 "yes" and "no" with "y" and "n", respectively. 965 B.1. Definition of the Padding Option 967 As summarized in Figure 3, the Padding option is elective, safe to 968 forward and not part of the cache key; these follow from the usage 969 instructions. The option may be repeated, as that may be the only 970 way to achieve a certain total length for the padded message. 972 +------+---+---+---+---+---------+--------+--------+---------+ 973 | No. | C | U | N | R | Name | Format | Length | Default | 974 +------+---+---+---+---+---------+--------+--------+---------+ 975 | TBD2 | | | x | x | Padding | opaque | any | (none) | 976 +------+---+---+---+---+---------+--------+--------+---------+ 978 Figure 3: Padding Option 980 B.2. Using and processing the Padding option 982 A client may set the Padding option, specifying any content of any 983 length as its value. 985 A server MUST ignore the option. 987 Proxies are free to keep the Padding option on a message, to remove 988 it or to add further padding of their own. 990 Appendix C. Simple Cacheability using Ticket Requests 992 Building on the concept of Phantom Requests and Informative Responses 993 defined in [I-D.ietf-core-observe-multicast-notifications], basic 994 caching is already possible without building a Deterministic Request. 996 The approach discussed in this appendix is not provided for 997 application. In fact, it is efficient only when dealing with very 998 large representations and no OSCORE inner Block-Wise mode (which is 999 inefficient for other reasons), or when dealing with observe 1000 notifications (which are already well covered in 1001 [I-D.ietf-core-observe-multicast-notifications]). 1003 Rather, it is more provided as a "mental exercise" for the authors 1004 and interested readers to bridge the gap between this document and 1005 [I-D.ietf-core-observe-multicast-notifications]. 1007 That is, instead of replying to a client with a regular response, a 1008 server can send an Informative Response, defined as a protected 5.03 1009 (Service Unavailable) error message. The payload of the Informative 1010 Response contains the Phantom Request, which is a Ticket Request in 1011 this document's broader terminology. 1013 Unlike a Deterministic Request, a Phantom Request is protected in 1014 Group Mode. Instead of verifying a hash, the client can see from the 1015 signature that this was indeed the request the server is answering. 1016 The client also verifies that the request URI is identical between 1017 the original request and the Ticket Request. 1019 The remaining exchange largely plays out like in 1020 [I-D.ietf-core-observe-multicast-notifications]'s "Example with a 1021 Proxy and Group OSCORE": The client sends the Phantom Request to the 1022 proxy (but, lacking a "tp_info", without a Listen-To-Multicast- 1023 Responses option), which forwards it to the server for lack of the 1024 option. 1026 The server then produces a regular response and includes a non-zero 1027 Max-Age option as an outer CoAP option. Note that there is no point 1028 in including an inner Max-Age option, as the client could not pin it 1029 in time. 1031 When a second, different client later asks for the same resource at 1032 the same server, its new request uses a different 'kid' and 'Partial 1033 IV' than the first client's. Thus, the new request produces a cache 1034 miss at the proxy and is forwarded to the server, which responds with 1035 the same Ticket Request provided to the first client. After that, 1036 when the second client sends the Ticket Request, a cache hit at the 1037 proxy will be produced, and the Ticket Request can be served from the 1038 proxy's cache. 1040 When multiple proxies are in use, or the response has expired from 1041 the proxy's cache, the server receives the Ticket Request multiple 1042 times. It is a matter of perspective whether the server treats that 1043 as an acceptable replay (given that this whole mechansim only makes 1044 sense on requests free of side effects), or whether it is 1045 conceptualized as having an internal proxy where the request produces 1046 a cache hit. 1048 Appendix D. Application for More Efficient End-to-End Protected 1049 Multicast Notifications 1051 [I-D.ietf-core-observe-multicast-notifications] defines how a CoAP 1052 server can serve all clients observing a same resource at once, by 1053 sending notifications over multicast. The approach supports the 1054 possible presence of intermediaries such as proxies, also if Group 1055 OSCORE is used to protect notifications end-to-end. 1057 However, comparing the "Example with a Proxy" in Appendix A of 1058 [I-D.ietf-core-observe-multicast-notifications] and the "Example with 1059 a Proxy and Group OSCORE" in Appendix B of 1060 [I-D.ietf-core-observe-multicast-notifications] shows that, when 1061 using Group OSCORE, more requests need to hit the server. This is 1062 because every client originally protects its Observation request 1063 individually, and thus needs a custom response served to obtain the 1064 Phantom Request as a Ticket Request. 1066 If the clients send their requests as the same deterministic request, 1067 the server can use these requests as Ticket Requests as well. Thus, 1068 there is no need for the server to provide a same Phantom Request to 1069 each client. 1071 Instead, the server can send a single unprotected Informative 1072 Response - very much like in the example without Group OSCORE - hence 1073 setting the proxy up and optionally providing also the latest 1074 notification along the way. 1076 The proxy can thus be configured by the server following the first 1077 request from the clients, after which it has an active observation 1078 and a fresh cache entry in time for the second client to arrive. 1080 Appendix E. Open questions 1082 * Is "deterministic encryption" something worthwhile to consider in 1083 COSE? 1085 COSE would probably specify something more elaborate for the KDF 1086 (the current KDF round is the pairwise mode's; COSE would probably 1087 run through KDF with a KDF context structure). 1089 COSE would give a header parameter name to the Request-Hash (which 1090 for the purpose of OSCORE deterministic requests would put back 1091 into Request-Hash by extending the option compression function 1092 across the two options). 1094 Conceptually, they should align well, and the implementation 1095 changes are likely limited to how the KDF is run. 1097 * An unprotection failure from a mismatched hash will not be part of 1098 the ideally constant-time code paths that otherwise lead to AEAD 1099 unprotect failures. Is that a problem? 1101 After all, it does tell the attacker that they did succeed in 1102 producing a valid MAC (it's just not doing it any good, because 1103 this key is only used for deterministic requests and thus also 1104 needs to pass the Request-Hash check). 1106 Appendix F. Unsorted further ideas 1108 * All or none of the deterministic requests should have an inner 1109 observe option. Preferably none -- that makes messages shorter, 1110 and clients need to ignore that option either way when checking 1111 whether a Consensus Request matches their intended request. 1113 Acknowledgments 1115 The authors sincerely thank Michael Richardson, Jim Schaad and Goeran 1116 Selander for their comments and feedback. 1118 The work on this document has been partly supported by VINNOVA and 1119 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1120 (Grant agreement 952652). 1122 Authors' Addresses 1124 Christian Amsüss 1125 Austria 1127 Email: christian@amsuess.com 1129 Marco Tiloca 1130 RISE AB 1131 Isafjordsgatan 22 1132 SE-16440 Stockholm Kista 1133 Sweden 1135 Email: marco.tiloca@ri.se