KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios

The purpose of this document is to address a more efficient quantum-resistant transition of the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol by extending with a new Key Encapsulation Mechanism (KEM)-based authentication method that uses a mandatory three-message handshake in Initiator-Known Responder (IKR) Scenarios. The specified protocol is part of a broader analysis of the post-quantum transition for EDHOC

The KEM-based authentication method for EDHOC, specified in , addresses the general mutually unknown peer scenario, similar to the original EDHOC protocol. In this case, the Initiator and Responder, if do not have prior knowledge of each other's credentials can exchange them in the form of X.509 certificate. To maintain this generality an additional round trip is required, resulting in a mandatory five-message handshake. This document explores the possibility of reducing this overhead in the specific scenario where the Initiator already possesses the credentials of the Responder it wishes to connect in advance. This applies to cases where the Initiator is a constrained device equipped with credentials for the Responder, obtained through pre-provisioning or out-of-band methods. A typical example is during onboarding, where a remote or local server (acting as the Responder) is configured on the device in advance. Such settings are particularly relevant for EDHOC, which targets constrained environments where transmitting credentials can be costly.

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 .

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

This document defines a KEM-based authentication method for EDHOC, tailored for a specific scenario where the Initiator knows the credentials of the Responder it intends to communicate with beforehand. In such cases, the method, specified in this document, reduces the standard five-message handshake defined in to a three-message exchange. This variant, referred to as Initiator Knows Responder (IKR), converts the Noise-XX pattern, used in both static-DH and KEM-based authentication EDHOC methods, into a Noise-IK pattern. The Noise-IK pattern enables a mutual authentication handshake when the Initiator has prior knowledge of the Responder’s static public key, and the Initiator’s static keys are sent in the first message. The mechanism provided in for transforming this pattern into the PQ Noise-IK version is integrated into this protocol. The KEM-based IKR variant provides a more efficient handshake with only three mandatory messages while maintaining mutual authentication, forward secrecy, and a level of identity protection. Notably, the Responder does not require prior knowledge of the Initiator’s credentials. Instead, the Initiator encrypts its credentials, or an identifier, within message_1 using a key derived from a shared secret, computed over the Responder’s static KEM public key, which the Initiator already possesses. Consequently, only the legitimate Responder, holding the corresponding static KEM private key, can decrypt this information, ensuring that the Initiator’s identity remains protected against both passive and active attackers. The KEM-based EDHOC protocol consists of three mandatory messages (message_1, message_2, message_3), an optional message_4, and an error message, between an Initiator (I) and a Responder (R). Figure 2 illustrates a KEM-based ikr authentication EDHOC message flow as well as the content of each message. The protocol elements in are introduced in this Section and in . Message formatting and processing are specified in .

| message_1 | | | | ct_eph, ct_I, AEAD( C_R, ID_CRED_R, MAC_2, EAD_2 ) | <----------------------------------------------------------------+ | message_2 | | | | AEAD( MAC_3, EAD_3 ) | +----------------------------------------------------------------> | message_3 | | | | AEAD( EAD_4 )? | <----- - - -- - - - - - - - - - - - - - - - - - - - - - - - - - -+ | message_4 | ]]> The Initiator can derive symmetric application keys after receiving message_2 and Responder after receiving message_3. 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. 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. "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 . AEAD(), and MAC() denote 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 5; 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 are External Authorization Data included in message_1, message_2, message_3 and message_4, 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 Furthermore, key derivation and message protection are based on the strongest shared secrets available at each stage of the handshake. Accordingly, this specification modifies the original EDHOC key schedule to incorporate each shared secret as soon as it is established. Consequently, every message is confidentiality- and integrity-protected using keying material derived from all shared secrets available at that point in the protocol execution.

This section describes the principal protocol elements that differ from the ones defined in EDHOC. For the missing elements, the definitions in SHOULD be consulted.

The ephemeral KEM is used to provide forward secrecy. 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: The ephemeral KEM key pair ( pk_eph, sk_eph ) is generated by the Initiator using the following function: pk_eph, sk_eph <- KEM.KeyGen() The ephemeral shared secret ( ss_eph ) and the ephemeral ciphertext ( ct_eph ) are generated using the encapsulation and decapsulation functions: in the Responder ss_eph, ct_eph <- KEM.Encapsulate( pk_eph ) in the Initiator ss_eph <- KEM.decapsulation( ct_eph, sk_eph )

The protocol performs the same authentication-related operations as described in The protocol transports information about credentials ID_CRED_I and ID_CRED_R encrypted in message_1 and message_2, respectively.

The protocol extends EDHOC with a new KEM-based authentication method for IKR scenarios, where both parties use static KEM key pairs. The authentication is provided by a Message Authentication Code (MAC) included in message_2 and message_3 to authenticate the Responder and Initiator, respectively. The Initiator and Responder need to have agreed on a method 5. Authentication Keys for Method Types

Method Type Value	Initiator Authentication Key	Responder Authentication Key
5	Static KEM Key (IKR scenario)	Static KEM Key (IKR scenario)

The authentication key MUST be a static KEM authentication key pair. The Initiator static KEM authentication key pair: ( pk_I, sk_I ) The Responder static KEM authentication key pair: ( pk_R, sk_R )

The authentication credentials, CRED_I and CRED_R, contain the static KEM 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 . describes the conventions for using the ML-KEM in X.509 Public Key Infrastructure. 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.

"The ID_CRED fields are used to identify and optionally transport credentials", as defined in . "ID_CRED_R is intended to facilitate for the Initiator retrieving the authentication credential CRED_R and the authentication key of R", as defined in . For the authentication method defined in this document, the authentication key is the static KEM public key, and ID_CRED_R SHOULD contain an identifier of the credentials, since in the specific IKR scenario, the Responder’s credentials have been pre-provisioned or acquired out-of-band. "ID_CRED_I is intended to facilitate for the Responder retrieving the authentication credential CRED_I and the authentication key of I", as defined in . For the authentication method defined in this document, the authentication key is the static KEM public key, and ID_CRED_I may contain the authentication credential CRED_I or an identifier of the credentials if these have been pre-provisioned or acquired out-of-band.

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 each supported KEM in the EDHOC Key Exchange Algorithm parameter. 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 method 5 is selected. Furthermore, the KEM algorithms used SHOULD also be added to the COSE Algorithms IANA registry to identify them, as is shown in .

This section highlights the differences and similarities in the key derivation process of the KEM-based authentication method for IKR scenarios compared to the KEM-based authentication method on the general case and with the original EDHOC authentication methods described in . An overview of the EDHOC key schedule when using the KEM-based authentication in the IKR scenarios method is shown in , and each key derivation step is defined in the following subsections.

|Ext|->|PRK_1e|--|Exp|->|K_1|->|AEAD|->|C_1| +----+ +---+ +--+---+ +--++ +---+ +--^-+ +---+ | | | +---+ | PLAINTEXT_1 | +-------+-----------+ | |TH_1=H(pk_eph,ct_R)| | +---------+---------+ | | +------+ +---+---+ +-------+ +--+---+ +-----+ |ss_eph|->|Extract|->|PRK_2m |---|Expand|->|MAC_2| +------+ +-------+ +--+----+ +------+ +-----+ | +-------------+ | +----+ +-+-+ +----------+ +---+ +---+ +----+ +---+ |ss_I|->|Ext|->|PRK_2e3e3m|+-|Exp|-->|K_2|-->|AEAD|->|C_2| +----+ +---+ +----------+ |+--++ +---+ +-^--+ +---+ | | | | | PLAINTEXT_2 | +--+---------------------------+ | |TH_2=H(H(Message1),ct_eph,ct_I| | +--+---------------------------+ | +--+---+ +-----+ +-|Expand|-->|MAC_3| | +------+ +-----+ | +-------------------------------+ | |TH_3=H(TH_2,PLAINTEXT_2,CRED_R)| | +--+----------------------------+ | | | +--++ +---+ +----+ +---+ +-|Exp|--->|K_3|-->|AEAD|->|C_3| | +---+ +---+ +-^--+ +---+ | | | PLAINTEXT_3 | +---+ +---+ +----+ +---+ +-m_4?-|Exp|->|K_4|-->|AEAD|->|C_4| | +--++ +---+ +-^--+ +---+ | | | | | PLAINTEXT_4 | +----------+--------------------+ | |TH_4=H(TH_3,PLAINTEXT_3,CRED_I)| | +----+--------------------------+ | | | +--+--+ +-------+ +--|Expand|->|PRK_out| +------+ +--+----+ | +--v---+ |Expand| +------+ | +----v-------+ |PRK_exporter| +---+--------+ | +--v---+ |Expand| +--+---+ | v Aplication Key ]]>

The pseudorandom keys (PRKs) used for KEM-based IKR authentication 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 usage of PRKs differs from the definitions in both and , and their names have been updated to reflect their new roles.

The pseudorandom key PRK_1e is derived with the following input: The salt SHALL be TH_1. The IKM SHALL be the KEM shared secret (ss_R), used to authenticate the Responder. When SHA-256 is used PRK_1e is produced as follows: PRK_1e = HMAC-SHA-256( TH_1, ss_R ) Where the ss_R shared secret is the output of the following functions in the Initiator and the Responder respectively. Initiator: ss_R, ct_R <- KEM.Encapsulate( pk_R ) Responder: ss_R <- KEM.Decapsulate( ct_R, sk_R )

The pseudorandom key PRK_2m is derived with the following input: The salt SHALL be the SALT_2m derived from PRK_1e The IKM SHALL be the ephemeral KEM shared secret ss_eph PRk_2m is derived as follows: PRK_2m = EDHOC_Extract( SALT_2m, ss_eph ) Where the ephemeral KEM shared secret ( ss_eph ) is the output of the following functions in the Initiator and Responder, respectively Initiator: ss_eph <- KEM.Decapsulate( ct_eph, sk_eph ) Responder: ss_eph, ct_eph <- KEM.Encapsulate( pk_eph )

The pseudorandom key PRK_2e3e3m is derived with the following input: The salt SHALL be the SALT_2e3m, derived from PRK_2m The IKM SHALL be the KEM shared secret ss_I, used to authenticate the Initiator PRK_2e3e3m is derived as follows: PRK_2e3e3m = EDHOC_Extract( SALT_2e3m, 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 )

The output key materials (OKMs) are derived from the PRKs in the same way as described in , with modifications in some of the transcription hashes THs input contraction as specified in . The OKMs, including keys, initialization vectors (IV), and salts derivations using EDHOC_KDF are shown in . The main differences from the original EDHOC key schedule, as shown in (Figure 6), reflect the design principle of incorporating all available shared secrets into the key schedule as soon as they are established, and are: A new K_1/IV_1 is computed to encrypt the message_1 which includes the ID_CRED_I initiator credentials, using a new transcrit hash (TH_1) defined as follows: TH_1 = H( pk_eph, ct_I ) The AEAD encrption of message_1 with K_1/IV_1 provide integrity protection and confidentiality ensuring that the Initiator’s identity is protected against active attacks. However, this does not provide authentication of the Initiator’s identity. K_2/IV_2 are computed to encrypt and authenticate message_2, derived from the PRK computed over the three shared secrets ( ss_eph, ss_I, and ss_R ) K_2/IV_2, K_3/IV_3 and K_4/IV_4 are derived from the same PRK_2e3e3m with different THs as Info. The usage of the pseudorandom keys (PRKs) has changed, and the salt names have been selected to reflect their new roles accordingly. Further details of the key derivation and how the output keying material is used are specified in

K_1 = EDHOC_KDF(PRK_1e, 0, TH_1, plaintext_length) IV_1 = EDHOC_KDF(PRK_1e, 1, TH_1, plaintext_length) SALT_2m = EDHOC_KDF(PRK_1e, 2, TH_1, hash_length) MAC_2 = EDHOC_KDF(PRK_2m, 3, context_2, mac_length_2) SALT_2e3e3m = EDHOC_KDF(PRK_2m, 4, TH_2, hash_length) K_2 = EDHOC_KDF(PRK_2e3e3m, 5, TH_2, key_length) IV_2 = EDHOC_KDF(PRK_2e3e3m, 6, TH_2, key_length) MAC_3 = EDHOC_KDF(PRK_2e3e3m, 7, context_3, mac_length_3) K_3 = EDHOC_KDF(PRK_2e3e3m, 8, TH_3, key_length) IV_3 = EDHOC_KDF(PRK_2e3e3m, 9, TH_3, key_length) PRK_out = EDHOC_KDF(PRK_2e3e3m, 10, TH_4, hash_length) K_4 = EDHOC_KDF(PRK_2e3e3m, 11, TH_4, key_length) IV_4 = EDHOC_KDF(PRK_2e3e3m, 12, TH_4, iv_length) PRK_exporter= EDHOC_KDF(PRK_out, 13, h'', hash_length)

The pseudorandom key PRK_out is the output session key of a completed EDHOC session and is derived as follows: PRK_out = EDHOC_KDF( PRK_2e3e3m, TH_4, hash_length ) The context include the trascription hash TH_4, defined as: TH_4 = H( TH_3, PLAINTEXT_3, CRED_I ) Instead of reusing the last key-exchange internal key, the final key derivation depends on both PRK_2e3e3m and a newly computed TH_4, which include PLAINTEXT_3. This approach aims to ensure robust session keys that are distinct from the MAC keys and whose confirmation implies the authentication of all the handshake data.

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.

The message_1 SHALL be a CBOR Sequence as defined below. message_1 = ( pk_eph : bstr, ct_R : bstr, CIPHERTEXT_1: bstr, )

The Initiator SHALL compose message_1 as following: Construct the following elements of PLAINTEX_1: Chose KEM-based ikr authentication method 5. Construct SUITES_I following the specifications Chose a connection identifier C_I and store it during the EDHOC session, as in Encode PLAINTEXT_1 as a sequence of CBOR-encoded data items, as specified below: PLAINTEX_1 = ( METHOD : int, SUITES_I : suites, ID_CRED_I : bstr/ -24..23, C_I, C_I : bstr / -24..23, ? EAD_1, ) 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() Encapsulate the known beforehand static KEM public key of the Responder (pk_R) by 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 transcript hash TH_1 = H(pk_eph,ct_R) Compute the PRK_1e pseudorandom key from the static KEM shared secret ( ss_R ) used to authenticate the Responder. Compute K_1/IV1 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_1, the initialization vector IV_1 (if used by the AEAD algorithm), the plaintext PLAINTEXT_1, and the following parameters as input: protected = h'' external_aad = TH_1 K_1 and IV_1 are defined in PLAINTEXT_1 = ( METHOD, SUITES_I, ID_CRED_I, C_I, ?EAD_2 ) CIPHERTEXT_1 is the 'ciphertext' of COSE_Encrypt0. Encode message_1 as a sequence of CBOR-encoded data items as specified in

The Responder SHALL process message_1 in the following order: Decode message_1 Compute the KEM shared_secret ( ss_R ) for the authentication of the Responder by decapsulating the KEM ciphertext (ct_R) received in message_1 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 transcript hash TH_1 = H(pk_eph,ct_R) Compute the PRK_1e pseudorandom key from the static KEM shared secret ( ss_R ) used to authenticate the Responder. Compute K_1/IV1 as in Decrypt the COSE_Encrypt0 (CIPHERTEXT_1) as defined ], with the EDHOC AEAD algorithm in the selected cipher suite and the parameters defined in . Process PLAINTEXT_1 as specify in If all processing is completed successfully, then make ID_CRED_I and (if present) EAD_1 available to the application. Obtain the authentication credential (CRED_I) from the (ID_CRED_I) and the static KEM authentication key (pk_I) of the Initiator

The Initiator SHALL compose message_2 as following: message_2 = ( ct_eph : bstr, ct_I : bstr, CIPHERTEXT_2: bstr, )

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) Choose a connection identifier C_R and store it for the length of the EDHOC session. Compute the PRK_2m pseudorandom key from both the static KEM shared secret ( ss_R ) and the latest ephemeral KEM shared secret ( ss_eph ). Choose a connection identifier C_R as specified in Compute the transcript hash TH_2 = H( ct_eph, ct_I, H(message_1) ). Compute MAC_2 as defined in , with context_2 =<< C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >> The Responder authenticates with a PRK_2m derived from the KEM ephemeral shared secret and with the shared secret computed over its static KEM public key. The mac_lenght_2 is equal to the EDHOC MAC length of the selected cipher suit. The C_R, ID_CRED_R and CRED_R elements corresponds with the ones in The latest transcript hash TH_2 and the External Application Data included in message_2 (EAD_2) are used. 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 new PRK_2e3e3m from a chain that includes the KEM shared secret for the Authentication of the Responder ( ss_R ), the ephemeral KEM shared secret ( ss_eph ), and, the latest KEM shared secret for the Authentication of the Initiator ( ss_I ) as defined in Derive the session key K_2/IV2 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_2, the initialization vector IV_2 (if used by the AEAD algorithm), the plaintext PLAINTEXT_2, and the following parameters as input: protected = h'' external_aad = TH_2 K_2 and IV_2 are defined in PLAINTEXT_2 = ( C_R, ID_CRED_R, MAC_2, ?EAD_2 ) CIPHERTEXT_2 is the 'ciphertext' of COSE_Encrypt0. 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 PRK_2m pseudorandom key from both the static KEM shared secret ( ss_R ) and the latest ephemeral KEM shared secret ( ss_eph ) Compute the transcript hash TH_2 = H(ct_eph,ct_I,H(message_1)) Compute the KEM shared_secret ( ss_I ) for the authentication of the Initiator by decapsulating the KEM ciphertext (ct_I) received in message_2 using the Initiator 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_2e3e3m from a chain that includes the KEM shared secret for the Authentication of the Responder ( ss_R ), the ephemeral KEM shared secret ( ss_eph ), and the latest KEM shared secret for the Authentication of the Initiator ( ss_I ) as defined in Derive the session key K_2/IV2 as in . Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_2) as defined ], with the EDHOC AEAD algorithm in the selected cipher suite and the parameters defined in . Verify MAC_2 as defined in , and make the result of the verification available to the application. If all processing is completed successfully, then make ID_CRED_R and (if present) EAD_2 available to the application as in

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

The Initiator SHALL process the composition of message_3 as follows: Compute MAC_3 as defined in , with context_3 =<< C_I, ID_CRED_I, TH_2, CRED_I, ? EAD_3 >> The Initaiator authenticate with a PRK_2e3e3m derived from the three shared secrets, including the shared secret computed over its static KEM key ( ss_I ). The mac_lenght_3 is equal to the EDHOC MAC lenght of the selected cipher suit. The C_I, ID_CRED_I and CRED_I elements corresponds with the ones in The latest trascript hash TH_3 and the External Aplication Data include it on Message 3 (EAD_3) are used it. Compute the transcript hash TH_3=H(TH_2,PLAINTEXT_2,CRED_R) as specified in Derive the new session key K_3/IV_3 as defined 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 = ( MAC_3, ?EAD_5 ) CIPHERTEXT_3 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_3 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.

The Responder SHALL process message_3 in the following order: Decode message_3 Retrieve the protocol state using available message correlation; see . Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_3) as defined in , with the EDHOC AEAD algorithm in the selected cipher suite and the parameters defined in . Verify MAC_3 as defined in , and make the result of the verification available to the application. Compute the transcript hash TH_4 = H(TH_3,PLAINTEXT_3,CRED_I) Calculate PRK_out as defined in . The Initiator can now derive application keys using the EDHOC_Exporter interface; see

This section specifies message_4, which is OPTIONAL to support. Confirmation of the latest pseudorandom key (PRK_2e3e3m) is already provided by message_2 and message_3, which are encrypted with K_2/IV_2 and K_3/IV_3, respectively. Explicit confirmation of all prior handshake data can be achieved, if necessary, either by exchanging message_4 or by protecting the first application message from the Responder to the Initiator using a key derived from the EDHOC_Exporter. In both cases, authenticity is ensured through the use of keying material derived from PRK_2e3e3m and the latest transcript hash TH_4.

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

The Responder SHALL process the composition of message_4 as follows: Derive the new session key K_4/IV_4 as defined 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 = ( EAD_4 ) CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0. Encode message_4 as a CBOR data item as specified in

The Initiator SHALL process message_4 in the following order: Decode message_4 Retrieve the protocol state using available message correlation; see . 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 . Make (if present) EAD_4 available to the application for EAD processing

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-authkem-ikr-edhoc-02

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
7 (suggested)	Static KEM Key (IKR)	Static KEM Key (IKR)	[draft-pocero-authkem-ikr-edhoc-02]

The protocol design aligns with the fundamental PQNoise process described in . Specifically, the Initiator transmits its ephemeral public key in the first message, along with a key encapsulation targeting the Responder’s known static public key. The Initiator also includes its own credentials, unknown to the Responder, in the first message using ID_CRED_I. As defined in the I pattern of the Noise framework , this approach exposes the Initiator’s identity to a passive attacker. To mitigate this, the Initiator’s credentials are encrypted using a key derived from the Responder’s static public key, ensuring that only the intended Responder can decrypt the credentials. Full forward secrecy and explicit mutual authentication are achieved once the KEM-based ikr EDHOC handshake is completed, as in the static-DH EDHOC handshake. While this mechanism preserves the Initiator’s anonymity against active attackers, the identity is protected only by the Responder public key, which makes it vulnerable if the Responder’s static key is later compromised, and vulnerable to be replayed. This KEM-based authnetication method does not provide non-repudiation, but only implicit proof of participation as EDHOC with static DH keys. It also maintains an equivalent level of downgrade protection, as the negotiation base of the protocol is unchanged.