| Internet-Draft | Additional Messages in LAKE | November 2026 |
| Selander & Preuß Mattsson | Expires 6 May 2027 | [Page] |
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.¶
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-selma-lake-additional-messages/.¶
Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (mailto:lake@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lake/. Subscribe at https://www.ietf.org/mailman/listinfo/lake/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Lightweight Authenticated Key Exchange (LAKE) [RFC9528], 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 [RFC9528] 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 Section 3.8 of [RFC9528]), allowing external security applications to be integrated into LAKE without additional round trips. For these methods, the optional message_4 (Section 5.5 of [RFC9528]) 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 [I-D.ietf-emu-eap-edhoc]. The PSK-based method specified in [I-D.ietf-lake-edhoc-psk] 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 [I-D.ietf-lake-authkem-edhoc], where the Initiator needs a protected success indication when the method is used with EAP-LAKE [I-D.ietf-emu-eap-edhoc]. Using an application protocol such as OSCORE [RFC8613] 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 [RFC9528] and [I-D.ietf-lake-edhoc-psk]). message_n looks and works like message_4 in Section 5.5 of [RFC9528]. In contrast to message_4, for n >= 5, the key K_n and the initialization vector IV_n are derived with the LAKE_Exporter (Section 4.2.1 of [RFC9528]) 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 [RFC9528] by defining message_n for use with all LAKE methods, by requiring message_4 when message_n is used with the methods in [RFC9528] (Section 4.1), and by specifying when a LAKE session in which message_n is used is completed (Section 4.7). This document does not change the use of message_4 in [RFC9528] when message_n is not used and does not update [I-D.ietf-emu-eap-edhoc].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Readers are expected to be familiar with LAKE [RFC9528], CBOR [RFC8949], CBOR Sequences [RFC8742], COSE [RFC9052], and CDDL [RFC8610]. As in [RFC9528], CBOR always refers to deterministically encoded CBOR.¶
This document uses the terms, functions, and algorithm names defined in [RFC9528] with the protocol name replaced by LAKE, e.g., LAKE_Exporter, LAKE_KDF, LAKE_KeyUpdate, LAKE AEAD algorithm, and LAKE error message.¶
Figure 1 shows a LAKE message flow for methods 0 to 3 [RFC9528] 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 Section 4.1.¶
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.¶
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 Section 5.¶
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 [RFC9528] and [I-D.ietf-lake-edhoc-psk]).¶
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 Section 3.1 of [RFC9528], 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 [RFC9528], 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.¶
message_n SHALL be a CBOR Sequence (see Appendix C.1 of [RFC9528]), as defined below.¶
message_n = ( CIPHERTEXT_n : bstr, )¶
CIPHERTEXT_n is the encryption of PLAINTEXT_n (see Section 4.4), which is a CBOR Sequence as defined below.¶
PLAINTEXT_n = ( ? EAD_n, ) EAD_n = 1* ead¶
where ead is an EAD item as defined in Section 3.8 of [RFC9528]. The CDDL definitions used in this document are summarized in Appendix A.¶
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 (Section 6 of [RFC9528]).¶
K_n and IV_n are derived with the LAKE_Exporter defined in Section 4.2.1 of [RFC9528] as follows:¶
K_n = LAKE_Exporter( TBD1, context_n, key_length ) IV_n = LAKE_Exporter( TBD2, context_n, iv_length )¶
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 Section 7.¶
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 Section 4.1.2 of [RFC9528].¶
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.¶
The sender SHALL compose message_n as follows:¶
Derive K_n and IV_n as specified in Section 4.3.¶
Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of [RFC9052], 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 Appendix C.3 of [RFC9528]):¶
protected = h''¶
external_aad = h''¶
PLAINTEXT_n = ( ? EAD_n ), as defined in Section 4.2¶
EAD_n is external authorization data; see Section 3.8 of [RFC9528] and Section 4.6.¶
CIPHERTEXT_n is the 'ciphertext' of COSE_Encrypt0.¶
Encode message_n as a CBOR Sequence as specified in Section 4.2.¶
The receiver SHALL process message_n as follows:¶
Decode message_n (see Appendix C.1 of [RFC9528]).¶
Retrieve the protocol state using available message correlation (e.g., the CoAP Token, the 5-tuple, or a prepended connection identifier; see Section 3.4.1 of [RFC9528]), and determine the expected value of n from the protocol state.¶
Derive K_n and IV_n as specified in Section 4.3.¶
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of [RFC9052], with the LAKE AEAD algorithm of the selected cipher suite and the parameters defined in Section 4.4.¶
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 Section 6 of [RFC9528], and the LAKE session MUST be aborted; see Section 4.7.¶
EAD_n follows the format and processing rules of Section 3.8 of [RFC9528], including the rules for critical and non-critical EAD items and the use of ead_label = 0 for padding (Section 3.8.1 of [RFC9528]). 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.¶
Section 5.1 of [RFC9528] 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 Section 6.4.¶
Message deduplication follows Section 7 of [RFC9528]. 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.¶
message_n is transported in the same way as the handshake messages, as specified in the application profile.¶
When LAKE is transported over CoAP [RFC7252] as in Appendix A.2 of [RFC9528], 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 Section 3.3 of [RFC9528], 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.¶
The application profile (Section 3.9 of [RFC9528]) 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 Section 6.7.¶
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 Section 6.7.¶
Whether a failure to process a message_n invalidates keying material derived with the LAKE_Exporter that is already in use; see Section 4.7.¶
When message_n is used with methods 0 to 3 of [RFC9528], message_4 MUST be sent; see Section 4.1. message_n does not replace message_4, and the use of message_n does not otherwise change the requirements on message_4 in Section 5.5 of [RFC9528].¶
The security considerations of [RFC9528] and [I-D.ietf-lake-edhoc-psk] apply. This section discusses additional considerations for message_n.¶
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 (Appendix A.1 of [RFC9528]). 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.¶
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 (Section 4.1), and that retransmissions are identical (Section 4.8). 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.¶
The LAKE_KeyUpdate function (Appendix H of [RFC9528]) 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.¶
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.¶
As discussed in Section 9.1 of [RFC9528], 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.¶
The security considerations for EAD in Section 9.1 of [RFC9528] 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.¶
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.¶
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 (Section 3.8.1 of [RFC9528]) 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 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 Section 10.1 of [RFC9528] and renamed in [I-D.spm-lake-pqsuites].¶
| Label | Description | Reference |
|---|---|---|
| TBD1 | message_n key | This document |
| TBD2 | message_n IV | This document |
This section compiles the CDDL definitions for message_n for ease of reference. The definition of ead is copied from Appendix C.2 of [RFC9528] and the definition of context_n follows Section 4.3.¶
message_n = ( CIPHERTEXT_n : bstr, ) PLAINTEXT_n = ( ? EAD_n, ) EAD_n = 1* ead ead = ( ead_label : int, ? ead_value : bstr, ) context_n = bstr .cbor uint¶
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.¶