diff options
Diffstat (limited to 'doc/rfc/rfc9529.txt')
| -rw-r--r-- | doc/rfc/rfc9529.txt | 2840 |
1 files changed, 2840 insertions, 0 deletions
diff --git a/doc/rfc/rfc9529.txt b/doc/rfc/rfc9529.txt new file mode 100644 index 0000000..df4241d --- /dev/null +++ b/doc/rfc/rfc9529.txt @@ -0,0 +1,2840 @@ + + + + +Internet Engineering Task Force (IETF) G. Selander +Request for Comments: 9529 J. Preuß Mattsson +Category: Informational Ericsson +ISSN: 2070-1721 M. Serafin + ASSA ABLOY + M. Tiloca + RISE AB + M. Vučinić + Inria + March 2024 + + + Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC) + +Abstract + + This document contains example traces of Ephemeral Diffie-Hellman + Over COSE (EDHOC). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9529. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Setup + 1.2. Requirements Language + 2. Authentication with Signatures, X.509 Identified by 'x5t' + 2.1. message_1 + 2.2. message_2 + 2.3. message_3 + 2.4. message_4 + 2.5. PRK_out and PRK_exporter + 2.6. OSCORE Parameters + 2.7. Key Update + 2.8. Certificates + 3. Authentication with Static DH, CCS Identified by 'kid' + 3.1. message_1 (First Time) + 3.2. error + 3.3. message_1 (Second Time) + 3.4. message_2 + 3.5. message_3 + 3.6. message_4 + 3.7. PRK_out and PRK_exporter + 3.8. OSCORE Parameters + 3.9. Key Update + 4. Invalid Traces + 4.1. Encoding Errors + 4.2. Cryptography-Related Errors + 4.3. Non-deterministic CBOR + 5. Security Considerations + 6. IANA Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + EDHOC [RFC9528] is a lightweight authenticated key exchange protocol + designed for highly constrained settings. This document contains + annotated traces of EDHOC sessions with input, output, and + intermediate processing results to simplify testing of + implementations. The traces have been verified by two independent + implementations. + +1.1. Setup + + EDHOC is run between an Initiator (I) and a Responder (R). The + private/public key pairs and credentials of the Initiator and the + Responder required to produce the protocol messages are shown in the + traces when needed for the calculations. + + EDHOC messages and intermediate results are encoded in Concise Binary + Object Representation (CBOR) [RFC8949] and can therefore be displayed + in CBOR diagnostic notation using, e.g., the CBOR playground + [CborMe], which makes them easy to parse for humans. Credentials can + also be encoded in CBOR, e.g., CBOR Web Tokens (CWTs) [RFC8392]. + + The document contains two traces: + + * Section 2 - Authentication with signature keys identified by the + hash value of the X.509 certificates (provided in Section 2.8). + The endpoints use Edwards-curve Digital Signature Algorithm + (EdDSA) [RFC8032] for authentication and X25519 [RFC7748] for + ephemeral-ephemeral Diffie-Hellman (DH) key exchange. + + * Section 3 - Authentication with static Diffie-Hellman keys + identified by short key identifiers labeling CWT Claims Sets + (CCSs) [RFC8392]. The endpoints use NIST P-256 [SP-800-186] for + both ephemeral-ephemeral and ephemeral-static DH key exchange. + This trace also illustrates the cipher suite negotiation and + provides an example of low protocol overhead with messages sizes + of 39, 45, and 19 bytes. + + Examples of invalid EDHOC messages are found in Section 4. + + 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, then + some messages are typically prepended with connection + identifiers and potentially a message_1 indicator (see + Section 3.4.1 and Appendix A.2 of [RFC9528]). Those bytes + are not included in the traces in this document. + +1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Authentication with Signatures, X.509 Identified by 'x5t' + + In this example, the Initiator (I) and Responder (R) are + authenticated with digital signatures (METHOD = 0). Both the + Initiator and the Responder support cipher suite 0, which determines + the algorithms: + + * EDHOC AEAD algorithm = AES-CCM-16-64-128 + + * EDHOC hash algorithm = SHA-256 + + * EDHOC Message Authentication Code (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 CBOR Object Signing and Encryption (COSE) header parameter 'x5t'. + +2.1. message_1 + + Both endpoints are authenticated with signatures, i.e., METHOD = 0: + + METHOD (CBOR Data Item) (1 byte) + 00 + + The Initiator selects cipher suite 0. A single cipher suite is + encoded as an int: + + SUITES_I (CBOR Data Item) (1 byte) + 00 + + The Initiator creates an ephemeral key pair for use with the EDHOC + key exchange algorithm: + + Initiator's ephemeral private key + X (Raw Value) (32 bytes) + 89 2e c2 8e 5c b6 66 91 08 47 05 39 50 0b 70 5e 60 d0 08 d3 47 c5 81 + 7e e9 f3 32 7c 8a 87 bb 03 + + Initiator's ephemeral public key + G_X (Raw Value) (32 bytes) + 31 f8 2c 7b 5b 9c bb f0 f1 94 d9 13 cc 12 ef 15 32 d3 28 ef 32 63 2a + 48 81 a1 c0 70 1e 23 7f 04 + + Initiator's ephemeral public key + G_X (CBOR Data Item) (34 bytes) + 58 20 31 f8 2c 7b 5b 9c bb f0 f1 94 d9 13 cc 12 ef 15 32 d3 28 ef 32 + 63 2a 48 81 a1 c0 70 1e 23 7f 04 + + The Initiator selects its connection identifier C_I to be the byte + string 0x2d, which is encoded as 0x2d since it is represented by the + 1-byte CBOR int -14: + + Connection identifier chosen by the Initiator + C_I (Raw Value) (1 byte) + 2d + + Connection identifier chosen by the Initiator + C_I (CBOR Data Item) (1 byte) + 2d + + No external authorization data: + + EAD_1 (CBOR Sequence) (0 bytes) + + The Initiator constructs message_1: + + message_1 = + ( + 0, + 0, + h'31f82c7b5b9cbbf0f194d913cc12ef1532d328ef32632a48 + 81a1c0701e237f04', + -14 + ) + + message_1 (CBOR Sequence) (37 bytes) + 00 00 58 20 31 f8 2c 7b 5b 9c bb f0 f1 94 d9 13 cc 12 ef 15 32 d3 28 + ef 32 63 2a 48 81 a1 c0 70 1e 23 7f 04 2d + +2.2. message_2 + + The Responder supports the most preferred and selected cipher suite + 0, so SUITES_I is acceptable. + + The Responder creates an ephemeral key pair for use with the EDHOC + key exchange algorithm: + + Responder's ephemeral private key + Y (Raw Value) (32 bytes) + e6 9c 23 fb f8 1b c4 35 94 24 46 83 7f e8 27 bf 20 6c 8f a1 0a 39 db + 47 44 9e 5a 81 34 21 e1 e8 + + Responder's ephemeral public key + G_Y (Raw Value) (32 bytes) + dc 88 d2 d5 1d a5 ed 67 fc 46 16 35 6b c8 ca 74 ef 9e be 8b 38 7e 62 + 3a 36 0b a4 80 b9 b2 9d 1c + + Responder's ephemeral public key + G_Y (CBOR Data Item) (34 bytes) + 58 20 dc 88 d2 d5 1d a5 ed 67 fc 46 16 35 6b c8 ca 74 ef 9e be 8b 38 + 7e 62 3a 36 0b a4 80 b9 b2 9d 1c + + The Responder selects its connection identifier C_R to be the byte + string 0x18, which is encoded as h'18' = 0x4118 since it is not + represented by a 1-byte CBOR int: + + Connection identifier chosen by the Responder + C_R (Raw Value) (1 byte) + 18 + + Connection identifier chosen by the Responder + C_R (CBOR Data Item) (2 bytes) + 41 18 + + The transcript hash TH_2 is calculated using the EDHOC hash + algorithm: + + TH_2 = H( G_Y, H(message_1) ) + + H(message_1) (Raw Value) (32 bytes) + c1 65 d6 a9 9d 1b ca fa ac 8d bf 2b 35 2a 6f 7d 71 a3 0b 43 9c 9d 64 + d3 49 a2 38 48 03 8e d1 6b + + H(message_1) (CBOR Data Item) (34 bytes) + 58 20 c1 65 d6 a9 9d 1b ca fa ac 8d bf 2b 35 2a 6f 7d 71 a3 0b 43 9c + 9d 64 d3 49 a2 38 48 03 8e d1 6b + + The input to calculate TH_2 is the CBOR sequence: + + G_Y, H(message_1) + + Input to calculate TH_2 (CBOR Sequence) (68 bytes) + 58 20 dc 88 d2 d5 1d a5 ed 67 fc 46 16 35 6b c8 ca 74 ef 9e be 8b 38 + 7e 62 3a 36 0b a4 80 b9 b2 9d 1c 58 20 c1 65 d6 a9 9d 1b ca fa ac 8d + bf 2b 35 2a 6f 7d 71 a3 0b 43 9c 9d 64 d3 49 a2 38 48 03 8e d1 6b + + TH_2 (Raw Value) (32 bytes) + c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a + 06 52 ca e6 6c 90 61 68 8d + + TH_2 (CBOR Data Item) (34 bytes) + 58 20 c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a + 79 6a 06 52 ca e6 6c 90 61 68 8d + + PRK_2e is specified in Section 4.1.1.1 of [RFC9528]. + + First, the Elliptic Curve Diffie-Hellman (ECDH) shared secret G_XY is + computed from G_X and Y or G_Y and X: + + G_XY (Raw Value) (ECDH shared secret) (32 bytes) + e5 cd f3 a9 86 cd ac 5b 7b f0 46 91 e2 b0 7c 08 e7 1f 53 99 8d 8f 84 + 2b 7c 3f b4 d8 39 cf 7b 28 + + Then, PRK_2e is calculated using EDHOC_Extract(), which is determined + by the EDHOC hash algorithm: + + PRK_2e = EDHOC_Extract( salt, G_XY ) + = HMAC-SHA-256( salt, G_XY ) + + where salt is TH_2: + + salt (Raw Value) (32 bytes) + c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a + 06 52 ca e6 6c 90 61 68 8d + + PRK_2e (Raw Value) (32 bytes) + d5 84 ac 2e 5d ad 5a 77 d1 4b 53 eb e7 2e f1 d5 da a8 86 0d 39 93 73 + bf 2c 24 0a fa 7b a8 04 da + + Since METHOD = 0, the Responder authenticates using signatures. + Since the selected cipher suite is 0, the EDHOC signature algorithm + is EdDSA. + + The Responder's signature key pair uses EdDSA: + + Responder's private authentication key + SK_R (Raw Value) (32 bytes) + ef 14 0f f9 00 b0 ab 03 f0 c0 8d 87 9c bb d4 b3 1e a7 1e 6e 7e e7 ff + cb 7e 79 55 77 7a 33 27 99 + + Responder's public authentication key + PK_R (Raw Value) (32 bytes) + a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62 + c0 0b 3a c5 5d e9 2f 93 59 + + PRK_3e2m is specified in Section 4.1.1.2 of [RFC9528]. + + Since the Responder authenticates with signatures, PRK_3e2m = PRK_2e. + + PRK_3e2m (Raw Value) (32 bytes) + d5 84 ac 2e 5d ad 5a 77 d1 4b 53 eb e7 2e f1 d5 da a8 86 0d 39 93 73 + bf 2c 24 0a fa 7b a8 04 da + + The Responder constructs the remaining input needed to calculate + MAC_2: + + MAC_2 = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 ) + + context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >> + + CRED_R is identified by a 64-bit hash: + + ID_CRED_R = + { + 34 : [-15, h'79f2a41b510c1f9b'] + } + + where the COSE header value 34 ('x5t') indicates a hash of an X.509 + certificate, 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 Section 2.8.1: + + CRED_R (Raw Value) (241 bytes) + 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 30 05 06 03 2b 65 + 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f 6f + 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 34 + 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 30 + 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 70 6f 6e 64 65 72 + 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 a1 db 47 + b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62 c0 0b 3a + c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 23 bc 01 ea b0 92 + 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 47 8f ec fa f1 45 + 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 65 d8 6d + ce 51 cf ae 52 ab 82 c1 52 cb 02 + + CRED_R (CBOR Data Item) (243 bytes) + 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 30 05 06 03 + 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 + 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 + 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 + 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 70 6f 6e 64 + 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 a1 + db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62 c0 + 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 23 bc 01 ea + b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 47 8f ec fa + f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 65 + d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02 + + No external authorization data: + + EAD_2 (CBOR Sequence) (0 bytes) + + context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >> + + context_2 (CBOR Sequence) (293 bytes) + 41 18 a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b 58 20 c6 40 5c 15 4c + 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a 06 52 ca e6 6c + 90 61 68 8d 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 + 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 + 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 + 31 36 30 38 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 + 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 + 70 6f 6e 64 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 + 03 21 00 a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 + f2 c6 62 c0 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 + 23 bc 01 ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 + 47 8f ec fa f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a + bc 94 95 65 d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02 + + context_2 (CBOR byte string) (296 bytes) + 59 01 25 41 18 a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b 58 20 c6 40 + 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a 06 52 + ca e6 6c 90 61 68 8d 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 + 31 9e c4 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 + 45 44 48 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 + 32 30 33 31 36 30 38 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 + 30 30 30 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 + 52 65 73 70 6f 6e 64 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 + 2b 65 70 03 21 00 a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac + e3 3a a0 f2 c6 62 c0 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 + 41 00 b7 23 bc 01 ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 + 87 b0 32 47 8f ec fa f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 + 37 eb 4a bc 94 95 65 d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02 + + MAC_2 is computed through EDHOC_Expand() using the EDHOC hash + algorithm (see Section 4.1.2 of [RFC9528]): + + 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: + + info = + ( + 2, + h'4118a11822822e4879f2a41b510c1f9b5820c6405c154c56 + 7466ab1df20369500e540e9f14bd3a796a0652cae66c9061 + 688d58f13081ee3081a1a003020102020462319ec4300506 + 032b6570301d311b301906035504030c124544484f432052 + 6f6f742045643235353139301e170d323230333136303832 + 3433365a170d3239313233313233303030305a3022312030 + 1e06035504030c174544484f4320526573706f6e64657220 + 45643235353139302a300506032b6570032100a1db47b951 + 84854ad12a0c1a354e418aace33aa0f2c662c00b3ac55de9 + 2f9359300506032b6570034100b723bc01eab0928e8b2b6c + 98de19cc3823d46e7d6987b032478fecfaf14537a1af14cc + 8be829c6b73044101837eb4abc949565d86dce51cfae52ab + 82c152cb02', + 32 + ) + + where the last value is the output size of the EDHOC hash algorithm + in bytes. + + info for MAC_2 (CBOR Sequence) (299 bytes) + 02 59 01 25 41 18 a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b 58 20 c6 + 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a 06 + 52 ca e6 6c 90 61 68 8d 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 + 62 31 9e c4 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c + 12 45 44 48 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d + 32 32 30 33 31 36 30 38 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 + 30 30 30 30 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 + 20 52 65 73 70 6f 6e 64 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 + 03 2b 65 70 03 21 00 a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a + ac e3 3a a0 f2 c6 62 c0 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 + 03 41 00 b7 23 bc 01 ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d + 69 87 b0 32 47 8f ec fa f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 + 18 37 eb 4a bc 94 95 65 d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02 18 20 + + MAC_2 (Raw Value) (32 bytes) + 86 2a 7e 5e f1 47 f9 a5 f4 c5 12 e1 b6 62 3c d6 6c d1 7a 72 72 07 2b + fe 5b 60 2f fe 30 7e e0 e9 + + MAC_2 (CBOR Data Item) (34 bytes) + 58 20 86 2a 7e 5e f1 47 f9 a5 f4 c5 12 e1 b6 62 3c d6 6c d1 7a 72 72 + 07 2b fe 5b 60 2f fe 30 7e e0 e9 + + Since METHOD = 0, Signature_or_MAC_2 is the 'signature' of the + COSE_Sign1 object. + + The Responder constructs the message to be signed: + + [ + "Signature1", + << ID_CRED_R >>, + << TH_2, CRED_R, ? EAD_2 >>, + MAC_2 + ] = + + [ + "Signature1", + h'a11822822e4879f2a41b510c1f9b', + h'5820c6405c154c567466ab1df20369500e540e9f14bd3a79 + 6a0652cae66c9061688d58f13081ee3081a1a00302010202 + 0462319ec4300506032b6570301d311b301906035504030c + 124544484f4320526f6f742045643235353139301e170d32 + 32303331363038323433365a170d32393132333132333030 + 30305a30223120301e06035504030c174544484f43205265 + 73706f6e6465722045643235353139302a300506032b6570 + 032100a1db47b95184854ad12a0c1a354e418aace33aa0f2 + c662c00b3ac55de92f9359300506032b6570034100b723bc + 01eab0928e8b2b6c98de19cc3823d46e7d6987b032478fec + faf14537a1af14cc8be829c6b73044101837eb4abc949565 + d86dce51cfae52ab82c152cb02', + h'862a7e5ef147f9a5f4c512e1b6623cd66cd17a7272072bfe + 5b602ffe307ee0e9' + ] + + Message to be signed in message_2 (CBOR Data Item) (341 bytes) + 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 79 f2 a4 1b + 51 0c 1f 9b 59 01 15 58 20 c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 + 0e 54 0e 9f 14 bd 3a 79 6a 06 52 ca e6 6c 90 61 68 8d 58 f1 30 81 ee + 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 30 05 06 03 2b 65 70 30 1d + 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f 6f 74 20 45 + 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 34 33 36 5a + 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 30 1e 06 03 + 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 70 6f 6e 64 65 72 20 45 64 + 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 a1 db 47 b9 51 84 + 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62 c0 0b 3a c5 5d e9 + 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 23 bc 01 ea b0 92 8e 8b 2b + 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 47 8f ec fa f1 45 37 a1 af + 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 65 d8 6d ce 51 cf + ae 52 ab 82 c1 52 cb 02 58 20 86 2a 7e 5e f1 47 f9 a5 f4 c5 12 e1 b6 + 62 3c d6 6c d1 7a 72 72 07 2b fe 5b 60 2f fe 30 7e e0 e9 + + The Responder signs using the private authentication key SK_R. + + Signature_or_MAC_2 (Raw Value) (64 bytes) + c3 b5 bd 44 d1 e4 4a 08 5c 03 d3 ae de 4e 1e 6c 11 c5 72 a1 96 8c c3 + 62 9b 50 5f 98 c6 81 60 8d 3d 1d e7 93 d1 c4 0e b5 dd 5d 89 ac f1 96 + 6a ea 07 02 2b 48 cd c9 98 70 eb c4 03 74 e8 fa 6e 09 + + Signature_or_MAC_2 (CBOR Data Item) (66 bytes) + 58 40 c3 b5 bd 44 d1 e4 4a 08 5c 03 d3 ae de 4e 1e 6c 11 c5 72 a1 96 + 8c c3 62 9b 50 5f 98 c6 81 60 8d 3d 1d e7 93 d1 c4 0e b5 dd 5d 89 ac + f1 96 6a ea 07 02 2b 48 cd c9 98 70 eb c4 03 74 e8 fa 6e 09 + + The Responder constructs PLAINTEXT_2: + + PLAINTEXT_2 = + ( + C_R, + ID_CRED_R / bstr / -24..23, + Signature_or_MAC_2, + ? EAD_2 + ) + + PLAINTEXT_2 (CBOR Sequence) (82 bytes) + 41 18 a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b 58 40 c3 b5 bd 44 d1 + e4 4a 08 5c 03 d3 ae de 4e 1e 6c 11 c5 72 a1 96 8c c3 62 9b 50 5f 98 + c6 81 60 8d 3d 1d e7 93 d1 c4 0e b5 dd 5d 89 ac f1 96 6a ea 07 02 2b + 48 cd c9 98 70 eb c4 03 74 e8 fa 6e 09 + + The input needed to calculate KEYSTREAM_2 is defined in Section 4.1.2 + of [RFC9528], using EDHOC_Expand() with the EDHOC hash algorithm: + + KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length ) + = HKDF-Expand( PRK_2e, info, plaintext_length ) + + where plaintext_length is the length in bytes of PLAINTEXT_2 in bytes + and info for KEYSTREAM_2 is: + + info = + ( + 0, + h'c6405c154c567466ab1df20369500e540e9f14bd3a796a06 + 52cae66c9061688d', + 82 + ) + + where the last value is the length in bytes of PLAINTEXT_2. + + info for KEYSTREAM_2 (CBOR Sequence) (37 bytes) + 00 58 20 c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd + 3a 79 6a 06 52 ca e6 6c 90 61 68 8d 18 52 + + KEYSTREAM_2 (Raw Value) (82 bytes) + fd 3e 7c 3f 2d 6b ee 64 3d 3c 9d 2f 28 47 03 5d 73 e2 ec b0 f8 db 5c + d1 c6 85 4e 24 89 6a f2 11 88 b2 c4 34 4e 68 9e c2 98 42 83 d9 fb c6 + 9c e1 c5 db 10 dc ff f2 4d f9 a4 9a 04 a9 40 58 27 7b c7 fa 9a d6 c6 + b1 94 ab 32 8b 44 5e b0 80 49 0c d7 86 + + The Responder calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and + KEYSTREAM_2: + + CIPHERTEXT_2 (Raw Value) (82 bytes) + bc 26 dd 27 0f e9 c0 2c 44 ce 39 34 79 4b 1c c6 2b a2 2f 05 45 9f 8d + 35 8c 8d 12 27 5a c4 2c 5f 96 de d5 f1 3c c9 08 4e 5b 20 18 89 a4 5e + 5a 60 a5 56 2d c1 18 61 9c 3d aa 2f d9 f4 c9 f4 d6 ed ad 10 9d d4 ed + f9 59 62 aa fb af 9a b3 f4 a1 f6 b9 8f + + The Responder constructs message_2: + + message_2 = + ( + G_Y_CIPHERTEXT_2 + ) + + where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of + the raw values of G_Y and CIPHERTEXT_2. + + message_2 (CBOR Sequence) (116 bytes) + 58 72 dc 88 d2 d5 1d a5 ed 67 fc 46 16 35 6b c8 ca 74 ef 9e be 8b 38 + 7e 62 3a 36 0b a4 80 b9 b2 9d 1c bc 26 dd 27 0f e9 c0 2c 44 ce 39 34 + 79 4b 1c c6 2b a2 2f 05 45 9f 8d 35 8c 8d 12 27 5a c4 2c 5f 96 de d5 + f1 3c c9 08 4e 5b 20 18 89 a4 5e 5a 60 a5 56 2d c1 18 61 9c 3d aa 2f + d9 f4 c9 f4 d6 ed ad 10 9d d4 ed f9 59 62 aa fb af 9a b3 f4 a1 f6 b9 + 8f + +2.3. message_3 + + Since METHOD = 0, the Initiator authenticates using signatures. + Since the selected cipher suite is 0, the EDHOC signature algorithm + is EdDSA. + + The Initiator's signature key pair uses EdDSA: + + Initiator's private authentication key + SK_I (Raw Value) (32 bytes) + 4c 5b 25 87 8f 50 7c 6b 9d ae 68 fb d4 fd 3f f9 97 53 3d b0 af 00 b2 + 5d 32 4e a2 8e 6c 21 3b c8 + + Initiator's public authentication key + PK_I (Raw Value) (32 bytes) + ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f + 23 d8 cc 20 b7 30 85 14 1e + + PRK_4e3m is specified in Section 4.1.1.3 of [RFC9528]. + + Since the Initiator authenticates with signatures, PRK_4e3m = + PRK_3e2m. + + PRK_4e3m (Raw Value) (32 bytes) + d5 84 ac 2e 5d ad 5a 77 d1 4b 53 eb e7 2e f1 d5 da a8 86 0d 39 93 73 + bf 2c 24 0a fa 7b a8 04 da + + The transcript hash TH_3 is calculated using the EDHOC hash + algorithm: + + TH_3 = H( TH_2, PLAINTEXT_2, CRED_R ) + + Input to calculate TH_3 (CBOR Sequence) (359 bytes) + 58 20 c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a + 79 6a 06 52 ca e6 6c 90 61 68 8d 41 18 a1 18 22 82 2e 48 79 f2 a4 1b + 51 0c 1f 9b 58 40 c3 b5 bd 44 d1 e4 4a 08 5c 03 d3 ae de 4e 1e 6c 11 + c5 72 a1 96 8c c3 62 9b 50 5f 98 c6 81 60 8d 3d 1d e7 93 d1 c4 0e b5 + dd 5d 89 ac f1 96 6a ea 07 02 2b 48 cd c9 98 70 eb c4 03 74 e8 fa 6e + 09 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 30 05 06 + 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 + 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 + 38 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 + 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 70 6f 6e + 64 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 + a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62 + c0 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 23 bc 01 + ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 47 8f ec + fa f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 + 65 d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02 + + TH_3 (Raw Value) (32 bytes) + 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 + b1 67 77 99 65 92 e9 28 bc + + TH_3 (CBOR Data Item) (34 bytes) + 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 + f6 69 b1 67 77 99 65 92 e9 28 bc + + The Initiator constructs the remaining input needed to calculate + MAC_3: + + MAC_3 = EDHOC_KDF( PRK_4e3m, 6, context_3, mac_length_3 ) + + where + + context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> + + CRED_I is identified by a 64-bit hash: + + ID_CRED_I = + { + 34 : [-15, h'c24ab2fd7643c79f'] + } + + where the COSE header value 34 ('x5t') indicates a hash of an X.509 + certificate, and the COSE algorithm -15 indicates the hash algorithm + SHA-256 truncated to 64 bits. + + ID_CRED_I (CBOR Data Item) (14 bytes) + a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f + + CRED_I is a CBOR byte string of the DER encoding of the X.509 + certificate in Section 2.8.2: + + CRED_I (Raw Value) (241 bytes) + 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 06 03 2b 65 + 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f 6f + 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 34 + 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 30 + 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 61 74 6f 72 + 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 ed 06 a8 + ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f 23 d8 cc + 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 d8 b3 a7 70 + 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 92 75 ae 48 + b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff 27 b9 + e7 a8 13 fa 57 4b 72 a0 0b 43 0b + + CRED_I (CBOR Data Item) (243 bytes) + 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 06 03 + 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 + 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 + 32 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 + 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 61 74 + 6f 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 ed + 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f 23 + d8 cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 d8 b3 + a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 92 75 + ae 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff + 27 b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b + + No external authorization data: + + EAD_3 (CBOR Sequence) (0 bytes) + + context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> + + context_3 (CBOR Sequence) (291 bytes) + a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f 58 20 5b 7d f9 b4 f5 8f 24 + 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 99 65 92 e9 + 28 bc 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 + 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 + 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 + 30 38 32 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 + 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 + 61 74 6f 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 + 00 ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e + 0f 23 d8 cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 + d8 b3 a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 + 92 75 ae 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 + ee ff 27 b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b + + context_3 (CBOR byte string) (294 bytes) + 59 01 23 a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f 58 20 5b 7d f9 b4 + f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 99 + 65 92 e9 28 bc 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e + a0 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 + 48 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 + 33 31 36 30 38 32 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 + 30 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e + 69 74 69 61 74 6f 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 + 70 03 21 00 ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 + 02 f4 3e 0f 23 d8 cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 + 52 12 41 d8 b3 a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df + 29 10 b3 92 75 ae 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 + 67 dd 05 ee ff 27 b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b + + MAC_3 is computed through EDHOC_Expand() using the EDHOC hash + algorithm (see Section 4.1.2 of [RFC9528]): + + MAC_3 = HKDF-Expand( PRK_4e3m, info, mac_length_3 ) + + where + + 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: + + info = + ( + 6, + h'a11822822e48c24ab2fd7643c79f58205b7df9b4f58f240c + e0418e48191b5fff3a22b5ca57f669b16777996592e928bc + 58f13081ee3081a1a003020102020462319ea0300506032b + 6570301d311b301906035504030c124544484f4320526f6f + 742045643235353139301e170d3232303331363038323430 + 305a170d3239313233313233303030305a30223120301e06 + 035504030c174544484f4320496e69746961746f72204564 + 3235353139302a300506032b6570032100ed06a8ae61a829 + ba5fa54525c9d07f48dd44a302f43e0f23d8cc20b7308514 + 1e300506032b6570034100521241d8b3a770996bcfc9b9ea + d4e7e0a1c0db353a3bdf2910b39275ae48b756015981850d + 27db6734e37f67212267dd05eeff27b9e7a813fa574b72a0 + 0b430b', + 32 + ) + + where the last value is the output size of the EDHOC hash algorithm + in bytes. + + info for MAC_3 (CBOR Sequence) (297 bytes) + 06 59 01 23 a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f 58 20 5b 7d f9 + b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 + 99 65 92 e9 28 bc 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 + 9e a0 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 + 44 48 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 + 30 33 31 36 30 38 32 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 + 30 30 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 + 6e 69 74 69 61 74 6f 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b + 65 70 03 21 00 ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 + a3 02 f4 3e 0f 23 d8 cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 + 00 52 12 41 d8 b3 a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b + df 29 10 b3 92 75 ae 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 + 22 67 dd 05 ee ff 27 b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b 18 20 + + MAC_3 (Raw Value) (32 bytes) + 39 b1 27 c1 30 12 9a fa 30 61 8c 75 13 29 e6 37 cc 37 34 27 0d 4b 01 + 25 84 45 a8 ee 02 da a3 bd + + MAC_3 (CBOR Data Item) (34 bytes) + 58 20 39 b1 27 c1 30 12 9a fa 30 61 8c 75 13 29 e6 37 cc 37 34 27 0d + 4b 01 25 84 45 a8 ee 02 da a3 bd + + Since METHOD = 0, Signature_or_MAC_3 is the 'signature' of the + COSE_Sign1 object. + + The Initiator constructs the message to be signed: + + [ + "Signature1", + << ID_CRED_I >>, + << TH_3, CRED_I, ? EAD_3 >>, + MAC_3 + ] = + + [ + "Signature1", + h'a11822822e48c24ab2fd7643c79f', + h'58205b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f6 + 69b16777996592e928bc58f13081ee3081a1a00302010202 + 0462319ea0300506032b6570301d311b301906035504030c + 124544484f4320526f6f742045643235353139301e170d32 + 32303331363038323430305a170d32393132333132333030 + 30305a30223120301e06035504030c174544484f4320496e + 69746961746f722045643235353139302a300506032b6570 + 032100ed06a8ae61a829ba5fa54525c9d07f48dd44a302f4 + 3e0f23d8cc20b73085141e300506032b6570034100521241 + d8b3a770996bcfc9b9ead4e7e0a1c0db353a3bdf2910b392 + 75ae48b756015981850d27db6734e37f67212267dd05eeff + 27b9e7a813fa574b72a00b430b', + h'39b127c130129afa30618c751329e637cc3734270d4b0125 + 8445a8ee02daa3bd' + ] + + Message to be signed in message_3 (CBOR Data Item) (341 bytes) + 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 c2 4a b2 fd + 76 43 c7 9f 59 01 15 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b + 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 99 65 92 e9 28 bc 58 f1 30 81 ee + 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 06 03 2b 65 70 30 1d + 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f 6f 74 20 45 + 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 34 30 30 5a + 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 30 1e 06 03 + 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 61 74 6f 72 20 45 64 + 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 ed 06 a8 ae 61 a8 + 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f 23 d8 cc 20 b7 30 + 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 d8 b3 a7 70 99 6b cf + c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 92 75 ae 48 b7 56 01 + 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff 27 b9 e7 a8 13 + fa 57 4b 72 a0 0b 43 0b 58 20 39 b1 27 c1 30 12 9a fa 30 61 8c 75 13 + 29 e6 37 cc 37 34 27 0d 4b 01 25 84 45 a8 ee 02 da a3 bd + + The Initiator signs using the private authentication key SK_I: + + Signature_or_MAC_3 (Raw Value) (64 bytes) + 96 e1 cd 5f ce ad fa c1 b5 af 81 94 43 f7 09 24 f5 71 99 55 95 7f d0 + 26 55 be b4 77 5e 1a 73 18 6a 0d 1d 3e a6 83 f0 8f 8d 03 dc ec b9 cf + 15 4e 1c 6f 55 5a 1e 12 ca 11 8c e4 2b db a6 87 89 07 + + Signature_or_MAC_3 (CBOR Data Item) (66 bytes) + 58 40 96 e1 cd 5f ce ad fa c1 b5 af 81 94 43 f7 09 24 f5 71 99 55 95 + 7f d0 26 55 be b4 77 5e 1a 73 18 6a 0d 1d 3e a6 83 f0 8f 8d 03 dc ec + b9 cf 15 4e 1c 6f 55 5a 1e 12 ca 11 8c e4 2b db a6 87 89 07 + + The Initiator constructs PLAINTEXT_3: + + PLAINTEXT_3 = + ( + ID_CRED_I / bstr / -24..23, + Signature_or_MAC_3, + ? EAD_3 + ) + + PLAINTEXT_3 (CBOR Sequence) (80 bytes) + a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f 58 40 96 e1 cd 5f ce ad fa + c1 b5 af 81 94 43 f7 09 24 f5 71 99 55 95 7f d0 26 55 be b4 77 5e 1a + 73 18 6a 0d 1d 3e a6 83 f0 8f 8d 03 dc ec b9 cf 15 4e 1c 6f 55 5a 1e + 12 ca 11 8c e4 2b db a6 87 89 07 + + The Initiator constructs the associated data for message_3: + + A_3 = + [ + "Encrypt0", + h'', + h'5b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f669b1 + 6777996592e928bc' + ] + + A_3 (CBOR Data Item) (45 bytes) + 83 68 45 6e 63 72 79 70 74 30 40 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 + 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 99 65 92 e9 28 bc + + The Initiator constructs the input needed to derive the key K_3 (see + Section 4.1.2 of [RFC9528]) using the EDHOC hash algorithm: + + K_3 = EDHOC_KDF( PRK_3e2m, 3, TH_3, key_length ) + = HKDF-Expand( PRK_3e2m, info, key_length ) + + where key_length is the key length in bytes for the EDHOC + Authenticated Encryption with Associated Data (AEAD) algorithm, and + info for K_3 is: + + info = + ( + 3, + h'5b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f669b1 + 6777996592e928bc', + 16 + ) + + where the last value is the key length in bytes for the EDHOC AEAD + algorithm. + + info for K_3 (CBOR Sequence) (36 bytes) + 03 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca + 57 f6 69 b1 67 77 99 65 92 e9 28 bc 10 + + K_3 (Raw Value) (16 bytes) + da 19 5e 5f 64 8a c6 3b 0e 8f b0 c4 55 20 51 39 + + The Initiator constructs the input needed to derive the nonce IV_3 + (see Section 4.1.2 of [RFC9528]) using the EDHOC hash algorithm: + + IV_3 = EDHOC_KDF( PRK_3e2m, 4, TH_3, iv_length ) + = HKDF-Expand( PRK_3e2m, info, iv_length ) + + where iv_length is the nonce length in bytes for the EDHOC AEAD + algorithm, and info for IV_3 is: + + info = + ( + 4, + h'5b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f669b1 + 6777996592e928bc', + 13 + ) + + where the last value is the nonce length in bytes for the EDHOC AEAD + algorithm. + + info for IV_3 (CBOR Sequence) (36 bytes) + 04 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca + 57 f6 69 b1 67 77 99 65 92 e9 28 bc 0d + + IV_3 (Raw Value) (13 bytes) + 38 d8 c6 4c 56 25 5a ff a4 49 f4 be d7 + + The Initiator 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. + + CIPHERTEXT_3 (Raw Value) (88 bytes) + 25 c3 45 88 4a aa eb 22 c5 27 f9 b1 d2 b6 78 72 07 e0 16 3c 69 b6 2a + 0d 43 92 81 50 42 72 03 c3 16 74 e4 51 4e a6 e3 83 b5 66 eb 29 76 3e + fe b0 af a5 18 77 6a e1 c6 5f 85 6d 84 bf 32 af 3a 78 36 97 04 66 dc + b7 1f 76 74 5d 39 d3 02 5e 77 03 e0 c0 32 eb ad 51 94 7c + + message_3 is the CBOR bstr encoding of CIPHERTEXT_3: + + message_3 (CBOR Sequence) (90 bytes) + 58 58 25 c3 45 88 4a aa eb 22 c5 27 f9 b1 d2 b6 78 72 07 e0 16 3c 69 + b6 2a 0d 43 92 81 50 42 72 03 c3 16 74 e4 51 4e a6 e3 83 b5 66 eb 29 + 76 3e fe b0 af a5 18 77 6a e1 c6 5f 85 6d 84 bf 32 af 3a 78 36 97 04 + 66 dc b7 1f 76 74 5d 39 d3 02 5e 77 03 e0 c0 32 eb ad 51 94 7c + + The transcript hash TH_4 is calculated using the EDHOC hash + algorithm: + + TH_4 = H( TH_3, PLAINTEXT_3, CRED_I ) + + Input to calculate TH_4 (CBOR Sequence) (357 bytes) + 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 + f6 69 b1 67 77 99 65 92 e9 28 bc a1 18 22 82 2e 48 c2 4a b2 fd 76 43 + c7 9f 58 40 96 e1 cd 5f ce ad fa c1 b5 af 81 94 43 f7 09 24 f5 71 99 + 55 95 7f d0 26 55 be b4 77 5e 1a 73 18 6a 0d 1d 3e a6 83 f0 8f 8d 03 + dc ec b9 cf 15 4e 1c 6f 55 5a 1e 12 ca 11 8c e4 2b db a6 87 89 07 58 + f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 06 03 2b + 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f + 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 + 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 + 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 61 74 6f + 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 ed 06 + a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f 23 d8 + cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 d8 b3 a7 + 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 92 75 ae + 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff 27 + b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b + + TH_4 (Raw Value) (32 bytes) + 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99 be 42 d5 + a4 1a 5a 37 c8 96 f2 94 ac + + TH_4 (CBOR Data Item) (34 bytes) + 58 20 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99 be + 42 d5 a4 1a 5a 37 c8 96 f2 94 ac + +2.4. message_4 + + No external authorization data: + + EAD_4 (CBOR Sequence) (0 bytes) + + The Responder constructs PLAINTEXT_4: + + PLAINTEXT_4 = + ( + ? EAD_4 + ) + + PLAINTEXT_4 (CBOR Sequence) (0 bytes) + + The Responder constructs the associated data for message_4: + + A_4 = + [ + "Encrypt0", + h'', + h'0eb868f263cf3555dccd396dd8dec29d3750d599be42d5a4 + 1a5a37c896f294ac' + ] + + A_4 (CBOR Data Item) (45 bytes) + 83 68 45 6e 63 72 79 70 74 30 40 58 20 0e b8 68 f2 63 cf 35 55 dc cd + 39 6d d8 de c2 9d 37 50 d5 99 be 42 d5 a4 1a 5a 37 c8 96 f2 94 ac + + The Responder constructs the input needed to derive the EDHOC + message_4 key (see Section 4.1.2 of [RFC9528]) using the EDHOC hash + algorithm: + + K_4 = EDHOC_KDF( PRK_4e3m, 8, TH_4, key_length ) + = HKDF-Expand( PRK_4e3m, info, key_length ) + + where key_length is the key length in bytes for the EDHOC AEAD + algorithm, and info for K_4 is: + + info = + ( + 8, + h'0eb868f263cf3555dccd396dd8dec29d3750d599be42d5a4 + 1a5a37c896f294ac', + 16 + ) + + where the last value is the key length in bytes for the EDHOC AEAD + algorithm. + + info for K_4 (CBOR Sequence) (36 bytes) + 08 58 20 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99 + be 42 d5 a4 1a 5a 37 c8 96 f2 94 ac 10 + + K_4 (Raw Value) (16 bytes) + df 8c b5 86 1e 1f df ed d3 b2 30 15 a3 9d 1e 2e + + The Responder constructs the input needed to derive the EDHOC + message_4 nonce (see Section 4.1.2 of [RFC9528]) using the EDHOC hash + algorithm: + + IV_4 = EDHOC_KDF( PRK_4e3m, 9, TH_4, iv_length ) + = HKDF-Expand( PRK_4e3m, info, iv_length ) + + where length is the nonce length in bytes for the EDHOC AEAD + algorithm, and info for IV_4 is: + + info = + ( + 9, + h'0eb868f263cf3555dccd396dd8dec29d3750d599be42d5a4 + 1a5a37c896f294ac', + 13 + ) + + where the last value is the nonce length in bytes for the EDHOC AEAD + algorithm. + + info for IV_4 (CBOR Sequence) (36 bytes) + 09 58 20 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99 + be 42 d5 a4 1a 5a 37 c8 96 f2 94 ac 0d + + IV_4 (Raw Value) (13 bytes) + 12 8e c6 58 d9 70 d7 38 0f 74 fc 6c 27 + + The Responder 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. + + CIPHERTEXT_4 (8 bytes) + 4f 0e de e3 66 e5 c8 83 + + message_4 is the CBOR bstr encoding of CIPHERTEXT_4: + + message_4 (CBOR Sequence) (9 bytes) + 48 4f 0e de e3 66 e5 c8 83 + +2.5. PRK_out and PRK_exporter + + PRK_out is specified in Section 4.1.3 of [RFC9528]. + + PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length ) + = HKDF-Expand( PRK_4e3m, info, hash_length ) + + where hash_length is the length in bytes of the output of the EDHOC + hash algorithm, and info for PRK_out is: + + info = + ( + 7, + h'0eb868f263cf3555dccd396dd8dec29d3750d599be42d5a4 + 1a5a37c896f294ac', + 32 + ) + + where the last value is the length in bytes of the output of the + EDHOC hash algorithm. + + info for PRK_out (CBOR Sequence) (37 bytes) + 07 58 20 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99 + be 42 d5 a4 1a 5a 37 c8 96 f2 94 ac 18 20 + + PRK_out (Raw Value) (32 bytes) + b7 44 cb 7d 8a 87 cc 04 47 c3 35 0e 16 5b 25 0d ab 12 ec 45 33 25 ab + b9 22 b3 03 07 e5 c3 68 f0 + + The Object Security for Constrained RESTful Environments (OSCORE) + Master Secret and OSCORE Master Salt are derived with the + EDHOC_Exporter as specified in Section 4.2.1 of [RFC9528]. + + EDHOC_Exporter( exporter_label, context, length ) + = EDHOC_KDF( PRK_exporter, exporter_label, context, length ) + + where PRK_exporter is derived from PRK_out: + + PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) + = HKDF-Expand( PRK_out, info, hash_length ) + + where hash_length is the length in bytes of the output of the EDHOC + hash algorithm, and info for the PRK_exporter is: + + info = + ( + 10, + h'', + 32 + ) + + where the last value is the length in bytes of the output of the + EDHOC hash algorithm. + + info for PRK_exporter (CBOR Sequence) (4 bytes) + 0a 40 18 20 + + PRK_exporter (Raw Value) (32 bytes) + 2a ae c8 fc 4a b3 bc 32 95 de f6 b5 51 05 1a 2f a5 61 42 4d b3 01 fa + 84 f6 42 f5 57 8a 6d f5 1a + +2.6. OSCORE Parameters + + The derivation of OSCORE parameters is specified in Appendix A.1 of + [RFC9528]. + + The AEAD and hash algorithms to use in OSCORE are given by the + selected cipher suite: + + Application AEAD Algorithm (int) + 10 + + Application Hash Algorithm (int) + -16 + + The mapping from EDHOC connection identifiers to OSCORE Sender/ + Recipient IDs is defined in Section 3.3.3 of [RFC9528]. + + 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. + + Client's OSCORE Sender ID (Raw Value) (1 byte) + 18 + + 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. + + Server's OSCORE Sender ID (Raw Value) (1 byte) + 2d + + The OSCORE Master Secret is computed through EDHOC_Expand() using the + application hash algorithm (see Appendix A.1 of [RFC9528]): + + OSCORE Master Secret = EDHOC_Exporter( 0, h'', oscore_key_length ) + = EDHOC_KDF( PRK_exporter, 0, h'', oscore_key_length ) + = HKDF-Expand( PRK_exporter, info, oscore_key_length ) + + where oscore_key_length is the key length in bytes for the + application AEAD algorithm by default, and info for the OSCORE Master + Secret is: + + info = + ( + 0, + h'', + 16 + ) + + where the last value is the key length in bytes for the application + AEAD algorithm. + + info for OSCORE Master Secret (CBOR Sequence) (3 bytes) + 00 40 10 + + OSCORE Master Secret (Raw Value) (16 bytes) + 1e 1c 6b ea c3 a8 a1 ca c4 35 de 7e 2f 9a e7 ff + + The OSCORE Master Salt is computed through EDHOC_Expand() using the + application hash algorithm (see Section 4.2 of [RFC9528]): + + OSCORE Master Salt = EDHOC_Exporter( 1, h'', oscore_salt_length ) + = EDHOC_KDF( PRK_exporter, 1, h'', oscore_salt_length ) + = HKDF-Expand( PRK_exporter, info, oscore_salt_length ) + + where oscore_salt_length is the length in bytes of the OSCORE Master + Salt, and info for the OSCORE Master Salt is: + + info = + ( + 1, + h'', + 8 + ) + + where the last value is the length in bytes of the OSCORE Master + Salt. + + info for OSCORE Master Salt (CBOR Sequence) (3 bytes) + 01 40 08 + + OSCORE Master Salt (Raw Value) (8 bytes) + ce 7a b8 44 c0 10 6d 73 + +2.7. Key Update + + Key update is defined in Appendix H of [RFC9528]. + + EDHOC_KeyUpdate( context ): + PRK_out = EDHOC_KDF( PRK_out, 11, context, hash_length ) + = HKDF-Expand( PRK_out, info, hash_length ) + + where hash_length is the length in bytes of the output of the EDHOC + hash function, and the context for KeyUpdate is: + + context for KeyUpdate (Raw Value) (16 bytes) + d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c + + context for KeyUpdate (CBOR Data Item) (17 bytes) + 50 d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c + + where info for KeyUpdate is: + + info = + ( + 11, + h'd6be169602b8bceaa01158fdb820890c', + 32 + ) + + info for KeyUpdate (CBOR Sequence) (20 bytes) + 0b 50 d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c 18 20 + + PRK_out after KeyUpdate (Raw Value) (32 bytes) + da 6e ac d9 a9 85 f4 fb a9 ae c2 a9 29 90 22 97 6b 25 b1 4e 89 fa 15 + 97 94 f2 8d 82 fa f2 da ad + + After the key update, the PRK_exporter needs to be derived anew: + + PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) + = HKDF-Expand( PRK_out, info, hash_length ) + + where info and hash_length are unchanged as in Section 2.5. + + PRK_exporter after KeyUpdate (Raw Value) (32 bytes) + 00 14 d2 52 5e e0 d8 e2 13 ea 59 08 02 8e 9a 1c e9 a0 1c 30 54 6f 09 + 30 c0 44 d3 8d b5 36 2c 05 + + The OSCORE Master Secret is derived with the updated PRK_exporter: + + OSCORE Master Secret + = HKDF-Expand( PRK_exporter, info, oscore_key_length ) + + where info and oscore_key_length are unchanged as in Section 2.6. + + OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes) + ee 0f f5 42 c4 7e b0 e0 9c 69 30 76 49 bd bb e5 + + The OSCORE Master Salt is derived with the updated PRK_exporter: + + OSCORE Master Salt + = HKDF-Expand( PRK_exporter, info, oscore_salt_length ) + + where info and oscore_salt_length are unchanged as in Section 2.6. + + OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes) + 80 ce de 2a 1e 5a ab 48 + +2.8. Certificates + +2.8.1. Responder Certificate + + Version: 3 (0x2) + Serial Number: 1647419076 (0x62319ec4) + Signature Algorithm: ED25519 + Issuer: CN = EDHOC Root Ed25519 + Validity + Not Before: Mar 16 08:24:36 2022 GMT + Not After : Dec 31 23:00:00 2029 GMT + Subject: CN = EDHOC Responder Ed25519 + Subject Public Key Info: + Public Key Algorithm: ED25519 + ED25519 Public-Key: + pub: + a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 + 8a ac e3 3a a0 f2 c6 62 c0 0b 3a c5 5d e9 2f + 93 59 + Signature Algorithm: ED25519 + Signature Value: + b7 23 bc 01 ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 + 6e 7d 69 87 b0 32 47 8f ec fa f1 45 37 a1 af 14 cc 8b + e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 65 d8 6d ce + 51 cf ae 52 ab 82 c1 52 cb 02 + +2.8.2. Initiator Certificate + + Version: 3 (0x2) + Serial Number: 1647419040 (0x62319ea0) + Signature Algorithm: ED25519 + Issuer: CN = EDHOC Root Ed25519 + Validity + Not Before: Mar 16 08:24:00 2022 GMT + Not After : Dec 31 23:00:00 2029 GMT + Subject: CN = EDHOC Initiator Ed25519 + Subject Public Key Info: + Public Key Algorithm: ED25519 + ED25519 Public-Key: + pub: + ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f + 48 dd 44 a3 02 f4 3e 0f 23 d8 cc 20 b7 30 85 + 14 1e + Signature Algorithm: ED25519 + Signature Value: + 52 12 41 d8 b3 a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 + db 35 3a 3b df 29 10 b3 92 75 ae 48 b7 56 01 59 81 85 + 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff 27 b9 e7 + a8 13 fa 57 4b 72 a0 0b 43 0b + +2.8.3. Common Root Certificate + + Version: 3 (0x2) + Serial Number: 1647418996 (0x62319e74) + Signature Algorithm: ED25519 + Issuer: CN = EDHOC Root Ed25519 + Validity + Not Before: Mar 16 08:23:16 2022 GMT + Not After : Dec 31 23:00:00 2029 GMT + Subject: CN = EDHOC Root Ed25519 + Subject Public Key Info: + Public Key Algorithm: ED25519 + ED25519 Public-Key: + pub: + 2b 7b 3e 80 57 c8 64 29 44 d0 6a fe 7a 71 d1 + c9 bf 96 1b 62 92 ba c4 b0 4f 91 66 9b bb 71 + 3b e4 + X509v3 extensions: + X509v3 Key Usage: critical + Certificate Sign + X509v3 Basic Constraints: critical + CA:TRUE + Signature Algorithm: ED25519 + Signature Value: + 4b b5 2b bf 15 39 b7 1a 4a af 42 97 78 f2 9e da 7e 81 + 46 80 69 8f 16 c4 8f 2a 6f a4 db e8 25 41 c5 82 07 ba + 1b c9 cd b0 c2 fa 94 7f fb f0 f0 ec 0e e9 1a 7f f3 7a + 94 d9 25 1f a5 cd f1 e6 7a 0f + +3. Authentication with Static DH, CCS Identified by 'kid' + + In this example, the Initiator and the Responder are authenticated + with ephemeral-static Diffie-Hellman (METHOD = 3). The Initiator + supports cipher suites 6 and 2 (in order of preference), and the + Responder 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 (RPKs), encoded in + a CWT Claims Set (CCS) and identified by the COSE header parameter + 'kid'. + +3.1. message_1 (First Time) + + Both endpoints are authenticated with static DH, i.e., METHOD = 3: + + METHOD (CBOR Data Item) (1 byte) + 03 + + The Initiator selects its preferred cipher suite 6. A single cipher + suite is encoded as an int: + + SUITES_I (CBOR Data Item) (1 byte) + 06 + + The Initiator creates an ephemeral key pair for use with the EDHOC + key exchange algorithm: + + Initiator's ephemeral private key + X (Raw Value) (32 bytes) + 5c 41 72 ac a8 b8 2b 5a 62 e6 6f 72 22 16 f5 a1 0f 72 aa 69 f4 2c 1d + 1c d3 cc d7 bf d2 9c a4 e9 + + Initiator's ephemeral public key, 'x'-coordinate + G_X (Raw Value) (32 bytes) + 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b 3d 8f 65 f3 26 + 20 b7 49 be e8 d2 78 ef a9 + + Initiator's ephemeral public key, 'x'-coordinate + G_X (CBOR Data Item) (34 bytes) + 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b 3d 8f 65 + f3 26 20 b7 49 be e8 d2 78 ef a9 + + The Initiator selects its connection identifier C_I to be the byte + string 0x0e, which is encoded as 0x0e since it is represented by the + 1-byte CBOR int 14: + + Connection identifier chosen by the Initiator + C_I (Raw Value) (1 byte) + 0e + + Connection identifier chosen by the Initiator + C_I (CBOR Data Item) (1 byte) + 0e + + No external authorization data: + + EAD_1 (CBOR Sequence) (0 bytes) + + The Initiator constructs message_1: + + message_1 = + ( + 3, + 6, + h'741a13d7ba048fbb615e94386aa3b61bea5b3d8f65f32620 + b749bee8d278efa9', + 14 + ) + + message_1 (CBOR Sequence) (37 bytes) + 03 06 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b 3d + 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e + +3.2. error + + The Responder does not support cipher suite 6 and sends an error with + ERR_CODE 2 containing SUITES_R as ERR_INFO. The Responder proposes + cipher suite 2, a single cipher suite thus encoded as an int. + + SUITES_R + 02 + + error (CBOR Sequence) (2 bytes) + 02 02 + +3.3. message_1 (Second Time) + + Same steps are performed as for message_1 the first time + (Section 3.1) but with SUITES_I updated. + + Both endpoints are authenticated with static DH, i.e., METHOD = 3: + + METHOD (CBOR Data Item) (1 byte) + 03 + + The Initiator selects cipher suite 2 and indicates the more preferred + cipher suite(s), in this case 6, all encoded as the array [6, 2]: + + SUITES_I (CBOR Data Item) (3 bytes) + 82 06 02 + + The Initiator creates an ephemeral key pair for use with the EDHOC + key exchange algorithm: + + Initiator's ephemeral private key + X (Raw Value) (32 bytes) + 36 8e c1 f6 9a eb 65 9b a3 7d 5a 8d 45 b2 1b dc 02 99 dc ea a8 ef 23 + 5f 3c a4 2c e3 53 0f 95 25 + + Initiator's ephemeral public key, 'x'-coordinate + G_X (Raw Value) (32 bytes) + 8a f6 f4 30 eb e1 8d 34 18 40 17 a9 a1 1b f5 11 c8 df f8 f8 34 73 0b + 96 c1 b7 c8 db ca 2f c3 b6 + + Initiator's ephemeral public key, one 'y'-coordinate + (Raw Value) (32 bytes) + 51 e8 af 6c 6e db 78 16 01 ad 1d 9c 5f a8 bf 7a a1 57 16 c7 c0 6a 5d + 03 85 03 c6 14 ff 80 c9 b3 + + Initiator's ephemeral public key, 'x'-coordinate + G_X (CBOR Data Item) (34 bytes) + 58 20 8a f6 f4 30 eb e1 8d 34 18 40 17 a9 a1 1b f5 11 c8 df f8 f8 34 + 73 0b 96 c1 b7 c8 db ca 2f c3 b6 + + The Initiator selects its connection identifier C_I to be the byte + string 0x37, which is encoded as 0x37 since it is represented by the + 1-byte CBOR int -24: + + Connection identifier chosen by the Initiator + C_I (Raw Value) (1 byte) + 37 + + Connection identifier chosen by the Initiator + C_I (CBOR Data Item) (1 byte) + 37 + + No external authorization data: + + EAD_1 (CBOR Sequence) (0 bytes) + + The Initiator constructs message_1: + + message_1 = + ( + 3, + [6, 2], + h'8af6f430ebe18d34184017a9a11bf511c8dff8f834730b96 + c1b7c8dbca2fc3b6', + -24 + ) + + message_1 (CBOR Sequence) (39 bytes) + 03 82 06 02 58 20 8a f6 f4 30 eb e1 8d 34 18 40 17 a9 a1 1b f5 11 c8 + df f8 f8 34 73 0b 96 c1 b7 c8 db ca 2f c3 b6 37 + +3.4. message_2 + + The Responder supports the selected cipher suite 2 and not the + Initiator's more preferred cipher suite(s) 6, so SUITES_I is + acceptable. + + The Responder creates an ephemeral key pair for use with the EDHOC + key exchange algorithm: + + Responder's ephemeral private key + Y (Raw Value) (32 bytes) + e2 f4 12 67 77 20 5e 85 3b 43 7d 6e ac a1 e1 f7 53 cd cc 3e 2c 69 fa + 88 4b 0a 1a 64 09 77 e4 18 + + Responder's ephemeral public key, 'x'-coordinate + G_Y (Raw Value) (32 bytes) + 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93 42 2c + 8e a0 f9 55 a1 3a 4f f5 d5 + + Responder's ephemeral public key, one 'y'-coordinate + (Raw Value) (32 bytes) + 5e 4f 0d d8 a3 da 0b aa 16 b9 d3 ad 56 a0 c1 86 0a 94 0a f8 59 14 91 + 5e 25 01 9b 40 24 17 e9 9d + + Responder's ephemeral public key, 'x'-coordinate + G_Y (CBOR Data Item) (34 bytes) + 58 20 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93 + 42 2c 8e a0 f9 55 a1 3a 4f f5 d5 + + The Responder selects its connection identifier C_R to be the byte + string 0x27, which is encoded as 0x27 since it is represented by the + 1-byte CBOR int -8: + + Connection identifier chosen by the Responder + C_R (raw value) (1 byte) + 27 + + Connection identifier chosen by the Responder + C_R (CBOR Data Item) (1 byte) + 27 + + The transcript hash TH_2 is calculated using the EDHOC hash + algorithm: + + TH_2 = H( G_Y, H(message_1) ) + + H(message_1) (Raw Value) (32 bytes) + ca 02 ca bd a5 a8 90 27 49 b4 2f 71 10 50 bb 4d bd 52 15 3e 87 52 75 + 94 b3 9f 50 cd f0 19 88 8c + + H(message_1) (CBOR Data Item) (34 bytes) + 58 20 ca 02 ca bd a5 a8 90 27 49 b4 2f 71 10 50 bb 4d bd 52 15 3e 87 + 52 75 94 b3 9f 50 cd f0 19 88 8c + + The input to calculate TH_2 is the CBOR sequence: + + G_Y, H(message_1) + + Input to calculate TH_2 (CBOR Sequence) (68 bytes) + 58 20 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93 + 42 2c 8e a0 f9 55 a1 3a 4f f5 d5 58 20 ca 02 ca bd a5 a8 90 27 49 b4 + 2f 71 10 50 bb 4d bd 52 15 3e 87 52 75 94 b3 9f 50 cd f0 19 88 8c + + TH_2 (Raw Value) (32 bytes) + 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 02 8f f3 + 9d 52 36 c1 82 b2 02 08 4b + + TH_2 (CBOR Data Item) (34 bytes) + 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 02 + 8f f3 9d 52 36 c1 82 b2 02 08 4b + + PRK_2e is specified in Section 4.1.1.1 of [RFC9528]. + + First, the ECDH shared secret G_XY is computed from G_X and Y or G_Y + and X: + + G_XY (Raw Value) (ECDH shared secret) (32 bytes) + 2f 0c b7 e8 60 ba 53 8f bf 5c 8b de d0 09 f6 25 9b 4b 62 8f e1 eb 7d + be 93 78 e5 ec f7 a8 24 ba + + Then, PRK_2e is calculated using EDHOC_Extract(), which is determined + by the EDHOC hash algorithm: + + PRK_2e = EDHOC_Extract( salt, G_XY ) + = HMAC-SHA-256( salt, G_XY ) + + where salt is TH_2: + + salt (Raw Value) (32 bytes) + 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 02 8f f3 + 9d 52 36 c1 82 b2 02 08 4b + + PRK_2e (Raw Value) (32 bytes) + 5a a0 d6 9f 3e 3d 1e 0c 47 9f 0b 8a 48 66 90 c9 80 26 30 c3 46 6b 1d + c9 23 71 c9 82 56 31 70 b5 + + Since METHOD = 3, the Responder 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. + + The Responder's static Diffie-Hellman P-256 key pair consists of a + private key and a public key. + + Responder's private authentication key + SK_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 + + Responder's public authentication key, 'x'-coordinate + (Raw Value) (32 bytes) + bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 91 a1 2a fb + cb ac 93 62 20 46 dd 44 f0 + + Responder's public authentication key, 'y'-coordinate + (Raw Value) (32 bytes) + 45 19 e2 57 23 6b 2a 0c e2 02 3f 09 31 f1 f3 86 ca 7a fd a6 4f cd e0 + 10 8c 22 4c 51 ea bf 60 72 + + Since the Responder 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 [RFC9528], using EDHOC_Expand() with the EDHOC hash algorithm: + + SALT_3e2m = EDHOC_KDF( PRK_2e, 1, TH_2, hash_length ) + = HKDF-Expand( PRK_2e, info, hash_length ) + + where hash_length is the length in bytes of the output of the EDHOC + hash algorithm, and info for SALT_3e2m is: + + info = + ( + 1, + h'356efd53771425e008f3fe3a86c83ff4c6b16e57028ff39d + 5236c182b202084b', + 32 + ) + + info for SALT_3e2m (CBOR Sequence) (37 bytes) + 01 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 + 02 8f f3 9d 52 36 c1 82 b2 02 08 4b 18 20 + + SALT_3e2m (Raw Value) (32 bytes) + af 4e 10 3a 47 cb 3c f3 25 70 d5 c2 5a d2 77 32 bd 8d 81 78 e9 a6 9d + 06 1c 31 a2 7f 8e 3c a9 26 + + PRK_3e2m is specified in Section 4.1.1.2 of [RFC9528]. + + PRK_3e2m is derived from G_RX using EDHOC_Extract() with the EDHOC + hash algorithm: + + PRK_3e2m = EDHOC_Extract( SALT_3e2m, G_RX ) + = HMAC-SHA-256( SALT_3e2m, G_RX ) + + where G_RX is the ECDH shared secret calculated from G_X and R, or + G_R and X. + + G_RX (Raw Value) (ECDH shared secret) (32 bytes) + f2 b6 ee a0 22 20 b9 5e ee 5a 0b c7 01 f0 74 e0 0a 84 3e a0 24 22 f6 + 08 25 fb 26 9b 3e 16 14 23 + + PRK_3e2m (Raw Value) (32 bytes) + 0c a3 d3 39 82 96 b3 c0 39 00 98 76 20 c1 1f 6f ce 70 78 1c 1d 12 19 + 72 0f 9e c0 8c 12 2d 84 34 + + The Responder constructs the remaining input needed to calculate + MAC_2: + + MAC_2 = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 ) + + context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >> + + CRED_R is identified by a 'kid' with byte string value 0x32: + + ID_CRED_R = + { + 4 : h'32' + } + + ID_CRED_R (CBOR Data Item) (4 bytes) + a1 04 41 32 + + CRED_R is an RPK encoded as a CCS: + + { /CCS/ + 2 : "example.edu", /sub/ + 8 : { /cnf/ + 1 : { /COSE_Key/ + 1 : 2, /kty/ + 2 : h'32', /kid/ + -1 : 1, /crv/ + -2 : h'bbc34960526ea4d32e940cad2a234148 + ddc21791a12afbcbac93622046dd44f0', /x/ + -3 : h'4519e257236b2a0ce2023f0931f1f386 + ca7afda64fcde0108c224c51eabf6072' /y/ + } + } + } + + CRED_R (CBOR Data Item) (95 bytes) + a2 02 6b 65 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 + 20 01 21 58 20 bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 + 17 91 a1 2a fb cb ac 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b + 2a 0c e2 02 3f 09 31 f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea + bf 60 72 + + No external authorization data: + + EAD_2 (CBOR Sequence) (0 bytes) + + context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >> + + context_2 (CBOR Sequence) (134 bytes) + 27 a1 04 41 32 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 + c6 b1 6e 57 02 8f f3 9d 52 36 c1 82 b2 02 08 4b a2 02 6b 65 78 61 6d + 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 20 01 21 58 20 bb c3 + 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 91 a1 2a fb cb ac + 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b 2a 0c e2 02 3f 09 31 + f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea bf 60 72 + + context_2 (CBOR byte string) (136 bytes) + 58 86 27 a1 04 41 32 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 + 3f f4 c6 b1 6e 57 02 8f f3 9d 52 36 c1 82 b2 02 08 4b a2 02 6b 65 78 + 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 20 01 21 58 20 + bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 91 a1 2a fb + cb ac 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b 2a 0c e2 02 3f + 09 31 f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea bf 60 72 + + MAC_2 is computed through EDHOC_Expand() using the EDHOC hash + algorithm (see Section 4.1.2 of [RFC9528]): + + 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: + + info = + ( + 2, + h'27a10441325820356efd53771425e008f3fe3a86c83ff4c6 + b16e57028ff39d5236c182b202084ba2026b6578616d706c + 652e65647508a101a501020241322001215820bbc3496052 + 6ea4d32e940cad2a234148ddc21791a12afbcbac93622046 + dd44f02258204519e257236b2a0ce2023f0931f1f386ca7a + fda64fcde0108c224c51eabf6072', + 8 + ) + + where the last value is the EDHOC MAC length in bytes. + + info for MAC_2 (CBOR Sequence) (138 bytes) + 02 58 86 27 a1 04 41 32 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 + c8 3f f4 c6 b1 6e 57 02 8f f3 9d 52 36 c1 82 b2 02 08 4b a2 02 6b 65 + 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 20 01 21 58 + 20 bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 91 a1 2a + fb cb ac 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b 2a 0c e2 02 + 3f 09 31 f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea bf 60 72 08 + + MAC_2 (Raw Value) (8 bytes) + 09 43 30 5c 89 9f 5c 54 + + MAC_2 (CBOR Data Item) (9 bytes) + 48 09 43 30 5c 89 9f 5c 54 + + Since METHOD = 3, Signature_or_MAC_2 is MAC_2: + + Signature_or_MAC_2 (Raw Value) (8 bytes) + 09 43 30 5c 89 9f 5c 54 + + Signature_or_MAC_2 (CBOR Data Item) (9 bytes) + 48 09 43 30 5c 89 9f 5c 54 + + The Responder constructs PLAINTEXT_2: + + PLAINTEXT_2 = + ( + C_R, + ID_CRED_R / bstr / -24..23, + Signature_or_MAC_2, + ? EAD_2 + ) + + 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 [RFC9528]. 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). + + PLAINTEXT_2 (CBOR Sequence) (11 bytes) + 27 32 48 09 43 30 5c 89 9f 5c 54 + + The input needed to calculate KEYSTREAM_2 is defined in Section 4.1.2 + of [RFC9528], using EDHOC_Expand() with the EDHOC hash algorithm: + + KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length ) + = HKDF-Expand( PRK_2e, info, plaintext_length ) + + where plaintext_length is the length in bytes of PLAINTEXT_2, and + info for KEYSTREAM_2 is: + + info = + ( + 0, + h'356efd53771425e008f3fe3a86c83ff4c6b16e57028ff39d + 5236c182b202084b', + 11 + ) + + where the last value is the length in bytes of PLAINTEXT_2. + + info for KEYSTREAM_2 (CBOR Sequence) (36 bytes) + 00 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 + 02 8f f3 9d 52 36 c1 82 b2 02 08 4b 0b + + KEYSTREAM_2 (Raw Value) (11 bytes) + bf 50 e9 e7 ba d0 bb 68 17 33 99 + + The Responder calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and + KEYSTREAM_2: + + CIPHERTEXT_2 (Raw Value) (11 bytes) + 98 62 a1 ee f9 e0 e7 e1 88 6f cd + + The Responder constructs message_2: + + message_2 = + ( + G_Y_CIPHERTEXT_2 + ) + + where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of + the raw values of G_Y and CIPHERTEXT_2. + + message_2 (CBOR Sequence) (45 bytes) + 58 2b 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93 + 42 2c 8e a0 f9 55 a1 3a 4f f5 d5 98 62 a1 ee f9 e0 e7 e1 88 6f cd + +3.5. message_3 + + The transcript hash TH_3 is calculated using the EDHOC hash + algorithm: + + TH_3 = H( TH_2, PLAINTEXT_2, CRED_R ) + + Input to calculate TH_3 (CBOR Sequence) (140 bytes) + 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 02 + 8f f3 9d 52 36 c1 82 b2 02 08 4b 27 32 48 09 43 30 5c 89 9f 5c 54 a2 + 02 6b 65 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 20 + 01 21 58 20 bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 + 91 a1 2a fb cb ac 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b 2a + 0c e2 02 3f 09 31 f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea bf + 60 72 + + TH_3 (Raw Value) (32 bytes) + ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 03 9d f0 + bc 1b bf 0c 16 1b b3 15 5c + + TH_3 (CBOR Data Item) (34 bytes) + 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 03 + 9d f0 bc 1b bf 0c 16 1b b3 15 5c + + Since METHOD = 3, the Initiator 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. + + The Initiator's static Diffie-Hellman P-256 key pair consists of a + private key and a public key: + + Initiator's private authentication key + SK_I (Raw Value) (32 bytes) + fb 13 ad eb 65 18 ce e5 f8 84 17 66 08 41 14 2e 83 0a 81 fe 33 43 80 + a9 53 40 6a 13 05 e8 70 6b + + Initiator's public authentication key, 'x'-coordinate + (Raw Value) (32 bytes) + ac 75 e9 ec e3 e5 0b fc 8e d6 03 99 88 95 22 40 5c 47 bf 16 df 96 66 + 0a 41 29 8c b4 30 7f 7e b6 + + Initiator's public authentication key, 'y'-coordinate + (Raw Value) (32 bytes) + 6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 d2 57 e6 db + 3c 2a 93 df 21 ff 3a ff c8 + + 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 [RFC9528], using EDHOC_Expand() with the EDHOC hash algorithm: + + SALT_4e3m = EDHOC_KDF( PRK_3e2m, 5, TH_3, hash_length ) + = HKDF-Expand( PRK_3e2m, info, hash_length ) + + where hash_length is the length in bytes of the output of the EDHOC + hash algorithm, and info for SALT_4e3m is: + + info = + ( + 5, + h'adaf67a78a4bcc91e018f8882762a722000b2507039df0bc + 1bbf0c161bb3155c', + 32 + ) + + info for SALT_4e3m (CBOR Sequence) (37 bytes) + 05 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 + 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c 18 20 + + SALT_4e3m (Raw Value) (32 bytes) + cf dd f9 51 5a 7e 46 e7 b4 db ff 31 cb d5 6c d0 4b a3 32 25 0d e9 ea + 5d e1 ca f9 f6 d1 39 14 a7 + + PRK_4e3m is specified in Section 4.1.1.3 of [RFC9528]. + + Since I authenticates with static DH (METHOD = 3), PRK_4e3m is + derived from G_IY using EDHOC_Extract() with the EDHOC hash + algorithm: + + PRK_4e3m = EDHOC_Extract(SALT_4e3m, G_IY) + = HMAC-SHA-256(SALT_4e3m, G_IY) + + where G_IY is the ECDH shared secret calculated from G_I and Y, or + G_Y and I. + + G_IY (Raw Value) (ECDH shared secret) (32 bytes) + 08 0f 42 50 85 bc 62 49 08 9e ac 8f 10 8e a6 23 26 85 7e 12 ab 07 d7 + 20 28 ca 1b 5f 36 e0 04 b3 + + PRK_4e3m (Raw Value) (32 bytes) + 81 cc 8a 29 8e 35 70 44 e3 c4 66 bb 5c 0a 1e 50 7e 01 d4 92 38 ae ba + 13 8d f9 46 35 40 7c 0f f7 + + The Initiator 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 = + { + 4 : h'2b' + } + + ID_CRED_I (CBOR Data Item) (4 bytes) + a1 04 41 2b + + CRED_I is an RPK encoded as a CCS: + + { /CCS/ + 2 : "42-50-31-FF-EF-37-32-39", /sub/ + 8 : { /cnf/ + 1 : { /COSE_Key/ + 1 : 2, /kty/ + 2 : h'2b', /kid/ + -1 : 1, /crv/ + -2 : h'ac75e9ece3e50bfc8ed6039988952240 + 5c47bf16df96660a41298cb4307f7eb6' /x/ + -3 : h'6e5de611388a4b8a8211334ac7d37ecb + 52a387d257e6db3c2a93df21ff3affc8' /y/ + } + } + } + + CRED_I (CBOR Data Item) (107 bytes) + a2 02 77 34 32 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 + 2d 33 39 08 a1 01 a5 01 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 + 0b fc 8e d6 03 99 88 95 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 + 7f 7e b6 22 58 20 6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 + a3 87 d2 57 e6 db 3c 2a 93 df 21 ff 3a ff c8 + + No external authorization data: + + EAD_3 (CBOR Sequence) (0 bytes) + + context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> + + context_3 (CBOR Sequence) (145 bytes) + a1 04 41 2b 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 + 0b 25 07 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c a2 02 77 34 32 2d 35 30 + 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 33 39 08 a1 01 a5 01 + 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 0b fc 8e d6 03 99 88 95 + 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 7f 7e b6 22 58 20 6e 5d + e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 d2 57 e6 db 3c 2a + 93 df 21 ff 3a ff c8 + + context_3 (CBOR byte string) (147 bytes) + 58 91 a1 04 41 2b 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 + 22 00 0b 25 07 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c a2 02 77 34 32 2d + 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 33 39 08 a1 01 + a5 01 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 0b fc 8e d6 03 99 + 88 95 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 7f 7e b6 22 58 20 + 6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 d2 57 e6 db + 3c 2a 93 df 21 ff 3a ff c8 + + MAC_3 is computed through EDHOC_Expand() using the EDHOC hash + algorithm (see Section 4.1.2 of [RFC9528]): + + MAC_3 = HKDF-Expand( PRK_4e3m, info, mac_length_3 ) + + where + + 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: + + info = + ( + 6, + h'a104412b5820adaf67a78a4bcc91e018f8882762a722000b + 2507039df0bc1bbf0c161bb3155ca2027734322d35302d33 + 312d46462d45462d33372d33322d333908a101a501020241 + 2b2001215820ac75e9ece3e50bfc8ed60399889522405c47 + bf16df96660a41298cb4307f7eb62258206e5de611388a4b + 8a8211334ac7d37ecb52a387d257e6db3c2a93df21ff3aff + c8', + 8 + ) + + where the last value is the EDHOC MAC length in bytes. + + info for MAC_3 (CBOR Sequence) (149 bytes) + 06 58 91 a1 04 41 2b 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 + a7 22 00 0b 25 07 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c a2 02 77 34 32 + 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 33 39 08 a1 + 01 a5 01 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 0b fc 8e d6 03 + 99 88 95 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 7f 7e b6 22 58 + 20 6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 d2 57 e6 + db 3c 2a 93 df 21 ff 3a ff c8 08 + + MAC_3 (Raw Value) (8 bytes) + 62 3c 91 df 41 e3 4c 2f + + MAC_3 (CBOR Data Item) (9 bytes) + 48 62 3c 91 df 41 e3 4c 2f + + Since METHOD = 3, Signature_or_MAC_3 is MAC_3: + + Signature_or_MAC_3 (Raw Value) (8 bytes) + 62 3c 91 df 41 e3 4c 2f + + Signature_or_MAC_3 (CBOR Data Item) (9 bytes) + 48 62 3c 91 df 41 e3 4c 2f + + The Initiator constructs PLAINTEXT_3: + + PLAINTEXT_3 = + ( + ID_CRED_I / bstr / -24..23, + Signature_or_MAC_3, + ? EAD_3 + ) + + 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 [RFC9528]. 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). + + PLAINTEXT_3 (CBOR Sequence) (10 bytes) + 2b 48 62 3c 91 df 41 e3 4c 2f + + The Initiator constructs the associated data for message_3: + + A_3 = + [ + "Encrypt0", + h'', + h'adaf67a78a4bcc91e018f8882762a722000b2507039df0bc + 1bbf0c161bb3155c' + ] + + A_3 (CBOR Data Item) (45 bytes) + 83 68 45 6e 63 72 79 70 74 30 40 58 20 ad af 67 a7 8a 4b cc 91 e0 18 + f8 88 27 62 a7 22 00 0b 25 07 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c + + The Initiator constructs the input needed to derive the key K_3 (see + Section 4.1.2 of [RFC9528]) using the EDHOC hash algorithm: + + K_3 = EDHOC_KDF( PRK_3e2m, 3, TH_3, key_length ) + = HKDF-Expand( PRK_3e2m, info, key_length ) + + where key_length is the key length in bytes for the EDHOC AEAD + algorithm, and info for K_3 is: + + info = + ( + 3, + h'adaf67a78a4bcc91e018f8882762a722000b2507039df0bc + 1bbf0c161bb3155c', + 16 + ) + + where the last value is the key length in bytes for the EDHOC AEAD + algorithm. + + info for K_3 (CBOR Sequence) (36 bytes) + 03 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 + 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c 10 + + K_3 (Raw Value) (16 bytes) + 8e 7a 30 04 20 00 f7 90 0e 81 74 13 1f 75 f3 ed + + The Initiator constructs the input needed to derive the nonce IV_3 + (see Section 4.1.2 of [RFC9528]) using the EDHOC hash algorithm: + + IV_3 = EDHOC_KDF( PRK_3e2m, 4, TH_3, iv_length ) + = HKDF-Expand( PRK_3e2m, info, iv_length ) + + where iv_length is the nonce length in bytes for the EDHOC AEAD + algorithm, and info for IV_3 is: + + info = + ( + 4, + h'adaf67a78a4bcc91e018f8882762a722000b2507039df0bc + 1bbf0c161bb3155c', + 13 + ) + + where the last value is the nonce length in bytes for the EDHOC AEAD + algorithm. + + info for IV_3 (CBOR Sequence) (36 bytes) + 04 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 + 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c 0d + + IV_3 (Raw Value) (13 bytes) + 6d 83 00 c1 e2 3b 56 15 3a e7 0e e4 57 + + The Initiator 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. + + CIPHERTEXT_3 (Raw Value) (18 bytes) + e5 62 09 7b c4 17 dd 59 19 48 5a c7 89 1f fd 90 a9 fc + + message_3 is the CBOR bstr encoding of CIPHERTEXT_3: + + message_3 (CBOR Sequence) (19 bytes) + 52 e5 62 09 7b c4 17 dd 59 19 48 5a c7 89 1f fd 90 a9 fc + + The transcript hash TH_4 is calculated using the EDHOC hash + algorithm: + + TH_4 = H( TH_3, PLAINTEXT_3, CRED_I ) + + Input to calculate TH_4 (CBOR Sequence) (151 bytes) + 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 03 + 9d f0 bc 1b bf 0c 16 1b b3 15 5c 2b 48 62 3c 91 df 41 e3 4c 2f a2 02 + 77 34 32 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 33 + 39 08 a1 01 a5 01 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 0b fc + 8e d6 03 99 88 95 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 7f 7e + b6 22 58 20 6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 + d2 57 e6 db 3c 2a 93 df 21 ff 3a ff c8 + + TH_4 (Raw Value) (32 bytes) + c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06 76 56 12 + e5 2b 5d 99 e6 05 9d 6b 6e + + TH_4 (CBOR Data Item) (34 bytes) + 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06 76 + 56 12 e5 2b 5d 99 e6 05 9d 6b 6e + +3.6. message_4 + + No external authorization data: + + EAD_4 (CBOR Sequence) (0 bytes) + + The Responder constructs PLAINTEXT_4: + + PLAINTEXT_4 = + ( + ? EAD_4 + ) + + PLAINTEXT_4 (CBOR Sequence) (0 bytes) + + The Responder constructs the associated data for message_4: + + A_4 = + [ + "Encrypt0", + h'', + h'c902b1e3a4326c93c5551f5f3aa6c5ecc0246806765612e5 + 2b5d99e6059d6b6e' + ] + + A_4 (CBOR Data Item) (45 bytes) + 83 68 45 6e 63 72 79 70 74 30 40 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 + 1f 5f 3a a6 c5 ec c0 24 68 06 76 56 12 e5 2b 5d 99 e6 05 9d 6b 6e + + The Responder constructs the input needed to derive the EDHOC + message_4 key (see Section 4.1.2 of [RFC9528]) using the EDHOC hash + algorithm: + + K_4 = EDHOC_KDF( PRK_4e3m, 8, TH_4, key_length ) + = HKDF-Expand( PRK_4e3m, info, key_length ) + + where key_length is the key length in bytes for the EDHOC AEAD + algorithm, and info for K_4 is: + + info = + ( + 8, + h'c902b1e3a4326c93c5551f5f3aa6c5ecc0246806765612e5 + 2b5d99e6059d6b6e', + 16 + ) + + where the last value is the key length in bytes for the EDHOC AEAD + algorithm. + + info for K_4 (CBOR Sequence) (36 bytes) + 08 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06 + 76 56 12 e5 2b 5d 99 e6 05 9d 6b 6e 10 + + K_4 (Raw Value) (16 bytes) + d3 c7 78 72 b6 ee b5 08 91 1b db d3 08 b2 e6 a0 + + The Responder constructs the input needed to derive the EDHOC + message_4 nonce (see Section 4.1.2 of [RFC9528]) using the EDHOC hash + algorithm: + + IV_4 = EDHOC_KDF( PRK_4e3m, 9, TH_4, iv_length ) + = HKDF-Expand( PRK_4e3m, info, iv_length ) + + where iv_length is the nonce length in bytes for the EDHOC AEAD + algorithm, and info for IV_4 is: + + info = + ( + 9, + h'c902b1e3a4326c93c5551f5f3aa6c5ecc0246806765612e5 + 2b5d99e6059d6b6e', + 13 + ) + + where the last value is the nonce length in bytes for the EDHOC AEAD + algorithm. + + info for IV_4 (CBOR Sequence) (36 bytes) + 09 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06 + 76 56 12 e5 2b 5d 99 e6 05 9d 6b 6e 0d + + IV_4 (Raw Value) (13 bytes) + 04 ff 0f 44 45 6e 96 e2 17 85 3c 36 01 + + The Responder 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. + + CIPHERTEXT_4 (8 bytes) + 28 c9 66 b7 ca 30 4f 83 + + message_4 is the CBOR bstr encoding of CIPHERTEXT_4: + + message_4 (CBOR Sequence) (9 bytes) + 48 28 c9 66 b7 ca 30 4f 83 + +3.7. PRK_out and PRK_exporter + + PRK_out is specified in Section 4.1.3 of [RFC9528]. + + PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length ) + = HKDF-Expand( PRK_4e3m, info, hash_length ) + + where hash_length is the length in bytes of the output of the EDHOC + hash algorithm, and info for PRK_out is: + + info = + ( + 7, + h'c902b1e3a4326c93c5551f5f3aa6c5ecc0246806765612e5 + 2b5d99e6059d6b6e', + 32 + ) + + where the last value is the length in bytes of the output of the + EDHOC hash algorithm. + + info for PRK_out (CBOR Sequence) (37 bytes) + 07 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06 + 76 56 12 e5 2b 5d 99 e6 05 9d 6b 6e 18 20 + + PRK_out (Raw Value) (32 bytes) + 2c 71 af c1 a9 33 8a 94 0b b3 52 9c a7 34 b8 86 f3 0d 1a ba 0b 4d c5 + 1b ee ae ab df ea 9e cb f8 + + The OSCORE Master Secret and OSCORE Master Salt are derived with the + EDHOC_Exporter as specified in Section 4.2.1 of [RFC9528]. + + EDHOC_Exporter( exporter_label, context, length ) + = EDHOC_KDF( PRK_exporter, exporter_label, context, length ) + + where PRK_exporter is derived from PRK_out: + + PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) + = HKDF-Expand( PRK_out, info, hash_length ) + + where hash_length is the length in bytes of the output of the EDHOC + hash algorithm, and info for the PRK_exporter is: + + info = + ( + 10, + h'', + 32 + ) + + where the last value is the length in bytes of the output of the + EDHOC hash algorithm. + + info for PRK_exporter (CBOR Sequence) (4 bytes) + 0a 40 18 20 + + PRK_exporter (Raw Value) (32 bytes) + e1 4d 06 69 9c ee 24 8c 5a 04 bf 92 27 bb cd 4c e3 94 de 7d cb 56 db + 43 55 54 74 17 1e 64 46 db + +3.8. OSCORE Parameters + + The derivation of OSCORE parameters is specified in Appendix A.1 of + [RFC9528]. + + The AEAD and hash algorithms to use in OSCORE are given by the + selected cipher suite: + + Application AEAD Algorithm (int) + 10 + + Application Hash Algorithm (int) + -16 + + The mapping from EDHOC connection identifiers to OSCORE Sender/ + Recipient IDs is defined in Section 3.3.3 of [RFC9528]. + + 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. + + Client's OSCORE Sender ID (Raw Value) (1 byte) + 27 + + 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. + + Server's OSCORE Sender ID (Raw Value) (1 byte) + 37 + + The OSCORE Master Secret is computed through EDHOC_Expand() using the + application hash algorithm (see Appendix A.1 of [RFC9528]): + + OSCORE Master Secret = EDHOC_Exporter( 0, h'', oscore_key_length ) + = EDHOC_KDF( PRK_exporter, 0, h'', oscore_key_length ) + = HKDF-Expand( PRK_exporter, info, oscore_key_length ) + + where oscore_key_length is by default the key length in bytes for the + application AEAD algorithm, and info for the OSCORE Master Secret is: + + info = + ( + 0, + h'', + 16 + ) + + where the last value is the key length in bytes for the application + AEAD algorithm. + + info for OSCORE Master Secret (CBOR Sequence) (3 bytes) + 00 40 10 + + OSCORE Master Secret (Raw Value) (16 bytes) + f9 86 8f 6a 3a ca 78 a0 5d 14 85 b3 50 30 b1 62 + + The OSCORE Master Salt is computed through EDHOC_Expand() using the + application hash algorithm (see Section 4.2 of [RFC9528]): + + OSCORE Master Salt = EDHOC_Exporter( 1, h'', oscore_salt_length ) + = EDHOC_KDF( PRK_exporter, 1, h'', oscore_salt_length ) + = HKDF-Expand( PRK_4x3m, info, oscore_salt_length ) + + where oscore_salt_length is the length in bytes of the OSCORE Master + Salt, and info for the OSCORE Master Salt is: + + info = + ( + 1, + h'', + 8 + ) + + where the last value is the length in bytes of the OSCORE Master + Salt. + + info for OSCORE Master Salt (CBOR Sequence) (3 bytes) + 01 40 08 + + OSCORE Master Salt (Raw Value) (8 bytes) + ad a2 4c 7d bf c8 5e eb + +3.9. Key Update + + The key update is defined in Appendix H of [RFC9528]. + + EDHOC_KeyUpdate( context ): + PRK_out = EDHOC_KDF( PRK_out, 11, context, hash_length ) + = HKDF-Expand( PRK_out, info, hash_length ) + + where hash_length is the length in bytes of the output of the EDHOC + hash function, and the context for KeyUpdate is: + + context for KeyUpdate (Raw Value) (16 bytes) + a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea + + context for KeyUpdate (CBOR Data Item) (17 bytes) + 50 a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea + + and where info for the key update is: + + info = + ( + 11, + h'a01158fdb820890cd6be169602b8bcea', + 32 + ) + + info for KeyUpdate (CBOR Sequence) (20 bytes) + 0b 50 a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea 18 20 + + PRK_out after KeyUpdate (Raw Value) (32 bytes) + f9 79 53 77 43 fe 0b d6 b9 b1 41 dd bd 79 65 6c 52 e6 dc 7c 50 ad 80 + 77 54 d7 4d 07 e8 7d 0d 16 + + After the key update, the PRK_exporter needs to be derived anew: + + PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) + = HKDF-Expand( PRK_out, info, hash_length ) + + where info and hash_length are unchanged as in Section 3.7. + + PRK_exporter after KeyUpdate (Raw Value) (32 bytes) + 00 fc f7 db 9b 2e ad 73 82 4e 7e 83 03 63 c8 05 c2 96 f9 02 83 0f ac + 23 d8 6c 35 9c 75 2f 0f 17 + + The OSCORE Master Secret is derived with the updated PRK_exporter: + + OSCORE Master Secret + = HKDF-Expand( PRK_exporter, info, oscore_key_length ) + + where info and oscore_key_length are unchanged as in Section 3.8. + + OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes) + 49 f7 2f ac 02 b4 65 8b da 21 e2 da c6 6f c3 74 + + The OSCORE Master Salt is derived with the updated PRK_exporter: + + OSCORE Master Salt + = HKDF-Expand( PRK_exporter, info, oscore_salt_length ) + + where info and oscore_salt_length are unchanged as in Section 3.8. + + OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes) + dd 8b 24 f2 aa 9b 01 1a + +4. Invalid Traces + + This section contains examples of invalid messages, which a compliant + implementation will not compose and must or may reject according to + [RFC9528], [RFC8949], [RFC9053], and [SP-800-56A]. This is just a + small set of examples of different reasons for which a message might + be invalid. The same types of invalidities apply to other fields and + messages as well. Implementations should make sure to check for + similar types of invalidities in all EDHOC fields and messages. + +4.1. Encoding Errors + +4.1.1. Surplus Array Encoding of a Message + + message_1 is incorrectly encoded as a CBOR array. The correct + encoding is a CBOR sequence according to Section 5.2.1 of [RFC9528]. + + Invalid message_1 (38 bytes) + 84 03 02 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b + 3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e + +4.1.2. Surplus bstr Encoding of the Connection Identifier + + The connection identifier C_I = 0x0e is incorrectly encoded as the + CBOR byte string 41 0e. The correct encoding is the integer 0e + according to Section 3.3.2 of [RFC9528]. + + Invalid message_1 (38 bytes) + 03 02 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b 3d + 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 41 0e + +4.1.3. Surplus Array Encoding of the Ciphersuite + + The element SUITES_I = 2 is incorrectly encoded as the CBOR array 81 + 02. The correct encoding is the integer 02 according to + Section 5.2.2 of [RFC9528]. + + Invalid message_1 (38 bytes) + 03 81 02 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b + 3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e + +4.1.4. Text String Encoding of the Ephemeral Key + + The third element of message_1 (G_X) is incorrectly encoded as a text + string. The correct encoding is a byte string according to + Section 5.2.1 of [RFC9528]. + + Invalid message_1 (37 bytes) + 03 02 78 20 20 61 69 72 20 73 70 65 65 64 20 6F 66 20 61 20 75 6E 6C + 61 64 65 6E 20 73 77 61 6C 6C 6F 77 20 0e + +4.1.5. Wrong Number of CBOR Sequence Elements + + The CBOR sequence in message_2 has an incorrect number of elements. + The correct number of elements in the CBOR sequence is 1 according to + Section 5.3.1 of [RFC9528]. + + Invalid message_2 (46 bytes) + 58 20 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93 + 42 2c 8e a0 f9 55 a1 3a 4f f5 d5 4B 98 62 a1 1d e4 2a 95 d7 85 38 6a + +4.1.6. Surplus Map Encoding of the ID_CRED Field + + The element ID_CRED_R in PLAINTEXT_2 is incorrectly encoded as the + map a1 04 42 32 10. The correct encoding is 42 32 10 according to + Section 3.5.3.2 of [RFC9528]. + + Invalid PLAINTEXT_2 (15 bytes) + 27 a1 04 42 32 10 48 fa 5e fa 2e bf 92 0b f3 + +4.1.7. Surplus bstr Encoding of the ID_CRED Field + + The element ID_CRED_R in PLAINTEXT_2 is incorrectly encoded as the + byte string 41 32. The correct encoding is 32 according to + Section 3.5.3.2 of [RFC9528]. + + Invalid PLAINTEXT_2 (12 bytes) + 27 41 32 48 fa 5e fa 2e bf 92 0b f3 + +4.2. Cryptography-Related Errors + +4.2.1. Error in the Length of the Ephemeral Key + + The third element (G_X) has an invalid length. The selected cipher + suite is cipher suite 24 with curve P-384 according to Sections 5.2.2 + and 10.2 of [RFC9528]. The correct length of the x-coordinate is 48 + bytes according to Section 3.7 of [RFC9528] and Section 7.1.1 of + [RFC9053]. + + Invalid message_1 (40 bytes) + 03 82 02 18 18 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b + ea 5b 3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e + +4.2.2. Error in Elliptic Curve Representation + + The x-coordinate in G_X is invalid as x ≥ p. It is required that x < + p according to Section 5.6.2.3 of [SP-800-56A], which is referenced + in Section 9.2 of [RFC9528]. + + Invalid message_1 (37 bytes) + 03 02 58 20 ff ff ff ff 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 + 00 ff ff ff ff ff ff ff ff ff ff ff ff 0e + +4.2.3. Error in the Elliptic Curve Point + + The x-coordinate in G_X is invalid as it does not correspond to a + point on the P-256 curve. It is required that y^2 ≡ x^3 + a ⋅ x + b + (mod p) according to Section 5.6.2.3 of [SP-800-56A], which is + referenced in Section 9.2 of [RFC9528]. + + Invalid message_1 (37 bytes) + 03 02 58 20 a0 4e 73 60 1d f5 44 a7 0b a7 ea 1e 57 03 0f 7d 4b 4e b7 + f6 73 92 4e 58 d5 4c a7 7a 5e 7d 4d 4a 0e + +4.2.4. Curve Point of the Low Order + + The Curve25519 point is invalid as it is of low order and fails the + check for all-zero output according to Section 9.2 of [RFC9528]. + + Invalid message_1 (37 bytes) + 03 00 58 20 ed ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + ff ff ff ff ff ff ff ff ff ff ff ff 7f 0e + +4.2.5. Error in the Length of the MAC + + The third element (Signature_or_MAC_2) has an invalid length. The + length of Signature_or_MAC_2 is given by the cipher suite, and the + MAC length is at least 8 bytes according to Section 9.3 of [RFC9528]. + + Invalid PLAINTEXT_2 (7 bytes) + 27 32 44 fa 5e fa 2e + +4.2.6. Error in the Elliptic Curve Encoding + + The third element (G_X) is incorrectly encoded. The correct encoding + is with leading-zero octets according to Section 7.1.1 of [RFC9053], + which is referenced in Section 3.7 of [RFC9528]. + + Invalid message_1 (36 bytes) + 03 02 58 1f d9 69 77 25 d2 3a 68 8b 12 d1 c7 e0 10 8a 08 c9 f7 1a 85 + a0 9c 20 81 49 76 ab 21 12 22 48 fc 0e + +4.3. Non-deterministic CBOR + +4.3.1. Unnecessary Long Encoding + + The element METHOD = 3 is incorrectly encoded as a 16-bit integer. + The deterministic encoding 03 is correct according to Section 3.1 of + [RFC9528] and Section 4.2.1 of [RFC8949], which states that the + arguments for integers, lengths in major types 2 through 5, and tags + are required to be as short as possible. + + Invalid message_1 (39 bytes) + 19 00 03 02 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea + 5b 3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e + +4.3.2. Indefinite-Length Array Encoding + + The element SUITES_I = [6, 2] is incorrectly encoded as an + indefinite-length array. The correct encoding is the definite-length + array 82 06 02 according to Section 4.2.1 of [RFC8949], which is + referenced in Section 3.1 of [RFC9528]. + + Invalid message_1 (40 bytes) + 03 9F 06 02 FF 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b + ea 5b 3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e + +5. Security Considerations + + This document contains examples of EDHOC [RFC9528]. The security + considerations described in [RFC9528] apply. The keys printed in + these examples cannot be considered secret and MUST NOT be used. + +6. IANA Considerations + + This document has no IANA actions. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini, + "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, + DOI 10.17487/RFC9528, March 2024, + <https://www.rfc-editor.org/rfc/rfc9528>. + +7.2. Informative References + + [CborMe] Bormann, C., "CBOR playground", <https://cbor.me/>. + + [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves + for Security", RFC 7748, DOI 10.17487/RFC7748, January + 2016, <https://www.rfc-editor.org/info/rfc7748>. + + [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital + Signature Algorithm (EdDSA)", RFC 8032, + DOI 10.17487/RFC8032, January 2017, + <https://www.rfc-editor.org/info/rfc8032>. + + [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, + "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, + May 2018, <https://www.rfc-editor.org/info/rfc8392>. + + [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", STD 94, RFC 8949, + DOI 10.17487/RFC8949, December 2020, + <https://www.rfc-editor.org/info/rfc8949>. + + [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): + Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, + August 2022, <https://www.rfc-editor.org/info/rfc9053>. + + [SP-800-186] + Chen, L., Moody, D., Randall, K., Regenscheid, A., and A. + Robinson, "Recommendations for Discrete Logarithm-based + Cryptography: Elliptic Curve Domain Parameters", + NIST Special Publication 800-186, + DOI 10.6028/NIST.SP.800-186, February 2023, + <https://doi.org/10.6028/NIST.SP.800-186>. + + [SP-800-56A] + Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. + Davis, "Recommendation for Pair-Wise Key-Establishment + Schemes Using Discrete Logarithm Cryptography", + NIST Special Publication 800-56A Revision 3, + DOI 10.6028/NIST.SP.800-56Ar3, April 2018, + <https://doi.org/10.6028/NIST.SP.800-56Ar3>. + +Acknowledgments + + The authors want to thank all people verifying EDHOC test vectors + and/or contributing to the interoperability testing, including: + Christian Amsüss, Timothy Claeys, Rikard Höglund, Stefan Hristozov, + Christos Koulamas, Francesca Palombini, Lidia Pocero, Peter van der + Stok, and Michel Veillette. + +Authors' Addresses + + Göran Selander + Ericsson + Sweden + Email: goran.selander@ericsson.com + + + John Preuß Mattsson + Ericsson + Sweden + Email: john.mattsson@ericsson.com + + + Marek Serafin + ASSA ABLOY + Poland + Email: marek.serafin@assaabloy.com + + + Marco Tiloca + RISE AB + Isafjordsgatan 22 + SE-164 40 Kista + Sweden + Email: marco.tiloca@ri.se + + + Mališa Vučinić + Inria + France + Email: malisa.vucinic@inria.fr |