]> RISE AB

Isafjordsgatan 22 Kista 16440 Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 16440 Sweden rikard.hoglund@ri.se

Internet CoRE Working Group Internet-Draft 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 to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., 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 can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication with intermediaries is used. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) 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 , 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 . The protocol Object Security for Constrained RESTful Environments (OSCORE) 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 . For a number of use cases (see ), 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 CoAP 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 does not define how OSCORE can be used to protect CoAP messages in such communication leg, which would require to consider also the intermediary as an "OSCORE endpoint". This document fills this gap, and updates as follows.

• It defines how to use OSCORE for protecting 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".
• It admits a CoAP message to be secured by multiple, nested OSCORE protections applied in sequence, as an "OSCORE-in-OSCORE" process. For instance, this is the case when the message is OSCORE-protected end-to-end between the origin client and origin server, and the result is 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).

This document does not specify any new signaling method to guide the message processing on the different endpoints. In particular, every endpoint is always able to understand what steps to take on an incoming message depending on the presence of the OSCORE Option, as exclusively included or instead combined together with CoAP options intended for an intermediary. The approach defined in this document can be seamlessly adopted also when Group OSCORE is used, for protecting CoAP messages in group communication scenarios that rely on intermediaries.

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 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 ; OSCORE and Group OSCORE . This document especially builds on concepts and mechanics related to intermediaries such as CoAP forward-proxies. In addition, this document uses 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.
• 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, if such a process is used, a successful decryption/verification of an OSCORE-protected message might yield an OSCORE-protected message.

Use Cases The approach proposed in this document has been motivated by a number of use cases, which are summarized below.

CoAP Group Communication with Proxies CoAP supports also one-to-many group communication, e.g., over IP multicast , which can be protected end-to-end between origin client and origin servers by using Group OSCORE . 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, 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 ). 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.

CoAP Observe Notifications over Multicast The Observe extension for CoAP 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 , multiple clients are interested to observe the same resource at the same server. Hence, 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", against which the following multicast notifications will match. 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 ). 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 ). Like for the use case in , 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.

LwM2M Client and External Application Server The Lightweight Machine-to-Machine (LwM2M) protocol 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 , 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 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 in , 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.

Further Use Cases The approach proposed in this document can be useful also in the following use cases relying on a proxy.

• A server aware of a suitable cross proxy can rely on it as a third-party service, in order to indicate transports for CoAP available to that server (see see ). From a security point of view, it would be convenient if the proxy could provide suitable credentials to the client, as a general trusted proxy for the system. However, in order for OSCORE to be an applicable security mechanism for this, it has to be terminated at the proxy. That is, it would be required for the client and the proxy to share a dedicated OSCORE Security Context and to use it for protecting their communication leg.
• A proxy may be deployed to act as an entry point to a firewalled network, which only authenticated clients can join. In particular, authentication can rely on the used secure communication association between a client and the proxy. If the proxy could share a dedicated OSCORE Security Context with each client, the proxy can rely on it to identify the client, before forwarding its messages to any other member of the firewalled network.
• The approach proposed in this document does not pose a limit to the number of OSCORE protections applied to the same CoAP message. This enables more privacy-oriented scenarios based on proxy chains, where the origin endpoint protects a message using first the OSCORE Security Context shared with the origin server, and then the dedicated OSCORE Security Context shared with each of the different chain hops. Once received at a chain hop, a message would be stripped of the OSCORE protection associated with that hop before being forwarded to the next one.

Message Processing As mentioned in , this document introduces the following two main deviations from the original OSCORE specification .

1. An "OSCORE endpoint", i.e., a producer/consumer of an OSCORE Option can be not only an application endpoint (i.e., an origin client or server), but also an intermediary such as a proxy. Hence, OSCORE can also be used between an origin client/server and a proxy, as well as between two proxies in an intermediary chain.
2. A CoAP message can be secured by multiple OSCORE protections applied in sequence. Therefore, the final result is a message with nested OSCORE protections, as the output of an "OSCORE-in-OSCORE" process. Hence, following a decryption, the resulting message might legitimately include an OSCORE Option, and thus have in turn to be decrypted. The most common case is expected to consider a message protected with up to two OSCORE layers, i.e.: i) an inner layer, protecting the message end-to-end between the origin client and the origin server acting as application endpoints; and ii) an outer layer, protecting the message between a certain OSCORE endpoint and the other OSCORE endpoint adjacent in the intermediary chain. However, a message can also be protected with a higher arbitrary number of nested OSCORE layers, e.g., in scenarios relying on a longer chain of intermediaries. For instance, the origin client can sequentially apply multiple OSCORE layers to a request, each of which to be consumed and removed by one of the intermediaries in the chain, until the origin server is reached and it consumes the innermost OSCORE layer.

General Rules on Protecting Options When a sender endpoint protects an outgoing message by applying the i-th OSCORE layer in sequence, the following CoAP options are also protected, in addition to those already specified as class I or class E in the document defining them.

• An OSCORE Option which is present as the result of the j-th OSCORE layer immediately previously applied, i.e., j = (i-1). Such an OSCORE Option is protected like an option of class E.
• Any option such that both the following conditions hold.
  1. The option is intended to be consumed by the other OSCORE endpoint X sharing the OSCORE Security Context used for applying the i-th OSCORE layer.
  2. The option does not play a role at the other OSCORE endpoint X for correctly processing the message before having removed the i-th OSCORE layer.
  Examples of such options are:
  • The proxy-related options Proxy-Uri, Proxy-Scheme and Uri-* defined in .
  • Listen-To-Multicast-Notifications defined in .
  • Multicast-Timeout, Response-Forwarding and Group-ETag defined in .

One the other hand, when applying the i-th OSCORE layer, an option intended to the endpoint X is not protected if it plays a role for removing the i-th OSCORE layer at that endpoint. Examples of such options are:

• Clearly, and consistently with , the OSCORE option added to the outgoing message as a result of applying the i-th OSCORE layer.
• The EDHOC option defined in , to signal to the endpoint X that part of the message payload has to be extracted and used to complete an ongoing execution of the EDHOC key establishment protocol , before the i-th OSCORE layer can be removed.

Processing an Outgoing Request The rules from apply when processing an outgoing request message, with the following addition. When an application endpoint applies multiple OSCORE layers in sequence to protect an outgoing request, and it uses an OSCORE Security Context shared with the other application endpoint, then the first OSCORE layer MUST be applied by using that Security Context.

Processing an Incoming Request The recipient endpoint performs the following actions on the received request REQ, depending on which of the following three conditions apply.

• A - REQ includes visible proxy-related options. If the endpoint is not configured to be a proxy, it MUST stop processing the request and MUST respond with a 5.05 (Proxying Not Supported) error response to (the previous hop towards) the origin client, as per . This may result in protecting the error response over that communication leg, as per . Otherwise, the endpoint consumes the proxy-related options and forwards REQ to (the next hop towards) the origin server. This may result in (further) protecting REQ over that communication leg, as per .
• B - REQ does not include proxy-related options and does not include an OSCORE Option. If the endpoint does not have an application to handle REQ, it MUST stop processing the request and MAY respond with a 4.00 (Bad Request) error response to (the previous hop towards) the origin client. This may result in protecting the error response over that communication leg, as per . Otherwise, the endpoint delivers REQ to the application.
• C - REQ does not include proxy-related options and includes an OSCORE Option. The endpoint decrypts REQ using the OSCORE Security Context indicated by the OSCORE Option, i.e., REQ* = dec(REQ). After that, the possible presence of an OSCORE Option in the decrypted request REQ* is not treated as an error situation. If the OSCORE processing results in an error, the endpoint MUST stop processing the request and performs error handling as per or Sections and of , in case OSCORE or Group OSCORE is used, respectively. In case the endpoint sends an error response to (the previous hop towards) the origin client, this may result in protecting the error response over that communication leg, as per . Otherwise, REQ takes REQ*, and the endpoint evaluates which of the three conditions (A, B, C) applies to REQ, thus performing again the algorithm defined in this section.

Processing an Outgoing Response The rules from apply when processing an outgoing response message, with the following additions. When an application endpoint applies multiple OSCORE layers in sequence to protect an outgoing response, and it uses an OSCORE Security Context shared with the other application endpoint, then the first OSCORE layer MUST be applied by using that Security Context. The sender endpoint protects the response by applying the same OSCORE layers that it removed from the corresponding incoming request, but in the reverse order than the one they were removed. In case the response is an error response, the sender endpoint protects it by applying the same OSCORE layers that it successfully removed from the corresponding incoming request, but in the reverse order than the one they were removed.

Processing an Incoming Response The recipient endpoint removes the same OSCORE layers that it added when protecting the corresponding outgoing request, but in the reverse order than the one they were removed. When doing so, the possible presence of an OSCORE Option in the decrypted response following the removal of an OSCORE layer is not treated as an error situation, unless it occurs after having removed as many OSCORE layers as were added in the outgoing request. In such a case, the endpoint MUST stop processing the response.

Example TODO: add example with message exchange.

Caching of OSCORE-Protected Responses Although not possible as per the original OSCORE specification , cacheability of OSCORE-protected responses at proxies can be achieved. To this end, the approach defined in can be used, as based on Deterministic Requests protected with the pairwise mode of Group OSCORE used end-to-end between an origin client and an origin server. The applicability of this approach is limited to requests that are safe (in the RESTful sense) to process and do not yield side effects at the origin server. In particular, both the origin client and the origin server are required to have already joined the correct OSCORE group. Then, starting from the same plain CoAP request, different clients in the OSCORE group are able to deterministically generate a same request protected with Group OSCORE, which is sent to a proxy for being forwarded to the origin server. The proxy can now effectively cache the resulting OSCORE-protected response from the server, since the same plain CoAP request will result again in the same Deterministic Request and thus will produce a cache hit. If the approach defined in is used, the following also applies in addition to what is defined in , when processing incoming messages at a proxy that implements caching of responses.

• Upon receiving a request from (the previous hop towards) the origin client, the proxy checks if specifically the message available during the execution of alternative A in produces a cache hit. That is, such a message: i) is exactly the one to be forwarded to (the next hop towards) the origin server if no cache hit is made; and ii) is the result of an OSCORE decryption at the proxy, if OSCORE is used on the communication leg between the proxy and (the previous hop towards) the origin client.
• Upon receiving a response from (the next hop towards) the origin server, the proxy first removes the same OSCORE layers that it added when protecting the corresponding outgoing request, as defined in . Then, the proxy stores specifically that resulting response message in its cache. That is, such a message is exactly the one to be forwarded to (the previous hop towards) the origin client.

The specific rules about serving a request with a cached response are defined in , as well as in for group communication scenarios.

Security Considerations TODO

IANA Considerations This document has no actions for IANA.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. RISE AB Ericsson AB Ericsson AB Ericsson AB Universitaet Duisburg-Essen This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described approach defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Informative References The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. IoTconsultancy.nl InterDigital RISE AB This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB IoTconsultancy.nl This document specifies the operations performed by a proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such a proxy processes a single request sent by a client over unicast, and distributes the request over IP multicast to a group of servers. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. SmartThings Ericsson Ericsson The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. There is work in progress to resolve some of the transfer layer issues by using a more RESTful approach. Please see https://github.com/core-wg/pubsub/blob/master/proposal.txt Ericsson RISE AB RISE AB Fraunhofer AISEC Ericsson The lightweight authenticated key exchange protocol EDHOC can be run over CoAP and used by two peers to establish an OSCORE Security Context. This document further profiles this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first subsequent OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. Ericsson AB Ericsson AB Ericsson AB This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be kept very low. The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] to express alternative transports available to a device, and to optimize exchanges using these. RISE AB Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. Open Mobile Alliance Open Mobile Alliance

OSCORE-protected Onion Forwarding TODO: better elaborate on the listed points below.

• The client can hide its position in the network from the origin server, while still possibly protecting communications end-to-end with OSCORE.
• Use the method defined in to achieve OSCORE-protected onion forwarding, through a chain of proxies (at least three are expected). Every message generated by or intended to the origin client must traverse the whole chain of proxies until the intended other endpoint (typically, the origin server). The chain of proxies has to be known in advance by the client, i.e., the exact proxies and their order in the chain.
• The typical case addressed in this document considers an origin client that, at most, shares one OSCORE Security Context with the origin server and one OSCORE Security Context with the first proxy in the chain. If onion forwarding is used, the origin client shares an OSCORE Security Context with the origin server, and a dedicated OSCORE Security Context with each of the proxies in the chain.
• The origin client protects a request by applying first the OSCORE layer intended to the origin server, then the OSCORE layer intended to the last proxy in the chain, then the OSCORE layer intended to the second from last proxy in the chain and so on, until it applies the OSCORE layer intended to the first proxy in the chain. Before protecting a request with the OSCORE layer to be consumed by a certain proxy in the chain, the origin client also adds proxy-related options intended to that proxy, as indications to forward the request to (the next hop towards) the origin server. Other than the actions above from the client, there should be no difference from the basic approach defined in . Each proxy in the chain would process and remove one OSCORE layer from the received request and then forward it to (the next hop towards) the origin server.
• The exact way used by the client to establish OSCORE Security Contexts with the proxies and the origin server is out of scope. However, if EDHOC is used, it is most convenient for the client to run it with the first proxy in the chain, then with the second proxy in the chain through the first one and so on, and finally with the origin server by traversing the whole chain of proxies. Then, it is especially convenient to use the optimized workflow defined in and based on the EDHOC + OSCORE request. This would basically allow the client to complete the EDHOC execution with an endpoint and start the EDHOC execution with the next endpoint in the chain, by means of a single message sent on the wire.
• Hop-by-hop security has to also be achieved between each pair of proxies in the chain. To this end, two adjacent proxies would better use TLS over TCP than OSCORE between one another (this should be acceptable for non-constrained proxies). This takes advantage of the TCP packet aggregation policies, and thus:
  • As request forwarding occurs in MTU-size bundles, the length of the origin request can be hidden as well.
  • Requests and responses traversing the proxy chain cannot be correlated, e.g., by externally monitoring the timing of message forwarding (which would jeopardize the client's wish to hide itself from anything but the first proxy in the chain).
• Cacheability of responses can still happen, as per and using the approach defined in . The last proxy in the chain would be the only proxy actually seeing the Deterministic Request originated by the client and then caching the corresponding responses from the origin server. It is good that other proxies are not able to do the same, thus preventing what might lead to request-response correlation, again opening for localization of the origin client.
• Possible optimizations along the proxy chains
  • In particular settings involving additional configuration on the client, some proxy in the chain might be a reverse-proxy. Then, such a proxy can be configured to map on one hand the OSCORE Security Context shared with the origin client (and used to remove a corresponding OSCORE layer from a received request to forward) and, on the other hand, the addressing information of the next hop in the chain where to forward the received request to. This would spare the origin client to add a set of proxy-related options for every single proxy in the chain.
  • It is mentioned above to additionally use TLS over TCP hop-by-hop between every two adjacent proxies in the chain. That said:
    • The OSCORE protection of the request has certainly to rely on authenticated encryption algorithms (as usual), when applying the OSCORE layer intended to the origin server (the first one applied by the origin client) and the OSCORE layer intended to the first proxy in the chain (the last one applied by the origin client).
    • For any other OSCORE layer applied by the origin client (i.e., intended for any proxy in the chain but the first one), the OSCORE protection can better rely on an encryption-only algorithm not providing an authentication tag (as admitted in the group mode of Group OSCORE and assuming the registration of such algorithms in COSE).
    • This would be secure to do, since every pair of adjacent proxies in the chain relies on its TLS connection for the respective hop-by-hop communication anyway. The benefit is that it avoids transmitting several unneeded authentication tags from OSCORE.

Acknowledgments The authors sincerely thank Christian Amsuess, Peter Blomqvist and Goeran Selander for their comments and feedback. 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).