Skip to main content

OSCORE-capable Proxies
draft-tiloca-core-oscore-capable-proxies-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Marco Tiloca , Rikard Höglund
Last updated 2021-07-12
Replaced by draft-ietf-core-oscore-capable-proxies
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-tiloca-core-oscore-capable-proxies-00
CoRE Working Group                                             M. Tiloca
Internet-Draft                                               R. Hoeglund
Updates: 8613 (if approved)                                      RISE AB
Intended status: Standards Track                            12 July 2021
Expires: 13 January 2022

                         OSCORE-capable Proxies
              draft-tiloca-core-oscore-capable-proxies-00

Abstract

   Object Security for Constrained RESTful Environments (OSCORE) can be
   used to protect CoAP messages end-to-end between two endpoints at the
   application layer, also in the presence of intermediaries such as
   proxies.  This document defines how OSCORE is used to protect CoAP
   messages also between an origin application endpoint and an
   intermediary, or between two intermediaries.  Besides, it defines how
   a CoAP message can be double-protected through "OSCORE-in-OSCORE",
   i.e., both end-to-end between origin application endpoints, as well
   as between an application endpoint and an intermediary or between two
   intermediaries.  Thus, this document updates RFC 8613.  The same
   approach applies to Group OSCORE, for protecting CoAP messages when
   group communication with intermediaries is used.

Discussion Venues

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

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

   Source for this draft and an issue tracker can be found at
   https://gitlab.com/crimson84/draft-tiloca-core-oscore-to-proxies.

Status of This Memo

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

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

Tiloca & Höglund         Expires 13 January 2022                [Page 1]
Internet-Draft           OSCORE-capable Proxies                July 2021

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

   This Internet-Draft will expire on 13 January 2022.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  UC1 - CoAP Group Communication with Proxies . . . . . . .   5
     2.2.  UC2 - CoAP Observe Notifications over Multicast . . . . .   5
     2.3.  UC3 - LwM2M Client and External Application Server  . . .   6
   3.  Possible Configurations . . . . . . . . . . . . . . . . . . .   7
     3.1.  Configurations without End-to-End Security  . . . . . . .   7
     3.2.  Configurations with End-to-End Security . . . . . . . . .   8
   4.  Request Processing  . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Protecting the Request at the Client  . . . . . . . . . .   9
     4.2.  Verifying the Request at the Proxy  . . . . . . . . . . .  11
     4.3.  Forwarding the Request to the Server  . . . . . . . . . .  13
     4.4.  Verifying the Request at the Server . . . . . . . . . . .  13
   5.  Response Processing . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  Protecting the Response at the Server . . . . . . . . . .  15
     5.2.  Verifying the Response at the Proxy . . . . . . . . . . .  17
     5.3.  Forwarding the Response to the Client . . . . . . . . . .  17
     5.4.  Verifying the Response at the Client  . . . . . . . . . .  18
   6.  Response Caching  . . . . . . . . . . . . . . . . . . . . . .  20
   7.  Chain of Intermediaries . . . . . . . . . . . . . . . . . . .  20
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  20
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  20

Tiloca & Höglund         Expires 13 January 2022                [Page 2]
Internet-Draft           OSCORE-capable Proxies                July 2021

     Normative References  . . . . . . . . . . . . . . . . . . . . .  20
     Informative References  . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

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

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

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

   For a number of use cases (see Section 2), it is required and/or
   beneficial that communications are secured also between an
   application endpoint (i.e., a CoAP origin client/server) and an
   intermediary, as well as between two adjacent intermediaries in a
   chain.  This especially applies to the communication leg between the
   CoAP origin client and the adjacent intermediary acting as next hop
   towards the origin server.

   In such cases, and especially if the origin client already uses
   OSCORE to achieve end-to-end security with the origin server, it
   would be convenient that OSCORE is used also to secure communications
   between the origin client and its next hop.  However, the original
   specification [RFC8613] does not define how OSCORE can be used to
   protect CoAP messages in such communication leg, i.e., by considering
   the intermediary as an "OSCORE endpoint".

   This document fills this gap, and updates [RFC8613] as follows.

   *  It defines how OSCORE is used to protect a CoAP message in the
      communication leg between: i) an origin client/server and an
      intermediary; or ii) two adjacent intermediaries in an
      intermediary chain.  That is, besides origin clients/servers, it
      allows also intermediaries to be possible "OSCORE endpoints".

Tiloca & Höglund         Expires 13 January 2022                [Page 3]
Internet-Draft           OSCORE-capable Proxies                July 2021

   *  It explicitly admits a CoAP message to be double-protected through
      "OSCORE-in-OSCORE".  This is the case when the message is first
      OSCORE-protected end-to-end between the origin client and origin
      server, and then further OSCORE-protected over the leg between the
      current and next hop (e.g., the origin client and the adjacent
      intermediary acting as next hop towards the origin server).

   What defined in this document is applicable also when Group OSCORE is
   used, for protecting CoAP messages in group communication scenarios
   that rely on intermediaries.

1.1.  Terminology

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

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

   In addition, this document uses to the following terms.

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

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

   *  Application endpoint: a source or destination application
      endpoint.

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

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

   *  OSCORE endpoint: a source/destination OSCORE endpoint.  An OSCORE
      endpoint is not necessarily also an application endpoint with
      respect to a certain message.

Tiloca & Höglund         Expires 13 January 2022                [Page 4]
Internet-Draft           OSCORE-capable Proxies                July 2021

   *  Proxy-related option: the Proxy-URI Option, the Proxy-Scheme
      Option, or any of the Uri-* Options.

   *  OSCORE-in-OSCORE: the process by which a message protected with
      (Group) OSCORE is further protected with (Group) OSCORE.  This
      means that, after the first OSCORE decryption/verification, the
      resulting message is again an OSCORE-protected message.

2.  Use Cases

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

2.1.  UC1 - CoAP Group Communication with Proxies

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

   This communication model can be assisted by intermediaries such as a
   CoAP forward-proxy or reverse-proxy, which relays a group request to
   the origin servers.  If Group OSCORE is used, the proxy is
   intentionally not a member of the OSCORE group.  Furthermore,
   [I-D.tiloca-core-groupcomm-proxy] defines a signaling protocol
   between origin client and proxy, to ensure that responses from the
   different origin servers are forwarded back to the origin client
   within a time interval set by the client, and that they can be
   distinguished from one another.

   In particular, it is required that the proxy identifies the origin
   client as allowed-listed, before forwarding a group request to the
   servers (see Section 4 of [I-D.tiloca-core-groupcomm-proxy]).  This
   requires a security association between the origin client and the
   proxy, which would be convenient to provide with a dedicated OSCORE
   Security Context between the two, since the client is possibly using
   also Group OSCORE with the origin servers.

2.2.  UC2 - CoAP Observe Notifications over Multicast

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

   In some applications, such as pub-sub [I-D.ietf-core-coap-pubsub],
   multiple clients are interested to observe the same resource at the
   same server.  Hence, [I-D.ietf-core-observe-multicast-notifications]

Tiloca & Höglund         Expires 13 January 2022                [Page 5]
Internet-Draft           OSCORE-capable Proxies                July 2021

   defines a method that allows the server to send a multicast
   notification to all the observer clients at once, e.g., over IP
   multicast.  To this end, the server synchronizes the clients, by
   providing them with a common "phantom observation request".

   In case the clients and the server use Group OSCORE for end-to-end
   security and a proxy is also involved, an additional step is required
   (see Section 10 of [I-D.ietf-core-observe-multicast-notifications]).
   That is, clients are in turn required to provide the proxy with the
   obtained "phantom observation request", thus enabling the proxy to
   receive the multicast notifications from the server.

   Therefore, it is preferable to have a security associations also
   between each client and the proxy, to especially ensure the integrity
   of that information provided to the proxy (see Section 13.1 of
   [I-D.ietf-core-observe-multicast-notifications]).  Like for the use
   case UC1 in Section 2.1, this would be conveniently achieved with a
   dedicated OSCORE Security Context between a client and the proxy,
   since the client is also using Group OSCORE with the origin server.

2.3.  UC3 - LwM2M Client and External Application Server

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

   Furthermore, Section 5.5.1 of [LwM2M-Transport] specifies that:
   "OSCORE MAY also be used between LwM2M endpoint and non-LwM2M
   endpoint, e.g., between an Application Server and a LwM2M Client via
   a LwM2M server.  Both the LwM2M endpoint and non-LwM2M endpoint MUST
   implement OSCORE and be provisioned with an OSCORE Security Context."

   In such a case, the LwM2M Server can practically act as forward-proxy
   between the LwM2M Client and the external Application Server.  At the
   same time, the LwM2M Client and LwM2M Server must continue protecting
   communications on their leg using their Security Context.  Like for
   the use case UC1 in Section 2.1, this also allows the LwM2M Server to
   identify the LwM2M Client, before forwarding its request outside the
   LwM2M domain and towards the external Application Server.

Tiloca & Höglund         Expires 13 January 2022                [Page 6]
Internet-Draft           OSCORE-capable Proxies                July 2021

3.  Possible Configurations

   This section provides an overview of different security
   configurations referred in the document.  The configurations differ
   on whether OSCORE is used or not in a certain communication leg.

   For simplicity, only one intermediary is considered, as a CoAP-to-
   CoAP forward-proxy standing between one CoAP client and one CoAP
   server.  The same can be extended to cover a chain of intermediaries,
   or a group communication scenario where CoAP requests are intended to
   multiple servers and possibly protected end-to-end with Group OSCORE.

   The used notation denotes the origin client with C, the origin server
   with S and the proxy with P.  Each configuration is denoted by CF-x,
   with x a positive integer number expressed by the bits (b2, b1, b0),
   i.e., x = b0 + (2 * b1) + (4 * b2).

   In particular, for each configuration CF-x:

   *  C and P use OSCORE between themselves if and only if b0 = 1.

   *  P and S use OSCORE between themselves if and only if b1 = 1.

   *  C and S use OSCORE between themselves if and only if b2 = 1.

   For convenience, the configurations are split into two sets.  That
   is, Section 3.1 overviews those where C and S do not use OSCORE
   between themselves (b2 = 0), while Section 3.2 overviews those where
   C and S use OSCORE between themselves (b2 = 1).

3.1.  Configurations without End-to-End Security

   Figure 1 shows the different configurations where OSCORE is not used
   end-to-end by the two application endpoints C and S.  That is, none
   of the shown configurations include the leg "C-S", i.e., b2 = 0.

   In the configurations CF-1, CF-2 and CF-3, the proxy uses OSCORE with
   C and/or S, hence the legs "C-P" and/or "P-S" are also included.
   None of these configurations results in using "OSCORE-in-OSCORE".

Tiloca & Höglund         Expires 13 January 2022                [Page 7]
Internet-Draft           OSCORE-capable Proxies                July 2021

             +--------------+-------+-------+-------+-------+
             | Conf. name   | CF-0  | CF-1  | CF-2  | CF-3  |
             | (b2, b1, b0) | (000) | (001) | (010) | (011) |
             +--------------+-------+-------+-------+-------+
             | Comm. legs   |       |       |       |       |
             | using OSCORE |       |  C-P  |       |  C-P  |
             |              |       |       |  P-S  |  P-S  |
             +--------------+-------+-------+-------+-------+
                C=Client, P=Proxy, S=Server

           Figure 1: Configurations without end-to-end security.

   Note that:

   *  CF-0 is the canonical case defined in [RFC7252] with no security
      at the application layer.

   *  CF-1 is relevant for the use cases UC1 and UC3 in Section 2, where
      end-to-end security is not provided between client and server(s).
      Instead, it is not relevant for UC2, since that use case would
      require secure communication between clients and proxy only when
      Group OSCORE is also used for end-to-security between the observer
      clients and the server (see Section 2.2).

   *  CF-2 can be seen as the canonical case of [RFC8613], with P acting
      as client with S.

   *  CF-3 can be seen as the canonical case of [RFC8613], applied
      separately to the two legs "C-P" (with P acting as server) and
      "P-S" (with P acting as client).

3.2.  Configurations with End-to-End Security

   Figure 2 shows the different configurations where OSCORE is used end-
   to-end by the two application endpoints C and S.  That is, all the
   shown configurations include the leg "C-S", i.e., b2 = 1.

   In the configurations CF-5, CF-6 and CF-7, the proxy uses OSCORE with
   C and/or S, hence the legs "C-P" and/or "P-S" are also included.
   Therefore, these configurations result in double-protecting the CoAP
   messages originated at C and S, and are thus marked with "(*)" to
   indicate the use of "OSCORE-in-OSCORE".

Tiloca & Höglund         Expires 13 January 2022                [Page 8]
Internet-Draft           OSCORE-capable Proxies                July 2021

         +--------------+---------+---------+---------+---------+
         | Conf. name   |  CF-4   |  CF-5   |  CF-6   |  CF-7   |
         | (b2, b1, b0) |  (100)  |  (101)  |  (110)  |  (111)  |
         +--------------+---------+---------+---------+---------+
         | Comm. legs   | C-S     | C-S     | C-S     | C-S     |
         | using OSCORE |         | C-P (*) |         | C-P (*) |
         |              |         |         | P-S (*) | P-S (*) |
         +--------------+---------+---------+---------+---------+
            C=Client, P=Proxy, S=Server
            (*) OSCORE-in-OSCORE

             Figure 2: Configurations with end-to-end security.

   Note that:

   *  CF-4 is the canonical case defined in [RFC8613].

   *  CF-5 is relevant for the use cases UC1, UC2 and UC3 in Section 2.

   *  CF-7 is relevant for the use cases UC2 and UC3 in Section 2.
      Instead, it is not relevant for UC1, since that would imply that P
      is also a member of the OSCORE group including the servers, which
      is not desirable (see Section 2.1).

4.  Request Processing

   This section extends the actions performed to protect an outgoing
   request, with respect to [RFC8613] or
   [I-D.ietf-core-oscore-groupcomm] when OSCORE or Group OSCORE is used,
   respectively.  Throughout the text, the configurations defined in
   Section 3 are also recalled by means of the bits (b2, b1, b0), to
   indicate the communication leg(s) using OSCORE.

   The following assumes the presence of a single intermediary acting as
   CoAP-to-CoAP Forward-Proxy between the origin CoAP client and a
   single origin CoAP server.

4.1.  Protecting the Request at the Client

   The client performs the following steps.

   1.  The client prepares the CoAP request REQ for the origin server,
       which is the intended destination application endpoint.

   2.  Since the client knows that a proxy is involved as next hop, the
       client adds the appropriate proxy-related options to the request.

Tiloca & Höglund         Expires 13 January 2022                [Page 9]
Internet-Draft           OSCORE-capable Proxies                July 2021

   3.  If the client uses (Group) OSCORE with the origin server (b2 =
       1), it performs the following actions.  Otherwise, it moves to
       step 4.

       *  The client protects the request REQ as it normally happens
          with OSCORE or Group OSCORE, using the Security Context shared
          with the server.

       *  The result is a protected request REQ* including an OSCORE
          option.  The intended destination OSCORE endpoint is the
          origin server.

       *  REQ takes REQ*, and the client moves to step 4.

   4.  If the client uses (Group) OSCORE with the proxy (b0 = 1), it
       performs the following actions.  Otherwise, it moves to step 5.

       *  The client protects the request REQ with (Group) OSCORE, using
          the Security Context shared with the Proxy.  Note that the
          Proxy-Uri option, if present at this point in time (b2 = 0 and
          b0 = 1), is first decomposed as per Section 4.1.3.3 of
          [RFC8613].

          Unlike in [RFC8613], the following options are processed as
          Class E, if present.

          -  Proxy-Scheme, Uri-Host, Uri-Port, Uri-Path and Uri-Query.

          -  OSCORE, which is present if (Group) OSCORE is used between
             the origin client and the origin server (i.e., b2 = 1 and
             b0 = 1, hence step 3 above was performed).  This is
             "OSCORE-in-OSCORE" and deviates from [RFC8613].

          -  Multicast-Signaling Option, defined in
             [I-D.tiloca-core-groupcomm-proxy].

          -  Listen-To-Multicast-Responses Option, defined in
             [I-D.ietf-core-observe-multicast-notifications].

          -  Any other option that is intended to be accessed and
             consumed by the proxy.

       *  The result is a protected request REQ** including its own
          outer OSCORE option, i.e., REQ** = Enc(REQ).  The intended
          destination OSCORE endpoint is the proxy.

       *  REQ takes REQ**, and the client moves to step 5.

Tiloca & Höglund         Expires 13 January 2022               [Page 10]
Internet-Draft           OSCORE-capable Proxies                July 2021

   5.  The client sends the request REQ to the proxy.

4.2.  Verifying the Request at the Proxy

   The proxy performs the following steps.

   1.  The proxy receives the request REQ from the origin client.

   2.  The proxy assesses which alternative it is.

       *  Alt 2.1 - The request REQ includes proxy-related options as
          already visible to the proxy (b0 = 0).  Hence, the request has
          to be forwarded to the origin server.

          In this case, the proxy moves to step 4.

          Note that:

          -  The request REQ includes an OSCORE option if the proxy is
             neither the destination application endpoint nor the
             destination OSCORE endpoint (b2 = 1 and b0 = 0).

          -  The request REQ does not include an OSCORE option if the
             proxy is not the destination application endpoint and no
             OSCORE is involved (b2 = 0 and b0 = 0).

       *  Alt 2.2 - The request REQ does not include proxy-related
          options but it includes an OSCORE option, as visible to the
          proxy (b0 = 1).  Hence, the proxy is the destination OSCORE
          endpoint.

          In this case, the proxy moves to step 3.

          Note that, at this point in time, the proxy does not know yet
          if it is going to act as proxy by forwarding the request, or
          if it is instead the actual destination application endpoint.

       *  Alt 2.3 - The request REQ does not include proxy-related
          options and it does not include an OSCORE option, as visible
          to the proxy (b2 = 0 and b0 = 0).  Hence, the proxy is the
          destination application endpoint with no OSCORE is involved.

          In this case, the proxy delivers the request REQ to the
          application for processing.

   3.  Coming from alternative 2.2 of step 2, the proxy unprotects the
       request REQ using the OSCORE Security Context shared with the
       origin client.

Tiloca & Höglund         Expires 13 January 2022               [Page 11]
Internet-Draft           OSCORE-capable Proxies                July 2021

       In case of an OSCORE-related error, the proxy responds to the
       client with an unprotected error response.  Following a
       successful processing, i.e. REQ* = Dec(REQ), three alternatives
       are possible.

       *  Alt 3.1 - The decrypted request REQ* includes proxy-related
          options.  Hence, the request has to be forwarded to the origin
          server.

          In this case, REQ takes REQ*, and the proxy moves to step 4.

          Note that:

          -  If the decrypted request REQ* includes an OSCORE option as
             well as proxy-related options, then the proxy is not the
             destination application endpoint, and OSCORE is used end-
             to-end between the origin client and origin server (b2 = 1
             and b0 = 1).  This is "OSCORE-in-OSCORE" and deviates from
             [RFC8613], i.e., under this specific outcome, it is fine
             for the proxy to find an OSCORE option in the decrypted
             request REQ*, and the message is not rejected.

          -  If the decrypted request REQ* does not include an OSCORE
             option, but it includes proxy-related options, then the
             proxy is not the destination application endpoint, and
             OSCORE is not used end-to-end between the origin client and
             origin server (b2 = 0 and b0 = 1).

       *  Alt 3.2 - The decrypted request REQ* does not include an
          OSCORE option, and it does not include any proxy-related
          option.  Hence, the proxy is the actual destination
          application endpoint.

          In this case, the proxy delivers the decrypted request REQ* to
          the application for processing.  The possible following
          response to the client occurs as per [RFC8613].

       *  Alt 3.3 - The decrypted request REQ* includes an OSCORE
          option, but it does not include any proxy-related option.

          This alternative is not valid, and the proxy MUST respond to
          the client with an error response.  This response MUST be
          protected with the (Group) OSCORE Security Context shared with
          the client.

   4.  The proxy proceeds with the forwarding of the request REQ to the
       origin server (see Section 4.3).

Tiloca & Höglund         Expires 13 January 2022               [Page 12]
Internet-Draft           OSCORE-capable Proxies                July 2021

4.3.  Forwarding the Request to the Server

   The proxy performs the following steps.

   1.  The proxy sets the Request URI in the request REQ, by consuming
       the Proxy-Uri or the Proxy-Scheme option as per Section 5.7.2 of
       [RFC7252].

   2.  If the proxy uses OSCORE with the origin server (b1 = 1), the
       proxy performs the following actions.  Otherwise, the proxy moves
       to step 3.

       *  The proxy protects the request REQ with OSCORE, i.e. REQ* =
          Enc(REQ), using the Security Context shared with the origin
          server.

          Unlike in [RFC8613], the OSCORE option, if present in the
          request REQ to protect, is processed as Class E.  This is the
          case if (Group) OSCORE is used between the origin client and
          the origin server (b2 = 1 and b1 = 1).  This is "OSCORE-in-
          OSCORE" and deviates from [RFC8613].

       *  The result is a protected request REQ* including an OSCORE
          option.  The intended destination OSCORE endpoint is the
          origin server.

       *  REQ takes REQ*, and the proxy moves to step 3.

   3.  The proxy forwards the request REQ to the origin server.

4.4.  Verifying the Request at the Server

   The server performs the following steps.

   1.  The server receives the request REQ from the proxy.

       In the considered scenario, the server is the actual origin
       server, hence it never encounters proxy-related options when
       processing the request (i.e., neither as outer nor as inner
       options).  This means that the server is the destination OSCORE
       endpoint with respect to any OSCORE option it encounters when
       processing the request.

   2.  The server assesses which alternative it is.

       *  Alt 2.1 - The request REQ does not include an OSCORE option
          (b2 = 0 and b1 = 0).

Tiloca & Höglund         Expires 13 January 2022               [Page 13]
Internet-Draft           OSCORE-capable Proxies                July 2021

          If proxy-related options are found at this point in time, this
          endpoint is not the actual destination application endpoint,
          and it should follow what described in Section 4.2, if it
          supports acting as proxy.

          Otherwise, the server is the destination application endpoint.
          Hence, the server moves to step 5.

       *  Alt 2.2 - The request REQ includes an OSCORE option (b2 = 1 or
          b1 = 1).

          In this case, the server is the destination OSCORE endpoint.
          Hence, the server moves to step 3.

   3.  Coming from alternative 2.2 of step 2, the server unprotects the
       request REQ using the OSCORE Security Context pointed by the
       OSCORE option, i.e. REQ* = Dec(REQ).

       In case of an OSCORE-related error, the server responds to the
       proxy with an unprotected error response.  Instead, following a
       successful processing, the two valid alternatives below are
       possible.

       If proxy-related options are found at this point in time, this
       endpoint is not the actual destination application endpoint.
       Hence, it should rather follow what described in Section 4.2, if
       it supports acting as proxy.

       *  Alt 3.1 - The decrypted request REQ* does not include an
          OSCORE option (b2 XOR b1 = 1).  Hence, the server is the
          destination application endpoint.

          In this case, REQ takes REQ*, and the server moves to step 5.

       *  Alt 3.2 - The decrypted request REQ* includes an OSCORE option
          (b2 = 1 and b1 = 1).  Hence, since the decrypted request REQ*
          does not include any proxy-related option, the server is the
          destination application endpoint, but it has to perform the
          actual end-to-end OSCORE decryption first.

          In this case, the server moves to step 4.

          Note that, this is "OSCORE-in-OSCORE" and deviates from
          [RFC8613], i.e., under this specific outcome, it is fine for
          the server to find an OSCORE option in the decrypted message,
          and the message is not rejected.

Tiloca & Höglund         Expires 13 January 2022               [Page 14]
Internet-Draft           OSCORE-capable Proxies                July 2021

   4.  Coming from alternative 3.2 of step 3, the server unprotects the
       inner request REQ* using the OSCORE Security Context pointed by
       the OSCORE option in REQ*, i.e. REQ** = Dec(REQ*).

       If any of the following cases occurs, the server MUST discard the
       request and MUST reply with an error response, which MUST be
       protected using the OSCORE Security Context shared with the
       proxy.

       *  An OSCORE-related error occurred when unprotecting REQ*, i.e.
          when using the OSCORE Security Context shared with the client.

       *  The decrypted request REQ** includes any proxy-related option.
          That is, proxy-related options cannot appear after having
          performed OSCORE decryption twice.

       *  The decrypted request REQ** includes an OSCORE option.  That
          is, at most two layers of OSCORE protection are admitted, i.e.
          one with the other application endpoint and one with the
          adjacent transport hop.

       Otherwise, REQ takes REQ**, and the server moves to step 5.

   5.  The server delivers the request REQ to the application for
       processing.  The possible following response to the proxy will
       happen as per [RFC7252], and possibly [RFC8613] or
       [I-D.ietf-core-oscore-groupcomm].

5.  Response Processing

   Following up on the process in Section 4, this section extends the
   actions performed to protect an outgoing response, with respect to
   [RFC8613] or [I-D.ietf-core-oscore-groupcomm] when OSCORE or Group
   OSCORE is used, respectively.  Throughout the text, the
   configurations defined in Section 3 are also recalled by means of the
   bits (b2, b1, b0), to indicate the communication leg(s) using OSCORE.

   The following assumes the presence of a single intermediary acting as
   CoAP-to-CoAP Forward-Proxy between the origin CoAP client and a
   single origin CoAP server.

5.1.  Protecting the Response at the Server

   The server performs the following steps.

   1.  The server possibly prepares a CoAP response RESP to send to the
       proxy, to be forwarded to the origin client as intended
       destination application endpoint.

Tiloca & Höglund         Expires 13 January 2022               [Page 15]
Internet-Draft           OSCORE-capable Proxies                July 2021

   2.  The server proceeds as follows.

       *  If the server performed only one OSCORE processing when
          receiving the request (b2 XOR b1 = 1), it moves to step 3.

       *  If the server performed two OSCORE processings when receiving
          the request (b2 = 1 and b1 = 1), it moves to step 4.

       *  If the server performed no OSCORE processing when receiving
          the request (b2 = 0 and b1 = 0), it moves to step 5.

   3.  The server protects the response RESP using the same OSCORE
       Security Context used to unprotect the request REQ.  The result
       is a protected response including an OSCORE option, i.e. RESP* =
       Enc(RESP).

       Then, RESP takes RESP*, and the server moves to step 5.

   4.  The server proceeds as follows.

       *  4.1.  The server protects the response RESP using the same
          OSCORE Security Context used for the second and last
          processing of the request, i.e. the one shared with the origin
          client.

          The result is a protected response including an OSCORE option,
          i.e. RESP* = Enc(RESP).

       *  4.2.  The server protects the encrypted response RESP* using
          the same OSCORE Security Context used for the first processing
          of the request, i.e. the one shared with the proxy as adjacent
          transport hop.

          The OSCORE option in the encrypted response RESP* is processed
          as class E.  If present, any other option that is intended to
          be accessed and consumed by the proxy is also processed as
          Class E.  This is "OSCORE-in-OSCORE" and deviates from
          [RFC8613].

          The result is a protected response including its own outer
          OSCORE option, i.e. RESP** = Enc(RESP*).

       4.3.  RESP takes RESP**, and the server moves to step 5.

   5.  The server sends the response RESP to the proxy.

Tiloca & Höglund         Expires 13 January 2022               [Page 16]
Internet-Draft           OSCORE-capable Proxies                July 2021

5.2.  Verifying the Response at the Proxy

   The proxy performs the following steps.

   1.  The proxy receives the response RESP from the origin server.

   2.  The proxy proceeds as follows.

       *  If the proxy protected the request forwarded to the server by
          using OSCORE (b1 = 1), it moves to step 3.

       *  If the proxy did not protect the request forwarded to the
          server by using OSCORE (b1 = 0), it moves to step 4.

   3.  The proxy proceeds as follows.

       If the received response RESP is unprotected, the proxy
       interprets it as an OSCORE-related error at the server.  This
       concerns the OSCORE association between proxy and server, and it
       is up to the proxy to handle this issue.

       Otherwise, i.e., the received response RESP includes an outer
       OSCORE option, the proxy unprotects the response RESP, with the
       OSCORE Security Context shared with the server.  This results in
       a decrypted response RESP* = Dec(RESP).

       If the OSCORE protection of the request performed by the proxy
       did not result in "OSCORE-in-OSCORE" (b2 = 0 and b1 = 1) --- see
       step 2 of Section 4.3 --- and the decrypted response RESP*
       includes an OSCORE option, then the proxy MUST discard the
       response.

       In any other case, RESP takes RESP*, and the proxy moves to step
       4.

   4.  The proxy forwards the response RESP back to the origin client
       (see Section 5.3).

5.3.  Forwarding the Response to the Client

   The proxy performs the following steps.

   1.  The proxy adds possible options to the response RESP to be
       forwarded.

Tiloca & Höglund         Expires 13 January 2022               [Page 17]
Internet-Draft           OSCORE-capable Proxies                July 2021

   2.  If the proxy uses (Group) OSCORE with the client, and the
       originally received request was protected with the OSCORE
       Security Context shared with the client (b0 = 1), then the proxy
       proceeds as follows.

       *  The proxy protects the response RESP with OSCORE, i.e. RESP* =
          Enc(RESP), using the Security Context shared with the origin
          client.  The following options, if present in the response
          RESP to protect, are processed as class E:

          -  The OSCORE option.  This is the case if (Group) OSCORE is
             used between the origin client and the origin server (b2 =
             1 and b0 = 1).  This is "OSCORE-in-OSCORE", which deviates
             from [RFC8613].

          -  Any other option that has been added by the proxy, e.g. the
             Response-Forwarding Option defined in
             [I-D.tiloca-core-groupcomm-proxy].

       *  The result is a protected response RESP* including an OSCORE
          option.  The intended destination OSCORE endpoint is the
          origin client.

       *  RESP takes RESP*, and the proxy moves to step 3.

   3.  The proxy forwards the response RESP back to the origin client.

5.4.  Verifying the Response at the Client

   The client performs the following steps.

   1.  The client receives the response RESP from the proxy.

   2.  The client proceeds as follows.

       *  If the client protected the request with (Group) OSCORE using
          an OSCORE Security Context shared with the proxy (b0 = 1), it
          moves to step 3.

       *  If the client did not protect the request with (Group) OSCORE
          using an OSCORE Security Context shared with the proxy (b0 =
          0), it moves to step 4.

   3.  The client proceeds as follows.

       If the received response RESP is an unprotected 4.00/4.01/4.02,
       the client interprets it as an OSCORE-related error at the proxy.
       This concerns the OSCORE association between client and proxy,

Tiloca & Höglund         Expires 13 January 2022               [Page 18]
Internet-Draft           OSCORE-capable Proxies                July 2021

       and it is up to the client to handle this issue.  Information
       specified in the diagnostic payload, if present, might result in
       the client taking alternative, more appropriate actions.

       Otherwise, i.e. the received response RESP includes an outer
       OSCORE option, the client unprotects the response RESP, with the
       OSCORE Security Context shared with the proxy.  This results in a
       decrypted response RESP* = Dec(RESP).

       If the OSCORE protection of the request performed by the client
       did not result in "OSCORE-in-OSCORE" (b2 = 0 and b0 = 1) --- see
       step 4 of Section 4.1 --- and the decrypted response RESP*
       includes an OSCORE option, then the client MUST discard the
       message and does not perform any further processing.

       If the OSCORE protection of the request performed by the client
       resulted in "OSCORE-in-OSCORE" (b2 = 1 and b0 = 1) --- see step 4
       of Section 4.1 --- then the decrypted response RESP* may include
       an OSCORE option.  This is "OSCORE-in-OSCORE" and deviates from
       [RFC8613], i.e., under this specific outcome, it is fine for the
       client to find an OSCORE option in the decrypted messages, and
       the message is not rejected.

       Finally, RESP takes RESP*, and the client moves to step 4.

   4.  The client proceeds as follows.

       *  If the client did not protect the original CoAP request with
          (Group) OSCORE using an OSCORE Security Context shared with
          the origin server (b2 = 0), the client moves to step 5.

       *  If the client protected the original CoAP request with (Group)
          OSCORE using an OSCORE Security Context shared with the origin
          server (b2 = 1), the client proceeds as follows.

          If the response RESP is an unprotected 4.00/4.01/4.02, the
          client interprets it as an OSCORE-related error at the origin
          server.  This concerns the OSCORE association between client
          and server, and it is up to the client to handle this issue.
          Information specified in the diagnostic payload, if present,
          might result in the client taking alternative, more
          appropriate actions.

          Otherwise, i.e. the response RESP includes an OSCORE option,
          the client unprotects the response RESP, with the OSCORE
          Security Context shared with the origin server.  This results
          in a decrypted response RESP* = Dec(RESP).

Tiloca & Höglund         Expires 13 January 2022               [Page 19]
Internet-Draft           OSCORE-capable Proxies                July 2021

          The client MUST discard the decrypted response RESP*, in case
          RESP* is the result of two OSCORE decryptions in a row (b2 = 1
          and b0 = 1) and includes an OSCORE option.  That is, at most
          two layers of OSCORE protection are admitted, i.e. one with
          the other application endpoint and one with the adjacent
          transport hop.

          Otherwise, RESP takes RESP*, and the client moves to step 5.

   5.  The client delivers the response RESP to the application for
       processing.

6.  Response Caching

   TBD

7.  Chain of Intermediaries

   TBD

8.  Security Considerations

   TBD

9.  IANA Considerations

   This document has no actions for IANA.

Acknowledgments

   The authors sincerely thank Christian Amsuess, Peter Blomqvist and
   Goeran Selander for the initial discussions that allowed shaping this
   document.

   The work on this document has been partly supported by VINNOVA and
   the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home
   (Grant agreement 952652).

References

Normative References

Tiloca & Höglund         Expires 13 January 2022               [Page 20]
Internet-Draft           OSCORE-capable Proxies                July 2021

   [I-D.ietf-core-oscore-groupcomm]
              Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
              and J. Park, "Group OSCORE - Secure Group Communication
              for CoAP", Work in Progress, Internet-Draft, draft-ietf-
              core-oscore-groupcomm-12, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-core-oscore-
              groupcomm-12.txt>.

   [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/info/rfc2119>.

   [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/info/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/info/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/info/rfc8613>.

Informative References

   [I-D.ietf-core-coap-pubsub]
              Koster, M., Keranen, A., and J. Jimenez, "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
              core-coap-pubsub-09, 30 September 2019,
              <https://www.ietf.org/archive/id/draft-ietf-core-coap-
              pubsub-09.txt>.

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E., Wang, C., and M. Tiloca, "Group Communication
              for the Constrained Application Protocol (CoAP)", Work in
              Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
              04, 12 July 2021, <https://www.ietf.org/archive/id/
              draft-ietf-core-groupcomm-bis-04.txt>.

   [I-D.ietf-core-observe-multicast-notifications]
              Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini,
              "Observe Notifications as CoAP Multicast Responses", Work
              in Progress, Internet-Draft, draft-ietf-core-observe-

Tiloca & Höglund         Expires 13 January 2022               [Page 21]
Internet-Draft           OSCORE-capable Proxies                July 2021

              multicast-notifications-01, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-core-observe-
              multicast-notifications-01.txt>.

   [I-D.tiloca-core-groupcomm-proxy]
              Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group
              Communication", Work in Progress, Internet-Draft, draft-
              tiloca-core-groupcomm-proxy-04, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-tiloca-core-
              groupcomm-proxy-04.txt>.

   [LwM2M-Core]
              Open Mobile Alliance, "Lightweight Machine to Machine
              Technical Specification - Core, Approved Version 1.2, OMA-
              TS-LightweightM2M_Core-V1_2-20201110-A", November 2020,
              <http://www.openmobilealliance.org/release/LightweightM2M/
              V1_2-20201110-A/OMA-TS-LightweightM2M_Core-
              V1_2-20201110-A.pdf>.

   [LwM2M-Transport]
              Open Mobile Alliance, "Lightweight Machine to Machine
              Technical Specification - Transport Bindings, Approved
              Version 1.2, OMA-TS-LightweightM2M_Transport-
              V1_2-20201110-A", November 2020,
              <http://www.openmobilealliance.org/release/LightweightM2M/
              V1_2-20201110-A/OMA-TS-LightweightM2M_Transport-
              V1_2-20201110-A.pdf>.

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

Authors' Addresses

   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   SE-16440 Kista
   Sweden

   Email: marco.tiloca@ri.se

Tiloca & Höglund         Expires 13 January 2022               [Page 22]
Internet-Draft           OSCORE-capable Proxies                July 2021

   Rikard Hoeglund
   RISE AB
   Isafjordsgatan 22
   SE-16440 Kista
   Sweden

   Email: rikard.hoglund@ri.se

Tiloca & Höglund         Expires 13 January 2022               [Page 23]