Additional Messages in Lightweight Authenticated Key Exchange (LAKE)
draft-selma-lake-additional-messages-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Göran Selander , John Preuß Mattsson | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-selma-lake-additional-messages-00
Lightweight Authenticated Key Exchange G. Selander
Internet-Draft J. Preuß Mattsson
Updates: 9528 (if approved) Ericsson
Intended status: Standards Track 2 November 2026
Expires: 6 May 2027
Additional Messages in Lightweight Authenticated Key Exchange (LAKE)
draft-selma-lake-additional-messages-00
Abstract
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
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/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 1]
Internet-Draft Additional Messages in LAKE November 2026
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 Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification of message_n . . . . . . . . . . . . . . . . . 5
4.1. Numbering and Ordering . . . . . . . . . . . . . . . . . 5
4.2. Formatting of message_n . . . . . . . . . . . . . . . . . 6
4.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 6
4.4. Sender Composition of message_n . . . . . . . . . . . . . 7
4.5. Receiver Processing of message_n . . . . . . . . . . . . 7
4.6. External Authorization Data in message_n . . . . . . . . 8
4.7. Error Handling and Session Completion . . . . . . . . . . 8
4.8. Retransmission and Deduplication . . . . . . . . . . . . 9
4.9. Transport . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Application Profile Considerations . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Key Separation . . . . . . . . . . . . . . . . . . . . . 10
6.2. Nonce Uniqueness . . . . . . . . . . . . . . . . . . . . 11
6.3. Key Update . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Replay, Reordering, Reflection, and Truncation . . . . . 11
6.5. Authentication Strength . . . . . . . . . . . . . . . . . 12
Selander & Preuß Mattsson Expires 6 May 2027 [Page 2]
Internet-Draft Additional Messages in LAKE November 2026
6.6. Security of EAD in message_n . . . . . . . . . . . . . . 12
6.7. Denial of Service and Resource Exhaustion . . . . . . . . 12
6.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. CDDL Definitions . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
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
Selander & Preuß Mattsson Expires 6 May 2027 [Page 3]
Internet-Draft Additional Messages in LAKE November 2026
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].
2. 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 [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.
3. Protocol Overview
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.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 4]
Internet-Draft Additional Messages in LAKE November 2026
Initiator Responder
| METHOD, SUITES_I, G_X, C_I, EAD_1 |
+------------------------------------------------------------------>|
| 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 |
Figure 1: LAKE Message Flow with message_5 and 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.
4. 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 Section 5.
4.1. 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 [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.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 5]
Internet-Draft Additional Messages in LAKE November 2026
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.
4.2. Formatting of message_n
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]).
4.3. Key Derivation
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:
Selander & Preuß Mattsson Expires 6 May 2027 [Page 6]
Internet-Draft Additional Messages in LAKE November 2026
* 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.
4.4. Sender Composition of message_n
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
o 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.
4.5. Receiver Processing of message_n
The receiver SHALL process message_n as follows:
* Decode message_n (see Appendix C.1 of [RFC9528]).
Selander & Preuß Mattsson Expires 6 May 2027 [Page 7]
Internet-Draft Additional Messages in LAKE November 2026
* 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.
4.6. External Authorization Data in message_n
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.
4.7. Error Handling and Session Completion
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.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 8]
Internet-Draft Additional Messages in LAKE November 2026
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.
4.8. Retransmission and Deduplication
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.
4.9. 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 [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.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 9]
Internet-Draft Additional Messages in LAKE November 2026
* 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.
5. Application Profile Considerations
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].
6. Security Considerations
The security considerations of [RFC9528] and
[I-D.ietf-lake-edhoc-psk] apply. This section discusses additional
considerations for message_n.
6.1. 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
Selander & Preuß Mattsson Expires 6 May 2027 [Page 10]
Internet-Draft Additional Messages in LAKE November 2026
(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.
6.2. 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 (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.
6.3. Key Update
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.
6.4. 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
Selander & Preuß Mattsson Expires 6 May 2027 [Page 11]
Internet-Draft Additional Messages in LAKE November 2026
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.
6.5. Authentication Strength
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.
6.6. Security of EAD in message_n
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.
6.7. 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.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 12]
Internet-Draft Additional Messages in LAKE November 2026
6.8. 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 (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.
7. 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
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 |
+-------+---------------+---------------+
Table 1: New LAKE Exporter Labels
8. References
8.1. Normative References
[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
DOI 10.17487/RFC9528, March 2024,
<https://www.rfc-editor.org/info/rfc9528>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 13]
Internet-Draft Additional Messages in LAKE November 2026
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>.
[I-D.ietf-lake-edhoc-psk]
Lopez-Perez, Selander, G., Mattsson, J. P., Marin-Lopez,
R., and F. Lopez-Gomez, "LAKE Authenticated with Pre-
Shared Keys (PSKs)", Work in Progress, Internet-Draft,
draft-ietf-lake-edhoc-psk-10, 5 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lake-
edhoc-psk-10>.
[I-D.spm-lake-pqsuites]
Selander, G. and J. P. Mattsson, "Quantum-Resistant Cipher
Suites for EDHOC", Work in Progress, Internet-Draft,
draft-spm-lake-pqsuites-02, 19 April 2026,
<https://datatracker.ietf.org/doc/html/draft-spm-lake-
pqsuites-02>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 14]
Internet-Draft Additional Messages in LAKE November 2026
[I-D.ietf-emu-eap-edhoc]
Garcia-Carrillo, D., Marin-Lopez, R., Selander, G.,
Mattsson, J. P., and F. Lopez-Gomez, "Using the Extensible
Authentication Protocol (EAP) with Ephemeral Diffie-
Hellman over COSE (EDHOC)", Work in Progress, Internet-
Draft, draft-ietf-emu-eap-edhoc-12, 29 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
edhoc-12>.
[I-D.ietf-lake-authkem-edhoc]
Fraile, L. P., Koulamas, C., Fournaris, A., and E.
Haleplidis, "KEM-based Authentication for EDHOC", Work in
Progress, Internet-Draft, draft-ietf-lake-authkem-edhoc-
01, 28 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lake-
authkem-edhoc-01>.
Appendix A. CDDL Definitions
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
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.
Selander & Preuß Mattsson Expires 6 May 2027 [Page 15]
Internet-Draft Additional Messages in LAKE November 2026
Authors' Addresses
Göran Selander
Ericsson
Sweden
Email: goran.selander@ericsson.com
John Preuß Mattsson
Ericsson
Sweden
Email: john.mattsson@ericsson.com
Selander & Preuß Mattsson Expires 6 May 2027 [Page 16]