Cacheable 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 11 January 2024.¶

Copyright Notice

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

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

Table of Contents

1. Introduction

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, in order to gain other desirable properties.¶

In order to clearly handle the protocol's security properties, and to broaden applicability to group situations outside the deterministic case, the technical implementation is split into two halves:¶

• maintaining request-response bindings in the absence of request source authentication; and¶
• building and processing of Deterministic Requests (which have no source authentication, and thus require the former).¶

2. OSCORE processing without source authentication

The request-response binding of OSCORE is achieved by the items request_kid / request_piv (and, in group OSCORE, request_kid_context) that are present in both the request's and the response's AAD, and are hereafter referred to as "request_ details".¶

The security of such binding depends on the server obtaining source authentication for the request: if this precondition is not fulfilled, a malicious group member could alter a request to the server (without altering the request_ details above), and the client would still accept the response as if it were a response to its request.¶

Source authentication is thus a precondition for the secure use of OSCORE and Group OSCORE. However, it is hard to provide when:¶

• Requests are built exclusively using shared keying material, like in the case of a Deterministic Client.¶
• Requests are sent without source authentication, or their source authentication is not checked. (This was part of [I-D.ietf-core-oscore-groupcomm] in revisions before version -12)¶

This document does not [ yet? ] give full guidance on how to restore request-response binding for the general case, but currently only offers suggestions:¶

• The response can contain the full request. An option that allows doing that is presented in [I-D.bormann-core-responses].¶
• The response can contain a cryptographic hash of the full request. This is used by the method specified in this document, as defined in Section 3.3.¶
• The request_ details above can be transported in a Class E option (encrypted and integrity protected) or a Class I option (unencrypted, but part of the AAD hence integrity protected). The latter has the advantage that the option can be removed in transit and reconstructed at the receiver.¶
• Alternatively, the agreed-on request data can be placed in a different position in the AAD, or take part to the derivation of the OSCORE Security Context. In the latter case, care needs to be taken to never initialize a Security Context twice with the same input, as that would lead to reuse of the AEAD nonce.¶

[ 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, and would allow just plugging in the hash or request in there as replacing the elements for the request_ details. ]¶

Additional care has to be taken in ensuring that request_ details that are not expressed in the request itself are captured. For instance, these include an indication of the Security Context from which the request is assumed to have been originated.¶

Requests without source authentication have to be processed assuming only the minimal possible privilege of the requester [ which is currently described as the authorization of the Deterministic Client, and may be moved up here in later versions of this document ]. If a response is built to such a request and contains data more sensitive than that (which might be justified if the response is protected for an authorized group member in pairwise mode), special consideration for any side channels like response size or timing is required.¶

3. Deterministic Requests

This section defines a method for clients starting from a same plain CoAP request to independently build the same, corresponding Deterministic Request protected with Group OSCORE.¶

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

4. 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 [RFC9200]. 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 3.4.1).¶

With reference to the 'key' parameter of the Join Response defined in Section 6.3 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 6.2 of this document. In particular:¶

• The 'det_senderId' parameter, if present, has as value the OSCORE Sender ID assigned to the Deterministic Client by the Group Manager. This parameter MUST be present if the OSCORE group uses Deterministic Requests as defined in this document. Otherwise, this parameter MUST NOT be present.¶
• The 'det_hash_alg' parameter, if present, has as value the hash algorithm to use for computing the hash of a plain CoAP request, when producing the associated Deterministic Request. This parameter takes values from the "Value" column of the "COSE Algorithms" Registry [COSE.Algorithms]. This parameter MUST be present if the OSCORE group uses Deterministic Requests as defined in this document. Otherwise, this parameter MUST NOT be present.¶

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

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

The following elaborates on how, compared to Group OSCORE, Deterministic Requests dispense with some of the OSCORE security properties, by just so much as to make caching possible.¶

• A Deterministic Request is intrinsically designed to be replayed, as intended to be identically sent multiple times by multiple clients to the same server(s).¶

  Consistently, as per the processing defined in Section 3.4.3, a server receiving a Deterministic Request does not perform replay checks against an OSCORE Replay Window.¶

  This builds on the following considerations.¶

  • For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server). In general, if processing a request does not have state-changing side effects, the consequences of replay are not significant.¶

    Just like for what concerns the lack of source authentication (see below), the server must verify that the received Deterministic Request (more precisely, its handler) is side effect free. The distinct semantics of the CoAP request codes can help the server make that assessment.¶

  • Consistently with the point above, a server can choose whether it will process a Deterministic Request on a per-resource basis. It is RECOMMENDED that origin servers allow resources to explicitly configure whether Deterministic Requests are appropriate to receive, as still limited to requests that are safe to be processed in the REST sense, i.e., they do not have state-changing side effects.¶

• Receiving a response to a Deterministic Request does not mean that the response was generated after the Deterministic Request was sent.¶

  However, a valid response to a Deterministic Request still contains two freshness statements.¶

  • 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 keying material in the Group OSCORE Security Context.¶

• Source authentication of Deterministic Requests is lost.¶

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

  Just like for what concerns the acceptance of replayed Deterministic Requests (see above), the server can choose whether it will process a Deterministic Request on a per-resource basis.¶

• The privacy of Deterministic Requests is limited.¶

  An intermediary can determine that two Deterministic Requests from different clients are identical, and associate the different responses generated for them. A server producing responses of varying size to a Deterministic Request can use the Padding option to hide when the response is changing.¶

[ More on the verification of the Deterministic Request ]¶

6. IANA Considerations

Note to RFC Editor: Please replace "[RFC-XXXX]" with the RFC number of this document and delete this paragraph.¶

This document has the following actions for IANA.¶

+--------+--------------+------------+
| Number | Name         | Reference  |
+--------+--------------+------------+
|  TBD1  | Request-Hash | [RFC-XXXX] |
+--------+--------------+------------+
|  TBD2  | Padding      | [RFC-XXXX] |
+--------+--------------+------------+

Appendix A. Change log

Since -06:¶

• Clarifications, terminology alignment, and editorial improvements.¶

Since -05:¶

• Updated references.¶

Since -04:¶

• Revised and extended list of use cases.¶
• Added further note on Deterministic Requests to a group of servers as still protected with the pairwise mode.¶
• Suppression of error responses for servers in a CoAP group.¶
• Extended security considerations with discussion on replayed requests.¶

Since -03:¶

• Processing steps in case only inner Observe is included.¶
• Clarified preserving/eliding the Request-Hash option in responses.¶
• Clarified limited use of the Echo option.¶
• Clarifications on using the Padding option.¶

Since -02:¶

• Separate parts needed to respond to unauthenticated requests from the remaining deterministic response part. (Currently this is mainly an addition; the document will undergo further refactoring if that split proves helpful).¶
• Inner Observe is set unconditionally in Deterministic Requests.¶
• Clarifications around padding and security considerations.¶

Since -01:¶

• Not meddling with request_kid any more.¶

  Instead, Request-Hash in responses is treated as Class I, but typically elided.¶

  In requests, this removes the need to compute the external_aad twice.¶

• Derivation of the hash now uses the external_aad, rather than the full AAD. This is good enough because AAD is a function only of the external_aad, and the external_aad is easier to get your hands on if COSE manages all the rest.¶
• The Sender ID of the Deterministic Client is immutable throughout the group lifetime. Hence, no need for any related expiration/creation time and mechanisms to perform its update in the group.¶
• Extension to the ACE Group Manager of ace-key-groupcomm-oscore to provide required info about the Deterministic Client to new group members when joining the group.¶
• Alignment with changes in core-oscore-groupcomm-12.¶
• Editorial improvements.¶

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 5, 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 new CoAP option with name Padding is defined, in order 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.¶

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

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 the broader terminology used by this document.¶

Unlike a Deterministic Request, a Phantom Request is protected with the Group Mode of Group OSCORE. Instead of verifying a hash, the client can see from the countersignature 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 mechanism 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 E of [I-D.ietf-core-observe-multicast-notifications] and the "Example with a Proxy and Group OSCORE" in Appendix F 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, then 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

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

• We could allows clients to elide all other options than Request-Hash, and elide the payload, if it has reason to believe that it can produce a cache hit with the abbreviated request alone.¶

  This may prove troublesome in terms of cache invalidation (the server would have to use short-lived responses to indicate that it does need the full request, or we'd need special handling for error responses, or criteria by which proxies don't even forward these if they don't have a response at hand).¶

  That may be more trouble than it's worth without a strong use case (say, of complex but converging FETCH requests).¶

  Hashes could also be used in truncated form for that.¶

Acknowledgments

The authors sincerely thank Michael Richardson, Jim Schaad, and Göran 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