OSCORE-capable Proxies

OSCORE-capable Proxies RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden rikard.hoglund@ri.se

Internet CoRE Working Group Internet-Draft When using the Constrained Application Protocol (CoAP), messages exchanged between two endpoints can be protected end-to-end at the application layer by means of Object Security for Constrained RESTful Environments (OSCORE), 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 rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints; and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP Hop-Limit Option. The approach defined in this document can be seamlessly employed also with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. 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 corresponding responses. CoAP also supports group communication scenarios , where clients can send a one-to-many request targeting all servers in the group, e.g., by using IP multicast. Like for one-to-one communication, group settings can also rely on intermediaries, e.g., by using the realization of proxy specified in . The security 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 security protocol Group OSCORE . For a number of use cases (see ), it is required and/or beneficial that communications are secured 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 the 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 also used 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 that communication leg, or how to generally process CoAP messages with OSCORE at an intermediary. In fact, this would also require to consider an 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 "OSCORE endpoints".
It defines rules to escalate the protection of a CoAP option that is originally meant to be unprotected or only integrity-protected by OSCORE. This results in both encrypting and integrity-protecting a CoAP option whenever it is possible.
It admits a CoAP message to be secured by multiple, nested OSCORE protections applied in sequence. For instance, this is the case when the message is OSCORE-protected end-to-end between the origin client and origin server, after which the result is further OSCORE-protected over the leg between the current and next hop (e.g., between the origin client and the adjacent intermediary acting as the next hop towards the origin server).

Furthermore, this document updates , by explicitly defining the CoAP Hop-Limit Option to be of Class U for OSCORE (see ). In the case where the Hop-Limit Option is first added to a request by an origin client instead of an intermediary, this update avoids undesired overhead in terms of message size and ensures that the first intermediary in the chain enforces the intent of the origin client in detecting forwarding loops. This document does not introduce any new signaling to guide the message processing on the different endpoints. Instead, according to the presence of the CoAP OSCORE Option and of other CoAP options intended for an intermediary, every endpoint is always able to understand whether (and how many times in a row) to decrypt an incoming message before possibly forwarding it. The approach defined in this document can be seamlessly employed 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 and reverse-proxies (see ). 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 application endpoint 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 OSCORE endpoint or destination OSCORE endpoint. An OSCORE endpoint is not necessarily also an application endpoint with respect to a certain message.
Hop: an endpoint in the end-to-end path between two application endpoints included.
Proxy-related options: either of the following (set of) CoAP options that a proxy can use to understand where to forward a CoAP request. These CoAP options are defined in , , and .
- The Proxy-Uri Option or the Proxy-Cri Option, possibly in combination with the Uri-Path-Abbrev Option (see ). These are relevant when using a forward-proxy.
- The set of CoAP options comprising the Proxy-Scheme Option or the Proxy-Scheme-Number Option, together with a combination of any among the Uri-Host Option, the Uri-Port Option, and the mutually exclusive Uri-Path Option and Uri-Path-Abbrev Option. This is relevant when using a forward-proxy.
- The set of CoAP options consisting in a combination of any among the Uri-Host Option, the Uri-Port Option, and the mutually exclusive Uri-Path Option and Uri-Path-Abbrev Option, when those are not used together with the Proxy-Scheme Option or the Proxy-Scheme-Number Option. This is relevant when using a reverse-proxy.

This document uses the acronym LAKE, expanded to Lightweight Authenticated Key Exchange, to denote the protocol specified as EDHOC in . Identifiers defined literally in or in IANA registries (e.g., the names of the EDHOC registries themselves) are unchanged.

Message Processing This section defines the processing of CoAP messages with OSCORE. provides a number of examples where the approach defined in this document is used to protect message exchanges.

Deviations from the Original Message Processing This document introduces the following two main deviations from the original OSCORE specification .

An "OSCORE endpoint", as 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 be used between an origin client/server and a proxy, as well as between two proxies in an intermediary chain.
A CoAP message can be secured by multiple OSCORE protections applied in sequence. In such a case, the final result is a message with nested OSCORE protections. Hence, following a decryption at a destination OSCORE endpoint, the resulting message might legitimately include an OSCORE Option and thus has in turn to be decrypted, by the same destination OSCORE endpoint or by a different one along the path towards the destination application endpoint included. 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 that rely on a longer chain of intermediaries. For instance, the origin client can sequentially apply multiple OSCORE layers to a request, with each intermediary in the chain intended to consume one of those until the origin server is reached and it consumes the innermost OSCORE layer. An OSCORE endpoint SHOULD define the maximum number of OSCORE layers that it is able to apply (remove) when processing an outgoing (incoming) CoAP message. The defined limit has to appropriately reflect the security requirements of the application. At the same time, such a limit is typically bounded by the maximum number of OSCORE Security Contexts that can be active at the endpoint as well as by the number of intermediary OSCORE endpoints that have been explicitly set up by the communicating parties. If its defined limit is reached when processing a CoAP message, an OSCORE endpoint MUST NOT perform any further OSCORE processing on that message. If the message is an outgoing request and it requires further OSCORE processing beyond the set limit, the endpoint MUST abort the message sending. If the message is an incoming request and it requires further OSCORE processing beyond the set limit, the endpoint MUST reply with a 4.01 (Unauthorized) error response. The endpoint protects such a response by applying the same OSCORE layers that it successfully removed from the corresponding incoming request, but in the reverse order than the one according to which those layers were removed (see ).

Protection of CoAP Options The following considers a sender endpoint that, when protecting an outgoing message M, applies the i-th OSCORE layer in sequence, by using the OSCORE Security Context that it shares with another OSCORE endpoint X. As usual, the sender endpoint encrypts and integrity-protects the CoAP options included in M that are processed as Class E for OSCORE, as per Sections and of . Per the update made by this document, the sender endpoint MUST perform the procedure defined below for each CoAP option OPT that is included in M and is originally specified only as an outer option (Class U or I) for OSCORE. This procedure does not apply to options that are specified (also) as Class E. Depending on the outcome of this procedure, the sender endpoint processes OPT as per its original Class U or I, or instead as Class E. Before protecting M by using the OSCORE Security Context shared with the other OSCORE endpoint X and applying the i-th OSCORE layer in sequence, the sender endpoint performs the following steps for each CoAP option OPT that is included in M and is originally specified only as an outer option (Class U or I) for OSCORE. provides an overview of these steps through a state diagram. In the following, a recipient endpoint is denoted as a "consumer" of an option OPT if the endpoint is meant to have access to OPT for processing it as appropriate. Note that the sender endpoint can assess some conditions only "to the best of its knowledge". This is due to the possible presence of a reverse-proxy standing for X and whose presence as reverse-proxy is, by definition, expected to be unknown to the sender endpoint.

If the sender endpoint has added OPT to M, then this algorithm moves to Step 2. Otherwise, this algorithm moves to Step 4.
If, to the best of the sender endpoint's knowledge, X is a consumer of OPT, then this algorithm moves to Step 3. Otherwise, this algorithm moves to Step 4.
If, to the best of the sender endpoint's knowledge, X is the immediately next consumer of OPT, then this algorithm moves to Step 5. Otherwise, this algorithm moves to Step 9.
If any of the following conditions holds, then this algorithm moves to Step 6. Otherwise, this algorithm moves to Step 9.
- To the best of the sender endpoint's knowledge, X is the next hop for the sender endpoint; or
- To the best of the sender endpoint's knowledge, the immediately next consumer of OPT is not a hop in between the sender endpoint and X.
If X needs to access OPT before having removed the i-th OSCORE layer or in order to remove the i-th OSCORE layer, then this algorithm moves to Step 9. Otherwise, this algorithm moves to Step 6.
If OPT is the Uri-Host Option or the Uri-Port Option, then this algorithm moves to Step 7. Otherwise, this algorithm moves to Step 8.
If M includes the Proxy-Scheme Option or the Proxy-Scheme-Number Option, then this algorithm moves to Step 8. Otherwise, this algorithm moves to Step 9.
The sender endpoint determines that OPT will be processed as Class E for OSCORE, i.e., both encrypted and integrity-protected. Then, the sender endpoint terminates this algorithm.
The sender endpoint determines that OPT will be processed as per its original Class U or I for OSCORE. Then, the sender endpoint terminates this algorithm.

Compared to what is defined in , a new requirement is introduced for a proxy that acts as an OSCORE endpoint. That is, for each CoAP option OPT included in an outgoing message M that the proxy protects with OSCORE, the proxy has to be able to recognize OPT and thus be aware of the original Class of OPT for OSCORE. If a proxy that acts as an OSCORE endpoint does not recognize a CoAP option included in M, then the proxy MUST stop processing M and performs the following actions:

If M is a request, then the proxy MUST reply with a 4.02 (Bad Option) error response to (the previous hop towards) the origin client.
If M is a response, then the proxy MUST send a 5.02 (Bad Gateway) error response to (the previous hop towards) the origin client.

In either case, this may result in protecting the error response over that communication leg, as per .

Processing of an Outgoing Request The rules from apply when processing an outgoing request message, with the following additions. When a source 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. After that, the source application endpoint further protects the outgoing request, by applying one OSCORE layer for each intermediary with which it shares an OSCORE Security Context. When doing so, the source application endpoint applies those OSCORE layers in the same order according to which those intermediaries are positioned in the chain, starting from the one closest to the other application endpoint and moving backwards towards the one closest to the source application endpoint.

Processing of an Incoming Request Upon receiving a request REQ, the recipient endpoint performs the following steps. provides an overview of these steps through a state diagram.

If REQ includes proxy-related options, this algorithm moves to Step 2. Otherwise, this algorithm moves to Step 5.
If REQ includes either of the following (set) of CoAP options, the endpoint proceeds as defined below. Otherwise, this algorithm moves to Step 3.
- The Proxy-Uri Option or the Proxy-Cri Option, possibly in combination with the Uri-Path-Abbrev Option (see ).
- The Proxy-Scheme Option or the Proxy-Scheme-Number Option, together with a combination of:
  - The Uri-Host Option.
  - The Uri-Port Option.
  - Either the Uri-Path-Abbrev Option, or one or more Uri-Path Options.
In the case that the endpoint is not configured to be a forward-proxy, it stops processing REQ and replies 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, this algorithm moves to Step 4.
Having reached this step, REQ does not include the Proxy-Scheme Option or the Proxy-Scheme-Number Option, but it includes a combination of:
- The Uri-Host Option.
- The Uri-Port Option.
- Either the Uri-Path-Abbrev Option, or one or more Uri-Path Options.
In the case that the endpoint is not configured to be a reverse-proxy, or the request URI from the Uri-Host, Uri-Port, Uri-Path, and Uri-Path-Abbrev Options is not intended to support reverse-proxy functionalities, then this algorithm moves to Step 5. Otherwise, this algorithm moves to Step 4.
The endpoint MUST check whether forwarding REQ to (the next hop towards) the origin server is an acceptable operation to perform, according to the endpoint's configuration and a possible authorization enforcement. This check can be based, for instance, on the specific OSCORE Security Context that the endpoint used to decrypt and verify REQ before performing this step (if applicable). If the check fails, the endpoint MUST stop processing REQ and MUST reply with a 4.01 (Unauthorized) error response to (the previous hop towards) the origin client. This may result in protecting the error response over that communication leg, as per . Instead, if the check succeeds, the following applies.
- In the case that the previous step in the present execution of this algorithm was Step 2, hence the endpoint is meant to process REQ as a forward-proxy, then the endpoint consumes the proxy-related options as per . In particular, the endpoint checks whether the authority component (host and port) of the request URI identifies the endpoint itself. In such a case, REQ has to be treated as a local (non-proxied) request and this algorithm moves to Step 1. Otherwise, the endpoint forwards REQ to (the next hop towards) the origin server according to the request URI, unless differently indicated in REQ, e.g., by means of any of its CoAP options. For instance, a forward-proxy does not forward a request that includes proxy-related options together with the Listen-To-Multicast-Responses Option (see ).
- In the case that the previous step in the present execution of this algorithm was Step 3, hence the endpoint is meant to process REQ as a reverse-proxy, then the endpoint consumes the included Uri-Host, Uri-Port, Uri-Path, and Uri-Path-Abbrev Options, and forwards REQ to (the next hop towards) the origin server, unless differently indicated in REQ, e.g., by means of any of its CoAP options. Note that, when forwarding REQ, the endpoint might not remove the Uri-Path-Abbrev-Option or all the Uri-Path Options originally included, e.g., if the next hop towards the origin server is a reverse-proxy.
In either case, if the endpoint forwards REQ to (the next hop towards) the origin server, this may result in (further) protecting REQ over that communication leg, as per . After that, the endpoint does not take any further action and terminates this algorithm.
If REQ includes an OSCORE Option, this algorithm moves to Step 6. Otherwise, the endpoint proceeds as defined below. In the case that the endpoint does not have an application to handle REQ, it MUST stop processing the request and MAY reply with a 4.04 (Not Found) 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 and terminates this algorithm.
The endpoint decrypts REQ using the OSCORE Security Context CTX indicated by the OSCORE Option. A successful decryption results in the decrypted request REQ*. The possible presence of an OSCORE Option in REQ* is not treated as an error situation. If the endpoint uses policies such as those discussed in , the endpoint retrieves CTX from a specific list of Security Contexts. The endpoint searches for such list by using the source addressing information of REQ, i.e., the addressing information of the (previous hop towards the) origin client. If the OSCORE processing results in an error, the endpoint MUST stop processing REQ and perform error handling as per or Sections and of , in the case that OSCORE or Group OSCORE is used, respectively. If 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, if the OSCORE processing is successful, REQ takes REQ* and this algorithm moves to Step 1.

Policies for Source-Based Processing In general, if a server receives a request protected with an OSCORE Security Context, the server does not need to verify whether the source address of the request matches the one with which the server established that OSCORE Security Context. That is an important feature, because it allows the server to reduce the state that it keeps per Security Context, and it allows the client to seamlessly continue communicating also after having migrated to a different network segment. However, different policies can be used by particularly sensitive servers that rely on protections afforded by reverse-proxies (in particular, the servers considered in ). For example, such servers might associate OSCORE Security Contexts with an outer OSCORE layer that is required to protect incoming requests, in order for those requests to be eligible for decryption and verification with any of those Security Contexts. Implementers of such a distinction should be aware of timing side channels: the server should not first look up an OSCORE Security Context (and, even worse, try using it to decrypt and verify the incoming request), and then verify whether the Security Context is eligible to use according to the source addressing information of the request. Instead, per-source-address lists of Security Contexts should be maintained. This ensures that, when a request is ineligible to be decrypted and verified, the server replies with an appropriate 4.01 (Unauthorized) error response through the same code path that is considered when an OSCORE Security Context is not found. Also, this helps keep separate name spaces of OSCORE Sender/Recipient IDs, which would otherwise leak information.

Processing of an Outgoing Response The rules from apply when processing an outgoing response message, with the following additions. 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 according to which those layers were removed. It follows that, when a source 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 is applied by using that Security Context. If 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 according to which those layers were removed.

Partial IV in the OSCORE Option When protecting an outgoing response, a source OSCORE endpoint MUST include its Sender Sequence Number as Partial IV in the response and use it to build the nonce to protect the response, except when sending the first response to the corresponding request, in which case the Partial IV in the response MAY be omitted. This holds for each OSCORE layer that the source OSCORE endpoint applies to protect the outgoing response. If the source OSCORE endpoint is the origin server, what is described above is in fact already guaranteed:

When the response is protected with Group OSCORE (see Sections , , and of ).
When the response is protected with OSCORE and it is an Observe notification (see ). Note that, when OSCORE is used, sending Observe notifications is the only way for the origin server to send multiple responses to the same request.

If the source OSCORE endpoint is not the origin server but rather a proxy, there are circumstances by which the OSCORE endpoint might send multiple responses to the same request, even though they are protected with OSCORE and they are not Observe notifications. A relevant example is the setup where a proxy receives a unicast request from the origin client, and it forwards the request to a group of origin servers, e.g., over IP multicast . The specification defines a realization of such proxy, which collects the individual responses from the origin servers and relays those responses back to the origin client. That is, all such responses are sent by the proxy as replies to the same unicast request that the origin client sent to the proxy. Just like for that request, each response can be protected with Group OSCORE end-to-end between the replying origin server and the origin client, as well as with OSCORE between the proxy and the origin client.

Processing of 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 according to which those layers were added. 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 corresponding outgoing request. In such a case, the endpoint MUST stop processing the response.

Partial IV in the OSCORE Option There are circumstances by which, after sending a request, the sender endpoint might receive multiple responses as replies from a given other endpoint. For example, this is the case:

When the request is an Observe request .
When the request is sent to a group of recipients, e.g., over IP multicast .
When the request is sent to a proxy, which forwards the request to a group of recipients (e.g., over IP multicast), and then relays their responses back .

In either case, the sender endpoint willingly opts-in for receiving multiple responses to the same request. In practice, such an indication can rely on: including the CoAP Observe Option in the request ; sending the request as addressed to a group of recipients (e.g., to an IP multicast address) ; including the CoAP Multicast-Timeout Option in the unicast request sent to a proxy, which forwards the request to a group of recipients ; or a combination of such means. When processing an incoming response to a request that could elicit multiple responses, a destination OSCORE endpoint MUST only accept for that request at most one response without Partial IV from each source OSCORE endpoint, and treat it as the oldest response for that request from that source OSCORE endpoint. In the following cases, what is described above is in fact already guaranteed:

The source OSCORE endpoint protected the response with Group OSCORE (see ).
The source OSCORE endpoint protected the response with OSCORE, and the response is an Observe notification (see ).

The requirement defined above additionally covers the case where the source OSCORE endpoint protected the response with OSCORE and Observe is not used. Note that having multiple such responses to the same request implies that the source OSCORE endpoint is not an origin server. The same example mentioned in holds as relevant, with an origin client using OSCORE to protect a unicast request to a proxy, which forwards the request to a group of origin servers and relays the collected responses back to the origin client.

Replay Protection and Ordering of Responses The following applies when the destination OSCORE endpoint that receives the response is specifically the destination application endpoint (i.e., the origin client) and the OSCORE layer to remove from the response was applied by a source OSCORE endpoint that is specifically a source application endpoint (i.e., an origin server):

If OSCORE is used to remove the OSCORE layer, the processing of the response in terms of replay protection and ordering occurs according to the method specified in Sections , , and of .
If Group OSCORE is used to remove the OSCORE layer, the processing of the response in terms of replay protection and ordering occurs according to the method specified in .

Instead, the following applies in any other case, i.e., when the source OSCORE endpoint A that applied the OSCORE layer to remove and the destination OSCORE endpoint B are not both application endpoints: Irrespective of whether OSCORE or Group OSCORE is used to remove the OSCORE layer, the processing of the response in terms of replay protection and ordering occurs according to the method specified in , with the following differences:

The "server" in corresponds to the source OSCORE endpoint A that applied the OSCORE layer to remove from the response.
The "client" in corresponds to the destination OSCORE endpoint B that has to remove the OSCORE layer from the response.
The "long exchange" in is further generalized to encompass a message exchange such that: the exchange pertains to the request to which the response under processing replies to; and, when previously sending the request, the destination OSCORE endpoint B willingly opted-in for receiving multiple responses to that request (e.g., see the circumstances compiled in of the present document).
The destination OSCORE endpoint B does not stop processing a response solely on the basis that the Partial IV of the response (when included) is not greater than the Response Number associated with the source OSCORE endpoint A in the message exchange.

OSCORE Processing of the Hop-Limit Option The CoAP Hop-Limit Option is defined in and can be used to detect forwarding loops through a chain of proxies. The first proxy in the chain that understands the option can include it in a received request (if not already present therein), then sets the option value to a proper integer value specifying the desired maximum number of hops, and finally forward the request to the next hop. Any following proxy that understands the option decrements the option value and forwards the request if the new value is different from zero, or it returns a 5.08 (Hop Limit Reached) error response otherwise. does not define how the Hop-Limit Option is processed by OSCORE. As a consequence, the default behavior specified in applies, i.e., the Hop-Limit Option has to be processed as Class E for OSCORE. However, this results in additionally and unjustifiably increasing the size of OSCORE-protected CoAP messages, in the case that the origin client is the first endpoint to add the Hop-Limit Option in a CoAP request. In the typical scenario where the origin client and the origin server share an OSCORE Security Context, the origin client including the Hop-Limit Option in a request will also protect that option when protecting the request end-to-end for the origin server, per the default processing mentioned above. After that, the origin client sends the request to its adjacent proxy in the chain, which will add an outer Hop-Limit Option to be effectively considered from then on as the message is forwarded towards the origin server. This undesirably prevents the first proxy in the chain from enforcing the intent of the origin client, which was presumably in the position to specify a better initial value for the Hop-Limit Option. While this does not fundamentally prevent the detection of forwarding loops, it is conducive to deviations from the intention of the origin client. Moreover, it results in undesired overhead due to the presence of the inner Hop-Limit Option included by the client. That inner option will not be visible by the proxies in the chain and therefore will serve no practical purpose, but it will still be conveyed within the request as this traverses each hop towards the origin server. In order to prevent that by construction, this section updates by explicitly defining the Hop-Limit Option to be of Class U for OSCORE. Therefore, with reference to the scenario discussed above, the origin client does not protect the Hop-Limit Option when protecting the request end-to-end for the origin server, thus allowing the first proxy in the chain to see and process the Hop-Limit Option as expected. When OSCORE is used at proxies like it is defined in this document, the process defined in seamlessly applies also to the Hop-Limit Option. Therefore, in a scenario where the origin client also shares an OSCORE Security Context with the first proxy in the chain, the origin client does not protect the Hop-Limit Option end-to-end for the origin server, but it does protect the option when protecting the request for that proxy by means of their shared OSCORE Security Context.

Caching of OSCORE-Protected Responses Although it is not possible as per the original OSCORE specification , effective 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 to process (in the REST sense) and that do not yield side effects at the origin server. In particular, this approach requires both the origin client and the origin server 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 the same Deterministic Request protected with Group OSCORE, which is sent to a proxy for being forwarded to the origin server. The proxy can 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 at the proxy. When using this approach, the following also applies in addition to what is defined in and , 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 Step 4 in produces a cache hit. That is, such a message: i) is the one to be forwarded to (the next hop towards) the origin server, if no cache hit occurs; and ii) is the result of an OSCORE decryption and verification 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 stored message is the one to be forwarded to (the previous hop towards) the origin client.

The above is orthogonal to the actual process of serving a request with a cached response, for which rules are defined in as well as in for group communication scenarios. When using the realization of proxy for group communication specified in , such rules are further specialized in .

Establishment of OSCORE Security Contexts Like the original OSCORE specification , this document is not devoted to any particular approach that two OSCORE endpoints use for establishing an OSCORE Security Context. At the same time, the following applies, depending on the two peers using OSCORE or Group OSCORE to protect their communications.

When using OSCORE, the establishment of the OSCORE Security Context can rely on the Lightweight Authenticated Key Exchange (LAKE) protocol . Assuming that OSCORE has to be used between the two origin application endpoints as well as between the origin client and the first proxy in the chain, it is expected that the origin client first runs LAKE with the first proxy in the chain and then with the origin server through the chain of proxies (see the example in ). Furthermore, the additional use of the combined LAKE + OSCORE request defined in (denoted therein as "EDHOC + OSCORE request") is particularly beneficial in this case (see the example in ) and especially when relying on a long chain of proxies.
The use of Group OSCORE is expected to be limited between the origin application endpoints, e.g., between the origin client and multiple origin servers. In order to join the same OSCORE group and obtain the corresponding Group OSCORE Security Context, those endpoints can use the approach defined in and based on the Authentication and Authorization for Constrained Environments (ACE) framework . For the purposes of this document, there is no need for a proxy to also be a member of the OSCORE group whose Group OSCORE Security Context is used by the origin application endpoints for protecting communications end-to-end.

Guidelines for Proxies When considering an intermediary chain between an origin client and an origin server, all proxies except for the one adjacent to the origin server are expected to be configured as to the establishment and use of OSCORE with the next hop towards the origin server. Such a configuration might not be as practical and feasible to enforce for a proxy P adjacent to an origin server S. That is, before forwarding a request to S, P might have to dynamically determine whether to establish an OSCORE Security Context with S (if none is established already) and whether to use it for protecting the request. The rest of this section provides guidelines that P can follow in order to determine when to try to establish an OSCORE Security Context with S and when to use an OSCORE Security Context shared with S. In order to come to such a determination, P can answer the following three questions. For all of them, the default answer is "no".

Q1: Does S wish to use (Group) OSCORE between itself and an adjacent proxy? For example, P can answer this question by relying on the SvcParamKey "oscore-with-proxy" within a DNS SVCB Resource Record (RR) , which is retrieved from a DNS response that P obtains in reply to a DNS query about S. For the SvcParamKey "oscore-with-proxy", the presentation and wire-format values MUST be empty. When the SvcParamKey "oscore-with-proxy" is specified in an SVCB RR about S, it indicates that S wishes to use (Group) OSCORE between itself and an adjacent proxy. The SvcParamKey "oscore-with-proxy" is registered in .
Q2: Does S support the use of multiple, nested OSCORE layers? For example, P can answer this question by relying on the SvcParamKey "nested-oscore" within a DNS SVCB RR, which is retrieved from a DNS response that P obtains in reply to a DNS query about S. For the SvcParamKey "nested-oscore", the presentation and wire-format values MUST be empty. When the SvcParamKey "nested-oscore" is specified in an SVCB RR about S, it indicates that S supports the use of multiple, nested OSCORE layers, i.e., S is able to handle messages that are protected by at least two OSCORE layers as defined in this document. The SvcParamKey "nested-oscore" is registered in . The SvcParamKey "nested-oscore" does not indicate how many nested OSCORE layers S supports exactly, which is in principle possible to express in an SVCB RR. In fact, it is already the case that S has to be configured with the maximum number of OSCORE layers that it is able to apply (remove) when processing an outgoing (incoming) CoAP message (see ).
Q3: Does S support the key exchange protocol LAKE ? For example, P can answer this question by using the means specified in that are not used during a LAKE session itself.

The examples above are not exhaustive and P can rely on alternative means to answer the three questions about S. Once P has the answers to the questions Q1, Q2, and Q3, then P can determine when to try to establish an OSCORE Security Context with S and when to use an OSCORE Security Context shared with S, as shown in the state diagram in .

Establishment and Use of OSCORE between a Proxy and an Origin Server | Forward the request to S |<--------+ | | | | | +-----+ +----------------------------+ | | ^ ^ ^ | | | | | | | | | | | | | | | | | YES | | | | v | | | | +---------------------+ | +------+-------+ | | | After that P has | | | Protect the | | | | completed all the | | | request with | | | | decryptions and | | | CTX_P_S | | | | verifications on | | +--------------+ | | | the request, does | | ^ ^ | | | the request include | | | | | | | an OSCORE Option? | | | | | | +---------------------+ | | | YES | NO | | | | | | | | | NO | YES | | +-----+----+ | | | | | | | | | | | | | | | Success? +---+ | | | | | | | | | v | | +----------+ | | +-----+ | | ^ | | | | NO | | | | | | Q2? +---------+ | | | | | | | +-----+----+ | | +-----+ | | Run LAKE | | | | | | with S | | | | YES | +----------+ | v v | ^ | +-------------------+ | | | | | YES | | YES | | Is P currently +------------+ | | | sharing an OSCORE | +--+--+ | | Security Context | NO | | NO | | CTX_P_S with S? +------------------->| Q3? +-----------------+ | | | | +-------------------+ +-----+ ]]> If P is considering using Group OSCORE with the server S or with a set of origin servers comprising S, then the same as shown in applies, with the following differences:

CTX_P_S denotes a Group OSCORE Security Context that P can use to protect the request over the communication leg between itself and the origin server(s).
The steps "Q3?", "Run LAKE with S", and "Success?" are replaced by P joining the correct OSCORE group. A successful group joining results in P establishing CTX_P_S, while a failure results in forwarding the request to the origin server(s) without P protecting the request using Group OSCORE.

CoAP Header Compression with SCHC The method defined in this document enables the possible protection of the same CoAP message with multiple, nested OSCORE layers. Especially when that happens, it is desirable to compress the header of protected CoAP messages, in order to improve performance and ensure that CoAP is usable also in Low-Power Wide-Area Networks (LPWANs). To this end, it is possible to use the Static Context Header Compression and fragmentation (SCHC) framework . In particular, specifies how to use SCHC for compressing headers of CoAP messages, also when messages are protected with OSCORE. The SCHC Compression/Decompression is applicable also in the presence of CoAP proxies and especially in the two following cases.

If OSCORE is not used at all, the SCHC processing occurs hop-by-hop, by relying on SCHC Rules that are consistently shared between two adjacent hops, i.e., by relying on a SCHC Context shared by the SCHC Instances hosted at the two adjacent hops and taking part in the same SCHC Session.
If OSCORE is used only end-to-end between the application endpoints, then an Inner SCHC Compression/Decompression and an Outer SCHC Compression/Decompression are performed (see ). In particular, the following holds. The SCHC processing occurs end-to-end as to the Inner SCHC Compression/Decompression, by relying on Inner SCHC Rules that are consistently shared between the two application endpoints acting as OSCORE endpoints and sharing the OSCORE Security Context used. The Inner SCHC Rules belong to a SCHC Context shared end-to-end by the SCHC Instances hosted at the two application endpoints and taking part in the same SCHC Session. Instead, the SCHC processing occurs hop-by-hop as to the Outer SCHC Compression/Decompression, by relying on Outer SCHC Rules that are consistently shared between two adjacent hops, i.e., by relying on a per-leg SCHC Context shared by the SCHC Instances hosted at the two adjacent hops and taking part in a distinct SCHC Session.

When using the method defined in this document, thus enabling also an intermediary proxy to be an OSCORE endpoint, the SCHC processing above is generalized as specified below. When processing an outgoing CoAP message, a sender endpoint proceeds as follows.

The sender endpoint performs one Inner SCHC Compression for each OSCORE layer applied to the outgoing message. Each Inner SCHC Compression occurs before protecting the message with that OSCORE layer and relies on the Inner SCHC Rules that are consistently shared with the other OSCORE endpoint. The Inner SCHC Rules belong to a SCHC Context shared by the SCHC Instances hosted at the two OSCORE endpoints and communicating using a SCHC Session.
The sender endpoint performs exactly one Outer SCHC Compression. This occurs after having performed all the intended OSCORE protections of the outgoing message and relies on the Outer SCHC Rules that are consistently shared with the (next hop towards the) destination application endpoint. The Outer SCHC Rules belong to a SCHC Context shared by the SCHC Instances hosted at the two adjacent hops and communicating using a SCHC Session.

That is, with respect to the SCHC Compression/Decompression processing, the following holds. An Inner SCHC Compression is intended for a destination OSCORE endpoint, which performs the following steps.

It decrypts an incoming message with the OSCORE Security Context shared with the other OSCORE endpoint.
It performs the corresponding Inner SCHC Decompression, by relying on the Inner SCHC Rules shared with the other OSCORE endpoint.

An Outer SCHC Compression is intended for the (next hop towards the) destination application endpoint, which performs the following steps.

It performs the Outer SCHC Decompression on an incoming message, by relying on the Outer SCHC Rules shared with the previous hop towards the destination application endpoint.
Unless it is the destination application endpoint, it performs a new Outer SCHC Compression after having performed all the intended OSCORE protections of an outgoing message, by relying on the Outer SCHC Rules shared with the (next hop towards the) destination application endpoint. Then, it sends the result to the (next-hop towards the) destination application endpoint.

Note that the generalization above does not alter the core approach, design choices, and features of the SCHC Compression/Decompression applied to CoAP headers.

Implementation Status Note to RFC Editor: when deleting this section, please also delete RFC 7942 from the references of this document. (Boilerplate as per :) This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Implementation #1

Author: Lucas Åhl
Responsible organization: RISE Research Institutes of Sweden AB
Implementation's name: OSCORE-capable proxy for Eclipse Californium
Available at: https://github.com/rikard-sics/californium/tree/oscore_capable_proxies
Description: Implementation in Java, building on Eclipse Californium, see:
- https://github.com/eclipse-californium/californium
- http://eclipse.dev/californium/
Implementation's level of maturity: prototype
The implementation provides the client, the OSCORE-capable forward-proxy, and the server. OSCORE is supported:
- Between a client and a server (end-to-end through a proxy); and/or
- Between a client and an OSCORE-capable forward-proxy; and/or
- Between an OSCORE-capable forward-proxy and a server.
Supported use also together with other features from the same codebase:
- CoAP Observe , when independently using OSCORE or not in any of the communication legs above.
- For any pair of OSCORE endpoints above, an OSCORE Security Context can be dynamically established by running LAKE .
Version compatibility: From version -07 onwards.
Licensing: according to the same dual license of Eclipse Californium, i.e., according to the "Eclipse Distribution License 1.0" and the "Eclipse Public License 2.0". See:
- https://github.com/eclipse-californium/californium/blob/main/LICENSE
- https://www.eclipse.org/org/documents/edl-v10.php
- https://www.eclipse.org/legal/epl-2.0/
Contact information: Rikard Höglund - rikard.hoglund@ri.se
Information last updated on: 2026-10-19

Implementation #2

Author: Manassanan Vongprai
Responsible organization: RISE Research Institutes of Sweden AB
Implementation's name: OSCORE-capable proxy for Contiki-NG
Available at: https://github.com/rikard-sics/contiki-ng/tree/oscore_capable_proxies
Description: Implementation in Contiki-NG, see:
- https://github.com/contiki-ng/contiki-ng
- https://www.contiki-ng.org/
Implementation's level of maturity: prototype
The implementation provides the client and the server. OSCORE is supported:
- Between a client and a server (end-to-end through a proxy); and/or
- Between a client and an OSCORE-capable forward-proxy (externally provided).
Version compatibility: From version -07 onwards.
Licensing: according to "3-clause BSD" license. See:
- https://github.com/contiki-ng/contiki-ng/blob/develop/LICENSE.md
Contact information: Rikard Höglund - rikard.hoglund@ri.se
Information last updated on: 2026-10-19

Interoperability The two implementations mentioned in and have successfully completed interoperability tests. The scenarios considered during the interoperability tests are as follows:

Java client and Java server
Java client and Contiki-NG server
Contiki-NG client and Java server
Contiki-NG client and Contiki-NG server

For every test scenario:

The Java OSCORE-capable forward-proxy is deployed between the client and the server.
The client and the server share an OSCORE Security Context CTX_C_S.
The client and the forward-proxy share an OSCORE Security Context CTX_C_P.
The client sends requests to a target resource hosted at the server, through the forward-proxy. The server replies to every request by sending a response.
All requests and responses are protected with OSCORE as follows:
- With CTX_C_S (innermost layer) and with CTX_C_P (outermost layer) when transferred over the communication leg between the client and the proxy.
- With CTX_C_S (single layer) when transferred over the communication leg between the proxy and the server.

Operational Considerations This section compiles the operational considerations that hold for this document.

Logging In some use cases, it can be desirable that a proxy produces timestamped logs about the successful or failed forwarding of a request to (the next hop towards) the intended application endpoint(s). An attempted request forwarding can be effectively characterized by the transport-specific information of the request to forward that the proxy receives from (the previous hop towards) the source application endpoint and of the request forwarded to (the next hop towards) the intended application endpoint(s), together with the secure communication associations used by the proxy in the two communication legs. Although log entries are produced by the proxy, the storage, management, controlled sharing, and disposal of logs could be entrusted to a designated storage point that can be the proxy itself or instead a separate trusted entity. Besides what is compiled above, the proxy could produce additional information to log. Further details about what the proxy logs, with what granularity, and based on what triggering events and conditions are application-specific and left to operators to define. Like for possible logging occurring at the application endpoints, the proxy MUST NOT log any secret or confidential information pertaining to its forwarding operations. For example, this includes information from its (Group) OSCORE Security Contexts such as the OSCORE Master Secret and keying material derived thereof, or own private keys associated with its authentication credentials used for establishing secure communication associations with other hops. It is up to the application to specify for how long a log entry is retained from the time of its creation and until its deletion. Different retention policies could be enforced, for example, depending on the successful/failed request forwarding, the transport-specific information of the adjacent hops, or the secure communication association shared with other hops. For a given set of log entries that are grouped together according to certain criteria, the oldest log entries are expected to be those deleted first. It is out of the scope of this document what specific semantics and data model are used by the proxy for producing and processing the logs. Specific semantics and data models can be defined by applications and future specifications. It is expected that the logs produced are made available for secure access by authorized external management applications and operators. In particular, logged information could be retrieved in the following ways.

By accessing logs at the designated storage point through polling. This can occur in an occasional, regular, or event-driven way.
Through notifications sent by the designated storage point according to an operator-defined frequency.
Through notifications asynchronously sent by the designated storage point, throttling them in order to prevent congestion and duplication and to not create attack vectors.

From the perspective of an individual management application or network operator, knowledge gained from the logged information can be useful for planning, adjusting, and (fine-)tuning the allocation of network resources, including the amount of available proxies. Also, it can help understand and possibly troubleshoot the reasons why a proxy has failed to forward certain incoming requests. For example, a request to forward could have been received from a legitimate hop that, contrary to expectation, the proxy fails to identify among those included in an allow-list as a prerequirement to forward the request. Some of the logged information can be privacy-sensitive. This especially holds for the metadata about application endpoints, i.e., their addressing information and, when applicable, (identifiers of) their authentication credentials that are used to authenticate with the proxy when establishing and using a secure communication association. If external management applications and operators obtain such metadata, they become able to track a given application endpoint, as to its interactions with one or multiple other application endpoints. Therefore, the logged information that is effectively provided to external management applications and operators SHOULD be redacted by the designated storage point, by omitting any privacy-sensitive information element that could enable or facilitate the impairment of application endpoints' privacy, e.g., by tracking origin clients as they interact with different origin servers. Exceptions could apply, e.g., if the designated storage point can verify that the management application or operator in question is specifically authorized to obtain such privacy-sensitive information and appropriately entitled to obtain it according to enforced privacy policies.

Management and Distribution of Keying Material The approaches used to manage and distribute keying material depend on whether any two OSCORE endpoints use OSCORE or Group OSCORE. If OSCORE is used, the two OSCORE endpoints can establish an OSCORE Security Context in different ways, e.g., by using the key exchange protocol LAKE . While sharing a still valid OSCORE Security Context, the two OSCORE endpoints could update it, for example by running a key update protocol such as Key Update for OSCORE (KUDOS) . If Group OSCORE is used, the management and distribution of the keying material used in the OSCORE group is entrusted to the Group Manager that is responsible for the group (see . A possible realization of Group Manager is the one defined and based on the ACE framework .

Access Control The enforcement of access control at a proxy makes it possible that only certain origin clients are able to have their requests proxied towards the targeted origin server(s). In order to enforce such access control, it is fundamentally required that a proxy receiving a request to forward has a secure communication association with the origin client and/or with the request sender when those are not the same. This allows the proxy to authenticate the hops that originate/send a request to forward, and to verify whether they are in an allow-list. Depending on the result of such verification, the proxy can unconditionally forward or not forward the request, or instead forward the request according to specific forwarding and traffic policies that apply to the identified originator/sender of the request. If unable to authenticate the originator/sender of the request, the proxy can be configured to unconditionally forward or not forward the request, or instead to forward the request according to rate limits, potentially taking into account the source-addressing information of the request sender. The enforcement of access control at proxies complements but does not replace the enforcement of access control at an origin server for accessing its target resources. In order to enforce access control for an origin client accessing a target resource, it is fundamentally required that secure communication is used between such a requesting client and the origin server hosting the resource. When receiving a request protected by the requesting client, the origin server can enforce access control after having successfully authenticated the requesting client, according to the access rights that are granted to the client's identity. In particular, access control at the origin server can be enforced by using the ACE framework , with a granularity that takes into account the resource specifically targeted at the origin server, the operation requested by sending a request to that resource, and the specific permission(s) that the requesting client is authorized to have according to its corresponding access token. Furthermore, the interactions between the requesting client and the origin server are secured as per the specific transport profile of ACE used, for example , , or .

Security Considerations The same security considerations about CoAP and group communication for CoAP apply to this document. The same security considerations from and apply to this document, when using OSCORE or Group OSCORE to protect exchanged messages. Further security considerations to take into account are inherited from the specific CoAP options, extensions, and methods that are used when relying on OSCORE or Group OSCORE. This document does not change the security properties of OSCORE and Group OSCORE. That is, given any two OSCORE endpoints, the method defined in this document provides them with the same security guarantees that OSCORE and Group OSCORE provide in the case where such endpoints are specifically application endpoints. If Group OSCORE is used over a communication leg and the group mode is used to apply a protection layer to a message over that leg (see ), then all the members of the OSCORE group that support the group mode are able to remove that protection layer, i.e., to accordingly decrypt and verify the message. Therefore, the OSCORE group should only include OSCORE endpoints for which that is acceptable.

Preserving Location Anonymity As discussed in , a particularly sensitive server might use policies with strict criteria about what makes an OSCORE-protected request eligible to be decrypted and verified. When a server using such policies receives an OSCORE-protected request (see Step 6 in ), the server proceeds only if the necessary OSCORE Security Contexts are not only available to use, but also present in a local list of OSCORE Security Contexts that are usable to decrypt a request from the alleged request sender. This is particularly relevant for an origin server that expects to receive messages protected end-to-end by origin clients, but only if sent by a reverse-proxy as its adjacent hop. In such a setup, that check prevents a malicious sender endpoint C from associating the addressing information of the origin server S with the OSCORE Security Context CTX that C and S are sharing. Making such an association would compromise the location anonymity of the origin server, as otherwise afforded by leveraging the reverse-proxy. That is, if C gains knowledge of some addressing information ADDR, then C might send a request directly addressed to ADDR and protected with CTX. A response protected with CTX would prove that ADDR is in fact the addressing information of S. However, after performing and failing the check on the received request, S replies with a 4.01 (Unauthorized) error response that is not protected with CTX, hence preserving the location anonymity of the origin server.

Hop-Limit Option of this document defines that the Hop-Limit Option is of Class U for OSCORE. This overrides the default behavior specified in , according to which the option would be processed as Class E for OSCORE. As discussed in , applying the default behavior would result in the Hop-Limit Option added by the origin client being protected end-to-end for the origin server. That is, the intention of the client about performing a detection of forwarding loops would be hidden even from the first proxy in the chain, which in turn adds an outer Hop-Limit Option and thus further contributes to increasing the message size (see ). Instead, having defined the Hop-Limit Option as Class U for OSCORE, the following holds by virtue of the procedure defined in .

If the origin client and the origin server share an OSCORE Security Context, the client protects the option end-to-end for the server only when sending a request to the server directly (i.e., not via a proxy).
If the origin client and the first proxy in the chain share an OSCORE Security Context, then the client protects the option for the proxy, while also avoiding the downsides resulting from the default behavior mentioned above. Otherwise, unless the communication leg between the origin client and the first proxy in the chain relies on another secure association (e.g., a DTLS connection ), the Hop-Limit Option included in a request sent to the proxy will be unprotected. Fundamentally, this is not worse then when applying the default behavior mentioned above. In that case, the origin client would not be able to provide the proxy with its intention as to detecting forwarding loops, while an active on-path adversary would be able to tamper with the request and add an outer Hop-Limit Option with a fraudulent value for the proxy to use.

More generally, if any two adjacent hops share an OSCORE Security Context, then the Hop-Limit Option will be protected with OSCORE in the communication leg between those two hops. If the Hop-Limit Option is transported unprotected over the communication leg between two hops, then the following applies.

A passive on-path adversary can read the option value. By possibly relying on other information such as the option value read in other communication legs, the adversary might be able to infer the topology of the network and the path used for delivering requests from the origin client.
An active on-path adversary can add or remove the option, or alter its value. Adding the option allows the adversary to trigger an otherwise undesired process for detecting forwarding loops, e.g., as an attempt to probe the topology of the network. Removing the option results in undetectably interrupting the ongoing process for detecting forwarding loops, while altering the option value undetectably interferes with the natural progress of such an ongoing process.

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

CoAP Option Numbers Registry IANA is asked to add this document as an additional reference for the Hop-Limit Option in the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.

DNS SVCB Service Parameter Keys (SvcParamKeys) IANA is asked to add the following entries to the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry within the "DNS Service Bindings (SVCB)" registry group.

Number: TBD1
Name: oscore-with-proxy
Meaning: Supported use of (Group) OSCORE with an adjacent proxy
Change Controller: IETF
Reference: [RFC-XXXX, ]

Number: TBD2
Name: nested-oscore
Meaning: Supported use of nested OSCORE layers
Change Controller: IETF
Reference: [RFC-XXXX, ]

References Normative References The Constrained Application Protocol (CoAP) 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. Object Security for Constrained RESTful Environments (OSCORE) 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. SCHC: Generic Framework for Static Context Header Compression and Fragmentation This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. Constrained Application Protocol (CoAP) Hop-Limit Option The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Service Binding Mapping for DNS Servers The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. Group Object Security for Constrained RESTful Environments (Group OSCORE) RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol 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 each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. Constrained Resource Identifiers Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) RISE AB IMT Atlantique IRISA Consultant This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices, and it uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. URI Path abbreviation in CoAP Sandelman Software Works Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus using (relatively verbose) well-known URI paths. This document introduces the Uri-Path-Abbrev CoAP option that allows expressing well-known URI paths in as little as two bytes. Using this option revealed a subtle flaw in RFC7252 that severely limited the extension point of critical options. This document updates RFC7252 to rectify that. CoAP Option Numbers IANA DNS SVCB Service Parameter Keys (SvcParamKeys) IANA Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Informative References Enrollment over Secure Transport This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. Observing Resources in the Constrained Application Protocol (CoAP) 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. Concise Binary Object Representation (CBOR) Sequences This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Ephemeral Diffie-Hellman Over COSE (EDHOC) 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 Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first 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. Group Communication for the Constrained Application Protocol (CoAP) IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of 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 and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. Proxy Operations in Group Communication for the Constrained Application Protocol (CoAP) RISE AB IoTconsultancy.nl This document defines a specific realization of proxy intended for scenarios that use group communication for the Constrained Application Protocol (CoAP). Such a proxy processes a single request sent by a client typically over unicast and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. 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. Observe Notifications as CoAP Multicast Responses RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. In some use cases, such as those based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing the same target resource. This document updates RFC7252 and RFC7641, and it defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of the same resource on the same shared Token value. Besides, this document defines how the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to- end between the server and the observer clients. Using Proxies for Observe Notifications as CoAP Multicast Responses RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. A publish-subscribe architecture for the Constrained Application Protocol (CoAP) Ericsson Dogtiger Labs Ericsson This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. CoAP Transport Indication TUD Dresden University of Technology 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] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. Key Update for OSCORE (KUDOS) RISE AB RISE AB Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE) RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. Protecting EST Payloads with OSCORE Ericsson AB RISE Nexus Inria Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. Lightweight Authenticated Key Exchange (LAKE) and Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes the Lightweight Authenticated Key Exchange (LAKE) protocol for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. LAKE also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework RISE AB RISE AB Ericsson AB This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information that pertains to the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving the access token. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. End-to-End Protected and Cacheable CoAP Responses using Group Object Security for Constrained RESTful Environments (Group OSCORE) RISE AB When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-to-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. Coordinating the Use of Application Profiles for the Lightweight Authenticated Key Exchange (LAKE) Protocol RISE AB RISE AB The Lightweight Authenticated Key Exchange (LAKE) protocol requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of LAKE to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store LAKE application profiles. Furthermore, in order to facilitate interoperability between LAKE implementations and support LAKE extensibility for additional integrations, this document defines a number of means to coordinate the use of LAKE application profiles. Finally, this document defines a set of well-known LAKE application profiles. Using onion routing with CoAP RISE AB RISE AB The CoAP protocol was designed with direct connections and proxies in mind. This document defines mechanisms by which chains of proxies can be set up. In combination, they enable the operation of hidden services and of clients similar to how Tor (onion routing) enables it for TCP-based protocols. Lightweight Machine to Machine Technical Specification - Core, Approved Version 1.2.2, OMA-TS-LightweightM2M_Core-V1_2_2-20240613-A Open Mobile Alliance Lightweight Machine to Machine Technical Specification - Transport Bindings, Approved Version 1.2.2, OMA-TS-LightweightM2M_Transport-V1_2_2-20240613-A Open Mobile Alliance Lightweight Machine to Machine Gateway Technical Specification - Approved Version 1.1.1, OMA-TS-LWM2M_Gateway-V1_1_1-20240312-A Open Mobile Alliance Tor Specifications Tor Project Discovery and capabilities of guard proxies for CoRE networks Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

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

CoAP Group Communication with Proxies CoAP also supports 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 those responses can be distinguished from one another. That signaling protocol requires that the proxy identifies the origin client as allowed-listed, before forwarding a group request to the servers (see ). In turn, this requires a security association between the origin client and the proxy, which would be convenient to provide with a dedicated OSCORE Security Context shared 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 in the resource representation, all matching with the original observation request. In some applications, such as based on publish-subscribe communication , multiple clients are interested in observing the same resource at the same server. In the interest of such applications, defines a method that allows the server to send a single notification response 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. If 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 association also between each client and the proxy, in order to 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 shared 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.4.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 as defined in [OSCORE].

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 OSCORE 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.

LwM2M Gateway The specification extends the LwM2M architecture by defining the LwM2M Gateway functionality. That is, a LwM2M Server can manage end IoT devices that are deployed "behind" the LwM2M Gateway. While it is outside the scope of that specification, it is possible for the LwM2M Gateway to use any suitable protocol with its connected end IoT devices, as well as to carry out any required protocol translation. Practically, the LwM2M Server can send a request to the LwM2M Gateway, asking to forward the request to an end IoT device. With particular reference to CoAP and the related transport binding specified in , the LwM2M Server acting as a CoAP client sends its request to the LwM2M Gateway acting as a CoAP server. If CoAP is used in the communication leg between the LwM2M Gateway and the end IoT devices, then the LwM2M Gateway fundamentally acts as a CoAP reverse-proxy (see ). That is, in addition to its own resources, the LwM2M Gateway serves the resources hosted by each end IoT device that stands behind it, as exposed by the LwM2M Gateway under a dedicated URI path. As per , the first URI path segment is used as a "prefix" to identify the specific IoT device, while the remaining URI path segments specify the target resource at that IoT device. As per Section 7 of , message exchanges between the LwM2M Server and the LwM2M Gateway are secured using the LwM2M-defined technologies, while the LwM2M protocol does not provide end-to-end security between the LwM2M Server and the end IoT devices. However, the approach defined in this document makes it possible to achieve both goals, by allowing the LwM2M Server to use OSCORE for protecting a message both end-to-end with the targeted end IoT device and with the LwM2M Gateway acting as a reverse-proxy.

Access Control to a Proxy 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. At the same time, it can be desirable to limit the use of such a proxy to a set of clients that have permission to use it, and that the proxy can identify through a secure communication association. However, in order for OSCORE to be an applicable security mechanism for this scenario, OSCORE has to be terminated at the proxy. That is, it would be required for a client and the proxy to share a dedicated OSCORE Security Context and to use it for protecting their communication leg. Combined with what is defined above, a server aware of a suitable cross-proxy can rely on it as a third-party service, in order to indicate transports for CoAP that are available for that server (see ).

Access Control to the Origin Server A proxy may be deployed to act as an entry point to a firewalled network that only authenticated clients can join. As an alternative to a hard firewall that can be either traversed or not, a proxy can instead apply major rate limits on incoming traffic from unauthenticated clients and lift those limits for authenticated clients, possibly to different extents depending on the specific client. In particular, authentication can rely on the secure communication association used between a client and the proxy. If the proxy could share a different OSCORE Security Context with each different client, then the proxy can rely on it to identify a client before forwarding messages from that client to other members of the firewalled network. Furthermore, if a client trusts the proxy to perform its tasks in a privacy-oriented way, the client can rely on its secure communication association shared with the proxy in order to conceal what origin servers it is communicating with, by hiding that information from further possible intermediaries or on-path passive adversaries on the communication leg between the client and the proxy.

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

The method specified in enables public-key certificate enrollment for Internet of Things deployments. This leverages payload formats defined in Enrollment over Secure Transport (EST) , while relying on CoAP for message transfer and on OSCORE for message protection. In real-world deployments, an EST server issuing public-key certificates may reside outside a constrained network that includes devices acting as EST clients. In particular, the EST clients are expected to support only CoAP, while the EST server in a non-constrained network is expected to support only HTTP. This requires a CoAP-to-HTTP proxy to be deployed between the EST clients and the EST server, in order to map CoAP messages with HTTP messages across the two networks. Even in such a scenario, the EST server and every EST client can still effectively use OSCORE to protect their communications end-to-end. At the same time, it is desirable to have an additional secure association between the EST client and the CoAP-to-HTTP proxy, especially in order for the proxy to identify the EST client before forwarding EST messages out of the CoAP boundary of the constrained network and towards the EST server.
The approach defined 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 client protects a CoAP request first by using the OSCORE Security Context shared with the origin server, and then by using different OSCORE Security Contexts shared with the different hops in the chain. Once received at a chain hop, the request would be stripped of the OSCORE protection associated with that hop before being forwarded to the next one. Building on that, it is also possible to enable the operation of hidden services and clients through onion routing with CoAP , similarly to how Tor (The Onion Router) enables it for TCP-based protocols.

Examples of Message Exchanges This section provides a number of examples where the approach defined in this document is used to protect message exchanges. The presented examples build on the example shown in , which illustrates an origin client requesting the alarm status from an origin server through a forward-proxy. The abbreviations "REQ" and "RESP" are used to denote a request message and a response message, respectively.

With Forward-Proxy; OSCORE: C-S, C-P In the example shown in , message exchanges are protected with OSCORE as follows.

End-to-end, between the client and the server, using the OSCORE Security Context CTX_C_S. The client uses the OSCORE Sender ID 0x5f when using OSCORE with the server.
Between the client and the proxy, using the OSCORE Security Context CTX_C_P. The client uses the OSCORE Sender ID 0x20 when using OSCORE with the proxy.

Use of OSCORE between Client-Server and Client-Proxy | | Code: 0.02 (POST) | POST | | Token: 0x8c | | | OSCORE: [kid:0x20, Partial IV:31] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | Uri-Host: "example.com", | | | OSCORE: [kid:0x5f, Partial IV:42], | | | Proxy-Scheme: "coap", | | | 0xff, | | | {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | | Decrypt | | REQ with | | CTX_C_P | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0x7b | | | Uri-Host: "example.com" | | | OSCORE: [kid:0x5f, Partial IV:42] | | | 0xff | | | Payload: { | | | Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | | | Decrypt | | REQ with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_C_S | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | | Encrypt | | RESP with | | CTX_C_P | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | OSCORE: -, | | | 0xff, | | | {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | Decrypt | | RESP with | | CTX_C_P | | | | | Decrypt | | RESP with | | CTX_C_S | | | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. ]]>

With Forward-Proxy; OSCORE: C-S, P-S In the example shown in , message exchanges are protected with OSCORE as follows.

End-to-end between the client and the server, using the OSCORE Security Context CTX_C_S. The client uses the OSCORE Sender ID 0x5f when using OSCORE with the server.
Between the proxy and the server, using the OSCORE Security Context CTX_P_S. The proxy uses the OSCORE Sender ID 0xd4 when using OSCORE with the server.

Use of OSCORE between Client-Server and Proxy-Server | | Code: 0.02 (POST) | POST | | Token: 0x8c | | | Uri-Host: "example.com" | | | OSCORE: [kid:0x5f, Partial IV:42] | | | Proxy-Scheme: "coap" | | | 0xff | | | Payload: {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | | Encrypt | | REQ with | | CTX_P_S | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0x7b | | | Uri-Host: "example.com" | | | OSCORE: [kid:0xd4, Partial IV:31] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | OSCORE: [kid:0x5f, Partial IV:42], | | | 0xff, | | | {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_P_S | | | | | Decrypt | | REQ with | | CTX_P_S | | | | | Decrypt | | REQ with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_P_S | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | OSCORE: -, | | | 0xff, | | | {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_P_S | | | | Decrypt | | RESP with | | CTX_P_S | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | Decrypt | | RESP with | | CTX_C_S | | | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. ]]>

With Forward-Proxy; OSCORE: C-S, C-P, P-S In the example shown in , message exchanges are protected with OSCORE as follows.

End-to-end between the client and the server, using the OSCORE Security Context CTX_C_S. The client uses the OSCORE Sender ID 0x5f when using OSCORE with the server.
Between the client and the proxy, using the OSCORE Security Context CTX_C_P. The client uses the OSCORE Sender ID 0x20 when using OSCORE with the proxy.
Between the proxy and the server, using the OSCORE Security Context CTX_P_S. The proxy uses the OSCORE Sender ID 0xd4 when using OSCORE with the server.

Use of OSCORE between Client-Server, Client-Proxy, and Proxy-Server | | Code: 0.02 (POST) | POST | | Token: 0x8c | | | OSCORE: [kid:0x20, Partial IV:31] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | Uri-Host: "example.com", | | | OSCORE: [kid:0x5f, Partial IV:42], | | | Proxy-Scheme: "coap", | | | 0xff, | | | {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | | Decrypt | | REQ with | | CTX_C_P | | | | | Encrypt | | REQ with | | CTX_P_S | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0x7b | | | Uri-Host: "example.com", | | | OSCORE: [kid:0xd4, Partial IV:53] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | OSCORE: [kid:0x5f, Partial IV:42], | | | 0xff, | | | {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_P_S | | | | | Decrypt | | REQ with | | CTX_P_S | | | | | Decrypt | | REQ with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_P_S | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | OSCORE: -, | | | 0xff, | | | {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_P_S | | | | Decrypt | | RESP with | | CTX_P_S | | | | | Encrypt | | RESP with | | CTX_C_P | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | OSCORE: -, | | | 0xff, | | | {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | Decrypt | | RESP with | | CTX_C_P | | | | | Decrypt | | RESP with | | CTX_C_S | | | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. ]]>

With Forward-Proxy and LAKE; OSCORE: C-S, C-P In the example shown in , message exchanges are protected as follows.

End-to-end, between the client and the server, using the OSCORE Security Context CTX_C_S. The client uses the OSCORE Sender ID 0x5f when using OSCORE with the server.
Between the client and the proxy, using the OSCORE Security Context CTX_C_P. The client uses the OSCORE Sender ID 0x20 when using OSCORE with the proxy.

The example also shows how the client establishes the OSCORE Security Contexts CTX_C_P with the proxy and CTX_C_S with the server, by using the key exchange protocol LAKE . After a first phase where the OSCORE Security Contexts are established, the second phase consists in a protected message exchange equivalent to that shown in .

Use of OSCORE between Client-Server and Proxy-Server, with OSCORE Security Contexts established through LAKE | | Code: 0.02 (POST) | POST | | Token: 0xf3 | | | Uri-Path: ".well-known" | | | Uri-Path: "edhoc" | | | 0xff | | | Payload: (true, LAKE message_1) | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0xf3 | | | 0xff | | | Payload: LAKE message_2 | | | Establish | | CTX_C_P | | | | | +------>| | Code: 0.02 (POST) | POST | | Token: 0x82 | | | Uri-Path: ".well-known" | | | Uri-Path: "edhoc" | | | 0xff | | | Payload: (C_R, LAKE message_3) | | | | Establish | | CTX_C_P | | | | |<------+ | | ACK | | | | | Encrypt | | REQ with | | CTX_C_P | | | | | +------>| | Code: 0.02 (POST) | POST | | Token: 0xbe | | | OSCORE: [kid:0x20, Partial IV:0] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | Uri-Host: "example.com", | | | Uri-Path: ".well-known", | | | Uri-Path: "edhoc", | | | Proxy-Scheme: "coap", | | | 0xff, | | | (true, LAKE message_1) | | | } // Encrypted with CTX_C_P | | | | Decrypt | | REQ with | | CTX_C_P | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0xa5 | | | Uri-Host: "example.com", | | | Uri-Path: ".well-known" | | | Uri-Path: "edhoc" | | | 0xff | | | Payload: (true, LAKE message_1) | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0xa5 | | | 0xff | | | Payload: LAKE message_2 | | | | Encrypt | | RESP with | | CTX_C_P | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0xbe | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | 0xff, | | | LAKE message_2 | | | } // Encrypted with CTX_C_P | | | Decrypt | | RESP with | | CTX_C_P | | | | | Establish | | CTX_C_S | | | | | Encrypt | | REQ with | | CTX_C_P | | | | | +------>| | Code: 0.02 (POST) | POST | | Token: 0xb9 | | | OSCORE: [kid:0x20, Partial IV:1] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | Uri-Host: "example.com", | | | Uri-Path: ".well-known", | | | Uri-Path: "edhoc", | | | Proxy-Scheme: "coap", | | | 0xff, | | | (C_R, LAKE message_3) | | | } // Encrypted with CTX_C_P | | | | Decrypt | | REQ with | | CTX_C_P | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0xdd | | | Uri-Host: "example.com", | | | Uri-Path: ".well-known" | | | Uri-Path: "edhoc" | | | 0xff | | | Payload: (C_R, LAKE message_3) | | | | | Establish | | CTX_C_S | | | | |<------+ | | ACK | | | | |<------+ | | ACK | | | | | Encrypt | | REQ with | | CTX_C_S | | | | | Encrypt | | REQ with | | CTX_C_P | | | | | +------>| | Code: 0.02 (POST) | POST | | Token: 0x8c | | | OSCORE: [kid:0x20, Partial IV:2] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | Uri-Host: "example.com", | | | OSCORE: [kid:0x5f, Partial IV:0], | | | Proxy-Scheme: "coap", | | | 0xff, | | | {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | | Decrypt | | REQ with | | CTX_C_P | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0x7b | | | Uri-Host: "example.com", | | | OSCORE: [kid:0x5f, Partial IV:0] | | | 0xff | | | Payload: {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | | | Decrypt | | REQ with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_C_S | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | | Encrypt | | RESP with | | CTX_C_P | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | OSCORE: -, | | | 0xff, | | | {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | Decrypt | | RESP with | | CTX_C_P | | | | | Decrypt | | RESP with | | CTX_C_S | | | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. (A, B) indicates a CBOR sequence [RFC8742] of two CBOR data items A and B. ]]>

With Forward-Proxy and LAKE (Optimized); OSCORE: C-S, C-P In the example shown in , message exchanges are protected as follows.

End-to-end, between the client and the server, using the OSCORE Security Context CTX_C_S. The client uses the OSCORE Sender ID 0x5f when using OSCORE with the server.
Between the client and the proxy, using the OSCORE Security Context CTX_C_P. The client uses the OSCORE Sender ID 0x20 when using OSCORE with the proxy.

The example also shows how the client establishes the OSCORE Security Contexts CTX_C_P with the proxy and CTX_C_S with the server, by using the key exchange protocol LAKE . In particular, the client relies on the LAKE + OSCORE request defined in (denoted therein as "EDHOC + OSCORE request") and indicated as COMB_REQ, in order to transport the last LAKE message_3 and the first OSCORE-protected application CoAP request combined together. After a first phase where the OSCORE Security Contexts are established, the second phase consists in a protected message exchange equivalent to that shown in . In the example shown in the present section, the two phases partly overlap at the POST request sent by the client with Token 0x83 and forwarded by the proxy with Token 0xa6, as the LAKE + OSCORE request that conveys both the last LAKE message_3 from the client intended for the server and the first OSCORE-protected application CoAP request combined together.

Use of OSCORE between Client-Server and Proxy-Server, with OSCORE Security Contexts established through LAKE using the LAKE + OSCORE request | | Code: 0.02 (POST) | POST | | Token: 0xf3 | | | Uri-Path: ".well-known" | | | Uri-Path: "edhoc" | | | 0xff | | | Payload: (true, LAKE message_1) | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0xf3 | | | 0xff | | | Payload: LAKE message_2 | | | Establish | | CTX_C_P | | | | | Encrypt | | REQ with | | CTX_C_P | | | | | Prepare | | COMB_REQ | | for P | | from REQ | | | | | +------>| | Code: 0.02 (POST) | POST | | Token: 0x82 | | | OSCORE: [kid:0x20, Partial IV:0] | | | EDHOC: - | | | 0xff | | | Payload: LAKE message_3, // Intended for P | | | {Code: 0.02 (POST), | | | Uri-Host: "example.com", | | | Uri-Path: ".well-known", | | | Uri-Path: "edhoc", | | | Proxy-Scheme: "coap", | | | 0xff, | | | (true, LAKE message_1) | | | } // Encrypted with CTX_C_P | | | | Establish | | CTX_C_P | | | | | Rebuild | | REQ from | | COMB_REQ | | | | | Decrypt | | REQ with | | CTX_C_P | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0xa5 | | | Uri-Host: "example.com", | | | Uri-Path: ".well-known" | | | Uri-Path: "edhoc" | | | 0xff | | | Payload: (true, LAKE message_1) | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0xa5 | | | 0xff | | | Payload: LAKE message_2 | | | | Encrypt | | RESP with | | CTX_C_P | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x82 | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | 0xff, | | | LAKE message_2 | | | } // Encrypted with CTX_C_P | | | Decrypt | | RESP with | | CTX_C_P | | | | | Establish | | CTX_C_S | | | | | Encrypt | | REQ with | | CTX_C_S | | | | | Prepare | | COMB_REQ | | for S | | from REQ | | | | | Encrypt | | COMB_REQ | | with | | CTX_C_P | | | | | +------>| | Code: 0.02 (POST) | POST | | Token: 0x83 | | | OSCORE: [kid:0x20, Partial IV:1] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | Uri-Host: "example.com", | | | OSCORE: [kid:0x5f, Partial IV:0], | | | EDHOC: -, | | | Proxy-Scheme: "coap", | | | 0xff, | | | LAKE message_3, // Intended for S | | | { | | | Code: 0.01 (GET), | | | Uri-Path:"alarm_status" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | | Decrypt | | COMB_REQ | | with | | CTX_C_P | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0xa6 | | | Uri-Host: "example.com", | | | OSCORE: [kid:0x5f, Partial IV:0] | | | EDHOC: - | | | 0xff | | | Payload: LAKE message_3, // Intended for S | | | { | | | Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | | | Establish | | CTX_C_S | | | | | Rebuild | | REQ from | | COMB_REQ | | | | | Decrypt | | REQ with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_C_S | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0xa6 | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | | Encrypt | | RESP with | | CTX_C_P | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x83 | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | OSCORE: -, | | | 0xff, | | | {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | Decrypt | | RESP with | | CTX_C_P | | | | | Decrypt | | RESP with | | CTX_C_S | | | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. (A, B) indicates a CBOR sequence [RFC8742] of two CBOR data items A and B. ]]>

With Two Forward-Proxies; OSCORE: C-S, C-P1, P1-P2, P2-S In the example shown in , message exchanges are protected with OSCORE as follows.

End-to-end between the client and the server, using the OSCORE Security Context CTX_C_S. The client uses the OSCORE Sender ID 0x5f when using OSCORE with the server.
Between the client and the proxy Proxy1 (P1), using the OSCORE Security Context CTX_C_P1. The client uses the OSCORE Sender ID 0x20 when using OSCORE with P1.
Between P1 and the proxy Proxy2 (P2), using the OSCORE Security Context CTX_P1_P2. P1 uses the OSCORE Sender ID 0xd4 when using OSCORE with P2.
Between P2 and the server, using the OSCORE Security Context CTX_P2_S. P2 uses the OSCORE Sender ID 0x77 when using OSCORE with the server.

Use of OSCORE between Client-Server, Client-Proxy1, Proxy1-Proxy2, and Proxy2-Server | | | Code: 0.02 (POST) | POST | | | Token: 0x8c | | | | OSCORE: [kid:0x20, Partial IV:31] | | | | 0xff | | | | Payload: {Code: 0.02 (POST), | | | | Uri-Host: "example.com", | | | | OSCORE: [kid:0x5f, | | | | Partial IV:42], | | | | Proxy-Scheme: "coap", | | | | 0xff, | | | | {Code: 0.01 (GET), | | | | Uri-Path: "alarm_status" | | | | } // Encrypted with CTX_C_S | | | | } // Encrypted with CTX_C_P1 | | | | | Decrypt | | | REQ with | | | CTX_C_P1 | | | | | | | Encrypt | | | REQ with | | | CTX_P1_P2 | | | | | | | +------>| | Code: 0.02 (POST) | | POST | | Token: 0x7b | | | | OSCORE: [kid:0xd4, Partial IV:53] | | | | 0xff | | | | Payload: {Code: 0.02 (POST), | | | | Uri-Host: "example.com", | | | | OSCORE: [kid:0x5f, | | | | Partial IV:42], | | | | Proxy-Scheme: "coap", | | | | 0xff, | | | | {Code: 0.01 (GET), | | | | Uri-Path: "alarm_status" | | | | } // Encrypted with CTX_C_S | | | | } // Encrypted with CTX_P1_P2 | | | | | | Decrypt | | | REQ with | | | CTX_P1_P2 | | | | | | | Encrypt | | | REQ with | | | CTX_P2_S | | | | | | | +------>| Code: 0.02 (POST) | | | POST | Token: 0x6a | | | | Uri-Host: "example.com", | | | | OSCORE: [kid:0x77, Partial IV:75] | | | | 0xff | | | | Payload: {Code: 0.02 (POST), | | | | OSCORE: [kid:0x5f, | | | | Partial IV:42], | | | | 0xff, | | | | {Code: 0.01 (GET), | | | | Uri-Path: "alarm_status" | | | | } // Encrypted with CTX_C_S | | | | } // Encrypted with CTX_P2_S | | | | | | | Decrypt | | | REQ with | | | CTX_P2_S | | | | | | | Decrypt | | | REQ with | | | CTX_C_S | | | | | | | Encrypt | | | RESP with | | | CTX_C_S | | | | | | | Encrypt | | | RESP with | | | CTX_P2_S | | | | | | |<------+ Code: 2.04 (Changed) | | | 2.04 | Token: 0x6a | | | | OSCORE: - | | | | 0xff | | | | Payload: {Code: 2.04 (Changed), | | | | OSCORE: -, | | | | 0xff, | | | | {Code: 2.05 (Content), | | | | 0xff, | | | | "0" | | | | } // Encrypted with CTX_C_S | | | | } // Encrypted with CTX_P2_S | | | | | | Decrypt | | | RESP with | | | CTX_P2_S | | | | | | | Encrypt | | | RESP with | | | CTX_P1_P2 | | | | | | |<------+ | Code: 2.04 (Changed) | | 2.04 | | Token: 0x7b | | | | OSCORE: - | | | | 0xff | | | | Payload: {Code: 2.04 (Changed), | | | | OSCORE: -, | | | | 0xff, | | | | {Code: 2.05 (Content), | | | | 0xff, | | | | "0" | | | | } // Encrypted with CTX_C_S | | | | } // Encrypted with CTX_P1_P2 | | | | | Decrypt | | | RESP with | | | CTX_P1_P2 | | | | | | | Encrypt | | | RESP with | | | CTX_C_P1 | | | | | | |<------+ | | Code: 2.04 (Changed) | 2.04 | | | Token: 0x8c | | | | OSCORE: - | | | | 0xff | | | | Payload: {Code: 2.04 (Changed), | | | | OSCORE: -, | | | | 0xff, | | | | {Code: 2.05 (Content), | | | | 0xff, | | | | "0" | | | | } // Encrypted with CTX_C_S | | | | } // Encrypted with CTX_C_P1 | | | | Decrypt | | | RESP with | | | CTX_C_P1 | | | | | | | Decrypt | | | RESP with | | | CTX_C_S | | | | | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. ]]>

With Reverse-Proxy; OSCORE: C-P, P-S In the example shown in , message exchanges are protected with OSCORE as follows.

Between the client and the proxy, using the OSCORE Security Context CTX_C_P. The client uses the OSCORE Sender ID 0x20 when using OSCORE with the proxy.
Between the proxy and the server, using the OSCORE Security Context CTX_P_S. The proxy uses the OSCORE Sender ID 0xd4 when using OSCORE with the server.

In this example, the proxy is specifically a reverse-proxy. Like typically expected in such a case, the client is not aware of that and believes to communicate with an origin server. In order to determine where it has to forward an incoming request to, the proxy relies on the hostname that clients specify in the Uri-Host Option of their sent requests. In particular, upon receiving a request that includes the Uri-Host Option with value "dev.example", the proxy forwards the request to the origin server shown in the example. Furthermore, this example assumes that, in the URI identifying the target resource at the server, the host subcomponent represents the destination IP address of the request as an IP-literal. Therefore, the request from the proxy to the server does not include a Uri-Host Option (see ).

Use of OSCORE between Client-Proxy and Proxy-Server (the Proxy is a Reverse-Proxy) | | Code: 0.02 (POST) | POST | | Token: 0x8c | | | Uri-Host: "dev.example" | | | OSCORE: [kid:0x20, Partial IV:31] | | | 0xff | | | Payload: {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_P | | | | Decrypt | | REQ with | | CTX_C_P | | | | | Encrypt | | REQ with | | CTX_P_S | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0x7b | | | OSCORE: [kid:0xd4, Partial IV:42] | | | 0xff | | | Payload: { | | | Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_P_S | | | | | Decrypt | | REQ with | | CTX_P_S | | | | | Encrypt | | RESP with | | CTX_P_S | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_P_S | | | | Decrypt | | RESP with | | CTX_P_S | | | | | Encrypt | | RESP with | | CTX_C_P | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_P | | | Decrypt | | RESP with | | CTX_C_P | | | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. ]]>

With Reverse-Proxy; OSCORE: C-S, C-P, P-S In the example shown in , message exchanges are protected with OSCORE as follows.

End-to-end between the client and the server, using the OSCORE Security Context CTX_C_S. The client uses the OSCORE Sender ID 0x5f when using OSCORE with the server.
Between the client and the proxy, using the OSCORE Security Context CTX_C_P. The client uses the OSCORE Sender ID 0x20 when using OSCORE with the proxy.
Between the proxy and the server, using the OSCORE Security Context CTX_P_S. The proxy uses the OSCORE Sender ID 0xd4 when using OSCORE with the server.

In this example, the proxy is specifically a reverse-proxy. However, unlike typically expected, the client is aware to communicate with a reverse-proxy. This is the case, e.g., in the LwM2M scenario considered in , where the LwM2M Server acts as a CoAP client and uses a LwM2M Gateway acting as a CoAP-to-CoAP reverse-proxy in order to reach an end IoT device. In order to determine where it has to forward an incoming request to, the proxy relies on the URI path components that are specified as value of the Uri-Path Options included in the request. In particular, the proxy relies on the first URI path segment to identify the specific IoT device to which the request has to be forwarded, while the remaining URI path segments specify the target resource at that IoT device. However, as shown in the example, the URI path segments that specify the target resource are hidden from the proxy, since they are protected by the additional use of OSCORE end-to-end between the client and the server. Furthermore, this example assumes that, in the URIs identifying the target resource at the proxy as well as in the URI identifying the target resource at the server, the host subcomponent represents the destination IP address of the request as an IP-literal. Therefore, both the request from the client to the proxy and the request from the proxy to the server do not include a Uri-Host Option (see ).

Use of OSCORE between Client-Proxy and Proxy-Server (the Proxy is a Reverse-Proxy) | | Code: 0.02 (POST) | POST | | Token: 0x8c | | | OSCORE: [kid:0x20, Partial IV:31] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | OSCORE: [kid:0x5f, Partial IV:42], | | | Uri-Path: "dev1", | | | 0xff, | | | {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | | Decrypt | | REQ with | | CTX_C_P | | | | | Encrypt | | REQ with | | CTX_P_S | | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0x7b | | | OSCORE: [kid:0xd4, Partial IV:53] | | | 0xff | | | Payload: {Code: 0.02 (POST), | | | OSCORE: [kid:0x5f, Partial IV:42], | | | 0xff, | | | {Code: 0.01 (GET), | | | Uri-Path: "alarm_status" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_P_S | | | | | Decrypt | | REQ with | | CTX_P_S | | | | | Decrypt | | REQ with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_C_S | | | | | Encrypt | | RESP with | | CTX_P_S | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | OSCORE: -, | | | 0xff, | | | {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_P_S | | | | Decrypt | | RESP with | | CTX_P_S | | | | | Encrypt | | RESP with | | CTX_C_P | | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | OSCORE: - | | | 0xff | | | Payload: {Code: 2.04 (Changed), | | | OSCORE: -, | | | 0xff, | | | {Code: 2.05 (Content), | | | 0xff, | | | "0" | | | } // Encrypted with CTX_C_S | | | } // Encrypted with CTX_C_P | | | Decrypt | | RESP with | | CTX_C_P | | | | | Decrypt | | RESP with | | CTX_C_S | | | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. ]]>

State Diagram: Protection of CoAP Options overviews the rules defined in , which are used to determine whether a CoAP option that is originally specified only as an outer option (Class U or I) for OSCORE has to be processed as Class E, when protecting an outgoing message.

Protection of CoAP Options Originally Specified only as Outer Options (Class U or I) for OSCORE | As far as I can |---YES-->| As far as I can | | OPT to M? | | tell, is X a | | tell, is X the | +-----------+ | consumer of OPT? | | immediately next | | +------------------+ | consumer of OPT? | | | +------------------+ | | | | NO NO YES NO | | | | | | | | v v v | +--------------------------+ +---------------------+ | | * As far as I can tell, | | Does X need to | | | X is my next hop | | access OPT before | | | | | decrypting M or in | | | OR | | order to decrypt M? | | | | +---------------------+ | | * As far as I can tell, | | | | | the immediately next | NO YES | | consumer of OPT is not | | | | | a hop in between | | | | | myself and X | | | | +--------------------------+ | | | | | | | | NO YES | | | | | | | | | | | | | | v v | | | +----------------------------+ | | | | Is OPT the Uri-Host Option | | | | +----| or the Uri-Port Option? | | | | | +----------------------------+ | | | | | | | | NO YES | | | | | | | | | | | | | | v | | | | +----------------------------------------+ | | | | | Does M include the Proxy-Scheme Option | | | | | | or the Proxy-Scheme-Number Option? | | | | | +----------------------------------------+ | | | | | | | | | | YES NO | | | | | | | | | | | | | | | v v | | | | +------------------------+ | | | | | Process OPT as Class E | | | | | +------------------------+ | | | | | | | | v v | | +-----------------------------------------------+ | +------->| Process OPT as per its original Class U or I |<-----+ +-----------------------------------------------+ ]]>

State Diagram: Processing of Incoming Requests overviews the processing of an incoming request, which is specified in . The dotted boxes indicate ending states where the processing terminates.

Processing of an Incoming Request | Are there proxy-related options? |<-------+ request +-----------------------------------------------+ | | ^ | | YES .......... | NO | | : Return : | | | | : 5.05 : | | | | :........: | | | | ^ | | | | | | | | | NO | | | v | | v | +------------------+ YES +---------+ | +----------------+ | | Is there the |----->| Am I a | | | Is there an | | | Proxy-Uri Option | | forward | | | OSCORE Option? | | | or the Proxy-Cri | +--->| proxy? | | +----------------+ | | Option, possibly | | +---------+ | ^ | | | | with the | | | | | NO YES | | Uri-Path-Abbrev | | | | | | | | | Option? | | | | | | | | +------------------+ | | | | | | | | | YES | | | | | NO | | | | | | | | | | | | | | | | | | | | | v | | | | .......... | | | +---------+ | | | | : Return : | | | | Decrypt | | | | | : 4.01 : | | | +---------+ | | | | :........: | | | | | | | | ^ | | | | | | | | | | | | | | | YES | NO | | | v | v | v | | | | +----------+ | +---------------------+ +--------------+ | | | | Success? | | | Is there the | | Is it | | | | +----------+ | | Proxy-Scheme | | acceptable | | | | | | | | Option or the | | to forward | | | | NO | | | Proxy-Scheme-Number | | the request? | | | | | | | | Option, with a | | (#) | | | | | +--YES--+ | combination of the | +--------------+ | | | | | following options? | | | | | | | | YES | | | v | - Uri-Host; | | | | | ................ | - Uri-Port; | | | | | : OSCORE error : | - Uri-Path-Abbrev, | | | | | : handling : | or one or more | | | | | :..............: | Uri-Path | | | | | +---------------------+ | | | | | | | | | NO v | | v | +---------------+ | | +--------------+ | | Consume the | | | | Is there an | | | proxy-related | | | | application? | | | options | | | +--------------+ | +---------------+ | | | | | | | | YES NO | | | | | | | | | | | | | | | | | | | | YES | | | | v | | | v | +------------------------------+ | | .......... | | Does the authority component | | | : Return : | | (host and port) of the | | | : 4.04 : | | request URI identify me? | | | :........: | +------------------------------+ | | | | | v | NO | .................. | | | : Deliver the : | | | : request to the : v v | : application : +-----------------------------+ ........... | :................: | There is no | : Forward : | | Proxy-Scheme Option or | : the : | | Proxy-Scheme-Number Option, | : request : | | but there is a combination | :.........: | | of the following options: | ^ | | | | | | - Uri-Host; | | | | - Uri-Port; | | | | - Uri-Path-Abbrev, or | | | | one or more Uri-Path | | | +-----------------------------+ | | | | | | .......... +---------------+ | | : Return : | Consume the | | | : 4.01 : | proxy-related | | | :........: | options | | | ^ +---------------+ | | | ^ | | | | | | NO | | | | | | | +---------------+ | | | | Is it | | | | | acceptable to |---YES---+ | | | forward the | | | | request? (#) | | | +---------------+ | | ^ | | | | | YES | v | | +-----------------------------------+ | | Am I a reverse-proxy using the | | | request URI from the options |---NO---+ | Uri-Host, Uri-Port, Uri-Path, | | and Uri-Path-Abbrev for proxying? | +-----------------------------------+ (#) This is determined according to the endpoint's configuration and a possible authorization enforcement. ]]>

Document Updates

Version -07 to -08

Renamed EDHOC to LAKE as appropriate.
More precise step for escalating the protection of CoAP options.
Added section on replay protection and ordering of responses.
Aligned SCHC terminology with that of draft-ietf-schc-8824-update.
Added "Implementation Status" section.
Added "Operational Considerations" section.
Registration of DNS SVCB SvcParamKeys.
Removed one item from "Further Use Cases".
Editorial fixes and improvements.

Version -06 to -07

Revised presentation of the algorithm for processing incoming requests.
Added guidelines for proxies on establishing/using OSCORE with an origin server.
Added example of message exchange with two forward-proxies.
Fixes in the examples of message exchange.
Minor clarifications and editorial improvements.

Version -05 to -06

Removed normative language when behavior is not new.
Removed inappropriate references to RFC 7252.
Defined meaning of "consumer" of a CoAP option.
Fixed use of error codes at the origin server.
Reorganized text on policies for source-based processing of incoming requests.
Covered the use of the CoAP Uri-Path-Abbrev Option.
Added requirements on including the Partial IV in the OSCORE Option of responses.
Use of SCHC Compression/Decompression:
- Fixed generalization of Outer SCHC Compression.
- Explicit distinction between Inner and Outer SCHC Compression Rules.
Improved visibility and discussion on two use cases: "Access Control to a Proxy" and "Access Control to the Origin Server" (via a pproxy).
Updated references.
Minor clarifications and editorial improvements.

Version -04 to -05

Fixes in the examples of message exchange.
Minor clarifications and editorial improvements.

Version -03 to -04

Removed definition and use of "OSCORE-in-OSCORE".
Moved use cases to an appendix.
Explain deviations from RFC 8613 as an actual subsection.
More precise indication of outer or inner CoAP options.
Added security consideration on membership of OSCORE groups.
Updated references.
Editorial improvements.

Version -02 to -03

Clarified motivation for updating RFC 8768 in the introduction.
Explained that OSCORE-capable proxies have to recognize CoAP options included in outgoing messages to protect.
Fixed typo about the intended class of Hop-Limit option for OSCORE.
Fixed protection of the Uri-Host option in examples.
Added security considerations about the Hop-Limit option.
Clarifications and editorial improvements.

Version -01 to -02

Revised escalation of CoAP option protection.
Specified general ordering for protecting outgoing requests.
Explicit definition of OSCORE processing for the Hop-Limit option (update to RFC 8768).
Added examples of message exchange with a reverse-proxy.
Clarifications and editorial improvements.

Version -00 to -01

Escalation of option protection as explicit update point to RFC 8613.
Clarified examples of Class U/I CoAP options that become encrypted.
Considered also the CoAP Options Proxy-Cri and Proxy-Scheme-Number.
Added reference to Onion CoAP as use case.
Required to set a limit on OSCORE layers that can be added/removed.
Revised general rules on protecting CoAP options.
A forward-proxy consumes a request when the request URI identifies the proxy itself.
Consistency fix: a reverse-proxy can forward based on Uri-Host, Uri-Port or Uri-Path.
Generalized authorization checks as acceptability checks.
Added acceptability check before decrypting a request.
Fixes in the examples of message exchange.
Updated state diagram of the incoming request processing.
Added state diagram on the protection of CoAP options of Class U/I.
Updated references.
Editorial fixes and improvements.

Acknowledgments The authors sincerely thank , , , , , and for their comments and feedback. The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).