



CoRE Working Group                                             M. Tiloca
Internet-Draft                                                R. Höglund
Updates: 8613, 8768 (if approved)                                RISE AB
Intended status: Standards Track                            2 March 2026
Expires: 3 September 2026


                         OSCORE-capable Proxies
               draft-ietf-core-oscore-capable-proxies-06

Abstract

   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

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Constrained RESTful
   Environments Working Group mailing list (core@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/core/.

   Source for this draft and an issue tracker can be found at
   https://github.com/core-wg/oscore-capable-proxies.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.





Tiloca & Höglund        Expires 3 September 2026                [Page 1]

Internet-Draft           OSCORE-capable Proxies               March 2026


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 3 September 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Message Processing  . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Deviations from the Original Message Processing . . . . .   6
     2.2.  Protection of CoAP Options  . . . . . . . . . . . . . . .   8
     2.3.  Processing of an Outgoing Request . . . . . . . . . . . .  10
     2.4.  Processing of an Incoming Request . . . . . . . . . . . .  10
       2.4.1.  Policies for Source-Based Processing  . . . . . . . .  13
     2.5.  Processing of an Outgoing Response  . . . . . . . . . . .  14
       2.5.1.  Partial IV in the OSCORE Option . . . . . . . . . . .  15
     2.6.  Processing of an Incoming Response  . . . . . . . . . . .  15
       2.6.1.  Partial IV in the OSCORE Option . . . . . . . . . . .  16
   3.  OSCORE Processing of the Hop-Limit Option . . . . . . . . . .  17
   4.  Caching of OSCORE-Protected Responses . . . . . . . . . . . .  18
   5.  Establishment of OSCORE Security Contexts . . . . . . . . . .  19
   6.  CoAP Header Compression with SCHC . . . . . . . . . . . . . .  20
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
     7.1.  Preserving Location Anonymity . . . . . . . . . . . . . .  22
     7.2.  Hop-Limit Option  . . . . . . . . . . . . . . . . . . . .  23
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25



Tiloca & Höglund        Expires 3 September 2026                [Page 2]

Internet-Draft           OSCORE-capable Proxies               March 2026


     8.1.  CoAP Option Numbers Registry  . . . . . . . . . . . . . .  25
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  26
   Appendix A.  Use Cases  . . . . . . . . . . . . . . . . . . . . .  29
     A.1.  CoAP Group Communication with Proxies . . . . . . . . . .  30
     A.2.  CoAP Observe Notifications over Multicast . . . . . . . .  30
     A.3.  LwM2M Client and External Application Server  . . . . . .  31
     A.4.  LwM2M Gateway . . . . . . . . . . . . . . . . . . . . . .  32
     A.5.  Access Control to a Proxy . . . . . . . . . . . . . . . .  32
     A.6.  Access Control to the Origin Server . . . . . . . . . . .  33
     A.7.  Further Use Cases . . . . . . . . . . . . . . . . . . . .  33
   Appendix B.  Examples of Message Exchanges  . . . . . . . . . . .  35
     B.1.  With Forward-Proxy; OSCORE: C-S, C-P  . . . . . . . . . .  35
     B.2.  With Forward-Proxy; OSCORE: C-S, P-S  . . . . . . . . . .  37
     B.3.  With Forward-Proxy; OSCORE: C-S, C-P, P-S . . . . . . . .  39
     B.4.  With Forward-Proxy and EDHOC; OSCORE: C-S, C-P  . . . . .  42
     B.5.  With Forward-Proxy and EDHOC (optimized); OSCORE: C-S,
           C-P . . . . . . . . . . . . . . . . . . . . . . . . . . .  46
     B.6.  With Reverse-Proxy; OSCORE: C-P, P-S  . . . . . . . . . .  51
     B.7.  With Reverse-Proxy; OSCORE: C-S, C-P, P-S . . . . . . . .  53
   Appendix C.  State Diagram: Protection of CoAP Options  . . . . .  57
   Appendix D.  State Diagram: Processing of Incoming Requests . . .  58
   Appendix E.  Document Updates . . . . . . . . . . . . . . . . . .  61
     E.1.  Version -05 to -06  . . . . . . . . . . . . . . . . . . .  61
     E.2.  Version -04 to -05  . . . . . . . . . . . . . . . . . . .  62
     E.3.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  62
     E.4.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  62
     E.5.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  62
     E.6.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  63
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  63
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  64

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] supports the
   presence of intermediaries such as forward-proxies and reverse-
   proxies, which assist origin clients by performing requests to origin
   servers on their behalf and forwarding back the corresponding
   responses.

   CoAP also supports group communication scenarios
   [I-D.ietf-core-groupcomm-bis], where clients can send a one-to-many
   request targeting all the servers in the group, e.g., by using IP
   multicast.  Like for one-to-one communication, group settings can
   also rely on intermediaries, e.g., by using the realization of proxy
   specified in [I-D.ietf-core-groupcomm-proxy].




Tiloca & Höglund        Expires 3 September 2026                [Page 3]

Internet-Draft           OSCORE-capable Proxies               March 2026


   The security protocol Object Security for Constrained RESTful
   Environments (OSCORE) [RFC8613] can be used to protect CoAP messages
   between two endpoints at the application layer, especially achieving
   end-to-end security in the presence of (non-trusted) intermediaries.
   When CoAP group communication is used, the same can be achieved by
   means of the security protocol Group OSCORE
   [I-D.ietf-core-oscore-groupcomm].

   For a number of use cases (see Appendix A), 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 [RFC8613] 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 [RFC8613] 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., the origin client and the adjacent intermediary acting as
      the next hop towards the origin server).




Tiloca & Höglund        Expires 3 September 2026                [Page 4]

Internet-Draft           OSCORE-capable Proxies               March 2026


   Furthermore, this document updates [RFC8768], by explicitly defining
   the CoAP Hop-Limit Option to be of Class U for OSCORE (see
   Section 3).  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 often) to decrypt an incoming message or
   whether to forward 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.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Readers are expected to be familiar with the terms and concepts
   related to CoAP [RFC7252], OSCORE [RFC8613], and Group OSCORE
   [I-D.ietf-core-oscore-groupcomm].  This document especially builds on
   concepts and mechanics related to intermediaries such as CoAP
   forward-proxies and reverse-proxies.

   In addition, this document uses the following terms.

   *  Source application endpoint: an origin client producing a request
      or an origin server producing a response.

   *  Destination application endpoint: an origin server intended to
      consume a request or an origin client intended to consume a
      response.

   *  Application endpoint: a source or destination application
      endpoint.

   *  Source OSCORE endpoint: an endpoint protecting a message with
      OSCORE or Group OSCORE.




Tiloca & Höglund        Expires 3 September 2026                [Page 5]

Internet-Draft           OSCORE-capable Proxies               March 2026


   *  Destination OSCORE endpoint: an endpoint unprotecting a message
      with OSCORE or Group OSCORE.

   *  OSCORE endpoint: a source 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 [RFC7252],
      [I-D.ietf-core-href], and [I-D.ietf-core-uri-path-abbrev].

      -  The Proxy-Uri Option or the Proxy-Cri Option, possibly in
         combination with the Uri-Path-Abbrev Option (see Section 2.4 of
         [I-D.ietf-core-uri-path-abbrev]).  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.

2.  Message Processing

   This section defines the processing of CoAP messages with OSCORE.

   Appendix B provides a number of examples where the approach defined
   in this document is used to protect message exchanges.

2.1.  Deviations from the Original Message Processing

   This document introduces the following two main deviations from the
   original OSCORE specification [RFC8613].

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



Tiloca & Höglund        Expires 3 September 2026                [Page 6]

Internet-Draft           OSCORE-capable Proxies               March 2026


      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, the resulting message might legitimately include an
      OSCORE Option and thus have in turn to be decrypted.

      The most common case is expected to consider a message protected
      with up to two OSCORE layers, i.e.: i) an inner layer, protecting
      the message end-to-end between the origin client and the origin
      server acting as application endpoints; and ii) an outer layer,
      protecting the message between a certain OSCORE endpoint and the
      other OSCORE endpoint adjacent in the intermediary chain.

      However, a message can also be protected with a higher, arbitrary
      number of nested OSCORE layers, e.g., in scenarios that rely on a
      longer chain of intermediaries.  For instance, the origin client
      can sequentially apply multiple OSCORE layers to a request, each
      of which is intended to be consumed and removed by one of the
      intermediaries in the chain, until the origin server is reached
      and it consumes the innermost OSCORE layer.

      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
      Section 2.5).





Tiloca & Höglund        Expires 3 September 2026                [Page 7]

Internet-Draft           OSCORE-capable Proxies               March 2026


2.2.  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 4.1.1 and 4.1.3 of [RFC8613].

   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.  Appendix C
   provides an overview of these steps through a state diagram.

   In the following, a recipient endpoint is denoted as "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.

   1.  If the sender endpoint has added OPT to M, then this algorithm
       moves to Step 2.  Otherwise, this algorithm moves to Step 4.

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

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

   4.  If any of the following conditions holds, then this algorithm
       moves to Step 6.  Otherwise, this algorithm moves to Step 9.



Tiloca & Höglund        Expires 3 September 2026                [Page 8]

Internet-Draft           OSCORE-capable Proxies               March 2026


       *  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 next hop
          for the sender endpoint is not the immediately next consumer
          of OPT.

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

   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.

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

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

   9.  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 Section 5.7.1 of [RFC7252], 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 respond 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 Section 2.5.



Tiloca & Höglund        Expires 3 September 2026                [Page 9]

Internet-Draft           OSCORE-capable Proxies               March 2026


2.3.  Processing of an Outgoing Request

   The rules from Section 2.2 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.

2.4.  Processing of an Incoming Request

   Upon receiving a request REQ, the recipient endpoint performs the
   actions described in the following steps.  Appendix D provides an
   overview of these steps through a state diagram.

   1.  If REQ includes proxy-related options, the endpoint moves to Step
       2.  Otherwise, the endpoint moves to Step 3.

   2.  The endpoint proceeds as defined below, depending on which of the
       two following conditions holds.

       *  REQ includes either of the following (set) of CoAP options:

          -  The Proxy-Uri Option or the Proxy-Cri Option, possibly in
             combination with the Uri-Path-Abbrev Option (see
             Section 2.4 of [I-D.ietf-core-uri-path-abbrev]).

          -  The Proxy-Scheme Option or the Proxy-Scheme-Number Option,
             together with a combination of:

             o  The Uri-Host Option.

             o  The Uri-Port Option.

             o  Either the Uri-Path-Abbrev Option, or one or more Uri-
                Path Options.





Tiloca & Höglund        Expires 3 September 2026               [Page 10]

Internet-Draft           OSCORE-capable Proxies               March 2026


          If the endpoint is not configured to be a forward-proxy, it
          stops processing REQ and responds with a 5.05 (Proxying Not
          Supported) error response to (the previous hop towards) the
          origin client, as per Section 5.10.2 of [RFC7252].  This may
          result in protecting the error response over that
          communication leg, as per Section 2.5.

          Otherwise, 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.

          In case the check fails, the endpoint MUST stop processing REQ
          and MUST respond 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 Section 2.5.

          Instead, in case the check succeeds, the endpoint consumes the
          proxy-related options as per Section 5.7.2 of [RFC7252].  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 the endpoint 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 Section 4 of
          [I-D.ietf-core-multicast-notifications-proxy]).

          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 Section 2.3.

          After that, the endpoint does not take any further action.

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



Tiloca & Höglund        Expires 3 September 2026               [Page 11]

Internet-Draft           OSCORE-capable Proxies               March 2026


          -  Either the Uri-Path-Abbrev Option, or one or more Uri-Path
             Options.

          If the endpoint is not configured to be a reverse-proxy, or
          what is targeted by the value of the included Uri-Host, Uri-
          Port, Uri-Path, and Uri-Path-Abbrev Options is not intended to
          support reverse-proxy functionalities, then the endpoint moves
          to Step 3.

          Otherwise, 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.

          In case the check fails, the endpoint MUST stop processing REQ
          and MUST respond 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 Section 2.5.

          Otherwise, 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., in case the next hop towards the
          origin server is a reverse-proxy.

          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 Section 2.3.

          After that, the endpoint does not take any further action.

   3.  The endpoint proceeds as defined below, depending on which of the
       two following conditions holds.

       *  REQ does not include an OSCORE Option.







Tiloca & Höglund        Expires 3 September 2026               [Page 12]

Internet-Draft           OSCORE-capable Proxies               March 2026


          If the endpoint does not have an application to handle REQ, it
          MUST stop processing the request and MAY respond 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 Section 2.5.

          Otherwise, the endpoint delivers REQ to the application.

       *  REQ includes an OSCORE Option.

          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
          Section 2.4.1, the endpoint retrieves CTX from a specific list
          of Security Contexts, which the endpoint looks up 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 performs error handling as per
          Section 8.2 of [RFC8613] or Sections 7.2 and 8.4 of
          [I-D.ietf-core-oscore-groupcomm], in case OSCORE or Group
          OSCORE is used, respectively.  In case the endpoint sends an
          error response to (the previous hop towards) the origin
          client, this may result in protecting the error response over
          that communication leg, as per Section 2.5.

          Otherwise, REQ takes REQ* and the endpoint moves to Step 1.

2.4.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
   [I-D.amsuess-t2trg-onion-coap]).  For example, such servers might



Tiloca & Höglund        Expires 3 September 2026               [Page 13]

Internet-Draft           OSCORE-capable Proxies               March 2026


   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
   help keeping separate name spaces of OSCORE Sender/Recipient IDs,
   which would otherwise leak information.

2.5.  Processing of an Outgoing Response

   The rules from Section 2.2 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.

   In case the response is an error response, the sender endpoint
   protects it by applying the same OSCORE layers that it successfully
   removed from the corresponding incoming request, but in the reverse
   order than the one according to which those layers were removed.











Tiloca & Höglund        Expires 3 September 2026               [Page 14]

Internet-Draft           OSCORE-capable Proxies               March 2026


2.5.1.  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
      5.3.1, 7.3, and 8.5 of [I-D.ietf-core-oscore-groupcomm]).

   *  When the response is protected with OSCORE and it is an Observe
      notification [RFC7641] (see Section 8.3.1 of [RFC8613]).

      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
   [I-D.ietf-core-groupcomm-bis].  The specification
   [I-D.ietf-core-groupcomm-proxy] 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.

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




Tiloca & Höglund        Expires 3 September 2026               [Page 15]

Internet-Draft           OSCORE-capable Proxies               March 2026


   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.

2.6.1.  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 [RFC7641].

   *  When the request is sent to a group of recipients, e.g., over IP
      multicast [I-D.ietf-core-groupcomm-bis].

   *  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
      [I-D.ietf-core-groupcomm-bis][I-D.ietf-core-groupcomm-proxy].

   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 [RFC7641]; sending the request as addressed to a group of
   recipients (e.g., to an IP multicast address)
   [I-D.ietf-core-groupcomm-bis]; including the CoAP Multicast-Timeout
   Option in the unicast request sent to a proxy, which forwards the
   request to a group of recipients [I-D.ietf-core-groupcomm-proxy]; 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 Section 5.3.1 of [I-D.ietf-core-oscore-groupcomm]).

   *  The source OSCORE endpoint protected the response with OSCORE, and
      the response is an Observe notification (see Section 4.1.3.5.2 of
      [RFC8613]).



Tiloca & Höglund        Expires 3 September 2026               [Page 16]

Internet-Draft           OSCORE-capable Proxies               March 2026


   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 Section 2.5.1 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.

3.  OSCORE Processing of the Hop-Limit Option

   The CoAP Hop-Limit Option is defined in [RFC8768] 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.

   [RFC8768] does not define how the Hop-Limit Option is processed by
   OSCORE.  As a consequence, the default behavior specified in
   Section 4.1 of [RFC8613] 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 case 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



Tiloca & Höglund        Expires 3 September 2026               [Page 17]

Internet-Draft           OSCORE-capable Proxies               March 2026


   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
   [RFC8768] 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 Section 2.2 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.

4.  Caching of OSCORE-Protected Responses

   Although it is not possible as per the original OSCORE specification
   [RFC8613], effective cacheability of OSCORE-protected responses at
   proxies can be achieved.  To this end, the approach defined in
   [I-D.ietf-core-cacheable-oscore] can be used, as based on
   Deterministic Requests protected with the pairwise mode of Group
   OSCORE [I-D.ietf-core-oscore-groupcomm] 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.




Tiloca & Höglund        Expires 3 September 2026               [Page 18]

Internet-Draft           OSCORE-capable Proxies               March 2026


   When using this approach, the following also applies in addition to
   what is defined in Section 2.4 and Section 2.6, 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 2 in Section 2.4 produces a
      cache hit.

      That is, such a message: i) is the one to be forwarded to (the
      next hop towards) the origin server, in case no cache hit occurs;
      and ii) is the result of an OSCORE decryption and verification at
      the proxy, in case 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 Section 2.6.

      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 specific rules about serving a request with a cached response are
   defined in Section 5.6 of [RFC7252] as well as in Section 7 of
   [I-D.ietf-core-groupcomm-proxy] for group communication scenarios.

5.  Establishment of OSCORE Security Contexts

   Like the original OSCORE specification [RFC8613], 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 [I-D.ietf-core-oscore-groupcomm] to
   protect their communications.

   *  When using OSCORE, the establishment of the OSCORE Security
      Context can rely on the authenticated key exchange protocol
      Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528].

      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 EDHOC with the first proxy in the chain and then with
      the origin server through the chain of proxies (see the example in
      Appendix B.4).



Tiloca & Höglund        Expires 3 September 2026               [Page 19]

Internet-Draft           OSCORE-capable Proxies               March 2026


      Furthermore, the additional use of the combined EDHOC + OSCORE
      request defined in [RFC9668] is particularly beneficial in this
      case (see the example in Appendix B.5) 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
      [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework
      for Authentication and Authorization in constrained environments
      [RFC9200].

      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.

6.  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 [RFC8724].  In
   particular, [I-D.ietf-schc-8824-update] 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.

   *  In case OSCORE is not used at all, the SCHC processing occurs hop-
      by-hop, by relying on SCHC Rules that are shared between two
      adjacent hops.

   *  In case 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
      Section 8.2 of [I-D.ietf-schc-8824-update]).  In particular, the
      following holds.






Tiloca & Höglund        Expires 3 September 2026               [Page 20]

Internet-Draft           OSCORE-capable Proxies               March 2026


      The SCHC processing occurs end-to-end as to the Inner SCHC
      Compression/Decompression.  This relies on Inner SCHC Rules that
      are shared between the two application endpoints, which act as
      OSCORE endpoints and share the OSCORE Security Context used.

      The SCHC processing occurs hop-by-hop as to the Outer SCHC
      Compression/Decompression.  This relies on Outer SCHC Rules that
      are shared between two adjacent hops.

   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
      shared with the other OSCORE endpoint.

   *  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 shared with the (next hop towards the) destination
      application endpoint.

   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.

   1.  It decrypts an incoming message with the OSCORE Security Context
       shared with the other OSCORE endpoint.

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






Tiloca & Höglund        Expires 3 September 2026               [Page 21]

Internet-Draft           OSCORE-capable Proxies               March 2026


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

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

7.  Security Considerations

   The same security considerations about CoAP [RFC7252] and group
   communication for CoAP [I-D.ietf-core-groupcomm-bis] apply to this
   document.  The same security considerations from [RFC8613] and
   [I-D.ietf-core-oscore-groupcomm] 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
   Section 7 of [I-D.ietf-core-oscore-groupcomm]), 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.

7.1.  Preserving Location Anonymity

   As discussed in Section 2.4.1, a particularly sensitive server might
   use policies with strict criteria about what makes an OSCORE-
   protected request eligible to be decrypted and verified.





Tiloca & Höglund        Expires 3 September 2026               [Page 22]

Internet-Draft           OSCORE-capable Proxies               March 2026


   When a server using such policies receives an OSCORE-protected
   request (see Step 3 in Section 2.4), 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 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.

7.2.  Hop-Limit Option

   Section 3 of this document defines that the Hop-Limit Option
   [RFC8768] is of Class U for OSCORE.  This overrides the default
   behavior specified in Section 4.1 of [RFC8613], according to which
   the option would be processed as Class E for OSCORE.

   As discussed in Section 3, 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 chain, which in turn adds an
   outer Hop-Limit Option and thus further contributes to increasing the
   message size (see Section 3).

   Instead, having defined the Hop-Limit Option as Class U for OSCORE,
   the following holds by virtue of the procedure defined in
   Section 2.2.







Tiloca & Höglund        Expires 3 September 2026               [Page 23]

Internet-Draft           OSCORE-capable Proxies               March 2026


   *  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 [RFC9147]), 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.







Tiloca & Höglund        Expires 3 September 2026               [Page 24]

Internet-Draft           OSCORE-capable Proxies               March 2026


8.  IANA Considerations

   This document has the following actions for IANA.

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

9.  References

9.1.  Normative References

   [I-D.ietf-core-href]
              Bormann, C. and H. Birkholz, "Constrained Resource
              Identifiers", Work in Progress, Internet-Draft, draft-
              ietf-core-href-30, 21 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              href-30>.

   [I-D.ietf-core-oscore-groupcomm]
              Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
              and R. Höglund, "Group Object Security for Constrained
              RESTful Environments (Group OSCORE)", Work in Progress,
              Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23
              December 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-core-oscore-groupcomm-28>.

   [I-D.ietf-core-uri-path-abbrev]
              Amsüss, C. and M. Richardson, "URI-Path abbreviation in
              CoAP", Work in Progress, Internet-Draft, draft-ietf-core-
              uri-path-abbrev-02, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              uri-path-abbrev-02>.

   [I-D.ietf-schc-8824-update]
              Tiloca, M., Toutain, L., Martínez, I., and A. Minaburo,
              "Static Context Header Compression (SCHC) for the
              Constrained Application Protocol (CoAP)", Work in
              Progress, Internet-Draft, draft-ietf-schc-8824-update-07,
              1 December 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-schc-8824-update-07>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.



Tiloca & Höglund        Expires 3 September 2026               [Page 25]

Internet-Draft           OSCORE-capable Proxies               March 2026


   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7252>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8613>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/rfc/rfc8724>.

   [RFC8768]  Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained
              Application Protocol (CoAP) Hop-Limit Option", RFC 8768,
              DOI 10.17487/RFC8768, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8768>.

9.2.  Informative References

   [DAI-SNAC] Amsüss, C., "Discovery and capabilities of guard proxies
              for CoRE networks", December 2021,
              <http://dx.doi.org/10.1145/3488661.3494029>.

   [I-D.amsuess-t2trg-onion-coap]
              Amsüss, C., Tiloca, M., and R. Höglund, "Using onion
              routing with CoAP", Work in Progress, Internet-Draft,
              draft-amsuess-t2trg-onion-coap-04, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-amsuess-
              t2trg-onion-coap-04>.

   [I-D.ietf-ace-coap-est-oscore]
              Selander, G., Raza, S., Furuhed, M., Vučinić, M., and T.
              Claeys, "Protecting EST Payloads with OSCORE", Work in
              Progress, Internet-Draft, draft-ietf-ace-coap-est-oscore-
              09, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
              coap-est-oscore-09>.






Tiloca & Höglund        Expires 3 September 2026               [Page 26]

Internet-Draft           OSCORE-capable Proxies               March 2026


   [I-D.ietf-ace-key-groupcomm-oscore]
              Tiloca, M. and F. Palombini, "Key Management for Group
              Object Security for Constrained RESTful Environments
              (Group OSCORE) Using Authentication and Authorization for
              Constrained Environments (ACE)", Work in Progress,
              Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-20, 25
              February 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ace-key-groupcomm-oscore-20>.

   [I-D.ietf-core-cacheable-oscore]
              Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in
              Progress, Internet-Draft, draft-ietf-core-cacheable-
              oscore-00, 22 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              cacheable-oscore-00>.

   [I-D.ietf-core-coap-pm]
              Fioccola, G., Zhou, T., Cociglio, M., Bulgarella, F., and
              Y. Zhu, "Constrained Application Protocol (CoAP)
              Performance Measurement Option", Work in Progress,
              Internet-Draft, draft-ietf-core-coap-pm-05, 20 October
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              core-coap-pm-05>.

   [I-D.ietf-core-coap-pubsub]
              Jimenez, J., Koster, M., and A. Keränen, "A publish-
              subscribe architecture for the Constrained Application
              Protocol (CoAP)", Work in Progress, Internet-Draft, draft-
              ietf-core-coap-pubsub-18, 28 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              coap-pubsub-18>.

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E. and M. Tiloca, "Group Communication for the
              Constrained Application Protocol (CoAP)", Work in
              Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
              18, 10 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              groupcomm-bis-18>.

   [I-D.ietf-core-groupcomm-proxy]
              Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group
              Communication", Work in Progress, Internet-Draft, draft-
              ietf-core-groupcomm-proxy-05, 3 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              groupcomm-proxy-05>.





Tiloca & Höglund        Expires 3 September 2026               [Page 27]

Internet-Draft           OSCORE-capable Proxies               March 2026


   [I-D.ietf-core-multicast-notifications-proxy]
              Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini,
              "Using Proxies for Observe Notifications as CoAP Multicast
              Responses", Work in Progress, Internet-Draft, draft-ietf-
              core-multicast-notifications-proxy-00, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              multicast-notifications-proxy-00>.

   [I-D.ietf-core-observe-multicast-notifications]
              Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini,
              "Observe Notifications as CoAP Multicast Responses", Work
              in Progress, Internet-Draft, draft-ietf-core-observe-
              multicast-notifications-13, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              observe-multicast-notifications-13>.

   [I-D.ietf-core-transport-indication]
              Amsüss, C. and M. S. Lenders, "CoAP Transport Indication",
              Work in Progress, Internet-Draft, draft-ietf-core-
              transport-indication-09, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              transport-indication-09>.

   [LwM2M-Core]
              Open Mobile Alliance, "Lightweight Machine to Machine
              Technical Specification - Core, Approved Version 1.2.2,
              OMA-TS-LightweightM2M_Core-V1_2_2-20240613-A", June 2024,
              <https://www.openmobilealliance.org/release/
              LightweightM2M/V1_2_2-20240613-A/OMA-TS-
              LightweightM2M_Core-V1_2_2-20240613-A.pdf>.

   [LwM2M-Gateway]
              Open Mobile Alliance, "Lightweight Machine to Machine
              Gateway Technical Specification - Approved Version 1.1.1,
              OMA-TS-LWM2M_Gateway-V1_1_1-20240312-A", March 2024,
              <https://www.openmobilealliance.org/release/LwM2M_Gateway/
              V1_1_1-20240312-A/OMA-TS-LWM2M_Gateway-
              V1_1_1-20240312-A.pdf>.

   [LwM2M-Transport]
              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", June 2024,
              <https://www.openmobilealliance.org/release/
              LightweightM2M/V1_2_2-20240613-A/OMA-TS-
              LightweightM2M_Transport-V1_2_2-20240613-A.pdf>.




Tiloca & Höglund        Expires 3 September 2026               [Page 28]

Internet-Draft           OSCORE-capable Proxies               March 2026


   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/rfc/rfc7030>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/rfc/rfc7641>.

   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8742>.

   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/rfc/rfc9147>.

   [RFC9200]  Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments Using the OAuth 2.0 Framework
              (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9200>.

   [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
              "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
              DOI 10.17487/RFC9528, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9528>.

   [RFC9668]  Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
              (EDHOC) with the Constrained Application Protocol (CoAP)
              and Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024,
              <https://www.rfc-editor.org/rfc/rfc9668>.

   [TOR-SPEC] Tor Project, "Tor Specifications",
              <https://spec.torproject.org/>.

Appendix A.  Use Cases

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







Tiloca & Höglund        Expires 3 September 2026               [Page 29]

Internet-Draft           OSCORE-capable Proxies               March 2026


A.1.  CoAP Group Communication with Proxies

   CoAP also supports one-to-many group communication
   [I-D.ietf-core-groupcomm-bis], e.g., over IP multicast, which can be
   protected end-to-end between origin client and origin servers by
   using Group OSCORE [I-D.ietf-core-oscore-groupcomm].

   This communication model can be assisted by intermediaries such as a
   CoAP forward-proxy or reverse-proxy, which relays a group request to
   the origin servers.  If Group OSCORE is used, the proxy is
   intentionally not a member of the OSCORE group.  Furthermore,
   [I-D.ietf-core-groupcomm-proxy] defines a signaling protocol between
   origin client and proxy, to ensure that responses from the different
   origin servers are forwarded back to the origin client within a time
   interval set by the client and that 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 Section 4 of [I-D.ietf-core-groupcomm-proxy]).  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.

A.2.  CoAP Observe Notifications over Multicast

   The Observe extension for CoAP [RFC7641] allows a client to register
   its interest in "observing" a resource at a server.  The server can
   then send back notification responses upon changes in the resource
   representation, all matching with the original observation request.

   In some applications, such as based on publish-subscribe
   communication [I-D.ietf-core-coap-pubsub], multiple clients are
   interested in observing the same resource at the same server.  In the
   interest of such applications,
   [I-D.ietf-core-observe-multicast-notifications] 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.









Tiloca & Höglund        Expires 3 September 2026               [Page 30]

Internet-Draft           OSCORE-capable Proxies               March 2026


   In case the clients and the server use Group OSCORE for end-to-end
   security and a proxy is also involved, an additional step is required
   (see Section 4 of [I-D.ietf-core-multicast-notifications-proxy]).
   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 Section 10.1 of
   [I-D.ietf-core-multicast-notifications-proxy]).  Like for the use
   case in Appendix A.1, 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.

A.3.  LwM2M Client and External Application Server

   The Lightweight Machine-to-Machine (LwM2M) protocol [LwM2M-Core]
   enables a LwM2M Client device to securely bootstrap and then register
   at a LwM2M Server, with which it will perform most of its following
   communication exchanges.  As per the transport bindings specification
   of LwM2M [LwM2M-Transport], the LwM2M Client and LwM2M Server can use
   CoAP and OSCORE to secure their communications at the application
   layer, including during the device registration process.

   Furthermore, Section 5.4.1 of [LwM2M-Transport] specifies that:

   |  OSCORE MAY also be used between LwM2M endpoint and non-LwM2M
   |  endpoint, e.g. between an Application Server and a LwM2M Client
   |  via a LwM2M server.  Both the LwM2M endpoint and non-LwM2M
   |  endpoint MUST implement OSCORE and be provisioned with an OSCORE
   |  Security Context 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 Appendix A.1, this also allows the LwM2M
   Server to identify the LwM2M Client, before forwarding its request
   outside the LwM2M domain and towards the external Application Server.










Tiloca & Höglund        Expires 3 September 2026               [Page 31]

Internet-Draft           OSCORE-capable Proxies               March 2026


A.4.  LwM2M Gateway

   The specification [LwM2M-Gateway] 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 it to an end IoT device.  With particular
   reference to CoAP and the related transport binding specified in
   [LwM2M-Transport], 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 Section 5.7.3 of [RFC7252]).  That is, in
   addition to its own resources, the LwM2M Gateway serves the resources
   hosted by each end IoT device standing behind it, as exposed by the
   LwM2M Gateway under a dedicated URI path.  As per [LwM2M-Gateway],
   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 the IoT device.

   As per Section 7 of [LwM2M-Gateway], 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.

A.5.  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.








Tiloca & Höglund        Expires 3 September 2026               [Page 32]

Internet-Draft           OSCORE-capable Proxies               March 2026


   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
   Section 5 of [I-D.ietf-core-transport-indication]).

A.6.  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 [DAI-SNAC] 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 the client trusts the proxy to perform its tasks in a
   privacy-oriented way, the client can rely on their shared secure
   communication association 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.

A.7.  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 [I-D.ietf-core-coap-pm] relies on the
      Performance Measurement Option to enable network telemetry for
      CoAP communications.  This makes it possible to efficiently
      measure Round-Trip Time and message losses, both end-to-end and
      hop-by-hop.  In particular, on-path probes such as intermediary
      proxies can be deployed to perform measurements hop-by-hop.






Tiloca & Höglund        Expires 3 September 2026               [Page 33]

Internet-Draft           OSCORE-capable Proxies               March 2026


      When OSCORE is used in deployments including on-path probes, an
      inner Performance Measurement Option is protected end-to-end
      between the two application endpoints and enables end-to-end
      measurements between those.  At the same time, an outer
      Performance Measurement Option allows also hop-by-hop measurements
      to be performed by relying on an on-path probe.

      Therefore, it is preferable to have a secure association with an
      on-path probe, in order to also ensure the integrity of the hop-
      by-hop measurements exchanged with the probe.

   *  The method specified in [I-D.ietf-ace-coap-est-oscore] enables
      public-key certificate enrollment for Internet of Things
      deployments.  This leverages payload formats defined in Enrollment
      over Secure Transport (EST) [RFC7030], 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.







Tiloca & Höglund        Expires 3 September 2026               [Page 34]

Internet-Draft           OSCORE-capable Proxies               March 2026


      Building on that, it is also possible to enable the operation of
      hidden services and clients through onion routing with CoAP
      [I-D.amsuess-t2trg-onion-coap], similarly to how Tor (The Onion
      Router) [TOR-SPEC] enables it for TCP-based protocols.

Appendix B.  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 Appendix A.1 of
   [RFC8613], 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.

B.1.  With Forward-Proxy; OSCORE: C-S, C-P

   In the example shown in Figure 1, 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.

   Client  Proxy  Server
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_S   |       |
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_P   |       |
     |       |       |
     +------>|       |     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-Host: "example.com",
     |       |       |            Proxy-Scheme: "coap",



Tiloca & Höglund        Expires 3 September 2026               [Page 35]

Internet-Draft           OSCORE-capable Proxies               March 2026


     |       |       |            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,



Tiloca & Höglund        Expires 3 September 2026               [Page 36]

Internet-Draft           OSCORE-capable Proxies               March 2026


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

       Figure 1: Use of OSCORE between Client-Server and Client-Proxy

B.2.  With Forward-Proxy; OSCORE: C-S, P-S

   In the example shown in Figure 2, 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.

   Client  Proxy  Server
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_S   |       |
     |       |       |
     +------>|       |         Code: 0.02 (POST)
     | POST  |       |        Token: 0x8c
     |       |       |     Uri-Host: "example.com"
     |       |       | Proxy-Scheme: "coap"
     |       |       |       OSCORE: [kid:0x5f, Partial IV:42]
     |       |       |         0xff
     |       |       |      Payload: {Code: 0.01 (GET),
     |       |       |                Uri-Path: "alarm_status"
     |       |       |               } // Encrypted with CTX_C_S



Tiloca & Höglund        Expires 3 September 2026               [Page 37]

Internet-Draft           OSCORE-capable Proxies               March 2026


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



Tiloca & Höglund        Expires 3 September 2026               [Page 38]

Internet-Draft           OSCORE-capable Proxies               March 2026


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

       Figure 2: Use of OSCORE between Client-Server and Proxy-Server

B.3.  With Forward-Proxy; OSCORE: C-S, C-P, P-S

   In the example shown in Figure 3, 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.

   Client  Proxy  Server
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_S   |       |
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_P   |       |



Tiloca & Höglund        Expires 3 September 2026               [Page 39]

Internet-Draft           OSCORE-capable Proxies               March 2026


     |       |       |
     +------>|       |     Code: 0.02 (POST)
     | POST  |       |    Token: 0x8c
     |       |       | Uri-Host: "example.com",
     |       |       |   OSCORE: [kid:0x20, Partial IV:31]
     |       |       |     0xff
     |       |       |  Payload: {Code: 0.02 (POST),
     |       |       |            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
     |       |       |  OSCORE: [kid:0xd4, Partial IV:53]
     |       |       |    0xff
     |       |       | Payload: {Code: 0.02 (POST),
     |       |       |           Uri-Host: "example.com",
     |       |       |           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
     |       |       |



Tiloca & Höglund        Expires 3 September 2026               [Page 40]

Internet-Draft           OSCORE-capable Proxies               March 2026


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



Tiloca & Höglund        Expires 3 September 2026               [Page 41]

Internet-Draft           OSCORE-capable Proxies               March 2026


   Curly brackets { ... } indicate encrypted data.

      Figure 3: Use of OSCORE between Client-Server, Client-Proxy, and
                                Proxy-Server

B.4.  With Forward-Proxy and EDHOC; OSCORE: C-S, C-P

   In the example shown in Figure 4, 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 EDHOC [RFC9528].

   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 Appendix B.1.

   Client  Proxy  Server
     |       |       |
     +------>|       |     Code: 0.02 (POST)
     | POST  |       |    Token: 0xf3
     |       |       | Uri-Path: ".well-known"
     |       |       | Uri-Path: "edhoc"
     |       |       |     0xff
     |       |       |  Payload: (true, EDHOC message_1)
     |       |       |
     |<------+       |     Code: 2.04 (Changed)
     |  2.04 |       |    Token: 0xf3
     |       |       |     0xff
     |       |       |  Payload: EDHOC message_2
     |       |       |
   Establish |       |
   CTX_C_P   |       |
     |       |       |
     +------>|       |     Code: 0.02 (POST)
     | POST  |       |    Token: 0x82
     |       |       | Uri-Path: ".well-known"
     |       |       | Uri-Path: "edhoc"
     |       |       |     0xff



Tiloca & Höglund        Expires 3 September 2026               [Page 42]

Internet-Draft           OSCORE-capable Proxies               March 2026


     |       |       |  Payload: (C_R, EDHOC 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, EDHOC 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, EDHOC message_1)
     |       |       |
     |       |<------+     Code: 2.04 (Changed)
     |       |  2.04 |    Token: 0xa5
     |       |       |     0xff
     |       |       |  Payload: EDHOC message_2
     |       |       |
     |     Encrypt   |
     |     RESP with |
     |     CTX_C_P   |
     |       |       |
     |<------+       |     Code: 2.04 (Changed)
     |  2.04 |       |    Token: 0xbe



Tiloca & Höglund        Expires 3 September 2026               [Page 43]

Internet-Draft           OSCORE-capable Proxies               March 2026


     |       |       |   OSCORE: -
     |       |       |     0xff
     |       |       |  Payload: {Code: 2.04 (Changed),
     |       |       |            0xff,
     |       |       |            EDHOC 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, EDHOC 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, EDHOC message_3)
     |       |       |
     |       |     Establish
     |       |     CTX_C_S
     |       |       |
     |       |<------+
     |       |  ACK  |



Tiloca & Höglund        Expires 3 September 2026               [Page 44]

Internet-Draft           OSCORE-capable Proxies               March 2026


     |       |       |
     |<------+       |
     |  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),
     |       |       |            OSCORE: [kid:0x5f, Partial IV:0],
     |       |       |            Uri-Host: "example.com",
     |       |       |            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)



Tiloca & Höglund        Expires 3 September 2026               [Page 45]

Internet-Draft           OSCORE-capable Proxies               March 2026


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

      Figure 4: Use of OSCORE between Client-Server and Proxy-Server,
          with OSCORE Security Contexts established through EDHOC

B.5.  With Forward-Proxy and EDHOC (optimized); OSCORE: C-S, C-P

   In the example shown in Figure 5, message exchanges are protected as
   follows.




Tiloca & Höglund        Expires 3 September 2026               [Page 46]

Internet-Draft           OSCORE-capable Proxies               March 2026


   *  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 EDHOC [RFC9528].

   In particular, the client relies on the EDHOC + OSCORE request
   defined in [RFC9668] and denoted as COMB_REQ, in order to transport
   the last EDHOC 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 Appendix B.1.  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 EDHOC + OSCORE request that conveys
   both the last EDHOC message_3 from the client intended for the server
   and the first OSCORE-protected application CoAP request combined
   together.

   Client  Proxy  Server
     |       |       |
     +------>|       |     Code: 0.02 (POST)
     | POST  |       |    Token: 0xf3
     |       |       | Uri-Path: ".well-known"
     |       |       | Uri-Path: "edhoc"
     |       |       |     0xff
     |       |       |  Payload: (true, EDHOC message_1)
     |       |       |
     |<------+       |    Code: 2.04 (Changed)
     |  2.04 |       |   Token: 0xf3
     |       |       |    0xff
     |       |       | Payload: EDHOC message_2
     |       |       |
   Establish |       |
   CTX_C_P   |       |
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_P   |       |
     |       |       |



Tiloca & Höglund        Expires 3 September 2026               [Page 47]

Internet-Draft           OSCORE-capable Proxies               March 2026


   Prepare   |       |
   COMB_REQ  |       |
   for P     |       |
   from REQ  |       |
     |       |       |
     +------>|       |     Code: 0.02 (POST)
     | POST  |       |    Token: 0x82
     |       |       |   OSCORE: [kid:0x20, Partial IV:0]
     |       |       |    EDHOC: -
     |       |       |     0xff
     |       |       |  Payload: EDHOC 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, EDHOC 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, EDHOC message_1)
     |       |       |
     |       |<------+    Code: 2.04 (Changed)
     |       |  2.04 |   Token: 0xa5
     |       |       |    0xff
     |       |       | Payload: EDHOC message_2
     |       |       |
     |     Encrypt   |
     |     RESP with |
     |     CTX_C_P   |
     |       |       |



Tiloca & Höglund        Expires 3 September 2026               [Page 48]

Internet-Draft           OSCORE-capable Proxies               March 2026


     |<------+       |     Code: 2.04 (Changed)
     |  2.04 |       |    Token: 0x82
     |       |       |   OSCORE: -
     |       |       |     0xff
     |       |       |  Payload: {Code: 2.04 (Changed),
     |       |       |            0xff,
     |       |       |            EDHOC 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,
     |       |       |            EDHOC message_3, // Intended for S
     |       |       |            {
     |       |       |             Code: 0.01 (GET),
     |       |       |             Uri-Path:"alarm_status"
     |       |       |            }   // Encrypted with CTX_C_S
     |       |       |           } // Encrypted with CTX_C_P
     |       |       |
     |     Decrypt   |



Tiloca & Höglund        Expires 3 September 2026               [Page 49]

Internet-Draft           OSCORE-capable Proxies               March 2026


     |     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: EDHOC 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



Tiloca & Höglund        Expires 3 September 2026               [Page 50]

Internet-Draft           OSCORE-capable Proxies               March 2026


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

      Figure 5: Use of OSCORE between Client-Server and Proxy-Server,
     with OSCORE Security Contexts established through EDHOC using the
                           EDHOC + OSCORE request

B.6.  With Reverse-Proxy; OSCORE: C-P, P-S

   In the example shown in Figure 6, 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



Tiloca & Höglund        Expires 3 September 2026               [Page 51]

Internet-Draft           OSCORE-capable Proxies               March 2026


   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 Section 6.4 of [RFC7252]).

   Client  Proxy  Server
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_P   |       |
     |       |       |
     +------>|       |     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



Tiloca & Höglund        Expires 3 September 2026               [Page 52]

Internet-Draft           OSCORE-capable Proxies               March 2026


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

       Figure 6: Use of OSCORE between Client-Proxy and Proxy-Server
                       (the Proxy is a Reverse-Proxy)

B.7.  With Reverse-Proxy; OSCORE: C-S, C-P, P-S

   In the example shown in Figure 7, 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.




Tiloca & Höglund        Expires 3 September 2026               [Page 53]

Internet-Draft           OSCORE-capable Proxies               March 2026


   *  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 Appendix A.4, 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 the 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
   Section 6.4 of [RFC7252]).

   Client  Proxy  Server
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_S   |       |
     |       |       |
   Encrypt   |       |
   REQ with  |       |
   CTX_C_P   |       |
     |       |       |
     +------>|       |    Code: 0.02 (POST)
     | POST  |       |   Token: 0x8c



Tiloca & Höglund        Expires 3 September 2026               [Page 54]

Internet-Draft           OSCORE-capable Proxies               March 2026


     |       |       |  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)



Tiloca & Höglund        Expires 3 September 2026               [Page 55]

Internet-Draft           OSCORE-capable Proxies               March 2026


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

       Figure 7: Use of OSCORE between Client-Proxy and Proxy-Server
                       (the Proxy is a Reverse-Proxy)




Tiloca & Höglund        Expires 3 September 2026               [Page 56]

Internet-Draft           OSCORE-capable Proxies               March 2026


Appendix C.  State Diagram: Protection of CoAP Options

   Figure 8 overviews the rules defined in Section 2.2, 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.

 ..........................
 :                        :
 : Source OSCORE endpoint :
 :                        :
 :..........o.............:
            o
            o
            o
 +----------o----------------------------------------------------------+
 |                                                                     |
 | I must protect an outgoing message M for another OSCORE endpoint X. |
 |                                                                     |
 | M includes a CoAP option OPT that is originally specified only as   |
 | an outer option (Class U or I) for OSCORE.                          |
 |                                                                     |
 +---------------------------------------------------------------------+
     |
     |
     v
 +-----------+         +------------------+         +------------------+
 | Did I add |---YES-->| 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, |           |                 |         |
   |   my next hop is not    |           NO               YES        |
   |   the immediately next  |           |                 |         |
   |   consumer of OPT       |           |                 |         |
   +-------------------------+           |                 |         |
     |                     |             |                 |         |



Tiloca & Höglund        Expires 3 September 2026               [Page 57]

Internet-Draft           OSCORE-capable Proxies               March 2026


     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 |<------+
              +----------------------------------------------+

   Figure 8: Protection of CoAP Options Originally Specified only as
                Outer Options (Class U or I) for OSCORE

Appendix D.  State Diagram: Processing of Incoming Requests

   Figure 9 overviews the processing of an incoming request, which is
   specified in Section 2.4.  The dotted boxes indicate ending states
   where the processing terminates.

              +-----------------------------------------------+
 Incoming --->|        Are there proxy-related options?       |<-------+
 request      +-----------------------------------------------+        |
                |                         ^             |              |
               YES          ..........    |             NO             |
                |           : Return :    |             |              |
                |           : 5.05   :    |             |              |
                |           :........:    |             |              |
                |               ^         |             |              |



Tiloca & Höglund        Expires 3 September 2026               [Page 58]

Internet-Draft           OSCORE-capable Proxies               March 2026


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



Tiloca & Höglund        Expires 3 September 2026               [Page 59]

Internet-Draft           OSCORE-capable Proxies               March 2026


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



Tiloca & Höglund        Expires 3 September 2026               [Page 60]

Internet-Draft           OSCORE-capable Proxies               March 2026


 | exact value of the included 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.

              Figure 9: Processing of an Incoming Request

Appendix E.  Document Updates

   This section is to be removed before publishing as an RFC.

E.1.  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.




Tiloca & Höglund        Expires 3 September 2026               [Page 61]

Internet-Draft           OSCORE-capable Proxies               March 2026


E.2.  Version -04 to -05

   *  Fixes in the examples of message exchange.

   *  Minor clarifications and editorial improvements.

E.3.  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.

E.4.  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.

E.5.  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.



Tiloca & Höglund        Expires 3 September 2026               [Page 62]

Internet-Draft           OSCORE-capable Proxies               March 2026


   *  Clarifications and editorial improvements.

E.6.  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 Christian Amsüss, Peter Blomqvist,
   Carsten Bormann, David Navarro, Göran Selander, and Lucas Åhl for
   their comments and feedback.





Tiloca & Höglund        Expires 3 September 2026               [Page 63]

Internet-Draft           OSCORE-capable Proxies               March 2026


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

Authors' Addresses

   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   SE-164 40 Kista
   Sweden
   Email: marco.tiloca@ri.se


   Rikard Höglund
   RISE AB
   Isafjordsgatan 22
   SE-164 40 Kista
   Sweden
   Email: rikard.hoglund@ri.se






























Tiloca & Höglund        Expires 3 September 2026               [Page 64]
