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

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

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

Thing-to-Thing Research Group Internet-Draft This document defines a method for efficiently distributing a software update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP), Block-wise transfers for CoAP, and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The method defined in this document is compatible with (but not dependent on) the architecture for software and firmware update developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF. Discussion Venues Discussion of this document takes place on the Thing-to-Thing Research Group mailing list (t2trg@irtf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Throughout the operational phase of their lifecycle, it is vital that devices can effectively receive and install required software (SW) updates. This is important not only in order to add and extend features or to improve performance, but also and especially in order to address and prevent security vulnerabilities. In turn, the distribution of SW updates in itself has to be a secure and efficient process that scales well with the size of the software update and with the number of target devices. This document defines a method for efficiently distributing a SW update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP) , Block-wise transfers for CoAP , and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) . The defined method leverages a CoAP-to-CoAP proxy deployed between the CoAP target devices to update and a CoAP server acting as Distributor of the SW update. The proxy communicates with the Distributor using CoAP over TCP and retrieves the next-in-line "inner chunk" of the SW update from the Distributor, by using Block-wise Extension for Reliable Transport (BERT) . A CoAP response originated by the Distributor and conveying an inner chunk is protected end-to-end between the Distributor and the target devices, by using Group OSCORE. When a target device contacts the proxy for obtaining the latest SW update, the proxy relies on the use of Group OSCORE defined in . That is, it retrieves the next-in-line inner chunk from the Distributor if not already available in its cache and then caches the response that conveys the inner chunk. After that, building on concepts from , the proxy replies to the target device with an error response, informing about the time when it is going to distribute the inner chunk and providing transport-specific information for receiving that inner chunk. When that time comes, the proxy transmits the inner chunk to all the target devices by further splitting it into smaller "outer chunks", each of which is conveyed by a CoAP response over UDP and IP multicast using Block-wise transfer . At the end of such transfer, the target devices are allowed to selectively request outer chunks that they have missed for the current inner chunk. After the proxy declares the transfer of the current inner chunk completed, the process is repeated for the next inner chunk, which the proxy retrieves from the Distributor and transmits to the target devices as above. Eventually, the proxy completes the transfer of the last inner chunk. After that, as a new request comes from a target device to retrieve the latest SW update, the proxy restarts the process by retrieving the first inner chunk and providing it to the target devices. This document also defines how to counteract an attack against availability that an active adversary could easily perform by manipulating the CoAP responses sent by the proxy to the target devices and conveying the small outer chunks. The attack is neutralized by having a short checksum value computed by the proxy and included in such responses. By recomputing and verifying the checksum, target devices can thus promptly detect a possible manipulation of an outer chunk and discard the response conveying it as invalid. The method defined in this document is compatible with (but not dependent on) the architecture for SW and firmware update specified in and developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF.

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 the terms and concepts related to:

CoAP , also used for group communication and over TCP .
The CoAP extensions Observe and Block-wise .
The security protocols OSCORE and Group OSCORE , and the use of the latter to enable cacheability of protected CoAP responses .
The Concise Data Definition Language (CDDL) , Concise Binary Object Representation (CBOR) , and CBOR Object Signing and Encryption (COSE) .

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 .
Image resource: a resource hosted at the Distributor, with an image as its representation.

Building Blocks The distribution method defined in this document largely relies on a number of building blocks that are summarized in the following subsections.

CoAP CoAP is a web-transfer protocol specified in . 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 it can also be used over reliable transports such as TCP and WebSockets . 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 . CoAP also natively supports group communication . 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.

CoAP Observe Observe is an extension for CoAP specified in . 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.

CoAP Block-wise Transfer Block-wise is an extension for CoAP specified in . 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, also specifies Block-wise Extension for Reliable Transport (BERT), which 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.

OSCORE Object Security for Constrained RESTful Environments (OSCORE) is a security protocol specified in . 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 for data encoding and COSE 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 when Observe 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 keeping the proxies 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) .

Group OSCORE Group OSCORE is a security protocol specified in . By building on OSCORE and extending its construct, Group OSCORE protects CoAP messages end-to-end between endpoints that use CoAP in a group communication setup . Also by relying on CBOR and COSE , 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 ), the message is first encrypted with keying material that every group member can derive, and then it 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 that are sent to the whole group, i.e., that are intended to all CoAP servers in the group.
When using the pairwise mode (see ), 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 that is 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 , where the join process is based on the ACE framework for authentication and authorization in constrained environments .

Observe multicast notifications According to the original use of CoAP Observe , 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 . 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 . 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.

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 or Group OSCORE , 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. The same holds also when considering the same client that wishes to send the same plain CoAP request at different points in time. In order to overcome this limitation, the approach defined in 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 the 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 that are known in advance.

Architecture This section describes the architecture considered in the rest of this document when defining the method for distributing SW updates.

Architecture Overview | ^ | | | | | | | | | | | | | | | | | +---|-------|-----------+ |<------------------ (b) -->| | | | | | | | | | | | | Manifest | | | ... | | | | +------------+ | | | | | | | | * Size | | | |<--------- (b) -->| | | | | * Location | | | | | | | | | * ... | | | | | | | | +------------+ | | | | | | | | |<---------------o-- (c) ---+ | | | Image | | | | | | | +-------------------+ | | | ... | | | | | 0x01ab... | | | | | | | | +-------------------+ | | |<------+ | | | | | | | | +-----------------------+ | | | ^ ............................................... | : | | | : | :.............................................: | End-to-end security with Group OSCORE | | (a) CoAP over TCP, using BERT to transfer O large inner chunks of the image .+. / | \ (b) CoAP over UDP + / \ (c) CoAP over UDP and IP multicast, using Block-wise to transfer small outer chunks of the image Author ]]> As shown in , the architecture consists of the following actors:

The Author is responsible for building and issuing the new version of the image, together with the corresponding manifest. The manifest MUST be signed by the author and MUST include at least the following information:
- The total size of the image.
- A location URI, i.e., the URI of the image resource at the Distributor from where it is possible to retrieve the image.
- The Author's digital signature computed over (a digest of) the image.
A possible manifest format that can be used is specified in , with its corresponding CBOR-based serialization format specified in .
The Distributor acts as a CoAP server, hosts the manifest and the image issued by the Author, and distributes those to the target Devices via the Proxy, as described in . At the Distributor, the following applies separately for each SW component X that can be updated.
- The Distributor hosts one observable manifest resource. At any point in time, the representation of the manifest resource is the latest manifest issued for X.
- For each different image released for X, the Distributor hosts one different image resource, whose representation is that image of X. More generally, the Distributor stores any two released images of any SW component as representations of two different image resources, hence identified by different URIs. For example, the URIs can differ as to their path components or query components. With reference to the manifest available as current representation of the manifest resource for X, the location URI specified within that manifest identifies the image resource whose representation is the image of X that has been released latest and is associated with that manifest. For simplicity of presentation, refers to a Distributor that is responsible for a single SW component, whose latest manifest is stored as the representation of the manifest resource at /manifest. Within that manifest, the location URI for the image associated with the manifest identifies the resource at /image/foo, whose representation is the latest released image in question. The criteria for retaining and eventually deleting image resources for old images are to be defined by application policies.
The Proxy is responsible for retrieving the manifest and the image from the Distributor and for practically sending those to the target Devices, as described in . The Proxy communicates with the Distributor using CoAP over TCP . In particular, the Proxy retrieves the image from the Distributor by using BERT . Each of such BERT responses from the Distributor includes exactly one block and conveys an "inner chunk" of the image. The Proxy communicates with the target Devices using CoAP over UDP. Specifically when providing the Devices with the image, the Proxy sends CoAP responses over UDP and IP multicast, as described in . Each of such responses uses Block-wise transfer for CoAP and conveys an "outer chunk" of the currently transferred inner chunk of the image.
The Devices obtain SW updates of interest from the Distributor, by directly interacting with the Proxy, as described in . At a high-level, a Device first learns about the availability of a new image for a SW component of interest, by receiving the corresponding manifest in an Observe notification response pertaining to the manifest resource at the Distributor. After that, each interested Device independently enrolls in a distribution process driven by the Proxy. During that process, the Device receives the image as a set of inner chunks that the Distributor provides to the Proxy. In particular, the Proxy provides the Devices with the inner chunks by further splitting each of those into smaller outer chunks, which constitute the actual unit of distribution. Each outer chunk is conveyed by a Block-wise response sent by the Proxy to all the enrolled target Devices over UDP and IP multicast. Once received all the inner chunks, the Devices rebuild the actual image and perform further checks against the corresponding manifest before consuming the image.

Secure communication is ensured end-to-end between the Distributor and the Devices. To this end, the Distributor and the Devices have to be members of the same OSCORE group, and therefore able to protect their exchanged messages using the security protocol Group OSCORE . In particular, the following applies:

Every response originated by the Distributor is protected by using the group mode of Group OSCORE (see ).
Every request originated by the Devices and targeting a resource at the Distributor are Deterministic Requests protected with Group OSCORE, according to the construct defined in .

The process of joining the OSCORE group is driven by a responsible Group Manager. For example, it can rely on the realization of Group Manager specified in , where the join process is based on the ACE framework for authentication and authorization in constrained environments . The method defined in this document is agnostic of such a join process and related provisioning of keying material for Group OSCORE. At the same time, it does benefit from the Group Manager entity taking care of the provisioning of keying material. In particular, the Distributor does not need to know the exact Devices that are members of the OSCORE group, or any keying material or authentication credential related to those. This allows the Distributor to seamlessly distribute SW updates over time, without needing to be aware of possible membership changes within the OSCORE group. As ultimately in charge with the membership of the OSCORE Group, the responsible Group Manager has to appropriately admit/refuse new members and evict current members as needed, thus ensuring that only Devices that are supposed to obtain a SW update can effectively do so.

Distribution Process This section describes the distribution process in detail, building on the architecture presented in . After an overview of its design goals in , the process is presented as composed of two main parts. The first part is described in and concerns the advertisement of a newly available SW update, by providing target Devices with the corresponding manifest through Observe notification responses. The second part is described in and concerns the actual distribution of the image to the target Devices. This is based on the Distributor providing large inner chunks of the image to the Proxy, which further splits each of those into smaller outer chunks that are sent to the target Devices. For simplicity of presentation, but with no loss of generality, the following considers a Distributor as responsible for a single SW component and only two Devices as target of updates for that SW component.

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 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 .
- Cacheable protected responses that are cached at the Proxy as per the construct defined in , 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 , 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 .
- 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 .
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.

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.

The Device composes an observation request targeting the manifest resource at the Distributor.
The Device protects the observation request from Step 1 with Group OSCORE, specifically using the construct defined in and therefore producing a Deterministic Request.
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.
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 , 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 use as a possible optimization the approach defined in , whose use in network setups that leverage proxies is described in . 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. shows an example of message exchange where the two Devices obtain the latest manifest from the Distributor through the Proxy.

Example of Notification of SW Update +--------------------->| | | | | | | | Protected Resp. | | | | 2.05 | | | | Token: 0xabcd | | | | Observe: 42 | | | | [Enc: { Manifest }] | | | |<---------------------+ | | | | | | Response | | | stored in | | | the cache | | | | | | Protected Resp. | | | | 2.05 | | | | Token: 0xaabb | | | | Observe: 42 | | | | [Enc: { Manifest }] | | | |<--------------------------------------------+ | | | | | | | | | | | Protected Det. Req. | | | | FETCH | | | | Token: 0xccdd | | | | Observe: 0 | | | | [Enc: GET /manifest] | | | +--------------------->| | | | | | | | Response | | | found in | | | the cache | | | | | | | Protected Resp. | | | | 2.05 | | | | Token: 0xccdd | | | | Observe: 42 | | | | [Enc: { Manifest }] | | | |<---------------------+ | | | | | ]]>

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

Overview of a Transfer Epoch and its Phases The following describes in detail the operations performed by a Device and by the Proxy during the transfer of an image.

Device Operations Following the reception of a manifest as described in , a Device can ask the Proxy to distribute the next inner chunk of the image. To this end, the Device sends to the Proxy a protected Deterministic Request as defined in . The Deterministic Request is computed by using the Group OSCORE Security Context shared between the Device and the Distributor. The original unprotected CoAP request is such that:

The request method is GET.
The target is the image resource at the Distributor.

Once produced the protected Deterministic Request, the Device includes the Block2 Option as an outer option intended for the Proxy. Its value specifies NUM = 0, M = 0, and SZX = 2 (i.e., a block size of 64 bytes). When sending such a request, the Device might not know what the current phase of the current epoch is at the Proxy, or what inner chunk is meant to be transferred in the current epoch. As defined in , the Proxy guides the Devices about the next actions to take, by providing information on the current status of the image transfer. From a high-level point of view, the following applies to each epoch:

A Device can enroll in the reception of the inner chunk for the current epoch, by sending its Deterministic Request during the "Admission" phase. Consequently, the Device obtains instructions for receiving that inner chunk, which the Proxy distributes as split into corresponding outer chunks during the immediately following "Full Transfer" phase.
A Device can ask the Proxy to re-send an outer chunk that was not correctly received (e.g., it was lost in transmission or got corrupted), by sending the Deterministic Request during the "Recovery Claim" phase and indicating the required outer chunk by means of the NUM field of the outer Block2 Option. Consequently, the Device obtains instructions for receiving the re-sent outer chunk, which the Proxy distributes during the immediately following "Recovery Transfer" phase.
If a Device has not enrolled during the "Admission" phase but attempts to enroll on-the-fly later on during the epoch, that Device will be instructed to enroll again at the next epoch.

A Device completes the retrieval of an inner chunk once it has received all the corresponding outer chunks from the Proxy, rebuilt the inner chunk from those, and successfully verified and decrypted the rebuilt CoAP response protected with Group OSCORE and conveying the inner chunk. A Device completes the retrieval of the whole image once it has received all the corresponding inner chunks from the Proxy. The Device is able to simply verify whether that holds, by checking the cumulated size of the obtained inner chunks against the total size of the image that is specified within the manifest. If needed, the Device is also able to correctly reorder the obtained inner chunks. To this end, the Device relies on the indication provided during each epoch by the Proxy through the "progress_indicator" parameter, which is included in responses sent by the Proxy during the "Admission" and "Recovery Claim" phases. As detailed in , the parameter indicates the index of the inner chunk transferred in the current epoch.

Proxy Operations The following describes the operations performed by the Proxy.

Kick-Off If the Proxy receives a Deterministic Request that targets the Distributor, includes an outer Block2 Option with value (NUM = 0, M = 0, SZX = 2), and does not produce a cache hit for a cache entry associated with an epoch, then the Proxy performs the following steps. For the considered Deterministic Requests, this occurs only if the Proxy has not distributed any inner chunk of the image yet, i.e., it has not retrieved any inner chunk of the image from the Distributor.

In the Deterministic Request, replace the value of the Block2 Option so that NUM = 0, M = 0, and SZX = 7 (i.e., BERT is used).
Forward the Deterministic Request to the Distributor over TCP.
Once received a corresponding successful 2.05 (Content) response from the Distributor, create a cache entry ENTRY and store the response in ENTRY as the inner chunk to transfer in the first epoch. Note that the value of the Block2 Option in the response specifies NUM = 0 and SZX = 7 (i.e., BERT is used). Before storing the response in ENTRY, the Proxy MUST remove from the response the Pre-OSCORE-Data Option and the associated CBOR data item prepended to the OSCORE ciphertext in the CoAP payload, which were added by the Distributor (see ).
Start an epoch with "Admission" as its current phase and associate it with ENTRY.
Initialize an unsigned integer INNER_INDEX to 0 and associate it with ENTRY.
Determine the time t_A when the immediately following "Full Transfer" phase will start. Start a timer with expiration set at t_A.
The Proxy performs Step 2 in , thus enrolling the Device that has sent the Deterministic Request in the upcoming transfer scheduled for the immediately following "Full Transfer" phase.

"Admission" Phase If the Proxy receives a Deterministic Request that targets the Distributor and produces a cache hit for the cache entry ENTRY associated with an epoch with current phase "Admission", then the Proxy performs the following steps.

Determine whether ENTRY is storing the inner chunk to transfer in the current epoch, i.e., whether the value of the Block2 Option in the cached response within ENTRY specifies NUM = INNER_INDEX. In such case, move to Step 2. Otherwise, perform the following steps.
- In the Deterministic Request, replace the value of the Block2 Option so that NUM = INNER_INDEX, M = 0, and SZX = 7 (i.e., BERT is used).
- Forward the Deterministic Request to the Distributor over TCP.
- Once received a corresponding successful 2.05 (Content) response from the Distributor, store the response in ENTRY as the inner chunk to transfer in the current epoch, by overwriting the current content of ENTRY. Note that the value of the Block2 Option in the response specifies NUM = INNER_INDEX and SZX = 7 (i.e., BERT is used). Before storing the response in ENTRY, the Proxy MUST remove from the response the Pre-OSCORE-Data Option and the associated CBOR data item prepended to the OSCORE ciphertext in the CoAP payload, which were added by the Distributor (see ).
- Determine the time t_A when the immediately following "Full Transfer" phase will start. Start a timer with expiration set at t_A.
- Move to Step 2.
Reply by sending a "Hold-on Response", i.e., a 5.03 (Service Unavailable) error response. This is specifically an informative response defined in , with Content-Format set to "application/informative-response+cbor" (see ). The payload of this informative response is a CBOR map that MUST include the following parameters.
- "tp_info", which is defined in . This parameter specifies the transport-specific information required to correctly receive CoAP responses over UDP and IP multicast, during the immediately following "Full Transfer" phase in the current epoch. Each of those responses will convey one outer chunk of the inner chunk distributed in the current epoch. Per , the "tp_info" parameter specifies addressing information as Constrained Resource Identifiers (CRIs) . Consistent with , the Token value to be used in the current epoch for the multicast responses is specified by the "tpi_token" parameter, within the "tpi_details" element of "tp_info". The Token value is selected by the Proxy, as an available value from a Token space under exclusive control of the Proxy and corresponding to a CoAP endpoint used for messages that have:
  - As source address and port number, the IP multicast address and port number where the Proxy sends the multicast responses in the current epoch.
  - As destination address and port number, the Proxy address and port number from where the Proxy sends the multicast responses in the current epoch, i.e., from where the Proxy sends the present error response.
  Within a given Token space, the Token value used in an epoch MUST NOT be reused in any other epoch of the current transfer of the image or before the two following transfers of the same image have been completed.
- "next_not_before", which is defined in . This parameter specifies the amount of seconds that will minimally elapse before the "Full Transfer" phase of the current epoch starts. Such a value MUST NOT result in indicating that the "Full Transfer" phase starts before t_A.
- "progress_indicator", with value a numeric indication of progress, encoded as a CBOR unsigned integer. This parameter is defined in this document and registered in . This parameter enables clients to unambiguously interpret, reorder, and process the content that will be sent per the information specified in the "tp_info" parameter, e.g., if that content is split into parts identifiable by an index value. When used in this document, the "progress_indicator" parameter MUST encode the current value of INNER_INDEX, thereby identifying the inner chunk that is transferred in the current epoch.
A Device receiving the "Hold-on Response" can set itself up for receiving the inner chunk during the immediately following "Full Transfer" phase of the current epoch. In particular, the Device becomes aware that the "Full Transfer" phase is scheduled to start not before the amount of seconds indicated by the "next_not_before" parameter, that the inner chunk to be transferred is the one with index INNER_INDEX indicated by the "progress_indicator" parameter, and that the responses conveying the corresponding outer chunks will be sent per the information specified in the "tp_info" parameter.

This phase finishes when the time t_A is reached and the related timer expires. After that, the epoch moves to the "Full Transfer" phase (see ).

"Full Transfer" Phase When this phase starts, the Proxy considers the response stored in the cache entry ENTRY associated with the current epoch. Such a response is the inner chunk to distribute in this phase, by using Block-wise transfer to further split the inner chunk into smaller outer chunks. In particular, the i-th outer chunk is a CoAP response such that:

It retains the same CoAP header of the inner chunk response, with the following exceptions:
- The Message ID has a new value determined by the Proxy;
- The message type MUST be Non-confirmable; and
- The Token Length and Token fields MUST specify the length and the value of the Token to use for the multicast responses to send in the current epoch, respectively. The Token value was specified within the "tp_info" parameter of the "Hold-on Response" that was sent during the "Admission" phase of the current epoch (see ).
It MUST include an outer Block2 Option, whose value specifies NUM = i (i.e., the index of the present outer chunk) and SZX = 2 (i.e., a block size of 64 bytes).
It MUST include the Checksum Option defined in , with value a checksum computed by the Proxy on the outer chunk, as defined in .

Before distributing the outer chunks, the Proxy determines the time t_C when the current epoch is expected to end. This takes into account the expected duration of the current "Full Transfer" phase and of the immediately following "Recovery Claim" and "Recovery Transfer" phases. Then, the Proxy sequentially sends the outer chunks to the enrolled Devices, according to the indexes of the outer chunks sorted in ascending order. That is, the Proxy first sends the outer chunk with i = 0, then continues with the outer chunk with i = 1, and so on until all the outer chunks have been sent. In the last outer chunk, the value of the outer Block2 Option specifies M = 0. Each outer chunk is transmitted as a response over UDP and IP multicast, according to the addressing information specified within the "tp_info" parameter of the "Hold-on Response" that was sent during the "Admission" phase of the current epoch (see ). This phase finishes when the Proxy has sent all the outer chunks corresponding to the inner chunk of the current epoch. After that, the epoch moves to the "Recovery Claim" phase (see ). If the Proxy receives a Deterministic Request that targets the Distributor and produces a cache hit for the cache entry ENTRY associated with an epoch with current phase "Full Transfer", then the Proxy MUST reply with a 5.03 (Service Unavailable) error response that has no payload. The error response MUST include the Max-Age Option, with value the amount of seconds that will minimally elapse before the current epoch ends. The value of the Max-Age Option MUST NOT result in indicating that the current epoch ends before t_C.

"Recovery Claim" Phase When this phase starts, the Proxy creates a set of unsigned integers, namely RECOVERY_INDEXES, and initializes it as empty. Also, the Proxy determines the time t_B when the immediately following "Recovery Transfer" phase will start. This takes into account the expected duration of the current "Recovery Claim" phase and the already determined time t_C when the current epoch is expected to end. In particular, the time t_B MUST NOT be after the time t_C. Finally, the Proxy starts a timer with expiration set at t_B. If the Proxy receives a Deterministic Request that targets the Distributor and produces a cache hit for the cache entry ENTRY associated with an epoch with current phase "Recovery Claim", then the Proxy performs the following steps.

The Proxy considers the received Deterministic Request and in particular its outer Block2 Option. The value specified by the NUM field of the option value is added to RECOVERY_INDEXES if and only if it is not included there already.
The Proxy replies by sending a 5.03 (Service Unavailable) error response. This is specifically an informative response defined in , with Content-Format set to "application/informative-response+cbor" (see ). The payload of the error response is a CBOR map that MUST include the following parameters.
- "tp_info", which is defined in . This parameter provides the same information as in the "Hold-on Response" sent during the "Admission" phase of the current epoch (see Step 2 of ), with the difference that it includes only server-side information and it MUST NOT include client-side information. That is, the parameter still specifies server-side addressing information related to the Proxy as the sender of multicast responses. However, the parameter MUST NOT specify addressing information as to where the multicast responses are sent or the Token value used for those in the current epoch. Consequently, only Devices that participated in the immediately previous "Full Transfer" phase and missed some outer chunks will participate in the immediately following "Recovery Transfer" phase. Instead, other Devices will be pointed to the start of the next epoch, according to what is specified by the Max-Age Option of the error response (see below).
- "next_not_before", which is defined in . This parameter specifies the amount of seconds that will minimally elapse before the "Recovery Transfer" phase of the current epoch starts. Such a value MUST NOT result in indicating that the "Recovery Transfer" phase starts before t_B.
- "progress_indicator", with value a numeric indication of progress, encoded as a CBOR unsigned integer. This parameter is defined in this document and registered in . Like in the "Hold-on Response" sent during the "Admission" phase of the current epoch (see Step 2 of ), the "progress_indicator" parameter MUST encode the current value of INNER_INDEX, thereby identifying the inner chunk that is transferred in the current epoch.
Furthermore, the error response MUST include the Max-Age Option, with value the amount of seconds that will minimally elapse before the current epoch ends. The value of the Max-Age Option MUST NOT result in indicating that the current epoch ends before t_C. A Device receiving this error response gains knowledge of when the immediately following "Recovery Transfer" phase starts and when the next epoch starts. The former information is useful for a Device that participated in the immediately previous "Full Transfer" phase and missed some outer chunks. That Device can thus set itself up for receiving such outer chunks, which will be distributed during the immediately following "Recovery Transfer" phase. In particular, the Device becomes aware that the "Recovery Transfer" phase is scheduled to start not before the amount of seconds indicated by the "next_not_before" parameter and that the outer chunks to be transferred pertain to the inner chunk with index INNER_INDEX indicated by the "progress_indicator" parameter. Having participated in the immediately previous "Full Transfer" phase, the Device is aware that the responses representing the outer chunks will be sent per the information specified in the "tp_info" parameter of the "Hold-on Response" that the Device received during the "Admission" phase of the current epoch.

This phase finishes when the time t_B is reached and the related timer expires. After that, the epoch moves to the "Recovery Transfer" phase (see ).

"Recovery Transfer" Phase When this phase starts, the Proxy prepares a set of outer chunks, namely RECOVERY_CHUNKS. The set includes a selection of the outer chunks that were sent during the "Full Transfer" phase of the current epoch (see ). In particular, each of such outer chunks is added to RECOVERY_CHUNKS if and only if the value specified by the NUM field in the value of its outer Block2 Option is an element of the RECOVERY_INDEXES set. After that, the Proxy distributes only the outer chunks included in RECOVERY_CHUNKS, just like it distributed the outer chunks during the "Full Transfer" phase of the current epoch (see ). In particular, the outer chunks are sent according to their indexes sorted in ascending order. Their transmission occurs over UDP and IP multicast, according to the same information specified in the "tp_info" parameter of the "Hold-on Responses" that were sent during the "Admission" phase of the current epoch. The Proxy MUST NOT alter the time t_C that was determined during the "Full Transfer" phase, as the time when the current epoch is expected to end. After the Proxy has sent all the outer chunks that are an element of RECOVERY_CHUNKS, the Proxy deletes the RECOVERY_INDEXES and RECOVERY_CHUNKS sets, and the epoch moves to the final "Epilogue" (see ). If the Proxy receives a Deterministic Request that targets the Distributor and produces a cache hit for the cache entry ENTRY associated with an epoch with current phase "Recovery Transfer" or in its "Epilogue", then the Proxy MUST reply with a 5.03 (Service Unavailable) error response that has no payload. The error response MUST include the Max-Age Option, with value the amount of seconds that will minimally elapse before the current epoch ends. The value of the Max-Age Option MUST NOT result in indicating that the current epoch ends before t_C.

Epilogue To conclude the current epoch, the Proxy performs the following steps.

The Proxy considers the response stored in the cache entry ENTRY associated with the current epoch, and particularly the field M in the value of the Block2 Option.
The Proxy updates the value of INNER_INDEX associated with ENTRY as follows:
- If M is 1, then INNER_INDEX is incremented by 1.
- If M is 0, then INNER_INDEX takes 0 as its new value.
When the time t_C is reached, the Proxy concludes the current epoch, starts a new epoch with "Admission" as its current phase, deletes the association between the old epoch end ENTRY, and associates the new epoch with ENTRY.

Checksum on Outer Chunks This section defines how the Proxy computes a checksum value over each outer chunk that it sends to the target Devices during the "Full Transfer" phase (see ) and the "Recovery Transfer" phase (see ). As described in , the computed checksum value is specified as the value of the Checksum Option defined in , which the Proxy includes in the response sent as outer chunk to the Devices. Upon receiving an outer chunk, a Device recomputes the checksum and compares it against the value conveyed in the Checksum Option, in order to check whether the outer chunk was altered in transit. The checksum value of an outer chunk is computed by using a checksum key, whose derivation is defined in . The same checksum key is used to compute the checksum values for all the outer chunks of the same inner chunk, i.e., during a whole epoch (see ). While a checksum key is used by the Proxy and the Devices, the checksum key is derived by the Distributor and the Devices, by using keying material in their shared Group OSCORE Security Context. The Distributor provides the Proxy with the checksum key to use during the current epoch (see ), when sending to the Proxy a CoAP response over TCP as the inner chunk to distribute in that epoch (see and ). In particular, the Distributor wraps the checksum key in a CBOR data item and prepends that data item to the OSCORE ciphertext in the CoAP payload of the response sent to the Proxy. The Distributor indicates the presence of the prepended CBOR data item by including in the response the Pre-OSCORE-Data Option defined in . The use of checksums counteracts an attack against availability that an active adversary could easily perform by manipulating the CoAP responses sent by the Proxy to the Devices as outer chunks. By recomputing a checksum and verifying it against the one included in the response received from the Proxy, target Devices can promptly detect a possible manipulation of the outer chunk and discard the response as invalid.

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 symmetric key. This is used for deriving checksum keys that are in turn used for computing checksums of outer chunks (see ). The Root Checksum Key is derived as defined for the Sender/Recipient Keys in , 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 ) encoded as a CBOR integer or text string, consistent with the "Value" field in the entry of the "COSE Algorithms" Registry for that algorithm .
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.

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 and ). Note that the Distributor provides the Proxy with the checksum key K as embedded in that response (see ).
By each target Device, when receiving an outer chunk of the inner chunk distributed in the current epoch (see and ).

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 ), which consists of composing the HKDF-Extract and HKDF-Expand steps . 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 outer Block2 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 ) and the "Recovery Claim" phase (see ).
IKM is the Root Checksum Key from the Common Context (see ).
info is the serialization of a CBOR array with the structure defined below, following the notation of ):

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 ).
- From the Device point of view, the responses received from the Proxy during the "Full Transfer" phase (see ) and "Recovery Transfer" phase (see ) 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.

Checksum Option The CoAP Checksum Option defined in this section has the properties summarized in , which extends Table 4 of . The option is Elective, Safe-to-Forward, and part of the Cache-Key. The option MUST NOT occur more than once. Checksum Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

No.	C	U	N	R	Name	Format	Length	Default
TBD256					Checksum	opaque	1-8	(none)

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 .

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 ) and "Recovery Transfer" phase (see ). After having computed the checksum as defined below, the Proxy specifies it as value of the Checksum Option (see ) 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 ). A Device computes the checksum on an outer chunk upon receiving that outer chunk from the Proxy, during the "Full Transfer" phase (see ) and "Recovery Transfer" phase (see ). 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 ), 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 . 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 ). 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 ) and the "Recovery Claim" phase (see ).
IKM is the Checksum Key to use for this inner chunk, which is derived as defined in .
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.

Pre-OSCORE-Data Option The CoAP Pre-OSCORE-Data Option defined in this section has the properties summarized in , which extends Table 4 of . The option is Critical, Safe-to-Forward, part of the Cache-Key, and repeatable. Pre-OSCORE-Data Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

No.	C	U	N	R	Name	Format	Length	Default
TBD257	x			x	Pre-OSCORE-Data	uint	1-4	(none)

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 strictly greater than 0, which 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 an odd value taken from the 'Value' column of the "Pre-OSCORE Data Semantics" IANA registry defined in . Both values 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 . The data with the indicated semantics consists of what is available at the recipient once successfully completed all the COSE processing, e.g., the data is a plaintext recovered after a decryption process.

Note that, although even values cannot be registered in the "Pre-OSCORE Data Semantics" IANA registry (see ), those values are meaningful semantics identifiers that can be used as option value. That is, the even value Y identifies the same semantics identified by its companion odd value X = (Y - 1). 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 .

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 ), 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 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. That is, the CBOR data item is prepended to the OSCORE ciphertext that results from protecting the response end-to-end between the Distributor and the Devices by using Group OSCORE. In order to indicate the presence of such CBOR data item, the response MUST include the Pre-OSCORE Data Option (see ), 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 , 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 with COSE. In particular, the HPKE Integrated Encryption Mode specified in MUST be used. The input pt for the HPKE Seal Single-Shot operation is the Checksum Key. The resulting COSE object uses a COSE_Encrypt0 structure . 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 . 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 ).
- The static public key of the Proxy to use as the input pkR of the HPKE Seal Single-Shot operation (see ).
describes possible approaches for the Distributor to obtain the static public key of the Proxy and to select the right one to use at runtime.

Secure communication associations between the Distributor and the Proxy can rely, for example, on a TLS channel where the Distributor has been authenticated during the secure channel establishment, or on a pairwise OSCORE Security Context shared between the Distributor and the Proxy (see ).

Obtaining and Selecting the Proxy's Public Key This section describes possible approaches that the Distributor can use to obtain the static public key of the Proxy and to select the right one to use at runtime. As discussed above, this is relevant in the case where the Distributor uses a COSE object as the value of the Pre-OSCORE Data Option, when providing the Proxy with a Checksum Key within a CoAP response as the inner chunk to distribute during an epoch. The following considers a Proxy that uses P_ADDR as source IP address when sending to the Distributor a request over TCP for retrieving the next inner chunk to distribute during an epoch. Also, AUTH_CRED_P denotes the Proxy's public authentication credential, which includes the Proxy's static public key K_PUB_P corresponding to the Proxy's static private key K_PRIV_P.

The Distributor can be pre-configured with the pair (P_ADDR, AUTH_CRED_P).
When receiving a request for an inner chunk from the Proxy, the Distributor can query a trusted public key repository, using the source IP address of the incoming request as lookup information. As a result, the Distributor retrieves AUTH_CRED_P.
When receiving a request for an inner chunk from the Proxy, the Distributor can contact the Proxy at P_ADDR, by accessing a (well-known) designated resource for retrieving K_PUB_P from the Proxy. This approach requires the Proxy to prove possession of its static private key and has two variants, depending on whether the Key Encapsulation Mechanism (KEM) used for HPKE is based on a Diffie-Hellman/Non-Interactive Key Exchange (DH/NIKE) or not. The two variants are separately defined in and .

Regardless of how the Distributor has obtained the Proxy's public key, the following holds:

The Distributor can select the right public key to use for producing the COSE object conveying the Checksum Key, based on the source IP address of an incoming request that asks for an inner chunk.
If AUTH_CRED_P specifies a domain name (e.g., it is a public key certificate) and that domain name resolves to an address ADDR, then the Distributor uses K_PUB_P only if ADDR is equal to P_ADDR.
If an active adversary makes the Distributor erroneously consider a public key different from the intended K_PUB_P, the Proxy will not be able to obtain the Checksum Key from the Distributor. Although this prevents the successful distribution of outer chunks to the Devices, it is easier for the adversary to create such a disservice by simply blocking messages exchanged between the Distributor and the Proxy.
By spoofing the source IP address of a request that the Proxy sends to the Distributor, an active adversary could manage to obtain the Checksum Key from the Distributor and then act like the Proxy towards the Devices. This enables the adversary to compute the correct checksum values and specify those in the outer chunks, which is in fact not really an attack against the distribution of the outer chunks to the Devices.

Retrieval from the Proxy (variant 1) If the KEM used for HPKE is based on a DH/NIKE, the interaction between the Distributor and the Proxy is as follows.

The Distributor generates:
- A nonce N_1, whose value is RECOMMENDED to be random and whose length is RECOMMENDED to be at least 8 bytes.
- An ephemeral public key.
The Distributor sends to the Proxy a request message MSG_1, whose Content-Format is "application/cbor-seq". The payload of MSG_1 specifies a CBOR sequence composed of two CBOR byte strings: the first CBOR byte string encodes N_1; the second CBOR byte string encodes the ephemeral public key generated at Step 1.
After receiving MSG_1, the Proxy generates a nonce N_2, whose value is RECOMMENDED to be random and whose length is RECOMMENDED to be at least 8 bytes.
The Proxy composes as proof-of-possession (PoP) input the byte concatenation of:
- The binary representation of a CBOR byte string whose value is N_1; and
- The binary representation of a CBOR byte string whose value is N_2.
The Proxy computes a MAC as a PoP evidence by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps . MAC = HKDF(salt, IKM, info, L) The input parameters of HKDF are as follows:
- salt takes as value the empty byte string.
- IKM is a shared secret computed by using the Distributor's ephemeral public key conveyed in MSG_1 and K_PRIV_P. For example, if the KEM relies on Diffie-Hellman, IKM is computed as a cofactor Diffie-Hellman shared secret (see Section 5.7.1.2 of , using the ECDH algorithm associated with K_PRIV_P.
- info takes as value the PoP input.
- L is equal to 8, i.e., the size of the MAC, in bytes.
The Proxy replies to the Distributor by sending a response message MSG_2, whose Content-Format is "application/cbor-seq". The payload of MSG_2 specifies a CBOR sequence composed of three CBOR byte strings: the first CBOR byte string encodes N_2; the second CBOR byte string encodes AUTH_CRED_P; the third CBOR byte string encodes the MAC computed at Step 5.
After receiving MSG_2, the Distributor derives the same shared secret by using K_PUB_P specified within AUTH_CRED_P and its own ephemeral private key corresponding to the ephemeral public generated at Step 1.
The Distributor computes a MAC as a PoP evidence, by means of the same process used by the Proxy at Step 5, using as IKM the shared secret computed at Step 7.
The Distributor achieves proof of possession and accepts K_PUB_P only if the MAC computed at Step 8 is equal to the one conveyed in MSG_2.

Retrieval from the Proxy (variant 2) If the KEM used for HPKE is not based on a DH/NIKE (e.g., the KEM used is ML-KEM ), the interaction between the Distributor and the Proxy is as follows.

The Distributor generates a nonce N_1, whose value is RECOMMENDED to be random and whose length is RECOMMENDED to be at least 8 bytes.
The Distributor sends to the Proxy a request message MSG_1, whose payload specifies N_1.
After receiving MSG_1, the Proxy generates a nonce N_2, whose value is RECOMMENDED to be random and whose length is RECOMMENDED to be at least 8 bytes. The Proxy stores the pair (N_1, N_2).
The Proxy replies to the Distributor by sending a response message MSG_2, whose Content-Format is "application/cbor-seq". The payload of MSG_2 specifies a CBOR sequence composed of two CBOR byte strings: the first CBOR byte string encodes N_2; the second CBOR byte string encodes AUTH_CRED_P.
After receiving MSG_2, the Distributor generates a shared secret and encapsulates it into a ciphertext, by using K_PUB_P specified within AUTH_CRED_P.
The Distributor sends to the Proxy a request message MSG_3, whose Content-Format is "application/cbor-seq". The payload of MSG_3 specifies a CBOR sequence composed of two CBOR byte strings: the first CBOR byte string encodes N_2; the second CBOR byte string encodes the ciphertext computed at Step 5.
After receiving MSG_3, the Proxy uses N_2 conveyed therein to retrieve N_1 from the stored pair (N_1, N_2). Then, the Proxy decapsulates the shared secret from the ciphertext and composes as proof-of-possession (PoP) input the byte concatenation of:
- The binary representation of a CBOR byte string whose value is N_1; and
- The binary representation of a CBOR byte string whose value is N_2.
The Proxy computes a MAC as a PoP evidence by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps . MAC = HKDF(salt, IKM, info, L) The input parameters of HKDF are as follows:
- salt takes as value the empty byte string.
- IKM is the shared secret retrieved at Step 7.
- info takes as value the PoP input.
- L is equal to 8, i.e., the size of the MAC, in bytes.
The Proxy deletes the stored pair (N_1, N_2). Then, the proxy replies to the Distributor by sending a response message MSG_4, whose payload specifies the MAC computed at Step 8.
After receiving MSG_4, the Distributor computes a MAC as a PoP evidence, by means of the same process used by the Proxy at Step 8, using as IKM the shared secret generated at Step 5.
The Distributor achieves proof of possession and accepts K_PUB_P only if the MAC computed at Step 10 is equal to the one conveyed in MSG_4.

Pre-OSCORE Data Semantics This document defines the following semantics for data prepended to the ciphertext conveyed in the CoAP payload of a message protected with OSCORE or Group OSCORE . Pre-OSCORE Data Semantics.

Value	Description	Reference
1	Checksum key	[RFC-XXXX],

Security Considerations Security considerations are inherited from , , and as to the use of CoAP also for group communication and over reliable transports. Security considerations are also inherited from as to the use of CoAP Observe, from as to the use of Block-wise transfer for CoAP, and from as to the use of BERT. Security considerations are also inherited from for the use of Group OSCORE and from as to the specific use of protected Deterministic Requests and the caching of corresponding protected responses. Furthermore, the following security considerations also apply. Editor's note: add more security considerations.

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

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. Registrations in the CoAP Option Numbers Registry

Number	Name	Reference
TBD256	Checksum	[RFC-XXXX]
TBD257	Pre-OSCORE-Data	[RFC-XXXX]

Informative Response Parameters Registry IANA is asked to enter the following entry to the "Informative Response Parameters" registry defined in within the "Constrained RESTful Environments (CoRE) Parameters" registry group.

Name: progress_indicator
CBOR Key: TBD23
CBOR Type: uint
Reference: [RFC-XXXX]

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 . "Expert Review" guidelines are provided in . All assignments according to "RFC Required With Expert Review" are made on an "RFC Required" basis per with "Expert Review" additionally required per . The procedure for early IANA allocation of "standards track code points" defined in 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 . The columns of this registry are:

Value: This field contains the value used to identify the semantics of the data that is prepended to the ciphertext conveyed in the CoAP payload of a message protected with OSCORE or Group OSCORE . 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 semantics, if one exists.

This registry has been initially populated by the entry in .

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.

References Normative References HMAC-based Extract-and-Expand Key Derivation Function (HKDF) This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Early IANA Allocation of Standards Track Code Points This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. The Constrained Application Protocol (CoAP) 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. Observing Resources in the Constrained Application Protocol (CoAP) 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. Block-Wise Transfers in the Constrained Application Protocol (CoAP) 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. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets 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. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures 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. Object Security for Constrained RESTful Environments (OSCORE) 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. Concise Binary Object Representation (CBOR) Sequences This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. Concise Binary Object Representation (CBOR) 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. CBOR Object Signing and Encryption (COSE): Structures and Process 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. CBOR Object Signing and Encryption (COSE): Initial Algorithms 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. Hybrid Public Key Encryption This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Constrained Resource Identifiers Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) University of the Bundeswehr Munich Self-Issued Consulting Tradeverifyd bibital LLC Security Theory LLC This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. Group Object Security for Constrained RESTful Environments (Group OSCORE) 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. Group Communication for the Constrained Application Protocol (CoAP) 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. End-to-End Protected and Cacheable Responses for the Constrained Application Protocol (CoAP) using Group Object Security for Constrained RESTful Environments (Group OSCORE) RISE AB 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-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. Observe Notifications as CoAP Multicast Responses 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. COSE Algorithms IANA CoAP Option Numbers IANA Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Security Architecture for the Internet Protocol This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] IP Encapsulating Security Payload (ESP) This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] Forward Error Correction (FEC) Building Block This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452. [STANDARDS-TRACK] Multicast Negative-Acknowledgment (NACK) Building Blocks This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. [STANDARDS-TRACK] NACK-Oriented Reliable Multicast (NORM) Transport Protocol This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK] Asynchronous Layered Coding (ALC) Protocol Instantiation This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450. [STANDARDS-TRACK] FLUTE - File Delivery over Unidirectional Transport This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC 3926. [STANDARDS-TRACK] The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. A Firmware Update Architecture for Internet of Things Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality. One component of such a firmware update is a concise and machine-processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) 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. Ephemeral Diffie-Hellman Over COSE (EDHOC) This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE) 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. OSCORE-capable Proxies RISE AB RISE AB When using the Constrained Application Protocol (CoAP), messages exchanged between two endpoints can be protected end-to-end at the application layer by means of Object Security for Constrained RESTful Environments (OSCORE), also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints; and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP Hop-Limit Option. The approach defined in this document can be seamlessly employed also with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest Arm Limited University of Applied Sciences Bonn-Rhein-Sieg Fraunhofer SIT Inria Nordic Semiconductor This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an Internet of Things (IoT) device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. Using Proxies for Observe Notifications as CoAP Multicast Responses 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. Module-Lattice-Based Key-Encapsulation Mechanism Standard Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography - NIST Special Publication 800-56A, Revision 3

Alternatives for Group Content Distribution Other relevant approaches have been proposed for distributing content to multiple recipients over IP multicast. In the following subsections, those are briefly overviewed and functionally compared with the method described in this document.

FLUTE The protocol File Delivery over Unidirectional Transport (FLUTE) provides unidirectional delivery of files from a single sender to multiple recipients, without requiring communication in the opposite direction. Building on the Asynchronous Layered Coding (ALC) protocol , the "objects" that are transferred in FLUTE are files and File Delivery Tables (FDTs) providing metadata and information related to the transferred files. Each object is identified by a Transmission Object Identifier (TOI) chosen by the sender and is sent through one or more ALC packets over UDP and IP multicast. In FLUTE, the sender creates a "session", as a bundle of channels within which objects will be distributed to all the recipients that have joined those channels. A channel is identified by an IP multicast address and port number where FLUTE packets will be sent, while a session is identified by the IP address of the sender paired with a Transport Session Identifier (TSI) chosen by the sender. To provide reliability and avoid the need for communication from the recipients to the sender, FLUTE uses Forward Error Correction (FEC) for each packet, indicating the specific FEC scheme used on a per-packet basis. Consequently, as long as it correctly receives enough packets, a recipient is able to recover the whole object, even in the case of packet loss or packet corruption. FLUTE acknowledges the risk of attacks where an adversary corrupts packets or inject corrupted ones, which can prevent recipients from recovering a distributed object. To counteract such attacks, FLUTE recommends to provide source authentication and content integrity both at an object level (e.g., through a digital signature) and at a packet level (e.g., through a group-keyed message authentication code). While FLUTE does not provide means to enforce such countermeasures, FLUTE recommends to rely on IPsec/ESP in transport mode . In comparison with FLUTE, the following holds for the method described in this document.

The metadata and other information related to the image to transfer are separately distributed as part of the corresponding manifest (see ).
The Proxy corresponds to the FLUTE sender and provides the Devices with the inner chunks of the image retrieved from the Distributor (see ). In particular, each inner chunk corresponds to a file object in FLUTE and is transferred during an epoch, which corresponds to a FLUTE session consisting of a single channel. Within an epoch, each outer chunk corresponds to a FLUTE packet.
Information to participate in the distribution of the image (i.e., equivalent to parameters for the file delivery session in FLUTE) is split into security-related and transport-related. The former information is obtained when joining the OSCORE group that includes both the Devices and the Distributor (see ). The latter information is provided by the Proxy to the Devices as they enroll in an epoch, by means of the "Hold-on Response" sent during the "Admission" phase of that epoch (see ).
Integrity at the image level relies on the digital signature computed over (a digest of) the image and included in the manifest (see ).
Protection of the inner chunks relies on using the group mode of Group OSCORE, providing source authentication and end-to-end security between the Distributor and the Devices through the Proxy. This corresponds to the protection at the file level in FLUTE.
Integrity of the outer chunks relies on the embedded checksums computed by the Proxy (see ). This corresponds to the integrity protection at the packet level in FLUTE.
Unlike in FLUTE, there is communication from the Devices to the Proxy, i.e., to subscribe for the latest manifest as well as to enroll in the distribution of inner chunks of the image.
Unlike in FLUTE, there is no required use of FEC, e.g., on the distributed outer chunks. Instead, during an epoch transferring an inner chunk, Devices can request the retransmission of outer chunks that were not received correctly in that same epoch. Those can be selectively re-requested from the Proxy during the "Recovery Claim" phase of that epoch, so that they are distributed again during the immediately following "Recovery Transfer" phase of that epoch. Also, consecutive epochs are used to transfer consecutive inner chunks of the image. After the last inner chunk of the image has been transferred, the next epoch is used to transfer again the first inner chunk of the image, i.e., the transfer of the whole image is repeated. While this enables newly-enrolled Devices to start retrieving the image, it also allows previously-enrolled Devices to enroll in the new transfer of the image for retrieving inner chunks that they did not successfully receive during a previous distribution.

NORM The protocol NACK-Oriented Reliable Multicast (NORM) provides efficient, scalable, robust, and reliable transport of bulk data objects or streams from one or more senders to a group of receivers over an IP multicast network. NORM data objects are sent to the IP multicast address and port number associated with a NORM session. Each node participating in a NORM session is identified by a session-unique NormNodeId. The transfer of a NORM data object occurs within an instance of NORM session, which is identified by a NormInstanceId. Specifically, transmitted NORM data objects are temporarily, yet uniquely, identified within the NormSession context using the data sender's NormNodeId, the NormInstanceId, and a temporary NormTransportId associated with the data object. To provide reliability, NORM relies on Forward Error Correction (FEC) repair as well as on a selective, negative acknowledgment (NACK) mechanism as a feedback from the data receivers to the data sender. According to the specific FEC scheme used, the data sender splits the data object into FEC coding blocks, each of which is organized into a number of segments. Each segment comprises one or more source or encoding symbols, and it is conveyed as the payload of a NORM_DATA message. Consequently, as long as it correctly receives enough messages, a receiver is able to recover the whole data object, even in the case of message loss or message corruption. A receiver can transmit a negative acknowledgment (NACK) message in order to request a repair transmission of data and/or FEC content from the data sender. A receiver prepares a NACK according to a process that is triggered by local timeouts or by the reception of specific NORM_CMD(FLUSH) messages from the data sender that elicit for a NACK. The actual transmission of a NACK is probabilistically suppressed based on exponentially distributed random backoff timers, in order to avoid an implosion of redundant feedback in the network. Like other feedback messages, NACK messages can be transmitted over multicast to the group at large, or instead over unicast to the data sender. In the latter case, the data sender aggregates the received feedback and relays the result over multicast to the group at large, by means of specific NORM_CMD(REPAIR_ADV) messages. Regarding security, NORM acknowledges the risk of attacks where an adversary might engage in excessively transmitting NACK messages, in an attempt to prevent the data sender from making forward progress in the reliable transmission of data. To counteract such a risk and achieve other security properties, NORM suggests the use of IPsec , with which NORM implementations are required to be compatible. Furthermore, NORM recommends the additional use of application-level integrity-checking of received data content, even when IPsec is used. In comparison with NORM, the following holds for the method described in this document.

The metadata and other information related to the image to transfer are separately distributed as part of the corresponding manifest (see ).
The Proxy corresponds to the NORM data sender and provides the Devices with the inner chunks of the image retrieved from the Distributor (see ). In particular, each inner chunk corresponds to a data object in NORM and is transferred during an epoch, which corresponds to a NORM session. Within an epoch, each outer chunk corresponds to a NORM_DATA message conveying a segment.
Information to participate in the distribution of the image (i.e., equivalent to parameters for the NORM session) is split into security-related and transport-related (see the third bullet point in ).
Integrity at the image level relies on the digital signature computed over (a digest of) the image and included in the manifest (see ).
Protection of the inner chunks relies on using the group mode of Group OSCORE, providing source authentication and end-to-end security between the Distributor and the Devices through the Proxy. This corresponds to application-level integrity-checking of received data content that NORM recommends.
Integrity of the outer chunks relies on the embedded checksums computed by the Proxy (see ). This corresponds to the integrity protection of NORM_DATA messages, e.g., from using IPsec.
Unlike in NORM, there is communication from the Devices to the Proxy for actively enrolling in and triggering the distribution of inner chunks of the image.
Unlike in NORM, there is no required use of FEC, e.g., on the distributed outer chunks.
During an epoch transferring an inner chunk, Devices can request the retransmission of outer chunks that were not received correctly in that same epoch. Those can be selectively re-requested from the Proxy during the "Recovery Claim" phase of that epoch, so that they are distributed again during the immediately following "Recovery Transfer" phase of that epoch. Unlike in NORM, such repair requests are only intended to the Proxy, ask for the retransmission of exactly one outer chunk each, and are only pertinent to the "Recovery Phase" of the specific epoch for which the requested outer chunks have been missed. Therefore, only such outer chunks are going to be distributed again in the immediately following "Recovery Transfer" phase of that epoch. Instead, outer chunks of a different inner chunk are distributed during the later epoch corresponding to that inner chunk, consistent with the sequential and cyclical distribution of inner chunks, each during an exclusively dedicated epoch.

Acknowledgments The author sincerely thanks , , , , , and for their comments and feedback. The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS.