]> XLIM UMR CNRS 7252 - Limoges University

clement.papon@unilim.fr

XLIM UMR CNRS 7252 - Limoges University

maria-cristina.onete@unilim.fr

LAKE EDHOC Post-Quantum Authentication Key Exchange This document specifies two extensions to the Ephemeral Diffie-Hellman over COSE (EDHOC). These two protocol versions aim to provide quantum-resistance to the original EDHOC protocol, while reducing message-complexity with respect to parallel drafts. The document defines: (1) a 3-message quantum-resistant EDHOC proposal when the Initiator knows the Responder; in this version, the Initiator authenticates using a signature, while the Responder uses a KEM; (2) a 3-or-4-message quantum-resistant EDHOC proposal, which proposes a tradeoff between message-complexity and computational overhead.

Introduction This document aims to present new alternatives for rendering the Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol quantum-resistant. The main goal is to reduce the number of messages exchanged during the handshake, using a combination of KEMs and signatures, as well as Post-Quantum Cryptography (PQC) cipher suites, for secure key-exchange and authentication. In this draft we: propose, building on , a version of quantum-resistant EDHOC where the Initiator knows the Responder, but in a scenario where the Initiator authenticates with a signature (ML-DSA) and the Responder with a KEM (ML-KEM). propose, building on , a version of the protocol that requires, depending on the case, either only 3 or 4 mandatory messages. This second version reduces the message overhead, but comes at an additional computational overhead for (at least) one of the two parties. The two proposals in this draft can be viewed to extend (in the case of the first bullet-point) and respectively to provide an alternative (in the case of the second bullet-point) to the current proposal for quantum-resistant EDHOC.

Terminology and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts described in EDHOC , CBOR , CBOR Sequences , COSE Structures and Processing and COSE Algorithms .

Definitions

KEMs (Key Encapsulation Mechanisms) A Key Encapsulation Mechanism (KEM) consists of three algorithms: KEM.KeyGen: a probabilistic key generation algorithm, which takes as input a security parameter k and outputs a key pair (kem.sk, kem.pk), where kem.sk is secret and kem.pk is public. KEM.Encapsulation: a probabilistic encapsulation algorithm, which takes as input a KEM public key kem.pk, and generates a pair (ss, kem.ct), where ss is the shared-secret and kem.ct is a ciphertext. KEM.Decapsulation: a deterministic decapsulation algorithm, which takes as input a KEM secret key kem.sk and a KEM ciphertext kem.ct, and outputs the shared-secret ss (associated to kem.ct). In practice, if Alice and Bob use a KEM, Alice generates the public and private keys, sends the public key to Bob, who generates the shared-secret and ciphertext. He then returns the latter to Alice, who can subsequently recover the same shared-secret using her private key and the ciphertext.

Digital Signature A Digital Signature (DS) scheme consists of three algorithms: DS.KeyGen: a probabilistic key generation algorithm, which takes as input a security parameter k and outputs a key pair (sign.sk, sign.pk), where sign.sk is secret and sign.pk is public. DS.Sign: a probabilistic algorithm, which takes as input a signing secret key sign.sk and a message m, and generates a signature s. DS.Verify: a deterministic algorithm, which takes as input a signing public key sign.pk, a message m and a signature s, and outputs 1 if the signature is valid for the message, and 0 otherwise. In practice, if Alice and Bob use a DS scheme, Alice generates the public and private keys, and sends the public key to Bob. Later, Alice sends a message together with a signature to Bob. Bob can then verify the validity of the signature on the message under the public key.

Post-Quantum EDHOC when the Initiator knows the Responder (PQ-EDHOC-IKR)

Motivation In , the authors adopt an EDHOC approach for use cases where the Initiator already knows the identity of the Responder, in a post-quantum version using ephemeral and static KEMs for authentication. The Initiator, knowing the long-term public key of the Responder, can derive the shared-secret ss_R and compute a key, then encrypt part of the first message. It can thus send its identity directly and securely authenticate himself, since only the Responder with its long-term secret key can decrypt the first message. Knowing the Initiator's identity, the Responder can derive the second shared-secret ss_I and continue the key derivation schedule. Sending the encrypted second message allows it to securely confirm its identity to the Initiator. The key motivation behind our current proposal is a desire to reduce the message-complexity of quantum-resistant EDHOC. We propose an extension to draft proposal , which allows the Initiator and Responder to authenticate using different mechanisms -- much as in the original EDHOC. In particular, while the Responder still authenticates using a KEM, in our proposal the Initiator will use a signature. This approach comes with the following benefit: there is no need to partially encrypt the first message. Instead, during the third message, the Initiator calculates a MAC and signs it. Upon receiving the encrypted third message, the Responder, after decryption, authenticates the Initiator in the usual EDHOC manner.

PQ-EDHOC-IKR protocol overview

PQ-EDHOC-IKR protocol description We present here a high-level description of our PQ-EDHOC-IKR where the Initiator authenticates with a signature and the Responder with a KEM.

| message_1 | | | | kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, MAC_2, EAD_2) | <------------------------------------------------------------+ | message_2 | | | | AEAD(ID_CRED_I, SIGNATURE_3, EAD_3) | +------------------------------------------------------------> | message_3 | | | | AEAD(EAD_4) | <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | message_4 | ]]>

Figure 1: PQ-EDHOC-IKR (I sign, R kem) message flow.

Formatting and sending message_1 As in the usual EDHOC protocol, the first message (message_1) consists of: METHOD --> as specified in it is an integer specifying the authentication method the Initiator wants to use; SUITES_I --> it consists of an ordered set of algorithms supported by the Initiator and formatted as specified in ; C_I (and also as C_R, which will appears later) --> the Connection Identifiers chosen by the Initiator (C_I) and by the Responder (C_R) as specified in ; EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later) -> External Authorization Data, respectively included in message_1, message_2, message_3 (and optionally) message_4, and formatted as specified in ; kem.pk_eph --> the Ephemeral KEM public key generated by the Initiator; kem.ct_R --> based on the Responder long-term KEM public key, the Initiator computes ss_R and kem.ct_R with the KEM.Encapsulation algorithm. He keeps secret ss_R to compute, later, PRK_3e2m, and sends kem.ct_R to the Responder.

Processing message_1, formatting and sending message_2 On the reception of the first message, the Responder first recovers ss_R thanks to his long-term KEM secret key kem.sk_R and kem.ct_R, using the KEM.Decapsulation algorithm (if the decapsulation process fails, he aborts). He then proceeds as in the original EDHOC protocol with elements METHOD, SUITES_I, C_I and EAD_1. Finally, using kem.pk_eph and the KEM.Encapsulation algorithm, he computes the ephemeral ciphertext kem.ct_eph and the ephemeral shared-secret ss_eph. The Responder selects its Connection Identifier C_R as specified in . He then computes: TH_2 = H(kem.ct_eph, H(message_1)); PRK_2e = EDHOC_Extract(TH_2, ss_eph). And also, as in : KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length); SALT_3e2m = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length). Compared to , the computation of PRK_3e2m is modified as follows : PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R). The Responder now computes MAC_2 and assembles PLAINTEXT_2: MAC_2 = EDHOC_KDF(PRK_3e2m, 2, C_R, ID_CRED_R, TH_2, EAD_2, mac_length_2); PLAINTEXT_2 = (C_R, ID_CRED_R, MAC_2, EAD_2). So the second message consists of: kem.ct_eph --> the ephemeral ciphertext obtained with kem.pk_eph; CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2.

Processing message_2, formatting and sending message_3 On reception of the second message, the Initiator, using kemp.ct_eph, can compute the ephemeral shared-secret ss_eph. As the Responder did, he computes TH_2, PRK_2e and KEYSTREAM_2. He can now decipher and retrieve : PLAINTEXT_2 = CIPHERTEXT_2 XOR KEYSTREAM_2. Thanks to ID_CRED_R, the Initiator verifies the validity of the long-term KEM public key of the Responder, kemp.pk_R, and computes SALT_3e2m and PRK_3e2m, using the shared-secret ss_R he generates at the beginning of the exchange. At this point the Initiator is able to authenticate the Responder (at least, make sure he is talking to the endpoint he hopes to talk to). For that, he computes, as the Responder did, the MAC MAC_2. If it matches with the one he received, then he properly authenticated the Responder. Otherwise he aborts. It is now up to the Initiator to authenticate himself. To do so, the Initiator computes the following elements: TH_3 = H(TH_2, PLAINTEXT_2, ID_CRED_R); K_3 = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length); IV_3 = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length); MAC_3 = EDHOC_KDF(PRK_3e2m, 6, ID_CRED_I, TH_3, EAD_3, mac_length_3). In this version of the protocol, the Initiator authenticates itself to the Responder with a signature: SIGNATURE_3 = DS.Sign(sign.sk_I, (ID_CRED_I, TH_3, EAD_3, MAC_3, sign_length)) where sign.sk_I is the long-term signing private key of the Initiator. Setting PLAINTEXT_3 = (ID_CRED_I, SIGNATURE_3, EAD_3), the Initiator ciphers PLAINTEXT_3 with the AEAD encryption algorithm negociated in SUITES_I.

Processing message_3 On reception of message_3, the Responder computes TH_3, K_3, and IV_3 as the Initiator did, and deciphers CIPHERTEXT_3 with the AEAD decryption algorithm. With PLAINTEXT_3, he can compute MAC_3 on his side, and verify the signature: DS.Verify(sign.pk_I, (ID_CRED_I, TH_3, EAD_3, MAC_3, sign_length), SIGNATURE_3) where sign.pk_I is the long-term signing public key of the Initiator. If the verification algorithm returns 1, the Responder properly authenticated the Initiator. Otherwise he aborts.

Optionally formatting, sending and receiving message_4 If the Responder decides of a fourth mandatory message, he then computes the following elements: TH_4 = H(TH_3, PLAINTEXT_3, ID_CRED_I); K_4 = EDHOC_KDF(PRK_3e2m, 8, TH_4, key_length); IV_4 = EDHOC_KDF(PRK_3e2m, 9, TH_4, iv_length). Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = EAD_4 and sends it to the Initiator. The latter computes TH_4, K_4, IV_4, and deciphers CIPHERTEXT_4 thanks to the AEAD decryption algorithm.

Computing the session key PRK_out It doesn't matter if there is a fourth mandatory message, in any case, both the Initiator and the Responder, in order to compute the key PRK_out, have to calculate the fourth transcript hash: TH_4 = H(TH_3, PLAINTEXT_3, ID_CRED_I). With that element, using the EDHOC_KDF algorithm, they both obtain: PRK_out = EDHOC_KDF(PRK_3e2m, 7, TH_4, hash_length) which is the desired session key, and the authentication process is fully achieved.

Key Derivation Schedule In this section we summarize the key derivation operations that appears throughout the protocol.

|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR| +------+ +-------+ +---+--+ +---+--+ +-----------+ +-+-+ | | | | | v | +-+--+ +---------+--+ | |TH_2| |CIPHERTEXT_2| | +--+-+ +------------+ +---+--+ | |Expand|--------+ +---+--+ | | +-----+---+ +------|SALT_3e2m| | +---------+ | +----+ +---+---+ +--------+ +------+ +-----+ |ss_R|-->|Extract|-->|PRK_3e2m|-->|Expand|-->|MAC_2| +----+ +-------+ +---+----+ +------+ +-----+ | PLAINTEXT_3 | | | +------+ +--------+ +--+-+ +--------|Expand|-->|K_3/IV_3|-->|AEAD| | +---+--+ +--------+ +--+-+ | | | | | v | | +-------+----+ | | |CIPHERTEXT_3| | | +------------+ | | | +--------+---------------------------+ | |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)| | +------------------------------------+ | | +------+ +-----+ +-----------+ +-------|Expand|-->|MAC_3|-->|SIGNATURE_3| | +------+ +-----+ +-----------+ | | PLAINTEXT_4 | | | +------+ +--------+ +--+-+ message_4? +--------|Expand|-->|K_4/IV_4|-->|AEAD| | +---+--+ +--------+ +--+-+ | | | | | v | | +-------+----+ | | |CIPHERTEXT_4| | | +------------+ | | | +--------+---------------------------+ | |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)| | +--------+---------------------------+ | | | | | +---+--+ +-------+ +--------|Expand|-->|PRK_out| +------+ +-------+ ]]>

Figure 2: PQ-EDHOC-IKR (I sign, R kem) key derivation schedule. So we can summarize the different computations as in :

Additional explanations We detail here the main elements that differ from the original EDHOC protocol.

Ephemeral KEM As explained in , the usual ephemeral Diffie-Hellman elements (x,g^x) and (y,g^y), are here replaced by an ephemeral KEM: At first, the Initiator generates a ephemeral KEM key pair (kem.sk_eph, kem.pk_eph) using the KEM.KeyGen(k) algorithm (where k is a security parameter); On reception of the ephemeral KEM public key kemp.pk_eph, the Responder generates a pair (ss_eph, kem.ct_eph) with the KEM.Encapsulation algorithm (with input kem.pk_eph). The element ss_eph is the ephemeral shared-secret, later used to derive a key, and kem.ct_eph is the ephemeral KEM ciphertext, used by the Initiator to retrieve the ephemeral shared-secret; On reception of the ephemeral KEM ciphertext, the Initiator recovers the ephemeral shared-secret ss_eph thanks to the KEM.Decapsulation' algorithm (with input kem.sk_eph and kem.ct_eph`).

Authentication keys For the Initiator, the authentication key MUST be a static signing key pair (sign.sk_I, sign.pk_I) generated using a DS.KeyGen(k) algorithm (where k is a security parameter). For the Responder, the authentication key MUST be a static KEM key pair (kem.sk_R, kem.pk_R) generated using a KEM.KeyGen(k) algorithm (where k is a security parameter).

Key derivation In this version of the protocol, the EDHOC_Extract fonction is used to derive two keys, in a way that slightly differ from the original EDHOC protocol. PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2 and the IKM SHALL be the ephemeral shared-secret ss_eph; PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R) --> the salt SHALL be SALT_3e2m directly derived from PRK_2e, and the IKM SHALL be the 'static' shared-secret ss_R. Concerning PRK_out, there is no modifications compared to the original EDHOC protocol.

Analysis In summary, we retain here the use case proposed by , where the Initiator already knows the Responder identity. Our protocol proposes a hybridization between the protocol proposed by and EDHOC method 1. In other words, Diffie-Hellman elements are replaced with KEMs, and the Initiator authenticates here using a signature (instead of a KEM). An important difference with the proposal of concerns the first message message_1, which in our version is simplified and remains closer to the standard EDHOC structure. Indeed, the Initiator authenticates via a signature at the third message. So he no longer needs to derive a key and encrypt part of the first message to securely send its identity. The second message also finds itself simplified. Since the Initiator does not use KEM in this situation, the Responder has no need to generate a shared-secret ss_I and send the KEM ciphertext kem.ct_I. The second message is therefore closer to the usual EDHOC structure. Finally, the third message is almost 'identical' to the third message of the EDHOC method 1 protocol. It seems important to note that complete and secure authentication is ensured here entirely in three messages, and the fourth message is optional. Regarding the Key Derivation Schedule, the changes are minor compared to (adaptation of notations, especially for the IKM to take into account the post-quantum nature of the cryptographic material) and (simply one less key derivation, since the Initiator uses a signature rather than a static KEM). We will discuss security considerations further in this document. We will also soon present a byte comparison for each message.

KEM & Sign Authentication for Post-Quantum EDHOC

Motivation Our second idea is to propose a tradeoff, allowing for a reduced number of messages in the quantum-resistant EDHOC handshake, which come at a slightly higher computational overhead compared to . Starting from the standard EDHOC protocol, method 0 allows for mutual authentication via signature between both users. As proposed in , replacing classical signatures with post-quantum resistant signatures such as ML-DSA and ephemeral Diffie-Hellman elements with a KEM like ML-KEM seems reasonable to make EDHOC post-quantum resistant (even if this still needs to be proved). These two changes do not affect the number of mandatory messages, since the fundamental structure of the protocol is preserved (however a post-quantum signature will likely be more computationally expensive, just like a KEM). Things get complicated when trying to apply these modifications to the other three methods. Continuing on this track, we replace ephemeral Diffie-Hellman elements with an ephemeral KEM. This does not affect the usual structure of EDHOC. However, if we want to take it further and also replace long-term Diffie-Hellman elements with a KEM, managing asymmetric keys for the latter poses a problem when trying to preserve the authentication structure of EDHOC, namely a MAC derived from a long-term secret. As proposed in , we go from 3 to 4 or 5 mandatory messages to achieve complete mutual authentication. Here, we want to explore a different path. Our solution aims to strike a balance between the number of mandatory messages and the computations performed by each endpoint. The principle is as follows. Suppose that the Initiator authenticates with a signature and the Responder uses a KEM. In this case, we will need an obligatory fourth message (for the Initiator to authenticate the Responder via the MAC, as proposed in ). To avoid this obligatory fourth message and return to three, we propose removing the MAC MAC_2 used to authenticate the Responder (eliminating calculations on both sides) and replacing it with a signature from the Responder (adding calculations on both sides). To do this, the Responder signs an element (which should not be chosen randomly for security reasons and which must allow the Initiator to identify the session) and sends it directly (encrypted) in the second message. The Initiator can then immediately identify the Responder: it retrieves its identity from the encrypted message and verifies the signature. The rest of the protocol remains 'unchanged', and the calculation of PRK_out is possible directly after sending/receiving the third message (thus no more obligatory fourth message). The costs of calculations are compensated, but the delicate point remains the size of the second message (we will provide a bytes analysis for this message later). We decline this procedure when the Initiator wants to authenticate with a KEM and the Responder with a signature, or when both parties want to authenticate with KEMs. In these two latter cases, the number of mandatory messages compared to decreases from 5 to 4.

First case: Initiator signs, Responder KEM and signs We describe below the equivalent of EDHOC method 1. The Initiator will authenticate with a signature, and the Responder with a KEM and a signature.

Protocol overview

| message_1 | | | |kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, EAD_2, SIGNATURE_2)| <----------------------------------------------------------------+ | message_2 | | | | kem.ct_R, AEAD(ID_CRED_I, SIGNATURE_3, EAD_3) | +----------------------------------------------------------------> | message_3 | | | | AEAD(EAD_4) | <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | message_4 | ]]>

Figure 3: PQ-EDHOC, I Signs - R KEM & Signs message flow.

Protocol description

Formatting and sending message_1 As in the usual EDHOC protocol, the first message (message_1) consists of: METHOD --> as specified in it is an integer specifying the authentication method the Initiator wants to use; SUITES_I --> it consists of an ordered set of algorithms supported by the Initiator and formatted as specified in ; C_I (and also as C_R, which will appears later) --> the Connection Identifiers chosen by the Initiator (C_I) and by the Responder (C_R) as specified in ; EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later) -> External Authorization Data, respectively included in message_1, message_2, message_3 (and optionally) message_4, and formatted as specified in ; kem.pk_eph --> the Ephemeral KEM public key generated by the Initiator.

Processing message_1, formatting and sending message_2 On the reception of the first message, the Responder proceeds as in the original EDHOC protocol with elements METHOD, SUITES_I, C_I and EAD_1. In a second step, using kem.pk_eph and the KEM.Encapsulation algorithm, he computes the ephemeral ciphertext kem.ct_eph and the ephemeral shared-secret ss_eph. The Responder selects its Connection Identifier C_R as specified in . He then computes: TH_2 = H(kem.ct_eph, H(message_1)); PRK_2e = EDHOC_Extract(TH_2, ss_eph); KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length). The Responder now assembles PLAINTEXT_2: PLAINTEXT_2 = (C_R, ID_CRED_R, TH_2, EAD_2) then signs this message : SIGNATURE_2 = DS.Sign(sign.sk_R, (PLAINTEXT_2, sign_length)) where sign.sk_R is the long-term signing private key of the Responder, and finally ciphers PLAINTEXT_2A = (PLAINTEXT_2, SIGNATURE_2): CIPHERTEXT_2 = PLAINTEXT_2A XOR KEYSTREAM_2. So the second message then consists of: kem.ct_eph --> the ephemeral ciphertext obtained with kem.pk_eph; CIPHERTEXT_2. Important note: let us mention that the element signed by the Responder, for security considerations during the security analysis, could be subject to slight changes. However, it serves here to illustrate the principle proposed here.

Processing message_2, formatting and sending message_3 On reception of the second message, the Initiator, using kemp.ct_eph, can compute the ephemeral shared-secret ss_eph. As the Responder did, he computes TH_2, PRK_2e and KEYSTREAM_2. He can now decipher and retrieve : PLAINTEXT_2A = CIPHERTEXT_2 XOR KEYSTREAM_2. Thanks to ID_CRED_R, the Initiator obtains the long-term public keys of the Responder, kemp.pk_R and sign.pk_R. At first, he checks the validity of the signature of the Responder: DS.Verify(sign.pk_R, (PLAINTEXT_2, sign_length), SIGNATURE_2). If the verification algorithm returns 1, the Initiator properly authenticated the Responder. Otherwise he aborts. Assuming everything goes well, using the KEM encapsulation algorithm KEM.Encapsulation, and the long-term input material kem.pk_R of the Responder, the Initiator generated the couple (ss_R, kem.ct_R). The shared-secret ss_R will then serve as IKM for the computation of PRK_3e2m: SALT_3e2m = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length); PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R). It is now the turn of the Initiator to authenticate himself. To do so, he computes the following elements: TH_3 = H(TH_2, PLAINTEXT_2A, ID_CRED_R); K_3 = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length); IV_3 = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length); MAC_3 = EDHOC_KDF(PRK_3e2m, 6, ID_CRED_I, TH_3, EAD_3, mac_length_3) as in the original EDHOC protocol. Then comes the signature: SIGNATURE_3 = DS.Sign(sign.sk_I, (ID_CRED_I, TH_3, EAD_3, MAC_3, sign_length)) where sign.sk_I is the long-term signing private key of the Initiator. Setting PLAINTEXT_3 = (ID_CRED_I, SIGNATURE_3, EAD_3), the Initiator ciphers PLAINTEXT_3 with the AEAD encryption algorithm negociated in SUITES_I. The third message is then composed of: CIPHERTEXT_3; kem.ct_R.

Processing message_3 On reception of message_3, the Responder computes TH_3. He also used the KEM.Decapsulation algorithm with its long-term KEM private key kem.sk_R and the KEM ciphertext kem.ct_R, to obtain the shared-secret ss_R. He can now compute SALT_3e2m, PRK_3e2m, K_3, and IV_3 as the Initiator did, and deciphers CIPHERTEXT_3 with the AEAD decryption algorithm. With PLAINTEXT_3, he calculates MAC_3 on his side, and verifies the signature: DS.Verify(sign.pk_I, (ID_CRED_I, TH_3, EAD_3, MAC_3, sign_length), SIGNATURE_3) where sign.pk_I is the long-term signing public key of the Initiator. If the verification algorithm returns 1, the Initiator is properly authenticated to the Initiator. Otherwise the Responder aborts.

Optionally formatting, sending and receiving message_4 If the Responder decides of a fourth mandatory message, he then computes the following elements: TH_4 = H(TH_3, PLAINTEXT_3, ID_CRED_I); K_4 = EDHOC_KDF(PRK_3e2m, 8, TH_4, key_length); IV_4 = EDHOC_KDF(PRK_3e2m, 9, TH_4, iv_length). Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = EAD_4 and sends it to the Initiator. The latter computes TH_4, K_4, IV_4, and deciphers CIPHERTEXT_4 thanks to the AEAD decryption algorithm.

Computing the session key PRK_out Here again, it doesn't matter if there is a fourth mandatory message, in any case, both the Initiator and the Responder, in order to compute the key PRK_out, have to calculate the fourth transcript hash as in the original EDHOC protocol: TH_4 = H(TH_3, PLAINTEXT_3, ID_CRED_I). With this element, using the EDHOC_KDF, they both obtain: PRK_out = EDHOC_KDF(PRK_3e2m, 7, TH_4, hash_length) which is the desired session key, and the authentication process is fully achieved.

Associated key derivation schedule In this section we present the key derivation schedule of the previously described protocol version.

|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR| +------+ +-------+ +---+--+ +---+--+ +-----------+ +-+-+ | | | v | +---------+--+ | |CIPHERTEXT_2| | +---------+--+ | +---------+ +---+--+ |SALT_3e2m|<--|Expand| +---+-----+ +---+--+ PLAINTEXT_3 | | +----+ +---+---+ +--------+ +------+ +--------+ +--+-+ |ss_R|-->|Extract|-->|PRK_3e2m|-->|Expand|-->|K_3/IV_3|-->|AEAD| +----+ +-------+ +---+----+ +---+--+ +--------+ +--+-+ | | | | | v | | +-------+----+ | | |CIPHERTEXT_3| | | +------------+ | | | +--------+---------------------------+ | |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)| | +------------------------------------+ | | +------+ +-----+ +-----------+ +-------|Expand|-->|MAC_3|-->|SIGNATURE_3| | +------+ +-----+ +-----------+ | | PLAINTEXT_4 | | | +------+ +--------+ +--+-+ message_4? +--------|Expand|-->|K_4/IV_4|-->|AEAD| | +---+--+ +--------+ +--+-+ | | | | | v | | +-------+----+ | | |CIPHERTEXT_4| | | +------------+ | | | +--------+---------------------------+ | |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)| | +--------+---------------------------+ | | | | | +---+--+ +-------+ +--------|Expand|-->|PRK_out| +------+ +-------+ ]]>

Figure 4: PQ-EDHOC, I Signs - R KEM & Signs key derivation schedule. So we can summarize the different computations as previously:

Additional explanations We detail here the main elements that differ from the original EDHOC protocol.

Ephemeral KEM As previously explain the usual ephemeral Diffie-Hellman elements are replaced by an ephemeral KEM. In this protocol, it works exactly as we previously described.

Authentication keys For the Initiator, the authentication key MUST be a static signing key pair (sign.sk_I, sign.pk_I) generated using a DS.KeyGen(k) algorithm (where k is a security parameter). For the Responder, the authentication key MUST be: (1) a static KEM key pair (kem.sk_R, kem.pk_R) generated using a KEM.KeyGen(k) algorithm (where k is a security parameter) and (2) a static signing key pair (sign.sk_R, sign.pk_R) generated using a DS.KeyGen(k) algorithm (where k is a security parameter).

Key derivation In this version of the protocol, the keys PRK_2e and PRK_3e2m are obtain thanks to EDHOC_Extract fonction: PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2 and the IKM SHALL be the ephemeral shared-secret ss_eph; PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R) --> the salt SHALL be SALT_3e2m directly derived from PRK_2e, and the IKM SHALL be the 'static' shared-secret ss_R. Concerning PRK_out, here again, there is no modifications compared to the original EDHOC protocol.

Analysis In this version of the protocol, we assumed that the Initiator has a pair of static signature keys (sign.sk_I, sign.pk_I) and that the Responder has not only a pair of static signature keys (sign.sk_R, sign.pk_R) but also a pair of static KEM keys (kem.sk_R, kem.pk_R). This is not an unusual case. We can suppose that each user, when registering in a Public Key Infrastructure (PKI), provides pairs of keys of both types (signature and KEM), which they update regularly. The difference in our protocol is that the Responder is forced to use both types during the same AKE. From a technical point of view, the first message message_1 and the third message message_3 do not differ from those proposed in . Two major differences are worth noting regarding the messages. Firstly, here we have only an optional fourth message message_4. Secondly, our second message message_2 contains an additional signature SIGNATURE_2 in PLAINTEXT_2A (before ciphering) (we will propose a byte analysis of this message later). Finally, from a computational point of view, both the Initiator and the Responder no longer need to calculate the MAC MAC_2. In return, the Responder must sign a message, and the Initiator must verify this signature. Regarding the Key Derivation Schedule, aside from the IKM which adapts to post-quantum cryptographic material, we remain close to the one of EDHOC's method 1. We thus have a tradeoff between the size of messages, calculation capabilities, and the number of messages.

Second case: Initiator KEM and signs, Responder signs We now invert the roles and describe below the equivalent of EDHOC method 2. The Initiator will authenticate with a KEM and a signature, and the Responder only with a signature.

Protocol overview

| message_1 | | | |kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, EAD_2, SIGNATURE_2)| <----------------------------------------------------------------+ | message_2 | | | | AEAD(ID_CRED_I, EAD_3, SIGNATURE_3) | +----------------------------------------------------------------> | message_3 | | | | kem.ct_I, AEAD(EAD_4) | <----------------------------------------------------------------+ | message_4 | ]]>

Figure 5: PQ-EDHOC, I KEM & Signs - R Signs message flow.

Protocol description

Formatting and sending message_1 As for our previous protocol version, the first message (message_1) consists of: METHOD --> as specified in it is an integer specifying the authentication method the Initiator wants to use; SUITES_I --> it consists of an ordered set of algorithms supported by the Initiator and formatted as specified in ; C_I (and also as C_R, which will appears later) --> the Connection Identifiers chosen by the Initiator (C_I) and by the Responder (C_R) as specified in ; EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later) -> External Authorization Data, respectively included in message_1, message_2, message_3 (and optionally) message_4, and formatted as specified in ; kem.pk_eph --> the Ephemeral KEM public key generated by the Initiator.

Processing message_1, formatting and sending message_2 On the reception of the first message, the Responder proceeds as in the original EDHOC protocol with elements METHOD, SUITES_I, C_I and EAD_1. In a second step, using kem.pk_eph and the KEM.Encapsulation algorithm, he computes the ephemeral ciphertext kem.ct_eph and the ephemeral shared-secret ss_eph. The Responder selects its Connection Identifier C_R as specified in . He then computes: TH_2 = H(kem.ct_eph, H(message_1)); PRK_2e = EDHOC_Extract(TH_2, ss_eph); KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length). In order to authenticate himself to the Initiator, in this version, similarly to the EDHOC method 2, the Responder computes a MAC MAC_2 and signs it with its long-term signing private key sign.sk_R: MAC_2 = EDHOC_KDF(PRK_2e, 2, C_R, ID_CRED_R, TH_2, EAD_2, mac_length_2); SIGNATURE_2 = DS.Sign(sign.sk_R, (C_R, ID_CRED_R, TH_2, EAD_2, MAC_2, sign_length)). The Responder now assembles PLAINTEXT_2: PLAINTEXT_2 = (C_R, ID_CRED_R, SIGNATURE_2, EAD_2) then ciphers this message : CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 and finally sends message_2 composed of CIPHERTEXT_2 and kem.ct_eph. So, so far, except the ephemeral KEM material, everything works like in the usual EDHOC method 2 protocol.

Processing message_2, formatting and sending message_3 On reception of the second message, the Initiator, using kemp.ct_eph, can compute the ephemeral shared-secret ss_eph. As the Responder did, he computes TH_2, PRK_2e and KEYSTREAM_2. He can now decipher and retrieve : PLAINTEXT_2 = CIPHERTEXT_2 XOR KEYSTREAM_2. Thanks to ID_CRED_R, the Initiator obtains the long-term signing public key of the Responder, sign.pk_R. He can then compute MAC_2 on its own, and check the validity of the signature of the Responder: DS.Verify(sign.pk_R, (C_R, ID_CRED_R, TH_2, EAD_2, MAC_2, sign_length), SIGNATURE_2). If the verification algorithm returns 1, the Initiator properly authenticated the Responder. Otherwise he aborts. Assuming everything goes well, the Initiator computes the following elements: TH_3 = H(TH_2, PLAINTEXT_2, ID_CRED_R); K_3 = EDHOC_KDF(PRK_2e, 3, TH_3, key_length); IV_3 = EDHOC_KDF(PRK_2e, 4, TH_3, iv_length). Then, in order to authenticate, he forms PLAINTEXT_3 = (ID_CRED_I, TH_3, EAD_3) and signs it: SIGNATURE_3 = DS.Sign(sign.sk_I, (PLAINTEXT_3, sign_length)). where sign.sk_I is the long-term signing private key of the Initiator. Finally he ciphers PLAINTEXT_3A = (PLAINTEXT_3, SIGNATURE_3) with the AEAD encryption algorithm negociated in SUITES_I, as CIPHERTEXT_3. The third message is then composed of: CIPHERTEXT_3. Important note: let us mention that the element signed by the Initiator, here again, for security considerations during the security analysis, could be subject to slight changes.

Processing message_3, formatting and sending message_4 On reception of message_3, the Responder computes TH_3, K_3 and IV_3, and deciphers CIPHERTEXT_3 with the AEAD decryption algorithm. With PLAINTEXT_3A, he obtains the Initiator's long-term signing public key, and so he verifies the signature: DS.Verify(sign.pk_I, (PLAINTEXT_3, sign_length), SIGNATURE_3). If the verification algorithm returns 1, the Initiator is properly authenticated to the Initiator. Otherwise the Responder aborts. With PLAINTEXT_3, the Responder also gets the Initiator's long-term KEM public key. He then uses the KEM.Encapsulation algorithm to generate ss_I and kem.ct_I. Following that, he computes: TH_4 = H(TH_3, PLAINTEXT_3A, ID_CRED_I); SALT_4e3m = EDHOC_KDF(PRK_2e, 5, TH_4, hash_length); PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I); K_4 = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length); IV_4 = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length). Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = EAD_4 and sends it to the Initiator, along with kem.ct_I. He then finishes the AKE by computing the final key PRK_out: PRK_out = EDHOC_KDF(PRK_4e3m, 7, TH_4, hash_length).

Processing message_4 In this situation the fourth message is mandatory. It is used to send the KEM ciphertext kem.ct_I to the Initiator (it cannot be shared before, since the Responder only learns the identity of the Initiator with the third message). When receiving this last message, the Initiator computes the shared-secret ss_I thanks to the KEM.Decapsulation algorithm, and elements kem.sk_I, kem.ct_I. After that, he can compute TH_4, K_4, IV_4, and decipher CIPHERTEXT_4 thanks to the AEAD decryption algorithm. Once he had checked the well formedness of PLAINTEXT_4, he can finally compute PRK_out as the Responder did.

Associated key derivation schedule In this section we present the key derivation schedule of the previously described protocol version.

|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR| +------+ +-------+ +---+--+ +---+--+ +-----------+ +-+-+ | | | v | +---------+--+ | |CIPHERTEXT_2| | +------------+ | | +------+ +-----+ +-----------+ +-----|Expand|-->|MAC_2|-->|SIGNATURE_2| | +------+ +-----+ +-----------+ | | +------------------------------------+ | |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)| | +--------+---------------------------+ | | | | PLAINTEXT_3A | | | | +---+--+ +--------+ +--+-+ +------|Expand|-->|K_3/IV_3|-->|AEAD| | +---+--+ +--------+ +--+-+ | | | v | +-------+----+ | |CIPHERTEXT_3| | +-------+----+ | +---------+ +---+--+ |SALT_4e3m|<--|Expand| +---+-----+ +---+--+ PLAINTEXT_4 | | +----+ +---+---+ +--------+ +------+ +--------+ +--+-+ |ss_I|-->|Extract|-->|PRK_4e3m|-->|Expand|-->|K_4/IV_4|-->|AEAD| +----+ +-------+ +---+----+ +---+--+ +--------+ +--+-+ | | | | | v | | +-------+----+ | | |CIPHERTEXT_4| | | +------------+ | | | +--------+---------------------------+ | |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)| | +--------+---------------------------+ | | | +---+--+ +-------+ +--------|Expand|-->|PRK_out| +------+ +-------+ ]]>

Figure 6: PQ-EDHOC, I KEM & Signs - R Signs key derivation schedule. So we can summarize the different computations as previously:

Additional explanations We detail here the main elements that differ from the original EDHOC protocol.

Ephemeral KEM As previously explain the usual ephemeral Diffie-Hellman elements are replaced by an ephemeral KEM. In this protocol, it works exactly as we previously described.

Authentication keys For the Initiator, the authentication key MUST be: (1) a static KEM key pair (kem.sk_I, kem.pk_I) generated using a KEM.KeyGen(k) algorithm (where k is a security parameter) and (2) a static signing key pair (sign.sk_I, sign.pk_I) generated using a DS.KeyGen(k) algorithm (where k is a security parameter). For the Responder, the authentication key MUST be a static signing key pair (sign.sk_R, sign.pk_R) generated using a DS.KeyGen(k) algorithm (where k is a security parameter).

Key derivation In this version of the protocol, the keys PRK_2e and PRK_4e3m are obtain thanks to EDHOC_Extract fonction: PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2 and the IKM SHALL be the ephemeral shared-secret ss_eph; PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I) --> the salt SHALL be SALT_4e3m directly derived from PRK_2e, and the IKM SHALL be the 'static' shared-secret ss_I. Concerning PRK_out, here again, there is no modifications compared to the original EDHOC protocol. We can note that in this two previous cases, the Key Derivation Schedule remains close to the standard EDHOC Key Derivation Schedule of method 1 and 2.

Analysis This is actually a mirror version of the previous protocol presented, in the sense that this time we assumed that the Responder has a pair of static signature keys (sign.sk_R, sign.pk_R) and that the Initiator has not only a pair of static signature keys (sign.sk_I, sign.pk_I) but also a pair of static KEM keys (kem.sk_I, kem.pk_I). For the same reasons, this is not an unusual case. From a technical point of view, messages message_1,message_2 and message_4 do not differ from those proposed in . Here again, two major differences are worth noting regarding the messages. Firstly, here we no more have a fifth mandatory message message_5. Secondly, our third message message_3 contains an additional signature SIGNATURE_3 in PLAINTEXT_3A (before ciphering) (as this was the case for the previous protocol we propose, with SIGNATURE_2) (we will propose a byte analysis of this message later). Finally, from a computational point of view, both the Initiator and the Responder no longer need to calculate the MAC MAC_3. In return, in the same vein, the Initiator must sign a message, and the Responder must verify this signature, in order to authenticate the Initiator, and send him the KEM ciphertext kem.ct_I. Regarding the Key Derivation Schedule, aside from the IKM which adapts to post-quantum cryptographic material, we remain close to the one of EDHOC's method 2. So compared to , we reduce the number of mandatory messages, from 5 to 4, and again we obtain a tradeoff between the size of messages, calculation capabilities, and the number of messages.

Third case: Initiator and Responder KEM and sign - version 1 We now present the equivalent of EDHOC method 3, which is in our case, an hybridation of the previous cases. We propose two variant of this version. We start here with the first one, where the Initiator authenticates with a KEM and a signature, and the Responder with only a KEM. More specifically, this first version is a kind of hybrid between a protocol proposed in and one of the protocols we have proposed above.

Protocol overview

| message_1 | | | | kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, EAD_2) | <--------------------------------------------------------------+ | message_2 | | | | kem.ct_R, AEAD(ID_CRED_I, EAD_3, SIGNATURE_3) | +--------------------------------------------------------------> | message_3 | | | | kem.ct_I, AEAD(EAD_4, MAC_2) | <--------------------------------------------------------------+ | message_4 | ]]>

Figure 7: PQ-EDHOC, I KEM & Signs - R KEM message flow.

Protocol description

Formatting and sending message_1 As for our previous protocol version, the first message (message_1) consists of: METHOD --> as specified in it is an integer specifying the authentication method the Initiator wants to use; SUITES_I --> it consists of an ordered set of algorithms supported by the Initiator and formatted as specified in ; C_I (and also as C_R, which will appears later) --> the Connection Identifiers chosen by the Initiator (C_I) and by the Responder (C_R) as specified in ; EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later) -> External Authorization Data, respectively included in message_1, message_2, message_3 (and optionally) message_4, and formatted as specified in ; kem.pk_eph --> the Ephemeral KEM public key generated by the Initiator.

Processing message_1, formatting and sending message_2 On the reception of the first message, the Responder proceeds as in the original EDHOC protocol with elements METHOD, SUITES_I, C_I and EAD_1. In a second step, using kem.pk_eph and the KEM.Encapsulation algorithm, he computes the ephemeral ciphertext kem.ct_eph and the ephemeral shared-secret ss_eph. The Responder selects its Connection Identifier C_R as specified in . He then computes: TH_2 = H(kem.ct_eph, H(message_1)); PRK_2e = EDHOC_Extract(TH_2, ss_eph); KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length). In this version the Responder authenticates with the fourth mandatory message. So he directly assembles PLAINTEXT_2: PLAINTEXT_2 = (C_R, ID_CRED_R, TH_2, EAD_2) then ciphers this message : CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 and finally sends message_2 composed of CIPHERTEXT_2 and kem.ct_eph.

Processing message_2, formatting and sending message_3 On reception of the second message, the Initiator, using kemp.ct_eph, can compute the ephemeral shared-secret ss_eph. As the Responder did, he computes TH_2, PRK_2e and KEYSTREAM_2. He can now decipher and retrieve : PLAINTEXT_2 = CIPHERTEXT_2 XOR KEYSTREAM_2. Thanks to ID_CRED_R, the Initiator obtains the long-term KEM public key of the Responder, kem.pk_R. He then uses the KEM.Encapsulation algorithm to generate ss_R and kem.ct_R. He then computes the following elements: SALT_3e2m = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length); PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R); TH_3 = H(TH_2, PLAINTEXT_2, ID_CRED_R); K_3 = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length); IV_3 = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length). Then, in order to authenticate, he then forms PLAINTEXT_3 = (ID_CRED_I, TH_3, EAD_3) and signs it: SIGNATURE_3 = DS.Sign(sign.sk_I, (PLAINTEXT_3, sign_length)) where sign.sk_I is the long-term signing private key of the Initiator. Finally he sets PLAINTEXT_3A = (PLAINTEXT_3, SIGNATURE_3) and ciphers it with the AEAD encryption algorithm negociated in SUITES_I, as CIPHERTEXT_3. The third message is then composed of: kem.ct_R; CIPHERTEXT_3.

Processing message_3, formatting and sending message_4 On reception of message_3, the Responder computes TH_3. He also used the KEM.Decapsulation algorithm with its long-term KEM private key kem.sk_R and the KEM ciphertext kem.ct_R, to obtain the shared-secret ss_R. He can now compute SALT_3e2m, PRK_3e2m, K_3, and IV_3 as the Initiator did, and deciphers CIPHERTEXT_3 with the AEAD decryption algorithm. With PLAINTEXT_3A, he obtains kem.pk_I and sign.pk_I, and verifies the signature: DS.Verify(sign.pk_I, (PLAINTEXT_3, sign_length), SIGNATURE_3). If the verification algorithm returns 1, the Initiator is properly authenticated to the Initiator. Otherwise the Responder aborts. He then uses the KEM.Encapsulation algorithm to generate ss_I and kem.ct_I. Following that, he computes: TH_4 = H(TH_3, PLAINTEXT_3A, ID_CRED_I); SALT_4e3m = EDHOC_KDF(PRK_3e2m, 5, TH_4, hash_length); PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I); K_4 = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length); IV_4 = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length). The Responder now needs to authenticate. For that, he computes a MAC MAC_2: MAC_2 = EDHOC_KDF(PRK_4e3m, 2, C_R, ID_CRED_R, TH_4, EAD_4, mac_length_2). Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = (EAD_4, MAC_2) and sends it to the Initiator, along with kem.ct_I. He then finishes the AKE by computing the final key PRK_out: PRK_out = EDHOC_KDF(PRK_4e3m, 7, TH_4, hash_length).

Processing message_4 In this situation the fourth message is mandatory. It is used to send the KEM ciphertext kem.ct_I to the Initiator (it cannot be shared before, since the Responder only learns the identity of the Initiator with the third message). When receiving this last message, the Initiator computes the shared-secret ss_I thanks to the KEM.Decapsulation algorithm, and elements kem.sk_I, kem.ct_I. After that, he can compute TH_4, K_4, IV_4, and decipher CIPHERTEXT_4 thanks to the AEAD decryption algorithm. Once he had checked the well formedness of PLAINTEXT_4, he can authenticate the Responder by computing MAC_2 on its own and comparing with the one he finds in PLAINTEXT_4. If everything goes well, he finally computes PRK_out as the Responder did.

Associated key derivation schedule In this section we present the key derivation schedule of the previously described protocol version.

|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR| +------+ +-------+ +---+--+ +---+--+ +-----------+ +-+-+ | | | v | +---------+--+ | |CIPHERTEXT_2| | +------------+ +---------+ +---+--+ |SALT_3e2m|<--|Expand| +---+-----+ +---+--+ | +------------------------------------+ | |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)| | +-------+----------------------------+ | | | | PLAINTEXT_3A | | | +----+ +---+---+ +--------+ +--+---+ +--------+ +--+-+ |ss_R|-->|Extract|-->|PRK_3e2m|-->|Expand|-->|K_3/IV_3|-->|AEAD| +----+ +-------+ +---+----+ +---+--+ +--------+ +--+-+ | | | v | +-------+----+ | |CIPHERTEXT_3| | +-------+----+ | +---------+ +---+--+ |SALT_4e3m|<--|Expand| +---+-----+ +---+--+ | +----+ +---+---+ +--------+ +------+ +-----+ |ss_I|-->|Extract|-->|PRK_4e3m|-->|Expand|-->|MAC_2| +----+ +-------+ +---+----+ +------+ +-----+ | | PLAINTEXT_4 | | | +------+ +--------+ +--+-+ +--------|Expand|-->|K_4/IV_4|-->|AEAD| | +---+--+ +--------+ +--+-+ | | | | | v | | +-------+----+ | | |CIPHERTEXT_4| | | +------------+ | | | +--------+---------------------------+ | |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)| | +--------+---------------------------+ | | | +---+--+ +-------+ +--------|Expand|-->|PRK_out| +------+ +-------+ ]]>

Figure 8: PQ-EDHOC, I KEM & Signs - R KEM key derivation schedule. As above, we summarize the different computations:

Additional explanations We detail here the main elements that differ from the original EDHOC protocol.

Ephemeral KEM As previously explain the usual ephemeral Diffie-Hellman elements are replaced by an ephemeral KEM. In this protocol, it works exactly as we previously described.

Authentication keys For the Initiator, the authentication key MUST be: (1) a static KEM key pair (kem.sk_I, kem.pk_I) generated using a KEM.KeyGen(k) algorithm (where k is a security parameter) and (2) a static signing key pair (sign.sk_I, sign.pk_I) generated using a DS.KeyGen(k) algorithm (where k is a security parameter). For the Responder, the authentication key MUST be a static KEM key pair (kem.sk_R, kem.pk_R) generated using a KEM.KeyGen(k) algorithm (where k is a security parameter).

Key derivation In this version of the protocol, the keys PRK_2e, PRK_3e2m and PRK_4e3m are obtain thanks to EDHOC_Extract fonction: PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2 and the IKM SHALL be the ephemeral shared-secret ss_eph; PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R) --> the salt SHALL be SALT_3e2m directly derived from PRK_2e, and the IKM SHALL be the 'static' shared-secret ss_R. PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I) --> the salt SHALL be SALT_4e3m directly derived from PRK_3e2m, and the IKM SHALL be the 'static' shared-secret ss_I. Concerning PRK_out, here again, there is no modifications compared to the original EDHOC protocol.

Analysis This variant combines our PQ-EDHOC I KEM & Signs - R Signs protocol with the version where the Initiator and Responder authenticate using a KEM, as presented in . The advantage of this alternative is that it preserves Responder authentication via a KEM and simply asks the Initiator to sign its identity. Additionally, there is no longer need to calculate the MAC MAC_3. In this variant, we assumed that the Initiator has a pair of static signature keys (sign.sk_I, sign.pk_I) and also a pair of static KEM keys (kem.sk_I, kem.pk_I), and that the Responder has only a pair of static KEM keys (kem.sk_R, kem.pk_R). As already explain, this is not an unusual case. From a technical point of view, messages message_1,message_2 and message_4 do not differ from those proposed in . Again, two major differences are worth noting regarding the messages. Firstly, here we no more have a fifth mandatory message message_5. Secondly, our third message message_3 contains an additional signature SIGNATURE_3 in PLAINTEXT_3A(befoire ciphering) (as this was the case for protocols that we have proposed above, with SIGNATURE_2 or SIGNATURE_3) (we will propose a byte analysis of this message later). Finally, from a computational point of view, both the Initiator and the Responder no longer need to calculate the MAC MAC_3. In return, here again, the Initiator must sign a message, and the Responder must verify this signature, in order to authenticate the Initiator, and send him the KEM ciphertext kem.ct_I. Regarding the Key Derivation Schedule, aside from the IKM which adapts to post-quantum cryptographic material, we remain close to the one of EDHOC's method 3. So compared to , we reduce the number of mandatory messages, from 5 to 4, and again we obtain a tradeoff between the size of messages, calculation capabilities, and the number of messages.

Third case: Initiator and Responder KEM and sign - version 2 We now present the second variant of the equivalent of EDHOC method 3. In this situation both the Initiator and the Responder authenticate with a KEM and a signature, which makes this protocol a hybrid of two of the protocols we presented previously.

Protocol overview

| message_1 | | | |kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, EAD_2, SIGNATURE_2)| <----------------------------------------------------------------+ | message_2 | | | | kem.ct_R, AEAD(ID_CRED_I, EAD_3, SIGNATURE_3) | +----------------------------------------------------------------> | message_3 | | | | kem.ct_I, AEAD(EAD_4) | <----------------------------------------------------------------+ | message_4 | ]]>

Figure 9: PQ-EDHOC, I KEM & Signs - R KEM & Signs message flow.

Protocol description

Formatting and sending message_1 As for our previous protocol version, the first message (message_1) consists of: METHOD --> as specified in it is an integer specifying the authentication method the Initiator wants to use; SUITES_I --> it consists of an ordered set of algorithms supported by the Initiator and formatted as specified in ; C_I (and also as C_R, which will appears later) --> the Connection Identifiers chosen by the Initiator (C_I) and by the Responder (C_R) as specified in ; EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later) -> External Authorization Data, respectively included in message_1, message_2, message_3 (and optionally) message_4, and formatted as specified in ; kem.pk_eph --> the Ephemeral KEM public key generated by the Initiator.

Processing message_1, formatting and sending message_2 On the reception of the first message, the Responder proceeds as in the original EDHOC protocol with elements METHOD, SUITES_I, C_I and EAD_1. In a second step, using kem.pk_eph and the KEM.Encapsulation algorithm, he computes the ephemeral ciphertext kem.ct_eph and the ephemeral shared-secret ss_eph. The Responder selects its Connection Identifier C_R as specified in . He then computes: TH_2 = H(kem.ct_eph, H(message_1)); PRK_2e = EDHOC_Extract(TH_2, ss_eph); KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length). In this version, the Responder authenticates with message_2 thanks to a signature. So he assembles PLAINTEXT_2: PLAINTEXT_2 = (C_R, ID_CRED_R, TH_2, EAD_2) then signs this message : SIGNATURE_2 = DS.Sign(sign.sk_R, (PLAINTEXT_2, sign_length)) where sign.sk_R is the long-term signing private key of the Responder. And finally he ciphers PLAINTEXT_2A = (PLAINTEXT_2, SIGNATURE_2): CIPHERTEXT_2 = PLAINTEXT_2A XOR KEYSTREAM_2 So the second message then consists of: kem.ct_eph --> the ephemeral ciphertext obtained with kem.pk_eph; CIPHERTEXT_2.

Processing message_2, formatting and sending message_3 On reception of the second message, the Initiator, using kemp.ct_eph, can compute the ephemeral shared-secret ss_eph. As the Responder did, he computes TH_2, PRK_2e and KEYSTREAM_2. He can now decipher and retrieve : PLAINTEXT_2A = CIPHERTEXT_2 XOR KEYSTREAM_2. Thanks to ID_CRED_R, the Initiator obtains the long-term public keys of the Responder, kemp.pk_R and sign.pk_R. At first, he checks the validity of the signature of the Responder: DS.Verify(sign.pk_R, (PLAINTEXT_2, sign_length), SIGNATURE_2). If the verification algorithm returns 1, the Initiator properly authenticated the Responder. Otherwise he aborts. Using the KEM encapsulation algorithm KEM.Encapsulation, and the long-term input material kem.pk_R of the Responder, the Initiator generated the pair (ss_R, kem.ct_R). The shared-secret ss_R will then serve as IKM for the computation of PRK_3e2m: SALT_3e2m = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length); PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R). It is now the turn of the Initiator to authenticate himself. To do so, he computes the following elements: TH_3 = H(TH_2, PLAINTEXT_2A, ID_CRED_R); K_3 = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length); IV_3 = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length); assembles PLAINTEXT_3 = (ID_CRED_I, TH_3, EAD_3), and signs PLAINTEXT_3: SIGNATURE_3 = DS.Sign(sign.sk_I, (PLAINTEXT_3, sign_length)) where sign.sk_I is the long-term signing private key of the Initiator. Then, with the AEAD encryption algorithm negociated in SUITES_I, he ciphers PLAINTEXT_3A = (PLAINTEXT_3,SIGNATURE_3) as CIPHERTEXT_3. The third message is then composed of: kem.ct_R; CIPHERTEXT_3.

Processing message_3, formatting and sending message_4 On reception of message_3, the Responder computes TH_3, K_3 and IV_3, and deciphers CIPHERTEXT_3 with the AEAD decryption algorithm. With PLAINTEXT_3A, he obtains the Initiator's long-term public keys kem.pk_I and sign.pk_I, and so he verifies the signature: DS.Verify(sign.pk_I, (PLAINTEXT_3, sign_length), SIGNATURE_3). If the verification algorithm returns 1, the Initiator is properly authenticated to the Initiator. Otherwise the Responder aborts. He then uses the KEM.Encapsulation algorithm to generate ss_I and kem.ct_I. Following that, he computes: TH_4 = H(TH_3, PLAINTEXT_3A, ID_CRED_I); SALT_4e3m = EDHOC_KDF(PRK_3e2m, 5, TH_4, hash_length); PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I); K_4 = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length); IV_4 = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length). Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = EAD_4 and sends it to the Initiator, along with kem.ct_I. He then finishes the AKE by computing the final key PRK_out: PRK_out = EDHOC_KDF(PRK_3e2m, 7, TH_4, hash_length).

Processing message_4 In this situation the fourth message is mandatory. It is used to send the KEM ciphertext kem.ct_I to the Initiator (it cannot be shared before, since the Responder only learns the identity of the Initiator with the third message). When receiving this last message, the Initiator computes the shared-secret ss_I thanks to the KEM.Decapsulation algorithm, and elements kem.sk_I, kem.ct_I. After that, he can compute TH_4, K_4, IV_4, and decipher CIPHERTEXT_4 thanks to the AEAD decryption algorithm. Once he had checked the well formedness of PLAINTEXT_4, he can finally compute PRK_out as the Responder did.

Associated key derivation schedule In this section we present the key derivation schedule of the previously described protocol version.

|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR| +------+ +-------+ +---+--+ +---+--+ +-----------+ +-+-+ | | | v | +---------+--+ | |CIPHERTEXT_2| | +---------+--+ | +---------+ +---+--+ |SALT_3e2m|<--|Expand| +---+-----+ +---+--+ | +------------------------------------+ | |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)| | +-------+----------------------------+ | | | | PLAINTEXT_3A | | | +----+ +---+---+ +--------+ +--+---+ +--------+ +--+-+ |ss_R|-->|Extract|-->|PRK_3e2m|-->|Expand|-->|K_3/IV_3|-->|AEAD| +----+ +-------+ +---+----+ +---+--+ +--------+ +--+-+ | | | v | +-------+----+ | |CIPHERTEXT_3| | +-------+----+ | +---------+ +---+--+ |SALT_4e3m|<--|Expand| +---+-----+ +---+--+ PLAINTEXT_4 | | +----+ +---+---+ +--------+ +------+ +--------+ +--+-+ |ss_I|-->|Extract|-->|PRK_4e3m|-->|Expand|-->|K_4/IV_4|-->|AEAD| +----+ +-------+ +---+----+ +---+--+ +--------+ +--+-+ | | | | | v | | +-------+----+ | | |CIPHERTEXT_4| | | +------------+ | | | +--------+---------------------------+ | |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)| | +--------+---------------------------+ | | | +---+--+ +-------+ +--------|Expand|-->|PRK_out| +------+ +-------+ ]]>

Figure 8: PQ-EDHOC, I KEM & Signs - R KEM & Sings key derivation schedule. Here, we summarize the different computations:

Additional explanations We detail here the main elements that differ from the original EDHOC protocol.

Ephemeral KEM As previously explain the usual ephemeral Diffie-Hellman elements are replaced by an ephemeral KEM. In this protocol, it works exactly as we previously described.

Authentication keys For the Initiator, the authentication key MUST be: (1) a static KEM key pair (kem.sk_I, kem.pk_I) generated using a KEM.KeyGen(k) algorithm (where k is a security parameter) and (2) a static signing key pair (sign.sk_I, sign.pk_I) generated using a DS.KeyGen(k) algorithm (where k is a security parameter). For the Responder, the authentication key MUST be: (1) a static KEM key pair (kem.sk_R, kem.pk_R) generated using a KEM.KeyGen(k) algorithm (where k is a security parameter) and (2) a static signing key pair (sign.sk_R, sign.pk_R) generated using a DS.KeyGen(k) algorithm (where k is a security parameter).

Key derivation In this version of the protocol, the keys PRK_2e, PRK_3e2m and PRK_4e3m are obtain thanks to EDHOC_Extract fonction: PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2 and the IKM SHALL be the ephemeral shared-secret ss_eph; PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R) --> the salt SHALL be SALT_3e2m directly derived from PRK_2e, and the IKM SHALL be the 'static' shared-secret ss_R. PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I) --> the salt SHALL be SALT_4e3m directly derived from PRK_3e2m, and the IKM SHALL be the 'static' shared-secret ss_I. Concerning PRK_out, here again, there is no modifications compared to the original EDHOC protocol.

Analysis We conclude all these descriptions, with a last one variant which combines our PQ-EDHOC I KEM & Signs - R Signs protocol with our PQ-EDHOC I Signs - R KEM & Signs protocol. In this situation, both the Initiator and the Responder will authenticate using a signature, and there will be no longer MACs MAC_2 and MAC_3 to compute. In this variant, we assumed that the Initiator has a pair of static signature keys (sign.sk_I, sign.pk_I) and also a pair of static KEM keys (kem.sk_I, kem.pk_I), and that the Responder has a pair of static signature keys (sign.sk_R, sign.pk_R) and also a pair of static KEM keys (kem.sk_R, kem.pk_R). As already explain, this is not an unusual case. From a technical point of view, only message message_1 remains unchanged as the one proposed in . Here, four major differences are worth noting regarding the messages. Firstly, here we no more have a fifth mandatory message message_5. Secondly, our second and third messages message_2 and message_3 contain each an additional signature SIGNATURE_2 and SIGNATURE_3 respectively in PLAINTEXT_2A and in PLAINTEXT_3A. Moreover, the plaintext PLAINTEXT_4 no longer includes MAC_2, which implies that the ciphertext CIPHERTEXT_4 is lighter, and so is our fourth message message_4 (we will propose a byte analysis of these messages later). Finally, from a computational point of view, both the Initiator and the Responder no longer need to calculate the MACs MAC_2 and MAC_3. In return, both the Initiator and the Responder must sign a message and verify signature, in order to authenticate themselves. This allows the Initiator to authenticate the Responder directly when he receives the second message, and vice versa for the Responder when he receives the third message. That is why we no longer need MAC_2 and MAC_3 in the fourth and fifth messages. Regarding the Key Derivation Schedule, aside from the IKM which adapts to post-quantum cryptographic material, we remain close to the one of EDHOC's method 3. So compared to , we reduce the number of mandatory messages, from 5 to 4, and again we obtain a tradeoff between the size of messages, calculation capabilities, and the number of messages.

Security Considerations We propose here a global security analysis of our five proposals (if necessary, we number the protocols from 1 to 5 according to their order of appearance in the document). At the end of each handshake, both endpoints: securely compute the session key PRK_out; securely authenticate their partner. For the first protocol, the Responder authenticates through the MAC in message_2, while the Initiator authenticates through the signature produced in message_3. This approach is similar to that of EDHOC in method 1. For the second protocol, the Responder's authentication is guaranteed by its signature in message_2, while the Initiator authenticates through its signature in message_3. Note that in this protocol variant, the Responder's signature is securely ciphered in the second message. The third protocol is essentially a mirrored version of the second protocol, and the authentication methods of the Initiator and the Responder are switched. For the fourth protocol, this authentication is ensured by the Responder's MAC, sent in message_4, and the Initiator's signature, sent encrypted in message_3. Finally, for the fifth protocol, authentication is guaranteed by the Initiator's and Responder's signatures, both sent encrypted in the third and second message respectively. Our hybrid approaches (combining KEM and signature for authentication) follow the structure of the Key Derivation Schedule in EDHOC . The use of a 'static' shared-secret in key derivation strengthens the security of the key between two non-compromised parties (e.g., if the ephemeral KEM key of the session is compromised), and to some extent also strengthens forward-security and authentication (e.g., if a long-term signature secret key is compromised).

Forward Secrecy A forward-secrecy attacker could compromise the long-term signature key sign.sk and/or the static KEM secret key kem.sk for one of the endpoints, after that particular endpoint has completed a protocol session. The attacker's goal is to compromise the session key PRK_out. First note that compromising long-term signature keys does not compromise the security of past sessions. If the static KEM secret key of the Initiator kem.sk_I or of the Responder kem.sk_R (depending on the use case and protocol) is compromised, the attacker can retrieve the shared secrets ss_I or ss_R. However, this knowledge is insufficient to learn PRK_out. This is because, as in the case of EDHOC (and similarly to the recent proposals and ), PRK_out is derived from all shared secrets of the session, including the ephemeral KEM secret ss_eph. As a result, to recompute PRK_out, attackers would also need to compromise the ephemeral KEM secret ss_eph used in the session. Thus, each of the five protocols achieves Forward Secrecy (FS) provided that the ephemeral KEM secret ss_eph remains uncompromised.

Identity protection Protocol 1 is relatively close to the one proposed in . Concerning the Identity Protection property, in the way it is constructed, protocol 1 guarantees this property against passive attackers for the Responder and active attackers for the Initiator. Indeed, the same attacks as in EDHOC by an active attacker allow learning the identity of the Responder. Moreover, since all information about identities is encrypted from the second message onwards, this ensures Identity Protection against passive/active attackers for Responder/Initiator, provided that long-term keys are not compromised. However, we want to point out a disputed aspect regarding this property. We think it might be possible to reuse the security game introduced in , reused in and adapted in to prove Identity Protection. But this security game seems difficult to adapt to the protocol proposed in due to the encryption present in the first message. We suggest a more global approach for this property, possibly based on . To return to a more classical definition of Identity Protection property, protocols 2 to 5 keep a similar structure as EDHOC, and so inherit of this property. In other words, the identities of the Initiator and the Responder are never sent in plaintext, always encrypted, and only from the second message onwards. Moreover, the various signatures executed by the endpoints are encrypted in the messages and therefore do not appear in clear in the exchange, as this is the case in the original EDHOC protocol. According to the definition in , protocols 2 to 5 verify the Identity Protection property against passive attackers for the Responder and against active attackers for the Initiator. However, we can still keep our previous proposal in mind and try to prove this property in a more general framework for these protocols as well.

Downgrade Protection Our protocols protect against downgrade attacks in the same way as EDHOC since the choice of methods and cipher suites is included in the calculation of certain THs and is linked to Connection Identifiers of each session (and then to endpoint identities). As a result, we have the same Downgrade Protection as in EDHOC .

Transcript Hash Binding In our protocols, transcript hashes are constructed as in . They contain elements from previous messages as well as endpoint identities. They are also involved in the computation of derived and intermediaries keys (as explained in the Key Derivation Schedules). Thus, like EDHOC, they provide protection against misbinding attacks (since identities are linked to keys and messages via THs) and inter-session replay attacks (since any changes to a message or injected message from another session invalidates subsequent THs). Consequently, at each step of the handshake, the integrity of the process is verified using THs.

External Authorization Data (EAD) The External Authorization Data (EAD) in our protocols behaves similarly to what is done in EDHOC and . The first two messages message_1 and message_2 carry EAD (partially encrypted), which are not yet authenticated. This makes them potentially vulnerable to replay attacks by an active attacker. The last two messages message_3 and message_4 protect the EAD using either MAC or signature, as well as AEAD encryption. Thus, like in EDHOC , our 5 protocols' EAD data must be treated as untrusted until the handshake is successfully completed.

IANA Considerations This document has no IANA actions.

Ericsson Ericsson The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-DSA for digital signatures and ML-KEM for key exchange. This document specifies how EDHOC operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites. ISI, R.C. ATHENA ISI, R.C. ATHENA ISI, R.C. ATHENA ISI, R.C. ATHENA This document specifies extensions to the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) mechanisms for both key exchange and authentication. It defines a Key Encapsulation Mechanism (KEM)-based authentication method to enable signature-free post-quantum authentication when PQC KEMs, such as NIST-standardized ML-KEM, are used. The document further describes scenarios where both parties employ KEM-based authentication, as well as cases where authentication methods are combined, with one party using KEM-based authentication and the other relying on a PQC signature scheme. ISI, R.C. ATHENA ISI, R.C. ATHENA ISI, R.C. ATHENA ISI, R.C. ATHENA This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.