Distribution of Software Updates with End-to-End Secure Group Communication and Block-Wise Transfer for CoAP

1.1. Terminology

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

Readers are expected to be familiar with the terms and concepts related to:¶

• CoAP [RFC7252], also used for group communication [I-D.ietf-core-groupcomm-bis] and over TCP [RFC8323].¶

• The CoAP extensions Observe [RFC7641] and Block-wise [RFC7959].¶

• The security protocols OSCORE [RFC8613] and Group OSCORE [I-D.ietf-core-oscore-groupcomm], and the use of the latter to enable cacheability of protected CoAP responses [I-D.amsuess-core-cachable-oscore].¶

• Concise Data Definition Language (CDDL) [RFC8610], Concise Binary Object Representation (CBOR) [RFC8949], and CBOR Object Signing and Encryption (COSE) [RFC9052][RFC9053].¶

This document also relies on the following terminology:¶

• Image: a binary that can contain the complete SW of a device, or part of it. The image might be in turn structured in multiple images, and the corresponding SW might specifically be a firmware. Also, it might consist of a differential update in the interest of performance.¶

• Manifest: a collection of metadata about the image and author. The manifest is generated by the author and protected against modifications.¶

• Author: the entity that generates the image and the associated manifest.¶

• Device: target of a SW update as intended to obtain and consume an image.¶

• Distributor: the entity that distributes the image and the associated manifest on behalf of the author.¶

• Manifest resource: a resource hosted at the Distributor, with a manifest as its representation. This resource is observable [RFC7641].¶

• Image resource: a resource hosted at the Distributor, with an image as its representation.¶

2.1. CoAP

CoAP is a web-transfer protocol specified in [RFC7252]. It relies on the client-server message exchange model and builds on the Representational State Transfer (REST) paradigm for accessing and manipulating resource representations hosted at a server. CoAP messages can be very compact and, besides a payload and a mandatory header, can include CoAP options that indicate the additional use of protocol extensions and optional features. The mandatory header includes a variable-length Token field whose value is used to associate a response with a corresponding request. CoAP is typically transported over UDP, but can also be used over reliable transports such as TCP and WebSockets [RFC8323].¶

CoAP natively supports proxies deployed between origin client endpoints and origin server endpoints. Main reasons to deploy proxies include: relaying messages between origin endpoints that cannot directly interact with one another; caching response messages to serve requests from origin clients more efficiently and avoiding repeatedly interacting with origin servers; and performing protocol translation across different communication legs. Proxy operations for CoAP are detailed in Section 5.7 of [RFC7252].¶

CoAP also natively supports group communication [I-D.ietf-core-groupcomm-bis]. That is, an origin client can send a single group request targeting multiple recipient servers at once, e.g., over UDP and IP multicast. The servers can individually reply to that group request by sending their unicast responses, each of which is associated by Token value with the same group request.¶

2.2. CoAP Observe

Observe is an extension for CoAP specified in [RFC7641]. When using Observe, a client accesses a resource at a server by additionally requesting to be registered as an observer for that resource. A successful response from the server can confirm the client to have become a registered observer. In such a case, following updates in the resource representation will result in the server sending notification responses to the client. Each of such notification responses conveys the current resource representation and is associated by Token value with the request originally sent by the client to start the observation. This extension relies on the CoAP Observe option included in the original observation request and in each notification response.¶

2.3. CoAP Block-wise Transfer

Block-wise is an extension for CoAP specified in [RFC7959]. With the intent to avoid message fragmentation at lower layers, Block-wise enables message senders to split their large-size application data to transmit (body) into multiple, smaller data units referred to as blocks. This process occurs at the CoAP layer and results in sequentially sending each block of the same body as the payload of a different CoAP message. The message recipient can re-assemble the original body once all the corresponding blocks are received. This extension relies on the CoAP Block1 and Block2 options. Those are appropriately included in request and response messages to either describe the block conveyed in the present message or to control the Block-wise transfer process.¶

For the case where CoAP is transported over reliable transports such as TCP, [RFC8323] also specifies Block-wise Extension for Reliable Transport (BERT). This still relies on the same CoAP Block1 and Block2 options as also explicitly indicating the use of BERT. In practice, a BERT message conveys in its payload one or more blocks of size 1024 bytes, with the possible exception of the BERT message conveying the last block that can have a smaller size.¶

2.4. OSCORE

Object Security for Constrained RESTful Environments (OSCORE) is a security protocol specified in [RFC8613]. OSCORE protects CoAP messages end-to-end between the origin endpoint producing application data and the other origin endpoint consuming that data.¶

To this end, it takes as input an outgoing CoAP message and produces as output an OSCORE-protected CoAP message that includes the CoAP OSCORE option. When receiving the OSCORE-protected message, the recipient endpoint relies on the information in the OSCORE option to attempt decrypting and verifying the message. By using CBOR [RFC8949] for data encoding and COSE [RFC9052] for security operations, OSCORE has a lightweight impact on message sizes and performance.¶

OSCORE ensures end-to-end confidentiality, integrity, and source authentication of messages, as well as replay protection. Each OSCORE-protected response is cryptographically bound to the corresponding request, also in case Observe [RFC7641] is used and thus multiple notification responses are bound to the same observation request.¶

These security properties hold also in the presence of (untrusted) proxies deployed between the two OSCORE endpoints. Since OSCORE selectively protects different parts of a CoAP message, it hides as much as possible from possibly deployed proxies, while still leaving those able to perform their intended tasks. Furthermore, since the OSCORE processing of a CoAP message results in another CoAP message, OSCORE is independent of the specific transport underlying CoAP and used to transport CoAP messages (e.g., UDP or TCP). Therefore, OSCORE works wherever CoAP works.¶

In order to use OSCORE, two CoAP endpoints have to first establish an OSCORE Security Context including the necessary parameters and keying material. OSCORE is agnostic of how exactly the Security Context is established. A possible way is the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528].¶

2.5. Group OSCORE

Group OSCORE is a security protocol specified in [I-D.ietf-core-oscore-groupcomm]. By building on OSCORE [RFC8613] and extending its construct, Group OSCORE protects CoAP messages end-to-end between endpoints that use CoAP in a group communication setup [I-D.ietf-core-groupcomm-bis].¶

Also by relying on CBOR [RFC8949] and COSE [RFC9052], Group OSCORE ensures end-to-end confidentiality, integrity, and source authentication of messages, as well as replay protection. All the protected responses originated by different servers and corresponding to the same group request are cryptographically bound to such request.¶

Messages protected with Group OSCORE also include a CoAP OSCORE option that indicates the recipient endpoint how to attempt decrypting and verifying an incoming message. Like OSCORE, Group OSCORE works wherever CoAP works, also in the presence of proxies.¶

Group OSCORE provides two modes for protecting messages, allowing to choose the mode to use on a per-message basis. The main difference between the two modes is about the way used to ensure source authentication of the protected message:¶

• When using the group mode (see Section 7 of [I-D.ietf-core-oscore-groupcomm]), the message is first encrypted with keying material that every group member can derive, and then is signed by using the private key of the sender endpoint. The resulting signature is placed at the end of the CoAP payload of the protected message and then separately encrypted in order to contrast tracking of endpoints across different groups. As a result, all group members are able to decrypt the message and to verify that the message sender is the alleged group member. The group mode is typically used to protect requests sent to the whole group, i.e., intended to all its CoAP servers.¶

• When using the pairwise mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]), the message is protected by using an authenticated encryption algorithm. The encryption key to use is derived from the asymmetric authentication credentials of the sender endpoint and the single recipient endpoint, by means of a static-static Diffie-Hellman key derivation performed locally. As a result, only the intended recipient is able to decrypt the message and to verify that the message sender is the alleged group member. The pairwise mode is typically used to protect a response individually sent by a server in the group.¶

In order to use Group OSCORE, a CoAP endpoint has to join an OSCORE group and effectively become a member. The join process is typically assisted by a Group Manager entity that is responsible for the OSCORE group and that might enforce access control when deciding whether to admit new endpoints requesting to join the group. As a result of a successful join process, a CoAP endpoint obtains the necessary parameters and keying material to set up a Group OSCORE Security Context and consequently use Group OSCORE with the other group members. A possible realization of Group Manager is specified in [I-D.ietf-ace-key-groupcomm-oscore], where the join process is based on the ACE framework for authentication and authorization in constrained environments [RFC9200].¶

2.6. Observe multicast notifications

According to the original use of CoAP Observe [RFC7641], two CoAP clients interested in registering a resource observation at a server will yield two distinct observations.¶

However, some applications involve multiple clients that are all interested in observing the same resource at the same server. While the original approach remains usable, an alternative and more scalable approach is specified in [I-D.ietf-core-observe-multicast-notifications].¶

This second approach takes advantage of group communication for CoAP and relies on the CoAP server to initiate a group observation at itself, e.g., upon receiving a first traditional observation request from a client. To this end, the server composes a cosmetic phantom observation request and sends it to itself without hitting the wire, in order to start the corresponding group observation.¶

When a client sends a traditional observation request targeting that resource, the server replies with an informative error response conveying: i) the phantom observation request associated with the group observation; and ii) transport-specific information that is needed for receiving the notification responses in the group observation. That information includes the CoAP Token value used for the phantom observation request and the multicast address where observe notifications will be sent to. This effectively aligns all the interested clients to the same common knowledge required for participating in the group observation and receiving the multicast notification responses.¶

Consequently, when the representation of the observed resource at the server changes, the server sends a single observe notification response over UDP and IP multicast, thus targeting all the clients that are taking part in the group observation. All such observe multicast notifications include the same CoAP Token value used in the phantom observation request. The recipient clients have been instructed on how to receive such observe multicast notifications when obtaining the individual informative error response from the server.¶

The observe multicast notifications can be protected end-to-end between the server and the clients, by using Group OSCORE in group mode [I-D.ietf-core-oscore-groupcomm]. Since the server uses Group OSCORE also to protect the phantom observation request that started the group observation, all the observe notifications in the group observation are cryptographically bound to such phantom observation request, and thereby verifiable to pertain to the group observation in question.¶

2.7. Cacheable OSCORE

It is typically possible to rely on a deployed proxy to store in its cache some classes of CoAP responses received from origin servers. That allows the proxy to quicker serve later requests from CoAP clients that produce a cache hit, by replying with the cached response instead of obtaining a new response from the origin server.¶

If CoAP messages are protected with OSCORE [RFC8613] or [I-D.ietf-core-oscore-groupcomm], effective caching of responses is not achievable anymore. That is, even if two clients wish to send the same plain CoAP request, the two resulting protected requests will be different and thus will not result in a cache hit at the proxy. Therefore, separately for each of the two clients, the proxy has to retrieve a new response from the origin server.¶

In order to overcome this limitation, the approach defined in [I-D.amsuess-core-cachable-oscore] builds on Group OSCORE and restores the effective cacheability of protected responses.¶

According to this approach, any client in the OSCORE group can also act as a specific "Deterministic Client" and use the corresponding keying material known to all the group members. When acting as Deterministic Client, any two clients in the group that protect the same plain CoAP request will produce the same protected "Deterministic Request", which is thereby usable to produce a cache hit at a caching proxy.¶

The construct that makes this possible relies on the following design points: i) Deterministic Requests are computed by using a variation of the pairwise mode of Group OSCORE; ii) responses to a Deterministic Request are protected by using the group mode of Group OSCORE.¶

This approach restores cacheability of protected responses while sacrificing some security properties of the protected Deterministic Requests, which in fact are replays and have no source authentication. However, this is deemed acceptable and harmless for the particular, narrow scope targeted by this approach, whose applicability is limited to content retrieval through read-only requests that are safe in the REST sense. Servers that want to be even more conservative can additionally limit themselves to accept only Deterministic Requests that target specific resources, or even that match byte-by-byte with Deterministic Requests known in advance.¶

4.1. Design Goals

The distribution method builds on the following design goals.¶

• Ensure end-to-end secure communication between the Devices and the Distributor.¶

  This goal is addressed by using Group OSCORE [I-D.ietf-core-oscore-groupcomm] to protect the messages exchanged by the Devices and the Distributor through the Proxy.¶

  The use of Group OSCORE is facilitated by a Group Manager that provides the necessary parameters and keying material to the intended group members, which is therefore not a concern for the Distributor.¶

• Limit interactions and exchanges with the Distributor.¶

  This goal is achieved by means of the Proxy deployed between the Devices and the Distributor and specifically relying on:¶

  • Large-size inner chunks that the Distributor provides to the Proxy, by using BERT [RFC8323].¶

  • Cacheable protected responses that are cached at the Proxy as per the construct defined in [I-D.amsuess-core-cachable-oscore], thereby sparing the retrieval of a cached inner chunk from the Distributor.¶

• Limit interactions and exchanges with the Devices.¶

  This goal is achieved by means of the Proxy deployed between the Devices and the Distributor and specifically relying on:¶

  • Cacheable protected responses that are cached at the Proxy as per the construct defined in [I-D.amsuess-core-cachable-oscore], thereby enabling the Proxy to quicker serve Devices' requests from its cache.¶

  • Responses sent by the Proxy to the Devices over UDP and IP multicast, building on concepts defined for observe multicast notifications in [I-D.ietf-core-observe-multicast-notifications].¶

  • Transferring outer chunks from the Proxy to the Devices in an uninterrupted, back-to-back fashion, thus avoiding the downsides of a synchronous, lock-step process based on the original Block-wise transfer [RFC7959].¶

• Accommodate Devices over constrained network links.¶

  This goal is achieved by means of the Proxy using small outer chunks (e.g., 64 bytes each in size) as the actual unit of distribution, when providing a SW update to the Devices.¶

4.2. Release and Notification of SW Update

This part of the process is devoted to inform the Devices about a newly released SW update as available at the Distributor.¶

A Device interested in obtaining SW updates for that SW component has to know the URI of the corresponding manifest resource at the Distributor and be able to access that resource through the Proxy.¶

In order to be informed of a newly available SW update, the Device performs the following actions.¶

1. The Device composes an observation request [RFC7641] targeting the manifest resource at the Distributor.¶

2. The Device protects the observation request from Step 1 with Group OSCORE, specifically using the construct defined in [I-D.amsuess-core-cachable-oscore] and therefore producing a Deterministic Request.¶

3. The Device sends the Deterministic Request from Step 2 to the Proxy.¶

   If the Deterministic Request does not produce a cache hit at the Proxy (e.g., as the first of this kind sent by any Device), the Proxy forwards the Deterministic Request to the Distributor, thereby registering itself as the actual observer at the Distributor. The Proxy caches the corresponding successful response from the Distributor and forwards it back to the Device.¶

   Otherwise, the Proxy does not interact with the Distributor, but instead promptly replies to the Device, by using the response stored in the identified cache entry.¶

4. Upon receiving a first successful notification response, the Device obtains the latest manifest and is subscribed for automatically receiving future manifests released for the same SW component.¶

When releasing a new SW update, the Author uploads the corresponding manifest and image on the Distributor. As discussed in Section 3, those become available at the manifest resource and at a new, dedicated image resource hosted by the Distributor, respectively. After that, the Distributor sends a notification response to the observer Proxy, conveying the newly released manifest.¶

The Proxy stores the notification response in the cache entry that it uses to store responses for that observation, by overwriting the current content of the entry. Finally, the Proxy forwards that notification response to the observer Devices. Upon receiving the notification response, the observer Devices obtain the new manifest, thus becoming aware of the new SW update and of the corresponding image resource at the Distributor.¶

In setups where multiple Proxies are deployed and each assists a different set of Devices, the Distributor can rely on the approach defined in [I-D.ietf-core-observe-multicast-notifications] as a possible optimization. Consequently, following the release of a new SW update, the Distributor sends a single observe notification response over UDP and IP multicast, thereby providing all the observer Proxies at once with the latest manifest corresponding to the newly released SW update.¶

Figure 2 shows an example of message exchange where the two Devices obtain the latest manifest from the Distributor through the Proxy.¶

4.3. Distribution of SW Update

The distribution of an image to target Devices is driven by the Proxy and organized into epochs, each of which is in turn composed of different phases, as shown in Figure 3.¶

Each epoch is devoted to transferring exactly one inner chunk of the image, by providing the target Devices with all the corresponding outer chunks.¶

After completing the epoch during which the last inner chunk of the image has been transferred, the next epoch is devoted to transfer again the first inner chunk of the image, i.e., the transfer of the whole image is repeated.¶

The following describes in detail the operations performed by a Device and by the Proxy during the transfer of an image.¶

5.1. Root Checksum Key

When using the method defined in this document, the Group OSCORE Security Context shared by the Distributor and the Devices is extended with one additional parameter in the Common Context.¶

The new parameter Root Checksum Key specifies a secret key. This is used for deriving checksum keys that are in turn used for computing checksums of outer chunks (see Section 5.4).¶

The Root Checksum Key is derived as defined for the Sender/Recipient Keys in Section 3.2.1 of [RFC8613], with the following differences.¶

• The 'id' element of the 'info' array is the empty byte string.¶

• The 'type' element of the 'info' array is "RCKey". The label is an ASCII string and does not include a trailing NUL byte.¶

• The 'alg_aead' element of the 'info' array specifies the Group Encryption Algorithm from the Common Context (see Section 2.1.7 of [I-D.ietf-core-oscore-groupcomm]) encoded as a CBOR integer or text string, consistently with the "Value" field in the entry of the "COSE Algorithms" Registry for this algorithm [COSE.Algorithms].¶

• The L parameter of the HKDF and the 'L' element of the 'info' array are the length in bytes of the key for the Group Encryption Algorithm specified in the Common Context. While the obtained Root Checksum Key is never used with the Group Encryption Algorithm, its length was chosen to obtain a matching level of security.¶

5.2. Derivation of Checksum Keys

The same checksum key K is used for computing the checksum value on all the outer chunks of the same inner chunk.¶

In particular, K is derived:¶

• By the Distributor, upon sending to the Proxy a CoAP response over TCP as the inner chunk to distribute in the current epoch (see Section 4.3.2.1 and Section 4.3.2.2).¶

  Note that the Distributor provides the Proxy with the checksum K as embedded in that response (see Section 5.6).¶

• By each target Device, when receiving an outer chunk of the inner chunk distributed in the current epoch (see Section 4.3.2.3 and Section 4.3.2.5).¶

A checksum key K SHALL be derived as follows, by using the HKDF Algorithm from the Common Context of the Group OSCORE Security Context (see Section 2.1.2 of [I-D.ietf-core-oscore-groupcomm]), which consists of composing the HKDF-Extract and HKDF-Expand steps [RFC5869].¶

K = HKDF(salt, IKM, info, L)¶

The input parameters of HKDF are as follows.¶

• salt takes as value the index of the inner chunk to distribute in the current epoch, i.e., INNER_INDEX, represented in the smallest number of bytes needed.¶

  From the Distributor point of view, this value is specified by the NUM field of the value of the Block2 outer option, which is included in the response sent to the Proxy as the inner chunk.¶

  From the Device point of view, this value is encoded as a CBOR unsigned integer by the "progress_indicator" parameter, which is conveyed in the payload of the error informative responses that the Proxy sends during the "Admission" phase (see Section 4.3.2.2) and the "Recovery Claim" phase (see Section 4.3.2.4).¶

• IKM is the Root Checksum Key from the Common Context (see Section 5.1).¶

• info is the serialization of a CBOR array consisting of (the notation follows [RFC8610]):¶

   info = [
     piv : bstr,
     L : uint
   ]

where:¶

• piv is the Partial IV field in the OSCORE option of the following messages:¶

  • From the Distributor point of view, the response that the Distributor sends to the Proxy as the inner chunk to distribute in the current epoch.¶

    Note that, such a message is specifically a response to a Deterministic Request. Therefore, it always includes a Partial IV in the OSCORE option (see [I-D.amsuess-core-cachable-oscore]).¶

  • From the Device point of view, the responses received from the Proxy during the "Full Transfer" phase (see Section 4.3.2.3) and "Recovery Transfer" phase (see Section 4.3.2.5) as the outer chunks of the inner chunk distributed in the current epoch.¶

    Note that all such responses include a Partial IV in the OSCORE option. The value of the Partial IV is the same one of the Partial IV in the OSCORE option of the response that the Proxy received from the Distributor as the inner chunk to distribute in the current epoch.¶

• The L parameter of the HKDF and the 'L' element of the 'info' array are the length in bytes of the Root Checksum Key from the Common Context.¶

5.3. Checksum Option

The Checksum option defined in this section has the properties summarized in Table 1, which extends Table 4 of [RFC7252]. The option is Elective, Safe-to-Forward, and part of the Cache-Key. The option MUST occur at most once.¶

The option value is a checksum computed over (part of) the message by the endpoint that added the option, thereby enabling the message recipient to perform an integrity check on the message.¶

The Checksum option is of class U for OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].¶

5.4. Computation and Embodiment of Checksums

The Proxy computes the checksum on an outer chunk before sending that outer chunk to the target Devices, during the "Full Transfer" phase (see Section 4.3.2.3) and "Recovery Transfer" phase (see Section 4.3.2.5).¶

After having computed the checksum as defined below, the Proxy specifies it as value of the Checksum option (see Section 5.3) and includes the option in the response sent as outer chunk to the Devices. If outer CoAP options were already included in the response and their option number is greater than that of the Checksum option, then the Proxy appropriately updates their Option Delta (see Section 3.1 of [RFC7252]).¶

A Device computes the checksum on an outer chunk upon receiving that outer chunk from the Proxy, during the "Full Transfer" phase (see Section 4.3.2.3) and "Recovery Transfer" phase (see Section 4.3.2.5).¶

In particular, the Device first removes the Checksum option from the response received as outer chunk from the Proxy. After that, if outer CoAP options are included in the response and their option number is greater than that of the Checksum option, then the Device appropriately updates their Option Delta. Finally, the Device computes the checksum on the resulting response and compares the result against the checksum specified as value of the removed Checksum option.¶

If the two checksums are not equal, the Device MUST discard the response without further processing it. If this happens during the "Full Transfer" phase, the Device can send a request to the Proxy during the immediately following "Recovery Claim" phase (see Section 4.3.2.4), thus asking the Proxy to re-send the outer chunk during the immediately following "Recovery Transfer" phase.¶

Given a response that the Proxy sends as outer chunk, the checksum on that outer chunk is a 2-byte MAC that SHALL be computed as follows by using the HKDF algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps [RFC5869].¶

MAC = HKDF(salt, IKM, info, L)¶

The input parameters of HKDF are as follows.¶

• salt takes as value the index of the inner chunk to distribute in the current epoch, i.e., INNER_INDEX, represented in the smallest number of bytes needed.¶

  From the Proxy point of view, INNER_INDEX is stored and consistently updated throughout the different epochs of the image distribution (see Section 4.3.2).¶

  From the Device point of view, this value is encoded as a CBOR unsigned integer by the "progress_indicator" parameter, which is conveyed in the payload of the error informative responses that the Proxy sends during the "Admission" phase (see Section 4.3.2.2) and the "Recovery Claim" phase (see Section 4.3.2.4).¶

• IKM is the Checksum Key to use for this inner chunk, which is derived as defined in Section 5.2.¶

• info is the serialization of the CoAP response that the Proxy has to send as outer chunk.¶

  The Proxy MUST use the CoAP response available before the addition of the Checksum option.¶

  The Device MUST use the CoAP response available after:¶

  • Removing the Checksum option; and¶

  • Updating the Option Delta of each outer option whose option number is greater than that of the Checksum option.¶

• L has value 2.¶

5.5. Pre-OSCORE-Data Option

The Pre-OSCORE-Data option defined in this section has the properties summarized in Table 2, which extends Table 4 of [RFC7252]. The option is Critical, Safe-to-Forward, part of the Cache-Key, and repeatable.¶

The presence of this option means that, within the CoAP payload, the OSCORE ciphertext is prepended by a CBOR data item that is intended for the consumer of the option.¶

The option value is an unsigned integer that identifies the semantics of the data conveyed by the CBOR data item. In particular, the option value MUST be either X or (X + 1), where X is taken from the 'Value' column of the "Pre-OSCORE Data Semantics" IANA registry defined in Section 8.3. Both X and (X + 1) identify the same data semantics. However:¶

• The odd value X means that the CBOR data item is a CBOR byte string, whose value is the data with the indicated semantics.¶

• The even value (X + 1) means that the CBOR data item is a COSE object, i.e., a possibly tagged COSE message as defined in Section 2 of [RFC9052].¶

  The data with the indicated semantics consists of what is available at the recipient once successfully completed all the COSE processing, e.g., a plaintext recovered after a decryption process.¶

The recipient of a CoAP message including the Pre-OSCORE-Data option MUST consume the option, i.e., it removes and consumes the prepended CBOR data item from the CoAP payload, after which it removes the option from the message.¶

The Pre-OSCORE-Data option MAY occur multiple times. In such a case, each occurrence of the option refers to one CBOR data item prepended to the OSCORE ciphertext within the CoAP payload. In particular, the i-th occurrence of the option refers to the i-th prepended CBOR data item.¶

The Pre-OSCORE-Data option is of class U for OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].¶

5.6. Provisioning of Checksum Keys to the Proxy

When the Distributor sends to the Proxy a CoAP response over TCP as the inner chunk to distribute during an epoch (see Section 4.3), the Distributor also provides the Proxy with a Checksum Key, i.e., the one to use during that epoch for computing the checksums on the outer chunks of that inner chunk.¶

The Distributor derives the Checksum Key as defined in Section 5.2 and includes it in the response sent to the Proxy, as a CBOR data item prepended to the OSCORE ciphertext that is conveyed by the CoAP payload of the response. In order to indicate the presence of such CBOR data item, the response MUST include the Pre-OSCORE Data option Section 5.5, whose value is set as defined below.¶

There are two possible ways for the Distributor to provide the Checksum Key in the response to the Proxy as a prepended CBOR data item:¶

• The CBOR data item is a CBOR byte string, whose value is the Checksum Key. In such a case, the value of the Pre-OSCORE Data option MUST be set to 1.¶

  This alternative SHOULD be used by the Distributor, if the response to the Proxy is protected by means of a mutually authenticated, secure communication association between the Distributor and the Proxy, in such a way that only the Proxy is able to retrieve the protected content in plain.¶

• The CBOR data item is a COSE object [RFC9052], which can be tagged or untagged. In such a case, the value of the Pre-OSCORE Data option MUST be set to 2.¶

  The COSE Object is the result of using HPKE [RFC9180] with COSE. In particular, the HPKE Direct Encryption Mode specified in Section 3.1.1 of [I-D.ietf-cose-hpke] MUST be used. The input pt for the HPKE Seal operation is the Checksum Key. The resulting COSE object uses a COSE_Encrypt0 structure [RFC9052].¶

  In order to ensure source authentication of the prepended CBOR data item, the Distributor can additionally rely on a COSE object that uses a COSE_Sign, COSE_Sign1, COSE_MAC, or COSE_MAC0 structure [RFC9052]. In such a case, the COSE_Encrypt0 object is used as payload of the COSE_Sign, COSE_Sign1, COSE_MAC, or COSE_MAC0 structure.¶

  This alternative MUST be used by the Distributor, unless the response to the Proxy is protected by means of a mutually authenticated, secure communication association between the Distributor and the Proxy, in such a way that only the Proxy is able to retrieve the protected content in plain.¶

  This alternative requires the Distributor to know:¶

  • The COSE-HPKE algorithm to use with the Proxy (see Section 4 of [I-D.ietf-cose-hpke]).¶

  • The static public key of the Proxy to use as the input pkR of the HPKE Seal operation (see Section 3.1.1 of [I-D.ietf-cose-hpke]).¶

  Editor's note: describe examples of how the Distributor can obtain the static public key of the Proxy and possibly select the right one to use at runtime.¶

Secure communication associations between the Distributor and the Proxy can rely, for example, on a TLS [RFC8446] channel where the Distributor has been authenticated during the secure channel establishment, or on a pairwise OSCORE [RFC8613] Security Context shared between the Distributor and the Proxy, as defined in [I-D.ietf-core-oscore-capable-proxies].¶

8.1. CoAP Option Numbers Registry

IANA is asked to enter the following option numbers to the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

8.2. Informative Response Parameters Registry

IANA is asked to enter the following entry to the "Informative Response Parameters" registry defined in [I-D.ietf-core-observe-multicast-notifications] within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

• Name: progress_indicator¶

• CBOR Key: TBD23¶

• CBOR Type: uint¶

• Reference: [RFC-XXXX]¶

8.3. Pre-OSCORE Data Semantics Registry

This document establishes the "Pre-OSCORE Data Semantics" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

The registration policy is either "Private Use", "RFC Required With Expert Review", or "Specification Required" per [RFC8126]. "Expert Review" guidelines are provided in Section 8.4.¶

All assignments according to "RFC Required With Expert Review" are made on an "RFC Required" basis per Section 4.7 of [RFC8126] with "Expert Review" additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of "standards track code points" defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, working group chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].¶

The columns of this registry are:¶

• Value: This value identifies the semantics of the data prepended to the ciphertext conveyed in the CoAP payload of a message protected with OSCORE [RFC8613] or Group OSCORE [I-D.ietf-core-oscore-groupcomm]. These values MUST be unique. The value MUST be an odd unsigned integer, with minimum value 1 and maximum value 4294967293 (i.e., 2³²-3). Odd unsigned integer values from 1 to 255 are designated as "RFC Required With Expert Review". Odd unsigned integer values from 257 to 4294965293 are designated as "Specification Required". Odd unsigned integer values from 4294965295 to 4294967293 are marked as "Private Use".¶

• Description: This field contains a brief description of the semantics.¶

• Reference: This field contains a pointer to the public specification defining the error, if one exists.¶

This registry has been initially populated by the values in Section 6.¶

Note that, although even values from 2 to 4294967294 cannot not registered, they are meaningful and usable semantics identifiers. That is, the even value X identifies the same semantics identified by its companion odd value (X-1).¶

8.4. Expert Review Instructions

"RFC Required With Expert Review" and "Specification Required" are two of the registration policies defined for the IANA registry established in this document. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude.¶

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.¶

• Specifications are required for the "RFC Required With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.¶

• Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for RFC documents does not mean that an RFC document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.¶

9.1. Normative References

[COSE.Algorithms]

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

[I-D.amsuess-core-cachable-oscore]

Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in Progress, Internet-Draft, draft-amsuess-core-cachable-oscore-11, 6 July 2025, <https://datatracker.ietf.org/doc/html/draft-amsuess-core-cachable-oscore-11>.

[I-D.ietf-core-groupcomm-bis]

Dijk, E. and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-14, 2 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-14>.

[I-D.ietf-core-href]

Bormann, C. and H. Birkholz, "Constrained Resource Identifiers", Work in Progress, Internet-Draft, draft-ietf-core-href-22, 20 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-href-22>.

[I-D.ietf-core-observe-multicast-notifications]

Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini, "Observe Notifications as CoAP Multicast Responses", Work in Progress, Internet-Draft, draft-ietf-core-observe-multicast-notifications-11, 3 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-observe-multicast-notifications-11>.

[I-D.ietf-core-oscore-groupcomm]

Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and R. Höglund, "Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-groupcomm-26, 5 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-26>.

[I-D.ietf-cose-hpke]

Tschofenig, H., Steele, O., Daisuke, A., and L. Lundblade, "Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)", Work in Progress, Internet-Draft, draft-ietf-cose-hpke-13, 4 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-13>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[RFC7120]

Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/rfc/rfc7120>.

[RFC7252]

Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.

[RFC7641]

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

[RFC7959]

Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/rfc/rfc7959>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8323]

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

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8613]

Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/rfc/rfc8613>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9180]

Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

9.2. Informative References

[I-D.ietf-ace-key-groupcomm-oscore]

Tiloca, M. and F. Palombini, "Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-17, 11 April 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-17>.

[I-D.ietf-core-oscore-capable-proxies]

Tiloca, M. and R. Höglund, "OSCORE-capable Proxies", Work in Progress, Internet-Draft, draft-ietf-core-oscore-capable-proxies-04, 3 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-capable-proxies-04>.

[I-D.ietf-suit-manifest]

Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and O. Rønningstad, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Work in Progress, Internet-Draft, draft-ietf-suit-manifest-34, 28 May 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-34>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC9019]

Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Firmware Update Architecture for Internet of Things", RFC 9019, DOI 10.17487/RFC9019, April 2021, <https://www.rfc-editor.org/rfc/rfc9019>.

[RFC9124]

Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices", RFC 9124, DOI 10.17487/RFC9124, January 2022, <https://www.rfc-editor.org/rfc/rfc9124>.

[RFC9200]

Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, <https://www.rfc-editor.org/rfc/rfc9200>.

[RFC9528]

Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, <https://www.rfc-editor.org/rfc/rfc9528>.