]> Ericsson

goran.selander@ericsson.com

Ericsson

john.mattsson@ericsson.com

Limoges University

clement.papon@unilim.fr

Security LAKE Working Group Internet-Draft The Lightweight Authenticated Key Exchange (LAKE) protocol, formerly known as Ephemeral Diffie-Hellman over COSE (EDHOC), as originally specified in RFC 9528, relies on Elliptic Curve Cryptography (ECC) for key exchange and authentication. This document specifies how the LAKE protocol operates in a post-quantum setting by defining new cipher suites using quantum-resistant algorithms, such as ML-DSA for digital signatures and ML-KEM for key exchange. This document also updates RFC 9528 by changing the name of the protocol together with associated terminology and IANA registries from EDHOC to LAKE, as well as updating the Method Types and Cipher Suites registries of the protocol to add columns indicating, respectively, whether a method requires and whether a cipher suite supports Diffie-Hellman or Non-Interactive Key Exchange (NIKE) primitives. 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 defined in , previously known as Ephemeral Diffie-Hellman over COSE (EDHOC), supports multiple authentication methods and negotiation of cipher suites based on COSE algorithms. Four asymmetric authentication methods (0–3) are defined in . A symmetric key-based authentication method and a Key Encapsulation Mechanism (KEM)-based authentication method are being developed; see and , respectively. The cipher suites defined in rely on Elliptic Curve Cryptography (ECC) for key exchange and authentication. While ECC is well suited to constrained environments, it is vulnerable to attacks by a Cryptographically Relevant Quantum Computer (CRQC). This document specifies how the LAKE protocol operates in a post-quantum setting by defining new cipher suites using ML-KEM for key exchange and ML-DSA for digital signatures. ML-KEM provides a post-quantum replacement for the ephemeral Diffie-Hellman key exchange. The new cipher suites can be used with signature-based authentication, as well as with the PSK-based and KEM-based authentication methods being developed; see on algorithms not used in certain methods. KEM algorithms such as ML-KEM are not Diffie-Hellman or Non-Interactive Key Exchange (DH/NIKE) primitives. Consequently, the new ML-KEM cipher suites cannot be used with methods 0–3, which require DH/NIKE. This document therefore updates the Method Types and Cipher Suites registries of the protocol to add columns indicating, respectively, whether a method requires and whether a cipher suite supports DH/NIKE-based key exchange; see and . The new cipher suites combining ML-KEM and ML-DSA are registered accordingly. With the addition of KEM-based key exchange, the protocol is no longer dependent on Diffie-Hellman, and the name Ephemeral Diffie-Hellman over COSE (EDHOC) no longer accurately describes the protocol. Accordingly, this document updates by changing the name of the protocol from EDHOC to Lightweight Authenticated Key Exchange (LAKE), a name associated with the protocol in the literature. The EDHOC prefix is replaced by LAKE also in terminology and IANA registry entries defined in .

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 . Consistent with the change of protocol name, all terms using the prefix "EDHOC" should henceforth be replaced by corresponding terms with the prefix "LAKE", for example, LAKE_KDF, LAKE_Extract, LAKE_Expand, LAKE_Exporter, LAKE_KeyUpdate, LAKE AEAD Algorithm, LAKE hash algorithm, LAKE MAC algorithm, LAKE key exchange algorithm, LAKE signature algorithm, etc.

LAKE 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 , are 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, in order to replace the Ephemeral Diffie-Hellman key exchange, a quantum-resistant Key Encapsulation Mechanism (KEM), such as ML-KEM , can be applied directly to the LAKE protocol, as is detailed in . To enable post-quantum security support for LAKE it suffices to register new cipher suites using COSE registered algorithms. Cipher suites using ML-KEM-512 and ML-KEM-1024 for key exchange, and ML-DSA-44 and ML-DSA-87 for digital signatures are specified in . As both ML-KEM and ML-DSA internally use SHAKE256 , it was natural to have SHAKE256 as LAKE hash algorithm in the cipher suite, and thus used also in the key derivation, see . Note that as application hash function in these cipher suites, the legacy algorithms SHA-256 or SHA-384 are still used, see . 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 require DH/NIKE, a column is added to the LAKE 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 support for the LAKE protocol is to define new authentication methods based on a Key Encapsulation Mechanisms (KEMs), one such method is specified in . The cipher suites defined in this document can also be used with these authentication methods. Compared to elliptic curve algorithms such as ECDHE, ECDSA, and EdDSA, ML-KEM and ML-DSA introduce significantly higher overhead (see and respectively), but currently are the most lightweight standardized post-quantum algorithms to use with LAKE. More efficient post-quantum signature schemes are being standardized, such as FN-DSA, which could offer smaller signatures. This remains a possible direction for future research, analysis and standardization, after which they may be included in new cipher suites. However, it is important to note that these cipher suites may not be usable for certain classes of constrained devices (see ) due to, e.g., increased size of signatures or of KEM keys in quantum-resistant algorithms.

Using KEMs in the Key Exchange Given a quantum-resistant KEM, such as ML-KEM-512, with encapsulation key ek, decapsulation key dk, ciphertext c, and shared secret key K (using the notation of ), the Diffie-Hellman procedure in the key exchange 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(dk, c).
• G_XY is the shared secret key K.

The security requirements and security considerations of and of the KEM algorithm used apply. For example, the Initiator MUST generate a new encapsulation / decapsulation key pair for each LAKE session. Note that G_Y does not contain a public key when a KEM is used in this way. The definition of LAKE 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 c is known from the corresponding algorithm in the selected cipher suite, see . Hence the Initiator can separate out the concatenated ciphertexts, decapsulate and decrypt, respectively. Length of ML-KEM Ciphertext.

KEM	Length of ciphertext (bytes)
ML‑KEM‑512	768
ML‑KEM‑768	1088
ML‑KEM‑1024	1568

Note also that this use of KEM applies both to standalone KEM and composite hybrid KEMs such as, e.g., . 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 this section we discuss the security considerations brought by the new cipher suites.

Classical LAKE Security Properties 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 security properties discussed in (for Method 0) and in (for PSK method). These include, for example, mutual authentication and confidentiality, keys security, identity protection, External Authorization Data (EAD) security, etc. This is because the security properties of LAKE (methods 0 and PSK) are affected by cipher suites only through the security of the algorithms involved. Since the algorithms introduced in these cipher suites -- ML-KEM, ML-DSA and SHAKE256 -- are post-quantum secure, i.e., secure against a quantum adversary and, by extension, secure against a classical adversary, the classical security properties are guaranteed.

Post-quantum Security Cipher suites specified in this document use ML-KEM for ephemeral key exchange, and ML-DSA for authentication. These algorithms are constructed to provide security against a quantum adversary. Security considerations of ML-KEM are discussed in , and those of ML-DSA are addressed in . The security of LAKE for methods 0 to 3, specified in , and for the PSK mode, settled in , has been established in the Random Oracle Model (ROM), i.e., against "classical" adversaries. In the Quantum Random Oracle Model (QROM), two adversary models are relevant: a Q1 adversary, able to perform offline quantum computations, but who can only make classical queries to oracles defined according to the protocol; and a Q2 adversary, able to query all the oracles in superposition. The Q1 adversary is considered as the most realistic and practicable threat model currently. However, establishing the security properties of LAKE Method 0 and PSK with quantum-resistant cipher suites in the Q1 model is left for future work. To date, only the standalone primitives ML-KEM and ML-DSA have been analyzed in the QROM, and their integration into cipher suites is not sufficient to claim the overall post-quantum security of LAKE Method 0 and PSK with these new cipher suites. The first two cipher suite proposals have Category 1 security level (according to NIST), while proposal 3 is in Category 5, see . As discussed above, SHA-256 and SHA-384, used as application hash functions in these cipher suites are still considered to provide adequate security against quantum pre-image attacks, providing 128-bit and 192-bit security levels, respectively.

Store Now Decrypt Later The use of PQ-KEM, e.g., ML-KEM, for ephemeral key exchange in LAKE Method 0 and PSK protects against Store Now Decrypt Later (SNDL) attacks from an adversary equipped with a CRQC.

PQ/T Hybridization In the event that a feasible attack against ML-KEM or ML-DSA is discovered (that does not require a CRQC), the use of hybrid algorithms in a cipher suite, i.e., a cipher suite combining classical and post-quantum algorithms for ephemeral key exchange and signature-based authentication, ensures the continuity of the (classical) security of the LAKE Method 0 and PSK protocols in post-quantum settings (as long as the classical algorithms remain secure). PQ/T hybrid algorithms such as could be registered in the future.

Side-channel Considerations Implementations of post-quantum algorithms, e.g., lattice-based or code-based algorithms, have been shown to be susceptible to side-channel attacks, e.g., regarding timing or power analysis attacks. Side-channel resistance of ML-KEM and ML-DSA depends both on their implementation and on how they are used within the protocol itself. Implementations MUST follow the side-channel requirements given in the specifications of ML-KEM and ML-DSA . Additional implementation guidance on side-channel attack resistance can be found in and . Moreover, ML-KEM key used for ephemeral key exchange MUST be freshly generated for each LAKE protocol session. In addition, analyzing the resistance of LAKE Method 0 and PSK to side-channel attacks, in post-quantum settings is out of scope of this document and left for future work.

Privacy Considerations This document does not add any new privacy considerations to those discussed in .

IANA Considerations This section specifies the name change of the registries and the updates to the Method Types and Cipher Suites registries for the protocol.

Name Change of EDHOC Registry Group Consistent with the change of protocol name, the IANA has changed the name of the registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" to "Lightweight Authenticated Key Exchange (LAKE)". A note is added to the preamble of the registry group: Renamed from "Ephemeral Diffie-Hellman Over COSE (EDHOC)"

Name Change of EDHOC Registries Consistent with the change of protocol name, the names of all IANA registries that include the term "EDHOC" in the registry group of this protocol are changed:

• "EDHOC Exporter Labels" is renamed "LAKE Exporter Labels". A note is added to the registry: Renamed from "EDHOC Exporter Labels"
• "EDHOC Cipher Suites" is renamed "LAKE Cipher Suites". A note is added to the registry: Renamed from "EDHOC Cipher Suites"
• "EDHOC Method Types" is renamed "LAKE Method Types". A note is added to the registry: Renamed from "EDHOC Method Types"
• "EDHOC Error Codes" is renamed "LAKE Error Codes". A note is added to the registry: Renamed from "EDHOC Error Codes"
• "EDHOC External Authorization Data" is renamed "LAKE External Authorization Data". A note is added to the registry: Renamed from "EDHOC External Authorization Data"
• "EDHOC Authentication Credential Types" is renamed "LAKE Authentication Credential Types". A note is added to the registry: Renamed from "EDHOC Authentication Credential Types"

LAKE Method Types Registry IANA is requested to update the LAKE Method Types 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: LAKE Method Types.

Value	Initiator Key	Responder Key	Requires DH/NIKE
0	Signature Key	Signature Key	No
1	Signature Key	Static DH Key	Yes
2	Static DH Key	Signature Key	Yes
3	Static DH Key	Static DH Key	Yes
4	PSK	PSK	No
23	Reserved	Reserved

RFC Editor Note: Please verify during publication that the LAKE Method Types registry has not been modified since the IANA instructions in this document were written. The table above assumes that is published before this document and registers value 4, and that is published after this document.

LAKE Cipher Suites Registry IANA is requested to update the LAKE 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 Cipher Suites 0–6, 24, and 25, the entry "Yes" is inserted in the new "Supports DH/NIKE" column. The column is left empty for all other existing entries. Furthermore, IANA is requested to register the following entries in the LAKE Cipher Suites registry, with this document as the reference: LAKE Cipher Suites.

Value	Array	Description	Supports DH/NIKE
TBD1	30, -45, 16, TBD10, -48, 10, -16	AES-CCM-16-128-128, SHAKE256, 16, MLKEM512, ML-DSA-44, AES-CCM-16-64-128, SHA-256	No
TBD2	3, -45, 16, TBD10, -48, 3, -16	A256GCM, SHAKE256, 16, MLKEM512, ML-DSA-44, A256GCM, SHA-256	No
TBD3	3, -43, 16, TBD12, -50, 3, -43	A256GCM, SHA-384, 16, MLKEM1024, ML-DSA-87, A256GCM, SHA-384	No

Cipher suite TBD3 is intended for high security applications such as government use and financial applications. This cipher suite consists of algorithms from the Commercial National Security Algorithm (CNSA) 2.0 suite . RFC Editor Note: Please verify during publication that the LAKE Cipher Suites registry has not been modified since the IANA instructions in this document were written.

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 the Bundeswehr Munich This document describes conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) with CBOR Object Signing and Encryption (COSE). 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 Universität Bremen TZI Ericsson Universitat Politecnica de Catalunya The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. ISI, R.C. ATHENA ISI, R.C. ATHENA ISI, R.C. ATHENA ISI, R.C. ATHENA This document specifies extensions to the Lightweight Authenticated Key Exchange (LAKE) protocol, formerly known as Ephemeral Diffie- Hellman over COSE (EDHOC), to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) Key Encapsulation Mechanisms (KEMs) for both key exchange and authentication. It defines a new signature-free KEM-based authentication method in which both parties authenticate using KEMs, enabling quantum-resistant authentication without relying on digital signatures when PQC KEMs, such as the NIST-standardized ML-KEM, are used. Inria Ericsson Ericsson University of Murcia University of Murcia This document specifies a Pre-Shared Key (PSK) authentication method for the Lightweight Authenticated Key Exchange (LAKE) protocol. The PSK method provides mutual authentication, ephemeral key exchange, identity protection, and quantum resistance while incurring lower computational costs than the public-key authentication methods specified for LAKE. It is 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 LAKE session (resumption PSK). This document details the PSK message flow, key derivation changes, message formatting, processing, and security considerations. SandboxAQ Cisco PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. Oracle NIST standardized ML-DSA as FIPS 204 in August 2024. This document discusses how to use ML-DSA within protocols - that is, what problem it solves, and what you need to do to use it securely. Cisco Systems National Institute of Standards and Technology Ericsson Individual Arqit Quantum Inc NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM within protocols - that is, what problem it solves, and what you need to do to use it securely. National Security Agency

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