Hybrid KEM/Signature-Based Methods for Scenarios with Asymmetric Device Constraints
draft-pocero-lake-authkemsig-edhoc-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 | Lidia Pocero Fraile , Christos Koulamas , Apostolos P. Fournaris , Evangelos Haleplidis | ||
| Last updated | 2026-05-22 | ||
| 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-pocero-lake-authkemsig-edhoc-00
individual L. Pocero Fraile
Internet-Draft C. Koulamas
Intended status: Standards Track A.P. Fournaris
Expires: 23 November 2026 E. Haleplidis
ISI, R.C. ATHENA
22 May 2026
Hybrid KEM/Signature-Based Methods for Scenarios with Asymmetric Device
Constraints
draft-pocero-lake-authkemsig-edhoc-00
Abstract
This document extends the KEM-based Authentication for EDHOC draft
[I-D.pocero-lake-authkem-edhoc] by defining additional quantum-
resistant authentication methods that support combined authentication
approaches, where one party authenticates using a KEM-based mechanism
and the other using a post-quantum signature scheme.
Status of This Memo
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 23 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pocero Fraile, et al. Expires 23 November 2026 [Page 1]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
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
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology and Requirements Language . . . . . . . . . . 4
1.2.1. Key Encapsulation Mechanisms (KEMs) . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Protocol Elements . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Ephemeral KEM . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Method . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Authentication Parameters . . . . . . . . . . . . . . 9
2.1.3.1. Authentication Keys . . . . . . . . . . . . . . . 9
2.1.3.2. Authentication Credentials . . . . . . . . . . . 10
2.1.3.3. Identification of Credentials . . . . . . . . . . 10
2.1.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . 10
2.1.5. Transport . . . . . . . . . . . . . . . . . . . . . . 11
3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Keys for EDHOC Message Processing . . . . . . . . . . . . 12
3.1.1. EDHOC_Extract . . . . . . . . . . . . . . . . . . . . 13
3.1.1.1. PRK_2e . . . . . . . . . . . . . . . . . . . . . 13
3.1.1.2. PRK_3e2m . . . . . . . . . . . . . . . . . . . . 13
3.1.1.3. PRK_4e3m . . . . . . . . . . . . . . . . . . . . 13
3.1.2. EDHOC_Expand and EDHOC_KDF . . . . . . . . . . . . . 14
3.1.3. PRK_out . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Keys for EDHOC Applications . . . . . . . . . . . . . . . 14
4. Message Formatting and Processing . . . . . . . . . . . . . . 14
4.1. KEM-based Authentication EDHOC Message 1 . . . . . . . . 14
4.1.1. Formating of Message 1 . . . . . . . . . . . . . . . 15
4.1.2. Initiator Composition of Message 1 . . . . . . . . . 15
4.1.3. Responder Processing of Message 1 . . . . . . . . . . 15
4.2. KEM-based authentication EDHOC Message 2 . . . . . . . . 16
4.2.1. Formating of Message 2 . . . . . . . . . . . . . . . 16
4.2.2. Responder Composition of Message 2 . . . . . . . . . 16
4.2.3. Initiator Processing of Message 2 . . . . . . . . . . 17
4.3. KEM-based authentication EDHOC Message 3 . . . . . . . . 18
4.3.1. Formating of Message 3 . . . . . . . . . . . . . . . 18
4.3.2. Initiator Composition of Message 3 . . . . . . . . . 19
4.3.3. Responder Processing of Message 3 . . . . . . . . . . 20
4.4. KEM-based authentication EDHOC Message 4 . . . . . . . . 21
Pocero Fraile, et al. Expires 23 November 2026 [Page 2]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
4.4.1. Formating of Message 4 . . . . . . . . . . . . . . . 21
4.4.2. Responder Composition of Message 4 . . . . . . . . . 21
4.4.3. Initaitor Processing of Message 4 . . . . . . . . . . 23
4.5. KEM-based authentication EDHOC Message 5 . . . . . . . . 24
4.5.1. Formating of Message 5 . . . . . . . . . . . . . . . 24
4.5.2. Initiator Composition of Message 5 . . . . . . . . . 24
4.5.3. Responder Processing of Message 5 . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
5.1. EDHOC Method Types Registry . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Early Authentication Approach for Combined PQC KEM and
Signature Authentication Methods . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
The purpose of this document is to extend the quantum-resistant (QR)
authentication methods defined in [I-D.pocero-lake-authkem-edhoc],
which provide PQC KEM-based signature-free authentication for both
the Initiator and the Responder, with two additional methods that
support combined authentication variants, where one party uses PQC
KEM-based authentication and the other uses PQC signature-based
authentication. The additional authentication methods 6 and 7
proposed in this document directly address the post-quantum
transition of the remaining methods 1 and 2 from the Ephemeral
Diffie-Hellman Over COSE (EDHOC) protocol [RFC9528], which are still
potentially vulnerable to attacks from Cryptographically Relevant
Quantum Computers (CRQCs). Together with the methods defined in
[I-D.pocero-lake-authkem-edhoc], they complete the quantum-resistant
versions of all authentication methods defined in [RFC9528].
This document defines the resulting protocol that integrates the
three QR authentication approaches: the KEM-based/KEM-based methods
defined in [I-D.pocero-lake-authkem-edhoc], where both the Initiator
and the Responder use KEM-based authentication, and the two new
combined variants, KEM-based/signature-based and signature-based/KEM-
based, where the Initiator and the Responder use different
authentication types. Together, these methods enable flexible post-
quantum authentication options while maintaining the security
properties of the original EDHOC design.
The specification defined in the body of this document follows the
simplest approach for extending the combined authentication variants,
in which the five-message handshake is maintained and authentication
is performed in the last two messages, as in the both-parties KEM-
Pocero Fraile, et al. Expires 23 November 2026 [Page 3]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
based authentication methods defined in
[I-D.pocero-lake-authkem-edhoc]. A more complex approach, which
prioritizes authentication as early as possible, is presented in
Appendix A to provide a discussion of alternative strategies and
their relative advantages.
The specified protocol is part of a broader analysis of the post-
quantum transition for EDHOC [PQ-EDHOC-Access25].
1.1. Motivation
TO DO: Asymetric constrains devices participate on the handshake.
Add anlysis on PQ algorithms as falcon
1.2. Terminology and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Readers are expected to be familiar with the terms and concepts
described in EDHOC [RFC9528], CBOR [RFC8949], CBOR Sequences
[RFC8742], COSE Structures and Processing [RFC9052] and COSE
Algorithms [RFC9053], When referring to CBOR, this specification
always refers to Deterministically Encoded CBOR, as specified in
Section 4.2.1 and 4.2.2 of [RFC8949]. The single output from
authenticated encryption (including the authentication tag) is called
"ciphertext", following [RFC5116].
TO DO: add subsection for Signatures?
1.2.1. Key Encapsulation Mechanisms (KEMs)
The Key Encapsulation Mechanism consists of 3 algorithms:
* *( pk, sk ) <- KEM.KeyGen( )*: The probabilistic key generation
algorithm generates a KEM key pair consisting of a public
encapsulation key ( pk ) and secret decapsulation key ( sk ).
* *( ss , ct ) <- KEM.Encapsulate( pk )*: The probabilistic
encapsulation algorithm takes as input a public encapsulation key
( pk ) and produces a shared secret ( ss ) and ciphertext ( ct ).
* *( ss ) <- KEM.Decapsulate( ct, sk )*: The decapsulation algorithm
takes as input a secret encacpsulation key ( sk ) and produce a
shared secret ( ss ).
Pocero Fraile, et al. Expires 23 November 2026 [Page 4]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
2. Protocol Overview
The KEM-based authentication in EDHOC is extended by defining three
new authentication methods: method 5, in which both parties use KEM-
based authentication; method 6, in which the Initiator employs KEM-
based authentication and the Responder uses a PQC signature scheme;
and method 7, in which the Initiator uses a PQC signature scheme and
the Responder employs KEM-based authentication. To extend KEM-based
authentication to support all this combinations of Initiator and
Responder authentication, a message-flow-preserving approach is
applied and specify in this document. This approach provides a
unified message flow, maintaining the same number of messages for all
KEM-based authentication method keeping a uniform message structure
across them. A second aproach, which prioritizes authenticating a
party as soon as it become possible is describe in Appendix A
highlighting its advantage and disadvantages compared with the
approach presented here.
All three new methods extending KEM-based authentication in EDHOC
consist of five mandatory messages (message_1, message_2, message_3,
message_4, and message_5). Figure 1 illustrates the EDHOC message
flow for these three methods, as well as the content of each message.
An error message may also be exchanged between the Initiator (I) and
the Responder (R). Error handling and cipher suit negotiation
mechanisms are the same as defined in Section 6 of [RFC9528]. All
EDHOC messages are CBOR Sequences as specified in [RFC9528]. The
protocol elements are introduced in this Section and in Section 4.
Message formatting and processing are specified in Section 4.
Pocero Fraile, et al. Expires 23 November 2026 [Page 5]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
Initiator Responder
| METHOD, SUITES_I, pk_eph, C_I, EAD_1 |
+------------------------------------------------------------------->
| message_1 |
| |
| ct_eph, Enc( C_R, ID_CRED_R, EAD_2 ) |
<-------------------------------------------------------------------+
| message_2 |
| |
| AEAD( ID_CRED_I, EAD_3 ), ct_R? |
+------------------------------------------------------------------->
| message_3 |
| |
| AEAD( EAD_4, Sig_R_or_MAC_2 ), ct_I? |
<-------------------------------------------------------------------+
| message_4 |
| |
| AEAD( EAD_5, Sig_I_or_MAC_3 ) |
+------------------------------------------------------------------->
| message_5 |
Figure 1: EDHOC Message Flow
The parties exchange ephemeral keys from a PQC KEM and static public
keys, either from the same PQC KEM as the ephemeral keys or from a
PQC digital signature scheme, depending on the selected method, along
with ciphertexts encapsulating these keys. They then compute shared
secrets and pseudorandom keys (PRK), from which symmetric session
keys are derived to encrypt elements in the intermediate handshake
messages. All handshake messages include encrypted components
protected with these derived session keys, offering varying levels of
confidentiality and authenticity, except for the first message, which
is sent in plaintext.
The parties compute a shared secret session key, PRK_out, from which
symmetric application keys are derived to protect application data.
The Initiator derives these keys after receiving message_4, and the
Responder after receiving message_5.
* pk_eph is the ephemeral KEM public key generated by the Initiator.
* ct_eph is the ephemeral ciphertext computed by the Responder with
the KEM.encapsulation algorithm over the received ephemeral public
key (pk_eph).
Pocero Fraile, et al. Expires 23 November 2026 [Page 6]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
* ct_R is the responder ciphertext computed by the Initiator with
the KEM.encapsulation algorithm over the static KEM public key of
the Responder, retrieved from the received ID_CRED_R in message_2.
This value is used in authentication Methods 4 and 6, where the
Responder employs KEM-based authentication.
* ct_I is the Iniatiator ciphertext computed by the Responder with
the KEM.encapsulation algorithm over the static KEM public key of
the Initiator, retrieved from the received ID_CRED_I in message_1.
This value is used in authentication Methods 4 and 5, where the
Initiator employs KEM-based authentication.
* "CRED_I and CRED_R are the authentication credentials containing
the public authentication keys of I and R, respectively", as
defined in Section 2 of [RFC9528].
* "ID_CRED_I and ID_CRED_R are used to identify and optionally
transport the credentials of I and R, respectively", as defined in
Section 2 of [RFC9528].
* Sig_I and Sig_R denote signatures made with the private
authentication key from a PQC digital signature algorithm selected
of I and R, respectively. Sig_I is used when the Initiator
employs PQC signature-based authentication in the method 6, and
Sig_R is used when the Responder employs PQC signature-based
authentication in the method 5.
* "Enc(), AEAD(), and MAC() denote encryption, Authenticated
Encryption with Associated Data, and Message Authentication Code,
crypto algorithms applied with keys derived from one or more
shared secrets calculated during the protocol", as defined in
Section 2 of [RFC9528].
* "SUITES_I contains cipher suites supported by the Initiator and
formatted and processed as specified in Section 3.6 and 6.3.2 of
[RFC9528]".
* "METHOD is an integer specifying the authentication method",as
defined in Section 3.2 of [RFC9528]. In this case method 4 5 or
6; see Section 2.1.2.
* C_I and C_R are Connection Identifiers chosen by the Initiator and
Responder, respectively, as specified in Section 3.3 of [RFC9528]
.
* EAD_1, EAD_2, EAD_3, EAD_4, EAD_5 are External Authorization Data
included in message_1, message_2, message_3, message_4 and
message_5 respectively.
Pocero Fraile, et al. Expires 23 November 2026 [Page 7]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
This protocol is designed so that it follows the provisions of
[RFC9528], that is, to encrypt and integrity protect as much
information as possible and derive symmetric keys and random material
using EDHOC_KDF with as much previous information as possible
2.1. Protocol Elements
This section describes the principal protocol elements that differ
from the definitions of EDHOC [RFC9528] and
[I-D.pocero-lake-authkem-edhoc], and highlights the most important
similarities. For the missing elements, the definitions in Section 3
of [RFC9528] SHOULD be consulted.
2.1.1. Ephemeral KEM
The ephemeral KEM provides forward secrecy for the three
authentication methods (Methods 4, 5, and 6) described in this
document, for both the mutual KEM-based authentication method and the
combined authentication variants. The Initiator generates a new
ephemeral KEM key pair in every new session to ensure that the
compromise of long-term keys does not compromise past communications.
The elements of the Ephemeral KEM are defined in Section 2.1.1 of
[I-D.pocero-lake-authkem-edhoc]:
2.1.2. Method
The protocol extends EDHOC by integrating Method 5 defined in
[I-D.pocero-lake-authkem-edhoc], where both parties use static KEM
key pairs, together with Methods 6 and 7, which correspond to
combined authentication modes where one party uses a static KEM key
pair and the other uses a PQC signature scheme. The Initiator and
Responder must agree on the authentication method to be used. The
selected method is indicated by the Initiator in message_1.
+===================+====================+====================+
| Method Type Value | Initiator | Responder |
| | Authentication Key | Authentication Key |
+===================+====================+====================+
| 6 | Static KEM Key | PQC Signature |
+-------------------+--------------------+--------------------+
| 7 | PQC Signature | Static KEM Key |
+-------------------+--------------------+--------------------+
Table 1: Authentication Keys for Method Types
Pocero Fraile, et al. Expires 23 November 2026 [Page 8]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
2.1.3. Authentication Parameters
The protocol performs the same authentication-related operations as
described in Section 3.5 of [RFC9528]
The protocol transports information about credentials ID_CRED_I and
ID_CRED_R in message_2 and message_3, respectively. The
authentication of these credentials is verified through
Sig_R_or_MAC_2 and Sig_I_or_MAC_3, sent by the Responder and the
Initiator in message_4 and message_5, respectively.
* If the Responder uses KEM-based authentication (methods 5 or 7),
it sends MAC_2. If it authenticates using a PQC signature key
(method 6), it sends a signature over MAC_2 using the PQC
algorithm selected on the cipher suit.
* Similarly, if the Initiator uses KEM-based authentication (methods
5 or 6), it sends MAC_3. If it authenticates with a PQC signature
key (method 7), it sends a signature over MAC_3 using the PQC
signature algorithm selected on the cipher suit
2.1.3.1. Authentication Keys
The authentication key MUST be a static KEM authentication key or a
PQC signature key. The Initiator and Responder use KEM
authentication keys with method 5, and different types of
authentication keys with methods 6 and 7.
The authentication key algorithm must be compatible with the chosen
method and selected cipher suite. When either party uses KEM-based
authentication, the same KEM algorithm selected for the EDHOC key
exchange in the cipher suite MUST be used for both the ephemeral KEM
key exchange and the authentication static KEM keys. When using
static KEM keys, the Initiator’s and Responder’s private and public
authentication keys are denoted as follows:
* The Initiator static KEM authentication key pair: ( pk_I, sk_I )
* The Responder static KEM authentication key pair: ( pk_R, sk_R )
When PQC signature authentication is used, the authentication key
algorithm MUST be compatible with the EDHOC signature algorithm
selected in the cipher suite.
Pocero Fraile, et al. Expires 23 November 2026 [Page 9]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
2.1.3.2. Authentication Credentials
The authentication credentials, CRED_I and CRED_R, contain the
authentication public key of the Initiator and Responder,
respectively, as described in Section 3.5.2 of [RFC9528].
* The authentication credentials can be X.509 certificates seconded
as bstr, as defined in Section 3.5.2 of [RFC9528], using
[RFC9360]. When static KEM authentication keys are used,
[I-D.ietf-lamps-kyber-certificates] specifies the conventions for
using ML-KEM within X.509 Public Key Infrastructure (PKI).
* Additionally, the authentication credential may include a
COSE_key, formatted as specified in [RFC8392], to reduce the
credential size and avoid the PQC signature verification needed
when X.509 certificates are used. New IANA value registries
should be defined to extend COSE Algorithms with the corresponding
KEMs algorithm values.
* TO DO: add PQC signature refereces
2.1.3.3. Identification of Credentials
The ID_CRED fields are used to identify and optionally transport
credentials as defined in Section 3.5.3 of [RFC9528].
2.1.4. Cipher Suites
The authentication method specified in this document uses the EDHOC
cipher suites element, as defined in Section 3.6 of [RFC9528]. An
EDHOC cipher suit consists of an ordered set of algorithms from the
"COSE Algorithms" IANA registry [RFC9053]. The predefined EDHOC
cipher suites are also listed in the IANA registry, as specified in
Section 10.2 of [RFC9528].
A new predefined cipher suite SHOULD be added to the IANA registry,
specifying the supported KEM in the EDHOC Key Exchange Algorithm
parameter and the PQC signature algorithm in the EDHOC signature
algorithm parameter, as specified in Section 5.2 of
[I-D.spm-lake-pqsuites]. An example of this, when ML-KEM is used, is
shown in Section 5. The same KEM algorithm selected for key exchange
SHOULD also be used for KEM-based authentication when methods 5, 6 or
7 are selected. Furthermore, the KEM algorithms used SHOULD also be
added to the COSE Algorithms IANA registry to identify them, as is
shown in Section 5.
Pocero Fraile, et al. Expires 23 November 2026 [Page 10]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
2.1.5. Transport
Same consoderations regarding the larger message sizes MAY
necessitate transport support for fragmentation than the defined in
Section 2.1.5 of [I-D.pocero-lake-authkem-edhoc].
3. Key Derivation
This section highlights the differences and similarities in the key
derivation process when KEM-based authentication is used to
authenticate the Initiator (method 6), the Responder (method 7), or
both (method 5), compared to [RFC9528]. An overview of the EDHOC key
schedule for KEM-based authentication methods 5, 6, or 7 is shown in
Figure 2, and each key derivation step is explained in the following
subsections.
+-------+
| TH_2 |
+-------+
|
+----+ +--v+ +------+ +------+ +-----+ +-+ +---+
|ss_e|->|Ext|->|PRK_2e|--|Expand|->|KEY_2|--->| |->|C_2|
+----+ +---+ +--+---+ +--+---+ +-----+ |X| +---+
| | PLAINTEXT_2-->| |
+-----+ | +-+
T+---|R use| |
| |KEM ?| |
| +-----+ |
| F| +--+----------------------+
| | |TH_2=H(H(Message1),ct_eph|
| | +-------------------------+
| |
+----+ +--++ +--v-----+ +------+ +---+ +----+ +---+
|ss_R|->|Ext|->|PRK_3e2m|+-|Expand|->|K_3|->|AEAD|->|C_3|
+----+ +---+ +----+---+ |+--+---+ +---+ +----+ +---+
| | | |
| | | PLAINTEXT_3
+----++ | |
T+---|I use| | |
| |KEM ?| | |
| +--+--+ | |
| | F | +-+---------------------+
| | | |TH_3= |
| | | | H(TH_2,PLAINTEXT_2, |
| | | | CRED_R,ct_R?) |
| | | +-----------------------+
| | |
Pocero Fraile, et al. Expires 23 November 2026 [Page 11]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
| | | +------+ +-----+
| | +--|Expand|->|MAC_2|
| | +-+----+ +-----+
| | |
| | +---------------+---------------------+
| | |TH_4=H(TH_3,PLAINTEXT_3,CRED_I,ct_I?)|
| | +------------------+------------------+
| | |
+----+ +--+-+ +-v------+ +-+----+ +---+ +----+ +---+
|ss_I|->|Ext |->|PRK_4e3m|+-|Expand|->|K_4|->|AEAD|->|C_4|
+----+ +----+ +--------+| +------+ |+---+ |+--^-+ +---+
| | | |
| | | PLAINTEXT_4
| | |+----+ +---+
| | -|AEAD|->|C_5|
+------------------------+| | +-^--+ +---+
|TH_5=H(TH_4,PLAINTEXT_4)|| | |
+--+---------------------+| | PLAINTEXT_5
| | |
+-----+ +-+----+ | |
|MAC_3|<--|Expand|--| |
+-----+ +------+ | +-------+
|-->|PRK_out|
+--+----+
|
+--v---+
|Expand|
+------+
|
v
+------------+
|PRK_exporter|
+---+--------+
|
+--v---+
|Expand|
+--+---+
|
v
Aplication Key
Figure 2: EDHOC Message Key Derivation using the KEM-based
Authentication Methods 5, 6 or 7
3.1. Keys for EDHOC Message Processing
Pocero Fraile, et al. Expires 23 November 2026 [Page 12]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
3.1.1. EDHOC_Extract
The pseudorandom keys (PRKs) used for KEM-based authentication
methods are derived using the same EDHOC_Extract function defined in
[RFC9528], where the input keying material (IKM) and Salt are
specified for each PRK below.
3.1.1.1. PRK_2e
The pseudorandom key PRK_2e is derived as defined in Section 3.1.1.1
of [I-D.pocero-lake-authkem-edhoc]
3.1.1.2. PRK_3e2m
If the Responder authenticates using static KEM keys, the
pseudorandom key PRK_3e2m is derived using the following input:
* The salt SHALL be the SALT_3e2m derived from PRK_2e
* The IKM SHALL be the KEM shared secret ss_R, used to authenticate
the Responder
PRk_3e2m is derived as follows:
PRK_3e2m = EDHOC_Extract( SALT_3e2m, ss_R )
Where the KEM shared secret ss_R used to authenticate the Responder
is the output of the following functions in the Initiator and
Responder, respectively
Initiator:
ss_R, ct_R <- KEM.Encapsulate( pk_R )
Responder:
ss_R <- KEM.Decapsulate( ct_R, sk_R )
Else, if the Responder authenticates using a PQC signature algorithm,
then PRK_3e2m SHALL be set equal to PRK_2e (PRK_3e2m = PRK_2e).
3.1.1.3. PRK_4e3m
If the Initiator authenticates using static KEM keys, the
pseudorandom key PRK_4e3m is derived using the following input:
* The salt SHALL be the SALT_4e3m, derived from PRK_3e2m
Pocero Fraile, et al. Expires 23 November 2026 [Page 13]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
* The IKM SHALL be the KEM shared secret ss_I, used to authenticate
the Initiator
PRk_4e3m is derived as follows:
PRK_4e3m = EDHOC_Extract( SALT_4e3m, ss_I )
Where the KEM shared secret ss_I used to authenticate the Initiator
is the output of the following functions in the Initiator and
Responder, respectively
Initiator:
ss_I <- KEM.Decapsulate( ct_I, sk_I )
Responder:
ss_I, ct_I <- KEM.Encapsulate( pk_I )
Else, if the Initiator authenticates using a PQC signature algorithm,
then PRK_4e3m SHALL be set equal to PRK_3e2m (PRK_4e3m = PRK_3e2m).
3.1.2. EDHOC_Expand and EDHOC_KDF
The same output key materials (OKMs) are derived from the PRKs as
defined in Section 3.1.2 of [I-D.pocero-lake-authkem-edhoc].
3.1.3. PRK_out
The pseudorandom key PRK_out is the output session key of a completed
EDHOC session and is derived as is Section 3.1.3 of
[I-D.pocero-lake-authkem-edhoc]
3.2. Keys for EDHOC Applications
Keying material for the application can be derived using the same
EDHOC_Exporter interface defined in Section 4.2.1 of [RFC9528]
4. Message Formatting and Processing
This section outlines the message format and the procedures for
composing and processing each message.
4.1. KEM-based Authentication EDHOC Message 1
Pocero Fraile, et al. Expires 23 November 2026 [Page 14]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
4.1.1. Formating of Message 1
message_1 retains the same format as defined in Section 5.2.1 of
[RFC9528]. The same fields are used, except that GX is replaced by
the KEM ephemeral public key ( pk_eph ) computed by the Initiator.
message_1 = (
METHOD : int,
SUITES_I : suites,
pk_eph : bstr,
C_I : bstr / -24..23,
? EAD_1,
)
suites = [ 2* int ] / int
EAD_1 = 1* ead
The selected authentication method (methods 5, 6 or 7) SHOULD be
indicated in the METHOD field.
4.1.2. Initiator Composition of Message 1
The Initiator SHALL compose message_1 as follows:
* Construct SUITES_I following the Section 5.2.2 of [RFC9528]
specifications
* Generate an ephemeral KEM Key pair (pk_eph) using the KEM
algorithm from the selected cipher suit. The ephemeral key pair
is computed by the Initiator using the following function:
pk_eph, sk_eph <- KEM.KeyGen()
* Choose a conection identifier as in Section 5.2.2 of [RFC9528].
* Encode message_1 as sequence of CBOR-encoded elements, as
specified in Section 4.1.1
4.1.3. Responder Processing of Message 1
The Responder SHALL process message_1 in the following order:
1. "Decode message_1", as specified in Section 5.2.3 of [RFC9528]
2. "Process message_1", as specify in Section 5.2.3 of [RFC9528]
Pocero Fraile, et al. Expires 23 November 2026 [Page 15]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
3. "If all processing is completed successfully, and if EAD_1 is
present, then make it available to the application", as specified
in Section 5.2.3 of [RFC9528]
4.2. KEM-based authentication EDHOC Message 2
4.2.1. Formating of Message 2
message_2 keeps the same formatting as Section 5.3.1 of [RFC9528].
The same fields are used instead GY is replaced with the ephemeral
KEM ciphertext ( ct_eph ) computed on the Responder.
message_2 = (
ct_eph_CIPHERTEXT_2 : bstr,
)
where cc_eph_CIPHERTEXT_2 is the concatenation of ct_eph and
CIPHERTEXT_2.
4.2.2. Responder Composition of Message 2
The Responder SHALL compose message_2 as follows:
* Encapsulate the ephemeral KEM key received within message_1 using
the KEM algorithm in the selected cipher suit. The ephemeral KEM
ciphertext and the KEM ephemeral shared secret are computed by the
Responder using the following function:
ss_eph, ct_eph <- KEM.Encapsulate(pk_eph)
* Compute the transcript hash TH_2 = H(pk_eph,H(message_1)) as
specified in Section 5.3.2 of [RFC9528]
* Compute the PRK_2e pseudorandom key from the ephemeral KEM shared
secret ( ss_eph )
* "Choose a connection identifier C_R", as specified in
Section 5.3.2 of [RFC9528]
* At this point, when the Responder use KEM-based authentication, is
not jet able to authenticate itself; therfore MAC_2 is not
computed. Although the Responder could, in principle,
authenticate itself at this stage when using PQC signature-based
authentication, the message-flow-preserving approach restricts
Responder authentication to message_4. A corresponding message
flow that enables a party to authenticate as soon as it becomes
possible is shown in Appendix A
Pocero Fraile, et al. Expires 23 November 2026 [Page 16]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
* CIPHERTEXT_2 is calculated, with a binary additive stream cipher
as in Section 5.3.2 of [RFC9528], using a keystream (KEYSTREAM_2)
generated with EDHOC_Expand and the following plaintext:
- Compute PLAINTEXT_2 as:
PLAINTEXT_2 = (C_R,ID_CRED_R,?EAD_2)
where C_R, ID_CRED_R and EAD_2 elements corresponds with the
ones in Section 5.3.2 of [RFC9528].
- Compute KEYSTREAM_2 as in Section 3.1.2
- Compute CIPHERTEXT_2 as in Section 5.3.2 of [RFC9528]
CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2
* Encode message_2 as a sequence of CBOR-encoded data items as
specified in Section 4.2.1
4.2.3. Initiator Processing of Message 2
The Initiator SHALL process message_2 in the following order:
1. Decode message_2
2. "Retrieve the protocol state" as proposed in Section 5.3.3 of
[RFC9528]
3. Compute the ephemeral KEM shared_secret ( ss_eph ) by
decapsulating the KEM ciphertext ( ct_eph ) received in
message_2 using the ephemeral secret key ( sk_eph ). The
ephemeral KEM shared secret is computed by the Initiator using
the following function:
ss_eph <- KEM.Decapsulate( ct_eph, sk_eph )
4. Compute the transcript hash TH_2 = H(pk_eph,H(message_1))
5. Compute the PRK_2e pseudorandom key from the ephemeral KEM
shared secret ( ss_eph )
6. Derive KEYSTREAM_2 as in Section 3.1.2
7. Decrypt CIPHERTEXT_2; see Section 4.2.2
Pocero Fraile, et al. Expires 23 November 2026 [Page 17]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
8. If all processing is completed successfully, ID_CRED_R and (if
present) EAD_2 SHALL be made available to the application, as
specified in Section 5.3.3 of [RFC9528]. In this specification,
the application MUST authenticate and validate the credentials
associated with ID_CRED_R at this point before proceeding. The
Initiator’s credentials are transmitted in the subsequent
message and are encrypted under a key that can only be derived
by a party possessing the private key corresponding to
ID_CRED_R. Prior to sending its credentials, the Initiator MUST
ensure that the credentials associated with ID_CRED_R have been
successfully validated and accepted according to local policy.
This prevents disclosure of the Initiator’s credentials to a
party presenting credentials that are cryptographically valid
but untrusted or unintended.
9. Obtain the authentication credential (CRED_R) from the
(ID_CRED_R) as in Section 5.3.3 of [RFC9528], and the static
authentication key of the Responder
10. If the Responder use KEM-based authentication (methods equal 5
or 7) then the Initiator MUST perform the following steps:
* Encapsulate the retrieved static KEM authentication key of
the Responder ( pk_R ) calculating the corresponding
ciphertext ( ct_R ) and shared secret ( ss_R ) with the
following function:
ss_R, ct_R <- KEM.Encapsulate(pk_R)
* Compute the new PRK_3e2m from a chain that includes both the
ephemeral KEM shared secret ( ss_eph ) and the latest KEM
shared secret for the Authentication of the Responder ( ss_R
), as defined in Section 3.1.1.2
Else, if the Responder authenticates using a PQC signature
algorithm (method 6), then PRK_3e2m SHALL be set equal to PRK_2e
(PRK_3e2m = PRK_2e).
4.3. KEM-based authentication EDHOC Message 3
4.3.1. Formating of Message 3
message_3 SHALL be a CBOR Sequence as defined below:
message_3 = (
CIPHERTEXT_3 : bstr,
? ct_R : bstr,
)
Pocero Fraile, et al. Expires 23 November 2026 [Page 18]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
4.3.2. Initiator Composition of Message 3
The Initiator SHALL process the composition of message_3 as follows:
* Compute the transcript hash TH_3=H(TH_2,PLAINTEXT_2,CRED_R,? ct_R)
as specified in Section 5.4.2 of [RFC9528]. The element ( ct_R )
SHALL be present only when the Responder use KEM-based
authentication (methods 4 and 6); otherwise it SHALL be ommited.
* Derive the new session key K_3/IV_3 as defined in Section 3.1.2.
The Initiator can use this key to compute CIPHERTEXT_3, but it
cannot be used to authenticate itself.
* At this point, when the Initiator use KEM-based authentication, is
not jet able to authenticate itself; therfore MAC_3 is not
computed. Although the Initiator could, in principle,
authenticate itself at this stage when using PQC signature-based
authentication, the message-flow-preserving approach restricts
Responder authentication to message_5. A corresponding message
flow that enables a party to authenticate as soon as it becomes
possible is shown in Appendix A
* Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
suite, using the encryption key K_3, the initialization vector
IV_3 (if used by the AEAD algorithm), the plaintext PLAINTEXT_3,
and the following parameters as input:
- protected = h''
- external_aad = TH_3
- K_3 and IV_3 are defined in Section 3.1.2
- PLAINTEXT_3 = (C_I,ID_CRED_I,?EAD_3) where C_I, ID_CRED_I and
EAD_3 elements corresponds with the ones in Section 5.3.3 of
[RFC9528]
CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.
* Encode message_3 as a CBOR data item as specified in
Section 4.3.1. The element ( ct_R ) SHALL be present only when
the Responder use KEM-based authentication (methods 4 and 6);
otherwise it SHALL be ommited. When the Responder use PQC
Signature algorithms (method 5) message_3 consists of a single
element (CIPHERTEXT_3). ( ct_R ) is defined as the trailing
element so it can be omitted when not used; therefore, senders
MUST NOT encode ct_R as NULL.
Pocero Fraile, et al. Expires 23 November 2026 [Page 19]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
4.3.3. Responder Processing of Message 3
The Responder SHALL process message_3 in the following order:
1. Decode message_3
2. "Retrieve the protocol state", as defined in Section 5.4.3 of
[RFC9528]
3. If the Responder use KEM-based authentication (methods 5 or 7)
then it MUST perform the following steps:
* Compute the KEM shared_secret ( ss_R ) for the authentication
of the Responder by decapsulating the KEM ciphertext ( ct_R )
received in message_3 using the Responder static KEM secret
key ( sk_R ). The KEM shared secret is computed by the
Responder using the following function:
ss_R <- KEM.Decapsulate( ct_R, sk_R )
* Compute the new PRK_3e2m from a chain that includes both the
ephemeral KEM shared secret ( ss_eph ) and the latest KEM
shared secret for the Authentication of the Responder ( ss_R
), as defined in Section 3.1.1.2
Else, if the Responder authenticates using a PQC signature
algorithm (method 6), then PRK_3e2m SHALL be set equal to PRK_2e
(PRK_3e2m = PRK_2e).
4. Compute the transcript hash TH_3=H(TH_2,PLAINTEXT_2,CRED_R,?
ct_R). The element ( ct_R ) SHALL be present only when the
Responder use KEM-based authentication (methods 4 and 6);
otherwise it SHALL be ommited.
5. Compute K_3/IV_3 as in Section 3.1.2, where plaintext_length is
the length of PLAINTEXT_3
6. Decrypt CIPHERTEXT_3; see Section 4.3.2
7. "If all processing is completed successfully, then make ID_CRED_I
and (if present) EAD_2 available to the application", as in
Section 5.3.4 of [RFC9528]
8. "Obtain the authentication credential (CRED_I) from the
(ID_CRED_I)" as in Section 5.3.4 of [RFC9528] and the static
authentication key of the Initiator.
Pocero Fraile, et al. Expires 23 November 2026 [Page 20]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
4.4. KEM-based authentication EDHOC Message 4
4.4.1. Formating of Message 4
message_4 SHALL be a CBOR Sequence as defined below:
message_3 = (
CIPHERTEXT_4 : bstr,
? ct_I : bstr,
)
4.4.2. Responder Composition of Message 4
The Responder SHALL process the composition of message_4 as follows:
* If the Initiator use KEM-based authentication (methods equal 4 or
5) then the Responder MUST perform the following step:
- Encapsulate the retrieved static KEM authentication key of the
Initiator ( pk_I ) calculating the corresponding ciphertext (
ct_I ) and shared secret ( ss_I ) with the following function:
ss_I, ct_I <- KEM.Encapsulate(pk_I)
* Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I,?
ct_I). The element ( ct_I ) SHALL be present only when the
Initiator use KEM-based authentication (methods 5 and 6);
otherwise it SHALL be ommited.
* Compute MAC_2 as defined in Section 3.1.2, with context_2 =<< C_R,
ID_CRED_R, TH_4, CRED_R, ? EAD_4 >>
- If the Resonder authenticates with static KEM key (methods
equals 5 or 7), then the mac_lenght_2 is equal to the EDHOC MAC
length of the selected cipher suit. If the Responder
authenticates with PQC Signature algorithms (method equal 6),
then the mac_lenght_2 is equal to hash_length.
- The C_R, ID_CRED_R and CRED_R elements corresponds with the
ones in Section 5.3.2 of [RFC9528]
- The latest transcript hash TH_4 and the External Application
Data included in Message 4 (EAD_4) are used.
* If the Responder use KEM-based authentication (methods equal 5 or
7) then Sig_R_or_MAC_2 is MAC_2. If the Responder authenticates
using a PQC signature algorithm (method 6), then Sig_R_or_MAC_2 is
the 'signature' field of a COSE_Sign1 object, computed as
Pocero Fraile, et al. Expires 23 November 2026 [Page 21]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
specified in Section 5.3.2 of [RFC9528] but using the PQC
Signature algorithm specify in the selected cipher suite, the
private PQC authentication key of the Responder,and the following
parameteres as input::
- protected = << ID_CRED_R >>
- external_aad = << TH_4, CRED_R, ? EAD_4 >>
- payload = MAC_2
* If the Initiator use KEM-based authentication (methods equal 5 or
6) then the Responder MUST perform the following step:
- Compute the new PRK_4e3m from a chain that includes the
ephemeral KEM shared secret ( ss_eph ), the KEM shared secret
for the Authentication of the Responder ( ss_R ), and the
latest KEM shared secret for the Authentication of the
Initiator ( ss_I ) as defined in Section 3.1.1.3
Else, if the Initiator authenticates using a PQC signature
algorithm (method equal 7), then PRK_4e3m SHALL be set equal to
PRK_3e2m (PRK_4e3m = PRK_3e2m).
* Derive the session key K_4/IV4 as in Section 3.1.2.
* Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
suite, using the encryption key K_4, the initialization vector
IV_4 (if used by the AEAD algorithm), the plaintext PLAINTEXT_4,
and the following parameters as input:
- protected = h''
- external_aad = TH_4
- K_4 and IV_4 are defined in Section 3.1.2
- PLAINTEXT_4 = ( MAC_2, ?EAD_4 )
CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.
* Compute the transcript hash TH_5 = H(TH_4, PLAINTEXT_4)
* Encode message_4 as a CBOR data item as specified in
Section 4.4.1.The element ( ct_I ) SHALL be present only when the
Initiator use KEM-based authentication (methods 5 and 6);
otherwise it SHALL be ommited. When the Initiator use PQC
Pocero Fraile, et al. Expires 23 November 2026 [Page 22]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
Signature algorithms (method 7) message_4 consists of a single
element (CIPHERTEXT_4). ( ct_I ) is defined as the trailing
element so it can be omitted when not used; therefore, senders
MUST NOT encode ct_I as NULL.
4.4.3. Initaitor Processing of Message 4
The Initiator SHALL process message_4 in the following order:
1. Decode message_4
2. "Retrieve the protocol state using available message
correlation", as in Section 3.4.2 of [RFC9528].
3. If the Initiator use KEM-based authentication (methods equal 5 or
6) then it MUST perform the following steps:
* Compute the KEM shared secret ( ss_I ) for the authentication
of the Initiator by decapsulating the KEM ciphertext ( ct_I )
received in message_4 using the Responder static KEM secret
key ( sk_I ). The KEM shared secret is computed by the
Initiator using the following function:
ss_I <- KEM.Decapsulate( ct_I, sk_I )
* Compute the new PRK_4e3m from a chain that includes the
ephemeral KEM shared secret ( ss_eph ), the KEM shared secret
for the Authentication of the Responder ( ss_R ), and the
latest KEM shared secret for the Authentication of the
Initiator ( ss_I ) as defined in Section 3.1.1.3
Else, if the Initiator authenticates using a PQC signature
algorithm (method equal 7), then PRK_4e3m SHALL be set equal to
PRK_3e2m (PRK_4e3m = PRK_3e2m).
4. Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I, ?
ct_I). The element ( ct_I ) SHALL be present only when the
Initiator use KEM-based authentication (methods 4 and 5);
otherwise it SHALL be ommited.
5. Derive the session key K_4/IV4 as in Section 3.1.2.
6. Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_4) as defined
Section 5.2 and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm
in the selected cipher suite and the parameters defined in
Section 4.4.2.
Pocero Fraile, et al. Expires 23 November 2026 [Page 23]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
7. Verify Sig_R_or_MAC_2 using the algorithm in the selected cipher
suite. The verification process depepends on the authentication
method used by the Responder as defined in Section 4.4.2. "Make
the result of the verification available to the application" as
in Section 5.3.3 of [RFC9052]
4.5. KEM-based authentication EDHOC Message 5
4.5.1. Formating of Message 5
message_5 SHALL be a CBOR Sequence as defined below:
message_3 = (
CIPHERTEXT_5 : bstr,
)
4.5.2. Initiator Composition of Message 5
The Initiator SHALL process the composition of message_5 as follows:
* Compute the transcript hash TH_5 = H(TH_4, PLAINTEXT_4)
* Compute MAC_3 as defined in Section 3.1.2, with context_3 =<< C_I,
ID_CRED_I, TH_5, CRED_I, ? EAD_5 >>
- If the Initiator authenticates with static KEM key (methods
equals 5 or 6), then the mac_lenght_3 is equal to the EDHOC MAC
length of the selected cipher suit. If the Initiator
authenticates with PQC Signature algorithms (method equal 7),
then the mac_lenght_3 is equal to hash_length.
- The C_I, ID_CRED_I and CRED_I elements corresponds with the
ones in Section 5.4.2 of [RFC9528]
- The latest transcript hash TH_5 and the External Application
Data included on Message 5 (EAD_5) are used.
* If the Initiator use KEM-based authentication (methods equal 5 or
6) then Sig_I_or_MAC_3 is MAC_3. If the Initiator authenticates
using a PQC signature algorithm (method 6), then Sig_I_or_MAC_3 is
the 'signature' field of a COSE_Sign1 object, computed as
specified in Section 4.3.2 of [RFC9528] but using the PQC
Signature algorithm specify in the selected cipher suite, the
private PQC authentication key of the Initiator, and the following
parameteres as input:
- protected = << ID_CRED_I >>
Pocero Fraile, et al. Expires 23 November 2026 [Page 24]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
- external_aad = << TH_5, CRED_I, ? EAD_5 >>
- payload = MAC_3
* Compute a COSE_Encrypt0 object as defined inSection 5.2 and 5.3 of
[RFC9052], with the EDHOC AEAD algorithm of the selected cipher
suite, using the encryption key K_4, the initialization vector
IV_4 (if used by the AEAD algorithm), the plaintext PLAINTEXT_5,
and the following parameters as input:
- protected = h''
- external_aad = TH_5
- K_5 and IV_5 are defined in Section 3.1.2
- PLAINTEXT_5 = ( MAC_3, ? EAD_5 )
CIPHERTEXT_5 is the 'ciphertext' of COSE_Encrypt0.
* Calculate PRK_out as defined in Section 3.1.3. The Initiator can
now derive application keys using the EDHOC_Exporter interface;
see Section 3.2
* Encode message_5 as a CBOR data item as specified in Section 4.5.1
* "Make the connection identifiers (C_I and C_R) and the application
algorithms in the selected cipher suite available to the
application" as in Section 5.4.2 of [RFC9528]
After creating message_5, the Initiator can compute PRK_out and
derive application keys using the EDHOC_Exporter interface. The
Responder SHOULD now persistently store PRK_out or application keys
and send protected application data, since it has already verified
message_4, which is protected with a derived application key by the
Responder, and the application has authenticated the Responder.
4.5.3. Responder Processing of Message 5
The Responder SHALL process message_5 in the following order:
1. Decode message_5
2. "Retrieve the protocol state using available message correlation"
as in Section 3.4.2 of [RFC9528].
Pocero Fraile, et al. Expires 23 November 2026 [Page 25]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
3. Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_5) as defined in
Section 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm
in the selected cipher suite and the parameters defined in
Section 4.5.2.
4. Verify Sig_I_or_MAC_3 using the algorithm in the selected cipher
suite. The verification process depepends on the authentication
method used by the Initiator as defined in Section 4.5.2. "Make
the result of the verification available to the application" as
in Section 5.3.3 of [RFC9052]
5. Calculate PRK_out as defined in Section 3.1.3. The Initiator can
now derive application keys using the EDHOC_Exporter interface;
see Section 3.2
After verifying message_5, the Responder can compute PRK_out and
derive application keys using the EDHOC_Exporter interface. The
Responder SHOULD now persistently store PRK_out or application keys
and send protected application data, since it has already verified
message_5, which is protected with a derived application key by the
Initiator, and the application has authenticated the Initiator.
5. IANA Considerations
5.1. EDHOC Method Types Registry
The "EDHOC Method Types" Registry from group "Ephemeral Diffie-
Hellman Over COSE (EDHOC)" SHOULD be extended with a new value that
identifies the KEM-based authentication method. The extension value
from the "Standards Action with Expert Review" range, is proposed in
Table 2
Registry Name: EDHOC Method Types
Reference: draft-pocero-authkemsig-edhoc-00
The columns of the registry are Value, Initiator Authentication Key,
Responder Authentication Key and Reference, where Value is an integer
and the other columns are text strings. The new value proposed is:
Pocero Fraile, et al. Expires 23 November 2026 [Page 26]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
+=============+================+================+================+
| Value | Initiator | Responder | Reference |
| | Authentication | Authentication | |
| | Key | Key | |
+=============+================+================+================+
| 6 | Static KEM Key | PQC Signature | [draft-pocero- |
| (suggested) | | key | authkemsig- |
| | | | edhoc-00] |
+-------------+----------------+----------------+----------------+
| 7 | PQC Signature | Static KEM Key | [draft-pocero- |
| (suggested) | key | | authkemsig- |
| | | | edhoc-00] |
+-------------+----------------+----------------+----------------+
Table 2: EDHOC Method Types
6. Security Considerations
The same Security Considerations described in Section 6 of
[I-D.pocero-lake-authkem-edhoc] apply to this document.
7. References
7.1. Normative References
[I-D.ietf-lamps-kyber-certificates]
Turner, S., Kampanakis, P., Massimo, J., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Key-
Encapsulation Mechanism (ML-KEM)", Work in Progress,
Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22
July 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-kyber-certificates-11>.
[I-D.pocero-lake-authkem-edhoc]
Fraile, L. P., Koulamas, C., Fournaris, A. P., and E.
Haleplidis, "KEM-based Authentication for EDHOC", Work in
Progress, Internet-Draft, draft-pocero-lake-authkem-edhoc-
00, 22 May 2026, <https://datatracker.ietf.org/doc/html/
draft-pocero-lake-authkem-edhoc-00>.
[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>.
Pocero Fraile, et al. Expires 23 November 2026 [Page 27]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>.
[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>.
[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>.
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/info/rfc9360>.
[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>.
7.2. Informative References
[PQ-EDHOC-Access25]
Pocero Fraile, L., Koulamas, C., and A. P. Fournaris,
"Reinventing EDHOC for the Post-Quantum Era", IEEE Access,
Volume 13, pages 196622–196640, 2025. DOI:
https://doi.org/10.1109/ACCESS.2025.3633843, 2025,
<https://doi.org/10.1109/ACCESS.2025.3633843>.
[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>.
Pocero Fraile, et al. Expires 23 November 2026 [Page 28]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
[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>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
March 2022, <https://www.rfc-editor.org/info/rfc9177>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/info/rfc9794>.
Appendix A. Early Authentication Approach for Combined PQC KEM and
Signature Authentication Methods
To extend the pure KEM-based authentication between both parties with
support for combinations where the Initiator and Responder use
different mechanisms, combining KEM-based and signature-based
authentication, an alternative approach can be considered. In this
early authentication approach, authentication is prioritized, and
each party authenticates in the first message in which it is able to
do so. This enables authentication to occur as early as possible, in
contrast to the message-flow-preserving approach defined in this
document.
When KEM-based authentication is used by both parties, the two
approaches share the same message flow, as shown in Figure 3. When
the Initiator uses PQC signature-based authentication, it is able to
authenticate its identity within message 3. By using the early
authentication approach, this avoids the need for message_5 and
reduces the message flow to four mandatory messages, as shown in
Figure 5. On the other hand, when the Responder uses PQC signature-
based authentication, the authentication trough signatures within
message 2 does not reduce the number of mandatory messages, as shown
in Figure 4. However, both Method 5 and Method 6 can benefit from
the early authentication approach, which allows the protocol to
Pocero Fraile, et al. Expires 23 November 2026 [Page 29]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
terminate early if authentication fails, enables early detection of
misbinding attacks, and increases the level of authentication
assurance provided by intermediate messages.
The main drawback of the early authentication approach is the
increased complexity associated with using different message formats
and numbers of messages across the various authentication methods,
which complicates protocol specifications and implementations.
Priority has been given in this document to maintaining a simpler
protocol specification with the same number of messages and a
consistent format across the three authentication methods, since the
benefits of lower complexity are considered more important than the
marginal advantages provided by the early authentication approach.
However, the advantages and disadvantages of both approaches should
be further discussed within the LAKE Working Group to evaluate the
pros and cons of each approach.
Initiator Responder
| METHOD, SUITES_I, pk_eph, C_I, EAD_1 |
+------------------------------------------------------------------->
| message_1 |
| |
| ct_eph, Enc( C_R, ID_CRED_R, EAD_2 ) |
<-------------------------------------------------------------------+
| message_2 |
| |
| ct_R, AEAD( ID_CRED_I, EAD_3 ) |
+------------------------------------------------------------------->
| message_3 |
| |
| ct_I, AEAD( EAD_4, MAC_2 ) |
<-------------------------------------------------------------------+
| message_4 |
| |
| AEAD( EAD_5, MAC_3 ) |
+------------------------------------------------------------------->
| message_5 |
Figure 3: EDHOC Message Flow for KEM-based Authentication on both
Initiator and Responder (Method 4)
Pocero Fraile, et al. Expires 23 November 2026 [Page 30]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
Initiator Responder
| METHOD, SUITES_I, pk_eph, C_I, EAD_1 |
+------------------------------------------------------------------->
| message_1 |
| |
| ct_eph, Enc( C_R, ID_CRED_R, sig, EAD_2 ) |
<-------------------------------------------------------------------+
| message_2 |
| |
| AEAD( ID_CRED_I, EAD_3 ) |
+------------------------------------------------------------------->
| message_3 |
| |
| ct_I, AEAD( EAD_4) |
<-------------------------------------------------------------------+
| message_4 |
| |
| AEAD( EAD_5, MAC_3 ) |
+------------------------------------------------------------------->
| message_5 |
Figure 4: EDHOC Message flow for KEM-based authentication on the
Initiator and PQC signature-based authentication on the Responder
(Method 5)
Initiator Responder
| METHOD, SUITES_I, pk_eph, C_I, EAD_1 |
+------------------------------------------------------------------->
| message_1 |
| |
| ct_eph, Enc( C_R, ID_CRED_R, EAD_2 ) |
<-------------------------------------------------------------------+
| message_2 |
| |
| ct_R, AEAD( ID_CRED_I, sig, EAD_3 ) |
+------------------------------------------------------------------->
| message_3 |
| |
| AEAD( EAD_4, MAC_2 ) |
<-------------------------------------------------------------------+
| message_4 |
Figure 5: EDHOC Message flow for PQC signature-based
authentication on the Initiator and KEM-based authentication on
the Responder (Method 6)
Authors' Addresses
Pocero Fraile, et al. Expires 23 November 2026 [Page 31]
Internet-Draft Hybrid KEM/Signature-Based Methods for S May 2026
Lidia Pocero Fraile
ISI, R.C. ATHENA
Cyber-physical and Networked Embedded Systems
26504 Patras
Greece
Email: pocero@isi.gr
Christos Koulamas
ISI, R.C. ATHENA
Cyber-physical and Networked Embedded Systems
26504 Patras
Greece
Email: koulamas@isi.gr
Apostolos P. Fournaris
ISI, R.C. ATHENA
Security and Protection of Systems, Networks and Infrastructures
26504 Patras
Greece
Email: fournaris@isi.gr
Evangelos Haleplidis
ISI, R.C. ATHENA
Department of Digital Systems
26504 Patras
Greece
Email: haleplidis@isi.gr
Pocero Fraile, et al. Expires 23 November 2026 [Page 32]