]> RISE AB

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

WIT CoRE Working Group Internet-Draft Group communication for the Constrained Application Protocol (CoAP) can be protected end-to-end by using the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The pairwise mode of Group OSCORE provides authenticated encryption of CoAP messages, by means of symmetric keys that two group members establish only among themselves to achieve pairwise secure communication. This document defines the use of quantum-resistant Key Encapsulation Mechanisms (KEMs) as Pairwise Key Agreement Algorithm of Group OSCORE, enabling post-quantum secure derivation of the symmetric keys used in the pairwise mode. The Group Manager facilitates the exchange of KEM public keys and KEM ciphertexts among group members. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) also supports group communication , e.g., over IP multicast. Building on Object Security for Constrained RESTful Environments (OSCORE) , the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) provides end-to-end security of CoAP messages when using group communication for CoAP. An OSCORE group is associated with a Group Manager, i.e., an entity responsible for managing identifiers and keying material in the group and for handling the join process to add group members, among other tasks. Group OSCORE provides two ways to protect a CoAP message:

• The group mode, which achieves group-level data confidentiality and provides source authentication by means of a digital signature. The message sender computes the signature with its own private key and embeds it in the protected CoAP message.
• The pairwise mode, which achieves pairwise data confidentiality and provides source authentication by means of integrity tags. The message sender performs authenticated encryption of the CoAP message by using a symmetric pairwise key that is exclusively shared with another group member as the intended message recipient. Symmetric pairwise keys are derived from a pairwise shared secret, which in turn is computed from the asymmetric keys of the message sender and recipient, ensuring authenticated key agreement.

In the event that a Cryptographically Relevant Quantum Computer (CRQC) is constructed, it is relatively simple to adapt the group mode of Group OSCORE to be quantum-resistant. That is, it is sufficient to rely on a quantum-resistant signature algorithm (e.g., ML-DSA ) as the Signature Algorithm used in the group (see ). However, equivalent drop-in replacements are not available for the Pairwise Key Agreement Algorithm (see ), which is used to compute the shared secret from which pairwise keys are derived (see ). In particular, the available Pairwise Key Agreement Algorithms are based on a direct Elliptic Curve Diffie-Hellman Static-Static key agreement . At the time of writing, there is no standardized Diffie-Hellman/Non-Interactive Key Exchange (DH/NIKE) that can be used for post-quantum secure establishment of the shared secret, which makes the pairwise mode of Group OSCORE vulnerable to quantum attacks. This document defines the use of quantum-resistant Key Encapsulation Mechanisms (KEMs), such as ML-KEM , as Pairwise Key Agreement Algorithm of Group OSCORE. Consequently, it enables the post-quantum secure establishment of the shared secret and thus the post-quantum secure derivation of the symmetric keys used in the pairwise mode of Group OSCORE. The Group Manager facilitates the exchange of KEM public keys and KEM ciphertexts among group members that perform the KEM-based Pairwise Key Agreement Algorithm.

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 , OSCORE , Group OSCORE , and CBOR Object Signing and Encryption (COSE) .

Pairwise Key Agreement Algorithm In an OSCORE group that uses the pairwise mode and a quantum-resistant KEM as the Pairwise Key Agreement Algorithm, the KEM is identified by the Pairwise Key Agreement Algorithm parameter, within the Common Context of the Group OSCORE Security Context (see ). Like for other algorithms used in Group OSCORE, the KEM used as Pairwise Key Agreement Algorithm MUST be one of those defined for COSE and registered at . For example, the COSE algorithms ML-KEM-512, ML-KEM-768, and ML-KEM-1024 are being registered by , consistent with the three corresponding parameter sets of the standard ML-KEM . For endpoints that support the pairwise mode and use a quantum-resistant KEM as Pairwise Key Agreement Algorithm, the algorithm ML-KEM-512 defined in is mandatory to implement.

Derivation of Pairwise Keys This section defines how pairwise keys are derived when the Pairwise Key Agreement Algorithm used is a quantum-resistant KEM. Analogous to the construction used by OSCORE in , the derivation of pairwise keys is aligned with the one defined in , with the difference that two shared secrets are established through the Pairwise Key Agreement Algorithm, and they are separately used to derive a Pairwise Sender Key and the corresponding Pairwise Recipient Key. For a given endpoint, the derivation of the pairwise keys to use between itself and each other endpoint X in the group is as below: where:

• The same as defined in applies for:
  • HKDF , info, and L.
  • The Sender Key and the Recipient Key.
  • Sender Auth Cred and Recipient Auth Cred.
  • The Pairwise Sender Key, as the AEAD key for processing outgoing messages addressed to endpoint X.
  • The Pairwise Recipient Key, as the AEAD key for processing incoming messages from endpoint X.
• IKM-Sender is the Input Keying Material (IKM) used in the HKDF for the derivation of the Pairwise Sender Key. IKM-Sender is the byte string concatenation of Sender Auth Cred, Recipient Auth Cred, and the Sender Shared Secret. The authentication credentials Sender Auth Cred and Recipient Auth Cred are binary encoded as defined in .
• IKM-Recipient is the Input Keying Material (IKM) used in the HKDF for the derivation of the Pairwise Recipient Key. IKM-Recipient is the byte string concatenation of Recipient Auth Cred, Sender Auth Cred, and the Recipient Shared Secret. The authentication credentials Recipient Auth Cred and Sender Auth Cred are binary encoded as defined in .
• The Sender Shared Secret is computed by the endpoint using the endpoint X's KEM public key, and it is encapsulated in the KEM ciphertext computed by the endpoint and intended to endpoint X.
• The Recipient Shared Secret is computed by the endpoint using the endpoint's own KEM private key to decrypt the KEM ciphertext that endpoint X computed using the endpoint's KEM public key.

A KEM public key associated with the endpoint is used by only one other endpoint X in the group, for computing only one shared secret encapsulated in a KEM ciphertext intended to the endpoint. In order to derive its Pairwise Sender Key, the endpoint has to obtain the endpoint X's KEM public key. Conversely, in order to derive its Pairwise Recipient Key, the endpoint has to obtain the KEM ciphertext that endpoint X computed using the endpoint's KEM public key. However, KEM public keys and KEM ciphertexts are not provided within messages that group members directly send to each other. Instead, group members exchange KEM public keys and KEM ciphertexts via the Group Manager responsible for the group, as defined in .

Use of ML-KEM (FIPS 203) When using ML-KEM as Pairwise Key Agreement Algorithm, the following applies. Editor's note: it should be sufficient to:

• Point to the guidelines/conventions provided in .
• Point to the COSE algorithms ML-KEM-* registered in .
• State that the initial shared secret SS' in is used here:
  • As the Sender Shared Secret, by the endpoint that computes the KEM ciphertext and encapsulates SS' therein.
  • As the Recipient Shared Secret, by the endpoint that decrypts the KEM ciphertext to compute SS'.

Assistance from the Group Manager This section defines the operations that the Group Manager performs to facilitate the exchange of KEM public keys and KEM ciphertexts among group members, when the Pairwise Key Agreement Algorithm used in the group is a quantum-resistant KEM. The following is not relevant for a node that joins the group exclusively as a silent server (see ), or that does not support or does not intend to use the pairwise mode in the group. There are different ways to perform such supportive operations, depending on the specific realization of Group Manager. For example, it is possible to accordingly extend the interface provided by the realization of Group Manager specified in , based on the ACE framework for authentication and authorization in constrained environments . Given an OSCORE group, the following applies.

Uploading a KEM Public Key A group member P has to be able to upload its own KEM public keys at the Group Manager. P generates and uploads at the Group Manager a KEM public key to be retrieved and used by any and exactly one other group member. P can upload a KEM public key at the Group Manager already when joining the group, and then upload other KEM public keys later on as a group member. P stores its KEM public key, the corresponding KEM private key, and a SHA-256 hash of the KEM public key as corresponding identifier. When the Group Manager receives a KEM public key from P, the Group Manager stores the KEM public key as associated with the Sender ID of P in the group. The Group Manager is able to identify P and thereby determine its Sender ID in the group, e.g., by means of the secure communication association shared with P. The Group Manager MUST keep the association between the KEM Public Key and Sender ID of P up-to-date over time, in the event that P changes its Sender ID in the group. The Group Manager is expected to be able to store multiple KEM public keys from the same group member P at any given time.

Retrieving a KEM Public Key Another group member Q has to be able to retrieve from the Group Manager a KEM public key uploaded by P. When Q retrieves a KEM public key of P from the Group Manager (see below), the Group Manager deletes that KEM public key of P from its local storage. P has to be able to gain knowledge about the number of own KEM public keys that are currently stored at the Group Manager. For example, this can rely on P accessing a dedicated resource hosted by the Group Manager. If such resource is observable , P can use CoAP Observe to subscribe for updates about the resource representation, thereby receiving notifications from the Group Manager. Q retrieves a KEM public key of P from the Group Manager, by specifying to the Group Manager the Sender ID of P in the group. Q is expected to retrieve a KEM public key of P when it wants to send to P a message protected with the pairwise mode and it does not have the Pairwise Sender Key required to process the message. After the Group Manager provides Q with the KEM public key of P, the Group Manager deletes the KEM public key of P from its local storage.

Uploading a KEM Ciphertext After Q retrieves a KEM public key of P from the Group Manager (see above), Q uses the KEM public key of P to compute a shared secret and encapsulate it in a KEM ciphertext intended to P. Q uses the shared secret as the Sender Shared Secret for deriving its own Pairwise Sender Key to use with P (see ). Q has to be able to upload at the Group Manager the following information:

• The KEM ciphertext.
• The Sender ID of P, identifying the intended consumer of the KEM ciphertext.
• The SHA-256 hash of the KEM public key of P that was used to compute the KEM ciphertext.

When the Group Manager receives from Q a KEM ciphertext intended to P, the Group Manager stores the KEM ciphertext as associated with the following information:

• The Sender ID of Q, identifying the producer of the KEM ciphertext. The Group Manager is able to identify Q and thereby determine its Sender ID in the group, e.g., by means of the secure communication association shared with Q.
• The Sender ID of P received from Q, identifying the intended consumer of the KEM ciphertext.
• The SHA-256 hash received from Q, as the identifier of the KEM public key of P that was used to compute the KEM ciphertext.

When doing so, the Group Manager overwrites any already stored KEM ciphertext and SHA-256 hash identifier that are associated with the same consumer Sender ID and producer Sender ID. The Group Manager MUST keep up-to-date the association between the KEM ciphertext and the three pieces of information above, in the event that P or Q change their Sender IDs in the group.

Retrieving a KEM Ciphertext P has to be able to retrieve from the Group Manager the following information:

• The KEM ciphertext computed for P by Q.
• The SHA-256 hash identifier of its own KEM public key that Q used to compute the KEM ciphertext.

In order to retrieve that information, P specifies the Sender ID of Q to the Group Manager. Then, the Group Manager provides the requested information, if it stores a KEM ciphertext associated with both:

• The specified Sender ID of Q, identifying the producer of the KEM ciphertext; and
• The Sender ID of P, identifying the intended consumer of the KEM ciphertext. The Group Manager is able to identify P and thereby determine its Sender ID in the group, e.g., by means of the secure communication association shared with P.

After providing P with the requested KEM ciphertext and SHA-256 hash identifier, the Group Manager deletes those two pieces of information from its local storage, freeing up their association with the consumer Sender ID and producer Sender ID. P is expected to retrieve the KEM ciphertext computed by Q when it receives from Q a message protected with the pairwise mode and it does not have the Pairwise Recipient Key required to process the message. P uses the SHA-256 hash identifier to retrieve its own corresponding KEM public key and KEM private key from its local storage. Then, P computes the shared secret by decrypting the KEM ciphertext using its retrieved KEM private key. After that, P deletes from its local storage the KEM private key just used, as well as the corresponding KEM public key and the corresponding SHA-256 hash identifier. P uses the shared secret as the Recipient Shared Secret for deriving its own Pairwise Recipient Key to use with Q (see ).

Security Considerations The security considerations from hold for this document too. The security considerations for the specific KEM used as Pairwise Key Agreement Algorithm also apply. Editor's note: add further security considerations.

IANA Considerations This document has no actions for IANA.

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. 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. 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) 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. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. Nokia Nokia University of the Bundeswehr Munich This document describes conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) with CBOR Object Signing and Encryption (COSE). NIST 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 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 JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. 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.

Acknowledgments The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next project CYPRESS.