CoRE Working Group M. Tiloca Internet-Draft R. Hoeglund Updates: 8613 (if approved) RISE AB Intended status: Standards Track 12 July 2021 Expires: 13 January 2022 OSCORE-capable Proxies draft-tiloca-core-oscore-capable-proxies-00 Abstract Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how OSCORE is used to protect CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Besides, it defines how a CoAP message can be double-protected through "OSCORE-in-OSCORE", i.e., both end-to-end between origin application endpoints, as well as between an application endpoint and an intermediary or between two intermediaries. Thus, this document updates RFC 8613. The same approach applies to Group OSCORE, for protecting CoAP messages when group communication with intermediaries is used. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Source for this draft and an issue tracker can be found at https://gitlab.com/crimson84/draft-tiloca-core-oscore-to-proxies. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Tiloca & Höglund Expires 13 January 2022 [Page 1] Internet-Draft OSCORE-capable Proxies July 2021 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 13 January 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. UC1 - CoAP Group Communication with Proxies . . . . . . . 5 2.2. UC2 - CoAP Observe Notifications over Multicast . . . . . 5 2.3. UC3 - LwM2M Client and External Application Server . . . 6 3. Possible Configurations . . . . . . . . . . . . . . . . . . . 7 3.1. Configurations without End-to-End Security . . . . . . . 7 3.2. Configurations with End-to-End Security . . . . . . . . . 8 4. Request Processing . . . . . . . . . . . . . . . . . . . . . 9 4.1. Protecting the Request at the Client . . . . . . . . . . 9 4.2. Verifying the Request at the Proxy . . . . . . . . . . . 11 4.3. Forwarding the Request to the Server . . . . . . . . . . 13 4.4. Verifying the Request at the Server . . . . . . . . . . . 13 5. Response Processing . . . . . . . . . . . . . . . . . . . . . 15 5.1. Protecting the Response at the Server . . . . . . . . . . 15 5.2. Verifying the Response at the Proxy . . . . . . . . . . . 17 5.3. Forwarding the Response to the Client . . . . . . . . . . 17 5.4. Verifying the Response at the Client . . . . . . . . . . 18 6. Response Caching . . . . . . . . . . . . . . . . . . . . . . 20 7. Chain of Intermediaries . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Tiloca & Höglund Expires 13 January 2022 [Page 2] Internet-Draft OSCORE-capable Proxies July 2021 Normative References . . . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The Constrained Application Protocol (CoAP) [RFC7252] supports the presence of intermediaries, such as forward-proxies and reverse- proxies, which assist origin clients by performing requests to origin servers on their behalf, and forwarding back the related responses. CoAP supports also group communication scenarios [I-D.ietf-core-groupcomm-bis], where clients can send a one-to-many request targeting all the servers in the group, e.g., by using IP multicast. Like for one-to-one communication, group settings can also rely on intermediaries [I-D.tiloca-core-groupcomm-proxy]. The protocol Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] can be used to protect CoAP messages between two endpoints at the application layer, especially achieving end-to-end security in the presence of (non-trusted) intermediaries. When CoAP group communication is used, the same can be achieved by means of the protocol Group OSCORE [I-D.ietf-core-oscore-groupcomm]. For a number of use cases (see Section 2), it is required and/or beneficial that communications are secured also between an application endpoint (i.e., a CoAP origin client/server) and an intermediary, as well as between two adjacent intermediaries in a chain. This especially applies to the communication leg between the CoAP origin client and the adjacent intermediary acting as next hop towards the origin server. In such cases, and especially if the origin client already uses OSCORE to achieve end-to-end security with the origin server, it would be convenient that OSCORE is used also to secure communications between the origin client and its next hop. However, the original specification [RFC8613] does not define how OSCORE can be used to protect CoAP messages in such communication leg, i.e., by considering the intermediary as an "OSCORE endpoint". This document fills this gap, and updates [RFC8613] as follows. * It defines how OSCORE is used to protect a CoAP message in the communication leg between: i) an origin client/server and an intermediary; or ii) two adjacent intermediaries in an intermediary chain. That is, besides origin clients/servers, it allows also intermediaries to be possible "OSCORE endpoints". Tiloca & Höglund Expires 13 January 2022 [Page 3] Internet-Draft OSCORE-capable Proxies July 2021 * It explicitly admits a CoAP message to be double-protected through "OSCORE-in-OSCORE". This is the case when the message is first OSCORE-protected end-to-end between the origin client and origin server, and then further OSCORE-protected over the leg between the current and next hop (e.g., the origin client and the adjacent intermediary acting as next hop towards the origin server). What defined in this document is applicable also when Group OSCORE is used, for protecting CoAP messages in group communication scenarios that rely on intermediaries. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts related to CoAP [RFC7252]; OSCORE [RFC8613] and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. This document especially builds on concepts and mechanics related to intermediaries such as CoAP forward-proxies. In addition, this document uses to the following terms. * Source application endpoint: an origin client producing a request, or an origin server producing a response. * Destination application endpoint: an origin server intended to consume a request, or an origin client intended to consume a response. * Application endpoint: a source or destination application endpoint. * Source OSCORE endpoint: an endpoint protecting a message with OSCORE or Group OSCORE. * Destination OSCORE endpoint: an endpoint unprotecting a message with OSCORE or Group OSCORE. * OSCORE endpoint: a source/destination OSCORE endpoint. An OSCORE endpoint is not necessarily also an application endpoint with respect to a certain message. Tiloca & Höglund Expires 13 January 2022 [Page 4] Internet-Draft OSCORE-capable Proxies July 2021 * Proxy-related option: the Proxy-URI Option, the Proxy-Scheme Option, or any of the Uri-* Options. * OSCORE-in-OSCORE: the process by which a message protected with (Group) OSCORE is further protected with (Group) OSCORE. This means that, after the first OSCORE decryption/verification, the resulting message is again an OSCORE-protected message. 2. Use Cases The approach proposed in this document has been motivated by a number of use cases, which are summarized below. 2.1. UC1 - CoAP Group Communication with Proxies CoAP supports also one-to-many group communication, e.g., over IP multicast [I-D.ietf-core-groupcomm-bis], which can be protected end- to-end between origin client and origin servers by using Group OSCORE [I-D.ietf-core-oscore-groupcomm]. This communication model can be assisted by intermediaries such as a CoAP forward-proxy or reverse-proxy, which relays a group request to the origin servers. If Group OSCORE is used, the proxy is intentionally not a member of the OSCORE group. Furthermore, [I-D.tiloca-core-groupcomm-proxy] defines a signaling protocol between origin client and proxy, to ensure that responses from the different origin servers are forwarded back to the origin client within a time interval set by the client, and that they can be distinguished from one another. In particular, it is required that the proxy identifies the origin client as allowed-listed, before forwarding a group request to the servers (see Section 4 of [I-D.tiloca-core-groupcomm-proxy]). This requires a security association between the origin client and the proxy, which would be convenient to provide with a dedicated OSCORE Security Context between the two, since the client is possibly using also Group OSCORE with the origin servers. 2.2. UC2 - CoAP Observe Notifications over Multicast The Observe extension for CoAP [RFC7641] allows a client to register its interest in "observing" a resource at a server. The server can then send back notification responses upon changes to the resource representation, all matching with the original observation request. In some applications, such as pub-sub [I-D.ietf-core-coap-pubsub], multiple clients are interested to observe the same resource at the same server. Hence, [I-D.ietf-core-observe-multicast-notifications] Tiloca & Höglund Expires 13 January 2022 [Page 5] Internet-Draft OSCORE-capable Proxies July 2021 defines a method that allows the server to send a multicast notification to all the observer clients at once, e.g., over IP multicast. To this end, the server synchronizes the clients, by providing them with a common "phantom observation request". In case the clients and the server use Group OSCORE for end-to-end security and a proxy is also involved, an additional step is required (see Section 10 of [I-D.ietf-core-observe-multicast-notifications]). That is, clients are in turn required to provide the proxy with the obtained "phantom observation request", thus enabling the proxy to receive the multicast notifications from the server. Therefore, it is preferable to have a security associations also between each client and the proxy, to especially ensure the integrity of that information provided to the proxy (see Section 13.1 of [I-D.ietf-core-observe-multicast-notifications]). Like for the use case UC1 in Section 2.1, this would be conveniently achieved with a dedicated OSCORE Security Context between a client and the proxy, since the client is also using Group OSCORE with the origin server. 2.3. UC3 - LwM2M Client and External Application Server The Lightweight Machine-to-Machine (LwM2M) protocol [LwM2M-Core] enables a LwM2M Client device to securely bootstrap and then register at a LwM2M Server, with which it will perform most of its following communication exchanges. As per the transport bindings specification of LwM2M [LwM2M-Transport], the LwM2M Client and LwM2M Server can use CoAP and OSCORE to secure their communications at the application layer, including during the device registration process. Furthermore, Section 5.5.1 of [LwM2M-Transport] specifies that: "OSCORE MAY also be used between LwM2M endpoint and non-LwM2M endpoint, e.g., between an Application Server and a LwM2M Client via a LwM2M server. Both the LwM2M endpoint and non-LwM2M endpoint MUST implement OSCORE and be provisioned with an OSCORE Security Context." In such a case, the LwM2M Server can practically act as forward-proxy between the LwM2M Client and the external Application Server. At the same time, the LwM2M Client and LwM2M Server must continue protecting communications on their leg using their Security Context. Like for the use case UC1 in Section 2.1, this also allows the LwM2M Server to identify the LwM2M Client, before forwarding its request outside the LwM2M domain and towards the external Application Server. Tiloca & Höglund Expires 13 January 2022 [Page 6] Internet-Draft OSCORE-capable Proxies July 2021 3. Possible Configurations This section provides an overview of different security configurations referred in the document. The configurations differ on whether OSCORE is used or not in a certain communication leg. For simplicity, only one intermediary is considered, as a CoAP-to- CoAP forward-proxy standing between one CoAP client and one CoAP server. The same can be extended to cover a chain of intermediaries, or a group communication scenario where CoAP requests are intended to multiple servers and possibly protected end-to-end with Group OSCORE. The used notation denotes the origin client with C, the origin server with S and the proxy with P. Each configuration is denoted by CF-x, with x a positive integer number expressed by the bits (b2, b1, b0), i.e., x = b0 + (2 * b1) + (4 * b2). In particular, for each configuration CF-x: * C and P use OSCORE between themselves if and only if b0 = 1. * P and S use OSCORE between themselves if and only if b1 = 1. * C and S use OSCORE between themselves if and only if b2 = 1. For convenience, the configurations are split into two sets. That is, Section 3.1 overviews those where C and S do not use OSCORE between themselves (b2 = 0), while Section 3.2 overviews those where C and S use OSCORE between themselves (b2 = 1). 3.1. Configurations without End-to-End Security Figure 1 shows the different configurations where OSCORE is not used end-to-end by the two application endpoints C and S. That is, none of the shown configurations include the leg "C-S", i.e., b2 = 0. In the configurations CF-1, CF-2 and CF-3, the proxy uses OSCORE with C and/or S, hence the legs "C-P" and/or "P-S" are also included. None of these configurations results in using "OSCORE-in-OSCORE". Tiloca & Höglund Expires 13 January 2022 [Page 7] Internet-Draft OSCORE-capable Proxies July 2021 +--------------+-------+-------+-------+-------+ | Conf. name | CF-0 | CF-1 | CF-2 | CF-3 | | (b2, b1, b0) | (000) | (001) | (010) | (011) | +--------------+-------+-------+-------+-------+ | Comm. legs | | | | | | using OSCORE | | C-P | | C-P | | | | | P-S | P-S | +--------------+-------+-------+-------+-------+ C=Client, P=Proxy, S=Server Figure 1: Configurations without end-to-end security. Note that: * CF-0 is the canonical case defined in [RFC7252] with no security at the application layer. * CF-1 is relevant for the use cases UC1 and UC3 in Section 2, where end-to-end security is not provided between client and server(s). Instead, it is not relevant for UC2, since that use case would require secure communication between clients and proxy only when Group OSCORE is also used for end-to-security between the observer clients and the server (see Section 2.2). * CF-2 can be seen as the canonical case of [RFC8613], with P acting as client with S. * CF-3 can be seen as the canonical case of [RFC8613], applied separately to the two legs "C-P" (with P acting as server) and "P-S" (with P acting as client). 3.2. Configurations with End-to-End Security Figure 2 shows the different configurations where OSCORE is used end- to-end by the two application endpoints C and S. That is, all the shown configurations include the leg "C-S", i.e., b2 = 1. In the configurations CF-5, CF-6 and CF-7, the proxy uses OSCORE with C and/or S, hence the legs "C-P" and/or "P-S" are also included. Therefore, these configurations result in double-protecting the CoAP messages originated at C and S, and are thus marked with "(*)" to indicate the use of "OSCORE-in-OSCORE". Tiloca & Höglund Expires 13 January 2022 [Page 8] Internet-Draft OSCORE-capable Proxies July 2021 +--------------+---------+---------+---------+---------+ | Conf. name | CF-4 | CF-5 | CF-6 | CF-7 | | (b2, b1, b0) | (100) | (101) | (110) | (111) | +--------------+---------+---------+---------+---------+ | Comm. legs | C-S | C-S | C-S | C-S | | using OSCORE | | C-P (*) | | C-P (*) | | | | | P-S (*) | P-S (*) | +--------------+---------+---------+---------+---------+ C=Client, P=Proxy, S=Server (*) OSCORE-in-OSCORE Figure 2: Configurations with end-to-end security. Note that: * CF-4 is the canonical case defined in [RFC8613]. * CF-5 is relevant for the use cases UC1, UC2 and UC3 in Section 2. * CF-7 is relevant for the use cases UC2 and UC3 in Section 2. Instead, it is not relevant for UC1, since that would imply that P is also a member of the OSCORE group including the servers, which is not desirable (see Section 2.1). 4. Request Processing This section extends the actions performed to protect an outgoing request, with respect to [RFC8613] or [I-D.ietf-core-oscore-groupcomm] when OSCORE or Group OSCORE is used, respectively. Throughout the text, the configurations defined in Section 3 are also recalled by means of the bits (b2, b1, b0), to indicate the communication leg(s) using OSCORE. The following assumes the presence of a single intermediary acting as CoAP-to-CoAP Forward-Proxy between the origin CoAP client and a single origin CoAP server. 4.1. Protecting the Request at the Client The client performs the following steps. 1. The client prepares the CoAP request REQ for the origin server, which is the intended destination application endpoint. 2. Since the client knows that a proxy is involved as next hop, the client adds the appropriate proxy-related options to the request. Tiloca & Höglund Expires 13 January 2022 [Page 9] Internet-Draft OSCORE-capable Proxies July 2021 3. If the client uses (Group) OSCORE with the origin server (b2 = 1), it performs the following actions. Otherwise, it moves to step 4. * The client protects the request REQ as it normally happens with OSCORE or Group OSCORE, using the Security Context shared with the server. * The result is a protected request REQ* including an OSCORE option. The intended destination OSCORE endpoint is the origin server. * REQ takes REQ*, and the client moves to step 4. 4. If the client uses (Group) OSCORE with the proxy (b0 = 1), it performs the following actions. Otherwise, it moves to step 5. * The client protects the request REQ with (Group) OSCORE, using the Security Context shared with the Proxy. Note that the Proxy-Uri option, if present at this point in time (b2 = 0 and b0 = 1), is first decomposed as per Section 4.1.3.3 of [RFC8613]. Unlike in [RFC8613], the following options are processed as Class E, if present. - Proxy-Scheme, Uri-Host, Uri-Port, Uri-Path and Uri-Query. - OSCORE, which is present if (Group) OSCORE is used between the origin client and the origin server (i.e., b2 = 1 and b0 = 1, hence step 3 above was performed). This is "OSCORE-in-OSCORE" and deviates from [RFC8613]. - Multicast-Signaling Option, defined in [I-D.tiloca-core-groupcomm-proxy]. - Listen-To-Multicast-Responses Option, defined in [I-D.ietf-core-observe-multicast-notifications]. - Any other option that is intended to be accessed and consumed by the proxy. * The result is a protected request REQ** including its own outer OSCORE option, i.e., REQ** = Enc(REQ). The intended destination OSCORE endpoint is the proxy. * REQ takes REQ**, and the client moves to step 5. Tiloca & Höglund Expires 13 January 2022 [Page 10] Internet-Draft OSCORE-capable Proxies July 2021 5. The client sends the request REQ to the proxy. 4.2. Verifying the Request at the Proxy The proxy performs the following steps. 1. The proxy receives the request REQ from the origin client. 2. The proxy assesses which alternative it is. * Alt 2.1 - The request REQ includes proxy-related options as already visible to the proxy (b0 = 0). Hence, the request has to be forwarded to the origin server. In this case, the proxy moves to step 4. Note that: - The request REQ includes an OSCORE option if the proxy is neither the destination application endpoint nor the destination OSCORE endpoint (b2 = 1 and b0 = 0). - The request REQ does not include an OSCORE option if the proxy is not the destination application endpoint and no OSCORE is involved (b2 = 0 and b0 = 0). * Alt 2.2 - The request REQ does not include proxy-related options but it includes an OSCORE option, as visible to the proxy (b0 = 1). Hence, the proxy is the destination OSCORE endpoint. In this case, the proxy moves to step 3. Note that, at this point in time, the proxy does not know yet if it is going to act as proxy by forwarding the request, or if it is instead the actual destination application endpoint. * Alt 2.3 - The request REQ does not include proxy-related options and it does not include an OSCORE option, as visible to the proxy (b2 = 0 and b0 = 0). Hence, the proxy is the destination application endpoint with no OSCORE is involved. In this case, the proxy delivers the request REQ to the application for processing. 3. Coming from alternative 2.2 of step 2, the proxy unprotects the request REQ using the OSCORE Security Context shared with the origin client. Tiloca & Höglund Expires 13 January 2022 [Page 11] Internet-Draft OSCORE-capable Proxies July 2021 In case of an OSCORE-related error, the proxy responds to the client with an unprotected error response. Following a successful processing, i.e. REQ* = Dec(REQ), three alternatives are possible. * Alt 3.1 - The decrypted request REQ* includes proxy-related options. Hence, the request has to be forwarded to the origin server. In this case, REQ takes REQ*, and the proxy moves to step 4. Note that: - If the decrypted request REQ* includes an OSCORE option as well as proxy-related options, then the proxy is not the destination application endpoint, and OSCORE is used end- to-end between the origin client and origin server (b2 = 1 and b0 = 1). This is "OSCORE-in-OSCORE" and deviates from [RFC8613], i.e., under this specific outcome, it is fine for the proxy to find an OSCORE option in the decrypted request REQ*, and the message is not rejected. - If the decrypted request REQ* does not include an OSCORE option, but it includes proxy-related options, then the proxy is not the destination application endpoint, and OSCORE is not used end-to-end between the origin client and origin server (b2 = 0 and b0 = 1). * Alt 3.2 - The decrypted request REQ* does not include an OSCORE option, and it does not include any proxy-related option. Hence, the proxy is the actual destination application endpoint. In this case, the proxy delivers the decrypted request REQ* to the application for processing. The possible following response to the client occurs as per [RFC8613]. * Alt 3.3 - The decrypted request REQ* includes an OSCORE option, but it does not include any proxy-related option. This alternative is not valid, and the proxy MUST respond to the client with an error response. This response MUST be protected with the (Group) OSCORE Security Context shared with the client. 4. The proxy proceeds with the forwarding of the request REQ to the origin server (see Section 4.3). Tiloca & Höglund Expires 13 January 2022 [Page 12] Internet-Draft OSCORE-capable Proxies July 2021 4.3. Forwarding the Request to the Server The proxy performs the following steps. 1. The proxy sets the Request URI in the request REQ, by consuming the Proxy-Uri or the Proxy-Scheme option as per Section 5.7.2 of [RFC7252]. 2. If the proxy uses OSCORE with the origin server (b1 = 1), the proxy performs the following actions. Otherwise, the proxy moves to step 3. * The proxy protects the request REQ with OSCORE, i.e. REQ* = Enc(REQ), using the Security Context shared with the origin server. Unlike in [RFC8613], the OSCORE option, if present in the request REQ to protect, is processed as Class E. This is the case if (Group) OSCORE is used between the origin client and the origin server (b2 = 1 and b1 = 1). This is "OSCORE-in- OSCORE" and deviates from [RFC8613]. * The result is a protected request REQ* including an OSCORE option. The intended destination OSCORE endpoint is the origin server. * REQ takes REQ*, and the proxy moves to step 3. 3. The proxy forwards the request REQ to the origin server. 4.4. Verifying the Request at the Server The server performs the following steps. 1. The server receives the request REQ from the proxy. In the considered scenario, the server is the actual origin server, hence it never encounters proxy-related options when processing the request (i.e., neither as outer nor as inner options). This means that the server is the destination OSCORE endpoint with respect to any OSCORE option it encounters when processing the request. 2. The server assesses which alternative it is. * Alt 2.1 - The request REQ does not include an OSCORE option (b2 = 0 and b1 = 0). Tiloca & Höglund Expires 13 January 2022 [Page 13] Internet-Draft OSCORE-capable Proxies July 2021 If proxy-related options are found at this point in time, this endpoint is not the actual destination application endpoint, and it should follow what described in Section 4.2, if it supports acting as proxy. Otherwise, the server is the destination application endpoint. Hence, the server moves to step 5. * Alt 2.2 - The request REQ includes an OSCORE option (b2 = 1 or b1 = 1). In this case, the server is the destination OSCORE endpoint. Hence, the server moves to step 3. 3. Coming from alternative 2.2 of step 2, the server unprotects the request REQ using the OSCORE Security Context pointed by the OSCORE option, i.e. REQ* = Dec(REQ). In case of an OSCORE-related error, the server responds to the proxy with an unprotected error response. Instead, following a successful processing, the two valid alternatives below are possible. If proxy-related options are found at this point in time, this endpoint is not the actual destination application endpoint. Hence, it should rather follow what described in Section 4.2, if it supports acting as proxy. * Alt 3.1 - The decrypted request REQ* does not include an OSCORE option (b2 XOR b1 = 1). Hence, the server is the destination application endpoint. In this case, REQ takes REQ*, and the server moves to step 5. * Alt 3.2 - The decrypted request REQ* includes an OSCORE option (b2 = 1 and b1 = 1). Hence, since the decrypted request REQ* does not include any proxy-related option, the server is the destination application endpoint, but it has to perform the actual end-to-end OSCORE decryption first. In this case, the server moves to step 4. Note that, this is "OSCORE-in-OSCORE" and deviates from [RFC8613], i.e., under this specific outcome, it is fine for the server to find an OSCORE option in the decrypted message, and the message is not rejected. Tiloca & Höglund Expires 13 January 2022 [Page 14] Internet-Draft OSCORE-capable Proxies July 2021 4. Coming from alternative 3.2 of step 3, the server unprotects the inner request REQ* using the OSCORE Security Context pointed by the OSCORE option in REQ*, i.e. REQ** = Dec(REQ*). If any of the following cases occurs, the server MUST discard the request and MUST reply with an error response, which MUST be protected using the OSCORE Security Context shared with the proxy. * An OSCORE-related error occurred when unprotecting REQ*, i.e. when using the OSCORE Security Context shared with the client. * The decrypted request REQ** includes any proxy-related option. That is, proxy-related options cannot appear after having performed OSCORE decryption twice. * The decrypted request REQ** includes an OSCORE option. That is, at most two layers of OSCORE protection are admitted, i.e. one with the other application endpoint and one with the adjacent transport hop. Otherwise, REQ takes REQ**, and the server moves to step 5. 5. The server delivers the request REQ to the application for processing. The possible following response to the proxy will happen as per [RFC7252], and possibly [RFC8613] or [I-D.ietf-core-oscore-groupcomm]. 5. Response Processing Following up on the process in Section 4, this section extends the actions performed to protect an outgoing response, with respect to [RFC8613] or [I-D.ietf-core-oscore-groupcomm] when OSCORE or Group OSCORE is used, respectively. Throughout the text, the configurations defined in Section 3 are also recalled by means of the bits (b2, b1, b0), to indicate the communication leg(s) using OSCORE. The following assumes the presence of a single intermediary acting as CoAP-to-CoAP Forward-Proxy between the origin CoAP client and a single origin CoAP server. 5.1. Protecting the Response at the Server The server performs the following steps. 1. The server possibly prepares a CoAP response RESP to send to the proxy, to be forwarded to the origin client as intended destination application endpoint. Tiloca & Höglund Expires 13 January 2022 [Page 15] Internet-Draft OSCORE-capable Proxies July 2021 2. The server proceeds as follows. * If the server performed only one OSCORE processing when receiving the request (b2 XOR b1 = 1), it moves to step 3. * If the server performed two OSCORE processings when receiving the request (b2 = 1 and b1 = 1), it moves to step 4. * If the server performed no OSCORE processing when receiving the request (b2 = 0 and b1 = 0), it moves to step 5. 3. The server protects the response RESP using the same OSCORE Security Context used to unprotect the request REQ. The result is a protected response including an OSCORE option, i.e. RESP* = Enc(RESP). Then, RESP takes RESP*, and the server moves to step 5. 4. The server proceeds as follows. * 4.1. The server protects the response RESP using the same OSCORE Security Context used for the second and last processing of the request, i.e. the one shared with the origin client. The result is a protected response including an OSCORE option, i.e. RESP* = Enc(RESP). * 4.2. The server protects the encrypted response RESP* using the same OSCORE Security Context used for the first processing of the request, i.e. the one shared with the proxy as adjacent transport hop. The OSCORE option in the encrypted response RESP* is processed as class E. If present, any other option that is intended to be accessed and consumed by the proxy is also processed as Class E. This is "OSCORE-in-OSCORE" and deviates from [RFC8613]. The result is a protected response including its own outer OSCORE option, i.e. RESP** = Enc(RESP*). 4.3. RESP takes RESP**, and the server moves to step 5. 5. The server sends the response RESP to the proxy. Tiloca & Höglund Expires 13 January 2022 [Page 16] Internet-Draft OSCORE-capable Proxies July 2021 5.2. Verifying the Response at the Proxy The proxy performs the following steps. 1. The proxy receives the response RESP from the origin server. 2. The proxy proceeds as follows. * If the proxy protected the request forwarded to the server by using OSCORE (b1 = 1), it moves to step 3. * If the proxy did not protect the request forwarded to the server by using OSCORE (b1 = 0), it moves to step 4. 3. The proxy proceeds as follows. If the received response RESP is unprotected, the proxy interprets it as an OSCORE-related error at the server. This concerns the OSCORE association between proxy and server, and it is up to the proxy to handle this issue. Otherwise, i.e., the received response RESP includes an outer OSCORE option, the proxy unprotects the response RESP, with the OSCORE Security Context shared with the server. This results in a decrypted response RESP* = Dec(RESP). If the OSCORE protection of the request performed by the proxy did not result in "OSCORE-in-OSCORE" (b2 = 0 and b1 = 1) --- see step 2 of Section 4.3 --- and the decrypted response RESP* includes an OSCORE option, then the proxy MUST discard the response. In any other case, RESP takes RESP*, and the proxy moves to step 4. 4. The proxy forwards the response RESP back to the origin client (see Section 5.3). 5.3. Forwarding the Response to the Client The proxy performs the following steps. 1. The proxy adds possible options to the response RESP to be forwarded. Tiloca & Höglund Expires 13 January 2022 [Page 17] Internet-Draft OSCORE-capable Proxies July 2021 2. If the proxy uses (Group) OSCORE with the client, and the originally received request was protected with the OSCORE Security Context shared with the client (b0 = 1), then the proxy proceeds as follows. * The proxy protects the response RESP with OSCORE, i.e. RESP* = Enc(RESP), using the Security Context shared with the origin client. The following options, if present in the response RESP to protect, are processed as class E: - The OSCORE option. This is the case if (Group) OSCORE is used between the origin client and the origin server (b2 = 1 and b0 = 1). This is "OSCORE-in-OSCORE", which deviates from [RFC8613]. - Any other option that has been added by the proxy, e.g. the Response-Forwarding Option defined in [I-D.tiloca-core-groupcomm-proxy]. * The result is a protected response RESP* including an OSCORE option. The intended destination OSCORE endpoint is the origin client. * RESP takes RESP*, and the proxy moves to step 3. 3. The proxy forwards the response RESP back to the origin client. 5.4. Verifying the Response at the Client The client performs the following steps. 1. The client receives the response RESP from the proxy. 2. The client proceeds as follows. * If the client protected the request with (Group) OSCORE using an OSCORE Security Context shared with the proxy (b0 = 1), it moves to step 3. * If the client did not protect the request with (Group) OSCORE using an OSCORE Security Context shared with the proxy (b0 = 0), it moves to step 4. 3. The client proceeds as follows. If the received response RESP is an unprotected 4.00/4.01/4.02, the client interprets it as an OSCORE-related error at the proxy. This concerns the OSCORE association between client and proxy, Tiloca & Höglund Expires 13 January 2022 [Page 18] Internet-Draft OSCORE-capable Proxies July 2021 and it is up to the client to handle this issue. Information specified in the diagnostic payload, if present, might result in the client taking alternative, more appropriate actions. Otherwise, i.e. the received response RESP includes an outer OSCORE option, the client unprotects the response RESP, with the OSCORE Security Context shared with the proxy. This results in a decrypted response RESP* = Dec(RESP). If the OSCORE protection of the request performed by the client did not result in "OSCORE-in-OSCORE" (b2 = 0 and b0 = 1) --- see step 4 of Section 4.1 --- and the decrypted response RESP* includes an OSCORE option, then the client MUST discard the message and does not perform any further processing. If the OSCORE protection of the request performed by the client resulted in "OSCORE-in-OSCORE" (b2 = 1 and b0 = 1) --- see step 4 of Section 4.1 --- then the decrypted response RESP* may include an OSCORE option. This is "OSCORE-in-OSCORE" and deviates from [RFC8613], i.e., under this specific outcome, it is fine for the client to find an OSCORE option in the decrypted messages, and the message is not rejected. Finally, RESP takes RESP*, and the client moves to step 4. 4. The client proceeds as follows. * If the client did not protect the original CoAP request with (Group) OSCORE using an OSCORE Security Context shared with the origin server (b2 = 0), the client moves to step 5. * If the client protected the original CoAP request with (Group) OSCORE using an OSCORE Security Context shared with the origin server (b2 = 1), the client proceeds as follows. If the response RESP is an unprotected 4.00/4.01/4.02, the client interprets it as an OSCORE-related error at the origin server. This concerns the OSCORE association between client and server, and it is up to the client to handle this issue. Information specified in the diagnostic payload, if present, might result in the client taking alternative, more appropriate actions. Otherwise, i.e. the response RESP includes an OSCORE option, the client unprotects the response RESP, with the OSCORE Security Context shared with the origin server. This results in a decrypted response RESP* = Dec(RESP). Tiloca & Höglund Expires 13 January 2022 [Page 19] Internet-Draft OSCORE-capable Proxies July 2021 The client MUST discard the decrypted response RESP*, in case RESP* is the result of two OSCORE decryptions in a row (b2 = 1 and b0 = 1) and includes an OSCORE option. That is, at most two layers of OSCORE protection are admitted, i.e. one with the other application endpoint and one with the adjacent transport hop. Otherwise, RESP takes RESP*, and the client moves to step 5. 5. The client delivers the response RESP to the application for processing. 6. Response Caching TBD 7. Chain of Intermediaries TBD 8. Security Considerations TBD 9. IANA Considerations This document has no actions for IANA. Acknowledgments The authors sincerely thank Christian Amsuess, Peter Blomqvist and Goeran Selander for the initial discussions that allowed shaping this document. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home (Grant agreement 952652). References Normative References Tiloca & Höglund Expires 13 January 2022 [Page 20] Internet-Draft OSCORE-capable Proxies July 2021 [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, Internet-Draft, draft-ietf- core-oscore-groupcomm-12, 12 July 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . Informative References [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf- core-coap-pubsub-09, 30 September 2019, . [I-D.ietf-core-groupcomm-bis] Dijk, E., Wang, C., and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 04, 12 July 2021, . [I-D.ietf-core-observe-multicast-notifications] Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, "Observe Notifications as CoAP Multicast Responses", Work in Progress, Internet-Draft, draft-ietf-core-observe- Tiloca & Höglund Expires 13 January 2022 [Page 21] Internet-Draft OSCORE-capable Proxies July 2021 multicast-notifications-01, 12 July 2021, . [I-D.tiloca-core-groupcomm-proxy] Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group Communication", Work in Progress, Internet-Draft, draft- tiloca-core-groupcomm-proxy-04, 12 July 2021, . [LwM2M-Core] Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification - Core, Approved Version 1.2, OMA- TS-LightweightM2M_Core-V1_2-20201110-A", November 2020, . [LwM2M-Transport] Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification - Transport Bindings, Approved Version 1.2, OMA-TS-LightweightM2M_Transport- V1_2-20201110-A", November 2020, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . Authors' Addresses Marco Tiloca RISE AB Isafjordsgatan 22 SE-16440 Kista Sweden Email: marco.tiloca@ri.se Tiloca & Höglund Expires 13 January 2022 [Page 22] Internet-Draft OSCORE-capable Proxies July 2021 Rikard Hoeglund RISE AB Isafjordsgatan 22 SE-16440 Kista Sweden Email: rikard.hoglund@ri.se Tiloca & Höglund Expires 13 January 2022 [Page 23]