idnits 2.17.1 draft-selander-lake-traces-02.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 October 2021) is 912 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Selander 3 Internet-Draft J. Preuß Mattsson 4 Intended status: Standards Track Ericsson 5 Expires: 24 April 2022 21 October 2021 7 Traces of EDHOC 8 draft-selander-lake-traces-02 10 Abstract 12 This document contains some example traces of Ephemeral Diffie- 13 Hellman Over COSE (EDHOC). 15 Discussion Venues 17 This note is to be removed before publishing as an RFC. 19 Discussion of this document takes place on the Lightweight 20 Authenticated Key Exchange Working Group mailing list 21 (lake@ietf.org), which is archived at 22 https://mailarchive.ietf.org/arch/browse/lake/. 24 Source for this draft and an issue tracker can be found at 25 https://github.com/lake-wg/edhoc. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 24 April 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Authentication with static DH, CCS identified by 'kid' . . . 4 63 3.1. message_1 . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. message_2 . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. message_3 . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.4. message_4 . . . . . . . . . . . . . . . . . . . . . . . . 15 67 3.5. OSCORE Parameters . . . . . . . . . . . . . . . . . . . . 17 68 3.6. Key Update . . . . . . . . . . . . . . . . . . . . . . . 19 69 4. Authentication with signatures, X.509 identified by 'x5t' . . 20 70 4.1. message_1 . . . . . . . . . . . . . . . . . . . . . . . . 20 71 4.2. message_2 . . . . . . . . . . . . . . . . . . . . . . . . 21 72 4.3. message_3 . . . . . . . . . . . . . . . . . . . . . . . . 27 73 4.4. message_4 . . . . . . . . . . . . . . . . . . . . . . . . 34 74 4.5. OSCORE Parameters . . . . . . . . . . . . . . . . . . . . 36 75 4.6. Key Update . . . . . . . . . . . . . . . . . . . . . . . 38 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 78 7. Informative References . . . . . . . . . . . . . . . . . . . 38 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 82 1. Introduction 84 EDHOC [I-D.ietf-lake-edhoc] is a lightweight authenticated key 85 exchange protocol designed for highly constrained settings. This 86 document contains annotated traces of EDHOC protocol runs, with 87 input, output and intermediate processing results to simplify testing 88 of implementations. 90 The traces in this draft are valid for versions -11 and -12 of 91 [I-D.ietf-lake-edhoc]. A more extensive test vector suite and 92 related code that was used to generate them can be found at: 93 https://github.com/lake-wg/edhoc/tree/master/test-vectors-11. 95 2. Setup 97 EDHOC is run between an Initiator (I) and a Responder (R). The 98 private/public key pairs and credentials of I and R required to 99 produce the protocol messages are shown in the traces when needed for 100 the calculations. 102 Both I and R are assumed to support cipher suite 0, which determines 103 the algorithms: 105 * EDHOC AEAD algorithm = AES-CCM-16-64-128 107 * EDHOC hash algorithm = SHA-256 109 * EDHOC MAC length in bytes (Static DH) = 8 111 * EDHOC key exchange algorithm (ECDH curve) = X25519 113 * EDHOC signature algorithm = EdDSA 115 * Application AEAD algorithm = AES-CCM-16-64-128 117 * Application hash algorithm = SHA-256 119 External authorization data (EAD) is not used in these examples. 121 EDHOC messages and intermediate results are encoded in CBOR [RFC8949] 122 and can therefore be displayed in CBOR diagnostic notation using, 123 e.g., the CBOR playground [CborMe], which makes them easy to parse 124 for humans. 126 NOTE 1. The same name is used for hexadecimal byte strings and their 127 CBOR encodings. The traces contain both the raw byte strings and the 128 corresponding CBOR encoded data items. 130 NOTE 2. If not clear from the context, remember that CBOR sequences 131 and CBOR arrays assume CBOR encoded data items as elements. 133 NOTE 3. When the protocol transporting EDHOC messages does not 134 inherently provide correlation across all messages, like CoAP, then 135 some messages typically are prepended with connection identifiers and 136 potentially a message_1 indicator (see Section 3.4.1 and Appendix A.3 137 of [I-D.ietf-lake-edhoc]). Those bytes are not included in the 138 traces in this document. 140 3. Authentication with static DH, CCS identified by 'kid' 142 In this example I and R are authenticated with ephemeral-static 143 Diffie-Hellman (METHOD = 3). The public keys are represented as raw 144 public keys (RPK), encoded in an CWT Claims Set (CCS) and identified 145 by the COSE header parameter 'kid'. 147 3.1. message_1 149 Both endpoints are authenticated with static DH, i.e. METHOD = 3: 151 METHOD (CBOR Data Item) (1 bytes) 152 03 154 I selects cipher suite 0. A single cipher suite is encoded as an 155 int: 157 SUITES_I (CBOR Data Item) (1 bytes) 158 00 160 I creates an ephemeral key pair for use with the EDHOC key exchange 161 algorithm: 163 X (Raw Value) (Initiator's ephemeral private key) (32 bytes) 164 b3 11 19 98 cb 3f 66 86 63 ed 42 51 c7 8b e6 e9 5a 4d a1 27 e4 f6 fe 165 e2 75 e8 55 d8 d9 df d8 ed 167 G_X (Raw Value) (Initiator's ephemeral public key) (32 bytes) 168 3a a9 eb 32 01 b3 36 7b 8c 8b e3 8d 91 e5 7a 2b 43 3e 67 88 8c 86 d2 169 ac 00 6a 52 08 42 ed 50 37 171 G_X (CBOR Data Item) (Initiator's ephemeral public key) (34 bytes) 172 58 20 3a a9 eb 32 01 b3 36 7b 8c 8b e3 8d 91 e5 7a 2b 43 3e 67 88 8c 173 86 d2 ac 00 6a 52 08 42 ed 50 37 175 I selects its connection identifier C_I to be the int 12: 177 C_I (Raw Value) (Connection identifier chosen by I) (int) 178 12 180 C_I (CBOR Data Item) (Connection identifier chosen by I) (1 bytes) 181 0c 183 No external authorization data: 185 EAD_1 (CBOR Sequence) (0 bytes) 187 I constructs message_1: 189 message_1 = 190 ( 191 3, 192 0, 193 h'3AA9EB3201B3367B8C8BE38D91E57A2B433E67888C86D2AC006A520842ED5037', 194 12 195 ) 197 message_1 (CBOR Sequence) (37 bytes) 198 03 00 58 20 3a a9 eb 32 01 b3 36 7b 8c 8b e3 8d 91 e5 7a 2b 43 3e 67 199 88 8c 86 d2 ac 00 6a 52 08 42 ed 50 37 0c 201 3.2. message_2 203 R creates an ephemeral key pair for use with the EDHOC key exchange 204 algorithm: 206 Y (Raw Value) (Responder's ephemeral private key) (32 bytes) 207 bd 86 ea f4 06 5a 83 6c d2 9d 0f 06 91 ca 2a 8e c1 3f 51 d1 c4 5e 1b 208 43 72 c0 cb e4 93 ce f6 bd 210 G_Y (Raw Value) (Responder's ephemeral public key) (32 bytes) 211 25 54 91 b0 5a 39 89 ff 2d 3f fe a6 20 98 aa b5 7c 16 0f 29 4e d9 48 212 01 8b 41 90 f7 d1 61 82 4e 214 G_Y (CBOR Data Item) (Responder's ephemeral public key) (34 bytes) 215 58 20 25 54 91 b0 5a 39 89 ff 2d 3f fe a6 20 98 aa b5 7c 16 0f 29 4e 216 d9 48 01 8b 41 90 f7 d1 61 82 4e 218 PRK_2e is specified in Section 4.1.1 of [I-D.ietf-lake-edhoc]. 220 First, the ECDH shared secret G_XY is computed from G_X and Y, or G_Y 221 and X: 223 G_XY (Raw Value) (ECDH shared secret) (32 bytes) 224 6d 26 60 ec 2b 30 15 d9 3f e6 5d ae a5 12 74 bd 5b 1e bb ad 9b 62 4e 225 67 0e 79 a6 55 e3 0e c3 4d 227 Then, PRK_2e is calculated using Extract() determined by the EDHOC 228 hash algorithm: 230 PRK_2e = Extract(salt, G_XY) = 231 = HMAC-SHA-256(salt, G_XY) 233 where salt is the zero-length byte string: 235 salt (Raw Value) (0 bytes) 236 PRK_2e (Raw Value) (32 bytes) 237 d1 d0 11 a5 9a 6d 10 57 5e b2 20 c7 65 2e 6f 98 c4 17 a5 65 e4 e4 5c 238 f5 b5 01 06 95 04 3b 0e b7 240 Since METHOD = 3, R authenticates using static DH. 242 R's static key pair for use with the EDHOC key exchange algorithm is 243 based on the same curve as for the ephemeral keys, X25519: 245 R (Raw Value) (Responder's private authentication key) (32 bytes) 246 52 8b 49 c6 70 f8 fc 16 a2 ad 95 c1 88 5b 2e 24 fb 15 76 22 72 79 2a 247 a1 cf 05 1d f5 d9 3d 36 94 249 G_R (Raw Value) (Responder's public authentication key) (32 bytes) 250 e6 6f 35 59 90 22 3c 3f 6c af f8 62 e4 07 ed d1 17 4d 07 01 a0 9e cd 251 6a 15 ce e2 c6 ce 21 aa 50 253 PRK_3e2m is specified in Section 4.1.2 of [I-D.ietf-lake-edhoc]. 255 Since R authenticates with static DH (METHOD = 3), PRK_3e2m is 256 derived from G_RX using Extract() with the EDHOC hash algorithm: 258 PRK_3e2m = Extract(PRK_2e, G_RX) = 259 = HMAC-SHA-256(PRK_2e, G_RX) 261 where G_RX is the ECDH shared secret calculated from G_X and R, or 262 G_R and X. 264 G_RX (Raw Value) (ECDH shared secret) (32 bytes) 265 b5 8b 40 34 26 c0 3d b0 7b aa 93 44 d5 51 e6 7b 21 78 bf 05 ec 6f 52 266 c3 6a 2f a5 be 23 2d d4 78 268 PRK_3e2m (Raw Value) (32 bytes) 269 76 8e 13 75 27 2e 1e 68 b4 2c a3 24 84 80 d5 bb a8 8b cb 55 f6 60 ce 270 7f 94 1e 67 09 10 31 17 a1 272 R selects its connection identifier C_R to be the empty byte string 273 "": 275 C_R (raw value) (Connection identifier chosen by R) (0 bytes) 277 C_R (CBOR Data Item) (Connection identifier chosen by R) (1 bytes) 278 40 280 The transcript hash TH_2 is calculated using the EDHOC hash 281 algorithm: 283 TH_2 = H(H(message_1), G_Y, C_R) 284 H(message_1) (Raw Value) (32 bytes) 285 9b dd b0 cd 55 48 7f 82 a8 6f b7 2a 8b b3 58 52 68 91 a0 a6 c9 08 61 286 24 12 f5 af 29 9d af 01 96 288 H(message_1) (CBOR Data Item) (34 bytes) 289 58 20 9b dd b0 cd 55 48 7f 82 a8 6f b7 2a 8b b3 58 52 68 91 a0 a6 c9 290 08 61 24 12 f5 af 29 9d af 01 96 292 The input to calculate TH_2 is the CBOR sequence: 294 H(message_1), G_Y, C_R 296 Input to calculate TH_2 (CBOR Sequence) (69 bytes) 297 58 20 9b dd b0 cd 55 48 7f 82 a8 6f b7 2a 8b b3 58 52 68 91 a0 a6 c9 298 08 61 24 12 f5 af 29 9d af 01 96 58 20 25 54 91 b0 5a 39 89 ff 2d 3f 299 fe a6 20 98 aa b5 7c 16 0f 29 4e d9 48 01 8b 41 90 f7 d1 61 82 4e 40 301 TH_2 (Raw Value) (32 bytes) 302 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 71 1b 303 9a 91 1c 71 fc 09 6a ee 0e 305 TH_2 (CBOR Data Item) (34 bytes) 306 58 20 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 307 71 1b 9a 91 1c 71 fc 09 6a ee 0e 309 R constructs the remaining input needed to calculate MAC_2: 311 MAC_2 = EDHOC-KDF(PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R, CRED_R, ? 312 EAD_2 >>, mac_length_2) 314 CRED_R is identified by a 'kid' with integer value 5: 316 ID_CRED_R = 317 { 318 4 : 5 319 } 321 ID_CRED_R (CBOR Data Item) (3 bytes) 322 a1 04 05 324 CRED_R is an RPK encoded as a CCS: 326 { /CCS/ 327 2 : "example.edu", /sub/ 328 8 : { /cnf/ 329 1 : { /COSE_Key/ 330 1 : 1, /kty/ 331 2 : 5, /kid/ 332 -1 : 4, /crv/ 333 -2 : h'E66F355990223C3F6CAFF862E407EDD1 /x/ 334 174D0701A09ECD6A15CEE2C6CE21AA50' 335 } 336 } 337 } 339 CRED_R (CBOR Data Item) (59 bytes) 340 a2 02 6b 65 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a4 01 01 02 05 20 341 04 21 58 20 e6 6f 35 59 90 22 3c 3f 6c af f8 62 e4 07 ed d1 17 4d 07 342 01 a0 9e cd 6a 15 ce e2 c6 ce 21 aa 50 344 No external authorization data: 346 EAD_2 (CBOR Sequence) (0 bytes) 348 MAC_2 is computed through Expand() using the EDHOC hash algorithm, 349 see Section 4.2 of [I-D.ietf-lake-edhoc]: 351 MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2) 353 Since METHOD = 3, mac_length_2 is given by the EDHOC MAC length. 355 info for MAC_2 is: 357 info = 358 ( 359 h'71A6C7C5BA9AD47FE72DA4DC359BF6B276D3515968711B9A911C71FC096AEE0E', 360 "MAC_2", 361 h'A10405A2026B6578616D706C652E65647508A101A4010102052004215820E6 362 6F355990223C3F6CAFF862E407EDD1174D0701A09ECD6A15CEE2C6CE21AA50', 363 8 364 ) 366 where the last value is the EDHOC MAC length. 368 info for MAC_2 (CBOR Sequence) (105 bytes) 369 58 20 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 370 71 1b 9a 91 1c 71 fc 09 6a ee 0e 65 4d 41 43 5f 32 58 3e a1 04 05 a2 371 02 6b 65 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a4 01 01 02 05 20 04 372 21 58 20 e6 6f 35 59 90 22 3c 3f 6c af f8 62 e4 07 ed d1 17 4d 07 01 373 a0 9e cd 6a 15 ce e2 c6 ce 21 aa 50 08 374 MAC_2 (Raw Value) (8 bytes) 375 8e 27 cb d4 94 f7 52 83 377 MAC_2 (CBOR Data Item) (9 bytes) 378 48 8e 27 cb d4 94 f7 52 83 380 Since METHOD = 3, Signature_or_MAC_2 is MAC_2: 382 Signature_or_MAC_2 (Raw Value) (8 bytes) 383 8e 27 cb d4 94 f7 52 83 385 Signature_or_MAC_2 (CBOR Data Item) (9 bytes) 386 48 8e 27 cb d4 94 f7 52 83 388 R constructs the plaintext: 390 PLAINTEXT_2 = 391 ( 392 ID_CRED_R / bstr / int, 393 Signature_or_MAC_2, 394 ? EAD_2 395 ) 397 Since ID_CRED_R contains a single 'kid' parameter, only the int 5 is 398 included in the plaintext. 400 PLAINTEXT_2 (CBOR Sequence) (10 bytes) 401 05 48 8e 27 cb d4 94 f7 52 83 403 The input needed to calculate KEYSTREAM_2 is defined in Section 4.2 404 of [I-D.ietf-lake-edhoc], using Expand() with the EDHOC hash 405 algorithm: 407 KEYSTREAM_2 = EDHOC-KDF(PRK_2e, TH_2, "KEYSTREAM_2", h'', length) = 408 = HKDF-Expand(PRK_2e, info, length), 410 where length is the length of PLAINTEXT_2, and info for KEYSTREAM_2 411 is: 413 info = 414 ( 415 h'71A6C7C5BA9AD47FE72DA4DC359BF6B276D3515968711B9A911C71FC096AEE0E', 416 "KEYSTREAM_2", 417 h'', 418 10 419 ) 421 where last value is the length of PLAINTEXT_2. 423 info for KEYSTREAM_2 (CBOR Sequence) (48 bytes) 424 58 20 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 425 71 1b 9a 91 1c 71 fc 09 6a ee 0e 6b 4b 45 59 53 54 52 45 41 4d 5f 32 426 40 0a 428 KEYSTREAM_2 (Raw Value) (10 bytes) 429 0a b8 c2 0e 84 9e 52 f5 9d fb 431 R calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and KEYSTREAM_2: 433 CIPHERTEXT_2 (Raw Value) (10 bytes) 434 0f f0 4c 29 4f 4a c6 02 cf 78 436 R constructs message_2: 438 message_2 = 439 ( 440 G_Y_CIPHERTEXT_2, 441 C_R 442 ) 444 where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of 445 the raw values of G_Y and CIPHERTEXT_2. 447 message_2 (CBOR Sequence) (45 bytes) 448 58 2a 25 54 91 b0 5a 39 89 ff 2d 3f fe a6 20 98 aa b5 7c 16 0f 29 4e 449 d9 48 01 8b 41 90 f7 d1 61 82 4e 0f f0 4c 29 4f 4a c6 02 cf 78 40 451 3.3. message_3 453 Since METHOD = 3, I authenticates using static DH. 455 I's static key pair for use with the EDHOC key exchange algorithm is 456 based on the same curve as for the ephemeral keys, X25519: 458 I (Raw Value) (Initiator's private authentication key) (32 bytes) 459 cf c4 b6 ed 22 e7 00 a3 0d 5c 5b cd 61 f1 f0 20 49 de 23 54 62 33 48 460 93 d6 ff 9f 0c fe a3 fe 04 462 G_I (Raw Value) (Initiator's public authentication key) (32 bytes) 463 4a 49 d8 8c d5 d8 41 fa b7 ef 98 3e 91 1d 25 78 86 1f 95 88 4f 9f 5d 464 c4 2a 2e ed 33 de 79 ed 77 466 PRK_4x3m is derived as specified in Section 4.1.3 of 467 [I-D.ietf-lake-edhoc]. Since I authenticates with static DH (METHOD 468 = 3), PRK_4x3m is derived from G_IY using Extract() with the EDHOC 469 hash algorithm: 471 PRK_4x3m = Extract(PRK_3e2m, G_IY) = 472 = HMAC-SHA-256(PRK_3e2m, G_IY) 474 where G_IY is the ECDH shared secret calculated from G_I and Y, or 475 G_Y and I. 477 G_IY (Raw Value) (ECDH shared secret) (32 bytes) 478 0a f4 2a d5 12 dc 3e 97 2b 3a c4 d4 7b a3 3f fc 21 f1 ae 6f 07 f2 f8 479 94 85 4a 5a 47 44 33 85 48 481 PRK_4x3m (Raw Value) (32 bytes) 482 b8 cc df 14 20 b5 b0 c8 2a 58 7e 7d 26 dd 7b 70 48 57 4c 3a 48 df 9f 483 6a 45 f7 21 c0 cf a4 b2 7c 485 The transcript hash TH_3 is calculated using the EDHOC hash 486 algorithm: 488 TH_3 = H(TH_2, CIPHERTEXT_2) 490 Input to calculate TH_3 (CBOR Sequence) (45 bytes) 491 58 20 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 492 71 1b 9a 91 1c 71 fc 09 6a ee 0e 4a 0f f0 4c 29 4f 4a c6 02 cf 78 494 TH_3 (Raw Value) (32 bytes) 495 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 5a c2 496 62 9b 2b be f7 fb 24 a3 70 498 TH_3 (CBOR Data Item) (34 bytes) 499 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 500 5a c2 62 9b 2b be f7 fb 24 a3 70 502 I constructs the remaining input needed to calculate MAC_3: 504 MAC_3 = EDHOC-KDF(PRK_4x3m, TH_3, "MAC_3", 505 << ID_CRED_I, CRED_I, ? EAD_3 >>, mac_length_3) 507 CRED_I is identified by a 'kid' with integer value -10: 509 ID_CRED_I = 510 { 511 4 : -10 512 } 514 ID_CRED_I (CBOR Data Item) (3 bytes) a1 04 29 516 CRED_I is an RPK encoded as a CCS: 518 { /CCS/ 519 2 : "42-50-31-FF-EF-37-32-39", /sub/ 520 8 : { /cnf/ 521 1 : { /COSE_Key/ 522 1 : 1, /kty/ 523 2 : -10, /kid/ 524 -1 : 4, /crv/ 525 -2 : h'4A49D88CD5D841FAB7EF983E911D2578 /x/ 526 861F95884F9F5DC42A2EED33DE79ED77' 527 } 528 } 529 } 531 CRED_I (CBOR Data Item) (71 bytes) 532 a2 02 77 34 32 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 533 2d 33 39 08 a1 01 a4 01 01 02 29 20 04 21 58 20 4a 49 d8 8c d5 d8 41 534 fa b7 ef 98 3e 91 1d 25 78 86 1f 95 88 4f 9f 5d c4 2a 2e ed 33 de 79 535 ed 77 537 No external authorization data: 539 EAD_3 (CBOR Sequence) (0 bytes) 541 MAC_3 is computed through Expand() using the EDHOC hash algorithm, 542 see Section 4.2 of [I-D.ietf-lake-edhoc]: 544 MAC_3 = HKDF-Expand(PRK_4x3m, info, mac_length_3) 546 Since METHOD = 3, mac_length_3 is given by the EDHOC MAC length. 548 info for MAC_3 is: 550 info = 551 ( 552 h'A49007CE54762E467C4E4A44692F2070D3E9EB00F95AC2629B2BBEF7FB24A370', 553 "MAC_3", 554 h'A10429A2027734322D35302D33312D46462D45462D33372D33322D333908A101 555 A40101022920042158204A49D88CD5D841FAB7EF983E911D2578861F95884F9F 556 5DC42A2EED33DE79ED77', 557 8 558 ) 560 where the last value is the EDHOC MAC length. 562 info for MAC_3 (CBOR Sequence) (117 bytes) 563 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 564 5a c2 62 9b 2b be f7 fb 24 a3 70 65 4d 41 43 5f 33 58 4a a1 04 29 a2 565 02 77 34 32 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 566 33 39 08 a1 01 a4 01 01 02 29 20 04 21 58 20 4a 49 d8 8c d5 d8 41 fa 567 b7 ef 98 3e 91 1d 25 78 86 1f 95 88 4f 9f 5d c4 2a 2e ed 33 de 79 ed 568 77 08 570 MAC_3 (Raw Value) (8 bytes) 571 db 0b 8f 75 27 09 53 da 573 MAC_3 (CBOR Data Item) (9 bytes) 574 48 db 0b 8f 75 27 09 53 da 576 Since METHOD = 3, Signature_or_MAC_3 is MAC_3: 578 Signature_or_MAC_3 (Raw Value) (8 bytes) 579 db 0b 8f 75 27 09 53 da 581 Signature_or_MAC_3 (CBOR Data Item) (9 bytes) 582 48 db 0b 8f 75 27 09 53 da 584 I constructs the plaintext P_3: 586 P_3 = 587 ( 588 ID_CRED_I / bstr / int, 589 Signature_or_MAC_3, 590 ? EAD_3 591 ) 593 Since ID_CRED_I contains a single 'kid' parameter, only the int -10 594 is included in the plaintext. 596 P_3 (CBOR Sequence) (10 bytes) 597 29 48 db 0b 8f 75 27 09 53 da 599 I constructs the associated data for message_3: 601 A_3 = 602 ( 603 "Encrypt0", 604 h'', 605 TH_3 606 ) 607 A_3 (CBOR Data Item) (45 bytes) 608 83 68 45 6e 63 72 79 70 74 30 40 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 609 4a 44 69 2f 20 70 d3 e9 eb 00 f9 5a c2 62 9b 2b be f7 fb 24 a3 70 611 I constructs the input needed to derive the key K_3, see Section 4.2 612 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 614 K_3 = EDHOC-KDF(PRK_3e2m, TH_3, "K_3", h'', length) = 615 = HKDF-Expand(PRK_3e2m, info, length), 617 where length is the key length of EDHOC AEAD algorithm, and info for 618 K_3 is: 620 info = 621 ( 622 h'A49007CE54762E467C4E4A44692F2070D3E9EB00F95AC2629B2BBEF7FB24A370', 623 "K_3", 624 h'', 625 16 626 ) 628 where the last value is the key length of EDHOC AEAD algorithm. 630 info for K_3 (CBOR Sequence) (40 bytes) 631 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 632 5a c2 62 9b 2b be f7 fb 24 a3 70 63 4b 5f 33 40 10 634 K_3 (Raw Value) (16 bytes) 635 2a 30 e4 f6 bc 55 8d 0e 7a 8c 63 ee 7b b5 45 7f 637 I constructs the input needed to derive the nonce IV_3, see 638 Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 640 IV_3 = EDHOC-KDF(PRK_3e2m, TH_3, "IV_3", h'', length) = 641 = HKDF-Expand(PRK_3e2m, info, length), 643 where length is the nonce length of EDHOC AEAD algorithm, and info 644 for IV_3 is: 646 info = 647 ( 648 h'A49007CE54762E467C4E4A44692F2070D3E9EB00F95AC2629B2BBEF7FB24A370', 649 "IV_3", 650 h'', 651 13 652 ) 654 where the last value is the nonce length of EDHOC AEAD algorithm. 656 info for IV_3 (CBOR Sequence) (41 bytes) 657 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 658 5a c2 62 9b 2b be f7 fb 24 a3 70 64 49 56 5f 33 40 0d 660 IV_3 (Raw Value) (13 bytes) 661 b3 8f b6 31 e3 44 a8 10 52 56 32 ed f8 663 I calculates CIPHERTEXT_3 as 'ciphertext' of COSE_Encrypt0 applied 664 using the EDHOC AEAD algorithm with plaintext P_3, additional data 665 A_3, key K_3 and nonce IV_3. 667 CIPHERTEXT_3 (Raw Value) (18 bytes) 668 be 01 46 c1 36 ac 2e ff d4 53 a7 5e fa 90 89 6f 65 3b 670 message_3 is the CBOR bstr encoding of CIPHERTEXT_3: 672 message_3 (CBOR Sequence) (19 bytes) 673 52 be 01 46 c1 36 ac 2e ff d4 53 a7 5e fa 90 89 6f 65 3b 675 The transcript hash TH_4 is calculated using the EDHOC hash 676 algorithm: 678 TH_4 = H(TH_3, CIPHERTEXT_3) 680 Input to calculate TH_4 (CBOR Sequence) (53 bytes) 681 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 682 5a c2 62 9b 2b be f7 fb 24 a3 70 52 be 01 46 c1 36 ac 2e ff d4 53 a7 683 5e fa 90 89 6f 65 3b 685 TH_4 (Raw Value) (32 bytes) 686 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 f8 d0 687 00 ad ce 88 b6 30 d8 84 eb 689 TH_4 (CBOR Data Item) (34 bytes) 690 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 691 f8 d0 00 ad ce 88 b6 30 d8 84 eb 693 3.4. message_4 695 No external authorization data: 697 EAD_4 (CBOR Sequence) (0 bytes) 699 R constructs the plaintext P_4: 701 P_4 = 702 ( 703 ? EAD_4 704 ) 706 P_4 (CBOR Sequence) (0 bytes) 708 R constructs the associated data for message_4: 710 A_4 = 711 ( 712 "Encrypt0", 713 h'', 714 TH_4 715 ) 717 A_4 (CBOR Data Item) (45 bytes) 718 83 68 45 6e 63 72 79 70 74 30 40 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 719 79 68 78 4f 55 40 dd 64 a3 bb 07 f8 d0 00 ad ce 88 b6 30 d8 84 eb 721 R constructs the input needed to derive the EDHOC message_4 key, see 722 Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 724 K_4 = EDHOC-Exporter("EDHOC_K_4", h'', length) 725 = EDHOC-KDF(PRK_4x3m, TH_4, "EDHOC_K_4", h'', length) 726 = HKDF-Expand(PRK_4x3m, info, length) 728 where length is the key length of the EDHOC AEAD algorithm, and info 729 for EDHOC_K_4 is: 731 info = 732 ( 733 h'4B9ADD2A9EEB8849716C7968784F5540DD64A3BB07F8D000ADCE88B630D884EB', 734 "EDHOC_K_4", 735 h'', 736 16 737 ) 739 where the last value is the key length of EDHOC AEAD algorithm. 741 info for K_4 (CBOR Sequence) (46 bytes) 742 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 743 f8 d0 00 ad ce 88 b6 30 d8 84 eb 69 45 44 48 4f 43 5f 4b 5f 34 40 10 745 K_4 (Raw Value) (16 bytes) 746 55 b5 7d 59 a8 26 f4 56 38 86 9b 75 07 0b 11 17 747 R constructs the input needed to derive the EDHOC message_4 nonce, 748 see Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash 749 algorithm: 751 IV_4 = 752 = EDHOC-Exporter( "EDHOC_IV_4", h'', length ) 753 = EDHOC-KDF(PRK_4x3m, TH_4, "EDHOC_IV_4", h'', length) 754 = HKDF-Expand(PRK_4x3m, info, length) 756 where length is the nonce length of EDHOC AEAD algorithm, and info 757 for EDHOC_IV_4 is: 759 info = 760 ( 761 h'4B9ADD2A9EEB8849716C7968784F5540DD64A3BB07F8D000ADCE88B630D884EB', 762 "EDHOC_IV_4", 763 h'', 764 13 765 ) 767 where the last value is the nonce length of EDHOC AEAD algorithm. 769 info for IV_4 (CBOR Sequence) (47 bytes) 770 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 771 f8 d0 00 ad ce 88 b6 30 d8 84 eb 6a 45 44 48 4f 43 5f 49 56 5f 34 40 772 0d 774 IV_4 (Raw Value) (13 bytes) 775 20 7a 4e fc 25 a6 58 96 45 11 f1 63 76 777 R calculates CIPHERTEXT_4 as 'ciphertext' of COSE_Encrypt0 applied 778 using the EDHOC AEAD algorithm with plaintext P_4, additional data 779 A_4, key K_4 and nonce IV_4. 781 CIPHERTEXT_4 (8 bytes) 782 e9 e6 c8 b6 37 6d b0 b1 784 message_4 is the CBOR bstr encoding of CIPHERTEXT_4: 786 message_4 (CBOR Sequence) (9 bytes) 787 48 e9 e6 c8 b6 37 6d b0 b1 789 3.5. OSCORE Parameters 791 The derivation of OSCORE parameters is specified in Appendix A.2 of 792 [I-D.ietf-lake-edhoc]. 794 The AEAD and Hash algorithms to use in OSCORE are given by the 795 selected cipher suite: 797 Application AEAD Algorithm (int) 798 10 800 Application Hash Algorithm (int) 801 -16 803 The mapping from EDHOC connection identifiers to OSCORE Sender/ 804 Recipient IDs is defined in Section A.1of [I-D.ietf-lake-edhoc]. 806 C_R is mapped to the Recipient ID of the server, i.e., the Sender ID 807 of the client. Since C_R is byte valued it the OSCORE Sender/ 808 Recipient ID equals the byte string (in this case the empty byte 809 string). 811 Client's OSCORE Sender ID (Raw Value) (0 bytes) 813 C_I is mapped to the Recipient ID of the client, i.e., the Sender ID 814 of the server. Since C_I is a numeric, it is converted to a byte 815 string equal to its CBOR encoded form. 817 Server's OSCORE Sender ID (Raw Value) (1 bytes) 818 0c 820 The OSCORE Master Secret is computed through Expand() using the 821 Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]: 823 OSCORE Master Secret = 824 = EDHOC-Exporter("OSCORE_Master_Secret", h'', key_length) 825 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE_Master_Secret", h'', key_length) 826 = HKDF-Expand(PRK_4x3m, info, key_length) 828 where key_length is by default the key length of the Application AEAD 829 algorithm, and info for the OSCORE Master Secret is: 831 info = 832 ( 833 h'4B9ADD2A9EEB8849716C7968784F5540DD64A3BB07F8D000ADCE88B630D884EB', 834 "OSCORE_Master_Secret", 835 h'', 836 16 837 ) 839 where the last value is the key length of Application AEAD algorithm. 841 info for OSCORE Master Secret (CBOR Sequence) (57 bytes) 842 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 843 f8 d0 00 ad ce 88 b6 30 d8 84 eb 74 4f 53 43 4f 52 45 5f 4d 61 73 74 844 65 72 5f 53 65 63 72 65 74 40 10 846 OSCORE Master Secret (Raw Value) (16 bytes) 847 c0 53 01 37 6c e9 5f 67 c4 14 d8 bb 5f 0f db 5e 849 The OSCORE Master Salt is computed through Expand() using the 850 Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]: 852 OSCORE Master Salt = 853 = EDHOC-Exporter("OSCORE_Master_Salt", h'', salt_length) 854 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE_Master_Salt", h'', salt_length) 855 = HKDF-Expand(PRK_4x3m, info, salt_length) 857 where salt_length is the length of the OSCORE Master Salt, and info 858 for the OSCORE Master Salt is: 860 info = 861 ( 862 h'4B9ADD2A9EEB8849716C7968784F5540DD64A3BB07F8D000ADCE88B630D884EB', 863 "OSCORE_Master_Salt", 864 h'', 865 8 866 ) 868 where the last value is the length of the OSCORE Master Salt. 870 info for OSCORE Master Salt (CBOR Sequence) (55 bytes) 871 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 872 f8 d0 00 ad ce 88 b6 30 d8 84 eb 72 4f 53 43 4f 52 45 5f 4d 61 73 74 873 65 72 5f 53 61 6c 74 40 08 875 OSCORE Master Salt (Raw Value) (8 bytes) 876 74 01 b4 6f a8 2f 66 31 878 3.6. Key Update 880 Key update is defined in Section 4.4 of [I-D.ietf-lake-edhoc]: 882 EDHOC-KeyUpdate(nonce): 883 PRK_4x3m = Extract(nonce, PRK_4x3m) 885 KeyUpdate Nonce (Raw Value) (16 bytes) 886 d4 91 a2 04 ca a6 b8 02 54 c4 71 e0 de ee d1 60 887 PRK_4x3m after KeyUpdate (Raw Value) (32 bytes) 888 82 09 6e 3a e6 3d 93 c7 b6 f8 8b 7c 1b 5e 63 f4 9f 74 c8 0e f3 14 42 889 51 9f fb 20 e2 f8 87 3e b1 891 The OSCORE Master Secret is derived with the updated PRK_4x3m: 893 OSCORE Master Secret = HKDF-Expand(PRK_4x3m, info, key_length) 895 where info and key_length are unchanged. 897 OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes) 898 a5 15 23 1d 9e c5 88 74 82 22 6b f9 e0 da 05 ce 900 The OSCORE Master Salt is derived with the updated PRK_4x3m: 902 OSCORE Master Salt = HKDF-Expand(PRK_4x3m, info, salt_length) 904 where info and salt_length are unchanged. 906 OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes) 907 50 57 e5 92 ed 8b 11 28 909 4. Authentication with signatures, X.509 identified by 'x5t' 911 In this example the Initiator (I) and Responder (R) are authenticated 912 with digital signatures (METHOD = 0). The public keys are 913 represented with dummy X.509 certificates identified by the COSE 914 header parameter 'x5t'. 916 4.1. message_1 918 Both endpoints are authenticated with signatures, i.e. METHOD = 0: 920 METHOD (CBOR Data Item) (1 bytes) 921 00 923 I selects cipher suite 0. A single cipher suite is encoded as an 924 int: 926 SUITES_I (CBOR Data Item) (1 bytes) 927 00 929 I creates an ephemeral key pair for use with the EDHOC key exchange 930 algorithm: 932 X (Raw Value) (Initiator's ephemeral private key) (32 bytes) 933 b0 26 b1 68 42 9b 21 3d 6b 42 1d f6 ab d0 64 1c d6 6d ca 2e e7 fd 59 934 77 10 4b b2 38 18 2e 5e a6 935 G_X (Raw Value) (Initiator's ephemeral public key) (32 bytes) 936 e3 1e c1 5e e8 03 94 27 df c4 72 7e f1 7e 2e 0e 69 c5 44 37 f3 c5 82 937 80 19 ef 0a 63 88 c1 25 52 939 G_X (CBOR Data Item) (Initiator's ephemeral public key) (34 bytes) 940 58 20 e3 1e c1 5e e8 03 94 27 df c4 72 7e f1 7e 2e 0e 69 c5 44 37 f3 941 c5 82 80 19 ef 0a 63 88 c1 25 52 943 I selects its connection identifier C_I to be the int 14: 945 C_I (Raw Value) (Connection identifier chosen by I) (int) 946 14 948 C_I (CBOR Data Item) (Connection identifier chosen by I) (1 bytes) 949 0e 951 No external authorization data: 953 EAD_1 (CBOR Sequence) (0 bytes) 955 I constructs message_1: 957 message_1 = 958 ( 959 0, 960 0, 961 h'E31EC15EE8039427DFC4727EF17E2E0E69C54437F3C5828019EF0A6388C12552', 962 14 963 ) 965 message_1 (CBOR Sequence) (37 bytes) 966 00 00 58 20 e3 1e c1 5e e8 03 94 27 df c4 72 7e f1 7e 2e 0e 69 c5 44 967 37 f3 c5 82 80 19 ef 0a 63 88 c1 25 52 0e 969 4.2. message_2 971 R creates an ephemeral key pair for use with the EDHOC key exchange 972 algorithm: 974 Y (Raw Value) (Responder's ephemeral private key) (32 bytes) 975 db 06 84 a8 12 54 66 41 3e 59 8d c2 67 73 7f 5f ef 0c 5a a2 29 fa a1 976 55 43 9f 60 08 5f d2 53 6d 978 G_Y (Raw Value) (Responder's ephemeral public key) (32 bytes) 979 e1 73 90 96 c5 c9 58 2c 12 98 91 81 66 d6 95 48 c7 8f 74 97 b2 58 c0 980 85 6a a2 01 98 93 a3 94 25 981 G_Y (CBOR Data Item) (Responder's ephemeral public key) (34 bytes) 982 58 20 e1 73 90 96 c5 c9 58 2c 12 98 91 81 66 d6 95 48 c7 8f 74 97 b2 983 58 c0 85 6a a2 01 98 93 a3 94 25 985 PRK_2e is specified in Section 4.1.1 of [I-D.ietf-lake-edhoc]. 987 First, the ECDH shared secret G_XY is computed from G_X and Y, or G_Y 988 and X: 990 G_XY (Raw Value) (ECDH shared secret) (32 bytes) 991 0b eb 98 d8 8f 49 67 7c 17 47 88 f8 87 bd cc d2 28 a1 88 39 2c cd 10 992 12 bd 31 70 d7 c8 85 65 66 994 Then, PRK_2e is calculated using Extract() determined by the EDHOC 995 hash algorithm: 997 PRK_2e = Extract(salt, G_XY) = 998 = HMAC-SHA-256(salt, G_XY) 1000 where salt is the zero-length byte string: 1002 salt (Raw Value) (0 bytes) 1004 PRK_2e (Raw Value) (32 bytes) 1005 4e 57 dc e2 58 75 77 c4 34 69 7c 03 93 5c c6 a2 82 16 5a 88 76 05 11 1006 fc 70 a8 c0 02 20 a5 ba 1a 1008 Since METHOD = 0, R authenticates using signatures with the EDHOC 1009 signature algorithm. R's signature key pair using Ed25519 is (note 1010 that Ed448 would also be compatible with EdDSA): 1012 SK_R (Raw Value) (Responders's private authentication key) (32 bytes) 1013 bc 4d 4f 98 82 61 22 33 b4 02 db 75 e6 c4 cf 30 32 a7 0a 0d 2e 3e e6 1014 d0 1b 11 dd de 5f 41 9c fc 1016 PK_R (Raw Value) (Responders's public authentication key) (32 bytes) 1017 27 ee f2 b0 8a 6f 49 6f ae da a6 c7 f9 ec 6a e3 b9 d5 24 24 58 0d 52 1018 e4 9d a6 93 5e df 53 cd c5 1020 PRK_3e2m is specified in Section 4.1.2 of [I-D.ietf-lake-edhoc]. 1022 Since R authenticates with signatures PRK_3e2m = PRK_2e. 1024 PRK_3e2m (Raw Value) (32 bytes) 1025 4e 57 dc e2 58 75 77 c4 34 69 7c 03 93 5c c6 a2 82 16 5a 88 76 05 11 1026 fc 70 a8 c0 02 20 a5 ba 1a 1028 R selects its connection identifier C_R to be the int -19 1029 C_R (Raw Value) (Connection identifier chosen by R) (int) 1030 -19 1032 C_R (CBOR Data Item) (Connection identifier chosen by R) (1 bytes) 1033 32 1035 The transcript hash TH_2 is calculated using the EDHOC hash 1036 algorithm: 1038 TH_2 = H(H(message_1), G_Y, C_R) 1040 H(message_1) (Raw Value) (32 bytes) 1041 ce ba 8d 4d a2 80 b1 61 c8 5a 19 47 81 a9 31 88 35 41 50 b4 9c 4f 93 1042 2e 4a a0 8f f3 ed 11 04 65 1044 H(message_1) (CBOR Data Item) (34 bytes) 1045 58 20 ce ba 8d 4d a2 80 b1 61 c8 5a 19 47 81 a9 31 88 35 41 50 b4 9c 1046 4f 93 2e 4a a0 8f f3 ed 11 04 65 1048 The input to calculate TH_2 is the CBOR sequence: 1050 H(message_1), G_Y, C_R 1052 Input to calculate TH_2 (CBOR Sequence) (69 bytes) 1053 58 20 ce ba 8d 4d a2 80 b1 61 c8 5a 19 47 81 a9 31 88 35 41 50 b4 9c 1054 4f 93 2e 4a a0 8f f3 ed 11 04 65 58 20 e1 73 90 96 c5 c9 58 2c 12 98 1055 91 81 66 d6 95 48 c7 8f 74 97 b2 58 c0 85 6a a2 01 98 93 a3 94 25 32 1057 TH_2 (Raw Value) (32 bytes) 1058 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 44 3e 1059 91 83 3d 68 cd dd 7f 9b 39 1061 TH_2 (CBOR Data Item) (34 bytes) 1062 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 1063 44 3e 91 83 3d 68 cd dd 7f 9b 39 1065 R constructs the remaining input needed to calculate MAC_2: 1067 MAC_2 = EDHOC-KDF(PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R, CRED_R, ? 1068 EAD_2 >>, mac_length_2) 1070 CRED_R is identified by a 64-bit hash: 1072 ID_CRED_R = 1073 { 1074 34 : [-15, h'60780E9451BDC43C'] 1075 } 1076 where the COSE header value 34 ('x5t') indicates a hash of an X.509 1077 certficate, and the COSE algorithm -15 indicates the hash algorithm 1078 SHA-256 truncated to 64 bits. 1080 ID_CRED_R (CBOR Data Item) (14 bytes) a1 18 22 82 2e 48 60 78 0e 94 1081 51 bd c4 3c 1083 CRED_R is a byte string acting as a dummy X.509 certificate: 1085 CRED_R (CBOR Data Item) (113 bytes) 1086 58 6f 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 1087 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 1088 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 1089 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 1090 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 1092 No external authorization data: 1094 EAD_2 (CBOR Sequence) (0 bytes) 1096 MAC_2 is computed through Expand() using the EDHOC hash algorithm, 1097 Section 4.2 of [I-D.ietf-lake-edhoc]: 1099 MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2) 1101 Since METHOD = 0, mac_length_2 is given by the EDHOC hash algorithm. 1103 info for MAC_2 is: 1105 info = 1106 ( 1107 h'0782DBB687C30288A30B706B074BED789574573F24443E91833D68CDDD7F9B39', 1108 "MAC_2", 1109 h'A11822822E4860780E9451BDC43C586F000102030405060708090A0B0C0D0E0F10 1110 1112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F3031 1111 32333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152 1112 535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E', 1113 32 1114 ) 1116 where the last value is the output size of the EDHOC hash algorithm. 1118 info for MAC_2 (CBOR Sequence) (171 bytes) 1119 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 1120 44 3e 91 83 3d 68 cd dd 7f 9b 39 65 4d 41 43 5f 32 58 7f a1 18 22 82 1121 2e 48 60 78 0e 94 51 bd c4 3c 58 6f 00 01 02 03 04 05 06 07 08 09 0a 1122 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 1123 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 1124 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 1125 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 1126 67 68 69 6a 6b 6c 6d 6e 18 20 1128 MAC_2 (Raw Value) (32 bytes) 1129 27 c8 f1 e4 a7 af f2 a0 f0 bc 0f 91 83 93 ee f1 8b 69 0c 4d 4c 3d 81 1130 bd fe 22 95 42 40 bc c4 cc 1132 MAC_2 (CBOR Data Item) (34 bytes) 1133 58 20 27 c8 f1 e4 a7 af f2 a0 f0 bc 0f 91 83 93 ee f1 8b 69 0c 4d 4c 1134 3d 81 bd fe 22 95 42 40 bc c4 cc 1136 Since METHOD = 0, Signature_or_MAC_2 is the 'signature' of the 1137 COSE_Sign1 object. 1139 R constructs the message to be signed: 1141 [ "Signature1", << ID_CRED_R >>, 1142 << TH_2, CRED_R, ? EAD_2 >>, MAC_2 ] = 1144 [ 1145 "Signature1", 1146 h'A11822822E4860780E9451BDC43C', 1147 h'58200782DBB687C30288A30B706B074BED789574573F24443E91833D68CDDD7F 1148 9B39586F000102030405060708090A0B0C0D0E0F101112131415161718191A1B 1149 1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B 1150 3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B 1151 5C5D5E5F606162636465666768696A6B6C6D6E', 1152 h'27C8F1E4A7AFF2A0F0BC0F918393EEF18B690C4D4C3D81BDFE22954240BCC4CC' 1153 ] 1155 Message to be signed 2 (CBOR Data Item) (210 bytes) 1156 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 60 78 0e 94 1157 51 bd c4 3c 58 93 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 1158 78 95 74 57 3f 24 44 3e 91 83 3d 68 cd dd 7f 9b 39 58 6f 00 01 02 03 1159 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1160 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 1161 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 1162 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 1163 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 58 20 27 c8 f1 e4 a7 af 1164 f2 a0 f0 bc 0f 91 83 93 ee f1 8b 69 0c 4d 4c 3d 81 bd fe 22 95 42 40 1165 bc c4 cc 1166 R signs using the private authentication key SK_R 1168 Signature_or_MAC_2 (Raw Value) (64 bytes) 1169 3c e5 20 75 db 55 89 2d f1 25 8f a6 9e 86 ab 5b 59 33 ea dc 07 ea 82 1170 41 1f 17 9a 5f de f1 c9 43 23 63 f6 58 f9 a2 04 fa 81 54 d1 4f fd 87 1171 b5 01 0c 4f d0 a0 c7 7e 2a ca 77 5f 67 cb 5e 8b be 08 1173 Signature_or_MAC_2 (CBOR Data Item) (66 bytes) 1174 58 40 3c e5 20 75 db 55 89 2d f1 25 8f a6 9e 86 ab 5b 59 33 ea dc 07 1175 ea 82 41 1f 17 9a 5f de f1 c9 43 23 63 f6 58 f9 a2 04 fa 81 54 d1 4f 1176 fd 87 b5 01 0c 4f d0 a0 c7 7e 2a ca 77 5f 67 cb 5e 8b be 08 1178 R constructs the plaintext: 1180 PLAINTEXT_2 = 1181 ( 1182 ID_CRED_R / bstr / int, 1183 Signature_or_MAC_2, 1184 ? EAD_2 1185 ) 1187 PLAINTEXT_2 (CBOR Sequence) (80 bytes) 1188 a1 18 22 82 2e 48 60 78 0e 94 51 bd c4 3c 58 40 3c e5 20 75 db 55 89 1189 2d f1 25 8f a6 9e 86 ab 5b 59 33 ea dc 07 ea 82 41 1f 17 9a 5f de f1 1190 c9 43 23 63 f6 58 f9 a2 04 fa 81 54 d1 4f fd 87 b5 01 0c 4f d0 a0 c7 1191 7e 2a ca 77 5f 67 cb 5e 8b be 08 1193 The input needed to calculate KEYSTREAM_2 is defined in Section 4.2 1194 of [I-D.ietf-lake-edhoc], using Expand() with the EDHOC hash 1195 algorithm: 1197 KEYSTREAM_2 = EDHOC-KDF(PRK_2e, TH_2, "KEYSTREAM_2", h'', length) = 1198 = HKDF-Expand(PRK_2e, info, length) 1200 where length is the length of PLAINTEXT_2, and info for KEYSTREAM_2 1201 is: 1203 info = 1204 ( 1205 h'0782DBB687C30288A30B706B074BED789574573F24443E91833D68CDDD7F9B39', 1206 "KEYSTREAM_2", 1207 h'', 1208 80 1209 ) 1211 where the last value is the length of PLAINTEXT_2. 1213 info for KEYSTREAM_2 (CBOR Sequence) (49 bytes) 1214 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 1215 44 3e 91 83 3d 68 cd dd 7f 9b 39 6b 4b 45 59 53 54 52 45 41 4d 5f 32 1216 40 18 50 1218 KEYSTREAM_2 (Raw Value) (80 bytes) 1219 c8 13 ff 19 3b c0 31 40 47 99 6a 37 03 09 ba ed 45 f7 f5 f8 d5 6c 1c 1220 df 44 6b 01 c5 77 8d 68 9f 7f 13 da 50 17 ba 0f 4e 5f df 6e d0 59 55 1221 cd 8c e4 ec 43 7a 22 fa 8e e8 72 8c 36 2b cb 7b 93 a9 11 e1 67 95 04 1222 31 c1 d5 05 0b da 69 e9 5b aa fb 1224 R calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and KEYSTREAM_2: 1226 CIPHERTEXT_2 (Raw Value) (80 bytes) 1227 69 0b dd 9b 15 88 51 38 49 0d 3b 8a c7 35 e2 ad 79 12 d5 8d 0e 39 95 1228 f2 b5 4e 8e 63 e9 0b c3 c4 26 20 30 8c 10 50 8d 0f 40 c8 f4 8f 87 a4 1229 04 cf c7 8f b5 22 db 58 8a 12 f3 d8 e7 64 36 fc 26 a8 1d ae b7 35 c3 1230 4f eb 1f 72 54 bd a2 b7 d0 14 f3 1232 R constructs message_2: 1234 message_2 = 1235 ( 1236 G_Y_CIPHERTEXT_2, 1237 C_R 1238 ) 1240 where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of 1241 the raw values of G_Y and CIPHERTEXT_2. 1243 message_2 (CBOR Sequence) (115 bytes) 1244 58 70 e1 73 90 96 c5 c9 58 2c 12 98 91 81 66 d6 95 48 c7 8f 74 97 b2 1245 58 c0 85 6a a2 01 98 93 a3 94 25 69 0b dd 9b 15 88 51 38 49 0d 3b 8a 1246 c7 35 e2 ad 79 12 d5 8d 0e 39 95 f2 b5 4e 8e 63 e9 0b c3 c4 26 20 30 1247 8c 10 50 8d 0f 40 c8 f4 8f 87 a4 04 cf c7 8f b5 22 db 58 8a 12 f3 d8 1248 e7 64 36 fc 26 a8 1d ae b7 35 c3 4f eb 1f 72 54 bd a2 b7 d0 14 f3 32 1250 4.3. message_3 1252 Since METHOD = 0, I authenticates using signatures with the EDHOC 1253 signature algorithm. I's signature key pair using Ed25519 is (note 1254 that Ed448 would also be compatible with EdDSA): 1256 SK_I (Raw Value) (Initiator's private authentication key) (32 bytes) 1257 36 6a 58 59 a4 cd 65 cf ae af 05 66 c9 fc 7e 1a 93 30 6f de c1 77 63 1258 e0 58 13 a7 0f 21 ff 59 db 1259 PK_I (Raw Value) (Responders's public authentication key) (32 bytes) 1260 ec 2c 2e b6 cd d9 57 82 a8 cd 0b 2e 9c 44 27 07 74 dc bd 31 bf be 23 1261 13 ce 80 13 2e 8a 26 1c 04 1263 PRK_4x3m is specified in Section 4.1.3 of [I-D.ietf-lake-edhoc]. 1265 Since R authenticates with signatures PRK_4x3m = PRK_3e2m. 1267 PRK_4x3m (Raw Value) (32 bytes) 1268 4e 57 dc e2 58 75 77 c4 34 69 7c 03 93 5c c6 a2 82 16 5a 88 76 05 11 1269 fc 70 a8 c0 02 20 a5 ba 1a 1271 The transcript hash TH_3 is calculated using the EDHOC hash 1272 algorithm: 1274 TH_3 = H(TH_2, CIPHERTEXT_2) 1276 Input to calculate TH_3 (CBOR Sequence) (116 bytes) 1277 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 1278 44 3e 91 83 3d 68 cd dd 7f 9b 39 58 50 69 0b dd 9b 15 88 51 38 49 0d 1279 3b 8a c7 35 e2 ad 79 12 d5 8d 0e 39 95 f2 b5 4e 8e 63 e9 0b c3 c4 26 1280 20 30 8c 10 50 8d 0f 40 c8 f4 8f 87 a4 04 cf c7 8f b5 22 db 58 8a 12 1281 f3 d8 e7 64 36 fc 26 a8 1d ae b7 35 c3 4f eb 1f 72 54 bd a2 b7 d0 14 1282 f3 1284 TH_3 (Raw Value) (32 bytes) 1285 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 37 98 1286 b0 81 a9 bd 12 a3 31 7a 82 1288 TH_3 (CBOR Data Item) (34 bytes) 1289 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1290 37 98 b0 81 a9 bd 12 a3 31 7a 82 1292 I constructs the remaining input needed to calculate MAC_3: 1294 MAC_3 = EDHOC-KDF(PRK_4x3m, TH_3, "MAC_3", 1295 << ID_CRED_I, CRED_I, ? EAD_3 >>, mac_length_3) 1297 CRED_I is identified by a 64-bit hash: 1299 ID_CRED_I = 1300 { 1301 34 : [-15, h'81D45BE06329D63A'] 1302 } 1304 where the COSE header value 34 ('x5t') indicates a hash of an X.509 1305 certficate, and the COSE algorithm -15 indicates the hash algorithm 1306 SHA-256 truncated to 64 bits. 1308 ID_CRED_I (CBOR Data Item) (14 bytes) 1309 a1 18 22 82 2e 48 81 d4 5b e0 63 29 d6 3a 1311 CRED_I is a byte string acting as a dummy X.509 certificate: 1313 CRED_I (CBOR Data Item) (139 bytes) 1314 58 89 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 1315 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 1316 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 1317 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 1318 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 1319 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 1320 88 1322 No external authorization data: 1324 EAD_3 (CBOR Sequence) (0 bytes) 1326 MAC_3 is computed through Expand() using the EDHOC hash algorithm, 1327 see Section 4.2 of [I-D.ietf-lake-edhoc]: 1329 MAC_3 = HKDF-Expand(PRK_4x3m, info, mac_length_3) 1331 Since METHOD = 0, mac_length_3 is given by the EDHOC hash algorithm. 1333 info for MAC_3 is: 1335 info = 1336 ( 1337 h'23CE4296FC64AB048A593B6711E4822011BB58D85D3798B081A9BD12A3317A82', 1338 "MAC_3", 1339 h'A11822822E4881D45BE06329D63A5889000102030405060708090A0B0C0D0E0F 1340 101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F 1341 303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F 1342 505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F 1343 707172737475767778797A7B7C7D7E7F808182838485868788', 1344 32 1345 ) 1347 where the last value is the output size of the EDHOC hash algorithm. 1349 info for MAC_3 (CBOR Sequence) (197 bytes) 1350 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1351 37 98 b0 81 a9 bd 12 a3 31 7a 82 65 4d 41 43 5f 33 58 99 a1 18 22 82 1352 2e 48 81 d4 5b e0 63 29 d6 3a 58 89 00 01 02 03 04 05 06 07 08 09 0a 1353 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 1354 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 1355 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 1356 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 1357 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 1358 7e 7f 80 81 82 83 84 85 86 87 88 18 20 1360 MAC_3 (Raw Value) (32 bytes) 1361 fc 86 e7 d4 f1 8b 34 8c 29 7c 2f a3 eb 19 52 9a cc 3e 0a 4c b1 ba 99 1362 b6 9d 16 aa b1 9d 33 3c 12 1364 MAC_3 (CBOR Data Item) (34 bytes) 1365 58 20 fc 86 e7 d4 f1 8b 34 8c 29 7c 2f a3 eb 19 52 9a cc 3e 0a 4c b1 1366 ba 99 b6 9d 16 aa b1 9d 33 3c 12 1368 Since METHOD = 0, Signature_or_MAC_3 is the 'signature' of the 1369 COSE_Sign1 object. 1371 I constructs the message to be signed: 1373 [ "Signature1", << ID_CRED_I >>, 1374 << TH_3, CRED_I, ? EAD_3 >>, MAC_3 ] = 1376 [ 1377 "Signature1", 1378 h'A11822822E4881D45BE06329D63A', 1379 h'58205AA25B46397C2F145EB792ED0D17EA2B078C73E4EE148780C3C2E7341372 1380 CBAD5889000102030405060708090A0B0C0D0E0F101112131415161718191A1B 1381 1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B 1382 3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B 1383 5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B 1384 7C7D7E7F808182838485868788', 1385 h'FC86E7D4F18B348C297C2FA3EB19529ACC3E0A4CB1BA99B69D16AAB19D333C12' 1386 ] 1387 Message to be signed 3 (CBOR Data Item) (236 bytes) 1388 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 81 d4 5b e0 1389 63 29 d6 3a 58 ad 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 1390 20 11 bb 58 d8 5d 37 98 b0 81 a9 bd 12 a3 31 7a 82 58 89 00 01 02 03 1391 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1392 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 1393 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 1394 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 1395 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 1396 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 58 20 fc 86 e7 1397 d4 f1 8b 34 8c 29 7c 2f a3 eb 19 52 9a cc 3e 0a 4c b1 ba 99 b6 9d 16 1398 aa b1 9d 33 3c 12 1400 R signs using the private authentication key SK_R: 1402 Signature_or_MAC_3 (Raw Value) (64 bytes) 1403 3d d3 74 07 a1 d9 f1 2a 5b a6 4d f0 5f a0 d9 46 25 bf 74 0c 29 5f e1 1404 88 58 d6 8e 04 5c 84 90 27 54 88 03 56 3e de 8c 5b 39 11 4f 13 fe 29 1405 78 8a 83 b7 42 28 8e ab 8a 94 52 2c b1 d3 03 f2 62 04 1407 Signature_or_MAC_3 (CBOR Data Item) (66 bytes) 1408 58 40 3d d3 74 07 a1 d9 f1 2a 5b a6 4d f0 5f a0 d9 46 25 bf 74 0c 29 1409 5f e1 88 58 d6 8e 04 5c 84 90 27 54 88 03 56 3e de 8c 5b 39 11 4f 13 1410 fe 29 78 8a 83 b7 42 28 8e ab 8a 94 52 2c b1 d3 03 f2 62 04 1412 R constructs the plaintext: 1414 P_3 = 1415 ( 1416 ID_CRED_I / bstr / int, 1417 Signature_or_MAC_3, 1418 ? EAD_3 1419 ) 1421 P_3 (CBOR Sequence) (80 bytes) 1422 a1 18 22 82 2e 48 81 d4 5b e0 63 29 d6 3a 58 40 3d d3 74 07 a1 d9 f1 1423 2a 5b a6 4d f0 5f a0 d9 46 25 bf 74 0c 29 5f e1 88 58 d6 8e 04 5c 84 1424 90 27 54 88 03 56 3e de 8c 5b 39 11 4f 13 fe 29 78 8a 83 b7 42 28 8e 1425 ab 8a 94 52 2c b1 d3 03 f2 62 04 1427 I constructs the associated data for message_3: 1429 A_3 = 1430 ( 1431 "Encrypt0", 1432 h'', 1433 TH_3 1434 ) 1435 A_3 (CBOR Data Item) (45 bytes) 1436 83 68 45 6e 63 72 79 70 74 30 40 58 20 23 ce 42 96 fc 64 ab 04 8a 59 1437 3b 67 11 e4 82 20 11 bb 58 d8 5d 37 98 b0 81 a9 bd 12 a3 31 7a 82 1439 I constructs the input needed to derive the key K_3, see Section 4.2 1440 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 1442 K_3 = EDHOC-KDF(PRK_3e2m, TH_3, "K_3", h'', length) = 1443 = HKDF-Expand(PRK_3e2m, info, length), 1445 where length is the key length of EDHOC AEAD algorithm, and info for 1446 K_3 is: 1448 info = 1449 ( 1450 h'23CE4296FC64AB048A593B6711E4822011BB58D85D3798B081A9BD12A3317A82', 1451 "K_3", 1452 h'', 1453 16 1454 ) 1456 where the last value is the key length of EDHOC AEAD algorithm. 1458 info for K_3 (CBOR Sequence) (40 bytes) 1459 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1460 37 98 b0 81 a9 bd 12 a3 31 7a 82 63 4b 5f 33 40 10 1462 K_3 (Raw Value) (16 bytes) 1463 7a 40 e4 b6 75 9c 72 7e 8a ef f1 08 9e e7 69 af 1465 I constructs the input needed to derive the nonce IV_3, see 1466 Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 1468 IV_3 = EDHOC-KDF(PRK_3e2m, TH_3, "IV_3", h'', length) = 1469 = HKDF-Expand(PRK_3e2m, info, length), 1471 where length is the nonce length of EDHOC AEAD algorithm, and info 1472 for IV_3 is: 1474 info = 1475 ( 1476 h'23CE4296FC64AB048A593B6711E4822011BB58D85D3798B081A9BD12A3317A82', 1477 "IV_3", 1478 h'', 1479 13 1480 ) 1482 where the last value is the nonce length of EDHOC AEAD algorithm. 1484 info for IV_3 (CBOR Sequence) (41 bytes) 1485 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1486 37 98 b0 81 a9 bd 12 a3 31 7a 82 64 49 56 5f 33 40 0d 1488 IV_3 (Raw Value) (13 bytes) 1489 d3 98 90 65 7e ef 37 8f 36 52 0c b3 44 1491 I calculates CIPHERTEXT_3 as 'ciphertext' of COSE_Encrypt0 applied 1492 using the EDHOC AEAD algorithm with plaintext P_3, additional data 1493 A_3, key K_3 and nonce IV_3. 1495 CIPHERTEXT_3 (Raw Value) (88 bytes) 1496 4c 53 ed 22 c4 5f b0 0c ad 88 9b 4c 06 f2 a2 6c f4 91 54 cb 8b df 4e 1497 ee 44 e2 b5 02 21 ab 1f 02 9d 3d 3e 05 23 dd f9 d7 61 0c 37 6c 72 8a 1498 1e 90 16 92 f1 da 07 82 a3 47 2f f6 eb 1b b6 81 0c 6f 68 68 79 c9 a5 1499 59 4f 8f 17 0c a5 a2 b5 bf 05 a7 4f 42 cd d9 c8 54 e0 1e 1501 message_3 is the CBOR bstr encoding of CIPHERTEXT_3: 1503 message_3 (CBOR Sequence) (90 bytes) 1504 58 58 4c 53 ed 22 c4 5f b0 0c ad 88 9b 4c 06 f2 a2 6c f4 91 54 cb 8b 1505 df 4e ee 44 e2 b5 02 21 ab 1f 02 9d 3d 3e 05 23 dd f9 d7 61 0c 37 6c 1506 72 8a 1e 90 16 92 f1 da 07 82 a3 47 2f f6 eb 1b b6 81 0c 6f 68 68 79 1507 c9 a5 59 4f 8f 17 0c a5 a2 b5 bf 05 a7 4f 42 cd d9 c8 54 e0 1e 1509 The transcript hash TH_4 is calculated using the EDHOC hash 1510 algorithm: 1512 TH_4 = H(TH_3, CIPHERTEXT_3) 1514 Input to calculate TH_4 (CBOR Sequence) (124 bytes) 1515 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1516 37 98 b0 81 a9 bd 12 a3 31 7a 82 58 58 4c 53 ed 22 c4 5f b0 0c ad 88 1517 9b 4c 06 f2 a2 6c f4 91 54 cb 8b df 4e ee 44 e2 b5 02 21 ab 1f 02 9d 1518 3d 3e 05 23 dd f9 d7 61 0c 37 6c 72 8a 1e 90 16 92 f1 da 07 82 a3 47 1519 2f f6 eb 1b b6 81 0c 6f 68 68 79 c9 a5 59 4f 8f 17 0c a5 a2 b5 bf 05 1520 a7 4f 42 cd d9 c8 54 e0 1e 1522 TH_4 (Raw Value) (32 bytes) 1523 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 b2 0a 1524 8b 67 07 6d cc 92 aa d4 0b 1526 TH_4 (CBOR Data Item) (34 bytes) 1527 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1528 b2 0a 8b 67 07 6d cc 92 aa d4 0b 1530 4.4. message_4 1532 No external authorization data: 1534 EAD_4 (CBOR Sequence) (0 bytes) 1536 R constructs the plaintext P_4: 1538 P_4 = 1539 ( 1540 ? EAD_4 1541 ) 1543 P_4 (CBOR Sequence) (0 bytes) 1545 R constructs the associated data for message_4: 1547 A_4 = 1548 ( 1549 "Encrypt0", 1550 h'', 1551 TH_4 1552 ) 1554 A_4 (CBOR Data Item) (45 bytes) 1555 83 68 45 6e 63 72 79 70 74 30 40 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 1556 66 f7 c9 23 e6 6c 36 02 e2 56 57 b2 0a 8b 67 07 6d cc 92 aa d4 0b 1558 R constructs the input needed to derive the EDHOC message_4 key, see 1559 Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 1561 K_4 = EDHOC-Exporter("EDHOC_K_4", h'', length) 1562 = EDHOC-KDF(PRK_4x3m, TH_4, "EDHOC_K_4", h'', length) 1563 = HKDF-Expand(PRK_4x3m, info, length) 1565 where length is the key length of the EDHOC AEAD algorithm, and info 1566 for EDHOC_K_4 is: 1568 info = 1569 ( 1570 h'63FF46ADB9EB2F89ACED66F7C923E66C3602E25657B20A8B67076DCC92AAD40B', 1571 "EDHOC_K_4", 1572 h'', 1573 16 1574 ) 1576 where the last value is the key length of EDHOC AEAD algorithm. 1578 info for K_4 (CBOR Sequence) (46 bytes) 1579 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1580 b2 0a 8b 67 07 6d cc 92 aa d4 0b 69 45 44 48 4f 43 5f 4b 5f 34 40 10 1582 K_4 (Raw Value) (16 bytes) 1583 ee 55 a5 46 1b 2c 41 82 1b 1a be dc 03 b4 ef 50 1585 R constructs the input needed to derive the EDHOC message_4 nonce, 1586 see Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash 1587 algorithm: 1589 IV_4 = 1590 = EDHOC-Exporter( "EDHOC_IV_4", h'', length ) 1591 = EDHOC-KDF(PRK_4x3m, TH_4, "EDHOC_IV_4", h'', length) 1592 = HKDF-Expand(PRK_4x3m, info, length) 1594 where length is the nonce length of EDHOC AEAD algorithm, and info 1595 for EDHOC_IV_4 is: 1597 info = 1598 ( 1599 h'63FF46ADB9EB2F89ACED66F7C923E66C3602E25657B20A8B67076DCC92AAD40B', 1600 "EDHOC_IV_4", 1601 h'', 1602 13 1603 ) 1605 where the last value is the nonce length of EDHOC AEAD algorithm. 1607 info for IV_4 (CBOR Sequence) (47 bytes) 1608 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1609 b2 0a 8b 67 07 6d cc 92 aa d4 0b 6a 45 44 48 4f 43 5f 49 56 5f 34 40 1610 0d 1612 IV_4 (Raw Value) (13 bytes) 1613 cb 14 8d 0f 30 c5 ce 4a 6d 80 eb f3 6c 1615 R calculates CIPHERTEXT_4 as 'ciphertext' of COSE_Encrypt0 applied 1616 using the EDHOC AEAD algorithm with plaintext P_4, additional data 1617 A_4, key K_4 and nonce IV_4. 1619 CIPHERTEXT_4 (8 bytes) 1620 fc 4f 5e 2f 54 c2 d4 08 1622 message_4 is the CBOR bstr encoding of CIPHERTEXT_4: 1624 message_4 (CBOR Sequence) (9 bytes) 1625 48 fc 4f 5e 2f 54 c2 d4 08 1627 4.5. OSCORE Parameters 1629 The derivation of OSCORE parameters is specified in Appendix A.2 of 1630 [I-D.ietf-lake-edhoc]. 1632 The AEAD and Hash algorithms to use in OSCORE are given by the 1633 selected cipher suite: 1635 Application AEAD Algorithm (int) 1636 10 1638 Application Hash Algorithm (int) 1639 -16 1641 The mapping from EDHOC connection identifiers to OSCORE Sender/ 1642 Recipient IDs is defined in Appendix A.1 of [I-D.ietf-lake-edhoc]. 1644 C_R is mapped to the Recipient ID of the server, i.e., the Sender ID 1645 of the client. Since C_R is a numeric, it is converted to a byte 1646 string equal to its CBOR encoded form. 1648 Client's OSCORE Sender ID (Raw Value) (1 bytes) 1649 32 1651 C_I is mapped to the Recipient ID of the client, i.e., the Sender ID 1652 of the server. Since C_I is a numeric, it is converted to a byte 1653 string equal to its CBOR encoded form. 1655 Server's OSCORE Sender ID (Raw Value) (1 bytes) 1656 0e 1658 The OSCORE Master Secret is computed through Expand() using the 1659 Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]: 1661 OSCORE Master Secret = 1662 = EDHOC-Exporter("OSCORE_Master_Secret", h'', key_length) 1663 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE_Master_Secret", h'', key_length) 1664 = HKDF-Expand(PRK_4x3m, info, key_length) 1666 where key_length is by default the key length of the Application AEAD 1667 algorithm, and info for the OSCORE Master Secret is: 1669 info = 1670 ( 1671 h'63FF46ADB9EB2F89ACED66F7C923E66C3602E25657B20A8B67076DCC92AAD40B', 1672 "OSCORE_Master_Secret", 1673 h'', 1674 16 1675 ) 1677 where the last value is the key length of Application AEAD algorithm. 1679 info for OSCORE Master Secret (CBOR Sequence) (57 bytes) 1680 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1681 b2 0a 8b 67 07 6d cc 92 aa d4 0b 74 4f 53 43 4f 52 45 5f 4d 61 73 74 1682 65 72 5f 53 65 63 72 65 74 40 10 1684 OSCORE Master Secret (Raw Value) (16 bytes) 1685 01 4f df 73 06 7d fe fd 97 e6 b0 59 72 f9 0d 85 1687 The OSCORE Master Salt is computed through Expand() using the 1688 Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]: 1690 OSCORE Master Salt = 1691 = EDHOC-Exporter("OSCORE_Master_Salt", h'', salt_length) 1692 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE_Master_Salt", h'', salt_length) 1693 = HKDF-Expand(PRK_4x3m, info, salt_length) 1695 where salt_length is the length of the OSCORE Master Salt, and info 1696 for the OSCORE Master Salt is: 1698 info = 1699 ( 1700 h'63FF46ADB9EB2F89ACED66F7C923E66C3602E25657B20A8B67076DCC92AAD40B', 1701 "OSCORE_Master_Salt", 1702 h'', 1703 8 1704 ) 1706 where the last value is the length of the OSCORE Master Salt. 1708 info for OSCORE Master Salt (CBOR Sequence) (55 bytes) 1709 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1710 b2 0a 8b 67 07 6d cc 92 aa d4 0b 72 4f 53 43 4f 52 45 5f 4d 61 73 74 1711 65 72 5f 53 61 6c 74 40 08 1713 OSCORE Master Salt (Raw Value) (8 bytes) 1714 cb 47 b6 ec d3 86 72 dd 1716 4.6. Key Update 1718 Key update is defined in Section 4.4 of [I-D.ietf-lake-edhoc]. 1720 EDHOC-KeyUpdate(nonce): 1721 PRK_4x3m = Extract(nonce, PRK_4x3m) 1723 KeyUpdate Nonce (Raw Value) (16 bytes) 1724 e6 f5 49 b8 58 1a a2 92 53 cf ce 68 07 53 a4 00 1726 PRK_4x3m after KeyUpdate (Raw Value) (32 bytes) 1727 26 78 00 73 f8 ce 0b eb 71 03 e0 c7 17 d1 6d db bb f6 7b b1 f0 77 53 1728 ca 97 df ec 34 73 23 47 4d 1730 The OSCORE Master Secret is derived with the updated PRK_4x3m: 1732 OSCORE Master Secret = HKDF-Expand(PRK_4x3m, info, key_length) 1734 where info and key_length are unchanged. 1736 OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes) 1737 8f 7c 42 12 d7 e4 2a 1c 5f bb 5d c6 2f d7 b7 f3 1739 The OSCORE Master Salt is derived with the updated PRK_4x3m: 1741 OSCORE Master Salt = HKDF-Expand(PRK_4x3m, info, salt_length) 1743 where info and salt_length are unchanged. 1745 OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes) 1746 87 eb 7d b2 fd cf a8 9c 1748 5. Security Considerations 1750 This document contains examples of EDHOC [I-D.ietf-lake-edhoc] whose 1751 security considerations apply. The keys printed in these examples 1752 cannot be considered secret and must not be used. 1754 6. IANA Considerations 1756 There are no IANA considerations. 1758 7. Informative References 1760 [CborMe] Bormann, C., "CBOR Playground", May 2018, 1761 . 1763 [I-D.ietf-lake-edhoc] 1764 Selander, G., Mattsson, J. P., and F. Palombini, 1765 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 1766 Progress, Internet-Draft, draft-ietf-lake-edhoc-11, 24 1767 September 2021, . 1770 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1771 Representation (CBOR)", STD 94, RFC 8949, 1772 DOI 10.17487/RFC8949, December 2020, 1773 . 1775 Acknowledgments 1777 Authors' Addresses 1779 Göran Selander 1780 Ericsson AB 1781 SE-164 80 Stockholm 1782 Sweden 1784 Email: goran.selander@ericsson.com 1786 John Preuß Mattsson 1787 Ericsson AB 1788 SE-164 80 Stockholm 1789 Sweden 1791 Email: john.mattsson@ericsson.com