]> RISE AB

Isafjordsgatan 22 Kista 16440 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 can 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 .
• 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 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). This still relies on the same CoAP Block1 and Block2 options as also explicitly indicating the use of BERT. In practice, a BERT message conveys in its payload one or more blocks of size 1024 bytes, with the possible exception of the BERT message conveying the last block that can have a smaller size.

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 in case 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 still leaving those able to perform their intended tasks. Furthermore, since the OSCORE processing of a CoAP message results in another CoAP message, OSCORE is independent of the specific transport underlying CoAP and used to transport CoAP messages (e.g., UDP or TCP). Therefore, OSCORE works wherever CoAP works. In order to use OSCORE, two CoAP endpoints have to first establish an OSCORE Security Context including the necessary parameters and keying material. OSCORE is agnostic of how exactly the Security Context is established. A possible way is the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) .

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 is signed by using the private key of the sender endpoint. The resulting signature is placed at the end of the CoAP payload of the protected message and then separately encrypted in order to contrast tracking of endpoints across different groups. As a result, all group members are able to decrypt the message and to verify that the message sender is the alleged group member. The group mode is typically used to protect requests sent to the whole group, i.e., intended to all its CoAP servers.
• When using the pairwise mode (see ), the message is protected by using an authenticated encryption algorithm. The encryption key to use is derived from the asymmetric authentication credentials of the sender endpoint and the single recipient endpoint, by means of a static-static Diffie-Hellman key derivation performed locally. As a result, only the intended recipient is able to decrypt the message and to verify that the message sender is the alleged group member. The pairwise mode is typically used to protect a response individually sent by a server in the group.

In order to use Group OSCORE, a CoAP endpoint has to join an OSCORE group and effectively become a member. The join process is typically assisted by a Group Manager entity that is responsible for the OSCORE group and that might enforce access control when deciding whether to admit new endpoints requesting to join the group. As a result of a successful join process, a CoAP endpoint obtains the necessary parameters and keying material to set up a Group OSCORE Security Context and consequently use Group OSCORE with the other group members. A possible realization of Group Manager is specified in , 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 , effective caching of responses is not achievable anymore. That is, even if two clients wish to send the same plain CoAP request, the two resulting protected requests will be different and thus will not result in a cache hit at the proxy. Therefore, separately for each of the two clients, the proxy has to retrieve a new response from the origin server. In order to overcome this limitation, the approach defined in builds on Group OSCORE and restores the effective cacheability of protected responses. According to this approach, any client in the OSCORE group can also act as a specific "Deterministic Client" and use the corresponding keying material known to all the group members. When acting as Deterministic Client, any two clients in the group that protect the same plain CoAP request will produce the same protected "Deterministic Request", which is thereby usable to produce a cache hit at a caching proxy. The construct that makes this possible relies on the following design points: i) Deterministic Requests are computed by using a variation of the pairwise mode of Group OSCORE; ii) responses to a Deterministic Request are protected by using the group mode of Group OSCORE. This approach restores cacheability of protected responses while sacrificing some security properties of the protected Deterministic Requests, which in fact are replays and have no source authentication. However, this is deemed acceptable and harmless for the particular, narrow scope targeted by this approach, whose applicability is limited to content retrieval through read-only requests that are safe in the REST sense. Servers that want to be even more conservative can additionally limit themselves to accept only Deterministic Requests that target specific resources, or even that match byte-by-byte with Deterministic Requests known in advance.

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, the architecture in 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 message 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 Section 7 of ).
• 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 the 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, 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.

1. The Device composes an observation request targeting the manifest resource at the Distributor.
2. The Device protects the observation request from Step 1 with Group OSCORE, specifically using the construct defined in and therefore producing a Deterministic Request.
3. The Device sends the Deterministic Request from Step 2 to the Proxy. If the Deterministic Request does not produce a cache hit at the Proxy (e.g., as the first of this kind sent by any Device), the Proxy forwards the Deterministic Request to the Distributor, thereby registering itself as the actual observer at the Distributor. The Proxy caches the corresponding successful response from the Distributor and forwards it back to the Device. Otherwise, the Proxy does not interact with the Distributor, but instead promptly replies to the Device, by using the response stored in the identified cache entry.
4. Upon receiving a first successful notification response, the Device obtains the latest manifest and is subscribed for automatically receiving future manifests released for the same SW component.

When releasing a new SW update, the Author uploads the corresponding manifest and image on the Distributor. As discussed in , those become available at the manifest resource and at a new, dedicated image resource hosted by the Distributor, respectively. After that, the Distributor sends a notification response to the observer Proxy, conveying the newly released manifest. The Proxy stores the notification response in the cache entry that it uses to store responses for that observation, by overwriting the current content of the entry. Finally, the Proxy forwards that notification response to the observer Devices. Upon receiving the notification response, the observer Devices obtain the new manifest, thus becoming aware of the new SW update and of the corresponding image resource at the Distributor. In setups where multiple Proxies are deployed and each assists a different set of Devices, the Distributor can rely on the approach defined in as a possible optimization. Consequently, following the release of a new SW update, the Distributor sends a single observe notification response over UDP and IP multicast, thereby providing all the observer Proxies at once with the latest manifest corresponding to the newly released SW update. 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 Block2 outer 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 required to, 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 parameter "progress_indicator", 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 targeting the Distributor and that does not produce a cache hit, 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.

1. 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).
2. Forward the Deterministic Request to the Distributor over TCP.
3. Once received a corresponding successful 2.05 (Content) response from the Distributor, create a cache 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 ).
4. Start an epoch with "Admission" as its current phase and associate it with ENTRY.
5. Initialize an unsigned integer INNER_INDEX to 0 and associate it with ENTRY.
6. Determine the time t_A when the immediately following "Full Transfer" phase will start. Start a timer with expiration set at t_A.
7. 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 targeting the Distributor and that produces a cache hit for the cache entry ENTRY associated with an epoch with current phase "Admission", the Proxy performs the following steps.

1. If ENTRY is storing the inner chunk to transfer in the current epoch, then 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" will start. Start a timer with expiration set at t_A.
   • Move to Step 2.
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 this epoch. Each of those responses will convey one outer chunk of the inner chunk distributed in this epoch. Per , the "tp_info" parameter specifies addressing information as Constrained Resource Identifiers (CRIs) . Furthermore, for each epoch, the "tp_info" parameter MUST specify a different Token value to use for the multicast responses. The same Token value MUST NOT be reused in any other epoch of the current transfer of the image or in any epoch of the two following transfers of the same image.
   • "next_not_before", which is defined in . This parameter specifies the amount of seconds that will minimally elapse before the "Full Transfer" phase of this 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 this 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 this 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 this 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 this epoch (see ).
• It MUST include a Block2 outer 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 Request" and "Recovery Transfer" phases. Then, the Proxy sequentially sends the outer chunks to the enrolled Devices, according to their indexes 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 Block2 outer 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 this epoch (see ). This phase finishes when the Proxy has sent all the outer chunks corresponding to the inner chunk of this epoch. After that, the epoch moves to the "Recovery Claim" phase (see ). If the Proxy receives a Deterministic Request targeting the Distributor and that produces a cache hit for the cache entry ENTRY associated with an epoch with current phase "Full Transfer", 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 targeting the Distributor and that produces a cache hit for the cache entry ENTRY associated with an epoch with current phase "Recovery Claim", the Proxy performs the following steps.

1. The Proxy considers the received Deterministic Request and in particular its Block2 outer option. The value specified by the NUM field of the option value is added to RECOVERY_INDEXES if it is not included there already.
2. 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 this informative 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 this 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 (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 this 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 this 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 Block2 outer 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 targeting the Distributor and that produces a cache hit for the cache entry ENTRY associated with an epoch with current phase "Recovery Transfer" or in its "Epilogue", 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.

1. 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.
2. 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.
3. 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 CoAP 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 CoAP Pre-OSCORE-Data option defined in . The use of checksums counteracts an attack against availability that an active adversary can 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 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, consistently with the "Value" field in the entry of the "COSE Algorithms" Registry for this 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 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 Block2 outer option, which is included in the response sent to the Proxy as the inner chunk. From the Device point of view, this value is encoded as a CBOR unsigned integer by the "progress_indicator" parameter, which is conveyed in the payload of the error informative responses that the Proxy sends during the "Admission" phase (see ) 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 consisting of (the notation follows ):

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 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 occur at most 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 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	0-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 that identifies the semantics of the data conveyed by the CBOR data item. In particular, the option value MUST be either X or (X + 1), where X is taken from the 'Value' column of the "Pre-OSCORE Data Semantics" IANA registry defined in . Both X and (X + 1) identify the same data semantics. However:

• The odd value X means that the CBOR data item is a CBOR byte string, whose value is the data with the indicated semantics.
• The even value (X + 1) means that the CBOR data item is a COSE object, i.e., a possibly tagged COSE message as defined in . The data with the indicated semantics consists of what is available at the recipient once successfully completed all the COSE processing, e.g., a plaintext recovered after a decryption process.

The recipient of a CoAP message including the Pre-OSCORE-Data option MUST consume the option, i.e., it removes and consumes the prepended CBOR data item from the CoAP payload, after which it removes the option from the message. The Pre-OSCORE-Data option MAY occur multiple times. In such a case, each occurrence of the option refers to one CBOR data item prepended to the OSCORE ciphertext within the CoAP payload. In particular, the i-th occurrence of the option refers to the i-th prepended CBOR data item. The Pre-OSCORE-Data option is of class U for OSCORE .

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. In order to indicate the presence of such CBOR data item, the response MUST include the Pre-OSCORE Data option , 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 Direct Encryption Mode specified in MUST be used. The input pt for the HPKE Seal 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 operation (see ).
  Editor's note: describe examples of how the Distributor can obtain the static public key of the Proxy and possibly select the right one to use at runtime.

Secure communication associations between the Distributor and the Proxy can rely, for example, on a TLS 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, as defined in .

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 value identifies the semantics of the data 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 error, if one exists.

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

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 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. 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) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. 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. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document 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. 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 to add a note on how the "URI Schemes" registry of RFC 7595 cooperates with the "CRI Scheme Numbers" registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –22 addresses a few remaining post-WGLC nits. University of Applied Sciences Bonn-Rhein-Sieg Transmute bibital 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 works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. This document defines the use of the HPKE with COSE. 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 CoAP messages exchanged 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. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References 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. 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. 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. 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. 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. 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 for a key owned by the Client and bound to an OAuth 2.0 access token. RISE AB RISE AB Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, 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 option Hop-Limit. The approach defined in this document can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. 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.

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.