idnits 2.17.1 draft-ietf-lake-traces-00.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 (25 November 2021) is 854 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-12 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: 29 May 2022 25 November 2021 7 Traces of EDHOC 8 draft-ietf-lake-traces-00 10 Abstract 12 This document contains some example traces of Ephemeral Diffie- 13 Hellman Over COSE (EDHOC). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 29 May 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Revised BSD License text as 43 described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Revised BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 3. Authentication with static DH, CCS identified by 'kid' . . . 3 51 3.1. message_1 . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.2. message_2 . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.3. message_3 . . . . . . . . . . . . . . . . . . . . . . . . 10 54 3.4. message_4 . . . . . . . . . . . . . . . . . . . . . . . . 15 55 3.5. OSCORE Parameters . . . . . . . . . . . . . . . . . . . . 17 56 3.6. Key Update . . . . . . . . . . . . . . . . . . . . . . . 19 57 4. Authentication with signatures, X.509 identified by 'x5t' . . 20 58 4.1. message_1 . . . . . . . . . . . . . . . . . . . . . . . . 20 59 4.2. message_2 . . . . . . . . . . . . . . . . . . . . . . . . 21 60 4.3. message_3 . . . . . . . . . . . . . . . . . . . . . . . . 27 61 4.4. message_4 . . . . . . . . . . . . . . . . . . . . . . . . 33 62 4.5. OSCORE Parameters . . . . . . . . . . . . . . . . . . . . 35 63 4.6. Key Update . . . . . . . . . . . . . . . . . . . . . . . 37 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 66 7. Informative References . . . . . . . . . . . . . . . . . . . 38 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 70 1. Introduction 72 EDHOC [I-D.ietf-lake-edhoc] is a lightweight authenticated key 73 exchange protocol designed for highly constrained settings. This 74 document contains annotated traces of EDHOC protocol runs, with 75 input, output and intermediate processing results to simplify testing 76 of implementations. 78 The traces in this draft are valid for versions -11 and -12 of 79 [I-D.ietf-lake-edhoc]. A more extensive test vector suite and 80 related code that was used to generate them can be found at: 81 https://github.com/lake-wg/edhoc/tree/master/test-vectors-11. 83 2. Setup 85 EDHOC is run between an Initiator (I) and a Responder (R). The 86 private/public key pairs and credentials of I and R required to 87 produce the protocol messages are shown in the traces when needed for 88 the calculations. 90 Both I and R are assumed to support cipher suite 0, which determines 91 the algorithms: 93 * EDHOC AEAD algorithm = AES-CCM-16-64-128 94 * EDHOC hash algorithm = SHA-256 96 * EDHOC MAC length in bytes (Static DH) = 8 98 * EDHOC key exchange algorithm (ECDH curve) = X25519 100 * EDHOC signature algorithm = EdDSA 102 * Application AEAD algorithm = AES-CCM-16-64-128 104 * Application hash algorithm = SHA-256 106 External authorization data (EAD) is not used in these examples. 108 EDHOC messages and intermediate results are encoded in CBOR [RFC8949] 109 and can therefore be displayed in CBOR diagnostic notation using, 110 e.g., the CBOR playground [CborMe], which makes them easy to parse 111 for humans. 113 NOTE 1. The same name is used for hexadecimal byte strings and their 114 CBOR encodings. The traces contain both the raw byte strings and the 115 corresponding CBOR encoded data items. 117 NOTE 2. If not clear from the context, remember that CBOR sequences 118 and CBOR arrays assume CBOR encoded data items as elements. 120 NOTE 3. When the protocol transporting EDHOC messages does not 121 inherently provide correlation across all messages, like CoAP, then 122 some messages typically are prepended with connection identifiers and 123 potentially a message_1 indicator (see Section 3.4.1 and Appendix A.3 124 of [I-D.ietf-lake-edhoc]). Those bytes are not included in the 125 traces in this document. 127 3. Authentication with static DH, CCS identified by 'kid' 129 In this example I and R are authenticated with ephemeral-static 130 Diffie-Hellman (METHOD = 3). The public keys are represented as raw 131 public keys (RPK), encoded in an CWT Claims Set (CCS) and identified 132 by the COSE header parameter 'kid'. 134 3.1. message_1 136 Both endpoints are authenticated with static DH, i.e. METHOD = 3: 138 METHOD (CBOR Data Item) (1 bytes) 139 03 140 I selects cipher suite 0. A single cipher suite is encoded as an 141 int: 143 SUITES_I (CBOR Data Item) (1 bytes) 144 00 146 I creates an ephemeral key pair for use with the EDHOC key exchange 147 algorithm: 149 X (Raw Value) (Initiator's ephemeral private key) (32 bytes) 150 b3 11 19 98 cb 3f 66 86 63 ed 42 51 c7 8b e6 e9 5a 4d a1 27 e4 f6 fe 151 e2 75 e8 55 d8 d9 df d8 ed 153 G_X (Raw Value) (Initiator's ephemeral public key) (32 bytes) 154 3a a9 eb 32 01 b3 36 7b 8c 8b e3 8d 91 e5 7a 2b 43 3e 67 88 8c 86 d2 155 ac 00 6a 52 08 42 ed 50 37 157 G_X (CBOR Data Item) (Initiator's ephemeral public key) (34 bytes) 158 58 20 3a a9 eb 32 01 b3 36 7b 8c 8b e3 8d 91 e5 7a 2b 43 3e 67 88 8c 159 86 d2 ac 00 6a 52 08 42 ed 50 37 161 I selects its connection identifier C_I to be the int 12: 163 C_I (Raw Value) (Connection identifier chosen by I) (int) 164 12 166 C_I (CBOR Data Item) (Connection identifier chosen by I) (1 bytes) 167 0c 169 No external authorization data: 171 EAD_1 (CBOR Sequence) (0 bytes) 173 I constructs message_1: 175 message_1 = 176 ( 177 3, 178 0, 179 h'3AA9EB3201B3367B8C8BE38D91E57A2B433E67888C86D2AC006A520842ED5037', 180 12 181 ) 183 message_1 (CBOR Sequence) (37 bytes) 184 03 00 58 20 3a a9 eb 32 01 b3 36 7b 8c 8b e3 8d 91 e5 7a 2b 43 3e 67 185 88 8c 86 d2 ac 00 6a 52 08 42 ed 50 37 0c 187 3.2. message_2 189 R creates an ephemeral key pair for use with the EDHOC key exchange 190 algorithm: 192 Y (Raw Value) (Responder's ephemeral private key) (32 bytes) 193 bd 86 ea f4 06 5a 83 6c d2 9d 0f 06 91 ca 2a 8e c1 3f 51 d1 c4 5e 1b 194 43 72 c0 cb e4 93 ce f6 bd 196 G_Y (Raw Value) (Responder's ephemeral public key) (32 bytes) 197 25 54 91 b0 5a 39 89 ff 2d 3f fe a6 20 98 aa b5 7c 16 0f 29 4e d9 48 198 01 8b 41 90 f7 d1 61 82 4e 200 G_Y (CBOR Data Item) (Responder's ephemeral public key) (34 bytes) 201 58 20 25 54 91 b0 5a 39 89 ff 2d 3f fe a6 20 98 aa b5 7c 16 0f 29 4e 202 d9 48 01 8b 41 90 f7 d1 61 82 4e 204 PRK_2e is specified in Section 4.1.1 of [I-D.ietf-lake-edhoc]. 206 First, the ECDH shared secret G_XY is computed from G_X and Y, or G_Y 207 and X: 209 G_XY (Raw Value) (ECDH shared secret) (32 bytes) 210 6d 26 60 ec 2b 30 15 d9 3f e6 5d ae a5 12 74 bd 5b 1e bb ad 9b 62 4e 211 67 0e 79 a6 55 e3 0e c3 4d 213 Then, PRK_2e is calculated using Extract() determined by the EDHOC 214 hash algorithm: 216 PRK_2e = Extract(salt, G_XY) = 217 = HMAC-SHA-256(salt, G_XY) 219 where salt is the zero-length byte string: 221 salt (Raw Value) (0 bytes) 223 PRK_2e (Raw Value) (32 bytes) 224 d1 d0 11 a5 9a 6d 10 57 5e b2 20 c7 65 2e 6f 98 c4 17 a5 65 e4 e4 5c 225 f5 b5 01 06 95 04 3b 0e b7 227 Since METHOD = 3, R authenticates using static DH. 229 R's static key pair for use with the EDHOC key exchange algorithm is 230 based on the same curve as for the ephemeral keys, X25519: 232 R (Raw Value) (Responder's private authentication key) (32 bytes) 233 52 8b 49 c6 70 f8 fc 16 a2 ad 95 c1 88 5b 2e 24 fb 15 76 22 72 79 2a 234 a1 cf 05 1d f5 d9 3d 36 94 235 G_R (Raw Value) (Responder's public authentication key) (32 bytes) 236 e6 6f 35 59 90 22 3c 3f 6c af f8 62 e4 07 ed d1 17 4d 07 01 a0 9e cd 237 6a 15 ce e2 c6 ce 21 aa 50 239 PRK_3e2m is specified in Section 4.1.2 of [I-D.ietf-lake-edhoc]. 241 Since R authenticates with static DH (METHOD = 3), PRK_3e2m is 242 derived from G_RX using Extract() with the EDHOC hash algorithm: 244 PRK_3e2m = Extract(PRK_2e, G_RX) = 245 = HMAC-SHA-256(PRK_2e, G_RX) 247 where G_RX is the ECDH shared secret calculated from G_X and R, or 248 G_R and X. 250 G_RX (Raw Value) (ECDH shared secret) (32 bytes) 251 b5 8b 40 34 26 c0 3d b0 7b aa 93 44 d5 51 e6 7b 21 78 bf 05 ec 6f 52 252 c3 6a 2f a5 be 23 2d d4 78 254 PRK_3e2m (Raw Value) (32 bytes) 255 76 8e 13 75 27 2e 1e 68 b4 2c a3 24 84 80 d5 bb a8 8b cb 55 f6 60 ce 256 7f 94 1e 67 09 10 31 17 a1 258 R selects its connection identifier C_R to be the empty byte string 259 "": 261 C_R (raw value) (Connection identifier chosen by R) (0 bytes) 263 C_R (CBOR Data Item) (Connection identifier chosen by R) (1 bytes) 264 40 266 The transcript hash TH_2 is calculated using the EDHOC hash 267 algorithm: 269 TH_2 = H(H(message_1), G_Y, C_R) 271 H(message_1) (Raw Value) (32 bytes) 272 9b dd b0 cd 55 48 7f 82 a8 6f b7 2a 8b b3 58 52 68 91 a0 a6 c9 08 61 273 24 12 f5 af 29 9d af 01 96 275 H(message_1) (CBOR Data Item) (34 bytes) 276 58 20 9b dd b0 cd 55 48 7f 82 a8 6f b7 2a 8b b3 58 52 68 91 a0 a6 c9 277 08 61 24 12 f5 af 29 9d af 01 96 279 The input to calculate TH_2 is the CBOR sequence: 281 H(message_1), G_Y, C_R 282 Input to calculate TH_2 (CBOR Sequence) (69 bytes) 283 58 20 9b dd b0 cd 55 48 7f 82 a8 6f b7 2a 8b b3 58 52 68 91 a0 a6 c9 284 08 61 24 12 f5 af 29 9d af 01 96 58 20 25 54 91 b0 5a 39 89 ff 2d 3f 285 fe a6 20 98 aa b5 7c 16 0f 29 4e d9 48 01 8b 41 90 f7 d1 61 82 4e 40 287 TH_2 (Raw Value) (32 bytes) 288 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 71 1b 289 9a 91 1c 71 fc 09 6a ee 0e 291 TH_2 (CBOR Data Item) (34 bytes) 292 58 20 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 293 71 1b 9a 91 1c 71 fc 09 6a ee 0e 295 R constructs the remaining input needed to calculate MAC_2: 297 MAC_2 = EDHOC-KDF(PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R, CRED_R, ? 298 EAD_2 >>, mac_length_2) 300 CRED_R is identified by a 'kid' with integer value 5: 302 ID_CRED_R = 303 { 304 4 : 5 305 } 307 ID_CRED_R (CBOR Data Item) (3 bytes) 308 a1 04 05 310 CRED_R is an RPK encoded as a CCS: 312 { /CCS/ 313 2 : "example.edu", /sub/ 314 8 : { /cnf/ 315 1 : { /COSE_Key/ 316 1 : 1, /kty/ 317 2 : 5, /kid/ 318 -1 : 4, /crv/ 319 -2 : h'E66F355990223C3F6CAFF862E407EDD1 /x/ 320 174D0701A09ECD6A15CEE2C6CE21AA50' 321 } 322 } 323 } 325 CRED_R (CBOR Data Item) (59 bytes) 326 a2 02 6b 65 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a4 01 01 02 05 20 327 04 21 58 20 e6 6f 35 59 90 22 3c 3f 6c af f8 62 e4 07 ed d1 17 4d 07 328 01 a0 9e cd 6a 15 ce e2 c6 ce 21 aa 50 329 No external authorization data: 331 EAD_2 (CBOR Sequence) (0 bytes) 333 MAC_2 is computed through Expand() using the EDHOC hash algorithm, 334 see Section 4.2 of [I-D.ietf-lake-edhoc]: 336 MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2) 338 Since METHOD = 3, mac_length_2 is given by the EDHOC MAC length. 340 info for MAC_2 is: 342 info = 343 ( 344 h'71A6C7C5BA9AD47FE72DA4DC359BF6B276D3515968711B9A911C71FC096AEE0E', 345 "MAC_2", 346 h'A10405A2026B6578616D706C652E65647508A101A4010102052004215820E6 347 6F355990223C3F6CAFF862E407EDD1174D0701A09ECD6A15CEE2C6CE21AA50', 348 8 349 ) 351 where the last value is the EDHOC MAC length. 353 info for MAC_2 (CBOR Sequence) (105 bytes) 354 58 20 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 355 71 1b 9a 91 1c 71 fc 09 6a ee 0e 65 4d 41 43 5f 32 58 3e a1 04 05 a2 356 02 6b 65 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a4 01 01 02 05 20 04 357 21 58 20 e6 6f 35 59 90 22 3c 3f 6c af f8 62 e4 07 ed d1 17 4d 07 01 358 a0 9e cd 6a 15 ce e2 c6 ce 21 aa 50 08 360 MAC_2 (Raw Value) (8 bytes) 361 8e 27 cb d4 94 f7 52 83 363 MAC_2 (CBOR Data Item) (9 bytes) 364 48 8e 27 cb d4 94 f7 52 83 366 Since METHOD = 3, Signature_or_MAC_2 is MAC_2: 368 Signature_or_MAC_2 (Raw Value) (8 bytes) 369 8e 27 cb d4 94 f7 52 83 371 Signature_or_MAC_2 (CBOR Data Item) (9 bytes) 372 48 8e 27 cb d4 94 f7 52 83 374 R constructs the plaintext: 376 PLAINTEXT_2 = 377 ( 378 ID_CRED_R / bstr / int, 379 Signature_or_MAC_2, 380 ? EAD_2 381 ) 383 Since ID_CRED_R contains a single 'kid' parameter, only the int 5 is 384 included in the plaintext. 386 PLAINTEXT_2 (CBOR Sequence) (10 bytes) 387 05 48 8e 27 cb d4 94 f7 52 83 389 The input needed to calculate KEYSTREAM_2 is defined in Section 4.2 390 of [I-D.ietf-lake-edhoc], using Expand() with the EDHOC hash 391 algorithm: 393 KEYSTREAM_2 = EDHOC-KDF(PRK_2e, TH_2, "KEYSTREAM_2", h'', length) = 394 = HKDF-Expand(PRK_2e, info, length), 396 where length is the length of PLAINTEXT_2, and info for KEYSTREAM_2 397 is: 399 info = 400 ( 401 h'71A6C7C5BA9AD47FE72DA4DC359BF6B276D3515968711B9A911C71FC096AEE0E', 402 "KEYSTREAM_2", 403 h'', 404 10 405 ) 407 where last value is the length of PLAINTEXT_2. 409 info for KEYSTREAM_2 (CBOR Sequence) (48 bytes) 410 58 20 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 411 71 1b 9a 91 1c 71 fc 09 6a ee 0e 6b 4b 45 59 53 54 52 45 41 4d 5f 32 412 40 0a 414 KEYSTREAM_2 (Raw Value) (10 bytes) 415 0a b8 c2 0e 84 9e 52 f5 9d fb 417 R calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and KEYSTREAM_2: 419 CIPHERTEXT_2 (Raw Value) (10 bytes) 420 0f f0 4c 29 4f 4a c6 02 cf 78 422 R constructs message_2: 424 message_2 = 425 ( 426 G_Y_CIPHERTEXT_2, 427 C_R 428 ) 430 where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of 431 the raw values of G_Y and CIPHERTEXT_2. 433 message_2 (CBOR Sequence) (45 bytes) 434 58 2a 25 54 91 b0 5a 39 89 ff 2d 3f fe a6 20 98 aa b5 7c 16 0f 29 4e 435 d9 48 01 8b 41 90 f7 d1 61 82 4e 0f f0 4c 29 4f 4a c6 02 cf 78 40 437 3.3. message_3 439 Since METHOD = 3, I authenticates using static DH. 441 I's static key pair for use with the EDHOC key exchange algorithm is 442 based on the same curve as for the ephemeral keys, X25519: 444 I (Raw Value) (Initiator's private authentication key) (32 bytes) 445 cf c4 b6 ed 22 e7 00 a3 0d 5c 5b cd 61 f1 f0 20 49 de 23 54 62 33 48 446 93 d6 ff 9f 0c fe a3 fe 04 448 G_I (Raw Value) (Initiator's public authentication key) (32 bytes) 449 4a 49 d8 8c d5 d8 41 fa b7 ef 98 3e 91 1d 25 78 86 1f 95 88 4f 9f 5d 450 c4 2a 2e ed 33 de 79 ed 77 452 PRK_4x3m is derived as specified in Section 4.1.3 of 453 [I-D.ietf-lake-edhoc]. Since I authenticates with static DH (METHOD 454 = 3), PRK_4x3m is derived from G_IY using Extract() with the EDHOC 455 hash algorithm: 457 PRK_4x3m = Extract(PRK_3e2m, G_IY) = 458 = HMAC-SHA-256(PRK_3e2m, G_IY) 460 where G_IY is the ECDH shared secret calculated from G_I and Y, or 461 G_Y and I. 463 G_IY (Raw Value) (ECDH shared secret) (32 bytes) 464 0a f4 2a d5 12 dc 3e 97 2b 3a c4 d4 7b a3 3f fc 21 f1 ae 6f 07 f2 f8 465 94 85 4a 5a 47 44 33 85 48 467 PRK_4x3m (Raw Value) (32 bytes) 468 b8 cc df 14 20 b5 b0 c8 2a 58 7e 7d 26 dd 7b 70 48 57 4c 3a 48 df 9f 469 6a 45 f7 21 c0 cf a4 b2 7c 470 The transcript hash TH_3 is calculated using the EDHOC hash 471 algorithm: 473 TH_3 = H(TH_2, CIPHERTEXT_2) 475 Input to calculate TH_3 (CBOR Sequence) (45 bytes) 476 58 20 71 a6 c7 c5 ba 9a d4 7f e7 2d a4 dc 35 9b f6 b2 76 d3 51 59 68 477 71 1b 9a 91 1c 71 fc 09 6a ee 0e 4a 0f f0 4c 29 4f 4a c6 02 cf 78 479 TH_3 (Raw Value) (32 bytes) 480 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 5a c2 481 62 9b 2b be f7 fb 24 a3 70 483 TH_3 (CBOR Data Item) (34 bytes) 484 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 485 5a c2 62 9b 2b be f7 fb 24 a3 70 487 I constructs the remaining input needed to calculate MAC_3: 489 MAC_3 = EDHOC-KDF(PRK_4x3m, TH_3, "MAC_3", 490 << ID_CRED_I, CRED_I, ? EAD_3 >>, mac_length_3) 492 CRED_I is identified by a 'kid' with integer value -10: 494 ID_CRED_I = 495 { 496 4 : -10 497 } 499 ID_CRED_I (CBOR Data Item) (3 bytes) a1 04 29 501 CRED_I is an RPK encoded as a CCS: 503 { /CCS/ 504 2 : "42-50-31-FF-EF-37-32-39", /sub/ 505 8 : { /cnf/ 506 1 : { /COSE_Key/ 507 1 : 1, /kty/ 508 2 : -10, /kid/ 509 -1 : 4, /crv/ 510 -2 : h'4A49D88CD5D841FAB7EF983E911D2578 /x/ 511 861F95884F9F5DC42A2EED33DE79ED77' 512 } 513 } 514 } 515 CRED_I (CBOR Data Item) (71 bytes) 516 a2 02 77 34 32 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 517 2d 33 39 08 a1 01 a4 01 01 02 29 20 04 21 58 20 4a 49 d8 8c d5 d8 41 518 fa b7 ef 98 3e 91 1d 25 78 86 1f 95 88 4f 9f 5d c4 2a 2e ed 33 de 79 519 ed 77 521 No external authorization data: 523 EAD_3 (CBOR Sequence) (0 bytes) 525 MAC_3 is computed through Expand() using the EDHOC hash algorithm, 526 see Section 4.2 of [I-D.ietf-lake-edhoc]: 528 MAC_3 = HKDF-Expand(PRK_4x3m, info, mac_length_3) 530 Since METHOD = 3, mac_length_3 is given by the EDHOC MAC length. 532 info for MAC_3 is: 534 info = 535 ( 536 h'A49007CE54762E467C4E4A44692F2070D3E9EB00F95AC2629B2BBEF7FB24A370', 537 "MAC_3", 538 h'A10429A2027734322D35302D33312D46462D45462D33372D33322D333908A101 539 A40101022920042158204A49D88CD5D841FAB7EF983E911D2578861F95884F9F 540 5DC42A2EED33DE79ED77', 541 8 542 ) 544 where the last value is the EDHOC MAC length. 546 info for MAC_3 (CBOR Sequence) (117 bytes) 547 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 548 5a c2 62 9b 2b be f7 fb 24 a3 70 65 4d 41 43 5f 33 58 4a a1 04 29 a2 549 02 77 34 32 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 550 33 39 08 a1 01 a4 01 01 02 29 20 04 21 58 20 4a 49 d8 8c d5 d8 41 fa 551 b7 ef 98 3e 91 1d 25 78 86 1f 95 88 4f 9f 5d c4 2a 2e ed 33 de 79 ed 552 77 08 554 MAC_3 (Raw Value) (8 bytes) 555 db 0b 8f 75 27 09 53 da 557 MAC_3 (CBOR Data Item) (9 bytes) 558 48 db 0b 8f 75 27 09 53 da 560 Since METHOD = 3, Signature_or_MAC_3 is MAC_3: 562 Signature_or_MAC_3 (Raw Value) (8 bytes) 563 db 0b 8f 75 27 09 53 da 565 Signature_or_MAC_3 (CBOR Data Item) (9 bytes) 566 48 db 0b 8f 75 27 09 53 da 568 I constructs the plaintext P_3: 570 P_3 = 571 ( 572 ID_CRED_I / bstr / int, 573 Signature_or_MAC_3, 574 ? EAD_3 575 ) 577 Since ID_CRED_I contains a single 'kid' parameter, only the int -10 578 is included in the plaintext. 580 P_3 (CBOR Sequence) (10 bytes) 581 29 48 db 0b 8f 75 27 09 53 da 583 I constructs the associated data for message_3: 585 A_3 = 586 ( 587 "Encrypt0", 588 h'', 589 TH_3 590 ) 592 A_3 (CBOR Data Item) (45 bytes) 593 83 68 45 6e 63 72 79 70 74 30 40 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 594 4a 44 69 2f 20 70 d3 e9 eb 00 f9 5a c2 62 9b 2b be f7 fb 24 a3 70 596 I constructs the input needed to derive the key K_3, see Section 4.2 597 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 599 K_3 = EDHOC-KDF(PRK_3e2m, TH_3, "K_3", h'', length) = 600 = HKDF-Expand(PRK_3e2m, info, length), 602 where length is the key length of EDHOC AEAD algorithm, and info for 603 K_3 is: 605 info = 606 ( 607 h'A49007CE54762E467C4E4A44692F2070D3E9EB00F95AC2629B2BBEF7FB24A370', 608 "K_3", 609 h'', 610 16 611 ) 613 where the last value is the key length of EDHOC AEAD algorithm. 615 info for K_3 (CBOR Sequence) (40 bytes) 616 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 617 5a c2 62 9b 2b be f7 fb 24 a3 70 63 4b 5f 33 40 10 619 K_3 (Raw Value) (16 bytes) 620 2a 30 e4 f6 bc 55 8d 0e 7a 8c 63 ee 7b b5 45 7f 622 I constructs the input needed to derive the nonce IV_3, see 623 Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 625 IV_3 = EDHOC-KDF(PRK_3e2m, TH_3, "IV_3", h'', length) = 626 = HKDF-Expand(PRK_3e2m, info, length), 628 where length is the nonce length of EDHOC AEAD algorithm, and info 629 for IV_3 is: 631 info = 632 ( 633 h'A49007CE54762E467C4E4A44692F2070D3E9EB00F95AC2629B2BBEF7FB24A370', 634 "IV_3", 635 h'', 636 13 637 ) 639 where the last value is the nonce length of EDHOC AEAD algorithm. 641 info for IV_3 (CBOR Sequence) (41 bytes) 642 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 643 5a c2 62 9b 2b be f7 fb 24 a3 70 64 49 56 5f 33 40 0d 645 IV_3 (Raw Value) (13 bytes) 646 b3 8f b6 31 e3 44 a8 10 52 56 32 ed f8 648 I calculates CIPHERTEXT_3 as 'ciphertext' of COSE_Encrypt0 applied 649 using the EDHOC AEAD algorithm with plaintext P_3, additional data 650 A_3, key K_3 and nonce IV_3. 652 CIPHERTEXT_3 (Raw Value) (18 bytes) 653 be 01 46 c1 36 ac 2e ff d4 53 a7 5e fa 90 89 6f 65 3b 655 message_3 is the CBOR bstr encoding of CIPHERTEXT_3: 657 message_3 (CBOR Sequence) (19 bytes) 658 52 be 01 46 c1 36 ac 2e ff d4 53 a7 5e fa 90 89 6f 65 3b 660 The transcript hash TH_4 is calculated using the EDHOC hash 661 algorithm: 663 TH_4 = H(TH_3, CIPHERTEXT_3) 665 Input to calculate TH_4 (CBOR Sequence) (53 bytes) 666 58 20 a4 90 07 ce 54 76 2e 46 7c 4e 4a 44 69 2f 20 70 d3 e9 eb 00 f9 667 5a c2 62 9b 2b be f7 fb 24 a3 70 52 be 01 46 c1 36 ac 2e ff d4 53 a7 668 5e fa 90 89 6f 65 3b 670 TH_4 (Raw Value) (32 bytes) 671 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 f8 d0 672 00 ad ce 88 b6 30 d8 84 eb 674 TH_4 (CBOR Data Item) (34 bytes) 675 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 676 f8 d0 00 ad ce 88 b6 30 d8 84 eb 678 3.4. message_4 680 No external authorization data: 682 EAD_4 (CBOR Sequence) (0 bytes) 684 R constructs the plaintext P_4: 686 P_4 = 687 ( 688 ? EAD_4 689 ) 691 P_4 (CBOR Sequence) (0 bytes) 693 R constructs the associated data for message_4: 695 A_4 = 696 ( 697 "Encrypt0", 698 h'', 699 TH_4 700 ) 702 A_4 (CBOR Data Item) (45 bytes) 703 83 68 45 6e 63 72 79 70 74 30 40 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 704 79 68 78 4f 55 40 dd 64 a3 bb 07 f8 d0 00 ad ce 88 b6 30 d8 84 eb 706 R constructs the input needed to derive the EDHOC message_4 key, see 707 Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 709 K_4 = EDHOC-Exporter("EDHOC_K_4", h'', length) 710 = EDHOC-KDF(PRK_4x3m, TH_4, "EDHOC_K_4", h'', length) 711 = HKDF-Expand(PRK_4x3m, info, length) 713 where length is the key length of the EDHOC AEAD algorithm, and info 714 for EDHOC_K_4 is: 716 info = 717 ( 718 h'4B9ADD2A9EEB8849716C7968784F5540DD64A3BB07F8D000ADCE88B630D884EB', 719 "EDHOC_K_4", 720 h'', 721 16 722 ) 724 where the last value is the key length of EDHOC AEAD algorithm. 726 info for K_4 (CBOR Sequence) (46 bytes) 727 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 728 f8 d0 00 ad ce 88 b6 30 d8 84 eb 69 45 44 48 4f 43 5f 4b 5f 34 40 10 730 K_4 (Raw Value) (16 bytes) 731 55 b5 7d 59 a8 26 f4 56 38 86 9b 75 07 0b 11 17 733 R constructs the input needed to derive the EDHOC message_4 nonce, 734 see Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash 735 algorithm: 737 IV_4 = 738 = EDHOC-Exporter( "EDHOC_IV_4", h'', length ) 739 = EDHOC-KDF(PRK_4x3m, TH_4, "EDHOC_IV_4", h'', length) 740 = HKDF-Expand(PRK_4x3m, info, length) 742 where length is the nonce length of EDHOC AEAD algorithm, and info 743 for EDHOC_IV_4 is: 745 info = 746 ( 747 h'4B9ADD2A9EEB8849716C7968784F5540DD64A3BB07F8D000ADCE88B630D884EB', 748 "EDHOC_IV_4", 749 h'', 750 13 751 ) 753 where the last value is the nonce length of EDHOC AEAD algorithm. 755 info for IV_4 (CBOR Sequence) (47 bytes) 756 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 757 f8 d0 00 ad ce 88 b6 30 d8 84 eb 6a 45 44 48 4f 43 5f 49 56 5f 34 40 758 0d 760 IV_4 (Raw Value) (13 bytes) 761 20 7a 4e fc 25 a6 58 96 45 11 f1 63 76 763 R calculates CIPHERTEXT_4 as 'ciphertext' of COSE_Encrypt0 applied 764 using the EDHOC AEAD algorithm with plaintext P_4, additional data 765 A_4, key K_4 and nonce IV_4. 767 CIPHERTEXT_4 (8 bytes) 768 e9 e6 c8 b6 37 6d b0 b1 770 message_4 is the CBOR bstr encoding of CIPHERTEXT_4: 772 message_4 (CBOR Sequence) (9 bytes) 773 48 e9 e6 c8 b6 37 6d b0 b1 775 3.5. OSCORE Parameters 777 The derivation of OSCORE parameters is specified in Appendix A.2 of 778 [I-D.ietf-lake-edhoc]. 780 The AEAD and Hash algorithms to use in OSCORE are given by the 781 selected cipher suite: 783 Application AEAD Algorithm (int) 784 10 786 Application Hash Algorithm (int) 787 -16 788 The mapping from EDHOC connection identifiers to OSCORE Sender/ 789 Recipient IDs is defined in Section A.1of [I-D.ietf-lake-edhoc]. 791 C_R is mapped to the Recipient ID of the server, i.e., the Sender ID 792 of the client. Since C_R is byte valued it the OSCORE Sender/ 793 Recipient ID equals the byte string (in this case the empty byte 794 string). 796 Client's OSCORE Sender ID (Raw Value) (0 bytes) 798 C_I is mapped to the Recipient ID of the client, i.e., the Sender ID 799 of the server. Since C_I is a numeric, it is converted to a byte 800 string equal to its CBOR encoded form. 802 Server's OSCORE Sender ID (Raw Value) (1 bytes) 803 0c 805 The OSCORE Master Secret is computed through Expand() using the 806 Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]: 808 OSCORE Master Secret = 809 = EDHOC-Exporter("OSCORE_Master_Secret", h'', key_length) 810 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE_Master_Secret", h'', key_length) 811 = HKDF-Expand(PRK_4x3m, info, key_length) 813 where key_length is by default the key length of the Application AEAD 814 algorithm, and info for the OSCORE Master Secret is: 816 info = 817 ( 818 h'4B9ADD2A9EEB8849716C7968784F5540DD64A3BB07F8D000ADCE88B630D884EB', 819 "OSCORE_Master_Secret", 820 h'', 821 16 822 ) 824 where the last value is the key length of Application AEAD algorithm. 826 info for OSCORE Master Secret (CBOR Sequence) (57 bytes) 827 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 828 f8 d0 00 ad ce 88 b6 30 d8 84 eb 74 4f 53 43 4f 52 45 5f 4d 61 73 74 829 65 72 5f 53 65 63 72 65 74 40 10 831 OSCORE Master Secret (Raw Value) (16 bytes) 832 c0 53 01 37 6c e9 5f 67 c4 14 d8 bb 5f 0f db 5e 834 The OSCORE Master Salt is computed through Expand() using the 835 Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]: 837 OSCORE Master Salt = 838 = EDHOC-Exporter("OSCORE_Master_Salt", h'', salt_length) 839 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE_Master_Salt", h'', salt_length) 840 = HKDF-Expand(PRK_4x3m, info, salt_length) 842 where salt_length is the length of the OSCORE Master Salt, and info 843 for the OSCORE Master Salt is: 845 info = 846 ( 847 h'4B9ADD2A9EEB8849716C7968784F5540DD64A3BB07F8D000ADCE88B630D884EB', 848 "OSCORE_Master_Salt", 849 h'', 850 8 851 ) 853 where the last value is the length of the OSCORE Master Salt. 855 info for OSCORE Master Salt (CBOR Sequence) (55 bytes) 856 58 20 4b 9a dd 2a 9e eb 88 49 71 6c 79 68 78 4f 55 40 dd 64 a3 bb 07 857 f8 d0 00 ad ce 88 b6 30 d8 84 eb 72 4f 53 43 4f 52 45 5f 4d 61 73 74 858 65 72 5f 53 61 6c 74 40 08 860 OSCORE Master Salt (Raw Value) (8 bytes) 861 74 01 b4 6f a8 2f 66 31 863 3.6. Key Update 865 Key update is defined in Section 4.4 of [I-D.ietf-lake-edhoc]: 867 EDHOC-KeyUpdate(nonce): 868 PRK_4x3m = Extract(nonce, PRK_4x3m) 870 KeyUpdate Nonce (Raw Value) (16 bytes) 871 d4 91 a2 04 ca a6 b8 02 54 c4 71 e0 de ee d1 60 873 PRK_4x3m after KeyUpdate (Raw Value) (32 bytes) 874 82 09 6e 3a e6 3d 93 c7 b6 f8 8b 7c 1b 5e 63 f4 9f 74 c8 0e f3 14 42 875 51 9f fb 20 e2 f8 87 3e b1 877 The OSCORE Master Secret is derived with the updated PRK_4x3m: 879 OSCORE Master Secret = HKDF-Expand(PRK_4x3m, info, key_length) 881 where info and key_length are unchanged. 883 OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes) 884 a5 15 23 1d 9e c5 88 74 82 22 6b f9 e0 da 05 ce 885 The OSCORE Master Salt is derived with the updated PRK_4x3m: 887 OSCORE Master Salt = HKDF-Expand(PRK_4x3m, info, salt_length) 889 where info and salt_length are unchanged. 891 OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes) 892 50 57 e5 92 ed 8b 11 28 894 4. Authentication with signatures, X.509 identified by 'x5t' 896 In this example the Initiator (I) and Responder (R) are authenticated 897 with digital signatures (METHOD = 0). The public keys are 898 represented with dummy X.509 certificates identified by the COSE 899 header parameter 'x5t'. 901 4.1. message_1 903 Both endpoints are authenticated with signatures, i.e. METHOD = 0: 905 METHOD (CBOR Data Item) (1 bytes) 906 00 908 I selects cipher suite 0. A single cipher suite is encoded as an 909 int: 911 SUITES_I (CBOR Data Item) (1 bytes) 912 00 914 I creates an ephemeral key pair for use with the EDHOC key exchange 915 algorithm: 917 X (Raw Value) (Initiator's ephemeral private key) (32 bytes) 918 b0 26 b1 68 42 9b 21 3d 6b 42 1d f6 ab d0 64 1c d6 6d ca 2e e7 fd 59 919 77 10 4b b2 38 18 2e 5e a6 921 G_X (Raw Value) (Initiator's ephemeral public key) (32 bytes) 922 e3 1e c1 5e e8 03 94 27 df c4 72 7e f1 7e 2e 0e 69 c5 44 37 f3 c5 82 923 80 19 ef 0a 63 88 c1 25 52 925 G_X (CBOR Data Item) (Initiator's ephemeral public key) (34 bytes) 926 58 20 e3 1e c1 5e e8 03 94 27 df c4 72 7e f1 7e 2e 0e 69 c5 44 37 f3 927 c5 82 80 19 ef 0a 63 88 c1 25 52 929 I selects its connection identifier C_I to be the int 14: 931 C_I (Raw Value) (Connection identifier chosen by I) (int) 932 14 933 C_I (CBOR Data Item) (Connection identifier chosen by I) (1 bytes) 934 0e 936 No external authorization data: 938 EAD_1 (CBOR Sequence) (0 bytes) 940 I constructs message_1: 942 message_1 = 943 ( 944 0, 945 0, 946 h'E31EC15EE8039427DFC4727EF17E2E0E69C54437F3C5828019EF0A6388C12552', 947 14 948 ) 950 message_1 (CBOR Sequence) (37 bytes) 951 00 00 58 20 e3 1e c1 5e e8 03 94 27 df c4 72 7e f1 7e 2e 0e 69 c5 44 952 37 f3 c5 82 80 19 ef 0a 63 88 c1 25 52 0e 954 4.2. message_2 956 R creates an ephemeral key pair for use with the EDHOC key exchange 957 algorithm: 959 Y (Raw Value) (Responder's ephemeral private key) (32 bytes) 960 db 06 84 a8 12 54 66 41 3e 59 8d c2 67 73 7f 5f ef 0c 5a a2 29 fa a1 961 55 43 9f 60 08 5f d2 53 6d 963 G_Y (Raw Value) (Responder's ephemeral public key) (32 bytes) 964 e1 73 90 96 c5 c9 58 2c 12 98 91 81 66 d6 95 48 c7 8f 74 97 b2 58 c0 965 85 6a a2 01 98 93 a3 94 25 967 G_Y (CBOR Data Item) (Responder's ephemeral public key) (34 bytes) 968 58 20 e1 73 90 96 c5 c9 58 2c 12 98 91 81 66 d6 95 48 c7 8f 74 97 b2 969 58 c0 85 6a a2 01 98 93 a3 94 25 971 PRK_2e is specified in Section 4.1.1 of [I-D.ietf-lake-edhoc]. 973 First, the ECDH shared secret G_XY is computed from G_X and Y, or G_Y 974 and X: 976 G_XY (Raw Value) (ECDH shared secret) (32 bytes) 977 0b eb 98 d8 8f 49 67 7c 17 47 88 f8 87 bd cc d2 28 a1 88 39 2c cd 10 978 12 bd 31 70 d7 c8 85 65 66 979 Then, PRK_2e is calculated using Extract() determined by the EDHOC 980 hash algorithm: 982 PRK_2e = Extract(salt, G_XY) = 983 = HMAC-SHA-256(salt, G_XY) 985 where salt is the zero-length byte string: 987 salt (Raw Value) (0 bytes) 989 PRK_2e (Raw Value) (32 bytes) 990 4e 57 dc e2 58 75 77 c4 34 69 7c 03 93 5c c6 a2 82 16 5a 88 76 05 11 991 fc 70 a8 c0 02 20 a5 ba 1a 993 Since METHOD = 0, R authenticates using signatures with the EDHOC 994 signature algorithm. R's signature key pair using Ed25519 is (note 995 that Ed448 would also be compatible with EdDSA): 997 SK_R (Raw Value) (Responders's private authentication key) (32 bytes) 998 bc 4d 4f 98 82 61 22 33 b4 02 db 75 e6 c4 cf 30 32 a7 0a 0d 2e 3e e6 999 d0 1b 11 dd de 5f 41 9c fc 1001 PK_R (Raw Value) (Responders's public authentication key) (32 bytes) 1002 27 ee f2 b0 8a 6f 49 6f ae da a6 c7 f9 ec 6a e3 b9 d5 24 24 58 0d 52 1003 e4 9d a6 93 5e df 53 cd c5 1005 PRK_3e2m is specified in Section 4.1.2 of [I-D.ietf-lake-edhoc]. 1007 Since R authenticates with signatures PRK_3e2m = PRK_2e. 1009 PRK_3e2m (Raw Value) (32 bytes) 1010 4e 57 dc e2 58 75 77 c4 34 69 7c 03 93 5c c6 a2 82 16 5a 88 76 05 11 1011 fc 70 a8 c0 02 20 a5 ba 1a 1013 R selects its connection identifier C_R to be the int -19 1015 C_R (Raw Value) (Connection identifier chosen by R) (int) 1016 -19 1018 C_R (CBOR Data Item) (Connection identifier chosen by R) (1 bytes) 1019 32 1021 The transcript hash TH_2 is calculated using the EDHOC hash 1022 algorithm: 1024 TH_2 = H(H(message_1), G_Y, C_R) 1025 H(message_1) (Raw Value) (32 bytes) 1026 ce ba 8d 4d a2 80 b1 61 c8 5a 19 47 81 a9 31 88 35 41 50 b4 9c 4f 93 1027 2e 4a a0 8f f3 ed 11 04 65 1029 H(message_1) (CBOR Data Item) (34 bytes) 1030 58 20 ce ba 8d 4d a2 80 b1 61 c8 5a 19 47 81 a9 31 88 35 41 50 b4 9c 1031 4f 93 2e 4a a0 8f f3 ed 11 04 65 1033 The input to calculate TH_2 is the CBOR sequence: 1035 H(message_1), G_Y, C_R 1037 Input to calculate TH_2 (CBOR Sequence) (69 bytes) 1038 58 20 ce ba 8d 4d a2 80 b1 61 c8 5a 19 47 81 a9 31 88 35 41 50 b4 9c 1039 4f 93 2e 4a a0 8f f3 ed 11 04 65 58 20 e1 73 90 96 c5 c9 58 2c 12 98 1040 91 81 66 d6 95 48 c7 8f 74 97 b2 58 c0 85 6a a2 01 98 93 a3 94 25 32 1042 TH_2 (Raw Value) (32 bytes) 1043 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 44 3e 1044 91 83 3d 68 cd dd 7f 9b 39 1046 TH_2 (CBOR Data Item) (34 bytes) 1047 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 1048 44 3e 91 83 3d 68 cd dd 7f 9b 39 1050 R constructs the remaining input needed to calculate MAC_2: 1052 MAC_2 = EDHOC-KDF(PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R, CRED_R, ? 1053 EAD_2 >>, mac_length_2) 1055 CRED_R is identified by a 64-bit hash: 1057 ID_CRED_R = 1058 { 1059 34 : [-15, h'60780E9451BDC43C'] 1060 } 1062 where the COSE header value 34 ('x5t') indicates a hash of an X.509 1063 certficate, and the COSE algorithm -15 indicates the hash algorithm 1064 SHA-256 truncated to 64 bits. 1066 ID_CRED_R (CBOR Data Item) (14 bytes) a1 18 22 82 2e 48 60 78 0e 94 1067 51 bd c4 3c 1069 CRED_R is a byte string acting as a dummy X.509 certificate: 1071 CRED_R (CBOR Data Item) (113 bytes) 1072 58 6f 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 1073 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 1074 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 1075 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 1076 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 1078 No external authorization data: 1080 EAD_2 (CBOR Sequence) (0 bytes) 1082 MAC_2 is computed through Expand() using the EDHOC hash algorithm, 1083 Section 4.2 of [I-D.ietf-lake-edhoc]: 1085 MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2) 1087 Since METHOD = 0, mac_length_2 is given by the EDHOC hash algorithm. 1089 info for MAC_2 is: 1091 info = 1092 ( 1093 h'0782DBB687C30288A30B706B074BED789574573F24443E91833D68CDDD7F9B39', 1094 "MAC_2", 1095 h'A11822822E4860780E9451BDC43C586F000102030405060708090A0B0C0D0E0F10 1096 1112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F3031 1097 32333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152 1098 535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E', 1099 32 1100 ) 1102 where the last value is the output size of the EDHOC hash algorithm. 1104 info for MAC_2 (CBOR Sequence) (171 bytes) 1105 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 1106 44 3e 91 83 3d 68 cd dd 7f 9b 39 65 4d 41 43 5f 32 58 7f a1 18 22 82 1107 2e 48 60 78 0e 94 51 bd c4 3c 58 6f 00 01 02 03 04 05 06 07 08 09 0a 1108 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 1109 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 1110 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 1111 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 1112 67 68 69 6a 6b 6c 6d 6e 18 20 1114 MAC_2 (Raw Value) (32 bytes) 1115 27 c8 f1 e4 a7 af f2 a0 f0 bc 0f 91 83 93 ee f1 8b 69 0c 4d 4c 3d 81 1116 bd fe 22 95 42 40 bc c4 cc 1117 MAC_2 (CBOR Data Item) (34 bytes) 1118 58 20 27 c8 f1 e4 a7 af f2 a0 f0 bc 0f 91 83 93 ee f1 8b 69 0c 4d 4c 1119 3d 81 bd fe 22 95 42 40 bc c4 cc 1121 Since METHOD = 0, Signature_or_MAC_2 is the 'signature' of the 1122 COSE_Sign1 object. 1124 R constructs the message to be signed: 1126 [ "Signature1", << ID_CRED_R >>, 1127 << TH_2, CRED_R, ? EAD_2 >>, MAC_2 ] = 1129 [ 1130 "Signature1", 1131 h'A11822822E4860780E9451BDC43C', 1132 h'58200782DBB687C30288A30B706B074BED789574573F24443E91833D68CDDD7F 1133 9B39586F000102030405060708090A0B0C0D0E0F101112131415161718191A1B 1134 1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B 1135 3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B 1136 5C5D5E5F606162636465666768696A6B6C6D6E', 1137 h'27C8F1E4A7AFF2A0F0BC0F918393EEF18B690C4D4C3D81BDFE22954240BCC4CC' 1138 ] 1140 Message to be signed 2 (CBOR Data Item) (210 bytes) 1141 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 60 78 0e 94 1142 51 bd c4 3c 58 93 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 1143 78 95 74 57 3f 24 44 3e 91 83 3d 68 cd dd 7f 9b 39 58 6f 00 01 02 03 1144 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1145 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 1146 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 1147 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 1148 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 58 20 27 c8 f1 e4 a7 af 1149 f2 a0 f0 bc 0f 91 83 93 ee f1 8b 69 0c 4d 4c 3d 81 bd fe 22 95 42 40 1150 bc c4 cc 1152 R signs using the private authentication key SK_R 1154 Signature_or_MAC_2 (Raw Value) (64 bytes) 1155 3c e5 20 75 db 55 89 2d f1 25 8f a6 9e 86 ab 5b 59 33 ea dc 07 ea 82 1156 41 1f 17 9a 5f de f1 c9 43 23 63 f6 58 f9 a2 04 fa 81 54 d1 4f fd 87 1157 b5 01 0c 4f d0 a0 c7 7e 2a ca 77 5f 67 cb 5e 8b be 08 1159 Signature_or_MAC_2 (CBOR Data Item) (66 bytes) 1160 58 40 3c e5 20 75 db 55 89 2d f1 25 8f a6 9e 86 ab 5b 59 33 ea dc 07 1161 ea 82 41 1f 17 9a 5f de f1 c9 43 23 63 f6 58 f9 a2 04 fa 81 54 d1 4f 1162 fd 87 b5 01 0c 4f d0 a0 c7 7e 2a ca 77 5f 67 cb 5e 8b be 08 1164 R constructs the plaintext: 1166 PLAINTEXT_2 = 1167 ( 1168 ID_CRED_R / bstr / int, 1169 Signature_or_MAC_2, 1170 ? EAD_2 1171 ) 1173 PLAINTEXT_2 (CBOR Sequence) (80 bytes) 1174 a1 18 22 82 2e 48 60 78 0e 94 51 bd c4 3c 58 40 3c e5 20 75 db 55 89 1175 2d f1 25 8f a6 9e 86 ab 5b 59 33 ea dc 07 ea 82 41 1f 17 9a 5f de f1 1176 c9 43 23 63 f6 58 f9 a2 04 fa 81 54 d1 4f fd 87 b5 01 0c 4f d0 a0 c7 1177 7e 2a ca 77 5f 67 cb 5e 8b be 08 1179 The input needed to calculate KEYSTREAM_2 is defined in Section 4.2 1180 of [I-D.ietf-lake-edhoc], using Expand() with the EDHOC hash 1181 algorithm: 1183 KEYSTREAM_2 = EDHOC-KDF(PRK_2e, TH_2, "KEYSTREAM_2", h'', length) = 1184 = HKDF-Expand(PRK_2e, info, length) 1186 where length is the length of PLAINTEXT_2, and info for KEYSTREAM_2 1187 is: 1189 info = 1190 ( 1191 h'0782DBB687C30288A30B706B074BED789574573F24443E91833D68CDDD7F9B39', 1192 "KEYSTREAM_2", 1193 h'', 1194 80 1195 ) 1197 where the last value is the length of PLAINTEXT_2. 1199 info for KEYSTREAM_2 (CBOR Sequence) (49 bytes) 1200 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 1201 44 3e 91 83 3d 68 cd dd 7f 9b 39 6b 4b 45 59 53 54 52 45 41 4d 5f 32 1202 40 18 50 1204 KEYSTREAM_2 (Raw Value) (80 bytes) 1205 c8 13 ff 19 3b c0 31 40 47 99 6a 37 03 09 ba ed 45 f7 f5 f8 d5 6c 1c 1206 df 44 6b 01 c5 77 8d 68 9f 7f 13 da 50 17 ba 0f 4e 5f df 6e d0 59 55 1207 cd 8c e4 ec 43 7a 22 fa 8e e8 72 8c 36 2b cb 7b 93 a9 11 e1 67 95 04 1208 31 c1 d5 05 0b da 69 e9 5b aa fb 1210 R calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and KEYSTREAM_2: 1212 CIPHERTEXT_2 (Raw Value) (80 bytes) 1213 69 0b dd 9b 15 88 51 38 49 0d 3b 8a c7 35 e2 ad 79 12 d5 8d 0e 39 95 1214 f2 b5 4e 8e 63 e9 0b c3 c4 26 20 30 8c 10 50 8d 0f 40 c8 f4 8f 87 a4 1215 04 cf c7 8f b5 22 db 58 8a 12 f3 d8 e7 64 36 fc 26 a8 1d ae b7 35 c3 1216 4f eb 1f 72 54 bd a2 b7 d0 14 f3 1218 R constructs message_2: 1220 message_2 = 1221 ( 1222 G_Y_CIPHERTEXT_2, 1223 C_R 1224 ) 1226 where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of 1227 the raw values of G_Y and CIPHERTEXT_2. 1229 message_2 (CBOR Sequence) (115 bytes) 1230 58 70 e1 73 90 96 c5 c9 58 2c 12 98 91 81 66 d6 95 48 c7 8f 74 97 b2 1231 58 c0 85 6a a2 01 98 93 a3 94 25 69 0b dd 9b 15 88 51 38 49 0d 3b 8a 1232 c7 35 e2 ad 79 12 d5 8d 0e 39 95 f2 b5 4e 8e 63 e9 0b c3 c4 26 20 30 1233 8c 10 50 8d 0f 40 c8 f4 8f 87 a4 04 cf c7 8f b5 22 db 58 8a 12 f3 d8 1234 e7 64 36 fc 26 a8 1d ae b7 35 c3 4f eb 1f 72 54 bd a2 b7 d0 14 f3 32 1236 4.3. message_3 1238 Since METHOD = 0, I authenticates using signatures with the EDHOC 1239 signature algorithm. I's signature key pair using Ed25519 is (note 1240 that Ed448 would also be compatible with EdDSA): 1242 SK_I (Raw Value) (Initiator's private authentication key) (32 bytes) 1243 36 6a 58 59 a4 cd 65 cf ae af 05 66 c9 fc 7e 1a 93 30 6f de c1 77 63 1244 e0 58 13 a7 0f 21 ff 59 db 1246 PK_I (Raw Value) (Responders's public authentication key) (32 bytes) 1247 ec 2c 2e b6 cd d9 57 82 a8 cd 0b 2e 9c 44 27 07 74 dc bd 31 bf be 23 1248 13 ce 80 13 2e 8a 26 1c 04 1250 PRK_4x3m is specified in Section 4.1.3 of [I-D.ietf-lake-edhoc]. 1252 Since R authenticates with signatures PRK_4x3m = PRK_3e2m. 1254 PRK_4x3m (Raw Value) (32 bytes) 1255 4e 57 dc e2 58 75 77 c4 34 69 7c 03 93 5c c6 a2 82 16 5a 88 76 05 11 1256 fc 70 a8 c0 02 20 a5 ba 1a 1258 The transcript hash TH_3 is calculated using the EDHOC hash 1259 algorithm: 1261 TH_3 = H(TH_2, CIPHERTEXT_2) 1263 Input to calculate TH_3 (CBOR Sequence) (116 bytes) 1264 58 20 07 82 db b6 87 c3 02 88 a3 0b 70 6b 07 4b ed 78 95 74 57 3f 24 1265 44 3e 91 83 3d 68 cd dd 7f 9b 39 58 50 69 0b dd 9b 15 88 51 38 49 0d 1266 3b 8a c7 35 e2 ad 79 12 d5 8d 0e 39 95 f2 b5 4e 8e 63 e9 0b c3 c4 26 1267 20 30 8c 10 50 8d 0f 40 c8 f4 8f 87 a4 04 cf c7 8f b5 22 db 58 8a 12 1268 f3 d8 e7 64 36 fc 26 a8 1d ae b7 35 c3 4f eb 1f 72 54 bd a2 b7 d0 14 1269 f3 1271 TH_3 (Raw Value) (32 bytes) 1272 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 37 98 1273 b0 81 a9 bd 12 a3 31 7a 82 1275 TH_3 (CBOR Data Item) (34 bytes) 1276 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1277 37 98 b0 81 a9 bd 12 a3 31 7a 82 1279 I constructs the remaining input needed to calculate MAC_3: 1281 MAC_3 = EDHOC-KDF(PRK_4x3m, TH_3, "MAC_3", 1282 << ID_CRED_I, CRED_I, ? EAD_3 >>, mac_length_3) 1284 CRED_I is identified by a 64-bit hash: 1286 ID_CRED_I = 1287 { 1288 34 : [-15, h'81D45BE06329D63A'] 1289 } 1291 where the COSE header value 34 ('x5t') indicates a hash of an X.509 1292 certficate, and the COSE algorithm -15 indicates the hash algorithm 1293 SHA-256 truncated to 64 bits. 1295 ID_CRED_I (CBOR Data Item) (14 bytes) 1296 a1 18 22 82 2e 48 81 d4 5b e0 63 29 d6 3a 1298 CRED_I is a byte string acting as a dummy X.509 certificate: 1300 CRED_I (CBOR Data Item) (139 bytes) 1301 58 89 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 1302 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 1303 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 1304 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 1305 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 1306 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 1307 88 1308 No external authorization data: 1310 EAD_3 (CBOR Sequence) (0 bytes) 1312 MAC_3 is computed through Expand() using the EDHOC hash algorithm, 1313 see Section 4.2 of [I-D.ietf-lake-edhoc]: 1315 MAC_3 = HKDF-Expand(PRK_4x3m, info, mac_length_3) 1317 Since METHOD = 0, mac_length_3 is given by the EDHOC hash algorithm. 1319 info for MAC_3 is: 1321 info = 1322 ( 1323 h'23CE4296FC64AB048A593B6711E4822011BB58D85D3798B081A9BD12A3317A82', 1324 "MAC_3", 1325 h'A11822822E4881D45BE06329D63A5889000102030405060708090A0B0C0D0E0F 1326 101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F 1327 303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F 1328 505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F 1329 707172737475767778797A7B7C7D7E7F808182838485868788', 1330 32 1331 ) 1333 where the last value is the output size of the EDHOC hash algorithm. 1335 info for MAC_3 (CBOR Sequence) (197 bytes) 1336 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1337 37 98 b0 81 a9 bd 12 a3 31 7a 82 65 4d 41 43 5f 33 58 99 a1 18 22 82 1338 2e 48 81 d4 5b e0 63 29 d6 3a 58 89 00 01 02 03 04 05 06 07 08 09 0a 1339 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 1340 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 1341 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 1342 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 1343 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 1344 7e 7f 80 81 82 83 84 85 86 87 88 18 20 1346 MAC_3 (Raw Value) (32 bytes) 1347 fc 86 e7 d4 f1 8b 34 8c 29 7c 2f a3 eb 19 52 9a cc 3e 0a 4c b1 ba 99 1348 b6 9d 16 aa b1 9d 33 3c 12 1350 MAC_3 (CBOR Data Item) (34 bytes) 1351 58 20 fc 86 e7 d4 f1 8b 34 8c 29 7c 2f a3 eb 19 52 9a cc 3e 0a 4c b1 1352 ba 99 b6 9d 16 aa b1 9d 33 3c 12 1354 Since METHOD = 0, Signature_or_MAC_3 is the 'signature' of the 1355 COSE_Sign1 object. 1357 I constructs the message to be signed: 1359 [ "Signature1", << ID_CRED_I >>, 1360 << TH_3, CRED_I, ? EAD_3 >>, MAC_3 ] = 1362 [ 1363 "Signature1", 1364 h'A11822822E4881D45BE06329D63A', 1365 h'58205AA25B46397C2F145EB792ED0D17EA2B078C73E4EE148780C3C2E7341372 1366 CBAD5889000102030405060708090A0B0C0D0E0F101112131415161718191A1B 1367 1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B 1368 3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B 1369 5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B 1370 7C7D7E7F808182838485868788', 1371 h'FC86E7D4F18B348C297C2FA3EB19529ACC3E0A4CB1BA99B69D16AAB19D333C12' 1372 ] 1374 Message to be signed 3 (CBOR Data Item) (236 bytes) 1375 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 81 d4 5b e0 1376 63 29 d6 3a 58 ad 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 1377 20 11 bb 58 d8 5d 37 98 b0 81 a9 bd 12 a3 31 7a 82 58 89 00 01 02 03 1378 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1379 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 1380 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 1381 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 1382 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 1383 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 58 20 fc 86 e7 1384 d4 f1 8b 34 8c 29 7c 2f a3 eb 19 52 9a cc 3e 0a 4c b1 ba 99 b6 9d 16 1385 aa b1 9d 33 3c 12 1387 R signs using the private authentication key SK_R: 1389 Signature_or_MAC_3 (Raw Value) (64 bytes) 1390 3d d3 74 07 a1 d9 f1 2a 5b a6 4d f0 5f a0 d9 46 25 bf 74 0c 29 5f e1 1391 88 58 d6 8e 04 5c 84 90 27 54 88 03 56 3e de 8c 5b 39 11 4f 13 fe 29 1392 78 8a 83 b7 42 28 8e ab 8a 94 52 2c b1 d3 03 f2 62 04 1394 Signature_or_MAC_3 (CBOR Data Item) (66 bytes) 1395 58 40 3d d3 74 07 a1 d9 f1 2a 5b a6 4d f0 5f a0 d9 46 25 bf 74 0c 29 1396 5f e1 88 58 d6 8e 04 5c 84 90 27 54 88 03 56 3e de 8c 5b 39 11 4f 13 1397 fe 29 78 8a 83 b7 42 28 8e ab 8a 94 52 2c b1 d3 03 f2 62 04 1399 R constructs the plaintext: 1401 P_3 = 1402 ( 1403 ID_CRED_I / bstr / int, 1404 Signature_or_MAC_3, 1405 ? EAD_3 1406 ) 1408 P_3 (CBOR Sequence) (80 bytes) 1409 a1 18 22 82 2e 48 81 d4 5b e0 63 29 d6 3a 58 40 3d d3 74 07 a1 d9 f1 1410 2a 5b a6 4d f0 5f a0 d9 46 25 bf 74 0c 29 5f e1 88 58 d6 8e 04 5c 84 1411 90 27 54 88 03 56 3e de 8c 5b 39 11 4f 13 fe 29 78 8a 83 b7 42 28 8e 1412 ab 8a 94 52 2c b1 d3 03 f2 62 04 1414 I constructs the associated data for message_3: 1416 A_3 = 1417 ( 1418 "Encrypt0", 1419 h'', 1420 TH_3 1421 ) 1423 A_3 (CBOR Data Item) (45 bytes) 1424 83 68 45 6e 63 72 79 70 74 30 40 58 20 23 ce 42 96 fc 64 ab 04 8a 59 1425 3b 67 11 e4 82 20 11 bb 58 d8 5d 37 98 b0 81 a9 bd 12 a3 31 7a 82 1427 I constructs the input needed to derive the key K_3, see Section 4.2 1428 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 1430 K_3 = EDHOC-KDF(PRK_3e2m, TH_3, "K_3", h'', length) = 1431 = HKDF-Expand(PRK_3e2m, info, length), 1433 where length is the key length of EDHOC AEAD algorithm, and info for 1434 K_3 is: 1436 info = 1437 ( 1438 h'23CE4296FC64AB048A593B6711E4822011BB58D85D3798B081A9BD12A3317A82', 1439 "K_3", 1440 h'', 1441 16 1442 ) 1444 where the last value is the key length of EDHOC AEAD algorithm. 1446 info for K_3 (CBOR Sequence) (40 bytes) 1447 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1448 37 98 b0 81 a9 bd 12 a3 31 7a 82 63 4b 5f 33 40 10 1449 K_3 (Raw Value) (16 bytes) 1450 7a 40 e4 b6 75 9c 72 7e 8a ef f1 08 9e e7 69 af 1452 I constructs the input needed to derive the nonce IV_3, see 1453 Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 1455 IV_3 = EDHOC-KDF(PRK_3e2m, TH_3, "IV_3", h'', length) = 1456 = HKDF-Expand(PRK_3e2m, info, length), 1458 where length is the nonce length of EDHOC AEAD algorithm, and info 1459 for IV_3 is: 1461 info = 1462 ( 1463 h'23CE4296FC64AB048A593B6711E4822011BB58D85D3798B081A9BD12A3317A82', 1464 "IV_3", 1465 h'', 1466 13 1467 ) 1469 where the last value is the nonce length of EDHOC AEAD algorithm. 1471 info for IV_3 (CBOR Sequence) (41 bytes) 1472 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1473 37 98 b0 81 a9 bd 12 a3 31 7a 82 64 49 56 5f 33 40 0d 1475 IV_3 (Raw Value) (13 bytes) 1476 d3 98 90 65 7e ef 37 8f 36 52 0c b3 44 1478 I calculates CIPHERTEXT_3 as 'ciphertext' of COSE_Encrypt0 applied 1479 using the EDHOC AEAD algorithm with plaintext P_3, additional data 1480 A_3, key K_3 and nonce IV_3. 1482 CIPHERTEXT_3 (Raw Value) (88 bytes) 1483 4c 53 ed 22 c4 5f b0 0c ad 88 9b 4c 06 f2 a2 6c f4 91 54 cb 8b df 4e 1484 ee 44 e2 b5 02 21 ab 1f 02 9d 3d 3e 05 23 dd f9 d7 61 0c 37 6c 72 8a 1485 1e 90 16 92 f1 da 07 82 a3 47 2f f6 eb 1b b6 81 0c 6f 68 68 79 c9 a5 1486 59 4f 8f 17 0c a5 a2 b5 bf 05 a7 4f 42 cd d9 c8 54 e0 1e 1488 message_3 is the CBOR bstr encoding of CIPHERTEXT_3: 1490 message_3 (CBOR Sequence) (90 bytes) 1491 58 58 4c 53 ed 22 c4 5f b0 0c ad 88 9b 4c 06 f2 a2 6c f4 91 54 cb 8b 1492 df 4e ee 44 e2 b5 02 21 ab 1f 02 9d 3d 3e 05 23 dd f9 d7 61 0c 37 6c 1493 72 8a 1e 90 16 92 f1 da 07 82 a3 47 2f f6 eb 1b b6 81 0c 6f 68 68 79 1494 c9 a5 59 4f 8f 17 0c a5 a2 b5 bf 05 a7 4f 42 cd d9 c8 54 e0 1e 1495 The transcript hash TH_4 is calculated using the EDHOC hash 1496 algorithm: 1498 TH_4 = H(TH_3, CIPHERTEXT_3) 1500 Input to calculate TH_4 (CBOR Sequence) (124 bytes) 1501 58 20 23 ce 42 96 fc 64 ab 04 8a 59 3b 67 11 e4 82 20 11 bb 58 d8 5d 1502 37 98 b0 81 a9 bd 12 a3 31 7a 82 58 58 4c 53 ed 22 c4 5f b0 0c ad 88 1503 9b 4c 06 f2 a2 6c f4 91 54 cb 8b df 4e ee 44 e2 b5 02 21 ab 1f 02 9d 1504 3d 3e 05 23 dd f9 d7 61 0c 37 6c 72 8a 1e 90 16 92 f1 da 07 82 a3 47 1505 2f f6 eb 1b b6 81 0c 6f 68 68 79 c9 a5 59 4f 8f 17 0c a5 a2 b5 bf 05 1506 a7 4f 42 cd d9 c8 54 e0 1e 1508 TH_4 (Raw Value) (32 bytes) 1509 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 b2 0a 1510 8b 67 07 6d cc 92 aa d4 0b 1512 TH_4 (CBOR Data Item) (34 bytes) 1513 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1514 b2 0a 8b 67 07 6d cc 92 aa d4 0b 1516 4.4. message_4 1518 No external authorization data: 1520 EAD_4 (CBOR Sequence) (0 bytes) 1522 R constructs the plaintext P_4: 1524 P_4 = 1525 ( 1526 ? EAD_4 1527 ) 1529 P_4 (CBOR Sequence) (0 bytes) 1531 R constructs the associated data for message_4: 1533 A_4 = 1534 ( 1535 "Encrypt0", 1536 h'', 1537 TH_4 1538 ) 1540 A_4 (CBOR Data Item) (45 bytes) 1541 83 68 45 6e 63 72 79 70 74 30 40 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 1542 66 f7 c9 23 e6 6c 36 02 e2 56 57 b2 0a 8b 67 07 6d cc 92 aa d4 0b 1543 R constructs the input needed to derive the EDHOC message_4 key, see 1544 Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash algorithm: 1546 K_4 = EDHOC-Exporter("EDHOC_K_4", h'', length) 1547 = EDHOC-KDF(PRK_4x3m, TH_4, "EDHOC_K_4", h'', length) 1548 = HKDF-Expand(PRK_4x3m, info, length) 1550 where length is the key length of the EDHOC AEAD algorithm, and info 1551 for EDHOC_K_4 is: 1553 info = 1554 ( 1555 h'63FF46ADB9EB2F89ACED66F7C923E66C3602E25657B20A8B67076DCC92AAD40B', 1556 "EDHOC_K_4", 1557 h'', 1558 16 1559 ) 1561 where the last value is the key length of EDHOC AEAD algorithm. 1563 info for K_4 (CBOR Sequence) (46 bytes) 1564 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1565 b2 0a 8b 67 07 6d cc 92 aa d4 0b 69 45 44 48 4f 43 5f 4b 5f 34 40 10 1567 K_4 (Raw Value) (16 bytes) 1568 ee 55 a5 46 1b 2c 41 82 1b 1a be dc 03 b4 ef 50 1570 R constructs the input needed to derive the EDHOC message_4 nonce, 1571 see Section 4.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash 1572 algorithm: 1574 IV_4 = 1575 = EDHOC-Exporter( "EDHOC_IV_4", h'', length ) 1576 = EDHOC-KDF(PRK_4x3m, TH_4, "EDHOC_IV_4", h'', length) 1577 = HKDF-Expand(PRK_4x3m, info, length) 1579 where length is the nonce length of EDHOC AEAD algorithm, and info 1580 for EDHOC_IV_4 is: 1582 info = 1583 ( 1584 h'63FF46ADB9EB2F89ACED66F7C923E66C3602E25657B20A8B67076DCC92AAD40B', 1585 "EDHOC_IV_4", 1586 h'', 1587 13 1588 ) 1590 where the last value is the nonce length of EDHOC AEAD algorithm. 1592 info for IV_4 (CBOR Sequence) (47 bytes) 1593 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1594 b2 0a 8b 67 07 6d cc 92 aa d4 0b 6a 45 44 48 4f 43 5f 49 56 5f 34 40 1595 0d 1597 IV_4 (Raw Value) (13 bytes) 1598 cb 14 8d 0f 30 c5 ce 4a 6d 80 eb f3 6c 1600 R calculates CIPHERTEXT_4 as 'ciphertext' of COSE_Encrypt0 applied 1601 using the EDHOC AEAD algorithm with plaintext P_4, additional data 1602 A_4, key K_4 and nonce IV_4. 1604 CIPHERTEXT_4 (8 bytes) 1605 fc 4f 5e 2f 54 c2 d4 08 1607 message_4 is the CBOR bstr encoding of CIPHERTEXT_4: 1609 message_4 (CBOR Sequence) (9 bytes) 1610 48 fc 4f 5e 2f 54 c2 d4 08 1612 4.5. OSCORE Parameters 1614 The derivation of OSCORE parameters is specified in Appendix A.2 of 1615 [I-D.ietf-lake-edhoc]. 1617 The AEAD and Hash algorithms to use in OSCORE are given by the 1618 selected cipher suite: 1620 Application AEAD Algorithm (int) 1621 10 1623 Application Hash Algorithm (int) 1624 -16 1626 The mapping from EDHOC connection identifiers to OSCORE Sender/ 1627 Recipient IDs is defined in Appendix A.1 of [I-D.ietf-lake-edhoc]. 1629 C_R is mapped to the Recipient ID of the server, i.e., the Sender ID 1630 of the client. Since C_R is a numeric, it is converted to a byte 1631 string equal to its CBOR encoded form. 1633 Client's OSCORE Sender ID (Raw Value) (1 bytes) 1634 32 1636 C_I is mapped to the Recipient ID of the client, i.e., the Sender ID 1637 of the server. Since C_I is a numeric, it is converted to a byte 1638 string equal to its CBOR encoded form. 1640 Server's OSCORE Sender ID (Raw Value) (1 bytes) 1641 0e 1643 The OSCORE Master Secret is computed through Expand() using the 1644 Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]: 1646 OSCORE Master Secret = 1647 = EDHOC-Exporter("OSCORE_Master_Secret", h'', key_length) 1648 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE_Master_Secret", h'', key_length) 1649 = HKDF-Expand(PRK_4x3m, info, key_length) 1651 where key_length is by default the key length of the Application AEAD 1652 algorithm, and info for the OSCORE Master Secret is: 1654 info = 1655 ( 1656 h'63FF46ADB9EB2F89ACED66F7C923E66C3602E25657B20A8B67076DCC92AAD40B', 1657 "OSCORE_Master_Secret", 1658 h'', 1659 16 1660 ) 1662 where the last value is the key length of Application AEAD algorithm. 1664 info for OSCORE Master Secret (CBOR Sequence) (57 bytes) 1665 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1666 b2 0a 8b 67 07 6d cc 92 aa d4 0b 74 4f 53 43 4f 52 45 5f 4d 61 73 74 1667 65 72 5f 53 65 63 72 65 74 40 10 1669 OSCORE Master Secret (Raw Value) (16 bytes) 1670 01 4f df 73 06 7d fe fd 97 e6 b0 59 72 f9 0d 85 1672 The OSCORE Master Salt is computed through Expand() using the 1673 Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]: 1675 OSCORE Master Salt = 1676 = EDHOC-Exporter("OSCORE_Master_Salt", h'', salt_length) 1677 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE_Master_Salt", h'', salt_length) 1678 = HKDF-Expand(PRK_4x3m, info, salt_length) 1680 where salt_length is the length of the OSCORE Master Salt, and info 1681 for the OSCORE Master Salt is: 1683 info = 1684 ( 1685 h'63FF46ADB9EB2F89ACED66F7C923E66C3602E25657B20A8B67076DCC92AAD40B', 1686 "OSCORE_Master_Salt", 1687 h'', 1688 8 1689 ) 1691 where the last value is the length of the OSCORE Master Salt. 1693 info for OSCORE Master Salt (CBOR Sequence) (55 bytes) 1694 58 20 63 ff 46 ad b9 eb 2f 89 ac ed 66 f7 c9 23 e6 6c 36 02 e2 56 57 1695 b2 0a 8b 67 07 6d cc 92 aa d4 0b 72 4f 53 43 4f 52 45 5f 4d 61 73 74 1696 65 72 5f 53 61 6c 74 40 08 1698 OSCORE Master Salt (Raw Value) (8 bytes) 1699 cb 47 b6 ec d3 86 72 dd 1701 4.6. Key Update 1703 Key update is defined in Section 4.4 of [I-D.ietf-lake-edhoc]. 1705 EDHOC-KeyUpdate(nonce): 1706 PRK_4x3m = Extract(nonce, PRK_4x3m) 1708 KeyUpdate Nonce (Raw Value) (16 bytes) 1709 e6 f5 49 b8 58 1a a2 92 53 cf ce 68 07 53 a4 00 1711 PRK_4x3m after KeyUpdate (Raw Value) (32 bytes) 1712 26 78 00 73 f8 ce 0b eb 71 03 e0 c7 17 d1 6d db bb f6 7b b1 f0 77 53 1713 ca 97 df ec 34 73 23 47 4d 1715 The OSCORE Master Secret is derived with the updated PRK_4x3m: 1717 OSCORE Master Secret = HKDF-Expand(PRK_4x3m, info, key_length) 1719 where info and key_length are unchanged. 1721 OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes) 1722 8f 7c 42 12 d7 e4 2a 1c 5f bb 5d c6 2f d7 b7 f3 1724 The OSCORE Master Salt is derived with the updated PRK_4x3m: 1726 OSCORE Master Salt = HKDF-Expand(PRK_4x3m, info, salt_length) 1728 where info and salt_length are unchanged. 1730 OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes) 1731 87 eb 7d b2 fd cf a8 9c 1733 5. Security Considerations 1735 This document contains examples of EDHOC [I-D.ietf-lake-edhoc] whose 1736 security considerations apply. The keys printed in these examples 1737 cannot be considered secret and must not be used. 1739 6. IANA Considerations 1741 There are no IANA considerations. 1743 7. Informative References 1745 [CborMe] Bormann, C., "CBOR Playground", May 2018, 1746 . 1748 [I-D.ietf-lake-edhoc] 1749 Selander, G., Mattsson, J. P., and F. Palombini, 1750 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 1751 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 1752 October 2021, . 1755 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1756 Representation (CBOR)", STD 94, RFC 8949, 1757 DOI 10.17487/RFC8949, December 2020, 1758 . 1760 Acknowledgments 1762 Authors' Addresses 1764 Göran Selander 1765 Ericsson AB 1766 SE-164 80 Stockholm 1767 Sweden 1769 Email: goran.selander@ericsson.com 1771 John Preuß Mattsson 1772 Ericsson AB 1773 SE-164 80 Stockholm 1774 Sweden 1776 Email: john.mattsson@ericsson.com