]> Ericsson

Sweden goran.selander@ericsson.com

Ericsson

Sweden john.mattsson@ericsson.com

Lightweight Authenticated Key Exchange The Lightweight Authenticated Key Exchange (LAKE) protocol supports methods with different numbers of messages and different security properties. The methods defined in the original specification, RFC 9528, consist of three mandatory messages and an optional fourth message. This document defines a generic mechanism for additional protected messages, message_n, where n is greater than the highest message number defined for the method in use. The format of each message_n is identical to that of message_4 in RFC 9528, except that its encryption key and initialization vector are derived using the LAKE_Exporter. This mechanism allows applications to include any number of additional protected messages in a LAKE session, for example, to carry additional External Authorization Data (EAD) and to convey protected success indications when required by a method or deployment, such as EAP-LAKE. This document updates RFC 9528. 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 .

Introduction Lightweight Authenticated Key Exchange (LAKE) , previously known as Ephemeral Diffie-Hellman Over COSE (EDHOC), is a compact authenticated Diffie-Hellman key exchange designed for constrained environments. The methods specified in consist of three mandatory messages (message_1, message_2, and message_3) and an optional fourth message (message_4). Each message can carry External Authorization Data (EAD) in its corresponding field (EAD_1, EAD_2, EAD_3, or EAD_4; see ), allowing external security applications to be integrated into LAKE without additional round trips. For these methods, the optional message_4 () provides key confirmation and a protected success indication to the Initiator. This is useful in deployments where the Responder does not send a protected application message to the Initiator, such as EAP-LAKE . The PSK-based method specified in requires four messages. Some applications require additional protected messages than are provided by a given LAKE method. Examples include security applications that use EAD and need to exchange multiple messages after mutual authentication, such as post-handshake remote attestation, applications needing a protected acknowledgement of EAD_4, and methods with five messages, such as , where the Initiator needs a protected success indication when the method is used with EAP-LAKE . Using an application protocol such as OSCORE to protect these messages is not always possible. This document defines message_n, a generic additional LAKE message where n is an integer greater than the highest message number defined for the method in use (i.e., n >= 5 for the methods in and ). message_n looks and works like message_4 in . In contrast to message_4, for n >= 5, the key K_n and the initialization vector IV_n are derived with the LAKE_Exporter () using dedicated exporter labels and n as context, and the external_aad is empty. Using the exporter means that message_n does not change the LAKE key schedule of any method, that two registered exporter labels serve an unbounded number of messages, and that message_n can be implemented on top of any LAKE implementation. This document updates by defining message_n for use with all LAKE methods, by requiring message_4 when message_n is used with the methods in (), and by specifying when a LAKE session in which message_n is used is completed (). This document does not change the use of message_4 in when message_n is not used and does not update .

Conventions and Definitions 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 LAKE , CBOR , CBOR Sequences , COSE , and CDDL . As in , CBOR always refers to deterministically encoded CBOR. This document uses the terms, functions, and algorithm names defined in with the protocol name replaced by LAKE, e.g., LAKE_Exporter, LAKE_KDF, LAKE_KeyUpdate, LAKE AEAD algorithm, and LAKE error message.

Protocol Overview shows a LAKE message flow for methods 0 to 3 extended with message_5 and message_6. As for the handshake messages, the odd messages are sent by the Initiator and the even messages by the Responder. When message_n is used with these methods, message_4 is mandatory; see .

LAKE Message Flow with message_5 and message_6 | | message_1 | | | | G_Y, Enc( C_R, ID_CRED_R, Signature_or_MAC_2, EAD_2 ) | |<------------------------------------------------------------------+ | message_2 | | | | AEAD( ID_CRED_I, Signature_or_MAC_3, EAD_3 ) | +------------------------------------------------------------------>| | message_3 | | | | AEAD( EAD_4 ) | |<------------------------------------------------------------------+ | message_4 | | | | AEAD( EAD_5 ) | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->| | message_5 | | | | AEAD( EAD_6 ) | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | message_6 | ]]>

The receiver does not learn n from the message itself; n is determined by the protocol state. Since K_n and IV_n depend on n, a message_n that is processed with the wrong value of n fails AEAD verification.

Specification of message_n This section specifies message_n, which is OPTIONAL to support. Whether message_n is used, and which values of n are sent and expected, is specified in the application profile; see .

Numbering and Ordering Each LAKE method defines a number of messages. Denote by N the highest message number defined for a given method, e.g., N = 4 for the methods defined in and ). An additional message is denoted message_n, for n > N. Additional messages MUST be numbered consecutively, starting with n = N + 1, and each value of n MUST be used at most once per LAKE session. Consistent with , the Initiator MUST send odd-numbered messages and the Responder MUST send even-numbered messages. Additional messages are exchanged in lockstep: a party MUST NOT send message_n until it has received and successfully processed message_(n-1). For methods where a message is optional, such as message_4 in methods 0 to 3 of , that message MUST be sent when message_n is used. In particular, when message_n is used with methods 0 to 3, the Responder MUST send message_4, and the first additional message is message_5, sent by the Initiator.

Formatting of message_n message_n SHALL be a CBOR Sequence (see ), as defined below. CIPHERTEXT_n is the encryption of PLAINTEXT_n (see ), which is a CBOR Sequence as defined below. where ead is an EAD item as defined in . The CDDL definitions used in this document are summarized in . The format is identical to that of message_4. As with message_4, the first CBOR data item of message_n is a byte string, which allows the receiver to distinguish message_n from a LAKE error message, whose first CBOR data item is an integer ().

Key Derivation K_n and IV_n are derived with the LAKE_Exporter defined in as follows: where:

• TBD1 is the exporter label registered with the description "message_n key" and TBD2 is the exporter label registered with the description "message_n IV"; see .
• context_n is the byte string containing the CBOR encoding of n as an unsigned integer (major type 0), e.g., h'05' for n = 5 and h'17' for n = 23.
• key_length and iv_length are the lengths of the encryption key and the initialization vector of the LAKE AEAD algorithm of the selected cipher suite, as defined in .

K_n and IV_n are bound to the LAKE session and the use of n as context makes them unique for each message_n within the session.

Sender Composition of message_n The sender SHALL compose message_n as follows:

• Derive K_n and IV_n as specified in .
• Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of , with the LAKE AEAD algorithm of the selected cipher suite, using the encryption key K_n, the initialization vector IV_n (if used by the AEAD algorithm), the plaintext PLAINTEXT_n, and the following parameters as input (see ):
  • protected = h''
  • external_aad = h''
  • PLAINTEXT_n = ( ? EAD_n ), as defined in
    • EAD_n is external authorization data; see and .
  CIPHERTEXT_n is the 'ciphertext' of COSE_Encrypt0.
• Encode message_n as a CBOR Sequence as specified in .

Receiver Processing of message_n The receiver SHALL process message_n as follows:

• Decode message_n (see ).
• Retrieve the protocol state using available message correlation (e.g., the CoAP Token, the 5-tuple, or a prepended connection identifier; see ), and determine the expected value of n from the protocol state.
• Derive K_n and IV_n as specified in .
• Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of , with the LAKE AEAD algorithm of the selected cipher suite and the parameters defined in .
• Make (if present) EAD_n available to the application for EAD processing.

If any processing step fails, then the receiver MUST send a LAKE error message back as defined in , and the LAKE session MUST be aborted; see .

External Authorization Data in message_n EAD_n follows the format and processing rules of , including the rules for critical and non-critical EAD items and the use of ead_label = 0 for padding (). The EAD_n field is a CBOR sequence of one or more EAD items. A specification of an EAD item that is intended to be used in message_n needs to specify in which message or messages the EAD item is used, e.g., "the first message_n sent by the Responder" or "message_6", and the processing at the sender and the receiver. EAD_n is protected between the authenticated Initiator and Responder, with confidentiality and integrity against active attackers.

Error Handling and Session Completion states that the LAKE session is completed after the last message (message_3 or message_4, depending on the application profile) has been successfully processed, after which no error messages are sent. When message_n is used, the LAKE session is instead completed after the last message_n specified by the application profile has been successfully processed, and error messages MAY be sent up to that point. When a LAKE session in which message_n is used is aborted, the endpoints MUST NOT persistently store PRK_out or derived keying material, and the application MUST be informed. Unless the application profile specifies otherwise, keying material derived with the LAKE_Exporter for the aborted session, including application keys already in use, SHOULD be discarded. Note that the abort of the session after a failed message_n cannot be signaled in a protected way. An on-path attacker can always drop the last message_n; see .

Retransmission and Deduplication Message deduplication follows . In particular, since K_n and IV_n are deterministic for a given LAKE session and n, an implementation MUST NOT regenerate message_n with a different PLAINTEXT_n. An endpoint that needs to retransmit message_n MUST resend the identical message_n, either by storing it or by deterministically regenerating identical plaintext. This is particularly important when EAD_n contains randomized content, such as non-deterministic signatures, nonces, or random padding. Since the receiver determines n from the protocol state, which advances after each successfully processed message, a retransmission of an already processed message would be processed with the wrong value of n and fail AEAD verification. An endpoint that does not rely on the transport for deduplication SHOULD therefore, before AEAD processing, check whether a received message is byte-identical to the last message it received in the LAKE session. If it is, the endpoint SHOULD resend its stored reply to that message, if any, or otherwise discard the duplicate, instead of processing it as a new message and aborting the session.

Transport message_n is transported in the same way as the handshake messages, as specified in the application profile. When LAKE is transported over CoAP as in , the following applies in the forward message flow, where the Initiator acts as CoAP client:

• message_n with odd n is sent in the payload of a POST request to the LAKE resource, prepended with the connection identifier C_R encoded as in , in the same way as message_3.
• message_n with even n is sent in the payload of the CoAP response to the request carrying message_(n-1), with the same Content-Format as message_4.

In the reverse message flow, where the Responder acts as CoAP client, the roles of requests and responses are swapped and the connection identifier C_I is prepended to messages sent in requests. The use of message_n with EAP is not specified in this document and is left to EAP method specifications.

Application Profile Considerations The application profile () is extended with the following information:

• Whether message_n is used, and if so, which values of n are allowed and expected, or how this is determined (e.g., by the EAD items in a previous message). From this it should be possible to derive the maximum value of n, see .
• The EAD items that can be present in each message_n. From this it should be possible to derive the maximum size of each message_n, see .
• Whether a failure to process a message_n invalidates keying material derived with the LAKE_Exporter that is already in use; see .

When message_n is used with methods 0 to 3 of , message_4 MUST be sent; see . message_n does not replace message_4, and the use of message_n does not otherwise change the requirements on message_4 in .

Security Considerations The security considerations of and apply. This section discusses additional considerations for message_n.

Key Separation K_n and IV_n are derived with the LAKE_Exporter using exporter labels dedicated to message_n and a context unique for each n. By the PRF security of LAKE_KDF, K_n is computationally independent of the keys for the handshake messages (including K_4), of IV_n, of other K_m with m != n, and of keying material derived with the LAKE_Exporter with other labels, such as the OSCORE Master Secret and Master Salt (). Compromise of keys derived with other exporter labels does not compromise K_n. Compromise of PRK_out or PRK_exporter compromises all K_n, as it does all other exporter output. The exporter labels TBD1 and TBD2 MUST NOT be used for any other purpose. In implementations where the LAKE_Exporter is exposed to application code that is less trusted than the LAKE implementation, for example when the LAKE implementation runs in a Trusted Execution Environment, any component able to invoke the LAKE_Exporter with label TBD1 can forge and decrypt message_n. Such implementations SHOULD restrict the use of labels TBD1 and TBD2 to the component implementing message_n.

Nonce Uniqueness Each (K_n, IV_n) pair MUST be used to encrypt at most one plaintext. This follows from the requirement that each value of n is used at most once per LAKE session (), and that retransmissions are identical (). Reusing a key and nonce with different plaintexts can compromise the confidentiality of both plaintexts and, for many AEAD algorithms, the integrity of all messages protected with that key.

Key Update The LAKE_KeyUpdate function () changes PRK_out and thereby PRK_exporter. To avoid the endpoints deriving different K_n, endpoints MUST NOT invoke LAKE_KeyUpdate before the LAKE session, including all message_n, is completed.

Replay, Reordering, Reflection, and Truncation Since K_n depends on PRK_out, which is unique per LAKE session, a message_n from one LAKE session cannot be replayed in another. Within a session, each message_n is protected with a distinct key and messages are processed in lockstep, so replayed, reordered, or reflected messages fail AEAD verification. Since the sender of message_n only sends it after having received and successfully processed message_(n-1), the successful verification of message_n also implies that the sender has received and accepted all previous messages in the session. message_n is not chained to the previous message_n via a transcript hash; external_aad is empty for all n. This is sufficient because each message_n is itself authenticated, its key is bound to the full handshake transcript, and the lockstep processing ensures that each message has been verified before the next is sent. Specifications of EAD items whose semantics depend on the content of several messages need to take into account that the binding between messages is provided by the lockstep processing and not by a hash chain. As for any protocol, an on-path attacker can drop the last message of the exchange. The sender of the last message_n does not learn whether it was received. Applications that need this assurance need to define a further message_n (e.g., an empty acknowledgement), and they need to take into account that the last message is always unacknowledged. When message_n is used as a protected success indication, the receiver MUST NOT consider the authentication successful before it has verified that message_n.

Authentication Strength As discussed in , the security of LAKE against online forgery attacks is given by the sum of the strength of the verified signatures and MACs, including the AEAD tags. Each verified message_n adds the strength of the AEAD tag of the LAKE AEAD algorithm to the authentication of its sender. For example, with cipher suite 2 and method 3, receiving message_5 in addition to message_3 gives the Responder 128-bit security against online attacks on the authentication of the Initiator.

Security of EAD in message_n The security considerations for EAD in apply. In contrast to EAD_1 and EAD_2, EAD_n is always sent after both endpoints have been authenticated and is protected against active attackers. Note that an EAD item in message_n is not covered by any signature in the handshake; its integrity relies on the AEAD protection with K_n. Applications that need non-repudiable or third-party verifiable statements, such as attestation Evidence, need to provide such protection within the EAD item itself. Designing a secure mechanism that uses EAD is not necessarily straightforward, and new uses of EAD in message_n should be subject to careful review.

Denial of Service and Resource Exhaustion message_n extends the lifetime of the LAKE protocol state, which an attacker that has completed the handshake could use to exhaust resources at the peer. The maximum value of n and the maximum size of each message_n SHOULD be limited by the application profile, and endpoints SHOULD apply timeouts to the exchange of message_n.

Privacy message_n is encrypted, but its length, timing, and number are visible to observers, and may reveal which use case or EAD items are in use. EAD padding () can be used in EAD_n to hide the length of the plaintext. An application concerned about traffic analysis can also use a fixed number of message_n regardless of the content.

IANA Considerations IANA is requested to register the following entries in the "LAKE Exporter Labels" registry within the "Lightweight Authenticated Key Exchange (LAKE)" registry group. The registry is defined in and renamed in . New LAKE Exporter Labels

Label	Description	Reference
TBD1	message_n key	This document
TBD2	message_n IV	This document

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. 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. 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. 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 describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. 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. Ericsson Ericsson 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. 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 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. 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. University of Oviedo University of Murcia Ericsson Ericsson University of Murcia The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. 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.

CDDL Definitions This section compiles the CDDL definitions for message_n for ease of reference. The definition of ead is copied from and the definition of context_n follows .

Acknowledgements The authors thank Jim Schaad for his work on COSE as well as his invaluable comments and feedback on CBOR, OSCORE, and LAKE; without him, this draft would not exist. This work was supported partially by Vinnova - the Swedish Agency for Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS.