Hybrid KEM/Signature-Based Methods for Scenarios with Asymmetric Device Constraints

Hybrid KEM/Signature-Based Methods for Scenarios with Asymmetric Device Constraints ISI, R.C. ATHENA

Cyber-physical and Networked Embedded Systems Patras 26504 Greece pocero@isi.gr

ISI, R.C. ATHENA

Cyber-physical and Networked Embedded Systems Patras 26504 Greece koulamas@isi.gr

ISI, R.C. ATHENA

Security and Protection of Systems, Networks and Infrastructures Patras 26504 Greece fournaris@isi.gr

ISI, R.C. ATHENA

Department of Digital Systems Patras 26504 Greece haleplidis@isi.gr

sec individual EDHOC Post Quantum This document extends the KEM-based Authentication for EDHOC draft 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.

The purpose of this document is to extend the quantum-resistant (QR) authentication methods defined in , 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 , which are still potentially vulnerable to attacks from Cryptographically Relevant Quantum Computers (CRQCs). Together with the methods defined in , they complete the quantum-resistant versions of all authentication methods defined in . This document defines the resulting protocol that integrates the three QR authentication approaches: the KEM-based/KEM-based methods defined in , 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-based authentication methods defined in . A more complex approach, which prioritizes authentication as early as possible, is presented in 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 .

TO DO: Asymetric constrains devices participate on the handshake. Add anlysis on PQ algorithms as falcon

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. Readers are expected to be familiar with the terms and concepts described in EDHOC , CBOR , CBOR Sequences , COSE Structures and Processing and COSE Algorithms , When referring to CBOR, this specification always refers to Deterministically Encoded CBOR, as specified in . The single output from authenticated encryption (including the authentication tag) is called "ciphertext", following . TO DO: add subsection for Signatures?

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 ).

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 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). 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 . All EDHOC messages are CBOR Sequences as specified in . The protocol elements are introduced in this Section and in . Message formatting and processing are specified in .

| 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 | ]]> 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). 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 . "ID_CRED_I and ID_CRED_R are used to identify and optionally transport the credentials of I and R, respectively", as defined in . 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 . "SUITES_I contains cipher suites supported by the Initiator and formatted and processed as specified in ". "METHOD is an integer specifying the authentication method",as defined in . In this case method 4 5 or 6; see . C_I and C_R are Connection Identifiers chosen by the Initiator and Responder, respectively, as specified in . 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. This protocol is designed so that it follows the provisions of , 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

This section describes the principal protocol elements that differ from the definitions of EDHOC and , and highlights the most important similarities. For the missing elements, the definitions in SHOULD be consulted.

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 :

The protocol extends EDHOC by integrating Method 5 defined in , 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. Authentication Keys for Method Types

Method Type Value	Initiator Authentication Key	Responder Authentication Key
6	Static KEM Key	PQC Signature
7	PQC Signature	Static KEM Key

The protocol performs the same authentication-related operations as described in 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

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.

The authentication credentials, CRED_I and CRED_R, contain the authentication public key of the Initiator and Responder, respectively, as described in . The authentication credentials can be X.509 certificates seconded as bstr, as defined in , using . When static KEM authentication keys are used, 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 , 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

The ID_CRED fields are used to identify and optionally transport credentials as defined in .

The authentication method specified in this document uses the EDHOC cipher suites element, as defined in . An EDHOC cipher suit consists of an ordered set of algorithms from the "COSE Algorithms" IANA registry . The predefined EDHOC cipher suites are also listed in the IANA registry, as specified in . 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 . An example of this, when ML-KEM is used, is shown in . 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 .

Same consoderations regarding the larger message sizes MAY necessitate transport support for fragmentation than the defined in .

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 . An overview of the EDHOC key schedule for KEM-based authentication methods 5, 6, or 7 is shown in , and each key derivation step is explained in the following subsections.

|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?) | | | | +-----------------------+ | | | | | | +------+ +-----+ | | +--|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 ]]>

The pseudorandom keys (PRKs) used for KEM-based authentication methods are derived using the same EDHOC_Extract function defined in , where the input keying material (IKM) and Salt are specified for each PRK below.

The pseudorandom key PRK_2e is derived as defined in

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).

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 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).

The same output key materials (OKMs) are derived from the PRKs as defined in .

The pseudorandom key PRK_out is the output session key of a completed EDHOC session and is derived as is

Keying material for the application can be derived using the same EDHOC_Exporter interface defined in

This section outlines the message format and the procedures for composing and processing each message.

message_1 retains the same format as defined in . 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.

The Initiator SHALL compose message_1 as follows: Construct SUITES_I following the 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 . Encode message_1 as sequence of CBOR-encoded elements, as specified in

The Responder SHALL process message_1 in the following order: "Decode message_1", as specified in "Process message_1", as specify in "If all processing is completed successfully, and if EAD_1 is present, then make it available to the application", as specified in

message_2 keeps the same formatting as . 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.

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 Compute the PRK_2e pseudorandom key from the ephemeral KEM shared secret ( ss_eph ) "Choose a connection identifier C_R", as specified in 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 CIPHERTEXT_2 is calculated, with a binary additive stream cipher as in , 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 . Compute KEYSTREAM_2 as in Compute CIPHERTEXT_2 as in CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 Encode message_2 as a sequence of CBOR-encoded data items as specified in

The Initiator SHALL process message_2 in the following order: Decode message_2 "Retrieve the protocol state" as proposed in 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 ) Compute the transcript hash TH_2 = H(pk_eph,H(message_1)) Compute the PRK_2e pseudorandom key from the ephemeral KEM shared secret ( ss_eph ) Derive KEYSTREAM_2 as in Decrypt CIPHERTEXT_2; see If all processing is completed successfully, ID_CRED_R and (if present) EAD_2 SHALL be made available to the application, as specified in . 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. Obtain the authentication credential (CRED_R) from the (ID_CRED_R) as in , and the static authentication key of the Responder 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 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).

message_3 SHALL be a CBOR Sequence as defined below: message_3 = ( CIPHERTEXT_3 : bstr, ? ct_R : bstr, )

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 . 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 . 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 Compute a COSE_Encrypt0 object as defined in , 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 PLAINTEXT_3 = (C_I,ID_CRED_I,?EAD_3) where C_I, ID_CRED_I and EAD_3 elements corresponds with the ones in CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. Encode message_3 as a CBOR data item as specified in . 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.

The Responder SHALL process message_3 in the following order: Decode message_3 "Retrieve the protocol state", as defined in 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 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). 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. Compute K_3/IV_3 as in , where plaintext_length is the length of PLAINTEXT_3 Decrypt CIPHERTEXT_3; see "If all processing is completed successfully, then make ID_CRED_I and (if present) EAD_2 available to the application", as in "Obtain the authentication credential (CRED_I) from the (ID_CRED_I)" as in and the static authentication key of the Initiator.

message_4 SHALL be a CBOR Sequence as defined below: message_3 = ( CIPHERTEXT_4 : bstr, ? ct_I : bstr, )

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 , 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 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 specified in 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 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 . Compute a COSE_Encrypt0 object as defined in , 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 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 .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 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.

The Initiator SHALL process message_4 in the following order: Decode message_4 "Retrieve the protocol state using available message correlation", as in . 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 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). 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. Derive the session key K_4/IV4 as in . Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_4) as defined ], with the EDHOC AEAD algorithm in the selected cipher suite and the parameters defined in . 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 . "Make the result of the verification available to the application" as in

message_5 SHALL be a CBOR Sequence as defined below: message_3 = ( CIPHERTEXT_5 : bstr, )

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 , 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 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 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 >> external_aad = << TH_5, CRED_I, ? EAD_5 >> payload = MAC_3 Compute a COSE_Encrypt0 object as defined in, 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 PLAINTEXT_5 = ( MAC_3, ? EAD_5 ) CIPHERTEXT_5 is the 'ciphertext' of COSE_Encrypt0. Calculate PRK_out as defined in . The Initiator can now derive application keys using the EDHOC_Exporter interface; see Encode message_5 as a CBOR data item as specified in "Make the connection identifiers (C_I and C_R) and the application algorithms in the selected cipher suite available to the application" as in 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.

The Responder SHALL process message_5 in the following order: Decode message_5 "Retrieve the protocol state using available message correlation" as in . Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_5) as defined in , with the EDHOC AEAD algorithm in the selected cipher suite and the parameters defined in . 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 . "Make the result of the verification available to the application" as in Calculate PRK_out as defined in . The Initiator can now derive application keys using the EDHOC_Exporter interface; see 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.

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

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: EDHOC Method Types

Value	Initiator Authentication Key	Responder Authentication Key	Reference
6 (suggested)	Static KEM Key	PQC Signature key	[draft-pocero-authkemsig-edhoc-00]
7 (suggested)	PQC Signature key	Static KEM Key	[draft-pocero-authkemsig-edhoc-00]

The same Security Considerations described in apply to this document.

&RFC9528; &RFC9052; &I-D.ietf-lamps-kyber-certificates; &RFC8392; &RFC9360; &RFC8949; &RFC8742; &RFC5116; &I-D.spm-lake-pqsuites; &I-D.pocero-lake-authkem-edhoc; &RFC2119; &RFC9794; &RFC9053; &RFC7252; &RFC7959; &RFC9177; Reinventing EDHOC for the Post-Quantum Era IEEE Access, Volume 13, pages 196622–196640, 2025. DOI: https://doi.org/10.1109/ACCESS.2025.3633843

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 . 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 . 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 . However, both Method 5 and Method 6 can benefit from the early authentication approach, which allows the protocol to 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.