idnits 2.17.1 draft-tiloca-core-oscore-capable-proxies-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (12 July 2021) is 1020 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-12 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-04 == Outdated reference: A later version (-08) exists of draft-ietf-core-observe-multicast-notifications-01 == Outdated reference: A later version (-09) exists of draft-tiloca-core-groupcomm-proxy-04 Summary: 0 errors (**), 0 flaws (~~), 6 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. Hoeglund 4 Updates: 8613 (if approved) RISE AB 5 Intended status: Standards Track 12 July 2021 6 Expires: 13 January 2022 8 OSCORE-capable Proxies 9 draft-tiloca-core-oscore-capable-proxies-00 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 OSCORE is used to protect CoAP 17 messages also between an origin application endpoint and an 18 intermediary, or between two intermediaries. Besides, it defines how 19 a CoAP message can be double-protected through "OSCORE-in-OSCORE", 20 i.e., both end-to-end between origin application endpoints, as well 21 as between an application endpoint and an intermediary or between two 22 intermediaries. Thus, this document updates RFC 8613. The same 23 approach applies to Group OSCORE, for protecting CoAP messages when 24 group communication with intermediaries is used. 26 Discussion Venues 28 This note is to be removed before publishing as an RFC. 30 Discussion of this document takes place on the Constrained RESTful 31 Environments Working Group mailing list (core@ietf.org), which is 32 archived at https://mailarchive.ietf.org/arch/browse/core/. 34 Source for this draft and an issue tracker can be found at 35 https://gitlab.com/crimson84/draft-tiloca-core-oscore-to-proxies. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 13 January 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.1. UC1 - CoAP Group Communication with Proxies . . . . . . . 5 74 2.2. UC2 - CoAP Observe Notifications over Multicast . . . . . 5 75 2.3. UC3 - LwM2M Client and External Application Server . . . 6 76 3. Possible Configurations . . . . . . . . . . . . . . . . . . . 7 77 3.1. Configurations without End-to-End Security . . . . . . . 7 78 3.2. Configurations with End-to-End Security . . . . . . . . . 8 79 4. Request Processing . . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Protecting the Request at the Client . . . . . . . . . . 9 81 4.2. Verifying the Request at the Proxy . . . . . . . . . . . 11 82 4.3. Forwarding the Request to the Server . . . . . . . . . . 13 83 4.4. Verifying the Request at the Server . . . . . . . . . . . 13 84 5. Response Processing . . . . . . . . . . . . . . . . . . . . . 15 85 5.1. Protecting the Response at the Server . . . . . . . . . . 15 86 5.2. Verifying the Response at the Proxy . . . . . . . . . . . 17 87 5.3. Forwarding the Response to the Client . . . . . . . . . . 17 88 5.4. Verifying the Response at the Client . . . . . . . . . . 18 89 6. Response Caching . . . . . . . . . . . . . . . . . . . . . . 20 90 7. Chain of Intermediaries . . . . . . . . . . . . . . . . . . . 20 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 Normative References . . . . . . . . . . . . . . . . . . . . . 20 96 Informative References . . . . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 99 1. Introduction 101 The Constrained Application Protocol (CoAP) [RFC7252] supports the 102 presence of intermediaries, such as forward-proxies and reverse- 103 proxies, which assist origin clients by performing requests to origin 104 servers on their behalf, and forwarding back the related responses. 106 CoAP supports also group communication scenarios 107 [I-D.ietf-core-groupcomm-bis], where clients can send a one-to-many 108 request targeting all the servers in the group, e.g., by using IP 109 multicast. Like for one-to-one communication, group settings can 110 also rely on intermediaries [I-D.tiloca-core-groupcomm-proxy]. 112 The protocol Object Security for Constrained RESTful Environments 113 (OSCORE) [RFC8613] can be used to protect CoAP messages between two 114 endpoints at the application layer, especially achieving end-to-end 115 security in the presence of (non-trusted) intermediaries. When CoAP 116 group communication is used, the same can be achieved by means of the 117 protocol Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 119 For a number of use cases (see Section 2), it is required and/or 120 beneficial that communications are secured also between an 121 application endpoint (i.e., a CoAP origin client/server) and an 122 intermediary, as well as between two adjacent intermediaries in a 123 chain. This especially applies to the communication leg between the 124 CoAP origin client and the adjacent intermediary acting as next hop 125 towards the origin server. 127 In such cases, and especially if the origin client already uses 128 OSCORE to achieve end-to-end security with the origin server, it 129 would be convenient that OSCORE is used also to secure communications 130 between the origin client and its next hop. However, the original 131 specification [RFC8613] does not define how OSCORE can be used to 132 protect CoAP messages in such communication leg, i.e., by considering 133 the intermediary as an "OSCORE endpoint". 135 This document fills this gap, and updates [RFC8613] as follows. 137 * It defines how OSCORE is used to protect a CoAP message in the 138 communication leg between: i) an origin client/server and an 139 intermediary; or ii) two adjacent intermediaries in an 140 intermediary chain. That is, besides origin clients/servers, it 141 allows also intermediaries to be possible "OSCORE endpoints". 143 * It explicitly admits a CoAP message to be double-protected through 144 "OSCORE-in-OSCORE". This is the case when the message is first 145 OSCORE-protected end-to-end between the origin client and origin 146 server, and then further OSCORE-protected over the leg between the 147 current and next hop (e.g., the origin client and the adjacent 148 intermediary acting as next hop towards the origin server). 150 What defined in this document is applicable also when Group OSCORE is 151 used, for protecting CoAP messages in group communication scenarios 152 that rely on intermediaries. 154 1.1. 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 the terms and concepts 163 related to CoAP [RFC7252]; OSCORE [RFC8613] and Group OSCORE 164 [I-D.ietf-core-oscore-groupcomm]. This document especially builds on 165 concepts and mechanics related to intermediaries such as CoAP 166 forward-proxies. 168 In addition, this document uses to the following terms. 170 * Source application endpoint: an origin client producing a request, 171 or an origin server producing a response. 173 * Destination application endpoint: an origin server intended to 174 consume a request, or an origin client intended to consume a 175 response. 177 * Application endpoint: a source or destination application 178 endpoint. 180 * Source OSCORE endpoint: an endpoint protecting a message with 181 OSCORE or Group OSCORE. 183 * Destination OSCORE endpoint: an endpoint unprotecting a message 184 with OSCORE or Group OSCORE. 186 * OSCORE endpoint: a source/destination OSCORE endpoint. An OSCORE 187 endpoint is not necessarily also an application endpoint with 188 respect to a certain message. 190 * Proxy-related option: the Proxy-URI Option, the Proxy-Scheme 191 Option, or any of the Uri-* Options. 193 * OSCORE-in-OSCORE: the process by which a message protected with 194 (Group) OSCORE is further protected with (Group) OSCORE. This 195 means that, after the first OSCORE decryption/verification, the 196 resulting message is again an OSCORE-protected message. 198 2. Use Cases 200 The approach proposed in this document has been motivated by a number 201 of use cases, which are summarized below. 203 2.1. UC1 - CoAP Group Communication with Proxies 205 CoAP supports also one-to-many group communication, e.g., over IP 206 multicast [I-D.ietf-core-groupcomm-bis], which can be protected end- 207 to-end between origin client and origin servers by using Group OSCORE 208 [I-D.ietf-core-oscore-groupcomm]. 210 This communication model can be assisted by intermediaries such as a 211 CoAP forward-proxy or reverse-proxy, which relays a group request to 212 the origin servers. If Group OSCORE is used, the proxy is 213 intentionally not a member of the OSCORE group. Furthermore, 214 [I-D.tiloca-core-groupcomm-proxy] defines a signaling protocol 215 between origin client and proxy, to ensure that responses from the 216 different origin servers are forwarded back to the origin client 217 within a time interval set by the client, and that they can be 218 distinguished from one another. 220 In particular, it is required that the proxy identifies the origin 221 client as allowed-listed, before forwarding a group request to the 222 servers (see Section 4 of [I-D.tiloca-core-groupcomm-proxy]). This 223 requires a security association between the origin client and the 224 proxy, which would be convenient to provide with a dedicated OSCORE 225 Security Context between the two, since the client is possibly using 226 also Group OSCORE with the origin servers. 228 2.2. UC2 - CoAP Observe Notifications over Multicast 230 The Observe extension for CoAP [RFC7641] allows a client to register 231 its interest in "observing" a resource at a server. The server can 232 then send back notification responses upon changes to the resource 233 representation, all matching with the original observation request. 235 In some applications, such as pub-sub [I-D.ietf-core-coap-pubsub], 236 multiple clients are interested to observe the same resource at the 237 same server. Hence, [I-D.ietf-core-observe-multicast-notifications] 238 defines a method that allows the server to send a multicast 239 notification to all the observer clients at once, e.g., over IP 240 multicast. To this end, the server synchronizes the clients, by 241 providing them with a common "phantom observation request". 243 In case the clients and the server use Group OSCORE for end-to-end 244 security and a proxy is also involved, an additional step is required 245 (see Section 10 of [I-D.ietf-core-observe-multicast-notifications]). 246 That is, clients are in turn required to provide the proxy with the 247 obtained "phantom observation request", thus enabling the proxy to 248 receive the multicast notifications from the server. 250 Therefore, it is preferable to have a security associations also 251 between each client and the proxy, to especially ensure the integrity 252 of that information provided to the proxy (see Section 13.1 of 253 [I-D.ietf-core-observe-multicast-notifications]). Like for the use 254 case UC1 in Section 2.1, this would be conveniently achieved with a 255 dedicated OSCORE Security Context between a client and the proxy, 256 since the client is also using Group OSCORE with the origin server. 258 2.3. UC3 - LwM2M Client and External Application Server 260 The Lightweight Machine-to-Machine (LwM2M) protocol [LwM2M-Core] 261 enables a LwM2M Client device to securely bootstrap and then register 262 at a LwM2M Server, with which it will perform most of its following 263 communication exchanges. As per the transport bindings specification 264 of LwM2M [LwM2M-Transport], the LwM2M Client and LwM2M Server can use 265 CoAP and OSCORE to secure their communications at the application 266 layer, including during the device registration process. 268 Furthermore, Section 5.5.1 of [LwM2M-Transport] specifies that: 269 "OSCORE MAY also be used between LwM2M endpoint and non-LwM2M 270 endpoint, e.g., between an Application Server and a LwM2M Client via 271 a LwM2M server. Both the LwM2M endpoint and non-LwM2M endpoint MUST 272 implement OSCORE and be provisioned with an OSCORE Security Context." 274 In such a case, the LwM2M Server can practically act as forward-proxy 275 between the LwM2M Client and the external Application Server. At the 276 same time, the LwM2M Client and LwM2M Server must continue protecting 277 communications on their leg using their Security Context. Like for 278 the use case UC1 in Section 2.1, this also allows the LwM2M Server to 279 identify the LwM2M Client, before forwarding its request outside the 280 LwM2M domain and towards the external Application Server. 282 3. Possible Configurations 284 This section provides an overview of different security 285 configurations referred in the document. The configurations differ 286 on whether OSCORE is used or not in a certain communication leg. 288 For simplicity, only one intermediary is considered, as a CoAP-to- 289 CoAP forward-proxy standing between one CoAP client and one CoAP 290 server. The same can be extended to cover a chain of intermediaries, 291 or a group communication scenario where CoAP requests are intended to 292 multiple servers and possibly protected end-to-end with Group OSCORE. 294 The used notation denotes the origin client with C, the origin server 295 with S and the proxy with P. Each configuration is denoted by CF-x, 296 with x a positive integer number expressed by the bits (b2, b1, b0), 297 i.e., x = b0 + (2 * b1) + (4 * b2). 299 In particular, for each configuration CF-x: 301 * C and P use OSCORE between themselves if and only if b0 = 1. 303 * P and S use OSCORE between themselves if and only if b1 = 1. 305 * C and S use OSCORE between themselves if and only if b2 = 1. 307 For convenience, the configurations are split into two sets. That 308 is, Section 3.1 overviews those where C and S do not use OSCORE 309 between themselves (b2 = 0), while Section 3.2 overviews those where 310 C and S use OSCORE between themselves (b2 = 1). 312 3.1. Configurations without End-to-End Security 314 Figure 1 shows the different configurations where OSCORE is not used 315 end-to-end by the two application endpoints C and S. That is, none 316 of the shown configurations include the leg "C-S", i.e., b2 = 0. 318 In the configurations CF-1, CF-2 and CF-3, the proxy uses OSCORE with 319 C and/or S, hence the legs "C-P" and/or "P-S" are also included. 320 None of these configurations results in using "OSCORE-in-OSCORE". 322 +--------------+-------+-------+-------+-------+ 323 | Conf. name | CF-0 | CF-1 | CF-2 | CF-3 | 324 | (b2, b1, b0) | (000) | (001) | (010) | (011) | 325 +--------------+-------+-------+-------+-------+ 326 | Comm. legs | | | | | 327 | using OSCORE | | C-P | | C-P | 328 | | | | P-S | P-S | 329 +--------------+-------+-------+-------+-------+ 330 C=Client, P=Proxy, S=Server 332 Figure 1: Configurations without end-to-end security. 334 Note that: 336 * CF-0 is the canonical case defined in [RFC7252] with no security 337 at the application layer. 339 * CF-1 is relevant for the use cases UC1 and UC3 in Section 2, where 340 end-to-end security is not provided between client and server(s). 341 Instead, it is not relevant for UC2, since that use case would 342 require secure communication between clients and proxy only when 343 Group OSCORE is also used for end-to-security between the observer 344 clients and the server (see Section 2.2). 346 * CF-2 can be seen as the canonical case of [RFC8613], with P acting 347 as client with S. 349 * CF-3 can be seen as the canonical case of [RFC8613], applied 350 separately to the two legs "C-P" (with P acting as server) and 351 "P-S" (with P acting as client). 353 3.2. Configurations with End-to-End Security 355 Figure 2 shows the different configurations where OSCORE is used end- 356 to-end by the two application endpoints C and S. That is, all the 357 shown configurations include the leg "C-S", i.e., b2 = 1. 359 In the configurations CF-5, CF-6 and CF-7, the proxy uses OSCORE with 360 C and/or S, hence the legs "C-P" and/or "P-S" are also included. 361 Therefore, these configurations result in double-protecting the CoAP 362 messages originated at C and S, and are thus marked with "(*)" to 363 indicate the use of "OSCORE-in-OSCORE". 365 +--------------+---------+---------+---------+---------+ 366 | Conf. name | CF-4 | CF-5 | CF-6 | CF-7 | 367 | (b2, b1, b0) | (100) | (101) | (110) | (111) | 368 +--------------+---------+---------+---------+---------+ 369 | Comm. legs | C-S | C-S | C-S | C-S | 370 | using OSCORE | | C-P (*) | | C-P (*) | 371 | | | | P-S (*) | P-S (*) | 372 +--------------+---------+---------+---------+---------+ 373 C=Client, P=Proxy, S=Server 374 (*) OSCORE-in-OSCORE 376 Figure 2: Configurations with end-to-end security. 378 Note that: 380 * CF-4 is the canonical case defined in [RFC8613]. 382 * CF-5 is relevant for the use cases UC1, UC2 and UC3 in Section 2. 384 * CF-7 is relevant for the use cases UC2 and UC3 in Section 2. 385 Instead, it is not relevant for UC1, since that would imply that P 386 is also a member of the OSCORE group including the servers, which 387 is not desirable (see Section 2.1). 389 4. Request Processing 391 This section extends the actions performed to protect an outgoing 392 request, with respect to [RFC8613] or 393 [I-D.ietf-core-oscore-groupcomm] when OSCORE or Group OSCORE is used, 394 respectively. Throughout the text, the configurations defined in 395 Section 3 are also recalled by means of the bits (b2, b1, b0), to 396 indicate the communication leg(s) using OSCORE. 398 The following assumes the presence of a single intermediary acting as 399 CoAP-to-CoAP Forward-Proxy between the origin CoAP client and a 400 single origin CoAP server. 402 4.1. Protecting the Request at the Client 404 The client performs the following steps. 406 1. The client prepares the CoAP request REQ for the origin server, 407 which is the intended destination application endpoint. 409 2. Since the client knows that a proxy is involved as next hop, the 410 client adds the appropriate proxy-related options to the request. 412 3. If the client uses (Group) OSCORE with the origin server (b2 = 413 1), it performs the following actions. Otherwise, it moves to 414 step 4. 416 * The client protects the request REQ as it normally happens 417 with OSCORE or Group OSCORE, using the Security Context shared 418 with the server. 420 * The result is a protected request REQ* including an OSCORE 421 option. The intended destination OSCORE endpoint is the 422 origin server. 424 * REQ takes REQ*, and the client moves to step 4. 426 4. If the client uses (Group) OSCORE with the proxy (b0 = 1), it 427 performs the following actions. Otherwise, it moves to step 5. 429 * The client protects the request REQ with (Group) OSCORE, using 430 the Security Context shared with the Proxy. Note that the 431 Proxy-Uri option, if present at this point in time (b2 = 0 and 432 b0 = 1), is first decomposed as per Section 4.1.3.3 of 433 [RFC8613]. 435 Unlike in [RFC8613], the following options are processed as 436 Class E, if present. 438 - Proxy-Scheme, Uri-Host, Uri-Port, Uri-Path and Uri-Query. 440 - OSCORE, which is present if (Group) OSCORE is used between 441 the origin client and the origin server (i.e., b2 = 1 and 442 b0 = 1, hence step 3 above was performed). This is 443 "OSCORE-in-OSCORE" and deviates from [RFC8613]. 445 - Multicast-Signaling Option, defined in 446 [I-D.tiloca-core-groupcomm-proxy]. 448 - Listen-To-Multicast-Responses Option, defined in 449 [I-D.ietf-core-observe-multicast-notifications]. 451 - Any other option that is intended to be accessed and 452 consumed by the proxy. 454 * The result is a protected request REQ** including its own 455 outer OSCORE option, i.e., REQ** = Enc(REQ). The intended 456 destination OSCORE endpoint is the proxy. 458 * REQ takes REQ**, and the client moves to step 5. 460 5. The client sends the request REQ to the proxy. 462 4.2. Verifying the Request at the Proxy 464 The proxy performs the following steps. 466 1. The proxy receives the request REQ from the origin client. 468 2. The proxy assesses which alternative it is. 470 * Alt 2.1 - The request REQ includes proxy-related options as 471 already visible to the proxy (b0 = 0). Hence, the request has 472 to be forwarded to the origin server. 474 In this case, the proxy moves to step 4. 476 Note that: 478 - The request REQ includes an OSCORE option if the proxy is 479 neither the destination application endpoint nor the 480 destination OSCORE endpoint (b2 = 1 and b0 = 0). 482 - The request REQ does not include an OSCORE option if the 483 proxy is not the destination application endpoint and no 484 OSCORE is involved (b2 = 0 and b0 = 0). 486 * Alt 2.2 - The request REQ does not include proxy-related 487 options but it includes an OSCORE option, as visible to the 488 proxy (b0 = 1). Hence, the proxy is the destination OSCORE 489 endpoint. 491 In this case, the proxy moves to step 3. 493 Note that, at this point in time, the proxy does not know yet 494 if it is going to act as proxy by forwarding the request, or 495 if it is instead the actual destination application endpoint. 497 * Alt 2.3 - The request REQ does not include proxy-related 498 options and it does not include an OSCORE option, as visible 499 to the proxy (b2 = 0 and b0 = 0). Hence, the proxy is the 500 destination application endpoint with no OSCORE is involved. 502 In this case, the proxy delivers the request REQ to the 503 application for processing. 505 3. Coming from alternative 2.2 of step 2, the proxy unprotects the 506 request REQ using the OSCORE Security Context shared with the 507 origin client. 509 In case of an OSCORE-related error, the proxy responds to the 510 client with an unprotected error response. Following a 511 successful processing, i.e. REQ* = Dec(REQ), three alternatives 512 are possible. 514 * Alt 3.1 - The decrypted request REQ* includes proxy-related 515 options. Hence, the request has to be forwarded to the origin 516 server. 518 In this case, REQ takes REQ*, and the proxy moves to step 4. 520 Note that: 522 - If the decrypted request REQ* includes an OSCORE option as 523 well as proxy-related options, then the proxy is not the 524 destination application endpoint, and OSCORE is used end- 525 to-end between the origin client and origin server (b2 = 1 526 and b0 = 1). This is "OSCORE-in-OSCORE" and deviates from 527 [RFC8613], i.e., under this specific outcome, it is fine 528 for the proxy to find an OSCORE option in the decrypted 529 request REQ*, and the message is not rejected. 531 - If the decrypted request REQ* does not include an OSCORE 532 option, but it includes proxy-related options, then the 533 proxy is not the destination application endpoint, and 534 OSCORE is not used end-to-end between the origin client and 535 origin server (b2 = 0 and b0 = 1). 537 * Alt 3.2 - The decrypted request REQ* does not include an 538 OSCORE option, and it does not include any proxy-related 539 option. Hence, the proxy is the actual destination 540 application endpoint. 542 In this case, the proxy delivers the decrypted request REQ* to 543 the application for processing. The possible following 544 response to the client occurs as per [RFC8613]. 546 * Alt 3.3 - The decrypted request REQ* includes an OSCORE 547 option, but it does not include any proxy-related option. 549 This alternative is not valid, and the proxy MUST respond to 550 the client with an error response. This response MUST be 551 protected with the (Group) OSCORE Security Context shared with 552 the client. 554 4. The proxy proceeds with the forwarding of the request REQ to the 555 origin server (see Section 4.3). 557 4.3. Forwarding the Request to the Server 559 The proxy performs the following steps. 561 1. The proxy sets the Request URI in the request REQ, by consuming 562 the Proxy-Uri or the Proxy-Scheme option as per Section 5.7.2 of 563 [RFC7252]. 565 2. If the proxy uses OSCORE with the origin server (b1 = 1), the 566 proxy performs the following actions. Otherwise, the proxy moves 567 to step 3. 569 * The proxy protects the request REQ with OSCORE, i.e. REQ* = 570 Enc(REQ), using the Security Context shared with the origin 571 server. 573 Unlike in [RFC8613], the OSCORE option, if present in the 574 request REQ to protect, is processed as Class E. This is the 575 case if (Group) OSCORE is used between the origin client and 576 the origin server (b2 = 1 and b1 = 1). This is "OSCORE-in- 577 OSCORE" and deviates from [RFC8613]. 579 * The result is a protected request REQ* including an OSCORE 580 option. The intended destination OSCORE endpoint is the 581 origin server. 583 * REQ takes REQ*, and the proxy moves to step 3. 585 3. The proxy forwards the request REQ to the origin server. 587 4.4. Verifying the Request at the Server 589 The server performs the following steps. 591 1. The server receives the request REQ from the proxy. 593 In the considered scenario, the server is the actual origin 594 server, hence it never encounters proxy-related options when 595 processing the request (i.e., neither as outer nor as inner 596 options). This means that the server is the destination OSCORE 597 endpoint with respect to any OSCORE option it encounters when 598 processing the request. 600 2. The server assesses which alternative it is. 602 * Alt 2.1 - The request REQ does not include an OSCORE option 603 (b2 = 0 and b1 = 0). 605 If proxy-related options are found at this point in time, this 606 endpoint is not the actual destination application endpoint, 607 and it should follow what described in Section 4.2, if it 608 supports acting as proxy. 610 Otherwise, the server is the destination application endpoint. 611 Hence, the server moves to step 5. 613 * Alt 2.2 - The request REQ includes an OSCORE option (b2 = 1 or 614 b1 = 1). 616 In this case, the server is the destination OSCORE endpoint. 617 Hence, the server moves to step 3. 619 3. Coming from alternative 2.2 of step 2, the server unprotects the 620 request REQ using the OSCORE Security Context pointed by the 621 OSCORE option, i.e. REQ* = Dec(REQ). 623 In case of an OSCORE-related error, the server responds to the 624 proxy with an unprotected error response. Instead, following a 625 successful processing, the two valid alternatives below are 626 possible. 628 If proxy-related options are found at this point in time, this 629 endpoint is not the actual destination application endpoint. 630 Hence, it should rather follow what described in Section 4.2, if 631 it supports acting as proxy. 633 * Alt 3.1 - The decrypted request REQ* does not include an 634 OSCORE option (b2 XOR b1 = 1). Hence, the server is the 635 destination application endpoint. 637 In this case, REQ takes REQ*, and the server moves to step 5. 639 * Alt 3.2 - The decrypted request REQ* includes an OSCORE option 640 (b2 = 1 and b1 = 1). Hence, since the decrypted request REQ* 641 does not include any proxy-related option, the server is the 642 destination application endpoint, but it has to perform the 643 actual end-to-end OSCORE decryption first. 645 In this case, the server moves to step 4. 647 Note that, this is "OSCORE-in-OSCORE" and deviates from 648 [RFC8613], i.e., under this specific outcome, it is fine for 649 the server to find an OSCORE option in the decrypted message, 650 and the message is not rejected. 652 4. Coming from alternative 3.2 of step 3, the server unprotects the 653 inner request REQ* using the OSCORE Security Context pointed by 654 the OSCORE option in REQ*, i.e. REQ** = Dec(REQ*). 656 If any of the following cases occurs, the server MUST discard the 657 request and MUST reply with an error response, which MUST be 658 protected using the OSCORE Security Context shared with the 659 proxy. 661 * An OSCORE-related error occurred when unprotecting REQ*, i.e. 662 when using the OSCORE Security Context shared with the client. 664 * The decrypted request REQ** includes any proxy-related option. 665 That is, proxy-related options cannot appear after having 666 performed OSCORE decryption twice. 668 * The decrypted request REQ** includes an OSCORE option. That 669 is, at most two layers of OSCORE protection are admitted, i.e. 670 one with the other application endpoint and one with the 671 adjacent transport hop. 673 Otherwise, REQ takes REQ**, and the server moves to step 5. 675 5. The server delivers the request REQ to the application for 676 processing. The possible following response to the proxy will 677 happen as per [RFC7252], and possibly [RFC8613] or 678 [I-D.ietf-core-oscore-groupcomm]. 680 5. Response Processing 682 Following up on the process in Section 4, this section extends the 683 actions performed to protect an outgoing response, with respect to 684 [RFC8613] or [I-D.ietf-core-oscore-groupcomm] when OSCORE or Group 685 OSCORE is used, respectively. Throughout the text, the 686 configurations defined in Section 3 are also recalled by means of the 687 bits (b2, b1, b0), to indicate the communication leg(s) using OSCORE. 689 The following assumes the presence of a single intermediary acting as 690 CoAP-to-CoAP Forward-Proxy between the origin CoAP client and a 691 single origin CoAP server. 693 5.1. Protecting the Response at the Server 695 The server performs the following steps. 697 1. The server possibly prepares a CoAP response RESP to send to the 698 proxy, to be forwarded to the origin client as intended 699 destination application endpoint. 701 2. The server proceeds as follows. 703 * If the server performed only one OSCORE processing when 704 receiving the request (b2 XOR b1 = 1), it moves to step 3. 706 * If the server performed two OSCORE processings when receiving 707 the request (b2 = 1 and b1 = 1), it moves to step 4. 709 * If the server performed no OSCORE processing when receiving 710 the request (b2 = 0 and b1 = 0), it moves to step 5. 712 3. The server protects the response RESP using the same OSCORE 713 Security Context used to unprotect the request REQ. The result 714 is a protected response including an OSCORE option, i.e. RESP* = 715 Enc(RESP). 717 Then, RESP takes RESP*, and the server moves to step 5. 719 4. The server proceeds as follows. 721 * 4.1. The server protects the response RESP using the same 722 OSCORE Security Context used for the second and last 723 processing of the request, i.e. the one shared with the origin 724 client. 726 The result is a protected response including an OSCORE option, 727 i.e. RESP* = Enc(RESP). 729 * 4.2. The server protects the encrypted response RESP* using 730 the same OSCORE Security Context used for the first processing 731 of the request, i.e. the one shared with the proxy as adjacent 732 transport hop. 734 The OSCORE option in the encrypted response RESP* is processed 735 as class E. If present, any other option that is intended to 736 be accessed and consumed by the proxy is also processed as 737 Class E. This is "OSCORE-in-OSCORE" and deviates from 738 [RFC8613]. 740 The result is a protected response including its own outer 741 OSCORE option, i.e. RESP** = Enc(RESP*). 743 4.3. RESP takes RESP**, and the server moves to step 5. 745 5. The server sends the response RESP to the proxy. 747 5.2. Verifying the Response at the Proxy 749 The proxy performs the following steps. 751 1. The proxy receives the response RESP from the origin server. 753 2. The proxy proceeds as follows. 755 * If the proxy protected the request forwarded to the server by 756 using OSCORE (b1 = 1), it moves to step 3. 758 * If the proxy did not protect the request forwarded to the 759 server by using OSCORE (b1 = 0), it moves to step 4. 761 3. The proxy proceeds as follows. 763 If the received response RESP is unprotected, the proxy 764 interprets it as an OSCORE-related error at the server. This 765 concerns the OSCORE association between proxy and server, and it 766 is up to the proxy to handle this issue. 768 Otherwise, i.e., the received response RESP includes an outer 769 OSCORE option, the proxy unprotects the response RESP, with the 770 OSCORE Security Context shared with the server. This results in 771 a decrypted response RESP* = Dec(RESP). 773 If the OSCORE protection of the request performed by the proxy 774 did not result in "OSCORE-in-OSCORE" (b2 = 0 and b1 = 1) --- see 775 step 2 of Section 4.3 --- and the decrypted response RESP* 776 includes an OSCORE option, then the proxy MUST discard the 777 response. 779 In any other case, RESP takes RESP*, and the proxy moves to step 780 4. 782 4. The proxy forwards the response RESP back to the origin client 783 (see Section 5.3). 785 5.3. Forwarding the Response to the Client 787 The proxy performs the following steps. 789 1. The proxy adds possible options to the response RESP to be 790 forwarded. 792 2. If the proxy uses (Group) OSCORE with the client, and the 793 originally received request was protected with the OSCORE 794 Security Context shared with the client (b0 = 1), then the proxy 795 proceeds as follows. 797 * The proxy protects the response RESP with OSCORE, i.e. RESP* = 798 Enc(RESP), using the Security Context shared with the origin 799 client. The following options, if present in the response 800 RESP to protect, are processed as class E: 802 - The OSCORE option. This is the case if (Group) OSCORE is 803 used between the origin client and the origin server (b2 = 804 1 and b0 = 1). This is "OSCORE-in-OSCORE", which deviates 805 from [RFC8613]. 807 - Any other option that has been added by the proxy, e.g. the 808 Response-Forwarding Option defined in 809 [I-D.tiloca-core-groupcomm-proxy]. 811 * The result is a protected response RESP* including an OSCORE 812 option. The intended destination OSCORE endpoint is the 813 origin client. 815 * RESP takes RESP*, and the proxy moves to step 3. 817 3. The proxy forwards the response RESP back to the origin client. 819 5.4. Verifying the Response at the Client 821 The client performs the following steps. 823 1. The client receives the response RESP from the proxy. 825 2. The client proceeds as follows. 827 * If the client protected the request with (Group) OSCORE using 828 an OSCORE Security Context shared with the proxy (b0 = 1), it 829 moves to step 3. 831 * If the client did not protect the request with (Group) OSCORE 832 using an OSCORE Security Context shared with the proxy (b0 = 833 0), it moves to step 4. 835 3. The client proceeds as follows. 837 If the received response RESP is an unprotected 4.00/4.01/4.02, 838 the client interprets it as an OSCORE-related error at the proxy. 839 This concerns the OSCORE association between client and proxy, 840 and it is up to the client to handle this issue. Information 841 specified in the diagnostic payload, if present, might result in 842 the client taking alternative, more appropriate actions. 844 Otherwise, i.e. the received response RESP includes an outer 845 OSCORE option, the client unprotects the response RESP, with the 846 OSCORE Security Context shared with the proxy. This results in a 847 decrypted response RESP* = Dec(RESP). 849 If the OSCORE protection of the request performed by the client 850 did not result in "OSCORE-in-OSCORE" (b2 = 0 and b0 = 1) --- see 851 step 4 of Section 4.1 --- and the decrypted response RESP* 852 includes an OSCORE option, then the client MUST discard the 853 message and does not perform any further processing. 855 If the OSCORE protection of the request performed by the client 856 resulted in "OSCORE-in-OSCORE" (b2 = 1 and b0 = 1) --- see step 4 857 of Section 4.1 --- then the decrypted response RESP* may include 858 an OSCORE option. This is "OSCORE-in-OSCORE" and deviates from 859 [RFC8613], i.e., under this specific outcome, it is fine for the 860 client to find an OSCORE option in the decrypted messages, and 861 the message is not rejected. 863 Finally, RESP takes RESP*, and the client moves to step 4. 865 4. The client proceeds as follows. 867 * If the client did not protect the original CoAP request with 868 (Group) OSCORE using an OSCORE Security Context shared with 869 the origin server (b2 = 0), the client moves to step 5. 871 * If the client protected the original CoAP request with (Group) 872 OSCORE using an OSCORE Security Context shared with the origin 873 server (b2 = 1), the client proceeds as follows. 875 If the response RESP is an unprotected 4.00/4.01/4.02, the 876 client interprets it as an OSCORE-related error at the origin 877 server. This concerns the OSCORE association between client 878 and server, and it is up to the client to handle this issue. 879 Information specified in the diagnostic payload, if present, 880 might result in the client taking alternative, more 881 appropriate actions. 883 Otherwise, i.e. the response RESP includes an OSCORE option, 884 the client unprotects the response RESP, with the OSCORE 885 Security Context shared with the origin server. This results 886 in a decrypted response RESP* = Dec(RESP). 888 The client MUST discard the decrypted response RESP*, in case 889 RESP* is the result of two OSCORE decryptions in a row (b2 = 1 890 and b0 = 1) and includes an OSCORE option. That is, at most 891 two layers of OSCORE protection are admitted, i.e. one with 892 the other application endpoint and one with the adjacent 893 transport hop. 895 Otherwise, RESP takes RESP*, and the client moves to step 5. 897 5. The client delivers the response RESP to the application for 898 processing. 900 6. Response Caching 902 TBD 904 7. Chain of Intermediaries 906 TBD 908 8. Security Considerations 910 TBD 912 9. IANA Considerations 914 This document has no actions for IANA. 916 Acknowledgments 918 The authors sincerely thank Christian Amsuess, Peter Blomqvist and 919 Goeran Selander for the initial discussions that allowed shaping this 920 document. 922 The work on this document has been partly supported by VINNOVA and 923 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 924 (Grant agreement 952652). 926 References 928 Normative References 930 [I-D.ietf-core-oscore-groupcomm] 931 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 932 and J. Park, "Group OSCORE - Secure Group Communication 933 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 934 core-oscore-groupcomm-12, 12 July 2021, 935 . 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, 940 DOI 10.17487/RFC2119, March 1997, 941 . 943 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 944 Application Protocol (CoAP)", RFC 7252, 945 DOI 10.17487/RFC7252, June 2014, 946 . 948 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 949 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 950 May 2017, . 952 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 953 "Object Security for Constrained RESTful Environments 954 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 955 . 957 Informative References 959 [I-D.ietf-core-coap-pubsub] 960 Koster, M., Keranen, A., and J. Jimenez, "Publish- 961 Subscribe Broker for the Constrained Application Protocol 962 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 963 core-coap-pubsub-09, 30 September 2019, 964 . 967 [I-D.ietf-core-groupcomm-bis] 968 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 969 for the Constrained Application Protocol (CoAP)", Work in 970 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 971 04, 12 July 2021, . 974 [I-D.ietf-core-observe-multicast-notifications] 975 Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, 976 "Observe Notifications as CoAP Multicast Responses", Work 977 in Progress, Internet-Draft, draft-ietf-core-observe- 978 multicast-notifications-01, 12 July 2021, 979 . 982 [I-D.tiloca-core-groupcomm-proxy] 983 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 984 Communication", Work in Progress, Internet-Draft, draft- 985 tiloca-core-groupcomm-proxy-04, 12 July 2021, 986 . 989 [LwM2M-Core] 990 Open Mobile Alliance, "Lightweight Machine to Machine 991 Technical Specification - Core, Approved Version 1.2, OMA- 992 TS-LightweightM2M_Core-V1_2-20201110-A", November 2020, 993 . 997 [LwM2M-Transport] 998 Open Mobile Alliance, "Lightweight Machine to Machine 999 Technical Specification - Transport Bindings, Approved 1000 Version 1.2, OMA-TS-LightweightM2M_Transport- 1001 V1_2-20201110-A", November 2020, 1002 . 1006 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1007 Application Protocol (CoAP)", RFC 7641, 1008 DOI 10.17487/RFC7641, September 2015, 1009 . 1011 Authors' Addresses 1013 Marco Tiloca 1014 RISE AB 1015 Isafjordsgatan 22 1016 SE-16440 Kista 1017 Sweden 1019 Email: marco.tiloca@ri.se 1020 Rikard Hoeglund 1021 RISE AB 1022 Isafjordsgatan 22 1023 SE-16440 Kista 1024 Sweden 1026 Email: rikard.hoglund@ri.se