Internet-Draft Cacheable OSCORE July 2021
Amsüss & Tiloca Expires 14 January 2022 [Page]
Workgroup:
CoRE Working Group
Internet-Draft:
draft-amsuess-core-cachable-oscore-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
C. Amsüss
M. Tiloca
RISE AB

Cacheable OSCORE

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 cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group.

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 14 January 2022.

Table of Contents

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 cacheability 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.ietf-core-observe-multicast-notifications], and defines "deterministic request" as a convenient incarnation of such concept.

All clients wishing to send a particular GET or FETCH 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.ietf-core-observe-multicast-notifications], this requires that clients and servers are already members of a suitable OSCORE group.

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

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] and identities.

When relying on intermediaries to fan out the delivery of multicast data protected end-to-end as in [I-D.ietf-core-observe-multicast-notifications], deterministic requests allow for a more efficient setup, by reducing the amount of message exchanges and enabling early population of cache entries (see 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 CoAP request protected with Group OSCORE 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 be said to "be the same Consensus Request" even if they have different Tokens or source addresses.

    The Consensus Request is the reference for request-response binding. In general, a client processing a response to a consensus request did not generate (and thus sign) the consensus request. The client not only needs to decrypt the Consensus Request to understand a response to it (for example to tell which path was requested), it also needs to verify that this is the only Consensus Request that could elicit this response.

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

    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.ietf-core-observe-multicast-notifications].

    In Appendix C, the term is used to 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.

2.1. Deterministic Unprotected Request

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 requests can be aggregated into a single request, that is upstreamed as an observation at the 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.
  • 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 requests are padded to reach a total length that 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 and effectiveness of a cache.

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

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

    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.

  • It may be present in responses (TBD: Does this affect any other properties?).
  • When used with a Deterministic Request, this option is created at message protection time by the sender, and used before message unprotection by the recipient. Therefore, in this use case, it is treated as Class U for OSCORE [RFC8613] in requests. In the same application, for responses, it is treated as Class I, and often elided from sending (but reconstructed at the receiver). Other uses of this option can put it into different classes for the OSCORE processing.

2.4. 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.4.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 Sender ID of the Deterministic Client is immutable throughout the lifetime of the OSCORE group. That is, it is not relinquished and it does not change upon changes of the group keying material following a group rekeying performed by the Group Manager.

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

Group members have to obtain this information from the Group Manager. A group member can do that, for instance, when obtaining the group keying 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.

The joining process based on 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. Such an extension is defined in Section 3 of this document.

2.4.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 external_aad and the AEAD nonce:

    • The used Sender ID is the Deterministic Client's Sender ID.
    • The used Partial IV is 0.

    When preparing the external_aad, the element 'sender_public_key' in the aad_array takes the empty CBOR byte string.

  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 external_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 deterministic 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 a pseudo IKM-Sender computable by all the group members.

      Note that an actual IKM-Sender cannot be obtained, since there is no public key associated with the deterministic client, to be used as Sender Public Key and for computing an actual Diffie-Hellman Shared Secret.

    • 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 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 deterministic Pairwise Sender Key K from step 3 as AEAD encryption key, and the finalized AAD.
  6. 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.4.5). On the other hand, it requires later checks at the client when verifying a response to a Deterministic Request (see Section 2.4.4).

2.4.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.
  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.4.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 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.4.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".

    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.4.4. Response to a Deterministic Request

When treating a response to a deterministic request, the Request-Hash option is treated as a Class I option. This creates the request-response binding ensuring that no mismatched responses can be successfully unprotected. The option does not actually need to be present in the message as transported (the server SHOULD elide it for compactness). The client MUST replace any Request-Hash values present in the response with the Request-Hash it sent in the request before any OSCORE processing.

[ 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. This would avoid the need to make up an option before processing. ]

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.
  • The server preliminarily sets the Request-Hash option with the full request hash.
  • 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.

    Note that the Request-Hash option is treated as Class I here.

  • 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.4.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.
  • The server SHOULD remove the Request-Hash option from the message before sending.

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.4.5), the client MUST verify it to be exactly the 'kid' of the server to which the Deterministic Request was sent.
  • The client removes any Request-Hash options from the response, and inserts a Request-Hash option with the full request hash in their place.
  • 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. When verifying the response, the Request-Hash option is treated as a Class I option.

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

[ 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 proceeds as defined in Section 2.4.3, with the difference that it 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. Obtaining Information about the Deterministic Client

This section extends the Joining Process defined in [I-D.ietf-ace-key-groupcomm-oscore], and based on the ACE framework for Authentication and Authorization [I-D.ietf-ace-oauth-authz]. Upon joining the OSCORE group, this enables a new group member to obtain from the Group Manager the required information about the Deterministic Client (see Section 2.4.1).

With reference to the 'key' parameter of the Joining Response defined in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], the Group_OSCORE_Input_Material object specified as its value contains also the two additional parameters 'det_senderId' and 'det_hash_alg'. These are defined in Section 5.2 of this document. In particular:

The same extension above applies also to the 'key' parameter when included in a Key Distribution Response (see Sections 8.1 and 8.2 of [I-D.ietf-ace-key-groupcomm-oscore]) and in a Signature Verification Data Response (see Section 13 of [I-D.ietf-ace-key-groupcomm-oscore]).

4. Security Considerations

The same security considerations from [RFC7252][I-D.ietf-core-groupcomm-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:

[ More on the verification of the Deterministic Request ]

5. IANA Considerations

This document has the following actions for IANA.

5.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.2. OSCORE Security Context Parameters Registry

IANA is asked to register the following entries in the "OSCORE Security Context Parameters" Registry defined in Section 9.4 of [I-D.ietf-ace-oscore-profile].

  • Name: det_senderId
  • CBOR Label: TBD3
  • CBOR Type: bstr
  • Registry: -
  • Description: OSCORE Sender ID assigned to the Deterministic Client of an OSCORE group
  • Reference: [[this document]] (Section 3)

  • Name: det_hash_alg
  • CBOR Label: TBD4
  • CBOR Type: int / tstr
  • Registry: -
  • Description: Hash algorithm to use in an OSCORE group when producing a Deterministic Request
  • Reference: [[this document]] (Section 3)

6. References

6.1. Normative References

[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-04>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-12>.
[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-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct-15>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-12>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://doi.org/10.17487/RFC2119>.
[RFC7252]
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <https://doi.org/10.17487/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, , <https://doi.org/10.17487/RFC8132>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://doi.org/10.17487/RFC8174>.
[RFC8613]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, , <https://doi.org/10.17487/RFC8613>.
[COSE.Algorithms]
IANA, "COSE Algorithms", <https://www.iana.org/assignments/cose/cose.xhtml#algorithms>.

6.2. Informative References

[RFC7641]
Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, , <https://doi.org/10.17487/RFC7641>.
[I-D.ietf-core-echo-request-tag]
Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", Work in Progress, Internet-Draft, draft-ietf-core-echo-request-tag-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag-13>.
[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-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-11>.
[I-D.amsuess-lwig-oscore]
Amsüss, C., "OSCORE Implementation Guidance", Work in Progress, Internet-Draft, draft-amsuess-lwig-oscore-00, , <https://datatracker.ietf.org/doc/html/draft-amsuess-lwig-oscore-00>.
[I-D.ietf-core-observe-multicast-notifications]
Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini, "Observe Notifications as CoAP Multicast Responses", Work in Progress, Internet-Draft, draft-ietf-core-observe-multicast-notifications-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-observe-multicast-notifications-01>.
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, draft-ietf-ace-oauth-authz-43, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-43>.
[I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework", Work in Progress, Internet-Draft, draft-ietf-ace-oscore-profile-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-19>.
[SW-EPIV]
Lucas, G., "Star Wars", Lucasfilm Ltd. , .
[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, , <https://doi.org/10.17487/RFC8323>.

Appendix A. Change log

Since -01:

Since -00:

Appendix B. Padding

As discussed in Section 4, 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.

+------+---+---+---+---+---------+--------+--------+---------+
| 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 Cacheability using Ticket Requests

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

The approach discussed in this appendix is not provided for application. In fact, it is efficient only when dealing with very large representations and no OSCORE inner Block-Wise mode (which is inefficient for other reasons), or when dealing with observe notifications (which are already well covered in [I-D.ietf-core-observe-multicast-notifications]).

Rather, it is more provided as a "mental exercise" for the authors and interested readers to bridge the gap between this document and [I-D.ietf-core-observe-multicast-notifications].

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.

The remaining exchange largely plays out like in [I-D.ietf-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 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

[I-D.ietf-core-observe-multicast-notifications] defines how a CoAP server can serve all clients observing a same resource at once, by sending notifications over multicast. The approach supports the possible presence of intermediaries such as proxies, also if Group OSCORE is used to protect notifications end-to-end.

However, comparing the "Example with a Proxy" in Appendix A of [I-D.ietf-core-observe-multicast-notifications] and the "Example with a Proxy and Group OSCORE" in Appendix B of [I-D.ietf-core-observe-multicast-notifications] shows that, when using Group OSCORE, more requests need to hit the server. This is because every client originally protects its Observation request individually, and thus needs a custom response served to obtain the Phantom Request as a Ticket Request.

If the clients send their requests as the same deterministic request, the server can use these requests as Ticket Requests as well. Thus, there is no need for the server to provide a same Phantom Request to each client.

Instead, the server can send a single unprotected Informative Response - very much like in the example without Group OSCORE - hence setting the proxy up and optionally providing also the latest notification along the way.

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

Appendix E. Open questions

Appendix F. Unsorted further ideas

Acknowledgments

The authors sincerely thank Michael Richardson, Jim Schaad and Goeran Selander for their comments and feedback.

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

Authors' Addresses

Christian Amsüss
Austria
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden