]>

Austria christian@amsuess.com

RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

CoRE Working Group CoAP, OSCORE, multicast, caching, proxy When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-to-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) supports intermediary proxies that perform requests on behalf of clients and relay back responses. A core functionality of intermediary proxies is the caching of responses. Even in the presence of such intermediaries, exchanged CoAP messages can be protected end-to-end by using Object Security for Constrained RESTful Environments (OSCORE) . In a group communication environment , CoAP exchanged messages can be protected end-to-end by using Group Object Security for Constrained RESTful Environments (Group OSCORE) . When protected with the group mode of Group OSCORE (see ), requests and responses exchanged in the OSCORE group can be decrypted by any member of the group, i.e., not only by the intended recipient(s), thus achieving group-level data confidentiality. With any security mechanism for CoAP, the caching of responses at intermediaries presents operators with a trade-off between required trust and provided performance:

• If an intermediary proxy is trusted, the proxy can inspect traffic that is going through, cache it, and provide cached responses.
• An untrusted proxy, while possible with OSCORE and Group OSCORE, sees different ciphertexts for different requests even when those requests target the same resource. Even if the proxy could somehow produce a cache hit, cached responses would be rejected by the request-response matching of (Group) OSCORE.

By using Group OSCORE, this document provides a way out of the trade-off situation. In particular, this document enables effective cacheability of protected responses for proxies that are not members of the OSCORE group and that are unaware of OSCORE and Group OSCORE in general. To this end, it builds on the concept of "consensus request" initially considered in , and it defines "Deterministic Request" as a convenient incarnation of such concept. All clients wishing to send a particular request with the GET method or FETCH method are able to deterministically compute the same protected request, using a variation of the pairwise mode of Group OSCORE (see ). It follows that cache hits become possible at the proxy, which can thus serve clients in the group from its cache. Like in , 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 Group 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
• Composition and processing of Deterministic Requests, which have no source authentication and thus require the former.

Use Cases When firmware updates are delivered using CoAP, many similar devices fetch the same large data at the same time. Collecting such large data at a proxy from its cache not only keeps the traffic low, but also lets the clients ride single file to hide their numbers and identities. By using protected Deterministic Requests as defined in this document, it is possible to efficiently perform data collection at a proxy also when the firmware updates are protected end-to-end. When relying on intermediaries to fan out the delivery of multicast data protected end-to-end as in , the use of protected Deterministic Requests as defined in this document allows for a more efficient setup, by reducing the amount of message exchanges and enabling early population of cache entries (see ). When building RESTful networks following the patterns of Information-Centric Networking (ICN), CoAP proxies take the role of forwarding nodes. Caching plays a large role in such networks, and cacheable OSCORE provides a compatible security mechanism . When DNS messages are transported over CoAP , it is recommended to use OSCORE for protecting such messages . By restoring cacheability of OSCORE-protected responses, it becomes possible to benefit from the cache retrieval of such CoAP responses that particularly transport DNS messages.

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 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with terms and concepts of CoAP and its method FETCH , group communication for CoAP , Concise Binary Object Representation (CBOR) , CBOR Object Signing and Encryption (COSE) , OSCORE , and Group OSCORE . This document also introduces the following new terms.

• Consensus Request: a CoAP request that multiple clients use to repeatedly access a particular resource. In this document, it exclusively refers to requests protected with Group OSCORE that target a resource hosted at one or more servers in an 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 corresponding response (for example, to tell which resource path was requested), but 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 responsible for the OSCORE group (see ) sets up the Deterministic Client and assigns it a unique Sender ID like 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 .
• Ticket Request: a Consensus Request generated by the server itself. This term is not used in the remaining of the main document body, but it is useful in comparison with other applications of Consensus Requests that are generated in a different way than as Deterministic Requests. The prototypical Ticket Request is the Phantom Request defined in . In , this term is used to bridge the gap with that document.

OSCORE Message Processing without Source Authentication In OSCORE , a response is cryptographically bound to the corresponding request through CBOR data items in their authenticated encryption's Additional Authenticated Data (AAD): "request_kid" and "request_piv". Building on the same construct, Group OSCORE adds "request_kid_context" to that list. Hereafter, those items are referred to as "request_details". The security of such binding depends on the server obtaining source authentication for the request, and on that source matching the request_details. 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 of requests 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 group keying material, like in the case of a Deterministic Client.
• Requests are sent without source authentication, or their source authentication is not checked.

This document does not give full guidance on how to restore request-response binding for the general case, but it offers suggestions:

• The response can contain the full request. An option that allows doing that is presented in .
• The response can contain a cryptographic hash of the full request. This is used by the method specified in this document, as defined in .
• The agreed-on request data can be placed in a different position in the AAD, or take part to the derivation of the (Group) 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 Authenticated Encryption with Associated Data (AEAD) nonce.

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 through 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, e.g., consistent with the privileges of the Deterministic Client considered in this document (see ). If a response to such a request is originated and it contains data more sensitive than that (which might be justified, if the response is protected for an authorized group member using the pairwise mode of Group OSCORE), special consideration for any side channels like response size or timing is required.

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

Deterministic Unprotected Request When clients compose their unprotected request, they can already minimize variability and thus maximize reproducibility. This document does not set out full guidelines for minimizing the variation, but considered starting points are:

• Set the Inner CoAP Observe Option to 0 (register) , even if no observation is intended (and hence no Outer Observe Option is set). Thus, both Observe and non-Observe requests can be aggregated into a single request, which is upstreamed as an observation at the latest when any Observe request reaches a caching proxy. In this case, following a Deterministic Request that includes only an Inner Observe Option, servers include an Inner Observe Option (but no Outer Observe Option) in a successful response sent as reply. Also, when receiving a response to such a Deterministic Request previously sent, clients silently ignore the Inner Observe Option in that response.
• Avoid setting the CoAP ETag Option in requests on a whim. Instead, clients should only set it when there was a recent response conveying that ETag value. When using block-wise transfers and obtaining later blocks, clients should not send the known-stale ETag value.
• When using block-wise transfers , maximally sized large Inner blocks (szx=6) should be selected. This not only serves to align the clients on consistent cache entries, but it also helps amortize the additional data transferred in the per-message signatures of the corresponding responses, which are protected with the group mode of Group OSCORE. Outer block-wise transfer can then be used if these messages exceed a hop's efficiently usable Maximum Transmission Unit (MTU) size. If Block-wise Extension for Reliable Transport (BERT) is usable with Group OSCORE, its use is fine as well. In that case, the server picks a consistent block size for all clients anyway.
• The CoAP Padding Option defined in can be used to limit an adversary's ability to deduce the content and the target resource of Deterministic Requests from their length. In particular, all Deterministic Requests of the same class (ideally, all requests to a particular server) can be padded to reach the same total length, which would need to be agreed on among all users of the same Group OSCORE Security Context.
• Clients should not send a protected (inner) CoAP Echo Option in Deterministic Requests. In combination with Deterministic Requests, this limits the use of the Echo Option to its inclusion as an unprotected (outer) Echo Option, and thus to testing the reachability of the client. However, this is not practically limiting, since the use as an Inner option would be to prove freshness, which is something that Deterministic Requests simply cannot provide anyway.

These guidelines only serve to ensure that cache entries are utilized. Failure to follow these guidelines has no more severe consequences than decreasing the utility and effectiveness of a cache.

Design Considerations The hard part is determining a consensus pair (key, nonce) to be used with the AEAD cipher for encrypting the plain CoAP request and obtaining the Deterministic Request as a result, while also avoiding the 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 (group) key, and use the hash as a deterministic AEAD nonce for each Deterministic Request through the Partial IV component (see ). However, the 40 bits 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. Consequently, the method defined in this document takes the opposite approach, by considering a fixed deterministic AEAD nonce, while deriving 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 derivation. As an advantage, this approach does not require to transport the computed hash in the CoAP OSCORE Option.

The Request-Hash Option 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 and its properties are summarized in , which extends Table 4 of . The option is Elective, Safe-to-Forward, part of the Cache-Key, and not repeatable. The Request-Hash Option (C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable)

No.	C	U	N	R	Name	Format	Length	Default
TBD548					Request-Hash	opaque	any	(none)

The Request-Hash Option is identical in all its properties to the Request-Tag Option defined in , with the following exceptions:

• It is not repeatable.
• The Option Value may be arbitrarily long. Implementations can limit the length of the Option Value to that of the longest output of the supported hash functions.
• It may be present in responses. [ Editor's note: Does this affect any other properties? ] A response's Request-Hash Option is, as a matter of default value, equal to the request's Request-Hash Option. The response is valid only if the value of its Request-Hash Option is equal to the value of the Request-Hash Option in the corresponding request. Servers (including proxies) thus generally should not need to include the Request-Hash Option explicitly in responses, especially as a matter of bandwidth efficiency. A reason (and, currently, the only known) to actually include a Request-Hash option in a response is the possible use of non-traditional responses as described in , which, in terms of that document, are non-matching to the request (and thus easily usable). The Request-Hash Option included in the response allows populating caches (see below) and enables the decryption and verification of a response that is sent as a reply to a Consensus Request. In the context of non-traditional responses, the value of the Request-Hash Option in the request corresponding to a response can be inferred from the value of the Request-Hash Option in the response.
• A proxy MAY use any fresh cached response from the selected server to reply to a request with the same Request-Hash; this can save it some memory. When replying to a request that includes a Request-Hash Option, the proxy MAY add a Request-Hash Option to the response if the option is not already present in the response, or remove the Request-Hash Option from the response if the option is already present in the response. In either case, the Request-Hash Option in the response MUST have the same value that the Request-Hash Option has in the corresponding request.
• When used with a Deterministic Request, the Request-Hash Option is created at message protection time by the sender endpoint, and it is used before message decryption and verification by the recipient endpoint. Therefore, in this use case, this option is treated as Class U for OSCORE in requests. In the same application, for responses, this option is treated as Class I and is often elided from sending, in which case it is reconstructed at the recipient endpoint. Other uses of the Request-Hash Option can treat it according to different classes for the OSCORE processing.

The Request-Hash Option achieves the request-response binding described in .

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

Preconditions 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 (see ).
• 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 interacting with the Group Manager. The joining process based on the realization of Group Manager defined in can be easily extended to support the provisioning of information about the Deterministic Client. Such an extension is defined in of the present document. With reference to the same realization of Group Manager, no such extension is needed for its management interface defined in , which already includes the relevant parameters.

Client Composition of Deterministic Requests In order to compose a Deterministic Request, the client protects the plain CoAP request using the pairwise mode of Group OSCORE (see ), with the following alterations.

1. When preparing the OSCORE Option, the external_aad, and the AEAD nonce:
   • The Sender ID used is the Deterministic Client's Sender ID.
   • The element 'sender_cred' in the aad_array takes the empty CBOR byte string (0x40).
   • The Partial IV used is 0.
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 binary serialization of the aad_array 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 , with the following differences:
   • The Sender Key of the Deterministic Client is used as the first argument of the HMAC-based Key Derivation Function (HKDF).
   • The hash H from Step 2 is used as the second argument IKM-Sender of the HKDF, i.e., as a pseudo Input Keying Material (IKM) computable by all the group members. Note that an actual IKM-Sender cannot be obtained, since there is no authentication credential (and public key included therein) associated with the Deterministic Client to be used as Sender Authentication Credential and for computing an actual shared secret.
   • The Sender ID of the Deterministic Client is used as the value for the 'id' element of the 'info' parameter that is used as the 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 MAY include an Inner Observe Option set to 0 (register) to be protected with Group OSCORE, even if no observation is intended (see ).
6. The client protects the request using the pairwise mode of Group OSCORE as defined in , using the AEAD nonce from Step 1, the deterministic Pairwise Sender Key K from Step 3 as the AEAD encryption key, and the finalized AAD.
7. The client MUST NOT include an unprotected (outer) Observe Option if no observation is intended, even in the case that an Inner Observe Option was included at Step 5.
8. The client MUST set 0.05 (FETCH) as the Outer Code of the protected request to make it usable for a proxy's cache, even if no observation is intended.

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 that the AEAD algorithm used is deterministic in itself. This is the case for all the AEAD algorithms currently registered with COSE in the "COSE Algorithms" registry . For future algorithms, a flag in the that 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 in the key derivation or is included in the AAD. This is intentional, since it allows sending a Deterministic Request to multiple servers at once (see ). On the other hand, it requires later checks at the client when verifying a response to a Deterministic Request (see ).

Server Processing of Deterministic Requests Upon receiving a Deterministic Request, a server performs the following actions. A server that does not support Deterministic Requests would not be able to derive the necessary Recipient Context at Step 4 below, and thus will fail decrypting and verifying 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 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 that is 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 .
3. The server retrieves the hash H from the Request-Hash Option.
4. The server derives a Recipient Context associated with the Deterministic Client, to be used for processing the Deterministic Request. In particular:
   • The Recipient ID is the Sender ID of the Deterministic Client.
   • The deterministic Pairwise Recipient Key K is derived as defined in , with the following differences:
     • The Recipient Key associated with the Deterministic Client (i.e., the Sender Key of the Deterministic Client) is used as the first argument of the HMAC-based Key Derivation Function (HKDF).
     • The hash H retrieved at Step 3 is used as the second argument IKM-Recipient of the HKDF, i.e., as a pseudo Input Keying Material (IKM). Note that an actual IKM-Recipient cannot be obtained, since there is no authentication credential (and public key included therein) associated with the Deterministic Client to be used as Recipient Authentication Credential and for computing an actual shared secret.
     • The Recipient ID is used as the value for the 'id' element of the 'info' parameter that is used as the third argument of the HKDF.
   Note that the server might already be storing a Recipient Context associated with the Deterministic Client, e.g., if that was established upon receiving a previous Deterministic Request in the OSCORE group, or already upon joining the OSCORE group. In such a case, the present step consists only in the (re-)derivation of the deterministic Pairwise Recipient Key K within the considered Recipient Context, to be used for decrypting and verifying the present Deterministic Request.
5. The server decrypts and verifies the Deterministic Request using the pairwise mode of Group OSCORE as defined in and the Recipient Context from Step 4, with the following differences:
   • When preparing the external_aad, the element 'sender_cred' in the aad_array takes the empty CBOR byte string (0x40).
   • The server does not perform replay checks against a Replay Window (see below).

If the verification is successful, 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 , according to the same process. If the recomputed hash value differs from the value retrieved from the Request-Hash Option at Step 3 of the present , 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 request 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 to treat the potential replay as answerable, if the handled request is side-effect free.

Response to a Deterministic Request When preparing a response to a Deterministic Request, the server treats the Request-Hash Option as a Class I option. The value of the Request-Hash Option MUST be equal to the value of the Request-Hash Option that was specified in the corresponding Deterministic Request. Since the client is aware of the Request-Hash value to expect in the response, the server usually elides the Request-Hash Option from the actually transmitted response. Treating the Request-Hash Option as a Class I option creates the request-response binding, thus ensuring that no mismatched responses can be successfully unprotected and verified by the client (see ). The client MUST reject a response to a Deterministic Request, if the value of the Request-Hash Option included in the response is not equal to the value that was specified in the Request-Hash Option of that Deterministic Request. In order to compose a response to a Deterministic Request, the server performs the following actions.

1. The server MUST either omit an Inner Max-Age Option or include it with Option Value different from 0.
2. The server preliminarily sets the Request-Hash Option with the full Request-Hash value, i.e., the same value of the Request-Hash Option that was specified in the Deterministic Request.
3. If the Deterministic Request included an Inner Observe Option but not an Outer Observe Option and the resource is observable , the server MUST include an Inner Observe Option in the response.
4. The server MUST protect the response using the group mode of Group OSCORE, as defined in . This is required to ensure that the client can verify the source authentication of the response, since the "pairwise" key used for producing the Deterministic Request is actually shared among all the group members. Note that the Request-Hash Option is treated as Class I here.
5. The server MUST include its Sender Sequence Number as Partial IV in the response and use it to build the nonce to protect the response. This is required since the server does not perform replay protection on the Deterministic Request (see ).
6. The server MUST use 2.05 (Content) as Outer Code of the response even though the response is not necessarily an Observe notification , in order to make the response cacheable.
7. The server SHOULD remove the Request-Hash Option from the response before sending the response to the client, as per the general option mechanism defined in .
8. If the Deterministic Request included an Inner Observe Option but not an Outer Observe Option, the server MUST NOT include an Outer Observe Option in the response.
9. The server MUST include an Outer Max-Age Option, setting the Option Value to the same Option Value of the Inner Max-Age Option, if present, or to the default value 60 otherwise (see ). This makes the Deterministic Request usable for the proxy cache.

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

1. If the response includes a 'kid' in the OSCORE Option, the client MUST verify it to be exactly the 'kid' of the server to which the Deterministic Request was sent, unless responses from multiple servers are expected (see ). If the verification fails, the client MUST reject the response.
2. If the response does not include the Request-Hash Option, the client adds the Request-Hash Option to the response, setting the Option Value to the same Option Value of the Request-Hash Option that was included in the Deterministic Request. Otherwise, the client MUST reject the response if the Option Value of the Request-Hash Option is different from the Option Value of the Request-Hash Option that was included in the Deterministic Request.
3. The client retrieves the Recipient Context to use for decrypting and verifying the response, based on the 'kid' either retrieved from the OSCORE Option of the response if present therein, or otherwise of the server to which the Deterministic Request was sent to. Then, the client decrypts and verifies the response using the group mode of Group OSCORE, as defined in . When verifying the response, the Request-Hash Option is treated as a Class I option.
4. If the Deterministic Request included an Inner Observe Option but not an Outer Observe option (see ), the client MUST silently ignore the Inner Observe Option in the response, which MUST NOT result in stopping the processing of the response. Note that this deviates from , but it is limited to a very specific situation, where the client and server both know exactly what happens. This does not affect the use of Group OSCORE in other situations.

Deterministic Requests to Multiple Servers A Deterministic Request can be sent to a CoAP group, e.g., over UDP and IP multicast , 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 . Note that this deviates from the recommendation in , since the Deterministic Request in this case is indeed intended to multiple recipients, but yet it is protected with the pairwise mode. However, this is limited to a very specific situation, where the client and servers both know exactly what happens. This does not affect the use of Group OSCORE in other situations. When a server receives a request from the Deterministic Client as addressed to a CoAP group, the server proceeds as defined in , with the difference that it MUST include its own Sender ID in the response, as the 'kid' parameter of the OSCORE Option. Although it is normally optional for the server to include its Sender ID when replying to a request that is protected with the pairwise mode, it is required in this case for allowing the client to retrieve the Recipient Context associated with the server originating the response. If a server is a member of a CoAP group, and it fails to successfully decrypt and verify an incoming Deterministic Request, then it is RECOMMENDED for that server to not reply with an error response, in the case that the server verifies that the Deterministic Request was sent to the CoAP group (e.g., to the associated IP multicast address) or in the case that the server is not able to verify that altogether. When the client receives a response to a Deterministic Request that it sent to a CoAP group, the client performs the same actions defined in , with the following differences:

• At Step 1, if the response does not include a 'kid' in the OSCORE Option, the client MUST reject the response. Otherwise, no verification of the 'kid' is performed.
• At Step 3, the client retrieves the Recipient Context to use for decrypting and verifying the response, based on the 'kid' retrieved from the OSCORE Option of the response.

Obtaining Information about the Deterministic Client This section extends the joining process defined in and based on the Authentication and Authorization for Constrained Environments (ACE) framework . 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 ). With reference to the 'key' parameter included in the Join Response defined in , the Group_OSCORE_Input_Material object specified as its value contains also the two additional parameters 'det_senderId' and 'det_hash_alg'. These are registered in of this document and are defined as follows:

• 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 . 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 included in a Key Distribution Response (see Sections and of ). With reference to the 'key' parameter included in a Signature Verification Data Response defined in , the Group_OSCORE_Input_Material object specified as its value contains also the 'det_senderId' parameter defined above.

Implementation Status Note to RFC Editor: when deleting this section, please also delete RFC 7942 from the references of this document. (Boilerplate as per :) This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Implementation in Californium

• Responsible organization: RISE Research Institutes of Sweden AB
• Implementation's name: Cacheable OSCORE for Eclipse Californium
• Available at: https://github.com/rikard-sics/californium/tree/cacheable-oscore
• Description: Implementation in Java, building on Eclipse Californium, see:
  • https://github.com/eclipse-californium/californium
  • http://eclipse.dev/californium/
• Implementation's level of maturity: prototype
• Version compatibility: -08 (which is the last time the wire format changed)
• Licensing: according to the same dual license of Eclipse Californium, i.e., according to the "Eclipse Distribution License 1.0" and the "Eclipse Public License 2.0". See:
  • https://github.com/eclipse-californium/californium/blob/main/LICENSE
  • https://www.eclipse.org/org/documents/edl-v10.php
  • https://www.eclipse.org/legal/epl-2.0/
• Contact point: Marco Tiloca - marco.tiloca@ri.se
• Last updated: 2025-06-27

Implementation in aiocoap

• Implementation: aiocoap https://christian.amsuess.com/tools/aiocoap/
• Description: General purpose unconstrained implementation of CoAP
• Implementation maturity: Cacheable OSCORE is part of the regular release, but not well integrated in the security setup.
• Version compatibility: -08 (which is the last time the wire format changed)
• Licensing: MIT
• Contact point: Christian Amsüss
• Last updated: 2025-06-30

Security Considerations The same security considerations from , , , and hold for this document. The following elaborates on how, compared to , Deterministic Requests dispense with some of the Group 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 , 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 methods can help the server make that assessment.
  • Consistent 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 conveys a smaller sequence number as Partial IV.
  • 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 methods 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 thus associate the different responses generated for them. If a server produces responses in reply to a Deterministic Request and those responses vary in size, the server can use the Padding Option defined in in order to hide when the response is changing.

[ Editor's note: more on the verification of the Deterministic Request ]

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.

CoAP Option Numbers Registry IANA is asked to add the following entries in the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Registrations in the CoAP Option Numbers Registry

Number	Name	Reference
TBD548	Request-Hash	[RFC-XXXX]
TBD64988	Padding	[RFC-XXXX]

Note to RFC Editor: Please remove the text following this note and within the present . Then, please delete this note. [ 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 "Expert 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 the Option Delta/Length and two more bytes for the extended Option Delta (see ). This is considered acceptable overhead, given that the application has already chosen to prefer the privacy gains of padding over wire transfer length. ]

OSCORE Security Context Parameters Registry IANA is asked to add the following entries in the "OSCORE Security Context Parameters" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.

• Name: det_senderId
• CBOR Label: 14 (suggested)
• CBOR Type: byte string
• Registry: -
• Description: OSCORE Sender ID assigned to the Deterministic Client of an OSCORE group
• Reference: [RFC-XXXX]

• Name: det_hash_alg
• CBOR Label: 15 (suggested)
• CBOR Type: text string / integer
• Registry: Values (Hash)
• Description: Hash algorithm to use in an OSCORE group when producing a Deterministic Request
• Reference: [RFC-XXXX]

References Normative References IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). IANA IANA IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. Object Security for Constrained RESTful Environments (OSCORE) is a means of end-to-end protection of short request/response exchanges for tiny devices, typically transported using the Constrained Application Protocol (CoAP). This document aims to assist implementers in leveraging the optimizations catered for by the combination of CoAP and OSCORE, and by generally providing experience from earlier implementations. RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. In some use cases, such as those based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing the same target resource. This document updates RFC7252 and RFC7641, and it defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of the same resource on the same shared Token value. Besides, this document defines how the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to- end between the server and the observer clients. RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. Universität Bremen TZI In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request. The present memo describes two forms of responses that go beyond that model. The design spaces for the new CoAP Options proposed to represent these responses are now sufficiently understood that they can be developed to standards-track specifications, either in this document or by transferring the specification for an Option to a document that that Option closely works with. RISE AB RISE AB Ericsson AB Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as for managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The Authentication and Authorization for Constrained Environments (ACE) framework is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof of possession, and server authentication. This document defines a protocol for exchanging DNS queries (OPCODE 0) over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by (D)TLS-Secured CoAP or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Padding As discussed in , 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 Padding Option is defined (see ), as a means to increase the length of a message without changing its meaning. The option can be used with any CoAP transport, but it is especially useful when using OSCORE or Group OSCORE, since they do not provide any padding of their 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.

The Padding Option The option is called Padding and its properties are summarized in , which extends Table 4 of . The option is Elective, Safe-to-Forward, not part of the Cache-Key, and repeatable. The option may be repeated, as that may be the only way to achieve a certain total length for the padded message. The Padding Option (C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable)

No.	C	U	N	R	Name	Format	Length	Default
TBD64988			x	x	Padding	opaque	any	(none)

The Padding Option is treated as Class E for OSCORE , which makes it indistinguishable from other Class E options or from the message payload to third parties.

Using and Processing the Padding Option A server that produces different responses of different length for a given class of requests might wish to produce responses of consistent length, typically to hide the variation from anyone but the intended recipient. In such a case, the server can pick a length that all possible responses can be padded to, and set the Padding Option with a suitable all-zero Option Value in all responses to that class of requests. Likewise, a client can decide on a class of requests that it pads to reach a consistent length. This has considerably less efficacy and applicability when applied to Deterministic Requests. That is: an external observer can group together different requests even if they are of the same length; and padding would hinder convergence on a single Consensus Request, thus requiring all users of the same Group OSCORE Security Context to agree in advance on the same total length for the requests. Any party receiving a Padding Option MUST ignore it. In particular, a server MUST NOT make its choice of padding a response dependent on any padding present in the corresponding request. A means driven by the client for coordinating response padding is out of scope for this document. Proxies that see a Padding Option MAY discard it.

Simple Cacheability using Ticket Requests Building on the concept of Phantom Requests and Informative Responses defined in , 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 ). Rather, it is more provided as a "mental exercise" for the authors and interested readers to bridge the gap between this document and . 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 will be able to see from the countersignature of later responses that this was indeed the request that the server is replying to. The client also verifies that the request URI is identical between the original request and the Ticket Request. The remaining exchange can largely play out like in 's "Example with a Proxy and with Group OSCORE". That is, the client first sends the Phantom Request to the proxy (but, lacking a tp_info, without including a Listen-To-Multicast-Responses Option). Then, the proxy forwards the Phantom Request to the server, due to the lack of the Listen-To-Multicast-Responses Option. The server then produces a regular response and includes an Outer Max-Age Option with Option Value different from zero. 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 replies 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.

Application for More Efficient End-to-End Protected Multicast Notifications The specification defines how a CoAP server can serve all clients observing a same resource at once, by sending notifications over multicast. As described in , 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 and the "Example with a Proxy and with Group OSCORE" in shows that, when using Group OSCORE, more requests need to reach the server. This is because every client originally protects its Observation request individually, and thus it 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. This is shown by the "Example with a Proxy and with Deterministic Requests" in .

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

Unsorted Further Ideas

• We could allow clients to elide all other options than the Request-Hash Option, and elide the payload, if they have reason to believe that they 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 would need special handling for error responses, or criteria by which proxies do not even forward these if they do not have a response at hand). That may be more trouble than it is worth without a strong use case (say, of complex but converging FETCH requests). Hashes could also be used in a truncated form for that -- should we suggest SHA-256/128 as a default? (Its birthday paradox starts to kick in at around 2⁶⁴ deterministic requests).

Test Vectors This appendix includes test vectors for an example where the method defined in this document is used. In the following, a CoAP Client C and a CoAP Server S are member of the same OSCORE group, and they exchange Deterministic Requests and corresponding responses. Note that, while they are consistent with the presented example, the values of the Token and Message ID in the CoAP messages are only indicative, as they are subject to change throughout different message exchanges. The considered authentication credentials of the CoAP Server S and of the Group Manager are CWT Claims Sets (CCSs) . Both authentication credentials as well as the aad_array used through the Group OSCORE processing are also expressed in CBOR extended diagnostic notation as defined in and .

Setup The Group OSCORE Security Context specifies the following parameters.

• AEAD Algorithm: AES-CCM-16-64-128 (10)
• HKDF Algorithm: HKDF SHA-256 (5)
• Group Encryption Algorithm: AES-CCM-16-64-128 (10)
• Signature Algorithm: EdDSA (used with curve Ed25519) (-8, 6)
• Pairwise Key Agreement Algorithm: ECDH-SS-HKDF-256 (used with curve X25519) (-27, 4)
• Hash algorithm for Deterministic Requests: SHA-256 (-16)
• Master Secret (16 bytes):

• Master Salt (8 bytes):

• ID Context (2 bytes):

• Deterministic Client's Sender ID (1 byte):

• Server's Sender ID (1 byte):

• Server's authentication credential as CCS (CBOR diagnostic notation):

• Server's authentication credential as CCS (serialization) (118 bytes):

• Server's private key (serialization) (32 bytes):

• Group Manager's authentication credential as CCS (CBOR diagnostic notation):

• Group Manager's authentication credential as CCS (serialization) (124 bytes):

Deterministic Request The client generates an unprotected CoAP GET request, which contains only the Uri-Path Option with value "helloWorld". The request is Confirmable, with a Token length equal to 8 bytes. Unprotected CoAP request (23 bytes): The client protects the CoAP request above to produce a Deterministic Request. When doing so, the client does not include an Inner Observe Option.   The following information is used to compute the Request-Hash value.

• Deterministic Client's Sender Key (16 bytes):

• aad_array (CBOR diagnostic notation):

• aad_array (serialization) (150 bytes):

• Plaintext (12 bytes):

• Request-Hash value (32 bytes):

  The following information is used to produce the protected Deterministic Request.

• Partial IV (1 byte):

• kid (1 byte):

• kid context (2 bytes):

• AAD (serialization) (163 bytes):

• Plaintext (12 bytes):

• Encryption Key (16 bytes):

• Nonce (13 bytes):

  From the previous parameter, the following is derived:

• OSCORE Option value (6 bytes):

• Request-Hash Option value (32 bytes):

• Ciphertext (20 bytes):

From there, the protected CoAP request as Deterministic Request (76 bytes):

Response to Deterministic Request The server responds to the first request with an ACK message, to which a 2.05 (Content) response indicating a Max-Age of 3600 seconds is piggybacked. The payload of the response is the ASCII-encoded string ". ID: 42". Unprotected CoAP response (61 bytes): The server protects the CoAP response above as follows. When doing so, the server: does not include an Inner Observe option; includes its own Sender ID in the 'kid' of the OSCORE option; elides the Request-Hash Option from the response.   The following information is used to protect the response.

• Partial IV (1 byte):

• kid (1 byte):

• kid context (2 bytes):

• aad_array (CBOR diagnostic notation):

• aad_array (serialization) (303 bytes):

• AAD (serialization) (317 bytes):

• Plaintext (14 bytes):

• Encryption Key (16 bytes):

• Nonce (13 bytes):

  From the previous parameter, the following is derived:

• OSCORE Option value (3 bytes):

• Request-Hash Option value (32 bytes):

• Ciphertext (22 bytes):

• Plain signature (64 bytes):

• Signature Encryption Key (16 bytes):

• Signature keystream (64 bytes):

• Encrypted signature (64 bytes):

  From there, the protected CoAP response (106 bytes):

Document Updates

Version -01 to -02

• Shortened title.
• Removed some old Editor's notes.
• Updated references.
• Fixed/improved presentation of:
  • Processing of a Deterministic Request at the server.
  • Composition of the response to a Deterministic Request at the server.
  • Processing of the response to a Deterministic Request at the client.
• Minor clarifications and editorial improvements.

Version -00 to -01

• Updated title.
• Revised abstract and first part of the introduction.
• Updated references.
• Suggested values for IANA registrations.
• Removed changelog for the individual submission document.
• Minor clarifications and editorial improvements.

Acknowledgments The authors sincerely thank , , , and for their comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).