]> Ericsson

SE-164 40 Stockholm Sweden goran.selander@ericsson.com

Ericsson

SE-164 40 Stockholm Sweden john.mattsson@ericsson.com

ASSA ABLOY

32-080 Zabierzów Poland marek.serafin@assaabloy.com

RISE

SE-164 40 Stockholm Sweden marco.tiloca@ri.se

This document contains some example traces of Ephemeral Diffie-Hellman Over COSE (EDHOC).

EDHOC is a lightweight authenticated key exchange protocol designed for highly constrained settings. This document contains annotated traces of EDHOC protocol runs, with input, output and intermediate processing results to simplify testing of implementations. The document contains two traces: Section 3. Authentication with signature keys identified by the hash value of the X.509 certificates (provided in ). The endpoints use EdDSA for authentication and X25519 for ephemeral-ephemeral Diffie-Hellman key exchange. Section 4. Authentication with static Diffie-Hellman keys identified by short key identifiers labelling CWT Claim Sets (CCSs) . The endpoints use NIST P-256 (FIPS PUB 186-4) for both ephemeral-ephemeral and static-ephemeral Diffie-Hellman key exchange. This trace also illustrates the cipher suite negotiation, and provides an example of low protocol overhead, with messages sizes of (39, 45, 19) bytes. The traces in this draft are valid for version -14 and -15 of . Editor’s note: update reference to test vectors below: The test vector for trace 2 can be found at: https://github.com/lake-wg/edhoc/tree/master/test-vectors-15/

EDHOC is run between an Initiator (I) and a Responder (R). The private/public key pairs and credentials of I and R required to produce the protocol messages are shown in the traces when needed for the calculations. EDHOC messages and intermediate results are encoded in CBOR and can therefore be displayed in CBOR diagnostic notation using, e.g., the CBOR playground , which makes them easy to parse for humans. NOTE 1. The same name is used for hexadecimal byte strings and their CBOR encodings. The traces contain both the raw byte strings and the corresponding CBOR encoded data items. NOTE 2. If not clear from the context, remember that CBOR sequences and CBOR arrays assume CBOR encoded data items as elements. NOTE 3. When the protocol transporting EDHOC messages does not inherently provide correlation across all messages, like CoAP, then some messages typically are prepended with connection identifiers and potentially a message_1 indicator (see Section 3.4.1 and Appendix A.3 of ). Those bytes are not included in the traces in this document.

In this example the Initiator (I) and Responder (R) are authenticated with digital signatures (METHOD = 0). Both I and R support cipher suite 0, which determines the algorithms: EDHOC AEAD algorithm = AES-CCM-16-64-128 EDHOC hash algorithm = SHA-256 EDHOC MAC length in bytes (Static DH) = 8 EDHOC key exchange algorithm (ECDH curve) = X25519 EDHOC signature algorithm = EdDSA Application AEAD algorithm = AES-CCM-16-64-128 Application hash algorithm = SHA-256 The public keys are represented with X.509 certificates identified by the COSE header parameter ‘x5t’.

Both endpoints are authenticated with signatures, i.e. METHOD = 0:

I selects cipher suite 0. A single cipher suite is encoded as an int:

I creates an ephemeral key pair for use with the EDHOC key exchange algorithm:

I selects its connection identifier C_I to be the byte string 0x2d, which since it is represented by the 1-byte CBOR int -14 is encoded as 0x2d:

No external authorization data:

I constructs message_1:

R supports the most preferred and selected cipher suite 0, so SUITES_I is acceptable. R creates an ephemeral key pair for use with the EDHOC key exchange algorithm:

R selects its connection identifier C_R to be the byte string 0x18, which since it is not represented as a 1-byte CBOR int is encoded as h’18’ = 0x4118:

The transcript hash TH_2 is calculated using the EDHOC hash algorithm: TH_2 = H( G_Y, C_R, H(message_1) )

The input to calculate TH_2 is the CBOR sequence: G_Y, C_R, H(message_1)

PRK_2e is specified in Section 4.1.1.1 of . First, the ECDH shared secret G_XY is computed from G_X and Y, or G_Y and X:

Then, PRK_2e is calculated using Extract() determined by the EDHOC hash algorithm:

where salt is the zero-length byte string:

Since METHOD = 0, R authenticates using signatures. Since the selected cipher suite is 0, the EDHOC signature algorithm is EdDSA. R’s signature key pair using EdDSA:

PRK_3e2m is specified in Section 4.1.1.2 of . Since R authenticates with signatures PRK_3e2m = PRK_2e.

R constructs the remaining input needed to calculate MAC_2: MAC_2 = EDHOC-KDF( PRK_3e2m, 2, context_2, mac_length_2 ) context_2 = « ID_CRED_R, TH_2, CRED_R, ? EAD_2 » CRED_R is identified by a 64-bit hash:

where the COSE header value 34 (‘x5t’) indicates a hash of an X.509 certficate, and the COSE algorithm -15 indicates the hash algorithm SHA-256 truncated to 64 bits. ID_CRED_R (CBOR Data Item) (14 bytes) a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b CRED_R is a CBOR byte string of the DER encoding of the X.509 certificate in :

No external authorization data:

context_2 = « ID_CRED_R, TH_2, CRED_R, ? EAD_2 »

MAC_2 is computed through Expand() using the EDHOC hash algorithm, see Section 4.1.2 of : MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2), where info = ( 2, context_2, mac_length_2 ) Since METHOD = 0, mac_length_2 is given by the EDHOC hash algorithm. info for MAC_2 is:

where the last value is the output size of the EDHOC hash algorithm.

Since METHOD = 0, Signature_or_MAC_2 is the ‘signature’ of the COSE_Sign1 object. R constructs the message to be signed:

>, << TH_2, CRED_R, ? EAD_2 >>, MAC_2 ] = [ "Signature1", h'A11822822E4879F2A41B510C1F9B', h'58203AB11700841FCE193C323911EDB317B046DCF24B9950FD624884F7F57CD98 B0758F13081EE3081A1A003020102020462319EC4300506032B6570301D311B3019 06035504030C124544484F4320526F6F742045643235353139301E170D323230333 1363038323433365A170D3239313233313233303030305A30223120301E06035504 030C174544484F4320526573706F6E6465722045643235353139302A300506032B6 570032100A1DB47B95184854AD12A0C1A354E418AACE33AA0F2C662C00B3AC55DE9 2F9359300506032B6570034100B723BC01EAB0928E8B2B6C98DE19CC3823D46E7D6 987B032478FECFAF14537A1AF14CC8BE829C6B73044101837EB4ABC949565D86DCE 51CFAE52AB82C152CB02', h'7F0FB42EC3EDDB0DB794B8EFDD141E44CA039AA719C9E6618FEAF1E7833E589A' ] ]]>

R signs using the private authentication key SK_R

R constructs the plaintext without padding:

The input needed to calculate KEYSTREAM_2 is defined in Section 4.1.2 of , using Expand() with the EDHOC hash algorithm:

where plaintext_length is the length of PLAINTEXT_2, and info for KEYSTREAM_2 is:

where the last value is the length of PLAINTEXT_2.

R calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and KEYSTREAM_2:

R constructs message_2:

where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of the raw values of G_Y and CIPHERTEXT_2.

Since METHOD = 0, I authenticates using signatures. Since the selected cipher suite is 0, the EDHOC signature algorithm is EdDSA. I’s signature key pair using EdDSA:

PRK_4e3m is specified in Section 4.1.1.3 of . Since I authenticates with signatures PRK_4e3m = PRK_3e2m.

The transcript hash TH_3 is calculated using the EDHOC hash algorithm: TH_3 = H(TH_2, PLAINTEXT_2)

I constructs the remaining input needed to calculate MAC_3:

where

> ]]>

CRED_I is identified by a 64-bit hash:

where the COSE header value 34 (‘x5t’) indicates a hash of an X.509 certficate, and the COSE algorithm -15 indicates the hash algorithm SHA-256 truncated to 64 bits.

CRED_I is a CBOR byte string of the DER encoding of the X.509 certificate in :

No external authorization data:

context_3 = « ID_CRED_I, TH_3, CRED_I, ? EAD_3 »

MAC_3 is computed through Expand() using the EDHOC hash algorithm, see Section 4.1.2 of :

info = ( 6, context_3, mac_length_3 ) where context_3 = « ID_CRED_I, TH_3, CRED_I, ? EAD_3 » Since METHOD = 0, mac_length_3 is given by the EDHOC hash algorithm. info for MAC_3 is:

where the last value is the output size of the EDHOC hash algorithm.

Since METHOD = 0, Signature_or_MAC_3 is the ‘signature’ of the COSE_Sign1 object. I constructs the message to be signed:

>, << TH_3, CRED_I, ? EAD_3 >>, MAC_3 ] = [ "Signature1", h'A11822822E48C24AB2FD7643C79F', h'582077A51A1CF0EB60E4061BFC270887529C16B6F4B34D88A226E7065B60F4 15267158F13081EE3081A1A003020102020462319EA0300506032B6570301D 311B301906035504030C124544484F4320526F6F742045643235353139301E 170D3232303331363038323430305A170D3239313233313233303030305A30 223120301E06035504030C174544484F4320496E69746961746F7220456432 35353139302A300506032B6570032100ED06A8AE61A829BA5FA54525C9D07F 48DD44A302F43E0F23D8CC20B73085141E300506032B6570034100521241D8 B3A770996BCFC9B9EAD4E7E0A1C0DB353A3BDF2910B39275AE48B756015981 850D27DB6734E37F67212267DD05EEFF27B9E7A813FA574B72A00B430B', h'7778CC727BF840C9BFC97018A4D1297C5174430A1742AE976AC415E97A42CE55' ] ]]>

I signs using the private authentication key SK_I:

I constructs the plaintext without padding:

I constructs the associated data for message_3:

I constructs the input needed to derive the key K_3, see Section 4.1.2 of , using the EDHOC hash algorithm:

where key_length is the key length of EDHOC AEAD algorithm, and info for K_3 is:

where the last value is the key length of EDHOC AEAD algorithm.

I constructs the input needed to derive the nonce IV_3, see Section 4.1.2 of , using the EDHOC hash algorithm:

where iv_length is the nonce length of EDHOC AEAD algorithm, and info for IV_3 is:

where the last value is the nonce length of EDHOC AEAD algorithm.

I calculates CIPHERTEXT_3 as ‘ciphertext’ of COSE_Encrypt0 applied using the EDHOC AEAD algorithm with plaintext PLAINTEXT_3, additional data A_3, key K_3 and nonce IV_3.

message_3 is the CBOR bstr encoding of CIPHERTEXT_3:

The transcript hash TH_4 is calculated using the EDHOC hash algorithm: TH_4 = H(TH_3, PLAINTEXT_3)

No external authorization data:

R constructs the plaintext PLAINTEXT_4:

R constructs the associated data for message_4:

R constructs the input needed to derive the EDHOC message_4 key, see Section 4.1.2 of , using the EDHOC hash algorithm:

where key_length is the key length of the EDHOC AEAD algorithm, and info for EDHOC_K_4 is:

where the last value is the key length of EDHOC AEAD algorithm.

R constructs the input needed to derive the EDHOC message_4 nonce, see Section 4.1.2 of , using the EDHOC hash algorithm:

where length is the nonce length of EDHOC AEAD algorithm, and info for EDHOC_IV_4 is:

where the last value is the nonce length of EDHOC AEAD algorithm.

R calculates CIPHERTEXT_4 as ‘ciphertext’ of COSE_Encrypt0 applied using the EDHOC AEAD algorithm with plaintext PLAINTEXT_4, additional data A_4, key K_4 and nonce IV_4.

message_4 is the CBOR bstr encoding of CIPHERTEXT_4:

PRK_out is specified in Section 4.1.2 of .

where hash_length is the length of the output of the EDHOC hash algorithm, and info for PRK_out is:

where the last value is the length of EDHOC hash algorithm.

The OSCORE Master Secret and OSCORE Master Salt are derived with the EDHOC-Exporter as specified in 4.2.1 of .

where PRK_exporter is derived from PRK_out:

where hash_length is the length of the output of the EDHOC hash algorithm, and info for the PRK_exporter is:

where the last value is the length of EDHOC hash algorithm.

The derivation of OSCORE parameters is specified in Appendix A.1 of . The AEAD and Hash algorithms to use in OSCORE are given by the selected cipher suite:

The mapping from EDHOC connection identifiers to OSCORE Sender/Recipient IDs is defined in Section 3.3.3 of . C_R is mapped to the Recipient ID of the server, i.e., the Sender ID of the client. The byte string 0x18, which as C_R is encoded as the CBOR byte string 0x4118, is converted to the server Recipient ID 0x18.

C_I is mapped to the Recipient ID of the client, i.e., the Sender ID of the server. The byte string 0x2d, which as C_I is encoded as the CBOR integer 0x2d is converted to the client Recipient ID 0x2d.

The OSCORE Master Secret is computed through Expand() using the Application hash algorithm, see Appendix A.1 of :

where oscore_key_length is by default the key length of the Application AEAD algorithm, and info for the OSCORE Master Secret is:

where the last value is the key length of Application AEAD algorithm.

The OSCORE Master Salt is computed through Expand() using the Application hash algorithm, see Section 4.2 of :

where oscore_salt_length is the length of the OSCORE Master Salt, and info for the OSCORE Master Salt is:

where the last value is the length of the OSCORE Master Salt.

Key update is defined in Section 4.2.2 of .

where hash_length is the length of the output of the EDHOC hash function, context for KeyUpdate is

and where info for key update is:

After key update the PRK_exporter needs to be derived anew:

where info and hash_length as unchanged as in .

The OSCORE Master Secret is derived with the updated PRK_exporter:

where info and key_length are unchanged as in .

The OSCORE Master Salt is derived with the updated PRK_exporter:

where info and salt_length are unchanged as in .

In this example I and R are authenticated with ephemeral-static Diffie-Hellman (METHOD = 3). I supports cipher suites 6 and 2 (in order of preference) and R only supports cipher suite 2. After an initial negotiation message exchange cipher suite 2 is used, which determines the algorithms: EDHOC AEAD algorithm = AES-CCM-16-64-128 EDHOC hash algorithm = SHA-256 EDHOC MAC length in bytes (Static DH) = 8 EDHOC key exchange algorithm (ECDH curve) = P-256 EDHOC signature algorithm = ES256 Application AEAD algorithm = AES-CCM-16-64-128 Application hash algorithm = SHA-256 The public keys are represented as raw public keys (RPK), encoded in a CWT Claims Set (CCS) and identified by the COSE header parameter ‘kid’.

Both endpoints are authenticated with static DH, i.e. METHOD = 3:

I selects its preferred cipher suite 6. A single cipher suite is encoded as an int:

I creates an ephemeral key pair for use with the EDHOC key exchange algorithm:

I selects its connection identifier C_I to be the byte string 0x0e, which since it is represented by the 1-byte CBOR int 14 is encoded as 0x0e:

No external authorization data: EAD_1 (CBOR Sequence) (0 bytes) I constructs message_1:

R does not support cipher suite 6 and sends an error with ERR_CODE 2 containing SUITES_R as ERR_INFO. R proposes cipher suite 2, a single cipher suite thus encoded as an int.

Same steps are performed as message_1 first time, , but with updated SUITES_I. Both endpoints are authenticated with static DH, i.e. METHOD = 3:

I selects cipher suite 2 and indicates the more preferred cipher suite(s), in this case 6, all encoded as the array [6, 2]:

I creates an ephemeral key pair for use with the EDHOC key exchange algorithm:

I selects its connection identifier C_I to be the byte string 0x37, which since it is represented by the 1-byte CBOR int -24 is encoded as 0x37:

No external authorization data:

I constructs message_1:

R supports the selected cipher suite 2 and not the by I more preferred cipher suite(s) 6, so SUITES_I is acceptable. R creates an ephemeral key pair for use with the EDHOC key exchange algorithm:

R selects its connection identifier C_R to be the byte string 0x27, which since it is represented by the 1-byte CBOR int -8 is encoded as 0x27:

The transcript hash TH_2 is calculated using the EDHOC hash algorithm: TH_2 = H( G_Y, C_R, H(message_1) )

The input to calculate TH_2 is the CBOR sequence: G_Y, C_R, H(message_1)

PRK_2e is specified in Section 4.1.1.1 of . First, the ECDH shared secret G_XY is computed from G_X and Y, or G_Y and X:

Then, PRK_2e is calculated using Extract() determined by the EDHOC hash algorithm:

where salt is the zero-length byte string:

Since METHOD = 3, R authenticates using static DH. The EDHOC key exchange algorithm is based on the same curve as for the ephemeral keys, which is P-256, since the selected cipher suite is 2. R’s static Diffie-Hellman key pair for use with P-256:

MT This should be called SK_R Responder's private authentication key R (Raw Value) (32 bytes) 72 cc 47 61 db d4 c7 8f 75 89 31 aa 58 9d 34 8d 1e f8 74 a7 e3 03 ed e2 f1 40 dc f3 e6 aa 4a ac ]]>

Since R authenticates with static DH (METHOD = 3), PRK_3e2m is derived from SALT_3e2m and G_RX. The input needed to calculate SALT_3e2m is defined in Section 4.1.2 of , using Expand() with the EDHOC hash algorithm:.

where hash_length is the length of the output of the EDHOC hash algorithm, and info for SALT_3e2m is:

PRK_3e2m is specified in Section 4.1.1.2 of . PRK_3e2m is derived from G_RX using Extract() with the EDHOC hash algorithm:

where G_RX is the ECDH shared secret calculated from G_X and R, or G_R and X.

R constructs the remaining input needed to calculate MAC_2: MAC_2 = EDHOC-KDF( PRK_3e2m, 2, context_2, mac_length_2 ) context_2 = « ID_CRED_R, TH_2, CRED_R, ? EAD_2 » CRED_R is identified by a ‘kid’ with byte string value 0x32:

CRED_R is an RPK encoded as a CCS:

No external authorization data:

context_2 = « ID_CRED_R, TH_2, CRED_R, ? EAD_2 »

MAC_2 is computed through Expand() using the EDHOC hash algorithm, see Section 4.1.2 of : MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2), where info = ( 2, context_2, mac_length_2 ) Since METHOD = 3, mac_length_2 is given by the EDHOC MAC length. info for MAC_2 is:

where the last value is the EDHOC MAC length.

Since METHOD = 3, Signature_or_MAC_2 is MAC_2:

R constructs PLAINTEXT_2 without padding:

Since ID_CRED_R contains a single ‘kid’ parameter, only the byte string value is included in the plaintext, represented as described in Section 3.3.2 of . The CBOR map { 4 : h’32’ } is thus replaced, not by the CBOR byte string 0x4132, but by the CBOR int 0x32, since that is a one byte encoding of a CBOR integer (-19).

The input needed to calculate KEYSTREAM_2 is defined in Section 4.1.2 of , using Expand() with the EDHOC hash algorithm:

where plaintext_length is the length of PLAINTEXT_2, and info for KEYSTREAM_2 is:

where last value is the length of PLAINTEXT_2.

R calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and KEYSTREAM_2:

R constructs message_2:

where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of the raw values of G_Y and CIPHERTEXT_2.

The transcript hash TH_3 is calculated using the EDHOC hash algorithm: TH_3 = H( TH_2, PLAINTEXT_2 )

Since METHOD = 3, I authenticates using static DH. The EDHOC key exchange algorithm is based on the same curve as for the ephemeral keys, which is P-256, since the selected cipher suite is 2. I’s static Diffie-Hellman key pair for use with P-256:

Since I authenticates with static DH (METHOD = 3), PRK_4e3m is derived from SALT_4e3m and G_IY. The input needed to calculate SALT_4e3m is defined in Section 4.1.2 of , using Expand() with the EDHOC hash algorithm:.

where hash_length is the length of the output of the EDHOC hash algorithm, and info for SALT_4e3m is:

PRK_4e3m is specified in Section 4.1.1.3 of . PRK_4x3m is derived as specified in Section 4.1.3 of . Since I authenticates with static DH (METHOD = 3), PRK_4x3m is derived from G_IY using Extract() with the EDHOC hash algorithm:

where G_IY is the ECDH shared secret calculated from G_I and Y, or G_Y and I.

I constructs the remaining input needed to calculate MAC_3: MAC_3 = EDHOC-KDF( PRK_4e3m, 6, context_3, mac_length_3 ) context_3 = « ID_CRED_I, TH_3, CRED_I, ? EAD_3 » CRED_I is identified by a ‘kid’ with byte string value 0x2b:

ID_CRED_I (CBOR Data Item) (4 bytes) a1 04 41 2b CRED_I is an RPK encoded as a CCS:

No external authorization data:

context_3 = « ID_CRED_I, TH_3, CRED_I, ? EAD_3 »

MAC_3 is computed through Expand() using the EDHOC hash algorithm, see Section 4.1.2 of :

info = ( 6, context_3, mac_length_3 ) Since METHOD = 3, mac_length_3 is given by the EDHOC MAC length. info for MAC_3 is:

where the last value is the EDHOC MAC length.

Since METHOD = 3, Signature_or_MAC_3 is MAC_3:

I constructs PLAINTEXT_3 without padding:

Since ID_CRED_I contains a single ‘kid’ parameter, only the byte string value is included in the plaintext, represented as described in Section 3.3.2 of . The CBOR map { 4 : h’2b’ } is thus replaced, not by the CBOR byte string 0x412b, but by the CBOR int 0x2b, since that is a one byte encoding of a CBOR integer (-12).

I constructs the associated data for message_3:

I constructs the input needed to derive the key K_3, see Section 4.1.2 of , using the EDHOC hash algorithm:

where key_length is the key length of EDHOC AEAD algorithm, and info for K_3 is:

where the last value is the key length of EDHOC AEAD algorithm.

I constructs the input needed to derive the nonce IV_3, see Section 4.1.2 of , using the EDHOC hash algorithm:

where iv_length is the nonce length of EDHOC AEAD algorithm, and info for IV_3 is:

where the last value is the nonce length of EDHOC AEAD algorithm.

I calculates CIPHERTEXT_3 as ‘ciphertext’ of COSE_Encrypt0 applied using the EDHOC AEAD algorithm with plaintext PLAINTEXT_3, additional data A_3, key K_3 and nonce IV_3.

message_3 is the CBOR bstr encoding of CIPHERTEXT_3:

The transcript hash TH_4 is calculated using the EDHOC hash algorithm: TH_4 = H( TH_3, PLAINTEXT_3 )

No external authorization data: EAD_4 (CBOR Sequence) (0 bytes) R constructs the plaintext PLAINTEXT_4:

PLAINTEXT_4 (CBOR Sequence) (0 bytes) R constructs the associated data for message_4:

R constructs the input needed to derive the EDHOC message_4 key, see Section 4.1.2 of , using the EDHOC hash algorithm:

where key_length is the key length of the EDHOC AEAD algorithm, and info for EDHOC_K_4 is:

where the last value is the key length of EDHOC AEAD algorithm.

R constructs the input needed to derive the EDHOC message_4 nonce, see Section 4.1.2 of , using the EDHOC hash algorithm:

where iv_length is the nonce length of EDHOC AEAD algorithm, and info for EDHOC_IV_4 is:

where the last value is the nonce length of EDHOC AEAD algorithm.

R calculates CIPHERTEXT_4 as ‘ciphertext’ of COSE_Encrypt0 applied using the EDHOC AEAD algorithm with plaintext PLAINTEXT_4, additional data A_4, key K_4 and nonce IV_4.

message_4 is the CBOR bstr encoding of CIPHERTEXT_4:

PRK_out is specified in Section 4.1.2 of .

where hash_length is the length of the output of the EDHOC hash algorithm, and info for PRK_out is:

where the last value is the length of EDHOC hash algorithm.

The OSCORE Master Secret and OSCORE Master Salt are derived with the EDHOC-Exporter as specified in 4.2.1 of .

where PRK_exporter is derived from PRK_out:

where hash_length is the length of the output of the EDHOC hash algorithm, and info for the PRK_exporter is:

where the last value is the length of EDHOC hash algorithm.

The derivation of OSCORE parameters is specified in Appendix A.1 of . The AEAD and Hash algorithms to use in OSCORE are given by the selected cipher suite:

The mapping from EDHOC connection identifiers to OSCORE Sender/Recipient IDs is defined in Section 3.3.3 of . C_R is mapped to the Recipient ID of the server, i.e., the Sender ID of the client. The byte string 0x27, which as C_R is encoded as the CBOR integer 0x27, is converted to the server Recipient ID 0x27.

C_I is mapped to the Recipient ID of the client, i.e., the Sender ID of the server. The byte string 0x37, which as C_I is encoded as the CBOR integer 0x0e is converted to the client Recipient ID 0x37.

The OSCORE Master Secret is computed through Expand() using the Application hash algorithm, see Appendix A.1 of :

where oscore_key_length is by default the key length of the Application AEAD algorithm, and info for the OSCORE Master Secret is:

where the last value is the key length of Application AEAD algorithm.

The OSCORE Master Salt is computed through Expand() using the Application hash algorithm, see Section 4.2 of :

where oscore_salt_length is the length of the OSCORE Master Salt, and info for the OSCORE Master Salt is:

where the last value is the length of the OSCORE Master Salt.

ey update is defined in Section 4.2.2 of .

where hash_length is the length of the output of the EDHOC hash function, context for KeyUpdate is

and where info for key update is:

After key update the PRK_exporter needs to be derived anew:

where info and hash_length as unchanged as in .

The OSCORE Master Secret is derived with the updated PRK_exporter:

where info and key_length are unchanged as in .

The OSCORE Master Salt is derived with the updated PRK_exporter:

where info and salt_length are unchanged as in .

This document contains examples of EDHOC whose security considerations apply. The keys printed in these examples cannot be considered secret and must not be used.

There are no IANA considerations.

&I-D.ietf-lake-edhoc; &RFC7748; &RFC8032; &RFC8392; &RFC8949;

The authors want to thank all people verifying EDHOC test vectors and/or contributing to the interoperability testing including: Christian Amsüss, Timothy Claeys, Stefan Hristozov, Rikard Höglund, Christos Koulamas, Francesca Palombini, Lidia Pocero, Peter van der Stok, and Michel Veillette.