idnits 2.17.1 draft-selander-ace-cose-ecdhe-14.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 121 instances of too long lines in the document, the longest one being 167 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2019) is 1688 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 (-16) exists of draft-ietf-cbor-7049bis-07 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' == Outdated reference: A later version (-02) exists of draft-ietf-cbor-sequence-01 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-05 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-03 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 6090 ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIGMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP-800-56A' == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-24 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-08 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-23 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-security-protocol-comparison-03 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-32 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Selander 3 Internet-Draft J. Mattsson 4 Intended status: Standards Track F. Palombini 5 Expires: March 14, 2020 Ericsson AB 6 September 11, 2019 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-selander-ace-cose-ecdhe-14 11 Abstract 13 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 14 very compact, and lightweight authenticated Diffie-Hellman key 15 exchange with ephemeral keys. EDHOC provides mutual authentication, 16 perfect forward secrecy, and identity protection. EDHOC is intended 17 for usage in constrained scenarios and a main use case is to 18 establish an OSCORE security context. By reusing COSE for 19 cryptography, CBOR for encoding, and CoAP for transport, the 20 additional code footprint can be kept very low. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 14, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Rationale for EDHOC . . . . . . . . . . . . . . . . . . . 4 58 1.2. Terminology and Requirements Language . . . . . . . . . . 5 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 9 62 3.2. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 9 63 3.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 9 64 4. EDHOC Authenticated with Asymmetric Keys . . . . . . . . . . 12 65 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 66 4.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 14 67 4.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 16 68 4.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 19 69 5. EDHOC Authenticated with Symmetric Keys . . . . . . . . . . . 21 70 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 71 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 22 72 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 23 73 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 23 74 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 24 75 6.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 24 76 7. Transferring EDHOC and Deriving Application Keys . . . . . . 25 77 7.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 25 78 7.2. Transferring EDHOC over Other Protocols . . . . . . . . . 28 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 80 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 28 81 8.2. Cryptographic Considerations . . . . . . . . . . . . . . 29 82 8.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 30 83 8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 30 84 8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 30 85 8.6. Implementation Considerations . . . . . . . . . . . . . . 31 86 8.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 32 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 88 9.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 32 89 9.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 32 90 9.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 33 91 9.4. Media Types Registry . . . . . . . . . . . . . . . . . . 33 92 9.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 34 93 9.6. Expert Review Instructions . . . . . . . . . . . . . . . 34 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 96 10.2. Informative References . . . . . . . . . . . . . . . . . 37 98 Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 39 99 A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 39 100 A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 40 101 Appendix B. EDHOC Authenticated withDiffie-Hellman Keys . . . . 40 102 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 41 103 C.1. Test Vectors for EDHOC Authenticated with Asymmetric Keys 104 (RPK) . . . . . . . . . . . . . . . . . . . . . . . . . . 41 105 C.2. Test Vectors for EDHOC Authenticated with Symmetric Keys 106 (PSK) . . . . . . . . . . . . . . . . . . . . . . . . . . 57 107 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 70 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 110 1. Introduction 112 Security at the application layer provides an attractive option for 113 protecting Internet of Things (IoT) deployments, for example where 114 transport layer security is not sufficient 115 [I-D.hartke-core-e2e-security-reqs] or where the protection needs to 116 work over a variety of underlying protocols. IoT devices may be 117 constrained in various ways, including memory, storage, processing 118 capacity, and energy [RFC7228]. A method for protecting individual 119 messages at the application layer suitable for constrained devices, 120 is provided by CBOR Object Signing and Encryption (COSE) [RFC8152]), 121 which builds on the Concise Binary Object Representation (CBOR) 122 [I-D.ietf-cbor-7049bis]. Object Security for Constrained RESTful 123 Environments (OSCORE) [RFC8613] is a method for application-layer 124 protection of the Constrained Application Protocol (CoAP), using 125 COSE. 127 In order for a communication session to provide forward secrecy, the 128 communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH) 129 key exchange protocol with ephemeral keys, from which shared key 130 material can be derived. This document specifies Ephemeral Diffie- 131 Hellman Over COSE (EDHOC), a lightweight key exchange protocol 132 providing perfect forward secrecy and identity protection. 133 Authentication is based on credentials established out of band, e.g. 134 from a trusted third party, such as an Authorization Server as 135 specified by [I-D.ietf-ace-oauth-authz]. EDHOC supports 136 authentication using pre-shared keys (PSK), raw public keys (RPK), 137 and public key certificates. After successful completion of the 138 EDHOC protocol, application keys and other application specific data 139 can be derived using the EDHOC-Exporter interface. A main use case 140 for EDHOC is to establish an OSCORE security context. EDHOC uses 141 COSE for cryptography, CBOR for encoding, and CoAP for transport. By 142 reusing existing libraries, the additional code footprint can be kept 143 very low. Note that this document focuses on authentication and key 144 establishment: for integration with authorization of resource access, 145 refer to [I-D.ietf-ace-oscore-profile]. 147 EDHOC is designed to work in highly constrained scenarios making it 148 especially suitable for network technologies such as Cellular IoT, 149 6TiSCH [I-D.ietf-6tisch-dtsecurity-zerotouch-join], and LoRaWAN 150 [LoRa1][LoRa2]. These network technologies are characterized by 151 their low throughput, low power consumption, and small frame sizes. 152 Compared to the DTLS 1.3 handshake [I-D.ietf-tls-dtls13] with ECDH 153 and connection ID, the number of bytes in EDHOC is less than 1/4 when 154 PSK authentication is used and less than 1/3 when RPK authentication 155 is used, see [I-D.ietf-lwig-security-protocol-comparison]. Typical 156 message sizes for EDHOC with pre-shared keys, raw public keys, and 157 X.509 certificates are shown in Figure 1. 159 ===================================================================== 160 PSK RPK x5t x5chain 161 --------------------------------------------------------------------- 162 message_1 40 38 38 38 163 message_2 45 114 126 116 + Certificate chain 164 message_3 11 80 91 81 + Certificate chain 165 --------------------------------------------------------------------- 166 Total 96 232 255 235 + Certificate chains 167 ===================================================================== 169 Figure 1: Typical message sizes in bytes 171 The ECDH exchange and the key derivation follow [SIGMA], NIST SP- 172 800-56A [SP-800-56A], and HKDF [RFC5869]. CBOR 173 [I-D.ietf-cbor-7049bis] and COSE [RFC8152] are used to implement 174 these standards. The use of COSE provides crypto agility and enables 175 use of future algorithms and headers designed for constrained IoT. 177 This document is organized as follows: Section 2 describes how EDHOC 178 builds on SIGMA-I, Section 3 specifies general properties of EDHOC, 179 including message flow, formatting of the ephemeral public keys, and 180 key derivation, Section 4 specifies EDHOC with asymmetric key 181 authentication, Section 5 specifies EDHOC with symmetric key 182 authentication, Section 6 specifies the EDHOC error message, and 183 Section 7 describes how EDHOC can be transferred in CoAP and used to 184 establish an OSCORE security context. 186 1.1. Rationale for EDHOC 188 Many constrained IoT systems today do not use any security at all, 189 and when they do, they often do not follow best practices. One 190 reason is that many current security protocols are not designed with 191 constrained IoT in mind. Constrained IoT systems often deal with 192 personal information, valuable business data, and actuators 193 interacting with the physical world. Not only do such systems need 194 security and privacy, they often need end-to-end protection with 195 source authentication and perfect forward secrecy. EDHOC and OSCORE 196 [RFC8613] enables security following current best practices to 197 devices and systems where current security protocols are impractical. 199 EDHOC is optimized for small message sizes and can therefore be sent 200 over a small number of radio frames. The message size of a key 201 exchange protocol may have a large impact on the performance of an 202 IoT deployment, especially in noisy environments. For example, in a 203 network bootstrapping setting a large number of devices turned on in 204 a short period of time may result in large latencies caused by 205 parallel key exchanges. Requirements on network formation time in 206 constrained environments can be translated into key exchange 207 overhead. In networks technologies with transmission back-off time, 208 each additional frame significantly increases the latency even if no 209 other devices are transmitting. 211 Power consumption for wireless devices is highly dependent on message 212 transmission, listening, and reception. For devices that only send a 213 few bytes occasionally, the battery lifetime may be significantly 214 reduced by a heavy key exchange protocol. Moreover, a key exchange 215 may need to be executed more than once, e.g. due to a device losing 216 power or rebooting for other reasons. 218 EDHOC is adapted to primitives and protocols designed for the 219 Internet of Things: EDHOC is built on CBOR and COSE which enables 220 small message overhead and efficient parsing in constrained devices. 221 EDHOC is not bound to a particular transport layer, but it is 222 recommended to transport the EDHOC message in CoAP payloads. EDHOC 223 is not bound to a particular communication security protocol but 224 works off-the-shelf with OSCORE [RFC8613] providing the necessary 225 input parameters with required properties. Maximum code complexity 226 (ROM/Flash) is often a constraint in many devices and by reusing 227 already existing libraries, the additional code footprint for EDHOC + 228 OSCORE can be kept very low. 230 1.2. Terminology and Requirements Language 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 234 "OPTIONAL" in this document are to be interpreted as described in BCP 235 14 [RFC2119] [RFC8174] when, and only when, they appear in all 236 capitals, as shown here. 238 The word "encryption" without qualification always refers to 239 authenticated encryption, in practice implemented with an 240 Authenticated Encryption with Additional Data (AEAD) algorithm, see 241 [RFC5116]. 243 Readers are expected to be familiar with the terms and concepts 244 described in CBOR [I-D.ietf-cbor-7049bis], COSE [RFC8152], and CDDL 245 [RFC8610]. The Concise Data Definition Language (CDDL) is used to 246 express CBOR data structures [I-D.ietf-cbor-7049bis]. Examples of 247 CBOR and CDDL are provided in Appendix A.1. 249 2. Background 251 SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a 252 large number of variants [SIGMA]. Like IKEv2 and (D)TLS 1.3 253 [RFC8446], EDHOC is built on a variant of the SIGMA protocol which 254 provide identity protection of the initiator (SIGMA-I), and like 255 (D)TLS 1.3, EDHOC implements the SIGMA-I variant as Sign-then-MAC. 256 The SIGMA-I protocol using an authenticated encryption algorithm is 257 shown in Figure 2. 259 Party U Party V 260 | G_X | 261 +-------------------------------------------------------->| 262 | | 263 | G_Y, AEAD( K_2; ID_CRED_V, Sig(V; CRED_V, G_X, G_Y) ) | 264 |<--------------------------------------------------------+ 265 | | 266 | AEAD( K_3; ID_CRED_U, Sig(U; CRED_U, G_Y, G_X) ) | 267 +-------------------------------------------------------->| 268 | | 270 Figure 2: Authenticated encryption variant of the SIGMA-I protocol. 272 The parties exchanging messages are called "U" and "V". They 273 exchange identities and ephemeral public keys, compute the shared 274 secret, and derive symmetric application keys. 276 o G_X and G_Y are the ECDH ephemeral public keys of U and V, 277 respectively. 279 o CRED_U and CRED_V are the credentials containing the public 280 authentication keys of U and V, respectively. 282 o ID_CRED_U and ID_CRED_V are data enabling the recipient party to 283 retrieve the credential of U and V, respectively. 285 o Sig(U; . ) and S(V; . ) denote signatures made with the private 286 authentication key of U and V, respectively. 288 o AEAD(K; . ) denotes authenticated encryption with additional data 289 using the key K derived from the shared secret. The authenticated 290 encryption MUST NOT be replaced by plain encryption, see 291 Section 8. 293 In order to create a "full-fledged" protocol some additional protocol 294 elements are needed. EDHOC adds: 296 o Explicit connection identifiers C_U, C_V chosen by U and V, 297 respectively, enabling the recipient to find the protocol state. 299 o Transcript hashes TH_2, TH_3, TH_4 used for key derivation and as 300 additional authenticated data. 302 o Computationally independent keys derived from the ECDH shared 303 secret and used for encryption of different messages. 305 o Verification of a common preferred cipher suite (AEAD algorithm, 306 ECDH algorithm, ECDH curve, signature algorithm): 308 * U lists supported cipher suites in order of preference 310 * V verifies that the selected cipher suite is the first 311 supported cipher suite 313 o Method types and error handling. 315 o Transport of opaque application defined data. 317 EDHOC is designed to encrypt and integrity protect as much 318 information as possible, and all symmetric keys are derived using as 319 much previous information as possible. EDHOC is furthermore designed 320 to be as compact and lightweight as possible, in terms of message 321 sizes, processing, and the ability to reuse already existing CBOR, 322 COSE, and CoAP libraries. 324 To simplify for implementors, the use of CBOR in EDHOC is summarized 325 in Appendix A and test vectors including CBOR diagnostic notation are 326 given in Appendix C. 328 3. EDHOC Overview 330 EDHOC consists of three flights (message_1, message_2, message_3) 331 that maps directly to the three messages in SIGMA-I, plus an EDHOC 332 error message. EDHOC messages are CBOR Sequences 333 [I-D.ietf-cbor-sequence], where the first data item of message_1 is 334 an int (TYPE) specifying the method (asymmetric, symmetric) and the 335 correlation properties of the transport used. 337 While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 338 structures, only a subset of the parameters is included in the EDHOC 339 messages. After creating EDHOC message_3, Party U can derive 340 symmetric application keys, and application protected data can 341 therefore be sent in parallel with EDHOC message_3. The application 342 may protect data using the algorithms (AEAD, HMAC, etc.) in the 343 selected cipher suite and the connection identifiers (C_U, C_V). 344 EDHOC may be used with the media type application/edhoc defined in 345 Section 9. 347 Party U Party V 348 | | 349 | ------------------ EDHOC message_1 -----------------> | 350 | | 351 | <----------------- EDHOC message_2 ------------------ | 352 | | 353 | ------------------ EDHOC message_3 -----------------> | 354 | | 355 | <----------- Application Protected Data ------------> | 356 | | 358 Figure 3: EDHOC message flow 360 The EDHOC message exchange may be authenticated using pre-shared keys 361 (PSK), raw public keys (RPK), or public key certificates. EDHOC 362 assumes the existence of mechanisms (certification authority, manual 363 distribution, etc.) for binding identities with authentication keys 364 (public or pre-shared). When a public key infrastructure is used, 365 the identity is included in the certificate and bound to the 366 authentication key by trust in the certification authority. When the 367 credential is manually distributed (PSK, RPK, self-signed 368 certificate), the identity and authentication key is distributed out- 369 of-band and bound together by trust in the distribution method. 370 EDHOC with symmetric key authentication is very similar to EDHOC with 371 asymmetric key authentication, the difference being that information 372 is only MACed, not signed, and that session keys are derived from the 373 ECDH shared secret and the PSK. 375 EDHOC allows opaque application data (UAD and PAD) to be sent in the 376 EDHOC messages. Unprotected Application Data (UAD_1, UAD_2) may be 377 sent in message_1 and message_2 and can be e.g. be used to transfer 378 access tokens that are protected outside of EDHOC. Protected 379 application data (PAD_3) may be used to transfer any application data 380 in message_3. 382 Cryptographically, EDHOC does not put requirements on the lower 383 layers. EDHOC is not bound to a particular transport layer, and can 384 be used in environments without IP. It is recommended to transport 385 the EDHOC message in CoAP payloads, see Section 7. An implementation 386 may support only Party U or only Party V. 388 3.1. Cipher Suites 390 EDHOC cipher suites consist of an ordered set of COSE algorithms: an 391 AEAD algorithm, an HMAC algorithm, an ECDH curve, a signature 392 algorithm, and signature algorithm parameters. The signature 393 algorithm is not used when EDHOC is authenticated with symmetric 394 keys. Each cipher suite is either identified with a pre-defined int 395 label or with an array of labels and values from the COSE Algorithms 396 and Elliptic Curves registries. 398 suite = int / [ 4*4 algs: int / tstr, ? para: any ] 400 This document specifies two pre-defined cipher suites. 402 0. [ 10, 5, 4, -8, 6 ] 403 (AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA, Ed25519) 405 1. [ 10, 5, 1, -7, 1 ] 406 (AES-CCM-16-64-128, HMAC 256/256, P-256, ES256, P-256) 408 3.2. Ephemeral Public Keys 410 The ECDH ephemeral public keys are formatted as a COSE_Key of type 411 EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only 412 the x-coordinate is included in the EDHOC messages. For Elliptic 413 Curve Keys of type EC2, compact representation as per [RFC6090] MAY 414 be used also in the COSE_Key. If the COSE implementation requires an 415 y-coordinate, any of the possible values of the y-coordinate can be 416 used, see Appendix C of [RFC6090]. COSE [RFC8152] always use compact 417 output for Elliptic Curve Keys of type EC2. 419 3.3. Key Derivation 421 Key and IV derivation SHALL be performed with HKDF [RFC5869] 422 following the specification in Section 11 of [RFC8152] using the HMAC 423 algorithm in the selected cipher suite. The pseudorandom key (PRK) 424 is derived using HKDF-Extract [RFC5869] 426 PRK = HKDF-Extract( salt, IKM ) 428 with the following input: 430 o The salt SHALL be the PSK when EDHOC is authenticated with 431 symmetric keys, and the empty byte string when EDHOC is 432 authenticated with asymmetric keys. The PSK is used as 'salt' to 433 simplify implementation. Note that [RFC5869] specifies that if 434 the salt is not provided, it is set to a string of zeros (see 435 Section 2.2 of [RFC5869]). For implementation purposes, not 436 providing the salt is the same as setting the salt to the empty 437 byte string. 439 o The input keying material (IKM) SHALL be the ECDH shared secret 440 G_XY as defined in Section 12.4.1 of [RFC8152]. When using the 441 curve25519, the ECDH shared secret is the output of the X25519 442 function [RFC7748]. 444 Example: Assuming use of HMAC 256/256 the extract phase of HKDF 445 produces a PRK as follows: 447 PRK = HMAC-SHA-256( salt, G_XY ) 449 where salt = 0x (the empty byte string) in the asymmetric case and 450 salt = PSK in the symmetric case. 452 The keys and IVs used in EDHOC are derived from PRK using HKDF-Expand 453 [RFC5869] 455 OKM = HKDF-Expand( PRK, info, L ) 457 where L is the length of output keying material (OKM) in bytes and 458 info is the CBOR encoding of a COSE_KDF_Context 460 info = [ 461 AlgorithmID, 462 [ null, null, null ], 463 [ null, null, null ], 464 [ keyDataLength, h'', other ] 465 ] 467 where 469 o AlgorithmID is an int or tstr, see below 471 o keyDataLength is a uint set to the length of output keying 472 material in bits, see below 474 o other is a bstr set to one of the transcript hashes TH_2, TH_3, or 475 TH_4 as defined in Sections 4.3.1, 4.4.1, and 3.3.1. 477 For message_2 and message_3, the keys K_2 and K_3 SHALL be derived 478 using transcript hashes TH_2 and TH_3 respectively. The key SHALL be 479 derived using AlgorithmID set to the integer value of the AEAD in the 480 selected cipher suite, and keyDataLength equal to the key length of 481 the AEAD. 483 If the AEAD algorithm uses an IV, then IV_2 and IV_3 for message_2 484 and message_3 SHALL be derived using the transcript hashes TH_2 and 485 TH_3 respectively. The IV SHALL be derived using AlgorithmID = "IV- 486 GENERATION" as specified in Section 12.1.2. of [RFC8152], and 487 keyDataLength equal to the IV length of the AEAD. 489 Assuming the output OKM length L is smaller than the hash function 490 output size, the expand phase of HKDF consists of a single HMAC 491 invocation 493 OKM = first L bytes of HMAC( PRK, info || 0x01 ) 495 where || means byte string concatenation. 497 Example: Assuming use of the algorithm AES-CCM-16-64-128 and HMAC 498 256/256, K_i and IV_i are therefore the first 16 and 13 bytes, 499 respectively, of 501 HMAC-SHA-256( PRK, info || 0x01 ) 503 calculated with (AlgorithmID, keyDataLength) = (10, 128) and 504 (AlgorithmID, keyDataLength) = ("IV-GENERATION", 104), respectively. 506 3.3.1. EDHOC-Exporter Interface 508 Application keys and other application specific data can be derived 509 using the EDHOC-Exporter interface defined as: 511 EDHOC-Exporter( label, length ) = HKDF-Expand( PRK, info, length ) 513 The output of the EDHOC-Exporter function SHALL be derived using 514 AlgorithmID = label, keyDataLength = 8 * length, and other = TH_4 515 where label is a tstr defined by the application and length is a uint 516 defined by the application. The label SHALL be different for each 517 different exporter value. The transcript hash TH_4 is a CBOR encoded 518 bstr and the input to the hash function is a CBOR Sequence. 520 TH_4 = H( TH_3, CIPHERTEXT_3 ) 522 where H() is the hash function in the HMAC algorithm. Example use of 523 the EDHOC-Exporter is given in Sections 3.3.2 and 7.1.1. 525 3.3.2. EDHOC PSK Chaining 527 An application using EDHOC may want to derive new PSKs to use for 528 authentication in future EDHOC exchanges. In this case, the new PSK 529 and the ID_PSK 'kid_value' parameter SHOULD be derived as follows 530 where length is the key length (in bytes) of the AEAD Algorithm. 532 PSK = EDHOC-Exporter( "EDHOC Chaining PSK", length ) 533 ID_PSK = EDHOC-Exporter( "EDHOC Chaining ID_PSK", 4 ) 535 4. EDHOC Authenticated with Asymmetric Keys 537 4.1. Overview 539 EDHOC supports authentication with raw public keys (RPK) and public 540 key certificates with the requirements that: 542 o Only Party V SHALL have access to the private authentication key 543 of Party V, 545 o Only Party U SHALL have access to the private authentication key 546 of Party U, 548 o Party U is able to retrieve Party V's public authentication key 549 using ID_CRED_V, 551 o Party V is able to retrieve Party U's public authentication key 552 using ID_CRED_U, 554 where the identifiers ID_CRED_U and ID_CRED_V are COSE header_maps, 555 i.e. a CBOR map containing COSE Common Header Parameters, see 556 [RFC8152]). ID_CRED_U and ID_CRED_V need to contain parameters that 557 can identify a public authentication key, see Appendix A.2. In the 558 following we give some examples of possible COSE header parameters. 560 Raw public keys are most optimally stored as COSE_Key objects and 561 identified with a 'kid' parameter (see [RFC8152]): 563 o ID_CRED_x = { 4 : kid_value }, where kid_value : bstr, for x = U 564 or V. 566 Public key certificates can be identified in different ways. Several 567 header parameters for identifying X.509 certificates are defined in 568 [I-D.ietf-cose-x509] (the exact labels are TBD): 570 o by a hash value with the 'x5t' parameter; 572 * ID_CRED_x = { TBD1 : COSE_CertHash }, for x = U or V, 574 o by a URL with the 'x5u' parameter; 576 * ID_CRED_x = { TBD2 : uri }, for x = U or V, 578 o or by a bag of certificates with the 'x5bag' parameter; 580 * ID_CRED_x = { TBD3 : COSE_X509 }, for x = U or V. 582 o by a certificate chain with the 'x5chain' parameter; 584 * ID_CRED_x = { TBD4 : COSE_X509 }, for x = U or V, 586 In the latter two examples, ID_CRED_U and ID_CRED_V contain the 587 actual credential used for authentication. The purpose of ID_CRED_U 588 and ID_CRED_V is to facilitate retrieval of a public authentication 589 key and when they do not contain the actual credential, they may be 590 very short. It is RECOMMENDED that they uniquely identify the public 591 authentication key as the recipient may otherwise have to try several 592 keys. ID_CRED_U and ID_CRED_V are transported in the ciphertext, see 593 Section 4.3.2 and Section 4.4.2. 595 The actual credentials CRED_U and CRED_V (e.g. a COSE_Key or a single 596 X.509 certificate) are signed by party U and V, respectively to 597 prevent duplicate-signature key selection (DSKS) attacks, see 598 Section 4.4.1 and Section 4.3.1. Party U and Party V MAY use 599 different types of credentials, e.g. one uses RPK and the other uses 600 certificate. When included in the signature payload, COSE_Keys of 601 type OKP SHALL only include the parameters 1 (kty), -1 (crv), and -2 602 (x-coordinate). COSE_Keys of type EC2 SHALL only include the 603 parameters 1 (kty), -1 (crv), -2 (x-coordinate), and -3 604 (y-coordinate). The parameters SHALL be encoded in decreasing order. 606 The connection identifiers C_U and C_V do not have any cryptographic 607 purpose in EDHOC. They contain information facilitating retrieval of 608 the protocol state and may therefore be very short. The connection 609 identifier MAY be used with an application protocol (e.g. OSCORE) 610 for which EDHOC establishes keys, in which case the connection 611 identifiers SHALL adhere to the requirements for that protocol. Each 612 party choses a connection identifier it desires the other party to 613 use in outgoing messages. 615 The first data item of message_1 is an int TYPE = 4 * method + corr 616 specifying the method and the correlation properties of the transport 617 used. corr = 0 is used when there is no external correlation 618 mechanism. corr = 1 is used when there is an external correlation 619 mechanism (e.g. the Token in CoAP) that enables Party U to correlate 620 message_1 and message_2. corr = 2 is used when there is an external 621 correlation mechanism that enables Party V to correlate message_2 and 622 message_3. corr = 3 is used when there is an external correlation 623 mechanism that enables the parties to correlate all the messages. 624 The use of the correlation parameter is exemplified in Section 7.1. 626 1 byte connection and credential identifiers are realistic in many 627 scenarios as most constrained devices only have a few keys and 628 connections. In cases where a node only has one connection or key, 629 the identifiers may even be the empty byte string. 631 EDHOC with asymmetric key authentication is illustrated in Figure 4. 633 Party U Party V 634 | TYPE, SUITES_U, G_X, C_U, UAD_1 | 635 +------------------------------------------------------------------>| 636 | message_1 | 637 | | 638 | C_U, G_Y, C_V, AEAD(K_2; ID_CRED_V, Sig(V; CRED_V, TH_2), UAD_2) | 639 |<------------------------------------------------------------------+ 640 | message_2 | 641 | | 642 | C_V, AEAD(K_3; ID_CRED_U, Sig(U; CRED_U, TH_3), PAD_3) | 643 +------------------------------------------------------------------>| 644 | message_3 | 646 Figure 4: Overview of EDHOC with asymmetric key authentication. 648 4.2. EDHOC Message 1 650 4.2.1. Formatting of Message 1 652 message_1 SHALL be a CBOR Sequence (see Appendix A.1) as defined 653 below 655 message_1 = ( 656 TYPE : int, 657 SUITES_U : suite / [ index : uint, 2* suite ], 658 G_X : bstr, 659 C_U : bstr, 660 ? UAD_1 : bstr, 661 ) 663 where: 665 o TYPE = 4 * method + corr, where the method = 0 and the correlation 666 parameter corr is chosen based on the transport and determines 667 which connection identifiers that are omitted (see Section 4.1). 669 o SUITES_U - cipher suites which Party U supports in order of 670 decreasing preference. One cipher suite is selected. If a single 671 cipher suite is conveyed then that cipher suite is selected. If 672 multiple cipher suites are conveyed then zero-based index (i.e. 0 673 for the first suite, 1 for the second suite, etc.) identifies the 674 selected cipher suite out of the array elements listing the cipher 675 suites (see Section 6). 677 o G_X - the x-coordinate of the ephemeral public key of Party U 679 o C_U - variable length connection identifier 681 o UAD_1 - bstr containing unprotected opaque application data 683 4.2.2. Party U Processing of Message 1 685 Party U SHALL compose message_1 as follows: 687 o The supported cipher suites and the order of preference MUST NOT 688 be changed based on previous error messages. However, the list 689 SUITES_U sent to Party V MAY be truncated such that cipher suites 690 which are the least preferred are omitted. The amount of 691 truncation MAY be changed between sessions, e.g. based on previous 692 error messages (see next bullet), but all cipher suites which are 693 more preferred than the least preferred cipher suite in the list 694 MUST be included in the list. 696 o Determine the cipher suite to use with Party V in message_1. If 697 Party U previously received from Party V an error message to 698 message_1 with diagnostic payload identifying a cipher suite that 699 U supports, then U SHALL use that cipher suite. Otherwise the 700 first cipher suite in SUITES_U MUST be used. 702 o Generate an ephemeral ECDH key pair as specified in Section 5 of 703 [SP-800-56A] using the curve in the selected cipher suite. Let 704 G_X be the x-coordinate of the ephemeral public key. 706 o Choose a connection identifier C_U and store it for the length of 707 the protocol. 709 o Encode message_1 as a sequence of CBOR encoded data items as 710 specified in Section 4.2.1 712 4.2.3. Party V Processing of Message 1 714 Party V SHALL process message_1 as follows: 716 o Decode message_1 (see Appendix A.1). 718 o Verify that the selected cipher suite is supported and that no 719 prior cipher suites in SUITES_U are supported. 721 o Validate that there is a solution to the curve definition for the 722 given x-coordinate G_X. 724 o Pass UAD_1 to the application. 726 If any verification step fails, Party V MUST send an EDHOC error 727 message back, formatted as defined in Section 6, and the protocol 728 MUST be discontinued. If V does not support the selected cipher 729 suite, then SUITES_V MUST include one or more supported cipher 730 suites. If V does not support the selected cipher suite, but 731 supports another cipher suite in SUITES_U, then SUITES_V MUST include 732 the first supported cipher suite in SUITES_U. 734 4.3. EDHOC Message 2 736 4.3.1. Formatting of Message 2 738 message_2 and data_2 SHALL be CBOR Sequences (see Appendix A.1) as 739 defined below 741 message_2 = ( 742 data_2, 743 CIPHERTEXT_2 : bstr, 744 ) 746 data_2 = ( 747 ? C_U : bstr, 748 G_Y : bstr, 749 C_V : bstr, 750 ) 752 where: 754 o G_Y - the x-coordinate of the ephemeral public key of Party V 756 o C_V - variable length connection identifier 758 4.3.2. Party V Processing of Message 2 760 Party V SHALL compose message_2 as follows: 762 o If TYPE mod 4 equals 1 or 3, C_U is omitted, otherwise C_U is not 763 omitted. 765 o Generate an ephemeral ECDH key pair as specified in Section 5 of 766 [SP-800-56A] using the curve in the selected cipher suite. Let 767 G_Y be the x-coordinate of the ephemeral public key. 769 o Choose a connection identifier C_V and store it for the length of 770 the protocol. 772 o Compute the transcript hash TH_2 = H( message_1, data_2 ) where 773 H() is the hash function in the HMAC algorithm. The transcript 774 hash TH_2 is a CBOR encoded bstr and the input to the hash 775 function is a CBOR Sequence. 777 o Compute COSE_Sign1 as defined in Section 4.4 of [RFC8152], using 778 the signature algorithm in the selected cipher suite, the private 779 authentication key of Party V, and the parameters below. Note 780 that only 'signature' of the COSE_Sign1 object is used to create 781 message_2, see next bullet. The unprotected header (not included 782 in the EDHOC message) MAY contain parameters (e.g. 'alg'). 784 * protected = bstr .cbor ID_CRED_V 786 * payload = CRED_V 788 * external_aad = TH_2 790 * ID_CRED_V - identifier to facilitate retrieval of CRED_V, see 791 Section 4.1 793 * CRED_V - bstr credential containing the credential of Party V, 794 e.g. its public authentication key or X.509 certificate see 795 Section 4.1. The public key must be a signature key. Note 796 that if objects that are not bstr are used, such as COSE_Key 797 for public authentication keys, these objects must be wrapped 798 in a CBOR bstr. 800 COSE constructs the input to the Signature Algorithm as follows: 802 * The key is the private authentication key of V. 804 * The message M to be signed is the CBOR encoding of: 806 [ "Signature1", << ID_CRED_V >>, TH_2, CRED_V ] 808 o Compute COSE_Encrypt0 as defined in Section 5.3 of [RFC8152], with 809 the AEAD algorithm in the selected cipher suite, K_2, IV_2, and 810 the parameters below. Note that only 'ciphertext' of the 811 COSE_Encrypt0 object is used to create message_2, see next bullet. 812 The protected header SHALL be empty. The unprotected header (not 813 included in the EDHOC message) MAY contain parameters (e.g. 814 'alg'). 816 * plaintext = ( ID_CRED_V / kid_value, signature, ? UAD_2 ) 818 * external_aad = TH_2 820 * UAD_2 = bstr containing opaque unprotected application data 822 where signature is taken from the COSE_Sign1 object, ID_CRED_V is 823 a COSE header_map (i.e. a CBOR map containing COSE Common Header 824 Parameters, see [RFC8152]), and kid_value is a bstr. If ID_CRED_V 825 contains a single 'kid' parameter, i.e., ID_CRED_V = { 4 : 826 kid_value }, only kid_value is conveyed in the plaintext. 828 COSE constructs the input to the AEAD [RFC5116] as follows: 830 * Key K = K_2 832 * Nonce N = IV_2 834 * Plaintext P = ( ID_CRED_V / kid_value, signature, ? UAD_2 ) 836 * Associated data A = [ "Encrypt0", h'', TH_2 ] 838 o Encode message_2 as a sequence of CBOR encoded data items as 839 specified in Section 4.3.1. CIPHERTEXT_2 is the COSE_Encrypt0 840 ciphertext. 842 4.3.3. Party U Processing of Message 2 844 Party U SHALL process message_2 as follows: 846 o Decode message_2 (see Appendix A.1). 848 o Retrieve the protocol state using the connection identifier C_U 849 and/or other external information such as the CoAP Token and the 850 5-tuple. 852 o Validate that there is a solution to the curve definition for the 853 given x-coordinate G_Y. 855 o Decrypt and verify COSE_Encrypt0 as defined in Section 5.3 of 856 [RFC8152], with the AEAD algorithm in the selected cipher suite, 857 K_2, and IV_2. 859 o Verify COSE_Sign1 as defined in Section 4.4 of [RFC8152], using 860 the signature algorithm in the selected cipher suite and the 861 public authentication key of Party V. 863 If any verification step fails, Party U MUST send an EDHOC error 864 message back, formatted as defined in Section 6, and the protocol 865 MUST be discontinued. 867 4.4. EDHOC Message 3 869 4.4.1. Formatting of Message 3 871 message_3 and data_3 SHALL be CBOR Sequences (see Appendix A.1) as 872 defined below 874 message_3 = ( 875 data_3, 876 CIPHERTEXT_3 : bstr, 877 ) 879 data_3 = ( 880 ? C_V : bstr, 881 ) 883 4.4.2. Party U Processing of Message 3 885 Party U SHALL compose message_3 as follows: 887 o If TYPE mod 4 equals 2 or 3, C_V is omitted, otherwise C_V is not 888 omitted. 890 o Compute the transcript hash TH_3 = H( TH_2 , CIPHERTEXT_2, data_3 891 ) where H() is the hash function in the HMAC algorithm. The 892 transcript hash TH_3 is a CBOR encoded bstr and the input to the 893 hash function is a CBOR Sequence. 895 o Compute COSE_Sign1 as defined in Section 4.4 of [RFC8152], using 896 the signature algorithm in the selected cipher suite, the private 897 authentication key of Party U, and the parameters below. Note 898 that only 'signature' of the COSE_Sign1 object is used to create 899 message_3, see next bullet. The unprotected header (not included 900 in the EDHOC message) MAY contain parameters (e.g. 'alg'). 902 * protected = bstr .cbor ID_CRED_U 904 * payload = CRED_U 906 * external_aad = TH_3 907 * ID_CRED_U - identifier to facilitate retrieval of CRED_U, see 908 Section 4.1 910 * CRED_U - bstr credential containing the credential of Party U, 911 e.g. its public authentication key or X.509 certificate see 912 Section 4.1. The public key must be a signature key. Note 913 that if objects that are not bstr are used, such as COSE_Key 914 for public authentication keys, these objects must be wrapped 915 in a CBOR bstr. 917 COSE constructs the input to the Signature Algorithm as follows: 919 * The key is the private authentication key of U. 921 * The message M to be signed is the CBOR encoding of: 923 [ "Signature1", << ID_CRED_U >>, TH_3, CRED_U ] 925 o Compute COSE_Encrypt0 as defined in Section 5.3 of [RFC8152], with 926 the AEAD algorithm in the selected cipher suite, K_3, and IV_3 and 927 the parameters below. Note that only 'ciphertext' of the 928 COSE_Encrypt0 object is used to create message_3, see next bullet. 929 The protected header SHALL be empty. The unprotected header (not 930 included in the EDHOC message) MAY contain parameters (e.g. 931 'alg'). 933 * plaintext = ( ID_CRED_U / kid_value, signature, ? PAD_3 ) 935 * external_aad = TH_3 937 * PAD_3 = bstr containing opaque protected application data 939 where signature is taken from the COSE_Sign1 object, ID_CRED_U is 940 a COSE header_map (i.e. a CBOR map containing COSE Common Header 941 Parameters, see [RFC8152]), and kid_value is a bstr. If ID_CRED_U 942 contains a single 'kid' parameter, i.e., ID_CRED_U = { 4 : 943 kid_value }, only kid_value is conveyed in the plaintext. 945 COSE constructs the input to the AEAD [RFC5116] as follows: 947 * Key K = K_3 949 * Nonce N = IV_2 951 * Plaintext P = ( ID_CRED_U / kid_value, signature, ? PAD_3 ) 953 * Associated data A = [ "Encrypt0", h'', TH_3 ] 955 o Encode message_3 as a sequence of CBOR encoded data items as 956 specified in Section 4.4.1. CIPHERTEXT_3 is the COSE_Encrypt0 957 ciphertext. 959 o Pass the connection identifiers (C_U, C_V) and the selected cipher 960 suite to the application. The application can now derive 961 application keys using the EDHOC-Exporter interface. 963 4.4.3. Party V Processing of Message 3 965 Party V SHALL process message_3 as follows: 967 o Decode message_3 (see Appendix A.1). 969 o Retrieve the protocol state using the connection identifier C_V 970 and/or other external information such as the CoAP Token and the 971 5-tuple. 973 o Decrypt and verify COSE_Encrypt0 as defined in Section 5.3 of 974 [RFC8152], with the AEAD algorithm in the selected cipher suite, 975 K_3, and IV_3. 977 o Verify COSE_Sign1 as defined in Section 4.4 of [RFC8152], using 978 the signature algorithm in the selected cipher suite and the 979 public authentication key of Party U. 981 If any verification step fails, Party V MUST send an EDHOC error 982 message back, formatted as defined in Section 6, and the protocol 983 MUST be discontinued. 985 o Pass PAD_3, the connection identifiers (C_U, C_V), and the 986 selected cipher suite to the application. The application can now 987 derive application keys using the EDHOC-Exporter interface. 989 5. EDHOC Authenticated with Symmetric Keys 991 5.1. Overview 993 EDHOC supports authentication with pre-shared keys. Party U and V 994 are assumed to have a pre-shared key (PSK) with a good amount of 995 randomness and the requirement that: 997 o Only Party U and Party V SHALL have access to the PSK, 999 o Party V is able to retrieve the PSK using ID_PSK. 1001 where the identifier ID_PSK is a COSE header_map (i.e. a CBOR map 1002 containing COSE Common Header Parameters, see [RFC8152]) containing 1003 COSE header parameter that can identify a pre-shared key. Pre-shared 1004 keys are typically stored as COSE_Key objects and identified with a 1005 'kid' parameter (see [RFC8152]): 1007 o ID_PSK = { 4 : kid_value } , where kid_value : bstr 1009 The purpose of ID_PSK is to facilitate retrieval of the PSK and in 1010 the case a 'kid' parameter is used it may be very short. It is 1011 RECOMMENDED that it uniquely identify the PSK as the recipient may 1012 otherwise have to try several keys. 1014 EDHOC with symmetric key authentication is illustrated in Figure 5. 1016 Party U Party V 1017 | TYPE, SUITES_U, G_X, C_U, ID_PSK, UAD_1 | 1018 +------------------------------------------------------------------>| 1019 | message_1 | 1020 | | 1021 | C_U, G_Y, C_V, AEAD(K_2; TH_2, UAD_2) | 1022 |<------------------------------------------------------------------+ 1023 | message_2 | 1024 | | 1025 | C_V, AEAD(K_3; TH_3, PAD_3) | 1026 +------------------------------------------------------------------>| 1027 | message_3 | 1029 Figure 5: Overview of EDHOC with symmetric key authentication. 1031 EDHOC with symmetric key authentication is very similar to EDHOC with 1032 asymmetric key authentication. In the following subsections the 1033 differences compared to EDHOC with asymmetric key authentication are 1034 described. 1036 5.2. EDHOC Message 1 1038 5.2.1. Formatting of Message 1 1040 message_1 SHALL be a CBOR Sequence (see Appendix A.1) as defined 1041 below 1043 message_1 = ( 1044 TYPE : int, 1045 SUITES_U : suite / [ index : uint, 2* suite ], 1046 G_X : bstr, 1047 C_U : bstr, 1048 ID_PSK : header_map // kid_value : bstr, 1049 ? UAD_1 : bstr, 1050 ) 1051 where: 1053 o TYPE = 4 * method + corr, where the method = 1 and the connection 1054 parameter corr is chosen based on the transport and determines 1055 which connection identifiers that are omitted (see Section 4.1). 1057 o ID_PSK - identifier to facilitate retrieval of the pre-shared key. 1058 If ID_PSK contains a single 'kid' parameter, i.e., ID_PSK = { 4 : 1059 kid_value }, with kid_value: bstr, only kid_value is conveyed. 1061 5.3. EDHOC Message 2 1063 5.3.1. Processing of Message 2 1065 o COSE_Sign1 is not used. 1067 o COSE_Encrypt0 is computed as defined in Section 5.3 of [RFC8152], 1068 with the AEAD algorithm in the selected cipher suite, K_2, IV_2, 1069 and the following parameters. The protected header SHALL be 1070 empty. The unprotected header MAY contain parameters (e.g. 1071 'alg'). 1073 * external_aad = TH_2 1075 * plaintext = ? UAD_2 1077 * UAD_2 = bstr containing opaque unprotected application data 1079 5.4. EDHOC Message 3 1081 5.4.1. Processing of Message 3 1083 o COSE_Sign1 is not used. 1085 o COSE_Encrypt0 is computed as defined in Section 5.3 of [RFC8152], 1086 with the AEAD algorithm in the selected cipher suite, K_3, IV_3, 1087 and the following parameters. The protected header SHALL be 1088 empty. The unprotected header MAY contain parameters (e.g. 1089 'alg'). 1091 * external_aad = TH_3 1093 * plaintext = ? PAD_3 1095 * PAD_3 = bstr containing opaque protected application data 1097 6. Error Handling 1099 6.1. EDHOC Error Message 1101 This section defines a message format for the EDHOC error message, 1102 used during the protocol. An EDHOC error message can be sent by both 1103 parties as a reply to any non-error EDHOC message. After sending an 1104 error message, the protocol MUST be discontinued. Errors at the 1105 EDHOC layer are sent as normal successful messages in the lower 1106 layers (e.g. CoAP POST and 2.04 Changed). An advantage of using 1107 such a construction is to avoid issues created by usage of cross 1108 protocol proxies (e.g. UDP to TCP). 1110 error SHALL be a CBOR Sequence (see Appendix A.1) as defined below 1112 error = ( 1113 ? C_x : bstr, 1114 ERR_MSG : tstr, 1115 ? SUITES_V : suite / [ 2* suite ], 1116 ) 1118 where: 1120 o C_x - if error is sent by Party V and TYPE mod 4 equals 0 or 2 1121 then C_x is set to C_U, else if error is sent by Party U and TYPE 1122 mod 4 equals 0 or 1 then C_x is set to C_V, else C_x is omitted. 1124 o ERR_MSG - text string containing the diagnostic payload, defined 1125 in the same way as in Section 5.5.2 of [RFC7252]. ERR_MSG MAY be 1126 a 0-length text string. 1128 o SUITES_V - cipher suites from SUITES_U or the EDHOC cipher suites 1129 registry that V supports. Note that SUITES_V only contains the 1130 values from the EDHOC cipher suites registry and no index. 1131 SUITES_V MUST only be included in replies to message_1. 1133 6.1.1. Example Use of EDHOC Error Message with SUITES_V 1135 Assuming that Party U supports the five cipher suites {5, 6, 7, 8, 9} 1136 in decreasing order of preference, Figures 6 and 7 show examples of 1137 how Party U can truncate SUITES_U and how SUITES_V is used by Party V 1138 to give Party U information about the cipher suites that Party V 1139 supports. In Figure 6, Party V supports cipher suite 6 but not the 1140 selected cipher suite 5. 1142 Party U Party V 1143 | TYPE, SUITES_U {0, 5, 6, 7}, G_X, C_U, UAD_1 | 1144 +------------------------------------------------------------------>| 1145 | message_1 | 1146 | | 1147 | C_U, ERR_MSG, SUITES_V {6} | 1148 |<------------------------------------------------------------------+ 1149 | error | 1150 | | 1151 | TYPE, SUITES_U {1, 5, 6}, G_X, C_U, UAD_1 | 1152 +------------------------------------------------------------------>| 1153 | message_1 | 1155 Figure 6: Example use of error message with SUITES_V. 1157 In Figure 7, Party V supports cipher suite 7 but not cipher suites 5 1158 and 6. 1160 Party U Party V 1161 | TYPE, SUITES_U {0, 5, 6}, G_X, C_U, UAD_1 | 1162 +------------------------------------------------------------------>| 1163 | message_1 | 1164 | | 1165 | C_U, ERR_MSG, SUITES_V {7, 9} | 1166 |<------------------------------------------------------------------+ 1167 | error | 1168 | | 1169 | TYPE, SUITES_U {2, 5, 6, 7}, G_X, C_U, UAD_1 | 1170 +------------------------------------------------------------------>| 1171 | message_1 | 1173 Figure 7: Example use of error message with SUITES_V. 1175 As Party U's list of supported cipher suites and order of preference 1176 is fixed, and Party V only accepts message_1 if the selected cipher 1177 suite is the first cipher suite in SUITES_U that Party V supports, 1178 the parties can verify that the selected cipher suite is the most 1179 preferred (by Party U) cipher suite supported by both parties. If 1180 the selected cipher suite is not the first cipher suite in SUITES_U 1181 that Party V supports, Party V will discontinue the protocol. 1183 7. Transferring EDHOC and Deriving Application Keys 1185 7.1. Transferring EDHOC in CoAP 1187 It is recommended to transport EDHOC as an exchange of CoAP [RFC7252] 1188 messages. CoAP is a reliable transport that can preserve packet 1189 ordering and handle message duplication. CoAP can also perform 1190 fragmentation and protect against denial of service attacks. It is 1191 recommended to carry the EDHOC flights in Confirmable messages, 1192 especially if fragmentation is used. 1194 By default, the CoAP client is Party U and the CoAP server is Party 1195 V, but the roles SHOULD be chosen to protect the most sensitive 1196 identity, see Section 8. By default, EDHOC is transferred in POST 1197 requests and 2.04 (Changed) responses to the Uri-Path: "/.well-known/ 1198 edhoc", but an application may define its own path that can be 1199 discovered e.g. using resource directory 1200 [I-D.ietf-core-resource-directory]. 1202 By default, the message flow is as follows: EDHOC message_1 is sent 1203 in the payload of a POST request from the client to the server's 1204 resource for EDHOC. EDHOC message_2 or the EDHOC error message is 1205 sent from the server to the client in the payload of a 2.04 (Changed) 1206 response. EDHOC message_3 or the EDHOC error message is sent from 1207 the client to the server's resource in the payload of a POST request. 1208 If needed, an EDHOC error message is sent from the server to the 1209 client in the payload of a 2.04 (Changed) response. 1211 An example of a successful EDHOC exchange using CoAP is shown in 1212 Figure 8. In this case the CoAP Token enables Party U to correlate 1213 message_1 and message_2 so the correlation parameter corr = 1. 1215 Client Server 1216 | | 1217 +--------->| Header: POST (Code=0.02) 1218 | POST | Uri-Path: "/.well-known/edhoc" 1219 | | Content-Format: application/edhoc 1220 | | Payload: EDHOC message_1 1221 | | 1222 |<---------+ Header: 2.04 Changed 1223 | 2.04 | Content-Format: application/edhoc 1224 | | Payload: EDHOC message_2 1225 | | 1226 +--------->| Header: POST (Code=0.02) 1227 | POST | Uri-Path: "/.well-known/edhoc" 1228 | | Content-Format: application/edhoc 1229 | | Payload: EDHOC message_3 1230 | | 1231 |<---------+ Header: 2.04 Changed 1232 | 2.04 | 1233 | | 1235 Figure 8: Transferring EDHOC in CoAP 1237 The exchange in Figure 8 protects the client identity against active 1238 attackers and the server identity against passive attackers. An 1239 alternative exchange that protects the server identity against active 1240 attackers and the client identity against passive attackers is shown 1241 in Figure 9. In this case the CoAP Token enables Party V to 1242 correlate message_2 and message_3 so the correlation parameter corr = 1243 2. 1245 Client Server 1246 | | 1247 +--------->| Header: POST (Code=0.02) 1248 | POST | Uri-Path: "/.well-known/edhoc" 1249 | | 1250 |<---------+ Header: 2.04 Changed 1251 | 2.04 | Content-Format: application/edhoc 1252 | | Payload: EDHOC message_1 1253 | | 1254 +--------->| Header: POST (Code=0.02) 1255 | POST | Uri-Path: "/.well-known/edhoc" 1256 | | Content-Format: application/edhoc 1257 | | Payload: EDHOC message_2 1258 | | 1259 |<---------+ Header: 2.04 Changed 1260 | 2.04 | Content-Format: application/edhoc 1261 | | Payload: EDHOC message_3 1262 | | 1264 Figure 9: Transferring EDHOC in CoAP 1266 To protect against denial-of-service attacks, the CoAP server MAY 1267 respond to the first POST request with a 4.01 (Unauthorized) 1268 containing an Echo option [I-D.ietf-core-echo-request-tag]. This 1269 forces the initiator to demonstrate its reachability at its apparent 1270 network address. If message fragmentation is needed, the EDHOC 1271 messages may be fragmented using the CoAP Block-Wise Transfer 1272 mechanism [RFC7959]. 1274 7.1.1. Deriving an OSCORE Context from EDHOC 1276 When EDHOC is used to derive parameters for OSCORE [RFC8613], the 1277 parties must make sure that the EDHOC connection identifiers are 1278 unique, i.e. C_V MUST NOT be equal to C_U. The CoAP client and 1279 server MUST be able to retrieve the OSCORE protocol state using its 1280 chosen connection identifier and optionally other information such as 1281 the 5-tuple. In case that the CoAP client is party U and the CoAP 1282 server is party V: 1284 o The client's OSCORE Sender ID is C_V and the server's OSCORE 1285 Sender ID is C_U, as defined in this document 1287 o The AEAD Algorithm and the HMAC algorithms are the AEAD and HMAC 1288 algorithms in the selected cipher suite. 1290 o The Master Secret and Master Salt are derived as follows where 1291 length is the key length (in bytes) of the AEAD Algorithm. 1293 Master Secret = EDHOC-Exporter( "OSCORE Master Secret", length ) 1294 Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 ) 1296 7.2. Transferring EDHOC over Other Protocols 1298 EDHOC may be transported over a different transport than CoAP. In 1299 this case the lower layers need to handle message loss, reordering, 1300 message duplication, fragmentation, and denial of service protection. 1302 8. Security Considerations 1304 8.1. Security Properties 1306 EDHOC inherits its security properties from the theoretical SIGMA-I 1307 protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides 1308 perfect forward secrecy, mutual authentication with aliveness, 1309 consistency, peer awareness, and identity protection. As described 1310 in [SIGMA], peer awareness is provided to Party V, but not to Party 1311 U. EDHOC also inherits Key Compromise Impersonation (KCI) resistance 1312 from SIGMA-I. 1314 EDHOC with asymmetric authentication offers identity protection of 1315 Party U against active attacks and identity protection of Party V 1316 against passive attacks. The roles should be assigned to protect the 1317 most sensitive identity, typically that which is not possible to 1318 infer from routing information in the lower layers. 1320 Compared to [SIGMA], EDHOC adds an explicit method type and expands 1321 the message authentication coverage to additional elements such as 1322 algorithms, application data, and previous messages. This protects 1323 against an attacker replaying messages or injecting messages from 1324 another session. 1326 EDHOC also adds negotiation of connection identifiers and downgrade 1327 protected negotiation of cryptographic parameters, i.e. an attacker 1328 cannot affect the negotiated parameters. A single session of EDHOC 1329 does not include negotiation of cipher suites, but it enables Party V 1330 to verify that the selected cipher suite is the most preferred cipher 1331 suite by U which is supported by both U and V. 1333 As required by [RFC7258], IETF protocols need to mitigate pervasive 1334 monitoring when possible. One way to mitigate pervasive monitoring 1335 is to use a key exchange that provides perfect forward secrecy. 1336 EDHOC therefore only supports methods with perfect forward secrecy. 1337 To limit the effect of breaches, it is important to limit the use of 1338 symmetrical group keys for bootstrapping. EDHOC therefore strives to 1339 make the additional cost of using raw public keys and self-signed 1340 certificates as small as possible. Raw public keys and self-signed 1341 certificates are not a replacement for a public key infrastructure, 1342 but SHOULD be used instead of symmetrical group keys for 1343 bootstrapping. 1345 Compromise of the long-term keys (PSK or private authentication keys) 1346 does not compromise the security of completed EDHOC exchanges. 1347 Compromising the private authentication keys of one party lets the 1348 attacker impersonate that compromised party in EDHOC exchanges with 1349 other parties, but does not let the attacker impersonate other 1350 parties in EDHOC exchanges with the compromised party. Compromising 1351 the PSK lets the attacker impersonate Party U in EDHOC exchanges with 1352 Party V and impersonate Party V in EDHOC exchanges with Party U. 1353 Compromise of the HDKF input parameters (ECDH shared secret and/or 1354 PSK) leads to compromise of all session keys derived from that 1355 compromised shared secret. Compromise of one session key does not 1356 compromise other session keys. 1358 8.2. Cryptographic Considerations 1360 The security of the SIGMA protocol requires the MAC to be bound to 1361 the identity of the signer. Hence the message authenticating 1362 functionality of the authenticated encryption in EDHOC is critical: 1363 authenticated encryption MUST NOT be replaced by plain encryption 1364 only, even if authentication is provided at another level or through 1365 a different mechanism. EDHOC implements SIGMA-I using the same Sign- 1366 then-MAC approach as TLS 1.3. 1368 To reduce message overhead EDHOC does not use explicit nonces and 1369 instead rely on the ephemeral public keys to provide randomness to 1370 each session. A good amount of randomness is important for the key 1371 generation, to provide liveness, and to protect against interleaving 1372 attacks. For this reason, the ephemeral keys MUST NOT be reused, and 1373 both parties SHALL generate fresh random ephemeral key pairs. 1375 The choice of key length used in the different algorithms needs to be 1376 harmonized, so that a sufficient security level is maintained for 1377 certificates, EDHOC, and the protection of application data. Party U 1378 and V should enforce a minimum security level. 1380 The data rates in many IoT deployments are very limited. Given that 1381 the application keys are protected as well as the long-term 1382 authentication keys they can often be used for years or even decades 1383 before the cryptographic limits are reached. If the application keys 1384 established through EDHOC need to be renewed, the communicating 1385 parties can derive application keys with other labels or run EDHOC 1386 again. 1388 8.3. Cipher Suites 1390 Cipher suite number 0 (AES-CCM-64-64-128, ECDH-SS + HKDF-256, X25519, 1391 Ed25519) is mandatory to implement. For many constrained IoT devices 1392 it is problematic to support more than one cipher suites, so some 1393 deployments with P-256 may not support the mandatory cipher suite. 1394 This is not a problem for local deployments. 1396 The HMAC algorithm HMAC 256/64 (HMAC w/ SHA-256 truncated to 64 bits) 1397 SHALL NOT be supported for use in EDHOC. 1399 8.4. Unprotected Data 1401 Party U and V must make sure that unprotected data and metadata do 1402 not reveal any sensitive information. This also applies for 1403 encrypted data sent to an unauthenticated party. In particular, it 1404 applies to UAD_1, ID_CRED_V, UAD_2, and ERR_MSG in the asymmetric 1405 case, and ID_PSK, UAD_1, and ERR_MSG in the symmetric case. Using 1406 the same ID_PSK or UAD_1 in several EDHOC sessions allows passive 1407 eavesdroppers to correlate the different sessions. The communicating 1408 parties may therefore anonymize ID_PSK. Another consideration is 1409 that the list of supported cipher suites may be used to identify the 1410 application. 1412 Party U and V must also make sure that unauthenticated data does not 1413 trigger any harmful actions. In particular, this applies to UAD_1 1414 and ERR_MSG in the asymmetric case, and ID_PSK, UAD_1, and ERR_MSG in 1415 the symmetric case. 1417 8.5. Denial-of-Service 1419 EDHOC itself does not provide countermeasures against Denial-of- 1420 Service attacks. By sending a number of new or replayed message_1 an 1421 attacker may cause Party V to allocate state, perform cryptographic 1422 operations, and amplify messages. To mitigate such attacks, an 1423 implementation SHOULD rely on lower layer mechanisms such as the Echo 1424 option in CoAP [I-D.ietf-core-echo-request-tag] that forces the 1425 initiator to demonstrate reachability at its apparent network 1426 address. 1428 8.6. Implementation Considerations 1430 The availability of a secure pseudorandom number generator and truly 1431 random seeds are essential for the security of EDHOC. If no true 1432 random number generator is available, a truly random seed must be 1433 provided from an external source. As each pseudoranom number must 1434 only be used once, an implementation need to get a new truly random 1435 seed after reboot, or continously store state in nonvolatile memory, 1436 see ([RFC8613], Appendix B.1.1) for issues and solution approaches 1437 for writing to nonvolatile memory. If ECDSA is supported, 1438 "deterministic ECDSA" as specified in [RFC6979] is RECOMMENDED. 1440 The referenced processing instructions in [SP-800-56A] must be 1441 complied with, including deleting the intermediate computed values 1442 along with any ephemeral ECDH secrets after the key derivation is 1443 completed. The ECDH shared secret, keys (K_2, K_3), and IVs (IV_2, 1444 IV_3) MUST be secret. Implementations should provide countermeasures 1445 to side-channel attacks such as timing attacks. 1447 Party U and V are responsible for verifying the integrity of 1448 certificates. The selection of trusted CAs should be done very 1449 carefully and certificate revocation should be supported. The 1450 private authentication keys and the PSK (even though it is used as 1451 salt) MUST be kept secret. 1453 Party U and V are allowed to select the connection identifiers C_U 1454 and C_V, respectively, for the other party to use in the ongoing 1455 EDHOC protocol as well as in a subsequent application protocol (e.g. 1456 OSCORE [RFC8613]). The choice of connection identifier is not 1457 security critical in EDHOC but intended to simplify the retrieval of 1458 the right security context in combination with using short 1459 identifiers. If the wrong connection identifier of the other party 1460 is used in a protocol message it will result in the receiving party 1461 not being able to retrieve a security context (which will terminate 1462 the protocol) or retrieve the wrong security context (which also 1463 terminates the protocol as the message cannot be verified). 1465 Party V MUST finish the verification step of message_3 before passing 1466 PAD_3 to the application. 1468 If two nodes unintentionally initiate two simultaneous EDHOC message 1469 exchanges with each other even if they only want to complete a single 1470 EDHOC message exchange, they MAY terminate the exchange with the 1471 lexicographically smallest G_X. If the two G_X values are equal, the 1472 received message_1 MUST be discarded to mitigate reflection attacks. 1473 Note that in the case of two simultaneous EDHOC exchanges where the 1474 nodes only complete one and where the nodes have different preferred 1475 cipher suites, an attacker can affect which of the two nodes' 1476 preferred cipher suites will be used by blocking the other exchange. 1478 8.7. Other Documents Referencing EDHOC 1480 EDHOC has been analyzed in several other documents. A formal 1481 verification of EDHOC was done in [SSR18], an analysis of EDHOC for 1482 certificate enrollment was done in [Kron18], the use of EDHOC in 1483 LoRaWAN is analyzed in [LoRa1] and [LoRa2], the use of EDHOC in IoT 1484 bootstrapping is analyzed in [Perez18], and the use of EDHOC in 1485 6TiSCH is described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. 1487 9. IANA Considerations 1489 9.1. EDHOC Cipher Suites Registry 1491 IANA has created a new registry titled "EDHOC Cipher Suites" under 1492 the new heading "EDHOC". The registration procedure is "Expert 1493 Review". The columns of the registry are Value, Array, Description, 1494 and Reference, where Value is an integer and the other columns are 1495 text strings. The initial contents of the registry are: 1497 Value: 1 1498 Array: [ 10, 5, 1, -7, 1 ] 1499 Desc: AES-CCM-16-64-128, HMAC 256/256, P-256, ES256, P-256 1500 Reference: [[this document]] 1502 Value: 0 1503 Array: [ 10, 5, 4, -8, 6 ] 1504 Desc: AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA, Ed25519 1505 Reference: [[this document]] 1507 Value: -5 1508 Array: 1509 Desc: Reserved for Private Use 1510 Reference: [[this document]] 1512 Value: -6 1513 Array: 1514 Desc: Reserved for Private Use 1515 Reference: [[this document]] 1517 9.2. EDHOC Method Type Registry 1519 IANA has created a new registry titled "EDHOC Method Type" under the 1520 new heading "EDHOC". The registration procedure is "Expert Review". 1521 The columns of the registry are Value, Description, and Reference, 1522 where Value is an integer and the other columns are text strings. 1523 The initial contents of the registry are: 1525 +-------+------------------------------------------+-------------------+ 1526 | Value | Specification | Reference | 1527 +-------+------------------------------------------+-------------------+ 1528 | 0 | EDHOC Authenticated with Asymmetric Keys | [[this document]] | 1529 | 1 | EDHOC Authenticated with Symmetric Keys | [[this document]] | 1530 +-------+------------------------------------------+-------------------+ 1532 9.3. The Well-Known URI Registry 1534 IANA has added the well-known URI 'edhoc' to the Well-Known URIs 1535 registry. 1537 o URI suffix: edhoc 1539 o Change controller: IETF 1541 o Specification document(s): [[this document]] 1543 o Related information: None 1545 9.4. Media Types Registry 1547 IANA has added the media type 'application/edhoc' to the Media Types 1548 registry. 1550 o Type name: application 1552 o Subtype name: edhoc 1554 o Required parameters: N/A 1556 o Optional parameters: N/A 1558 o Encoding considerations: binary 1560 o Security considerations: See Section 7 of this document. 1562 o Interoperability considerations: N/A 1564 o Published specification: [[this document]] (this document) 1566 o Applications that use this media type: To be identified 1568 o Fragment identifier considerations: N/A 1569 o Additional information: 1571 * Magic number(s): N/A 1573 * File extension(s): N/A 1575 * Macintosh file type code(s): N/A 1577 o Person & email address to contact for further information: See 1578 "Authors' Addresses" section. 1580 o Intended usage: COMMON 1582 o Restrictions on usage: N/A 1584 o Author: See "Authors' Addresses" section. 1586 o Change Controller: IESG 1588 9.5. CoAP Content-Formats Registry 1590 IANA has added the media type 'application/edhoc' to the CoAP 1591 Content-Formats registry. 1593 o Media Type: application/edhoc 1595 o Encoding: 1597 o ID: TBD42 1599 o Reference: [[this document]] 1601 9.6. Expert Review Instructions 1603 The IANA Registries established in this document is defined as 1604 "Expert Review". This section gives some general guidelines for what 1605 the experts should be looking for, but they are being designated as 1606 experts for a reason so they should be given substantial latitude. 1608 Expert reviewers should take into consideration the following points: 1610 o Clarity and correctness of registrations. Experts are expected to 1611 check the clarity of purpose and use of the requested entries. 1612 Expert needs to make sure the values of algorithms are taken from 1613 the right registry, when that's required. Expert should consider 1614 requesting an opinion on the correctness of registered parameters 1615 from relevant IETF working groups. Encodings that do not meet 1616 these objective of clarity and completeness should not be 1617 registered. 1619 o Experts should take into account the expected usage of fields when 1620 approving point assignment. The length of the encoded value 1621 should be weighed against how many code points of that length are 1622 left, the size of device it will be used on, and the number of 1623 code points left that encode to that size. 1625 o Specifications are recommended. When specifications are not 1626 provided, the description provided needs to have sufficient 1627 information to verify the points above. 1629 10. References 1631 10.1. Normative References 1633 [I-D.ietf-cbor-7049bis] 1634 Bormann, C. and P. Hoffman, "Concise Binary Object 1635 Representation (CBOR)", draft-ietf-cbor-7049bis-07 (work 1636 in progress), August 2019. 1638 [I-D.ietf-cbor-sequence] 1639 Bormann, C., "Concise Binary Object Representation (CBOR) 1640 Sequences", draft-ietf-cbor-sequence-01 (work in 1641 progress), August 2019. 1643 [I-D.ietf-core-echo-request-tag] 1644 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1645 Request-Tag, and Token Processing", draft-ietf-core-echo- 1646 request-tag-05 (work in progress), May 2019. 1648 [I-D.ietf-cose-x509] 1649 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1650 Headers for carrying and referencing X.509 certificates", 1651 draft-ietf-cose-x509-03 (work in progress), August 2019. 1653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1654 Requirement Levels", BCP 14, RFC 2119, 1655 DOI 10.17487/RFC2119, March 1997, 1656 . 1658 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1659 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1660 . 1662 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1663 Key Derivation Function (HKDF)", RFC 5869, 1664 DOI 10.17487/RFC5869, May 2010, 1665 . 1667 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1668 Curve Cryptography Algorithms", RFC 6090, 1669 DOI 10.17487/RFC6090, February 2011, 1670 . 1672 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 1673 Algorithm (DSA) and Elliptic Curve Digital Signature 1674 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 1675 2013, . 1677 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1678 Application Protocol (CoAP)", RFC 7252, 1679 DOI 10.17487/RFC7252, June 2014, 1680 . 1682 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1683 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1684 2016, . 1686 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1687 the Constrained Application Protocol (CoAP)", RFC 7959, 1688 DOI 10.17487/RFC7959, August 2016, 1689 . 1691 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1692 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1693 . 1695 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1696 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1697 May 2017, . 1699 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1700 Definition Language (CDDL): A Notational Convention to 1701 Express Concise Binary Object Representation (CBOR) and 1702 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1703 June 2019, . 1705 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1706 "Object Security for Constrained RESTful Environments 1707 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1708 . 1710 [SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to 1711 Authenticated Diffie-Hellman and Its Use in the IKE- 1712 Protocols (Long version)", June 2003, 1713 . 1715 [SP-800-56A] 1716 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1717 Davis, "Recommendation for Pair-Wise Key-Establishment 1718 Schemes Using Discrete Logarithm Cryptography", 1719 NIST Special Publication 800-56A Revision 3, April 2018, 1720 . 1722 10.2. Informative References 1724 [CborMe] Bormann, C., "CBOR Playground", May 2018, 1725 . 1727 [I-D.hartke-core-e2e-security-reqs] 1728 Selander, G., Palombini, F., and K. Hartke, "Requirements 1729 for CoAP End-To-End Security", draft-hartke-core-e2e- 1730 security-reqs-03 (work in progress), July 2017. 1732 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 1733 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 1734 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 1735 progress), July 2019. 1737 [I-D.ietf-ace-oauth-authz] 1738 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1739 H. Tschofenig, "Authentication and Authorization for 1740 Constrained Environments (ACE) using the OAuth 2.0 1741 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 1742 (work in progress), March 2019. 1744 [I-D.ietf-ace-oscore-profile] 1745 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1746 "OSCORE profile of the Authentication and Authorization 1747 for Constrained Environments Framework", draft-ietf-ace- 1748 oscore-profile-08 (work in progress), July 2019. 1750 [I-D.ietf-core-resource-directory] 1751 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1752 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1753 resource-directory-23 (work in progress), July 2019. 1755 [I-D.ietf-lwig-security-protocol-comparison] 1756 Mattsson, J. and F. Palombini, "Comparison of CoAP 1757 Security Protocols", draft-ietf-lwig-security-protocol- 1758 comparison-03 (work in progress), March 2019. 1760 [I-D.ietf-tls-dtls13] 1761 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1762 Datagram Transport Layer Security (DTLS) Protocol Version 1763 1.3", draft-ietf-tls-dtls13-32 (work in progress), July 1764 2019. 1766 [Kron18] Krontiris, A., "Evaluation of Certificate Enrollment over 1767 Application Layer Security", May 2018, 1768 . 1771 [LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., 1772 Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. 1773 Skarmeta, "Enhancing LoRaWAN Security through a 1774 Lightweight and Authenticated Key Management Approach", 1775 June 2018, 1776 . 1779 [LoRa2] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., 1780 Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. 1781 Skarmeta, "Internet Access for LoRaWAN Devices Considering 1782 Security Issues", June 2018, 1783 . 1785 [OPTLS] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 1786 October 2015, . 1788 [Perez18] Perez, S., Garcia-Carrillo, D., Marin-Lopez, R., 1789 Hernandez-Ramos, J., Marin-Perez, R., and A. Skarmeta, 1790 "Architecture of security association establishment based 1791 on bootstrapping technologies for enabling critical IoT 1792 infrastructures", October 2018, . 1797 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1798 Constrained-Node Networks", RFC 7228, 1799 DOI 10.17487/RFC7228, May 2014, 1800 . 1802 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1803 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1804 2014, . 1806 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1807 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1808 . 1810 [SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T., 1811 and C. Schuermann, "Formal Verification of Ephemeral 1812 Diffie-Hellman Over COSE (EDHOC)", November 2018, 1813 . 1817 Appendix A. Use of CBOR, CDDL and COSE in EDHOC 1819 This Appendix is intended to simplify for implementors not familiar 1820 with CBOR [I-D.ietf-cbor-7049bis], CDDL [RFC8610], COSE [RFC8152], 1821 and HKDF [RFC5869]. 1823 A.1. CBOR and CDDL 1825 The Concise Binary Object Representation (CBOR) 1826 [I-D.ietf-cbor-7049bis] is a data format designed for small code size 1827 and small message size. CBOR builds on the JSON data model but 1828 extends it by e.g. encoding binary data directly without base64 1829 conversion. In addition to the binary CBOR encoding, CBOR also has a 1830 diagnostic notation that is readable and editable by humans. The 1831 Concise Data Definition Language (CDDL) [RFC8610] provides a way to 1832 express structures for protocol messages and APIs that use CBOR. 1833 [RFC8610] also extends the diagnostic notation. 1835 CBOR data items are encoded to or decoded from byte strings using a 1836 type-length-value encoding scheme, where the three highest order bits 1837 of the initial byte contain information about the major type. CBOR 1838 supports several different types of data items, in addition to 1839 integers (int, uint), simple values (e.g. null), byte strings (bstr), 1840 and text strings (tstr), CBOR also supports arrays [] of data items, 1841 maps {} of pairs of data items, and sequences 1842 [I-D.ietf-cbor-sequence] of data items. Some examples are given 1843 below. For a complete specification and more examples, see 1844 [I-D.ietf-cbor-7049bis] and [RFC8610]. We recommend implementors to 1845 get used to CBOR by using the CBOR playground [CborMe]. 1847 Diagnostic Encoded Type 1848 ------------------------------------------------------------------ 1849 1 0x01 unsigned integer 1850 24 0x1818 unsigned integer 1851 -24 0x37 negative integer 1852 -25 0x3818 negative integer 1853 null 0xf6 simple value 1854 h'12cd' 0x4212cd byte string 1855 '12cd' 0x4431326364 byte string 1856 "12cd" 0x6431326364 text string 1857 { 4 : h'cd' } 0xa10441cd map 1858 << 1, 2, null >> 0x430102f6 byte string 1859 [ 1, 2, null ] 0x830102f6 array 1860 ( 1, 2, null ) 0x0102f6 sequence 1861 1, 2, null 0x0102f6 sequence 1862 ------------------------------------------------------------------ 1864 EDHOC messages are CBOR Sequences [I-D.ietf-cbor-sequence]. The 1865 message format specification uses the construct '.cbor' enabling 1866 conversion between different CDDL types matching different CBOR items 1867 with different encodings. Some examples are given below. 1869 A type (e.g. an uint) may be wrapped in a byte string (bstr): 1871 CDDL Type Diagnostic Encoded 1872 ------------------------------------------------------------------ 1873 uint 24 0x1818 1874 bstr .cbor uint << 24 >> 0x421818 1875 ------------------------------------------------------------------ 1877 A.2. COSE 1879 CBOR Object Signing and Encryption (COSE) [RFC8152] describes how to 1880 create and process signatures, message authentication codes, and 1881 encryption using CBOR. COSE builds on JOSE, but is adapted to allow 1882 more efficient processing in constrained devices. EDHOC makes use of 1883 COSE_Key, COSE_Encrypt0, COSE_Sign1, and COSE_KDF_Context objects. 1885 Appendix B. EDHOC Authenticated withDiffie-Hellman Keys 1887 The SIGMA protocol is mainly optimized for PKI and certificates. The 1888 OPTLS protocol [OPTLS] shows how authentication can be provided by a 1889 MAC computed from an ephemeral-static ECDH shared secret. Instead of 1890 signature authentication keys, U and V would have Diffie-Hellman 1891 authentication keys G_U and G_V, respectively. This type of 1892 authentication keys could easily be used with RPK and would provide 1893 significant reductions in message sizes as the 64 bytes signature 1894 would be replaced by an 8 bytes MAC. 1896 EDHOC authenticated with asymmetric Diffie-Hellman keys should have 1897 similar security properties as EDHOC authenticated with asymmetric 1898 signature keys with a few differences: 1900 o Repudiation: In EDHOC authenticated with asymmetric signature 1901 keys, Party U could theoretically prove that Party V performed a 1902 run of the protocol by presenting the private ephemeral key, and 1903 vice versa. Note that storing the private ephemeral keys violates 1904 the protocol requirements. With asymmetric Diffie-Hellman key 1905 authentication, both parties can always deny having participated 1906 in the protocol, this is similar to EDHOC with symmetric key 1907 authentication. 1909 o Key compromise impersonation (KCI): In EDHOC authenticated with 1910 asymmetric signature keys, EDHOC provides KCI protection against 1911 an attacker having access to the long term key or the ephemeral 1912 secret key. In EDHOC authenticated with symmetric keys, EDHOC 1913 provides KCI protection against an attacker having access to the 1914 ephemeral secret key, but not against an attacker having access to 1915 the long-term PSK. With asymmetric Diffie-Hellman key 1916 authentication, KCI protection would be provided against an 1917 attacker having access to the long-term Diffie-Hellman key, but 1918 not to an attacker having access to the ephemeral secret key. 1919 Note that the term KCI has typically been used for compromise of 1920 long-term keys, and that an attacker with access to the ephemeral 1921 secret key can only attack that specific protocol run. 1923 TODO: Initial suggestion for key derivation, message formats, and 1924 processing 1926 Appendix C. Test Vectors 1928 This appendix provides detailed test vectors to ease implementation 1929 and ensure interoperability. In addition to hexadecimal, all CBOR 1930 data items and sequences are given in CBOR diagnostic notation. The 1931 test vectors use 1 byte key identifiers, 1 byte connection IDs, and 1932 the default mapping to CoAP where Party U is CoAP client (this means 1933 that corr = 1). 1935 C.1. Test Vectors for EDHOC Authenticated with Asymmetric Keys (RPK) 1937 Asymmetric EDHOC is used: 1939 method (Asymmetric Authentication) 1940 0 1942 CoAP is used as transport: 1944 corr (Party U is CoAP client) 1945 1 1947 No unprotected opaque application data is sent in the message 1948 exchanges. 1950 The pre-defined Cipher Suite 0 is in place both on Party U and Party 1951 V, see Section 3.1. 1953 C.1.1. Input for Party U 1955 The following are the parameters that are set in Party U before the 1956 first message exchange. 1958 Party U's private authentication key (32 bytes) 1959 53 21 fc 01 c2 98 20 06 3a 72 50 8f c6 39 25 1d c8 30 e2 f7 68 3e b8 e3 8a 1960 f1 64 a5 b9 af 9b e3 1962 Party U's public authentication key (32 bytes) 1963 42 4c 75 6a b7 7c c6 fd ec f0 b3 ec fc ff b7 53 10 c0 15 bf 5c ba 2e c0 a2 1964 36 e6 65 0c 8a b9 c7 1966 kid value to identify U's public authentication key (1 bytes) 1967 a2 1969 This test vector uses COSE_Key objects to store the raw public keys. 1970 Moreover, EC2 keys with curve Ed25519 are used. That is in agreement 1971 with the Cipher Suite 0. 1973 CRED_U = 1974 << { 1975 1: 1, 1976 -1: 6, 1977 -2: h'424c756ab77cc6fdecf0b3ecfcffb75310c015bf5cba2ec0a236e6650c8ab9c7' 1978 } >> 1980 CRED_U (COSE_Key) (CBOR-encoded) (42 bytes) 1981 58 28 a3 01 01 20 06 21 58 20 42 4c 75 6a b7 7c c6 fd ec f0 b3 ec fc ff b7 1982 53 10 c0 15 bf 5c ba 2e c0 a2 36 e6 65 0c 8a b9 c7 1984 Because COSE_Keys are used, and because kid = h'a2': 1986 ID_CRED_U = 1987 { 1988 4: h'a2' 1989 } 1990 Note that since the map for ID_CRED_U contains a single 'kid' 1991 parameter, ID_CRED_U is used when transported in the protected header 1992 of the COSE Object, but only the kid_value is used when added to the 1993 plaintext (see Section 4.4.2): 1995 ID_CRED_U (in protected header) (CBOR-encoded) (4 bytes) 1996 a1 04 41 a2 1998 kid_value (in plaintext) (CBOR-encoded) (2 bytes) 1999 41 a2 2001 C.1.2. Input for Party V 2003 The following are the parameters that are set in Party V before the 2004 first message exchange. 2006 Party V's private authentication key (32 bytes) 2007 74 56 b3 a3 e5 8d 8d 26 dd 36 bc 75 d5 5b 88 63 a8 5d 34 72 f4 a0 1f 02 24 2008 62 1b 1c b8 16 6d a9 2010 Party V's public authentication key (32 bytes) 2011 1b 66 1e e5 d5 ef 16 72 a2 d8 77 cd 5b c2 0f 46 30 dc 78 a1 14 de 65 9c 7e 2012 50 4d 0f 52 9a 6b d3 2014 kid value to identify U's public authentication key (1 bytes) 2015 a3 2017 This test vector uses COSE_Key objects to store the raw public keys. 2018 Moreover, EC2 keys with curve Ed25519 are used. That is in agreement 2019 with the Cipher Suite 0. 2021 CRED_V = 2022 << { 2023 1: 1, 2024 -1: 6, 2025 -2: h'1b661ee5d5ef1672a2d877cd5bc20f4630dc78a114de659c7e504d0f529a6bd3' 2026 } >> 2028 CRED_V (COSE_Key) (CBOR-encoded) (42 bytes) 2029 58 28 a3 01 01 20 06 21 58 20 1b 66 1e e5 d5 ef 16 72 a2 d8 77 cd 5b c2 0f 2030 46 30 dc 78 a1 14 de 65 9c 7e 50 4d 0f 52 9a 6b d3 2032 Because COSE_Keys are used, and because kid = h'a3': 2034 ID_CRED_V = 2035 { 2036 4: h'a3' 2037 } 2038 Note that since the map for ID_CRED_U contains a single 'kid' 2039 parameter, ID_CRED_U is used when transported in the protected header 2040 of the COSE Object, but only the kid_value is used when added to the 2041 plaintext (see Section 4.4.2): 2043 ID_CRED_V (in protected header) (CBOR-encoded) (4 bytes) 2044 a1 04 41 a3 2046 kid_value (in plaintext) (CBOR-encoded) (2 bytes) 2047 41 a3 2049 C.1.3. Message 1 2051 From the input parameters (in Appendix C.1.1): 2053 TYPE (4 * method + corr) 2054 1 2056 suite 2057 0 2059 SUITES_U : suite 2060 0 2062 G_X (X-coordinate of the ephemeral public key of Party U) (32 bytes) 2063 b1 a3 e8 94 60 e8 8d 3a 8d 54 21 1d c9 5f 0b 90 3f f2 05 eb 71 91 2d 6d b8 2064 f4 af 98 0d 2d b8 3a 2066 C_U (Connection identifier chosen by U) (1 bytes) 2067 c3 2069 No UAD_1 is provided, so UAD_1 is absent from message_1. 2071 Message_1 is constructed, as the CBOR Sequence of the CBOR data items 2072 above. 2074 message_1 = 2075 ( 2076 1, 2077 0, 2078 h'b1a3e89460e88d3a8d54211dc95f0b903ff205eb71912d6db8f4af980d2db83a', 2079 h'c3' 2080 ) 2082 message_1 (CBOR Sequence) (38 bytes) 2083 01 00 58 20 b1 a3 e8 94 60 e8 8d 3a 8d 54 21 1d c9 5f 0b 90 3f f2 05 eb 71 2084 91 2d 6d b8 f4 af 98 0d 2d b8 3a 41 c3 2085 C.1.4. Message 2 2087 Since TYPE mod 4 equals 1, C_U is omitted from data_2. 2089 G_Y (X-coordinate of the ephemeral public key of Party V) (32 bytes) 2090 8d b5 77 f9 b9 c2 74 47 98 98 7d b5 57 bf 31 ca 48 ac d2 05 a9 db 8c 32 0e 2091 5d 49 f3 02 a9 64 74 2093 C_V (Connection identifier chosen by V) (1 bytes) 2094 c4 2096 Data_2 is constructed, as the CBOR Sequence of the CBOR data items 2097 above. 2099 data_2 = 2100 ( 2101 h'8db577f9b9c2744798987db557bf31ca48acd205a9db8c320e5d49f302a96474', 2102 h'c4' 2103 ) 2105 data_2 (CBOR Sequence) (36 bytes) 2106 58 20 8d b5 77 f9 b9 c2 74 47 98 98 7d b5 57 bf 31 ca 48 ac d2 05 a9 db 8c 2107 32 0e 5d 49 f3 02 a9 64 74 41 c4 2109 From data_2 and message_1 (from Appendix C.1.3), compute the input to 2110 the transcript hash TH_2 = H( message_1, data_2 ), as a CBOR Sequence 2111 of these 2 data items. 2113 ( message_1, data_2 ) (CBOR Sequence) 2114 (74 bytes) 2115 01 00 58 20 b1 a3 e8 94 60 e8 8d 3a 8d 54 21 1d c9 5f 0b 90 3f f2 05 eb 71 2116 91 2d 6d b8 f4 af 98 0d 2d b8 3a 41 c3 58 20 8d b5 77 f9 b9 c2 74 47 98 98 2117 7d b5 57 bf 31 ca 48 ac d2 05 a9 db 8c 32 0e 5d 49 f3 02 a9 64 74 41 c4 2119 And from there, compute the transcript hash TH_2 = SHA-256( 2120 message_1, data_2 ) 2122 TH_2 value (32 bytes) 2123 55 50 b3 dc 59 84 b0 20 9a e7 4e a2 6a 18 91 89 57 50 8e 30 33 2b 11 da 68 2124 1d c2 af dd 87 03 55 2126 When encoded as a CBOR bstr, that gives: 2128 TH_2 (CBOR-encoded) (34 bytes) 2129 58 20 55 50 b3 dc 59 84 b0 20 9a e7 4e a2 6a 18 91 89 57 50 8e 30 33 2b 11 2130 da 68 1d c2 af dd 87 03 55 2131 C.1.4.1. Signature Computation 2133 COSE_Sign1 is computed with the following parameters. From 2134 Appendix C.1.2: 2136 o protected = bstr .cbor ID_CRED_V 2138 o payload = CRED_V 2140 And from Appendix C.1.4: 2142 o external_aad = TH_2 2144 The Sig_structure M_V to be signed is: [ "Signature1", 2145 << ID_CRED_V >>, TH_2, CRED_V ] , as defined in Section 4.3.2: 2147 M_V = 2148 [ 2149 "Signature1", 2150 << { 4: h'a3' } >>, 2151 h'5550b3dc5984b0209ae74ea26a18918957508e30332b11da681dc2afdd870355', 2152 << { 2153 1: 1, 2154 -1: 6, 2155 -2: h'1b661ee5d5ef1672a2d877cd5bc20f4630dc78a114de659c7e504d0f529a6b 2156 d3' 2157 } >> 2158 ] 2160 Which encodes to the following byte string ToBeSigned: 2162 M_V (message to be signed with Ed25519) (CBOR-encoded) (93 bytes) 2163 84 6a 53 69 67 6e 61 74 75 72 65 31 44 a1 04 41 a3 58 20 55 50 b3 dc 59 84 2164 b0 20 9a e7 4e a2 6a 18 91 89 57 50 8e 30 33 2b 11 da 68 1d c2 af dd 87 03 2165 55 58 28 a3 01 01 20 06 21 58 20 1b 66 1e e5 d5 ef 16 72 a2 d8 77 cd 5b c2 2166 0f 46 30 dc 78 a1 14 de 65 9c 7e 50 4d 0f 52 9a 6b d3 2168 The message is signed using the private authentication key of V, and 2169 produces the following signature: 2171 V's signature (64 bytes) 2172 52 3d 99 6d fd 9e 2f 77 c7 68 71 8a 30 c3 48 77 8c 5e b8 64 dd 53 7e 55 5e 2173 4a 00 05 e2 09 53 07 13 ca 14 62 0d e8 18 7e 81 99 6e e8 04 d1 53 b8 a1 f6 2174 08 49 6f dc d9 3d 30 fc 1c 8b 45 be cc 06 2175 C.1.4.2. Key and Nonce Computation 2177 The key and nonce for calculating the ciphertext are calculated as 2178 follows, as specified in Section 3.3. 2180 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 2182 PRK = HMAC-SHA-256(salt, G_XY) 2184 Since this is the asymmetric case, salt is the empty byte string. 2186 G_XY is the shared secret, and since the curve25519 is used, the ECDH 2187 shared secret is the output of the X25519 function. 2189 G_XY (32 bytes) 2190 c6 1e 09 09 a1 9d 64 24 01 63 ec 26 2e 9c c4 f8 8c e7 7b e1 23 c5 ab 53 8d 2191 26 b0 69 22 a5 20 67 2193 From there, PRK is computed: 2195 PRK (32 bytes) 2196 ba 9c 2c a1 c5 62 14 a6 e0 f6 13 ed a8 91 86 8a 4c a3 e3 fa bc c7 79 8f dc 2197 01 60 80 07 59 16 71 2199 Key K_2 is the output of HKDF-Expand(PRK, info, L). 2201 info is defined as follows: 2203 info for K_2 2204 [ 2205 10, 2206 [ null, null, null ], 2207 [ null, null, null ], 2208 [ 128, h'', h'5550b3dc5984b0209ae74ea26a18918957508e30332b11da681dc2afdd 2209 870355' ] 2210 ] 2212 Which as a CBOR encoded data item is: 2214 info (K_2) (CBOR-encoded) (48 bytes) 2215 84 0a 83 f6 f6 f6 83 f6 f6 f6 83 18 80 40 58 20 55 50 b3 dc 59 84 b0 20 9a 2216 e7 4e a2 6a 18 91 89 57 50 8e 30 33 2b 11 da 68 1d c2 af dd 87 03 55 2218 L is the length of K_2, so 16 bytes. 2220 From these parameters, K_2 is computed: 2222 K_2 (16 bytes) 2223 da d7 44 af 07 c4 da 27 d1 f0 a3 8a 0c 4b 87 38 2225 Nonce IV_2 is the output of HKDF-Expand(PRK, info, L). 2227 info is defined as follows: 2229 info for IV_2 2230 [ 2231 "IV-GENERATION", 2232 [ null, null, null ], 2233 [ null, null, null ], 2234 [ 104, h'', h'5550b3dc5984b0209ae74ea26a18918957508e30332b11da681dc2afdd 2235 870355' ] 2236 ] 2238 Which as a CBOR encoded data item is: 2240 info (IV_2) (CBOR-encoded) (61 bytes) 2241 84 6d 49 56 2d 47 45 4e 45 52 41 54 49 4f 4e 83 f6 f6 f6 83 f6 f6 f6 83 18 2242 68 40 58 20 55 50 b3 dc 59 84 b0 20 9a e7 4e a2 6a 18 91 89 57 50 8e 30 33 2243 2b 11 da 68 1d c2 af dd 87 03 55 2245 L is the length of IV_2, so 13 bytes. 2247 From these parameters, IV_2 is computed: 2249 IV_2 (13 bytes) 2250 fb a1 65 d9 08 da a7 8e 4f 84 41 42 d0 2252 C.1.4.3. Ciphertext Computation 2254 COSE_Encrypt0 is computed with the following parameters. Note that 2255 UAD_2 is omitted. 2257 o empty protected header 2259 o external_aad = TH_2 2261 o plaintext = CBOR Sequence of the items kid_value, signature, in 2262 this order. 2264 with kid_value taken from Appendix C.1.2, and signature as calculated 2265 in Appendix C.1.4.1. 2267 The plaintext is the following: 2269 P_2 (68 bytes) 2270 41 a3 58 40 52 3d 99 6d fd 9e 2f 77 c7 68 71 8a 30 c3 48 77 8c 5e b8 64 dd 2271 53 7e 55 5e 4a 00 05 e2 09 53 07 13 ca 14 62 0d e8 18 7e 81 99 6e e8 04 d1 2272 53 b8 a1 f6 08 49 6f dc d9 3d 30 fc 1c 8b 45 be cc 06 2274 From the parameters above, the Enc_structure A_2 is computed. 2276 A_2 = 2277 [ 2278 "Encrypt0", 2279 h'', 2280 h'5550b3dc5984b0209ae74ea26a18918957508e30332b11da681dc2afdd870355' 2281 ] 2283 Which encodes to the following byte string to be used as Additional 2284 Authenticated Data: 2286 A_2 (CBOR-encoded) (45 bytes) 2287 83 68 45 6e 63 72 79 70 74 30 40 58 20 55 50 b3 dc 59 84 b0 20 9a e7 4e a2 2288 6a 18 91 89 57 50 8e 30 33 2b 11 da 68 1d c2 af dd 87 03 55 2290 The key and nonce used are defined in Appendix C.1.4.2: 2292 o key = K_2 2294 o nonce = IV_2 2296 Using the parameters above, the ciphertext CIPHERTEXT_2 can be 2297 computed: 2299 CIPHERTEXT_2 (76 bytes) 2300 1e 6b fe 0e 77 99 ce f0 66 a3 4f 08 ef aa 90 00 6d b4 4c 90 1c f7 9b 23 85 2301 3a b9 7f d8 db c8 53 39 d5 ed 80 87 78 3c f7 a4 a7 e0 ea 38 c2 21 78 9f a3 2302 71 be 64 e9 3c 43 a7 db 47 d1 e3 fb 14 78 8e 96 7f dd 78 d8 80 78 e4 9b 78 2303 bf 2305 C.1.4.4. message_2 2307 From the parameter computed in Appendix C.1.4 and Appendix C.1.4.3, 2308 message_2 is computed, as the CBOR Sequence of the following items: 2309 (G_Y, C_V, CIPHERTEXT_2). 2311 message_2 = 2312 ( 2313 h'8db577f9b9c2744798987db557bf31ca48acd205a9db8c320e5d49f302a96474', 2314 h'c4', 2315 h'1e6bfe0e7799cef066a34f08efaa90006db44c901cf79b23853ab97fd8dbc85339d5ed 2316 8087783cf7a4a7e0ea38c221789fa371be64e93c43a7db47d1e3fb14788e967fdd78d880 2317 78e49b78bf' 2318 ) 2320 Which encodes to the following byte string: 2322 message_2 (CBOR Sequence) (114 bytes) 2323 58 20 8d b5 77 f9 b9 c2 74 47 98 98 7d b5 57 bf 31 ca 48 ac d2 05 a9 db 8c 2324 32 0e 5d 49 f3 02 a9 64 74 41 c4 58 4c 1e 6b fe 0e 77 99 ce f0 66 a3 4f 08 2325 ef aa 90 00 6d b4 4c 90 1c f7 9b 23 85 3a b9 7f d8 db c8 53 39 d5 ed 80 87 2326 78 3c f7 a4 a7 e0 ea 38 c2 21 78 9f a3 71 be 64 e9 3c 43 a7 db 47 d1 e3 fb 2327 14 78 8e 96 7f dd 78 d8 80 78 e4 9b 78 bf 2329 C.1.5. Message 3 2331 Since TYPE mod 4 equals 1, C_V is not omitted from data_3. 2333 C_V (1 bytes) 2334 c4 2336 Data_3 is constructed, as the CBOR Sequence of the CBOR data item 2337 above. 2339 data_3 = 2340 ( 2341 h'c4' 2342 ) 2344 data_3 (CBOR Sequence) (2 bytes) 2345 41 c4 2347 From data_3, CIPHERTEXT_2 (Appendix C.1.4.3), and TH_2 2348 (Appendix C.1.4), compute the input to the transcript hash TH_2 = 2349 H(TH_2 , CIPHERTEXT_2, data_3), as a CBOR Sequence of these 3 data 2350 items. 2352 ( TH_2, CIPHERTEXT_2, data_3 ) 2353 (CBOR Sequence) (114 bytes) 2354 58 20 55 50 b3 dc 59 84 b0 20 9a e7 4e a2 6a 18 91 89 57 50 8e 30 33 2b 11 2355 da 68 1d c2 af dd 87 03 55 58 4c 1e 6b fe 0e 77 99 ce f0 66 a3 4f 08 ef aa 2356 90 00 6d b4 4c 90 1c f7 9b 23 85 3a b9 7f d8 db c8 53 39 d5 ed 80 87 78 3c 2357 f7 a4 a7 e0 ea 38 c2 21 78 9f a3 71 be 64 e9 3c 43 a7 db 47 d1 e3 fb 14 78 2358 8e 96 7f dd 78 d8 80 78 e4 9b 78 bf 41 c4 2359 And from there, compute the transcript hash TH_3 = SHA-256(TH_2 , 2360 CIPHERTEXT_2, data_3) 2362 TH_3 value (32 bytes) 2363 21 cc b6 78 b7 91 14 96 09 55 88 5b 90 a2 b8 2e 3b 2c a2 7e 8e 37 4a 79 07 2364 f3 e7 85 43 67 fc 22 2366 When encoded as a CBOR bstr, that gives: 2368 TH_3 (CBOR-encoded) (34 bytes) 2369 58 20 21 cc b6 78 b7 91 14 96 09 55 88 5b 90 a2 b8 2e 3b 2c a2 7e 8e 37 4a 2370 79 07 f3 e7 85 43 67 fc 22 2372 C.1.5.1. Signature Computation 2374 COSE_Sign1 is computed with the following parameters. From 2375 Appendix C.1.2: 2377 o protected = bstr .cbor ID_CRED_U 2379 o payload = CRED_U 2381 And from Appendix C.1.4: 2383 o external_aad = TH_3 2385 The Sig_structure M_V to be signed is: [ "Signature1", 2386 << ID_CRED_U >>, TH_3, CRED_U ] , as defined in Section 4.4.2: 2388 M_U = 2389 [ 2390 "Signature1", 2391 << { 4: h'a2' } >>, 2392 h'734bef323d867a12956127c2e62ade42c0f119e5487750c0c31fd093376dceed', 2393 << { 2394 1: 1, 2395 -1: 6, 2396 -2: h'424c756ab77cc6fdecf0b3ecfcffb75310c015bf5cba2ec0a236e6650c8ab9 2397 c7' 2398 } >> 2399 ] 2401 Which encodes to the following byte string ToBeSigned: 2403 M_U (message to be signed with Ed25519) (CBOR-encoded) (93 bytes) 2404 84 6a 53 69 67 6e 61 74 75 72 65 31 44 a1 04 41 a2 58 20 73 4b ef 32 3d 86 2405 7a 12 95 61 27 c2 e6 2a de 42 c0 f1 19 e5 48 77 50 c0 c3 1f d0 93 37 6d ce 2406 ed 58 28 a3 01 01 20 06 21 58 20 42 4c 75 6a b7 7c c6 fd ec f0 b3 ec fc ff 2407 b7 53 10 c0 15 bf 5c ba 2e c0 a2 36 e6 65 0c 8a b9 c7 2409 The message is signed using the private authentication key of U, and 2410 produces the following signature: 2412 U's signature (64 bytes) 2413 5c 7d 7d 64 c9 61 c5 f5 2d cf 33 91 25 92 a1 af f0 2c 33 62 b0 e7 55 0e 4b 2414 c5 66 b7 0c 20 61 f3 c5 f6 49 e5 ed 32 3d 30 a2 6c 61 2f bb 5c bd 25 f3 1c 2415 27 22 8c ea ec 64 29 31 95 41 fe 07 8e 0e 2417 C.1.5.2. Key and Nonce Computation 2419 The key and nonce for calculating the ciphertext are calculated as 2420 follows, as specified in Section 3.3. 2422 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 2424 PRK = HMAC-SHA-256(salt, G_XY) 2426 Since this is the asymmetric case, salt is the empty byte string. 2428 G_XY is the shared secret, and since the curve25519 is used, the ECDH 2429 shared secret is the output of the X25519 function. 2431 G_XY (32 bytes) 2432 c6 1e 09 09 a1 9d 64 24 01 63 ec 26 2e 9c c4 f8 8c e7 7b e1 23 c5 ab 53 8d 2433 26 b0 69 22 a5 20 67 2435 From there, PRK is computed: 2437 PRK (32 bytes) 2438 ba 9c 2c a1 c5 62 14 a6 e0 f6 13 ed a8 91 86 8a 4c a3 e3 fa bc c7 79 8f dc 2439 01 60 80 07 59 16 71 2441 Key K_3 is the output of HKDF-Expand(PRK, info, L). 2443 info is defined as follows: 2445 info for K_3 2446 [ 2447 10, 2448 [ null, null, null ], 2449 [ null, null, null ], 2450 [ 128, h'', h'21ccb678b79114960955885b90a2b82e3b2ca27e8e374a7907f3e78543 2451 67fc22' ] 2452 ] 2454 Which as a CBOR encoded data item is: 2456 info (K_3) (CBOR-encoded) (48 bytes) 2457 84 0a 83 f6 f6 f6 83 f6 f6 f6 83 18 80 40 58 20 21 cc b6 78 b7 91 14 96 09 2458 55 88 5b 90 a2 b8 2e 3b 2c a2 7e 8e 37 4a 79 07 f3 e7 85 43 67 fc 22 2460 L is the length of K_3, so 16 bytes. 2462 From these parameters, K_3 is computed: 2464 K_3 (16 bytes) 2465 e1 ac d4 76 f5 96 a4 60 72 44 a8 da 8c ff 49 df 2467 Nonce IV_3 is the output of HKDF-Expand(PRK, info, L). 2469 info is defined as follows: 2471 info for IV_3 2472 [ 2473 "IV-GENERATION", 2474 [ null, null, null ], 2475 [ null, null, null ], 2476 [ 104, h'', h'21ccb678b79114960955885b90a2b82e3b2ca27e8e374a7907f3e78543 2477 67fc22' ] 2478 ] 2480 Which as a CBOR encoded data item is: 2482 info (IV_3) (CBOR-encoded) (61 bytes) 2483 84 6d 49 56 2d 47 45 4e 45 52 41 54 49 4f 4e 83 f6 f6 f6 83 f6 f6 f6 83 18 2484 68 40 58 20 21 cc b6 78 b7 91 14 96 09 55 88 5b 90 a2 b8 2e 3b 2c a2 7e 8e 2485 37 4a 79 07 f3 e7 85 43 67 fc 22 2487 L is the length of IV_3, so 13 bytes. 2489 From these parameters, IV_3 is computed: 2491 IV_3 (13 bytes) 2492 de 53 02 13 ab a2 6a 47 1a 51 f3 d6 fb 2494 C.1.5.3. Ciphertext Computation 2496 COSE_Encrypt0 is computed with the following parameters. Note that 2497 PAD_3 is omitted. 2499 o empty protected header 2501 o external_aad = TH_3 2503 o plaintext = CBOR Sequence of the items kid_value, signature, in 2504 this order. 2506 with kid_value taken from Appendix C.1.1, and signature as calculated 2507 in Appendix C.1.5.1. 2509 The plaintext is the following: 2511 P_3 (68 bytes) 2512 41 a2 58 40 5c 7d 7d 64 c9 61 c5 f5 2d cf 33 91 25 92 a1 af f0 2c 33 62 b0 2513 e7 55 0e 4b c5 66 b7 0c 20 61 f3 c5 f6 49 e5 ed 32 3d 30 a2 6c 61 2f bb 5c 2514 bd 25 f3 1c 27 22 8c ea ec 64 29 31 95 41 fe 07 8e 0e 2516 From the parameters above, the Enc_structure A_3 is computed. 2518 A_3 = 2519 [ 2520 "Encrypt0", 2521 h'', 2522 h'21ccb678b79114960955885b90a2b82e3b2ca27e8e374a7907f3e7854367fc22' 2523 ] 2525 Which encodes to the following byte string to be used as Additional 2526 Authenticated Data: 2528 A_2 (CBOR-encoded) (45 bytes) 2529 83 68 45 6e 63 72 79 70 74 30 40 58 20 21 cc b6 78 b7 91 14 96 09 55 88 5b 2530 90 a2 b8 2e 3b 2c a2 7e 8e 37 4a 79 07 f3 e7 85 43 67 fc 22 2532 The key and nonce used are defined in Appendix C.1.4.2: 2534 o key = K_3 2536 o nonce = IV_3 2538 Using the parameters above, the ciphertext CIPHERTEXT_3 can be 2539 computed: 2541 CIPHERTEXT_3 (76 bytes) 2542 de 4a 83 3d 48 b6 64 74 14 2c c9 bd ce 87 d9 3a f8 35 57 9c 2d bf 1b 9e 2f 2543 b4 dc 66 60 0d ba c6 bb 3c c0 5c 29 0e f3 5d 51 5b 4d 7d 64 83 f5 09 61 43 2544 b5 56 44 cf af d1 ff aa 7f 2b a3 86 36 57 83 1d d2 e5 bd 04 04 38 60 14 0d 2545 c8 2547 C.1.5.4. message_3 2549 From the parameter computed in Appendix C.1.5 and Appendix C.1.5.3, 2550 message_3 is computed, as the CBOR Sequence of the following items: 2551 (C_V, CIPHERTEXT_3). 2553 message_3 = 2554 ( 2555 h'c4', 2556 h'de4a833d48b66474142cc9bdce87d93af835579c2dbf1b9e2fb4dc66600dbac6bb3cc0 2557 5c290ef35d515b4d7d6483f5096143b55644cfafd1ffaa7f2ba3863657831dd2e5bd0404 2558 3860140dc8' 2559 ) 2561 Which encodes to the following byte string: 2563 message_3 (CBOR Sequence) (80 bytes) 2564 41 c4 58 4c de 4a 83 3d 48 b6 64 74 14 2c c9 bd ce 87 d9 3a f8 35 57 9c 2d bf 1b 9e 2f b4 dc 66 60 0d ba c6 bb 3c c0 5c 29 0e f3 5d 51 5b 4d 7d 64 83 f5 09 61 43 b5 56 44 cf af d1 ff aa 7f 2b a3 86 36 57 83 1d d2 e5 bd 04 04 38 60 14 0d c8 2566 C.1.5.5. OSCORE Security Context Derivation 2568 From the previous message exchange, the Common Security Context for 2569 OSCORE [RFC8613] can be derived, as specified in Section 3.3.1. 2571 First af all, TH_4 is computed: TH_4 = H( TH_3, CIPHERTEXT_3 ), where 2572 the input to the hash function is the CBOR Sequence of TH_3 and 2573 CIPHERTEXT_3 2575 ( TH_3, CIPHERTEXT_3 ) 2576 (CBOR Sequence) (112 bytes) 2577 58 20 21 cc b6 78 b7 91 14 96 09 55 88 5b 90 a2 b8 2e 3b 2c a2 7e 8e 37 4a 2578 79 07 f3 e7 85 43 67 fc 22 58 4c de 4a 83 3d 48 b6 64 74 14 2c c9 bd ce 87 2579 d9 3a f8 35 57 9c 2d bf 1b 9e 2f b4 dc 66 60 0d ba c6 bb 3c c0 5c 29 0e f3 2580 5d 51 5b 4d 7d 64 83 f5 09 61 43 b5 56 44 cf af d1 ff aa 7f 2b a3 86 36 57 2581 83 1d d2 e5 bd 04 04 38 60 14 0d c8 2583 And from there, compute the transcript hash TH_4 = SHA-256( TH_3, 2584 CIPHERTEXT_3 ) 2586 TH_4 value (32 bytes) 2587 51 ed 39 32 bc ba e8 90 1c 1d 4d eb 94 bd 67 3a b4 d3 8c 34 81 96 09 ee 0d 2588 5c 9d a6 e9 80 7f e5 2589 When encoded as a CBOR bstr, that gives: 2591 TH_4 (CBOR-encoded) (34 bytes) 2592 58 20 51 ed 39 32 bc ba e8 90 1c 1d 4d eb 94 bd 67 3a b4 d3 8c 34 81 96 09 2593 ee 0d 5c 9d a6 e9 80 7f e5 2595 To derive the Master Secret and Master Salt the same HKDF-Expand 2596 (PRK, info, L) is used, with different info and L. 2598 For Master Secret: 2600 L for Master Secret = 16 2602 Info for Master Secret = 2603 [ 2604 "OSCORE Master Secret", 2605 [ null, null, null ], 2606 [ null, null, null ], 2607 [ 128, h'', h'51ed3932bcbae8901c1d4deb94bd673ab4d38c34819609ee0d5c9da6e9 2608 807fe5' ] 2609 ] 2611 When encoded as a CBOR bstr, that gives: 2613 info (OSCORE Master Secret) (CBOR-encoded) (68 bytes) 2614 84 74 4f 53 43 4f 52 45 20 4d 61 73 74 65 72 20 53 65 63 72 65 74 83 f6 f6 2615 f6 83 f6 f6 f6 83 18 80 40 58 20 51 ed 39 32 bc ba e8 90 1c 1d 4d eb 94 bd 2616 67 3a b4 d3 8c 34 81 96 09 ee 0d 5c 9d a6 e9 80 7f e5 2618 Finally, the Master Secret value computed is: 2620 OSCORE Master Secret (16 bytes) 2621 09 02 9d b0 0c 3e 01 27 42 c3 a8 69 04 07 4c 0e 2623 For Master Salt: 2625 L for Master Secret = 8 2627 Info for Master Salt = 2628 [ 2629 "OSCORE Master Salt", 2630 [ null, null, null ], 2631 [ null, null, null ], 2632 [ 64, h'', h'51ed3932bcbae8901c1d4deb94bd673ab4d38c34819609ee0d5c9da6e98 2633 07fe5' ] 2634 ] 2636 When encoded as a CBOR bstr, that gives: 2638 info (OSCORE Master Salt) (CBOR-encoded) (66 bytes) 2639 84 72 4f 53 43 4f 52 45 20 4d 61 73 74 65 72 20 53 61 6c 74 83 f6 f6 f6 83 2640 f6 f6 f6 83 18 40 40 58 20 51 ed 39 32 bc ba e8 90 1c 1d 4d eb 94 bd 67 3a 2641 b4 d3 8c 34 81 96 09 ee 0d 5c 9d a6 e9 80 7f e5 2643 Finally, the Master Secret value computed is: 2645 OSCORE Master Salt (8 bytes) 2646 81 02 97 22 a2 30 4a 06 2648 The Client's Sender ID takes the value of C_V: 2650 Client's OSCORE Sender ID (1 bytes) 2651 c4 2653 The Server's Sender ID takes the value of C_U: 2655 Server's OSCORE Sender ID (1 bytes) 2656 c3 2658 The algorithms are those negociated in the cipher suite: 2660 AEAD Algorithm 2661 10 2663 HMAC Algorithm 2664 5 2666 C.2. Test Vectors for EDHOC Authenticated with Symmetric Keys (PSK) 2668 Symmetric EDHOC is used: 2670 method (Symmetric Authentication) 2671 1 2673 CoAP is used as transport: 2675 corr (Party U is CoAP client) 2676 1 2678 No unprotected opaque application data is sent in the message 2679 exchanges. 2681 The pre-defined Cipher Suite 0 is in place both on Party U and Party 2682 V, see Section 3.1. 2684 C.2.1. Input for Party U 2686 The following are the parameters that are set in Party U before the 2687 first message exchange. 2689 Party U's ephemeral private key (32 bytes) 2690 f4 0c ea f8 6e 57 76 92 33 32 b8 d8 fd 3b ef 84 9c ad b1 9c 69 96 bc 27 2a 2691 f1 f6 48 d9 56 6a 4c 2693 Party U's ephemeral public key (value of X_U) (32 bytes) 2694 ab 2f ca 32 89 83 22 c2 08 fb 2d ab 50 48 bd 43 c3 55 c6 43 0f 58 88 97 cb 2695 57 49 61 cf a9 80 6f 2697 Connection identifier chosen by U (value of C_U) (1 bytes) 2698 c1 2700 Pre-shared Key (PSK) (16 bytes) 2701 a1 1f 8f 12 d0 87 6f 73 6d 2d 8f d2 6e 14 c2 de 2703 kid value to identify PSK (1 bytes) 2704 a1 2706 So ID_PSK is defined as the following: 2708 ID_PSK = 2709 { 2710 4: h'a1' 2711 } 2713 This test vector uses COSE_Key objects to store the pre-shared key. 2715 Note that since the map for ID_PSK contains a single 'kid' parameter, 2716 ID_PSK is used when transported in the protected header of the COSE 2717 Object, but only the kid_value is used when added to the plaintext 2718 (see Section 5.1): 2720 ID_PSK (in protected header) (CBOR-encoded) (4 bytes) 2721 a1 04 41 a1 2723 kid_value (in plaintext) (CBOR-encoded) (2 bytes) 2724 41 a1 2726 C.2.2. Input for Party V 2728 The following are the parameters that are set in Party U before the 2729 first message exchange. 2731 Party V's ephemeral private key (32 bytes) 2732 d9 81 80 87 de 72 44 ab c1 b5 fc f2 8e 55 e4 2c 7f f9 c6 78 c0 60 51 81 f3 2733 7a c5 d7 41 4a 7b 95 2735 Party V's ephemeral public key (value of X_V) (32 bytes) 2736 fc 3b 33 93 67 a5 22 5d 53 a9 2d 38 03 23 af d0 35 d7 81 7b 6d 1b e4 7d 94 2737 6f 6b 09 a9 cb dc 06 2739 Connection identifier chosen by V (value of C_V) (1 bytes) 2740 c2 2742 Pre-shared Key (PSK) (16 bytes) 2743 a1 1f 8f 12 d0 87 6f 73 6d 2d 8f d2 6e 14 c2 de 2745 kid value to identify PSK (1 bytes) 2746 a1 2748 So ID_PSK is defined as the following: 2750 ID_PSK = 2751 { 2752 4: h'a1' 2753 } 2755 This test vector uses COSE_Key objects to store the pre-shared key. 2757 Note that since the map for ID_PSK contains a single 'kid' parameter, 2758 ID_PSK is used when transported in the protected header of the COSE 2759 Object, but only the kid_value is used when added to the plaintext 2760 (see Section 5.1): 2762 ID_PSK (in protected header) (CBOR-encoded) (4 bytes) 2763 a1 04 41 a1 2765 kid_value (in plaintext) (CBOR-encoded) (2 bytes) 2766 41 a1 2768 C.2.3. Message 1 2770 From the input parameters (in Appendix C.2.1): 2772 TYPE (4 * method + corr) 2773 5 2775 suite 2776 0 2777 SUITES_U : suite 2778 0 2780 G_X (X-coordinate of the ephemeral public key of Party U) (32 bytes) 2781 ab 2f ca 32 89 83 22 c2 08 fb 2d ab 50 48 bd 43 c3 55 c6 43 0f 58 88 97 cb 2782 57 49 61 cf a9 80 6f 2784 C_U (Connection identifier chosen by U) (CBOR encoded) (2 bytes) 2785 41 c1 2787 kid_value of ID_PSK (CBOR encoded) (2 bytes) 2788 41 a1 2790 No UAD_1 is provided, so UAD_1 is absent from message_1. 2792 Message_1 is constructed, as the CBOR Sequence of the CBOR data items 2793 above. 2795 message_1 = 2796 ( 2797 5, 2798 0, 2799 h'ab2fca32898322c208fb2dab5048bd43c355c6430f588897cb574961cfa9806f', 2800 h'c1', 2801 h'a1' 2802 ) 2804 message_1 (CBOR Sequence) (40 bytes) 2805 05 00 58 20 ab 2f ca 32 89 83 22 c2 08 fb 2d ab 50 48 bd 43 c3 55 c6 43 0f 2806 58 88 97 cb 57 49 61 cf a9 80 6f 41 c1 41 a1 2808 C.2.4. Message 2 2810 Since TYPE mod 4 equals 1, C_U is omitted from data_2. 2812 G_Y (X-coordinate of the ephemeral public key of Party V) (32 bytes) 2813 fc 3b 33 93 67 a5 22 5d 53 a9 2d 38 03 23 af d0 35 d7 81 7b 6d 1b e4 7d 94 2814 6f 6b 09 a9 cb dc 06 2816 C_V (Connection identifier chosen by V) (1 bytes) 2817 c2 2819 Data_2 is constructed, as the CBOR Sequence of the CBOR data items 2820 above. 2822 data_2 = 2823 ( 2824 h'fc3b339367a5225d53a92d380323afd035d7817b6d1be47d946f6b09a9cbdc06', 2825 h'c2' 2826 ) 2828 data_2 (CBOR Sequence) (36 bytes) 2829 58 20 fc 3b 33 93 67 a5 22 5d 53 a9 2d 38 03 23 af d0 35 d7 81 7b 6d 1b e4 2830 7d 94 6f 6b 09 a9 cb dc 06 41 c2 2832 From data_2 and message_1 (from Appendix C.2.3), compute the input to 2833 the transcript hash TH_2 = H( message_1, data_2 ), as a CBOR Sequence 2834 of these 2 data items. 2836 ( message_1, data_2 ) (CBOR Sequence) 2837 (76 bytes) 2838 05 00 58 20 ab 2f ca 32 89 83 22 c2 08 fb 2d ab 50 48 bd 43 c3 55 c6 43 0f 2839 58 88 97 cb 57 49 61 cf a9 80 6f 41 c1 41 a1 58 20 fc 3b 33 93 67 a5 22 5d 2840 53 a9 2d 38 03 23 af d0 35 d7 81 7b 6d 1b e4 7d 94 6f 6b 09 a9 cb dc 06 41 2841 c2 2843 And from there, compute the transcript hash TH_2 = SHA-256( 2844 message_1, data_2 ) 2846 TH_2 value (32 bytes) 2847 16 4f 44 d8 56 dd 15 22 2f a4 63 f2 02 d9 c6 0b e3 c6 9b 40 f7 35 8d 34 1c 2848 db 7b 07 de e1 70 ca 2850 When encoded as a CBOR bstr, that gives: 2852 TH_2 (CBOR-encoded) (34 bytes) 2853 58 20 16 4f 44 d8 56 dd 15 22 2f a4 63 f2 02 d9 c6 0b e3 c6 9b 40 f7 35 8d 2854 34 1c db 7b 07 de e1 70 ca 2856 C.2.4.1. Key and Nonce Computation 2858 The key and nonce for calculating the ciphertext are calculated as 2859 follows, as specified in Section 3.3. 2861 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 2863 PRK = HMAC-SHA-256(salt, G_XY) 2865 Since this is the symmetric case, salt is the PSK: 2867 salt (16 bytes) 2868 a1 1f 8f 12 d0 87 6f 73 6d 2d 8f d2 6e 14 c2 de 2869 G_XY is the shared secret, and since the curve25519 is used, the ECDH 2870 shared secret is the output of the X25519 function. 2872 G_XY (32 bytes) 2873 d5 75 05 50 6d 8f 30 a8 60 a0 63 d0 1b 5b 7a d7 6a 09 4f 70 61 3b 4a e6 6c 2874 5a 90 e5 c2 1f 23 11 2876 From there, PRK is computed: 2878 PRK (32 bytes) 2879 aa b2 f1 3c cb 1a 4f f7 96 a9 7a 32 a4 d2 fb 62 47 ef 0b 6b 06 da 04 d3 d1 2880 06 39 4b 28 76 e2 8c 2882 Key K_2 is the output of HKDF-Expand(PRK, info, L). 2884 info is defined as follows: 2886 info for K_2 2887 [ 2888 10, 2889 [ null, null, null ], 2890 [ null, null, null ], 2891 [ 128, h'', h'164f44d856dd15222fa463f202d9c60be3c69b40f7358d341cdb7b07de 2892 e170ca' ] 2893 ] 2895 Which as a CBOR encoded data item is: 2897 info (K_2) (CBOR-encoded) (48 bytes) 2898 84 0a 83 f6 f6 f6 83 f6 f6 f6 83 18 80 40 58 20 16 4f 44 d8 56 dd 15 22 2f 2899 a4 63 f2 02 d9 c6 0b e3 c6 9b 40 f7 35 8d 34 1c db 7b 07 de e1 70 ca 2901 L is the length of K_2, so 16 bytes. 2903 From these parameters, K_2 is computed: 2905 K_2 (16 bytes) 2906 ac 42 6e 5e 7d 7a d6 ae 3b 19 aa bd e0 f6 25 57 2908 Nonce IV_2 is the output of HKDF-Expand(PRK, info, L). 2910 info is defined as follows: 2912 info for IV_2 2913 [ 2914 "IV-GENERATION", 2915 [ null, null, null ], 2916 [ null, null, null ], 2917 [ 104, h'', h'164f44d856dd15222fa463f202d9c60be3c69b40f7358d341cdb7b07de 2918 e170ca' ] 2919 ] 2921 Which as a CBOR encoded data item is: 2923 info (IV_2) (CBOR-encoded) (61 bytes) 2924 84 6d 49 56 2d 47 45 4e 45 52 41 54 49 4f 4e 83 f6 f6 f6 83 f6 f6 f6 83 18 2925 68 40 58 20 16 4f 44 d8 56 dd 15 22 2f a4 63 f2 02 d9 c6 0b e3 c6 9b 40 f7 2926 35 8d 34 1c db 7b 07 de e1 70 ca 2928 L is the length of IV_2, so 13 bytes. 2930 From these parameters, IV_2 is computed: 2932 IV_2 (13 bytes) 2933 ff 11 2e 1c 26 8a a2 a7 7c c3 ee 6c 4d 2935 C.2.4.2. Ciphertext Computation 2937 COSE_Encrypt0 is computed with the following parameters. Note that 2938 UAD_2 is omitted. 2940 o empty protected header 2942 o external_aad = TH_2 2944 o empty plaintext, since UAD_2 is omitted 2946 From the parameters above, the Enc_structure A_2 is computed. 2948 A_2 = 2949 [ 2950 "Encrypt0", 2951 h'', 2952 h'164f44d856dd15222fa463f202d9c60be3c69b40f7358d341cdb7b07dee170ca' 2953 ] 2955 Which encodes to the following byte string to be used as Additional 2956 Authenticated Data: 2958 A_2 (CBOR-encoded) (45 bytes) 2959 83 68 45 6e 63 72 79 70 74 30 40 58 20 16 4f 44 d8 56 dd 15 22 2f a4 63 f2 2960 02 d9 c6 0b e3 c6 9b 40 f7 35 8d 34 1c db 7b 07 de e1 70 ca 2962 The key and nonce used are defined in Appendix C.2.4.1: 2964 o key = K_2 2966 o nonce = IV_2 2968 Using the parameters above, the ciphertext CIPHERTEXT_2 can be 2969 computed: 2971 CIPHERTEXT_2 (8 bytes) 2972 ba 38 b9 a3 fc 1a 58 e9 2974 C.2.4.3. message_2 2976 From the parameter computed in Appendix C.2.4 and Appendix C.2.4.2, 2977 message_2 is computed, as the CBOR Sequence of the following items: 2978 (G_Y, C_V, CIPHERTEXT_2). 2980 message_2 = 2981 ( 2982 h'fc3b339367a5225d53a92d380323afd035d7817b6d1be47d946f6b09a9cbdc06', 2983 h'c2', 2984 h'ba38b9a3fc1a58e9' 2985 ) 2987 Which encodes to the following byte string: 2989 message_2 (CBOR Sequence) (45 bytes) 2990 58 20 fc 3b 33 93 67 a5 22 5d 53 a9 2d 38 03 23 af d0 35 d7 81 7b 6d 1b e4 2991 7d 94 6f 6b 09 a9 cb dc 06 41 c2 48 ba 38 b9 a3 fc 1a 58 e9 2993 C.2.5. Message 3 2995 Since TYPE mod 4 equals 1, C_V is not omitted from data_3. 2997 C_V (1 bytes) 2998 c2 3000 Data_3 is constructed, as the CBOR Sequence of the CBOR data item 3001 above. 3003 data_3 = 3004 ( 3005 h'c2' 3006 ) 3008 data_3 (CBOR Sequence) (2 bytes) 3009 41 c2 3011 From data_3, CIPHERTEXT_2 (Appendix C.2.4.2), and TH_2 3012 (Appendix C.2.4), compute the input to the transcript hash TH_2 = 3013 H(TH_2 , CIPHERTEXT_2, data_3), as a CBOR Sequence of these 3 data 3014 items. 3016 ( TH_2, CIPHERTEXT_2, data_3 ) (CBOR Sequence) (45 bytes) 3017 58 20 16 4f 44 d8 56 dd 15 22 2f a4 63 f2 02 d9 c6 0b e3 c6 9b 40 f7 35 8d 3018 34 1c db 7b 07 de e1 70 ca 48 ba 38 b9 a3 fc 1a 58 e9 41 c2 3020 And from there, compute the transcript hash TH_3 = SHA-256(TH_2 , 3021 CIPHERTEXT_2, data_3) 3023 TH_3 value (32 bytes) 3024 11 98 aa b3 ed db 61 b8 a1 b1 93 a9 e5 60 2b 5d 5f ea 76 bc 28 52 89 54 81 3025 b5 2b 8a f5 66 d7 fe 3027 When encoded as a CBOR bstr, that gives: 3029 TH_3 (CBOR-encoded) (34 bytes) 3030 58 20 11 98 aa b3 ed db 61 b8 a1 b1 93 a9 e5 60 2b 5d 5f ea 76 bc 28 52 89 3031 54 81 b5 2b 8a f5 66 d7 fe 3033 C.2.5.1. Key and Nonce Computation 3035 The key and nonce for calculating the ciphertext are calculated as 3036 follows, as specified in Section 3.3. 3038 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 3040 PRK = HMAC-SHA-256(salt, G_XY) 3042 Since this is the symmetric case, salt is the PSK: 3044 salt (16 bytes) 3045 a1 1f 8f 12 d0 87 6f 73 6d 2d 8f d2 6e 14 c2 de 3047 G_XY is the shared secret, and since the curve25519 is used, the ECDH 3048 shared secret is the output of the X25519 function. 3050 G_XY (32 bytes) 3051 d5 75 05 50 6d 8f 30 a8 60 a0 63 d0 1b 5b 7a d7 6a 09 4f 70 61 3b 4a e6 6c 3052 5a 90 e5 c2 1f 23 11 3054 From there, PRK is computed: 3056 PRK (32 bytes) 3057 aa b2 f1 3c cb 1a 4f f7 96 a9 7a 32 a4 d2 fb 62 47 ef 0b 6b 06 da 04 d3 d1 3058 06 39 4b 28 76 e2 8c 3060 Key K_3 is the output of HKDF-Expand(PRK, info, L). 3062 info is defined as follows: 3064 info for K_3 3065 [ 3066 10, 3067 [ null, null, null ], 3068 [ null, null, null ], 3069 [ 128, h'', h'1198aab3eddb61b8a1b193a9e5602b5d5fea76bc2852895481b52b8af5 3070 66d7fe' ] 3071 ] 3073 Which as a CBOR encoded data item is: 3075 info (K_3) (CBOR-encoded) (48 bytes) 3076 84 0a 83 f6 f6 f6 83 f6 f6 f6 83 18 80 40 58 20 11 98 aa b3 ed db 61 b8 a1 3077 b1 93 a9 e5 60 2b 5d 5f ea 76 bc 28 52 89 54 81 b5 2b 8a f5 66 d7 fe 3079 L is the length of K_3, so 16 bytes. 3081 From these parameters, K_3 is computed: 3083 K_3 (16 bytes) 3084 fe 75 e3 44 27 f8 3a ad 84 16 83 c6 6f a3 8a 62 3086 Nonce IV_3 is the output of HKDF-Expand(PRK, info, L). 3088 info is defined as follows: 3090 info for IV_3 3091 [ 3092 "IV-GENERATION", 3093 [ null, null, null ], 3094 [ null, null, null ], 3095 [ 104, h'', h'1198aab3eddb61b8a1b193a9e5602b5d5fea76bc2852895481b52b8af5 3096 66d7fe' ] 3097 ] 3098 Which as a CBOR encoded data item is: 3100 info (IV_3) (CBOR-encoded) (61 bytes) 3101 84 6d 49 56 2d 47 45 4e 45 52 41 54 49 4f 4e 83 f6 f6 f6 83 f6 f6 f6 83 18 3102 68 40 58 20 11 98 aa b3 ed db 61 b8 a1 b1 93 a9 e5 60 2b 5d 5f ea 76 bc 28 3103 52 89 54 81 b5 2b 8a f5 66 d7 fe 3105 L is the length of IV_3, so 13 bytes. 3107 From these parameters, IV_3 is computed: 3109 IV_3 (13 bytes) 3110 60 0a 33 b4 16 de 08 23 52 67 71 ec 8a 3112 C.2.5.2. Ciphertext Computation 3114 COSE_Encrypt0 is computed with the following parameters. Note that 3115 PAD_2 is omitted. 3117 o empty protected header 3119 o external_aad = TH_3 3121 o empty plaintext, since PAD_2 is omitted 3123 From the parameters above, the Enc_structure A_3 is computed. 3125 A_3 = 3126 [ 3127 "Encrypt0", 3128 h'', 3129 h'1198aab3eddb61b8a1b193a9e5602b5d5fea76bc2852895481b52b8af566d7fe' 3130 ] 3132 Which encodes to the following byte string to be used as Additional 3133 Authenticated Data: 3135 A_3 (CBOR-encoded) (45 bytes) 3136 83 68 45 6e 63 72 79 70 74 30 40 58 20 11 98 aa b3 ed db 61 b8 a1 b1 93 a9 3137 e5 60 2b 5d 5f ea 76 bc 28 52 89 54 81 b5 2b 8a f5 66 d7 fe 3139 The key and nonce used are defined in Appendix C.2.5.1: 3141 o key = K_3 3143 o nonce = IV_3 3144 Using the parameters above, the ciphertext CIPHERTEXT_3 can be 3145 computed: 3147 CIPHERTEXT_3 (8 bytes) 3148 51 29 07 92 61 45 40 04 3150 C.2.5.3. message_3 3152 From the parameter computed in Appendix C.2.5 and Appendix C.2.5.2, 3153 message_3 is computed, as the CBOR Sequence of the following items: 3154 (C_V, CIPHERTEXT_3). 3156 message_3 = 3157 ( 3158 h'c2', 3159 h'5129079261454004' 3160 ) 3162 Which encodes to the following byte string: 3164 message_3 (CBOR Sequence) (11 bytes) 3165 41 c2 48 51 29 07 92 61 45 40 04 3167 C.2.5.4. OSCORE Security Context Derivation 3169 From the previous message exchange, the Common Security Context for 3170 OSCORE [RFC8613] can be derived, as specified in Section 3.3.1. 3172 First af all, TH_4 is computed: TH_4 = H( TH_3, CIPHERTEXT_3 ), where 3173 the input to the hash function is the CBOR Sequence of TH_3 and 3174 CIPHERTEXT_3 3176 ( TH_3, CIPHERTEXT_3 ) 3177 (CBOR Sequence) (43 bytes) 3178 58 20 11 98 aa b3 ed db 61 b8 a1 b1 93 a9 e5 60 2b 5d 5f ea 76 bc 28 52 89 3179 54 81 b5 2b 8a f5 66 d7 fe 48 51 29 07 92 61 45 40 04 3181 And from there, compute the transcript hash TH_4 = SHA-256( TH_3, 3182 CIPHERTEXT_3 ) 3184 TH_4 value (32 bytes) 3185 df 7c 9b 06 f5 dc 0e e8 86 0b 39 6c 78 c5 be b7 57 41 3f a7 b6 a9 cf 28 3d 3186 db 4c d4 c1 fd e4 3c 3188 When encoded as a CBOR bstr, that gives: 3190 TH_4 (CBOR-encoded) (34 bytes) 3191 58 20 df 7c 9b 06 f5 dc 0e e8 86 0b 39 6c 78 c5 be b7 57 41 3f a7 b6 a9 cf 3192 28 3d db 4c d4 c1 fd e4 3c 3194 To derive the Master Secret and Master Salt the same HKDF-Expand 3195 (PRK, info, L) is used, with different info and L. 3197 For Master Secret: 3199 L for Master Secret = 16 3201 Info for Master Secret = 3202 [ 3203 "OSCORE Master Secret", 3204 [ null, null, null ], 3205 [ null, null, null ], 3206 [ 128, h'', h'df7c9b06f5dc0ee8860b396c78c5beb757413fa7b6a9cf283ddb4cd4c1 3207 fde43c' ] 3208 ] 3210 When encoded as a CBOR bstr, that gives: 3212 info (OSCORE Master Secret) (CBOR-encoded) (68 bytes) 3213 84 74 4f 53 43 4f 52 45 20 4d 61 73 74 65 72 20 53 65 63 72 65 74 83 f6 f6 3214 f6 83 f6 f6 f6 83 18 80 40 58 20 df 7c 9b 06 f5 dc 0e e8 86 0b 39 6c 78 c5 3215 be b7 57 41 3f a7 b6 a9 cf 28 3d db 4c d4 c1 fd e4 3c 3217 Finally, the Master Secret value computed is: 3219 OSCORE Master Secret (16 bytes) 3220 8d 36 8f 09 26 2d c5 52 7f e7 19 e6 6c 91 63 75 3222 For Master Salt: 3224 L for Master Secret = 8 3226 Info for Master Salt = 3227 [ 3228 "OSCORE Master Salt", 3229 [ null, null, null ], 3230 [ null, null, null ], 3231 [ 64, h'', h'df7c9b06f5dc0ee8860b396c78c5beb757413fa7b6a9cf283ddb4cd4c1f 3232 de43c' ] 3233 ] 3235 When encoded as a CBOR bstr, that gives: 3237 info (OSCORE Master Salt) (CBOR-encoded) (66 bytes) 3238 84 72 4f 53 43 4f 52 45 20 4d 61 73 74 65 72 20 53 61 6c 74 83 f6 f6 f6 83 3239 f6 f6 f6 83 18 40 40 58 20 df 7c 9b 06 f5 dc 0e e8 86 0b 39 6c 78 c5 be b7 3240 57 41 3f a7 b6 a9 cf 28 3d db 4c d4 c1 fd e4 3c 3242 Finally, the Master Secret value computed is: 3244 OSCORE Master Salt (8 bytes) 3245 4d b7 06 58 c5 e9 9f b6 3247 The Client's Sender ID takes the value of C_V: 3249 Client's OSCORE Sender ID (1 bytes) 3250 c2 3252 The Server's Sender ID takes the value of C_U: 3254 Server's OSCORE Sender ID (1 bytes) 3255 c1 3257 The algorithms are those negociated in the cipher suite: 3259 AEAD Algorithm 3260 10 3262 HMAC Algorithm 3263 5 3265 Acknowledgments 3267 The authors want to thank Alessandro Bruni, Martin Disch, Theis 3268 Groenbech Petersen, Dan Harkins, Klaus Hartke, Russ Housley, 3269 Alexandros Krontiris, Ilari Liusvaara, Karl Norrman, Salvador Perez, 3270 Eric Rescorla, Michael Richardson, Thorvald Sahl Joergensen, Jim 3271 Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav Smyshlyaev, 3272 Valery Smyslov, Rene Struik, and Erik Thormarker for reviewing and 3273 commenting on intermediate versions of the draft. We are especially 3274 indebted to Jim Schaad for his continuous reviewing and 3275 implementation of different versions of the draft. 3277 Authors' Addresses 3279 Goeran Selander 3280 Ericsson AB 3282 Email: goran.selander@ericsson.com 3283 John Mattsson 3284 Ericsson AB 3286 Email: john.mattsson@ericsson.com 3288 Francesca Palombini 3289 Ericsson AB 3291 Email: francesca.palombini@ericsson.com