[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
CoRE Working Group                                             C. Amsüss
Internet-Draft
Intended status: Standards Track                               M. Tiloca
Expires: 26 August 2021                                          RISE AB
                                                        22 February 2021


                            Cacheable OSCORE
                 draft-amsuess-core-cachable-oscore-01

Abstract

   Group communication with the Constrained Application Protocol (CoAP)
   can be secured end-to-end using Group Object Security for Constrained
   RESTful Environments (Group OSCORE), also across untrusted
   intermediary proxies.  However, this sidesteps the proxies' abilities
   to cache responses from the origin server(s).  This specification
   restores cachability of protected responses at proxies, by
   introducing consensus requests which any client in a group can send
   to one server or multiple servers in the same group.

Discussion Venues

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

   Discussion of this document takes place on the CORE 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/chrysn/core-cachable-oscore/.

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

   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 26 August 2021.



Amsüss & Tiloca          Expires 26 August 2021                 [Page 1]


Internet-Draft              Cacheable OSCORE               February 2021


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.  Use cases . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Deterministic Requests  . . . . . . . . . . . . . . . . . . .   5
     2.1.  Design Considerations . . . . . . . . . . . . . . . . . .   6
     2.2.  Request-Hash  . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Use of Deterministic Requests . . . . . . . . . . . . . .   8
       2.3.1.  Pre-Conditions  . . . . . . . . . . . . . . . . . . .   8
       2.3.2.  Client Processing of Deterministic Request  . . . . .   9
       2.3.3.  Server Processing of Deterministic Request  . . . . .  10
       2.3.4.  Response to a Deterministic Request . . . . . . . . .  12
       2.3.5.  Deterministic Requests to Multiple Servers  . . . . .  13
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     4.1.  CoAP Option Numbers Registry  . . . . . . . . . . . . . .  15
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .  18
   Appendix B.  Padding  . . . . . . . . . . . . . . . . . . . . . .  18
     B.1.  Definition of the Padding Option  . . . . . . . . . . . .  18
     B.2.  Using and processing the Padding option . . . . . . . . .  19
   Appendix C.  Simple Cachability using Ticket Requests . . . . . .  19
   Appendix D.  Application for more efficient end-to-end protected
           multicast notifications . . . . . . . . . . . . . . . . .  20
   Appendix E.  Open questions . . . . . . . . . . . . . . . . . . .  21
   Appendix F.  Unsorted further ideas . . . . . . . . . . . . . . .  21
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21






Amsüss & Tiloca          Expires 26 August 2021                 [Page 2]


Internet-Draft              Cacheable OSCORE               February 2021


1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] supports also
   group communication, for instance over UDP and IP multicast
   [I-D.ietf-core-groupcomm-bis].  In a group communication environment,
   exchanged messages can be secured end-to-end by using Group Object
   Security for Constrained RESTful Environments (Group OSCORE)
   [I-D.ietf-core-oscore-groupcomm].

   Requests and responses protected with the group mode of Group OSCORE
   can be read by all group members, i.e. not only by the intended
   recipient(s), thus achieving group-level confidentiality.

   This allows a trusted intermediary proxy which is also a member of
   the OSCORE group to populate its cache with responses from origin
   servers.  Later on, the proxy can possibly reply to a request in the
   group with a response from its cache, if recognized as an eligible
   server by the client.

   However, an untrusted proxy which is not member of the OSCORE group
   only sees protected responses as opaque, uncacheable ciphertext.  In
   particular, different clients in the group that originate a same
   plain CoAP request would send different protected requests, as a
   result of their Group OSCORE processing.  Such protected requests
   cannot yield a cache hit at the proxy, which makes the whole caching
   of protected responses pointless.

   This document addresses this complication and enables cachability of
   protected responses, also for proxies that are not members of the
   OSCORE group and are unaware of OSCORE in general.  To this end, it
   builds on the concept of "consensus request" initially considered in
   [I-D.tiloca-core-observe-multicast-notifications], and defines
   "deterministic request" as a convenient incarnation of such concept.

   Intuitively, given a GET or FETCH plain CoAP request, all clients
   wishing to send that request are able to deterministically compute
   the same protected request, using a variation on the pairwise mode of
   Group OSCORE.  It follows that cache hits become possible at the
   proxy, which can thus serve clients in the group from its cache.
   Like in [I-D.tiloca-core-observe-multicast-notifications], this
   requires that clients and servers are already members of a suitable
   OSCORE group.

   Cachability of protected responses is useful also in applications
   where several clients wish to retrieve the same object.  Some
   security properties of OSCORE are dispensed with to gain other
   desirable properties.




Amsüss & Tiloca          Expires 26 August 2021                 [Page 3]


Internet-Draft              Cacheable OSCORE               February 2021


1.1.  Use cases

   When firmware updates are delivered using CoAP, many similar devices
   fetch large representations at the same time.  Collecting them at a
   proxy not only keeps the traffic low, but also lets the clients ride
   single file to hide their numbers[SW:EPIV].

   When fanning out multicast data delivery, deterministic requests
   allow for a more efficient setup (Appendix D).

1.2.  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 terms and concepts of CoAP
   [RFC7252] and its method FETCH [RFC8132], group communication for
   CoAP [I-D.ietf-core-groupcomm-bis], COSE
   [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs],
   OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm].

   This document introduces the following new terms.

   *  Consensus Request: a Group OSCORE request that can be used
      repeatedly to access a particular resource, hosted at one or more
      servers in the OSCORE group.

      A Consensus Request has all the properties relevant to caching,
      but its transport dependent properties (e.g.  Token or Message ID)
      are not defined.  Thus, different requests on the wire can both be
      said to "be the same Consensus Request" even if they have
      different Tokens or client addresses.

      The Consensus Request is the reference for request-response
      binding.  Hence, if it does not generate a Consensus Request by
      itself, the client has still to be able to read and verify any
      obtained Consensus Request, before using it to verify a bound
      response.

   *  Deterministic Client: a fictitious member of an OSCORE group,
      having no Sender Sequence Number, no asymmetric key pair, and no
      Recipient Context.






Amsüss & Tiloca          Expires 26 August 2021                 [Page 4]


Internet-Draft              Cacheable OSCORE               February 2021


      The Group Manager sets up the Deterministic Client, and assigns it
      a unique Sender ID as for other group members.  Furthermore, the
      Deterministic Client has only the minimum common set of privileges
      shared by all group members.

   *  Deterministic Request: a Consensus Request generated by the
      Deterministic Client.  The use of Deterministic Requests is
      defined in Section 2.

   *  Ticket Request: a Consensus Request generated by the server
      itself.

      This term is not used in the main document, but is useful in
      comparison with other applications of consensus requests that are
      generated in a different way than as a Deterministic Request.  The
      prototypical Ticket Request is the Phantom Request defined in
      [I-D.tiloca-core-observe-multicast-notifications].

      In Appendix C, the term is used bridge the gap to that draft.

2.  Deterministic Requests

   This section defines a method for clients starting from a same plain
   CoAP request to independently arrive at a same Deterministic Request
   protected with Group OSCORE.

   While the first client sending the Deterministic Request actually
   reaches the origin server, the response can be cached by an
   intermediary proxy.  Later on, a different client with the same plain
   CoAP request would send the same Deterministic Request, which will be
   served from the proxy's cache.

   Clients build the unprotected Deterministic Request in a way which is
   as much reproducible as possible.  This document does not set out
   full guidelines for minimizing the variation, but considered starting
   points are:

   *  Set the inner Observe option to 0 if the requested resource is
      described as observable, even if no observation is intended (and
      no outer Observe is set).  Thus, both observing and non-observing
      requsts can be aggregated into a single request, that is
      upstreamed as an observation at latest when any observing request
      reaches the proxy.

   *  Avoid setting the ETag option in requests on a whim.  Only set it
      when there was a recent response with that ETag.  When obtaining
      later blocks, do not send the known-stale ETag.




Amsüss & Tiloca          Expires 26 August 2021                 [Page 5]


Internet-Draft              Cacheable OSCORE               February 2021


   *  In block-wise transfer, maximally sized large inner blocks (szx=6)
      should be selected.  This serves not only to align the clients on
      consistent cache entries, but also helps amortize the additional
      data transferred in the per-message signatures.

      Outer block-wise transfer can then be used if these messages
      excede a hop's efficiently usable MTU size.

      (If BERT [RFC8323] is usable with OSCORE, its use is fine as well;
      in that case, the server picks a consistent block size for all
      clients anyway).

   *  If padding (see Appendix B) is used to limit an adversary's
      ability to deduce requests' content from their length, the length
      requests are padded to should be agreed on among all users of a
      security context.

   These only serve to ensure that cache entries are utilized; failure
   to follow them has no more severe consequences than decreasing the
   utility of a cache.

2.1.  Design Considerations

   The hard part is arriving at a consensus pair (key, nonce) to be used
   with the AEAD cipher for encrypting the Deterministic Request, while
   also avoiding reuse of the same (key, nonce) pair across different
   requests.

   Diversity can conceptually be enforced by applying a cryptographic
   hash function to the complete input of the encryption operation over
   the plain CoAP request (i.e., the AAD and the plaintext of the COSE
   object), and then using the result as source of uniqueness.  Any non-
   malleable cryptographically secure hash of sufficient length to make
   collisions sufficiently unlikely is suitable for this purpose.

   A tempting possibility is to use a fixed key, and use the hash as a
   deterministic AEAD nonce for each Deterministic Request throught the
   Partial IV component (see Section 5.2 of [RFC8613]).  However, the 40
   bit available for the Partial IV are by far insufficient to ensure
   that the deterministic nonce is not reused across different
   Deterministic Requests.  Even if the full deterministic AEAD nonce
   could be set, the sizes used by common algorithms would still be too
   small.








Amsüss & Tiloca          Expires 26 August 2021                 [Page 6]


Internet-Draft              Cacheable OSCORE               February 2021


   As a consequence, the proposed method takes the opposite approach, by
   considering a fixed deterministic AEAD nonce, while generating a
   different deterministic encryption key for each Deterministic
   Request.  That is, the hash computed over the plain CoAP request is
   taken as input to the key generation.  As an advantage, this approach
   does not require to transport the computed hash in the OSCORE option.

   [ Note: This has a further positive side effect arising with version
   -11 of Group OSCORE.  That is, since the full encoded OSCORE option
   is part of the AAD, it avoids a circular dependency from feeding the
   AAD into the hash computation, which in turn needs crude workarounds
   like building the full AAD twice, or zeroing out the hash-to-be. ]

2.2.  Request-Hash

   In order to transport the hash of the plain CoAP request, a new CoAP
   option is defined, which MUST be supported by clients and servers
   that support Deterministic Requests.

   The option is called Request-Hash.  As summarized in Figure 1, the
   Request-Hash option is elective, safe to forward, part of the cache
   key and repeatable.

    +------+---+---+---+---+--------------+--------+--------+---------+
    | No.  | C | U | N | R |     Name     | Format | Length | Default |
    +------+---+---+---+---+--------------+--------+--------+---------+
    | TBD1 |   |   |   | x | Request-Hash | opaque |  any   | (none)  |
    +------+---+---+---+---+--------------+--------+--------+---------+

                       Figure 1: Request-Hash Option

   The Request-Hash option is identical in all its properties to the
   Request-Tag option defined in [I-D.ietf-core-echo-request-tag], with
   the following exceptions:

   *  It may be arbitrarily long.

      Implementations can limit its length to that of the longest output
      of the supported hash functions.

   *  A proxy MAY use any fresh cached response from the selected server
      to respond to a request with the same Request-Hash (or possibly
      even if the new request's Request-Hash is a prefix of the cached
      one).







Amsüss & Tiloca          Expires 26 August 2021                 [Page 7]


Internet-Draft              Cacheable OSCORE               February 2021


      This is a potential future optimization which is not mentioned
      anywhere else yet, and allows clients to elide all other options
      and payload if it has reason to believe that it can produce a
      cache hit with the abbreviated request alone.

   *  When used with a Deterministic Request, this option is created at
      message protection time by the client, and used before message
      unprotection by the server.  Therefore, when used in a
      Deterministic Request, this option is treated as Class U for
      OSCORE [RFC8613].  Other uses of this option can put it into
      different classes for OSCORE the processing.

2.3.  Use of Deterministic Requests

   This section defines how a Deterministic Request is built on the
   client side and then processed on the server side.

2.3.1.  Pre-Conditions

   The use of Deterministic Requests in an OSCORE group requires that
   the interested group members are aware of the Deterministic Client in
   the group.  In particular, they need to know:

   *  The Sender ID of the Deterministic Client, to be used as 'kid'
      parameter for the Deterministic Requests.  This allows all group
      members to compute the Sender Key of the Deterministic Client.

   *  The hash algorithm to use for computing the hash of a plain CoAP
      request, when producing the associated Deterministic Request.

   *  Optionally, a creation timestamp associated to the Deterministic
      Client.  This is aligned with the Group Manager that might replace
      the current Deterministic Client with a new one with a different
      Sender ID, e.g. to enforce freshness indications without rekeying
      the whole group.

   Group members have to obtain this information from the Group Manager.
   A group member can do that, for instance, when obtaining the group
   key material upon joining the OSCORE group, or later on as an active
   member by sending a request to a dedicated resource at the Group
   Manager.  In either case, information on the latest Deterministic
   Client is returned.

   The Group Manager defined in [I-D.ietf-ace-key-groupcomm-oscore] can
   be easily extended to support the provisioning of information about
   the Deterministic Client; no such extension has been drafted as of
   the publication of this draft.




Amsüss & Tiloca          Expires 26 August 2021                 [Page 8]


Internet-Draft              Cacheable OSCORE               February 2021


2.3.2.  Client Processing of Deterministic Request

   In order to build a Deterministic Request, the client protects the
   plain CoAP request using the pairwise mode of Group OSCORE (see
   Section 9 of [I-D.ietf-core-oscore-groupcomm]), with the following
   alterations.

   1.  When preparing the OSCORE option, the AAD and the AEAD nonce:

       *  The used Sender ID is the Deterministic Client's Sender ID.

       *  The used Partial IV is 0, hence it does not need to be set in
          the OSCORE option.

   2.  The client uses the hash function indicated for the Deterministic
       Client, and computes a hash H over the following input: the
       Sender Key of the Deterministic Client, concatenated with the AAD
       from step 1, concatenated with the COSE plaintext.

       Note that the payload of the plain CoAP request (if any) is not
       self-delimiting, and thus hash functions are limited to non-
       malleable ones.

   3.  The client derives the Pairwise Sender Key K as defined in
       Section 2.3.1 of [I-D.ietf-core-oscore-groupcomm], with the
       following differences:

       *  The Sender Key of the Deterministic Client is used as first
          argument of the HKDF.

       *  The hash H from step 2 is used as second argument of the HKDF,
          i.e. as "Shared Secret" computable by all the group members.

          An actual Diffie-Hellman secret cannot be obtained, as there
          is no public key associated with the deterministic client.

       *  The Sender ID of the Deterministic Client is used as value for
          the 'id' element of the 'info' parameter used as third
          argument of the HKDF.

   4.  The client includes a Request-Hash option in the request to
       protect, with value set to the hash H from Step 2.

   5.  The client updates the value of the 'request_kid' field in the
       AAD, and sets it to the hash H from step 2.






Amsüss & Tiloca          Expires 26 August 2021                 [Page 9]


Internet-Draft              Cacheable OSCORE               February 2021


   (This step is still under active debate: While setting it like that
   makes the request and response AADs consistent, it is also means that
   implementations which build the AAD in memory need to do so twice).

   1.  The client protects the request using the pairwise mode of Group
       OSCORE as defined in Section 9.3 of
       [I-D.ietf-core-oscore-groupcomm], using the AEAD nonce from step
       1, the AEAD encryption key from step 3, and the finalized AAD
       from step 5.

   2.  The client sets FETCH as the outer code of the protected request
       to make it usable for a proxy's cache, even if no observation is
       requested [RFC7641].

   The result is the Deterministic Request to be sent.

   Since the encryption key K is derived using material from the whole
   plain CoAP request, this (key, nonce) pair is only used for this very
   message, which is deterministically encrypted unless there is a hash
   collision between two Deterministic Requests.

   The deterministic encryption requires the used AEAD algorithm to be
   deterministic in itself.  This is the case for all the AEAD
   algorithms currently registered with COSE in [COSE.Algorithms].  For
   future algorithms, a flag in the COSE registry is to be added.

   Note that, while the process defined above is based on the pairwise
   mode of Group OSCORE, no information about the server takes part to
   the key derivation or is included in the AAD.  This is intentional,
   since it allows for sending a deterministic request to multiple
   servers at once (see Section 2.3.5).  On the other hand, it requires
   later checks at the client when verifying a response to a
   Deterministic Request (see Section 2.3.4).

2.3.3.  Server Processing of Deterministic Request

   Upon receiving a Deterministic Request, a server performs the
   following actions.

   A server that does not support Deterministic Requests would not be
   able to create the necessary Recipient Context, and thus will fail
   decrypting the request.

   1.  If not already available, the server retrieves the information
       about the Deterministic Client from the Group Manager, and
       derives the Sender Key of the Deterministic Client.





Amsüss & Tiloca          Expires 26 August 2021                [Page 10]


Internet-Draft              Cacheable OSCORE               February 2021


   2.  The server actually recognizes the request to be a Deterministic
       Request, due to the presence of the Request-Hash option and to
       the 'kid' parameter of the OSCORE option set to the Sender ID of
       the Deterministic Client.

       If the 'kid' parameter of the OSCORE option specifies a different
       Sender ID than the one of the Deterministic Client, the server
       MUST NOT take the following steps, and instead processes the
       request as per Section 9.4 of [I-D.ietf-core-oscore-groupcomm].

   3.  The server retrieves the hash H from the Request-Hash option.

   4.  The server derives a Recipient Context for processing the
       Deterministic Request.  In particular:

       *  The Recipient ID is the Sender ID of the Deterministic Client.

       *  The Recipient Key is derived as the key K in step 3 of
          Section 2.3.2, with the hash H retrieved at the previous step.

   5.  The server verifies the request using the pairwise mode of Group
       OSCORE, as defined in Section 9.4 of
       [I-D.ietf-core-oscore-groupcomm], using the Recipient Context
       from step 4, with the following differences.

       *  The server sets the value of the 'request_kid' field in the
          AAD to be the hash H from step 3.

       *  The server does not perform replay checks against a Replay
          Window (see below).

   In case of successful verification, the server MUST also perform the
   following actions, before possibly delivering the request to the
   application.

   *  Starting from the recovered plain CoAP request, the server MUST
      recompute the same hash that the client computed at step 2 of
      Section 2.3.2.

      If the recomputed hash value differs from the value retrieved from
      the Request-Hash option at step 3, the server MUST treat the
      request as invalid and MAY reply with an unprotected 4.00 (Bad
      Request) error response.  The server MAY set an Outer Max-Age
      option with value zero.  The diagnostic payload MAY contain the
      string "Decryption failed".






Amsüss & Tiloca          Expires 26 August 2021                [Page 11]


Internet-Draft              Cacheable OSCORE               February 2021


      This prevents an attacker that guessed a valid authentication tag
      for a given Request-Hash value to poison caches with incorrect
      responses.

   *  The server MUST verify that the unprotected request is safe to be
      processed in the REST sense, i.e. that it has no side effects.  If
      verification fails, the server MUST discard the message and SHOULD
      reply with a protected 4.01 (Unauthorized) error response.

      Note that some CoAP implementations may not be able to prevent
      that an application produces side effects from a safe request.
      This may incur checking whether the particular resource handler is
      explicitly marked as eligible for processing deterministic
      requests.  An implementation may also have a configured list of
      requests that are known to be side effect free, or even a pre-
      built list of valid hashes for all sensible requests for them, and
      reject any other request.

      These checks replace the otherwise present requirement that the
      server needs to check the Replay Window of the Recipient Context
      (see step 5 above), which is inapplicable with the Recipient
      Context derived at step 4 from the value of the Request-Hash
      option.  The reasoning is analogous to the one in
      [I-D.amsuess-lwig-oscore] to treat the potential replay as
      answerable, if the handled request is side effect free.

2.3.4.  Response to a Deterministic Request

   Both when protecting and unprotecting the response, the 'request_kid'
   field of the external AAD is replaced with the Request-Hash value.
   This creates the request-response binding ensuring that no mismatched
   responses can be successfully unprotected.

   [ Note: Mismatching this with the actual request's 'request_kid'
   (that stays the Deterministic Client's Sender ID) is ugly, but also
   the only way to avoid any zeroing/rebuilding of the AAD. ]

   [ Suggestion for any OSCORE v2: avoid request details in the
   request's AAD as individual elements.  Rather than having
   'request_kid', 'request_piv' and (in Group OSCORE)
   'request_kid_context' as separate fields, they can better be
   something more pluggable. ]

   When preparing the response, the server performs the following
   actions.

   *  The server sets a non-zero Max-Age option, thus making the
      Deterministic Request usable for the proxy cache.



Amsüss & Tiloca          Expires 26 August 2021                [Page 12]


Internet-Draft              Cacheable OSCORE               February 2021


   *  The server MUST protect the response using the group mode of Group
      OSCORE, as defined in Section 8.3 of
      [I-D.ietf-core-oscore-groupcomm].  This is required to ensure that
      the client can verify source authentication of the response, since
      the "pairwise" key used for the Deterministic Request is actually
      shared among all the group members.

      In particular, the server sets the value of the 'request_kid'
      field in the AAD to be the hash H retrieved from the Request-Hash
      option of the Deterministic Request (see step 3 in Section 2.3.3).

   *  The server MUST use its own Sender Sequence Number as Partial IV
      to protect the response, and include it as Partial IV in the
      OSCORE option of the response.  This is required since the server
      does not perform replay protection on the Deterministic Request
      (see Section 2.3.4).

   *  The server uses 2.05 (Content) as outer code even though it is not
      necessarily an Observe notification [RFC7641], in order to make
      the response cacheable.

   Upon receiving the response, the client performs the following
   actions.

   *  In case the response includes a 'kid' in the OSCORE option and
      unless responses from multiple servers are expected (see
      Section 2.3.5), the client MUST verify it to be exactly the 'kid'
      of the server to which the Deterministic Request was sent.

   *  The client verifies the response using the group mode of Group
      OSCORE, as defined in Section 8.4 of
      [I-D.ietf-core-oscore-groupcomm].  In particular, the client
      verifies the counter signature in the response, based on the 'kid'
      of the server it sent the request to.

2.3.5.  Deterministic Requests to Multiple Servers

   A Deterministic Request _can_ be sent to a CoAP group, e.g. over UDP
   and IP multicast [I-D.ietf-core-groupcomm-bis], thus targeting
   multiple servers at once.

   To simplify key derivation, such a Deterministic Request is still
   created in the same way as a one-to-one request and still protected
   with the pairwise mode of Group OSCORE, as defined in Section 2.3.2.







Amsüss & Tiloca          Expires 26 August 2021                [Page 13]


Internet-Draft              Cacheable OSCORE               February 2021


   [ Note: If it was protected with the group mode, the request hash
   would need to be fed into the group key derivation just for this
   corner case.  Furthermore, there would need to be a signature from
   the absent public key. ]

   When a server receives a request from the Deterministic Client as
   addressed to a CoAP group, the server MUST include its own Sender ID
   in the response, as 'kid' parameter of the OSCORE option.

   Although it is normally optional for the server to include its Sender
   ID when replying to a request protected in pairwise mode, it is
   required in this case for allowing the client to retrieve the
   Recipient Context associated to the server originating the response.

3.  Security Considerations

   The same security considerations from [RFC7252][I-D.ietf-core-groupco
   mm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this
   document.

   Compared to Group OSCORE, deterministic requests dispense with some
   of OSCORE's security properties by just so much as to make caching
   possible:

   *  Receiving a response to a deterministic request does not mean that
      the response was generated after the request was sent.

      It still contains two freshness statements, though:

      -  It is more recent than any other response from the same group
         member that has a smaller sequence number.

      -  It is more recent than the original creation of the
         deterministic security context.

   *  Request confidentiality is limited.

      An intermediary can determine that two requests from different
      clients are identical, and associate the different responses
      generated for them.  Padding is suggested for responses where
      necessary.

   *  Source authentication for requests is lost.

      Instead, the server must verify that the request (precisely: its
      handler) is side effect free.  The distinct semantics of the CoAP
      request codes can help the server make that assessment.




Amsüss & Tiloca          Expires 26 August 2021                [Page 14]


Internet-Draft              Cacheable OSCORE               February 2021


   [ More on the verification of the Deterministic Request ]

4.  IANA Considerations

   This document has the following actions for IANA.

4.1.  CoAP Option Numbers Registry

   IANA is asked to enter the following option numbers to the "CoAP
   Option Numbers" registry defined in [RFC7252] within the "CoRE
   Parameters" registry.

               +--------+--------------+-------------------+
               | Number |     Name     |     Reference     |
               +--------+--------------+-------------------+
               |  TBD1  | Request-Hash | [[this document]] |
               +--------+--------------+-------------------+
               |  TBD2  | Padding      | [[this document]] |
               +--------+--------------+-------------------+

                       Figure 2: CoAP Option Numbers

   [

   For the Request-Hash option, the number suggested to IANA is 548.

   For the Padding option, the option number is picked to be the highest
   number in the Experts Review range; the high option number allows it
   to follow practically all other options, and thus to be set when the
   final unpadded message length including all options is known.
   Therefore, the number suggested to IANA is 64988.

   Applications that make use of the "Experimental use" range and want
   to preserve that property are invited to pick the largest suitable
   experimental number (65532)

   Note that unless other high options are used, this means that padding
   a message adds an overhead of at least 3 bytes, i.e. 1 byte for
   option delta/length and two more bytes of extended option delta.
   This is considered acceptable overhead, given that the application
   has already chosen to prefer the privacy gains of padding over wire
   transfer length.

   ]

5.  References

5.1.  Normative References



Amsüss & Tiloca          Expires 26 August 2021                [Page 15]


Internet-Draft              Cacheable OSCORE               February 2021


   [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-
              02, 2 November 2020, <http://www.ietf.org/internet-drafts/
              draft-ietf-core-groupcomm-bis-02.txt>.

   [I-D.ietf-core-oscore-groupcomm]
              Tiloca, M., Selander, G., Palombini, F., and J. Park,
              "Group OSCORE - Secure Group Communication for CoAP", Work
              in Progress, Internet-Draft, draft-ietf-core-oscore-
              groupcomm-10, 2 November 2020, <http://www.ietf.org/
              internet-drafts/draft-ietf-core-oscore-groupcomm-10.txt>.

   [I-D.ietf-cose-rfc8152bis-struct]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", Work in Progress, Internet-Draft,
              draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-cose-
              rfc8152bis-struct-14.txt>.

   [I-D.ietf-cose-rfc8152bis-algs]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", Work in Progress, Internet-Draft,
              draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-cose-
              rfc8152bis-algs-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>.

   [RFC8132]  van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
              FETCH Methods for the Constrained Application Protocol
              (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
              <https://www.rfc-editor.org/info/rfc8132>.

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





Amsüss & Tiloca          Expires 26 August 2021                [Page 16]


Internet-Draft              Cacheable OSCORE               February 2021


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

   [COSE.Algorithms]
              IANA, "COSE Algorithms",
              <https://www.iana.org/assignments/cose/
              cose.xhtml#algorithms>.

5.2.  Informative References

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

   [I-D.ietf-core-echo-request-tag]
              Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
              Request-Tag, and Token Processing", Work in Progress,
              Internet-Draft, draft-ietf-core-echo-request-tag-11, 2
              November 2020, <http://www.ietf.org/internet-drafts/draft-
              ietf-core-echo-request-tag-11.txt>.

   [I-D.ietf-ace-key-groupcomm-oscore]
              Tiloca, M., Park, J., and F. Palombini, "Key Management
              for OSCORE Groups in ACE", Work in Progress, Internet-
              Draft, draft-ietf-ace-key-groupcomm-oscore-09, 2 November
              2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
              key-groupcomm-oscore-09.txt>.

   [I-D.amsuess-lwig-oscore]
              Amsuess, C., "OSCORE Implementation Guidance", Work in
              Progress, Internet-Draft, draft-amsuess-lwig-oscore-00, 29
              April 2020, <http://www.ietf.org/internet-drafts/draft-
              amsuess-lwig-oscore-00.txt>.

   [I-D.tiloca-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-tiloca-core-observe-
              multicast-notifications-04, 2 November 2020,
              <http://www.ietf.org/internet-drafts/draft-tiloca-core-
              observe-multicast-notifications-04.txt>.







Amsüss & Tiloca          Expires 26 August 2021                [Page 17]


Internet-Draft              Cacheable OSCORE               February 2021


   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/info/rfc8323>.

Appendix A.  Change log

   Since -00:

   *  More precise specification of the hashing (guided by first
      implementations)

   *  Focus shifted to deterministic requests (where it should have been
      in the first place; all the build-up of Token Requests was moved
      to a motivating appendix)

   *  Aligned with draft-tiloca-core-observe-responses-multicast-05 (not
      submitted at the time of submission)

   *  List the security properties lost compared to OSCORE

Appendix B.  Padding

   As discussed in Section 3, information can be leaked by the length of
   a response or, in different contexts, of a request.

   In order to hide such information and mitigate the impact on privacy,
   the following Padding option is defined, to allow increasing a
   message's length without changing its meaning.

   The option can be used with any CoAP transport, but is especially
   useful with OSCORE as that does not provide any padding of its own.

   Before choosing to pad a message by using the Padding option,
   application designers should consider whether they can arrange for
   common message variants to have the same length by picking a suitable
   content representation; the canonical example here is expressing
   "yes" and "no" with "y" and "n", respectively.

B.1.  Definition of the Padding Option

   As summarized in Figure 3, the Padding option is elective, safe to
   forward and not part of the cache key; these follow from the usage
   instructions.  The option may be repeated, as that may be the only
   way to achieve a certain total length for the padded message.





Amsüss & Tiloca          Expires 26 August 2021                [Page 18]


Internet-Draft              Cacheable OSCORE               February 2021


      +------+---+---+---+---+---------+--------+--------+---------+
      | No.  | C | U | N | R |  Name   | Format | Length | Default |
      +------+---+---+---+---+---------+--------+--------+---------+
      | TBD2 |   |   | x | x | Padding | opaque | any    | (none)  |
      +------+---+---+---+---+---------+--------+--------+---------+

                          Figure 3: Padding Option

B.2.  Using and processing the Padding option

   A client may set the Padding option, specifying any content of any
   length as its value.

   A server MUST ignore the option.

   Proxies are free to keep the Padding option on a message, to remove
   it or to add further padding of their own.

Appendix C.  Simple Cachability using Ticket Requests

   Building on the concept of Phantom Requests and Informative Responses
   defined in [I-D.tiloca-core-observe-multicast-notifications], basic
   caching is already possible without building a Deterministic Request.

   This appendix is not provided for application (for it is only
   efficient when dealing with very large representations and no OSCORE
   inner Block-Wise mode, which is inefficient for other reasons, and
   for observations which are already well covered in
   [I-D.tiloca-core-observe-multicast-notifications]).  It is more
   provided as a "mental exercise" for the authors and interested
   readers to bridge the gap between these documents.

   That is, instead of replying to a client with a regular response, a
   server can send an Informative Response, defined as a protected 5.03
   (Service Unavailable) error message.  The payload of the Informative
   Response contains the Phantom Request, which is a Ticket Request in
   this document's broader terminology.

   Unlike a Deterministic Request, a Phantom Request is protected in
   Group Mode.  Instead of verifying a hash, the client can see from the
   signature that this was indeed the request the server is answering.
   The client also verifies that the request URI is identical between
   the original request and the Ticket Request.








Amsüss & Tiloca          Expires 26 August 2021                [Page 19]


Internet-Draft              Cacheable OSCORE               February 2021


   The remaining exchange largely plays out like in
   [I-D.tiloca-core-observe-multicast-notifications]'s "Example with a
   Proxy and Group OSCORE": The client sends the Phantom Request to the
   proxy (but, lacking a "tp_info", without a Listen-To-Multicast-
   Responses option), which forwards it to the server for lack of the
   option.

   The server then produces a regular response and includes a non-zero
   Max-Age option as an outer CoAP option.  Note that there is no point
   in including in an inner Max-Age option, as the client could not pin
   it in time.

   When a second, different client later asks for the same resource at
   the same server, its new request uses a different 'kid' and 'Partial
   IV' than the first client's.  Thus, the new request produces a cache
   miss at the proxy and is forwarded to the server, which responds with
   the same Ticket Request provided to the first client.  After that,
   when the second client sends the Ticket Request, a cache hit at the
   proxy will be produced, and the Ticket Request can be served from the
   proxy's cache.

   When multiple proxies are in use, or the response has expired from
   the proxy's cache, the server receives the Ticket Request multiple
   times.  It is a matter of perspective whether the server treats that
   as an acceptable replay (given that this whole mechansim only makes
   sense on requests free of side effects), or whether it is
   conceptualized as having an internal proxy where the request produces
   a cache hit.

Appendix D.  Application for more efficient end-to-end protected
             multicast notifications

   Comparing the "Example with a Proxy" and the "Example with a Proxy
   and Group OSCORE" in
   [I-D.tiloca-core-observe-multicast-notifications] shows that with
   OSCORE, more requests than without need to hit the server.  This is
   because every client originally protects their request individually
   and thus needs a custom response served to send the Phantom Request
   as a Ticket Request.

   If the clients send their deterministic requests in a deterministic
   way, and the server uses these requests as Ticket Requests as well,
   then there is no need for a Phantom Request to be sent back to the
   client.

   Instead, the server can send an unprotected Informative Response very
   much like in the example without OSCORE, setting the proxy up and
   giving the latest response along the way.



Amsüss & Tiloca          Expires 26 August 2021                [Page 20]


Internet-Draft              Cacheable OSCORE               February 2021


   The proxy can thus be configured by the server with the first
   request, and has an active observation and a fresh cache entry in
   time for the second client to arrive.

Appendix E.  Open questions

   *  Is "deterministic encryption" something worthwhile to consider in
      COSE?

      COSE would probably specify something more elaborate for the KDF
      (the current KDF round is the pairwise mode's; COSE would probably
      run through KDF with a KDF context structure).

      COSE would give a header parameter name to the Request-Hash (which
      for the purpose of OSCORE deterministic requests would put back
      into Request-Hash by extending the option compression function
      across the two options).

      Conceptually, they should align well, and the implementation
      changes are likely limited to how the KDF is run.

   *  An unprotection failure from a mismatched hash will not be part of
      the ideally constant-time code paths that otherwise lead to AEAD
      unprotect failures.  Is that a problem?

      After all, it does tell the attacker that they did succeed in
      producing a valid MAC (it's just not doing it any good, because
      this key is only used for deterministic requests and thus also
      needs to pass the Request-Hash check).

Appendix F.  Unsorted further ideas

   *  All or none of the deterministic requests should have an inner
      observe option.  Preferably none - that makes messages shorter,
      and clients need to ignore that option either way when checking
      whether a Consensus Request matches their intended request.

Acknowledgments

   The authors sincerely thank Jim Schaad for his comments and feedback.

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

Authors' Addresses





Amsüss & Tiloca          Expires 26 August 2021                [Page 21]


Internet-Draft              Cacheable OSCORE               February 2021


   Christian Amsüss
   Austria

   Email: christian@amsuess.com


   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   SE-16440 Stockholm Kista
   Sweden

   Email: marco.tiloca@ri.se






































Amsüss & Tiloca          Expires 26 August 2021                [Page 22]