idnits 2.17.1 draft-tiloca-core-oscore-capable-proxies-02.txt: -(3): 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 (7 March 2022) is 752 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 (-21) exists of draft-ietf-core-oscore-groupcomm-14 == Outdated reference: A later version (-08) exists of draft-amsuess-core-cachable-oscore-04 == Outdated reference: A later version (-13) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-06 == Outdated reference: A later version (-08) exists of draft-ietf-core-observe-multicast-notifications-03 == Outdated reference: A later version (-10) exists of draft-ietf-core-oscore-edhoc-03 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-12 == Outdated reference: A later version (-09) exists of draft-tiloca-core-groupcomm-proxy-06 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft R. Höglund 4 Updates: 8613 (if approved) RISE AB 5 Intended status: Standards Track 7 March 2022 6 Expires: 8 September 2022 8 OSCORE-capable Proxies 9 draft-tiloca-core-oscore-capable-proxies-02 11 Abstract 13 Object Security for Constrained RESTful Environments (OSCORE) can be 14 used to protect CoAP messages end-to-end between two endpoints at the 15 application layer, also in the presence of intermediaries such as 16 proxies. This document defines how to use OSCORE for protecting CoAP 17 messages also between an origin application endpoint and an 18 intermediary, or between two intermediaries. Also, it defines how to 19 secure a CoAP message by applying multiple, nested OSCORE 20 protections, e.g., both end-to-end between origin application 21 endpoints, as well as between an application endpoint and an 22 intermediary or between two intermediaries. Thus, this document 23 updates RFC 8613. The same approach can be seamlessly used with 24 Group OSCORE, for protecting CoAP messages when group communication 25 with intermediaries is used. 27 Discussion Venues 29 This note is to be removed before publishing as an RFC. 31 Discussion of this document takes place on the Constrained RESTful 32 Environments Working Group mailing list (core@ietf.org), which is 33 archived at https://mailarchive.ietf.org/arch/browse/core/. 35 Source for this draft and an issue tracker can be found at 36 https://gitlab.com/crimson84/draft-tiloca-core-oscore-to-proxies. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 8 September 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. CoAP Group Communication with Proxies . . . . . . . . . . 5 75 2.2. CoAP Observe Notifications over Multicast . . . . . . . . 6 76 2.3. LwM2M Client and External Application Server . . . . . . 6 77 2.4. Further Use Cases . . . . . . . . . . . . . . . . . . . . 7 78 3. Message Processing . . . . . . . . . . . . . . . . . . . . . 8 79 3.1. General Rules on Protecting Options . . . . . . . . . . . 8 80 3.2. Processing an Outgoing Request . . . . . . . . . . . . . 9 81 3.3. Processing an Incoming Request . . . . . . . . . . . . . 10 82 3.4. Processing an Outgoing Response . . . . . . . . . . . . . 11 83 3.5. Processing an Incoming Response . . . . . . . . . . . . . 11 84 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 5. Caching of OSCORE-Protected Responses . . . . . . . . . . . . 11 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 8.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Appendix A. OSCORE-protected Onion Forwarding . . . . . . . . . 15 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 The Constrained Application Protocol (CoAP) [RFC7252] supports the 98 presence of intermediaries, such as forward-proxies and reverse- 99 proxies, which assist origin clients by performing requests to origin 100 servers on their behalf, and forwarding back the related responses. 102 CoAP supports also group communication scenarios 103 [I-D.ietf-core-groupcomm-bis], where clients can send a one-to-many 104 request targeting all the servers in the group, e.g., by using IP 105 multicast. Like for one-to-one communication, group settings can 106 also rely on intermediaries [I-D.tiloca-core-groupcomm-proxy]. 108 The protocol Object Security for Constrained RESTful Environments 109 (OSCORE) [RFC8613] can be used to protect CoAP messages between two 110 endpoints at the application layer, especially achieving end-to-end 111 security in the presence of (non-trusted) intermediaries. When CoAP 112 group communication is used, the same can be achieved by means of the 113 protocol Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 115 For a number of use cases (see Section 2), it is required and/or 116 beneficial that communications are secured also between an 117 application endpoint (i.e., a CoAP origin client/server) and an 118 intermediary, as well as between two adjacent intermediaries in a 119 chain. This especially applies to the communication leg between the 120 CoAP origin client and the adjacent intermediary acting as next hop 121 towards the CoAP origin server. 123 In such cases, and especially if the origin client already uses 124 OSCORE to achieve end-to-end security with the origin server, it 125 would be convenient that OSCORE is used also to secure communications 126 between the origin client and its next hop. However, the original 127 specification [RFC8613] does not define how OSCORE can be used to 128 protect CoAP messages in such communication leg, which would require 129 to consider also the intermediary as an "OSCORE endpoint". 131 This document fills this gap, and updates [RFC8613] as follows. 133 * It defines how to use OSCORE for protecting a CoAP message in the 134 communication leg between: i) an origin client/server and an 135 intermediary; or ii) two adjacent intermediaries in an 136 intermediary chain. That is, besides origin clients/servers, it 137 allows also intermediaries to be possible "OSCORE endpoints". 139 * It admits a CoAP message to be secured by multiple, nested OSCORE 140 protections applied in sequence, as an "OSCORE-in-OSCORE" process. 141 For instance, this is the case when the message is OSCORE- 142 protected end-to-end between the origin client and origin server, 143 and the result is further OSCORE-protected over the leg between 144 the current and next hop (e.g., the origin client and the adjacent 145 intermediary acting as next hop towards the origin server). 147 This document does not specify any new signaling method to guide the 148 message processing on the different endpoints. In particular, every 149 endpoint is always able to understand what steps to take on an 150 incoming message depending on the presence of the OSCORE Option, as 151 exclusively included or instead combined together with CoAP options 152 intended for an intermediary. 154 The approach defined in this document can be seamlessly adopted also 155 when Group OSCORE is used, for protecting CoAP messages in group 156 communication scenarios that rely on intermediaries. 158 1.1. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 Readers are expected to be familiar with the terms and concepts 167 related to CoAP [RFC7252]; OSCORE [RFC8613] and Group OSCORE 168 [I-D.ietf-core-oscore-groupcomm]. This document especially builds on 169 concepts and mechanics related to intermediaries such as CoAP 170 forward-proxies. 172 In addition, this document uses the following terms. 174 * Source application endpoint: an origin client producing a request, 175 or an origin server producing a response. 177 * Destination application endpoint: an origin server intended to 178 consume a request, or an origin client intended to consume a 179 response. 181 * Application endpoint: a source or destination application 182 endpoint. 184 * Source OSCORE endpoint: an endpoint protecting a message with 185 OSCORE or Group OSCORE. 187 * Destination OSCORE endpoint: an endpoint unprotecting a message 188 with OSCORE or Group OSCORE. 190 * OSCORE endpoint: a source/destination OSCORE endpoint. An OSCORE 191 endpoint is not necessarily also an application endpoint with 192 respect to a certain message. 194 * Proxy-related option: the Proxy-URI Option, the Proxy-Scheme 195 Option, or any of the Uri-* Options. 197 * OSCORE-in-OSCORE: the process by which a message protected with 198 (Group) OSCORE is further protected with (Group) OSCORE. This 199 means that, if such a process is used, a successful decryption/ 200 verification of an OSCORE-protected message might yield an OSCORE- 201 protected message. 203 2. Use Cases 205 The approach proposed in this document has been motivated by a number 206 of use cases, which are summarized below. 208 2.1. CoAP Group Communication with Proxies 210 CoAP supports also one-to-many group communication, e.g., over IP 211 multicast [I-D.ietf-core-groupcomm-bis], which can be protected end- 212 to-end between origin client and origin servers by using Group OSCORE 213 [I-D.ietf-core-oscore-groupcomm]. 215 This communication model can be assisted by intermediaries such as a 216 CoAP forward-proxy or reverse-proxy, which relays a group request to 217 the origin servers. If Group OSCORE is used, the proxy is 218 intentionally not a member of the OSCORE group. Furthermore, 219 [I-D.tiloca-core-groupcomm-proxy] defines a signaling protocol 220 between origin client and proxy, to ensure that responses from the 221 different origin servers are forwarded back to the origin client 222 within a time interval set by the client, and that they can be 223 distinguished from one another. 225 In particular, it is required that the proxy identifies the origin 226 client as allowed-listed, before forwarding a group request to the 227 servers (see Section 4 of [I-D.tiloca-core-groupcomm-proxy]). This 228 requires a security association between the origin client and the 229 proxy, which would be convenient to provide with a dedicated OSCORE 230 Security Context between the two, since the client is possibly using 231 also Group OSCORE with the origin servers. 233 2.2. CoAP Observe Notifications over Multicast 235 The Observe extension for CoAP [RFC7641] allows a client to register 236 its interest in "observing" a resource at a server. The server can 237 then send back notification responses upon changes to the resource 238 representation, all matching with the original observation request. 240 In some applications, such as pub-sub [I-D.ietf-core-coap-pubsub], 241 multiple clients are interested to observe the same resource at the 242 same server. Hence, [I-D.ietf-core-observe-multicast-notifications] 243 defines a method that allows the server to send a multicast 244 notification to all the observer clients at once, e.g., over IP 245 multicast. To this end, the server synchronizes the clients by 246 providing them with a common "phantom observation request", against 247 which the following multicast notifications will match. 249 In case the clients and the server use Group OSCORE for end-to-end 250 security and a proxy is also involved, an additional step is required 251 (see Section 10 of [I-D.ietf-core-observe-multicast-notifications]). 252 That is, clients are in turn required to provide the proxy with the 253 obtained "phantom observation request", thus enabling the proxy to 254 receive the multicast notifications from the server. 256 Therefore, it is preferable to have a security associations also 257 between each client and the proxy, to especially ensure the integrity 258 of that information provided to the proxy (see Section 13.3 of 259 [I-D.ietf-core-observe-multicast-notifications]). Like for the use 260 case in Section 2.1, this would be conveniently achieved with a 261 dedicated OSCORE Security Context between a client and the proxy, 262 since the client is also using Group OSCORE with the origin server. 264 2.3. LwM2M Client and External Application Server 266 The Lightweight Machine-to-Machine (LwM2M) protocol [LwM2M-Core] 267 enables a LwM2M Client device to securely bootstrap and then register 268 at a LwM2M Server, with which it will perform most of its following 269 communication exchanges. As per the transport bindings specification 270 of LwM2M [LwM2M-Transport], the LwM2M Client and LwM2M Server can use 271 CoAP and OSCORE to secure their communications at the application 272 layer, including during the device registration process. 274 Furthermore, Section 5.5.1 of [LwM2M-Transport] specifies that: 275 "OSCORE MAY also be used between LwM2M endpoint and non-LwM2M 276 endpoint, e.g., between an Application Server and a LwM2M Client via 277 a LwM2M server. Both the LwM2M endpoint and non-LwM2M endpoint MUST 278 implement OSCORE and be provisioned with an OSCORE Security Context." 279 In such a case, the LwM2M Server can practically act as forward-proxy 280 between the LwM2M Client and the external Application Server. At the 281 same time, the LwM2M Client and LwM2M Server must continue protecting 282 communications on their leg using their Security Context. Like for 283 the use case in Section 2.1, this also allows the LwM2M Server to 284 identify the LwM2M Client, before forwarding its request outside the 285 LwM2M domain and towards the external Application Server. 287 2.4. Further Use Cases 289 The approach proposed in this document can be useful also in the 290 following use cases relying on a proxy. 292 * A server aware of a suitable cross proxy can rely on it as a 293 third-party service, in order to indicate transports for CoAP 294 available to that server (see see Section 4 of 295 [I-D.amsuess-core-transport-indication]). 297 From a security point of view, it would be convenient if the proxy 298 could provide suitable credentials to the client, as a general 299 trusted proxy for the system. However, in order for OSCORE to be 300 an applicable security mechanism for this, it has to be terminated 301 at the proxy. That is, it would be required for the client and 302 the proxy to share a dedicated OSCORE Security Context and to use 303 it for protecting their communication leg. 305 * A proxy may be deployed to act as an entry point to a firewalled 306 network, which only authenticated clients can join. In 307 particular, authentication can rely on the used secure 308 communication association between a client and the proxy. If the 309 proxy could share a dedicated OSCORE Security Context with each 310 client, the proxy can rely on it to identify the client, before 311 forwarding its messages to any other member of the firewalled 312 network. 314 * The approach proposed in this document does not pose a limit to 315 the number of OSCORE protections applied to the same CoAP message. 316 This enables more privacy-oriented scenarios based on proxy 317 chains, where the origin endpoint protects a message using first 318 the OSCORE Security Context shared with the origin server, and 319 then the dedicated OSCORE Security Context shared with each of the 320 different chain hops. Once received at a chain hop, a message 321 would be stripped of the OSCORE protection associated with that 322 hop before being forwarded to the next one. 324 3. Message Processing 326 As mentioned in Section 1, this document introduces the following two 327 main deviations from the original OSCORE specification [RFC8613]. 329 1. An "OSCORE endpoint", i.e., a producer/consumer of an OSCORE 330 Option can be not only an application endpoint (i.e., an origin 331 client or server), but also an intermediary such as a proxy. 333 Hence, OSCORE can also be used between an origin client/server 334 and a proxy, as well as between two proxies in an intermediary 335 chain. 337 2. A CoAP message can be secured by multiple OSCORE protections 338 applied in sequence. Therefore, the final result is a message 339 with nested OSCORE protections, as the output of an "OSCORE-in- 340 OSCORE" process. Hence, following a decryption, the resulting 341 message might legitimately include an OSCORE Option, and thus 342 have in turn to be decrypted. 344 The most common case is expected to consider a message protected 345 with up to two OSCORE layers, i.e.: i) an inner layer, protecting 346 the message end-to-end between the origin client and the origin 347 server acting as application endpoints; and ii) an outer layer, 348 protecting the message between a certain OSCORE endpoint and the 349 other OSCORE endpoint adjacent in the intermediary chain. 351 However, a message can also be protected with a higher arbitrary 352 number of nested OSCORE layers, e.g., in scenarios relying on a 353 longer chain of intermediaries. For instance, the origin client 354 can sequentially apply multiple OSCORE layers to a request, each 355 of which to be consumed and removed by one of the intermediaries 356 in the chain, until the origin server is reached and it consumes 357 the innermost OSCORE layer. 359 3.1. General Rules on Protecting Options 361 When a sender endpoint protects an outgoing message by applying the 362 i-th OSCORE layer in sequence, the following CoAP options are also 363 protected, in addition to those already specified as class I or class 364 E in the document defining them. 366 * An OSCORE Option which is present as the result of the j-th OSCORE 367 layer immediately previously applied, i.e., j = (i-1). Such an 368 OSCORE Option is protected like an option of class E. 370 * Any option such that both the following conditions hold. 372 1. The option is intended to be consumed by the other OSCORE 373 endpoint X sharing the OSCORE Security Context used for 374 applying the i-th OSCORE layer. 376 2. The option does not play a role at the other OSCORE endpoint X 377 for correctly processing the message before having removed the 378 i-th OSCORE layer. 380 Examples of such options are: 382 - The proxy-related options Proxy-Uri, Proxy-Scheme and Uri-* 383 defined in [RFC7252]. 385 - Listen-To-Multicast-Notifications defined in 386 [I-D.ietf-core-observe-multicast-notifications]. 388 - Multicast-Timeout, Response-Forwarding and Group-ETag defined 389 in [I-D.tiloca-core-groupcomm-proxy]. 391 One the other hand, when applying the i-th OSCORE layer, an option 392 intended to the endpoint X is not protected if it plays a role for 393 removing the i-th OSCORE layer at that endpoint. Examples of such 394 options are: 396 * Clearly, and consistently with [RFC8613], the OSCORE option added 397 to the outgoing message as a result of applying the i-th OSCORE 398 layer. 400 * The EDHOC option defined in [I-D.ietf-core-oscore-edhoc], to 401 signal to the endpoint X that part of the message payload has to 402 be extracted and used to complete an ongoing execution of the 403 EDHOC key establishment protocol [I-D.ietf-lake-edhoc], before the 404 i-th OSCORE layer can be removed. 406 3.2. Processing an Outgoing Request 408 The rules from Section 3.1 apply when processing an outgoing request 409 message, with the following addition. 411 When an application endpoint applies multiple OSCORE layers in 412 sequence to protect an outgoing request, and it uses an OSCORE 413 Security Context shared with the other application endpoint, then the 414 first OSCORE layer MUST be applied by using that Security Context. 416 3.3. Processing an Incoming Request 418 The recipient endpoint performs the following actions on the received 419 request REQ, depending on which of the following three conditions 420 apply. 422 * A - REQ includes visible proxy-related options. 424 If the endpoint is not configured to be a proxy, it MUST stop 425 processing the request and MUST respond with a 5.05 (Proxying Not 426 Supported) error response to (the previous hop towards) the origin 427 client, as per Section 5.10.2 of [RFC7252]. This may result in 428 protecting the error response over that communication leg, as per 429 Section 3.4. 431 Otherwise, the endpoint consumes the proxy-related options and 432 forwards REQ to (the next hop towards) the origin server. This 433 may result in (further) protecting REQ over that communication 434 leg, as per Section 3.2. 436 * B - REQ does not include proxy-related options and does not 437 include an OSCORE Option. 439 If the endpoint does not have an application to handle REQ, it 440 MUST stop processing the request and MAY respond with a 4.00 (Bad 441 Request) error response to (the previous hop towards) the origin 442 client. This may result in protecting the error response over 443 that communication leg, as per Section 3.4. 445 Otherwise, the endpoint delivers REQ to the application. 447 * C - REQ does not include proxy-related options and includes an 448 OSCORE Option. 450 The endpoint decrypts REQ using the OSCORE Security Context 451 indicated by the OSCORE Option, i.e., REQ* = dec(REQ). After 452 that, the possible presence of an OSCORE Option in the decrypted 453 request REQ* is not treated as an error situation. 455 If the OSCORE processing results in an error, the endpoint MUST 456 stop processing the request and performs error handling as per 457 Section 8.2 of [RFC8613] or Sections 8.2 and 9.4 of 458 [I-D.ietf-core-oscore-groupcomm], in case OSCORE or Group OSCORE 459 is used, respectively. In case the endpoint sends an error 460 response to (the previous hop towards) the origin client, this may 461 result in protecting the error response over that communication 462 leg, as per Section 3.4. 464 Otherwise, REQ takes REQ*, and the endpoint evaluates which of the 465 three conditions (A, B, C) applies to REQ, thus performing again 466 the algorithm defined in this section. 468 3.4. Processing an Outgoing Response 470 The rules from Section 3.1 apply when processing an outgoing response 471 message, with the following additions. 473 When an application endpoint applies multiple OSCORE layers in 474 sequence to protect an outgoing response, and it uses an OSCORE 475 Security Context shared with the other application endpoint, then the 476 first OSCORE layer MUST be applied by using that Security Context. 478 The sender endpoint protects the response by applying the same OSCORE 479 layers that it removed from the corresponding incoming request, but 480 in the reverse order than the one they were removed. 482 In case the response is an error response, the sender endpoint 483 protects it by applying the same OSCORE layers that it successfully 484 removed from the corresponding incoming request, but in the reverse 485 order than the one they were removed. 487 3.5. Processing an Incoming Response 489 The recipient endpoint removes the same OSCORE layers that it added 490 when protecting the corresponding outgoing request, but in the 491 reverse order than the one they were removed. 493 When doing so, the possible presence of an OSCORE Option in the 494 decrypted response following the removal of an OSCORE layer is not 495 treated as an error situation, unless it occurs after having removed 496 as many OSCORE layers as were added in the outgoing request. In such 497 a case, the endpoint MUST stop processing the response. 499 4. Example 501 TODO: add example with message exchange. 503 5. Caching of OSCORE-Protected Responses 505 Although not possible as per the original OSCORE specification 506 [RFC8613], cacheability of OSCORE-protected responses at proxies can 507 be achieved. To this end, the approach defined in 508 [I-D.amsuess-core-cachable-oscore] can be used, as based on 509 Deterministic Requests protected with the pairwise mode of Group 510 OSCORE [I-D.ietf-core-oscore-groupcomm] used end-to-end between an 511 origin client and an origin server. The applicability of this 512 approach is limited to requests that are safe (in the RESTful sense) 513 to process and do not yield side effects at the origin server. 515 In particular, both the origin client and the origin server are 516 required to have already joined the correct OSCORE group. Then, 517 starting from the same plain CoAP request, different clients in the 518 OSCORE group are able to deterministically generate a same request 519 protected with Group OSCORE, which is sent to a proxy for being 520 forwarded to the origin server. The proxy can now effectively cache 521 the resulting OSCORE-protected response from the server, since the 522 same plain CoAP request will result again in the same Deterministic 523 Request and thus will produce a cache hit. 525 If the approach defined in [I-D.amsuess-core-cachable-oscore] is 526 used, the following also applies in addition to what is defined in 527 Section 3, when processing incoming messages at a proxy that 528 implements caching of responses. 530 * Upon receiving a request from (the previous hop towards) the 531 origin client, the proxy checks if specifically the message 532 available during the execution of alternative A in Section 3.3 533 produces a cache hit. 535 That is, such a message: i) is exactly the one to be forwarded to 536 (the next hop towards) the origin server if no cache hit is made; 537 and ii) is the result of an OSCORE decryption at the proxy, if 538 OSCORE is used on the communication leg between the proxy and (the 539 previous hop towards) the origin client. 541 * Upon receiving a response from (the next hop towards) the origin 542 server, the proxy first removes the same OSCORE layers that it 543 added when protecting the corresponding outgoing request, as 544 defined in Section 3.5. 546 Then, the proxy stores specifically that resulting response 547 message in its cache. That is, such a message is exactly the one 548 to be forwarded to (the previous hop towards) the origin client. 550 The specific rules about serving a request with a cached response are 551 defined in Section 5.6 of [RFC7252], as well as in Section 7 of 552 [I-D.tiloca-core-groupcomm-proxy] for group communication scenarios. 554 6. Security Considerations 556 TODO 558 7. IANA Considerations 560 This document has no actions for IANA. 562 8. References 564 8.1. Normative References 566 [I-D.ietf-core-oscore-groupcomm] 567 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 568 and J. Park, "Group OSCORE - Secure Group Communication 569 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 570 core-oscore-groupcomm-14, 7 March 2022, 571 . 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 580 Application Protocol (CoAP)", RFC 7252, 581 DOI 10.17487/RFC7252, June 2014, 582 . 584 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 585 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 586 May 2017, . 588 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 589 "Object Security for Constrained RESTful Environments 590 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 591 . 593 8.2. Informative References 595 [I-D.amsuess-core-cachable-oscore] 596 Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in 597 Progress, Internet-Draft, draft-amsuess-core-cachable- 598 oscore-04, 6 March 2022, . 601 [I-D.amsuess-core-transport-indication] 602 Amsüss, C., "CoAP Protocol Indication", Work in Progress, 603 Internet-Draft, draft-amsuess-core-transport-indication- 604 03, 3 March 2022, . 607 [I-D.ietf-core-coap-pubsub] 608 Koster, M., Keranen, A., and J. Jimenez, "Publish- 609 Subscribe Broker for the Constrained Application Protocol 610 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 611 core-coap-pubsub-09, 30 September 2019, 612 . 615 [I-D.ietf-core-groupcomm-bis] 616 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 617 for the Constrained Application Protocol (CoAP)", Work in 618 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 619 06, 7 March 2022, . 622 [I-D.ietf-core-observe-multicast-notifications] 623 Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini, 624 "Observe Notifications as CoAP Multicast Responses", Work 625 in Progress, Internet-Draft, draft-ietf-core-observe- 626 multicast-notifications-03, 7 March 2022, 627 . 630 [I-D.ietf-core-oscore-edhoc] 631 Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., 632 and G. Selander, "Profiling EDHOC for CoAP and OSCORE", 633 Work in Progress, Internet-Draft, draft-ietf-core-oscore- 634 edhoc-03, 7 March 2022, . 637 [I-D.ietf-lake-edhoc] 638 Selander, G., Mattsson, J. P., and F. Palombini, 639 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 640 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 641 October 2021, . 644 [I-D.tiloca-core-groupcomm-proxy] 645 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 646 Communication", Work in Progress, Internet-Draft, draft- 647 tiloca-core-groupcomm-proxy-06, 7 March 2022, 648 . 651 [LwM2M-Core] 652 Open Mobile Alliance, "Lightweight Machine to Machine 653 Technical Specification - Core, Approved Version 1.2, OMA- 654 TS-LightweightM2M_Core-V1_2-20201110-A", November 2020, 655 . 659 [LwM2M-Transport] 660 Open Mobile Alliance, "Lightweight Machine to Machine 661 Technical Specification - Transport Bindings, Approved 662 Version 1.2, OMA-TS-LightweightM2M_Transport- 663 V1_2-20201110-A", November 2020, 664 . 668 [RFC7641] Hartke, K., "Observing Resources in the Constrained 669 Application Protocol (CoAP)", RFC 7641, 670 DOI 10.17487/RFC7641, September 2015, 671 . 673 Appendix A. OSCORE-protected Onion Forwarding 675 TODO: better elaborate on the listed points below. 677 * The client can hide its position in the network from the origin 678 server, while still possibly protecting communications end-to-end 679 with OSCORE. 681 * Use the method defined in Section 3 to achieve OSCORE-protected 682 onion forwarding, through a chain of proxies (at least three are 683 expected). Every message generated by or intended to the origin 684 client must traverse the whole chain of proxies until the intended 685 other endpoint (typically, the origin server). The chain of 686 proxies has to be known in advance by the client, i.e., the exact 687 proxies and their order in the chain. 689 * The typical case addressed in this document considers an origin 690 client that, at most, shares one OSCORE Security Context with the 691 origin server and one OSCORE Security Context with the first proxy 692 in the chain. 694 If onion forwarding is used, the origin client shares an OSCORE 695 Security Context with the origin server, and a dedicated OSCORE 696 Security Context with each of the proxies in the chain. 698 * The origin client protects a request by applying first the OSCORE 699 layer intended to the origin server, then the OSCORE layer 700 intended to the last proxy in the chain, then the OSCORE layer 701 intended to the second from last proxy in the chain and so on, 702 until it applies the OSCORE layer intended to the first proxy in 703 the chain. 705 Before protecting a request with the OSCORE layer to be consumed 706 by a certain proxy in the chain, the origin client also adds 707 proxy-related options intended to that proxy, as indications to 708 forward the request to (the next hop towards) the origin server. 710 Other than the actions above from the client, there should be no 711 difference from the basic approach defined in Section 3. Each 712 proxy in the chain would process and remove one OSCORE layer from 713 the received request and then forward it to (the next hop towards) 714 the origin server. 716 * The exact way used by the client to establish OSCORE Security 717 Contexts with the proxies and the origin server is out of scope. 719 However, if EDHOC is used, it is most convenient for the client to 720 run it with the first proxy in the chain, then with the second 721 proxy in the chain through the first one and so on, and finally 722 with the origin server by traversing the whole chain of proxies. 724 Then, it is especially convenient to use the optimized workflow 725 defined in [I-D.ietf-core-oscore-edhoc] and based on the EDHOC + 726 OSCORE request. This would basically allow the client to complete 727 the EDHOC execution with an endpoint and start the EDHOC execution 728 with the next endpoint in the chain, by means of a single message 729 sent on the wire. 731 * Hop-by-hop security has to also be achieved between each pair of 732 proxies in the chain. To this end, two adjacent proxies would 733 better use TLS over TCP than OSCORE between one another (this 734 should be acceptable for non-constrained proxies). This takes 735 advantage of the TCP packet aggregation policies, and thus: 737 - As request forwarding occurs in MTU-size bundles, the length of 738 the origin request can be hidden as well. 740 - Requests and responses traversing the proxy chain cannot be 741 correlated, e.g., by externally monitoring the timing of 742 message forwarding (which would jeopardize the client's wish to 743 hide itself from anything but the first proxy in the chain). 745 * Cacheability of responses can still happen, as per Section 5 and 746 using the approach defined in [I-D.amsuess-core-cachable-oscore]. 748 The last proxy in the chain would be the only proxy actually 749 seeing the Deterministic Request originated by the client and then 750 caching the corresponding responses from the origin server. It is 751 good that other proxies are not able to do the same, thus 752 preventing what might lead to request-response correlation, again 753 opening for localization of the origin client. 755 * Possible optimizations along the proxy chains 757 - In particular settings involving additional configuration on 758 the client, some proxy in the chain might be a reverse-proxy. 759 Then, such a proxy can be configured to map on one hand the 760 OSCORE Security Context shared with the origin client (and used 761 to remove a corresponding OSCORE layer from a received request 762 to forward) and, on the other hand, the addressing information 763 of the next hop in the chain where to forward the received 764 request to. This would spare the origin client to add a set of 765 proxy-related options for every single proxy in the chain. 767 - It is mentioned above to additionally use TLS over TCP hop-by- 768 hop between every two adjacent proxies in the chain. That 769 said: 771 o The OSCORE protection of the request has certainly to rely 772 on authenticated encryption algorithms (as usual), when 773 applying the OSCORE layer intended to the origin server (the 774 first one applied by the origin client) and the OSCORE layer 775 intended to the first proxy in the chain (the last one 776 applied by the origin client). 778 o For any other OSCORE layer applied by the origin client 779 (i.e., intended for any proxy in the chain but the first 780 one), the OSCORE protection can better rely on an 781 encryption-only algorithm not providing an authentication 782 tag (as admitted in the group mode of Group OSCORE 783 [I-D.ietf-core-oscore-groupcomm] and assuming the 784 registration of such algorithms in COSE). 786 o This would be secure to do, since every pair of adjacent 787 proxies in the chain relies on its TLS connection for the 788 respective hop-by-hop communication anyway. The benefit is 789 that it avoids transmitting several unneeded authentication 790 tags from OSCORE. 792 Acknowledgments 794 The authors sincerely thank Christian Amsuess, Peter Blomqvist and 795 Goeran Selander for their comments and feedback. 797 The work on this document has been partly supported by VINNOVA and 798 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 799 (Grant agreement 952652). 801 Authors' Addresses 803 Marco Tiloca 804 RISE AB 805 Isafjordsgatan 22 806 SE-16440 Kista 807 Sweden 808 Email: marco.tiloca@ri.se 810 Rikard Höglund 811 RISE AB 812 Isafjordsgatan 22 813 SE-16440 Kista 814 Sweden 815 Email: rikard.hoglund@ri.se