]> Ericsson

goran.selander@ericsson.com

Ericsson

john.mattsson@ericsson.com

Security LAKE Working Group Internet-Draft The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-DSA for digital signatures and ML-KEM for key exchange. This document specifies how EDHOC operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites. About This Document Status information for this document may be found at . Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC) , supports the use of multiple authentication methods and the negotiation of cipher suites based on COSE algorithms. Currently, four asymmetric authentication methods (0, 1, 2, and 3) are defined. In addition, a symmetric key-based authentication method is being developed, see . Currently defined cipher suites rely on Elliptic Curve Cryptography (ECC) for key exchange and authentication, making them vulnerable in the event that a Cryptographically Relevant Quantum Computer (CRQC) is constructed. This document specifies how EDHOC can operate in a post-quantum setting using both signature-based and PSK-based authentication, and defines corresponding cipher suites.

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

EDHOC with Quantum-Resistant Algorithms Method 0 in , which uses digital signatures for authentication by both the Initiator and Responder, and also the PSK method in , is straightforward to use with standardized post-quantum algorithms. A quantum-resistant signature algorithm, such as ML-DSA , is a drop-in replacement for classical signature algorithms such as ECDSA. For post-quantum secure key exchange, a quantum-resistant Key Encapsulation Mechanism (KEM), such as ML-KEM , can be applied directly to EDHOC, as is detailed in . To enable post-quantum security in EDHOC it suffices to register new cipher suites using COSE registered algorithms. Cipher suites using ML-KEM-512 for key exchange and ML-DSA-44 for digital signatures are specified in . As both ML-KEM and ML-DSA internally use SHAKE256, it is natural to also use SHAKE256 for EDHOC's key derivation. Additional post-quantum cipher suites may be specified. Methods 1–3 in use a Diffie-Hellman/Non-Interactive Key Exchange (NIKE) based API for authentication. As of this writing, no standardized post-quantum algorithms for these methods exist. To highlight which methods that require DH/NIKE a column is added to the EDHOC Method Type registry, see . To highlight matching cipher suites a corresponding column indicating support for DH/NIKE is added, see . An alternative path to post-quantum EDHOC, not pursued in this document, would be to define new authentication methods based on Key Encapsulation Mechanisms (KEMs). Compared to elliptic curve algorithms such as ECDHE, ECDSA, and EdDSA, ML-KEM-512 and ML-DSA-44 introduce significantly higher overhead . More efficient post-quantum signature schemes are being standardized, such as FN-DSA.

Using KEMs in EDHOC Key Exchange Given a quantum-resistant KEM, such as ML-KEM-512, with encapsulation key ek, ciphertext c, and shared secret key K (using the notation of ). The Diffie-Hellman procedure in EDHOC is replaced by a KEM procedure as follows:

• The Initiator generates a new encapsulation / decapsulation key pair matching the selected cipher suite.
• The encapsulation key ek is transported in the G_X field in message_1.
• The Responder calculates (K,c) = Encaps(ek).
• The ciphertext c is transported in the G_Y field in message_2.
• The Initiator calculates the shared secret K = Decaps(c).
• G_XY is the shared secret key K.

The security requirements and security considerations of EDHOC and the KEM algorithm used apply. For example, the Initiator MUST generate a new encapsulation / decapsulation key pair for each EDHOC session. Note that G_Y does not contain a public key when a KEM is used in this way. The definition of EDHOC message_2 in remains the same: and G_Y_CIPHERTEXT_2 remains the concatenation of G_Y and CIPHERTEXT_2, the latter is defined in . But now G_Y is a KEM ciphertext. Just as with the ephemeral key G_Y, the length of KEM ciphertext G_Y is known from the corresponding algorithm in the selected cipher suite, see . Hence the Initator can separate out the concatenated ciphertexts and decapsulate and decrypt, respectively.

Length of ML-KEM Ciphertext.

Note also that this use of KEM applies both to standalone KEM and hybrid KEMs such as, e.g., X-wing . Conventions for using post-quantum KEMs within COSE are described in . The shared secret key K corresponds to the initial shared secret SS' in that document.

Security Considerations The cipher suites defined in rely on Elliptic Curve Cryptography (ECC) for key exchange and authentication, which would be broken by a Cryptographically Relevant Quantum Computer (CRQC). In contrast, the cipher suites specified in this document use the quantum-resistant algorithms ML-KEM for key exchange and ML-DSA for authentication. When used with Method 0 from , where both the Initiator and Responder authenticate using digital signatures, or with the PSK method defined in , these cipher suites preserve the same security properties even in the presence of a quantum-capable adversary. Security considerations of ML-KEM are discussed in .

Privacy Considerations TBD

IANA Considerations

EDHOC Method Type Registry IANA is requested to update the EDHOC Method Type registry with a column with heading "Requires DH/NIKE" indicating that the method requires Diffie-Hellman or Non-Interactive Key Exchange. Valid table entries in this column are "Yes" and "No". For the existing Method Types, the following entries are inserted in the new "Requires DH/NIKE" column:

EDHOC Cipher Suites Registry IANA is requested to update the EDHOC Cipher Suites registry with a column with heading "Supports DH/NIKE" indicating that the cipher suite supports Diffie-Hellman or Non-Interactive Key Exchange. Valid table entries in this column are "Yes" and "No". For the existing EDHOC Cipher Suites 0-6, 24, 25, the entry "Yes" is inserted in the new "Supports DH/NIKE" column. Furthermore, IANA is requested to register the following entries in the EDHOC Cipher Suites Registry: Cipher suite TBD3 is intended for for high security applications such as government use and financial applications. This cipher suites consists of algorithms from the Commercial National Security Algorithm (CNSA) 2.0 suite [CNSA2].

References Normative References 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. Tradeverifyd Tradeverifyd This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Nokia Nokia University of Applied Sciences Bonn-Rhein-Sieg This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. 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 Inria Ericsson Ericsson University of Murcia University of Murcia This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations. SandboxAQ MPI-SP & Radboud University Cloudflare This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. Cisco Systems National Institute of Standards and Technology Ericsson Quantinuum Arqit Quantum Inc NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM and how to use it within protocols - that is, what problem it solves, and what you need to do to use it securely.

Acknowledgments This work was supported partially by Vinnova - the Swedish Agency for Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS.