idnits 2.17.1 draft-ietf-lake-edhoc-03.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 3 instances of too long lines in the document, the longest one being 109 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 (December 18, 2020) is 1217 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) -- Looks like a reference, but probably isn't: '6' on line 1454 -- Looks like a reference, but probably isn't: '5' on line 1454 -- Looks like a reference, but probably isn't: '9' on line 1450 -- Looks like a reference, but probably isn't: '7' on line 1454 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-11 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-08 ** Downref: Normative reference to an Informational draft: draft-ietf-lake-reqs (ref. 'I-D.ietf-lake-reqs') ** 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) ** Downref: Normative reference to an Informational RFC: RFC 8376 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-36 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-26 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-security-protocol-comparison-05 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-39 == Outdated reference: A later version (-02) exists of draft-palombini-core-oscore-edhoc-01 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-02 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 5 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: June 21, 2021 Ericsson AB 6 December 18, 2020 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-ietf-lake-edhoc-03 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 size 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 June 21, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . 5 58 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 6 59 1.3. Terminology and Requirements Language . . . . . . . . . . 6 60 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.2. Method and Correlation . . . . . . . . . . . . . . . . . 9 64 3.3. Authentication Parameters . . . . . . . . . . . . . . . . 11 65 3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 14 66 3.5. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 16 67 3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 16 68 3.7. Communication of Protocol Features . . . . . . . . . . . 17 69 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 17 70 4.1. EDHOC-Exporter Interface . . . . . . . . . . . . . . . . 19 71 5. Message Formatting and Processing . . . . . . . . . . . . . . 20 72 5.1. Encoding of bstr_identifier . . . . . . . . . . . . . . . 20 73 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 21 74 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 23 75 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 26 76 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29 77 6.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 29 78 7. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 32 79 7.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 32 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 81 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 35 82 8.2. Cryptographic Considerations . . . . . . . . . . . . . . 36 83 8.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 37 84 8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 37 85 8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 38 86 8.6. Implementation Considerations . . . . . . . . . . . . . . 38 87 8.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 39 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 89 9.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 39 90 9.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 41 91 9.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 41 92 9.4. Media Types Registry . . . . . . . . . . . . . . . . . . 41 93 9.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 42 94 9.6. Expert Review Instructions . . . . . . . . . . . . . . . 42 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 43 97 10.2. Informative References . . . . . . . . . . . . . . . . . 45 98 Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 47 99 A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 47 100 A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 48 101 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 48 102 B.1. Test Vectors for EDHOC Authenticated with Signature Keys 103 (x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 48 104 B.2. Test Vectors for EDHOC Authenticated with Static Diffie- 105 Hellman Keys . . . . . . . . . . . . . . . . . . . . . . 63 106 Appendix C. Applicability Statement Template . . . . . . . . . . 76 107 C.1. Use of EDHOC in the XX Protocol . . . . . . . . . . . . . 76 108 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 77 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 111 1. Introduction 113 Security at the application layer provides an attractive option for 114 protecting Internet of Things (IoT) deployments, for example where 115 protection needs to work over a variety of underlying protocols. IoT 116 devices may be constrained in various ways, including memory, 117 storage, processing capacity, and energy [RFC7228]. A method for 118 protecting individual messages at the application layer suitable for 119 constrained devices, is provided by CBOR Object Signing and 120 Encryption (COSE) [RFC8152]), which builds on the Concise Binary 121 Object Representation (CBOR) [RFC8949]. Object Security for 122 Constrained RESTful Environments (OSCORE) [RFC8613] is a method for 123 application-layer protection of the Constrained Application Protocol 124 (CoAP), using COSE. 126 In order for a communication session to provide forward secrecy, the 127 communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH) 128 key exchange protocol with ephemeral keys, from which shared key 129 material can be derived. This document specifies Ephemeral Diffie- 130 Hellman Over COSE (EDHOC), a lightweight key exchange protocol 131 providing perfect forward secrecy and identity protection. 132 Authentication is based on credentials established out of band, e.g. 133 from a trusted third party, such as an Authorization Server as 134 specified by [I-D.ietf-ace-oauth-authz]. The construction provided 135 by EDHOC can be applied to authenticate raw public keys (RPK) and 136 public key certificates. This version of the protocol is focusing on 137 RPK and certificates by reference which is the initial focus for the 138 LAKE WG (see Section 2.2 of [I-D.ietf-lake-reqs]). 140 After successful completion of the EDHOC protocol, application keys 141 and other application specific data can be derived using the EDHOC- 142 Exporter interface. A main use case for EDHOC is to establish an 143 OSCORE security context. EDHOC uses COSE for cryptography, CBOR for 144 encoding, and CoAP for transport. By reusing existing libraries, the 145 additional code footprint can be kept very low. 147 EDHOC is designed for highly constrained settings making it 148 especially suitable for low-power wide area networks [RFC8376] such 149 as Cellular IoT, 6TiSCH, and LoRaWAN. Compared to the DTLS 1.3 150 handshake [I-D.ietf-tls-dtls13] with ECDH and connection ID, the 151 number of bytes in EDHOC + CoAP can be less than 1/6 when RPK 152 authentication is used, see 153 [I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows two 154 examples of message sizes for EDHOC with different kinds of 155 authentication keys and different COSE header parameters for 156 identification: static Diffie-Hellman keys identified by 'kid' 157 [RFC8152], and X.509 signature certificates identified by a hash 158 value using 'x5t' [I-D.ietf-cose-x509]. Further reductions of 159 message sizes are possible, for example by eliding redundant length 160 indications. 162 ================================= 163 kid x5t 164 --------------------------------- 165 message_1 37 37 166 message_2 46 117 167 message_3 20 91 168 ---------------------------------- 169 Total 103 245 170 ================================= 172 Figure 1: Example of message sizes in bytes. 174 The ECDH exchange and the key derivation follow known protocol 175 constructions such as [SIGMA], NIST SP-800-56A [SP-800-56A], and 176 Extract-and-Expand [RFC5869]. CBOR [RFC8949] and COSE [RFC8152] are 177 used to implement these standards. The use of COSE provides crypto 178 agility and enables use of future algorithms and headers designed for 179 constrained IoT. 181 This document is organized as follows: Section 2 describes how EDHOC 182 authenticated with digital signatures builds on SIGMA-I, Section 3 183 specifies general properties of EDHOC, including message flow and 184 formatting of the ephemeral public keys, Section 4 specifies the key 185 derivation, Section 5 specifies EDHOC with signature key and static 186 Diffie-Hellman key authentication, Section 6 specifies the EDHOC 187 error message, and Section 7 describes how EDHOC can be transferred 188 in CoAP and used to establish an OSCORE security context. 190 1.1. Rationale for EDHOC 192 Many constrained IoT systems today do not use any security at all, 193 and when they do, they often do not follow best practices. One 194 reason is that many current security protocols are not designed with 195 constrained IoT in mind. Constrained IoT systems often deal with 196 personal information, valuable business data, and actuators 197 interacting with the physical world. Not only do such systems need 198 security and privacy, they often need end-to-end protection with 199 source authentication and perfect forward secrecy. EDHOC and OSCORE 200 [RFC8613] enables security following current best practices to 201 devices and systems where current security protocols are impractical. 203 EDHOC is optimized for small message sizes and can therefore be sent 204 over a small number of radio frames. The message size of a key 205 exchange protocol may have a large impact on the performance of an 206 IoT deployment, especially in constrained environments. For example, 207 in a network bootstrapping setting a large number of devices turned 208 on in a short period of time may result in large latencies caused by 209 parallel key exchanges. Requirements on network formation time in 210 constrained environments can be translated into key exchange 211 overhead. In network technologies with duty cycle, each additional 212 frame significantly increases the latency even if no other devices 213 are transmitting. 215 Power consumption for wireless devices is highly dependent on message 216 transmission, listening, and reception. For devices that only send a 217 few bytes occasionally, the battery lifetime may be impacted by a 218 heavy key exchange protocol. A key exchange may need to be executed 219 more than once, e.g. due to a device rebooting or for security 220 reasons such as perfect forward secrecy. 222 EDHOC is adapted to primitives and protocols designed for the 223 Internet of Things: EDHOC is built on CBOR and COSE which enables 224 small message overhead and efficient parsing in constrained devices. 225 EDHOC is not bound to a particular transport layer, but it is 226 recommended to transport the EDHOC message in CoAP payloads. EDHOC 227 is not bound to a particular communication security protocol but 228 works off-the-shelf with OSCORE [RFC8613] providing the necessary 229 input parameters with required properties. Maximum code complexity 230 (ROM/Flash) is often a constraint in many devices and by reusing 231 already existing libraries, the additional code footprint for EDHOC + 232 OSCORE can be kept very low. 234 1.2. Use of EDHOC 236 EDHOC is designed as a lightweight AKE for OSCORE, i.e. to provide 237 authentication and session key establishment for IoT use cases such 238 as those built on CoAP [RFC7252]. CoAP is a specialized web transfer 239 protocol for use with constrained nodes and networks, providing a 240 request/response interaction model between application endpoints. As 241 such, EDHOC is targeting a large variety of use cases involving 242 'things' with embedded microcontrollers, sensors and actuators. 244 A typical setting is when one of the endpoints is constrained or in a 245 constrained network, and the other endpoint is a node on the Internet 246 (such as a mobile phone) or at the edge of the constrained network 247 (such as a gateway). Thing-to-thing interactions over constrained 248 networks are also relevant since both endpoints would then benefit 249 from the lightweight properties of the protocol. EDHOC could e.g. be 250 run when a device/device(s) connect(s) for the first time, or to 251 establish fresh keys which are not compromised by a later compromise 252 of the long-term keys. (Further security properties are described in 253 Section 8.1.) 255 1.3. Terminology and Requirements Language 257 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 258 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 259 "OPTIONAL" in this document are to be interpreted as described in BCP 260 14 [RFC2119] [RFC8174] when, and only when, they appear in all 261 capitals, as shown here. 263 Readers are expected to be familiar with the terms and concepts 264 described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE 265 [RFC8152], and CDDL [RFC8610]. The Concise Data Definition Language 266 (CDDL) is used to express CBOR data structures [RFC8949]. Examples 267 of CBOR and CDDL are provided in Appendix A.1. 269 2. EDHOC Outline 271 EDHOC specifies different authentication methods of the Diffie- 272 Hellman key exchange: digital signatures and static Diffie-Hellman 273 keys. This section outlines the digital signature based method. 274 Further details of protocol elements and other authentication methods 275 are provided in the remainder of this document. 277 SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a 278 large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS 279 1.3 [RFC8446], EDHOC authenticated with digital signatures is built 280 on a variant of the SIGMA protocol which provide identity protection 281 of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC 282 implements the SIGMA-I variant as MAC-then-Sign. The SIGMA-I 283 protocol using an authenticated encryption algorithm is shown in 284 Figure 2. 286 Initiator Responder 287 | G_X | 288 +-------------------------------------------------------->| 289 | | 290 | G_Y, AEAD( K_2; ID_CRED_R, Sig(R; CRED_R, G_X, G_Y) ) | 291 |<--------------------------------------------------------+ 292 | | 293 | AEAD( K_3; ID_CRED_I, Sig(I; CRED_I, G_Y, G_X) ) | 294 +-------------------------------------------------------->| 295 | | 297 Figure 2: Authenticated encryption variant of the SIGMA-I protocol. 299 The parties exchanging messages are called Initiator (I) and 300 Responder (R). They exchange ephemeral public keys, compute the 301 shared secret, and derive symmetric application keys. 303 o G_X and G_Y are the ECDH ephemeral public keys of I and R, 304 respectively. 306 o CRED_I and CRED_R are the credentials containing the public 307 authentication keys of I and R, respectively. 309 o ID_CRED_I and ID_CRED_R are data enabling the recipient party to 310 retrieve the credential of I and R, respectively. 312 o Sig(I; . ) and S(R; . ) denote signatures made with the private 313 authentication key of I and R, respectively. 315 o AEAD(K; . ) denotes authenticated encryption with additional data 316 using a key K derived from the shared secret. 318 In order to create a "full-fledged" protocol some additional protocol 319 elements are needed. EDHOC adds: 321 o Explicit connection identifiers C_I, C_R chosen by I and R, 322 respectively, enabling the recipient to find the protocol state. 324 o Transcript hashes (hashes of message data) TH_2, TH_3, TH_4 used 325 for key derivation and as additional authenticated data. 327 o Computationally independent keys derived from the ECDH shared 328 secret and used for authenticated encryption of different 329 messages. 331 o Verification of a common preferred cipher suite: 333 * The Initiator lists supported cipher suites in order of 334 preference 336 * The Responder verifies that the selected cipher suite is the 337 first supported cipher suite 339 o Method types and error handling. 341 o Transport of opaque auxiliary data. 343 EDHOC is designed to encrypt and integrity protect as much 344 information as possible, and all symmetric keys are derived using as 345 much previous information as possible. EDHOC is furthermore designed 346 to be as compact and lightweight as possible, in terms of message 347 sizes, processing, and the ability to reuse already existing CBOR, 348 COSE, and CoAP libraries. 350 To simplify for implementors, the use of CBOR and COSE in EDHOC is 351 summarized in Appendix A and test vectors including CBOR diagnostic 352 notation are given in Appendix B. 354 3. Protocol Elements 356 3.1. General 358 EDHOC consists of three messages (message_1, message_2, message_3) 359 between Initiator and Responder, plus an EDHOC error message. EDHOC 360 messages are CBOR Sequences [RFC8742], see Figure 3. The protocol 361 elements in the figure are introduced in the following sections. 362 Message formatting and processing is specified in Section 5 and 363 Section 6. An implementation may support only Initiator or only 364 Responder. 366 Application data is protected using the agreed application algorithms 367 (AEAD, hash) in the selected cipher suite (see Section 3.4) and the 368 application can make use of the established connection identifiers 369 C_I and C_R (see Section 3.2.4). EDHOC may be used with the media 370 type application/edhoc defined in Section 9. 372 The Initiator can derive symmetric application keys after creating 373 EDHOC message_3, see Section 4.1. Application protected data can 374 therefore be sent in parallel with EDHOC message_3, optionally in the 375 same CoAP message [I-D.palombini-core-oscore-edhoc]. 377 Initiator Responder 378 | METHOD_CORR, SUITES_I, G_X, C_I, AD_1 | 379 +------------------------------------------------------------------>| 380 | message_1 | 381 | | 382 | C_I, G_Y, C_R, Enc(K_2e; ID_CRED_R, Signature_or_MAC_2, AD_2) | 383 |<------------------------------------------------------------------+ 384 | message_2 | 385 | | 386 | C_R, AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, AD_3) | 387 +------------------------------------------------------------------>| 388 | message_3 | 390 Figure 3: EDHOC Message Flow 392 3.2. Method and Correlation 394 The first data item of message_1, METHOD_CORR (see Section 5.2.1), is 395 an integer specifying the method and the correlation properties of 396 the transport, which are described in this section. 398 3.2.1. Method 400 EDHOC supports authentication with signature or static Diffie-Hellman 401 keys, as defined in the four authentication methods: 0, 1, 2, and 3, 402 see Figure 4. (Method 0 corresponds to the case outlined in 403 Section 2 where both Initiator and Responder authenticate with 404 signature keys.) 406 An implementation may support only a single method. The Initiator 407 and the Responder need to have agreed on a single method to be used 408 for EDHOC, see Appendix C. 410 +-------+-------------------+-------------------+-------------------+ 411 | Value | Initiator | Responder | Reference | 412 +-------+-------------------+-------------------+-------------------+ 413 | 0 | Signature Key | Signature Key | [[this document]] | 414 | 1 | Signature Key | Static DH Key | [[this document]] | 415 | 2 | Static DH Key | Signature Key | [[this document]] | 416 | 3 | Static DH Key | Static DH Key | [[this document]] | 417 +-------+-------------------+-------------------+-------------------+ 419 Figure 4: Method Types 421 3.2.2. Connection Identifiers 423 EDHOC includes connection identifiers (C_I, C_R) to correlate 424 messages. The connection identifiers C_I and C_R do not have any 425 cryptographic purpose in EDHOC. They contain information 426 facilitating retrieval of the protocol state and may therefore be 427 very short. One byte connection identifiers are realistic in many 428 scenarios as most constrained devices only have a few connections. 429 In cases where a node only has one connection, the identifiers may 430 even be the empty byte string. 432 The connection identifier MAY be used with an application protocol 433 (e.g. OSCORE) for which EDHOC establishes keys, in which case the 434 connection identifiers SHALL adhere to the requirements for that 435 protocol. Each party choses a connection identifier it desires the 436 other party to use in outgoing messages. (For OSCORE this results in 437 the endpoint selecting its Recipient ID, see Section 3.1 of 438 [RFC8613]). 440 3.2.3. Transport 442 Cryptographically, EDHOC does not put requirements on the lower 443 layers. EDHOC is not bound to a particular transport layer, and can 444 be used in environments without IP. The transport is responsible to 445 handle message loss, reordering, message duplication, fragmentation, 446 and denial of service protection, where necessary. 448 The Initiator and the Responder need to have agreed on a transport to 449 be used for EDHOC, see Appendix C. It is recommended to transport 450 EDHOC in CoAP payloads, see Section 7. 452 3.2.4. Message Correlation 454 If the transport provides a mechanism for correlating messages, some 455 of the connection identifiers may be omitted. There are four cases: 457 o corr = 0, the transport does not provide a correlation mechanism. 459 o corr = 1, the transport provides a correlation mechanism that 460 enables the Responder to correlate message_2 and message_1. 462 o corr = 2, the transport provides a correlation mechanism that 463 enables the Initiator to correlate message_3 and message_2. 465 o corr = 3, the transport provides a correlation mechanism that 466 enables both parties to correlate all three messages. 468 For example, if the key exchange is transported over CoAP, the CoAP 469 Token can be used to correlate messages, see Section 7.1. 471 3.3. Authentication Parameters 473 3.3.1. Authentication Keys 475 The authentication key MUST be a signature key or static Diffie- 476 Hellman key. The Initiator and the Responder MAY use different types 477 of authentication keys, e.g. one uses a signature key and the other 478 uses a static Diffie-Hellman key. When using a signature key, the 479 authentication is provided by a signature. When using a static 480 Diffie-Hellman key the authentication is provided by a Message 481 Authentication Code (MAC) computed from an ephemeral-static ECDH 482 shared secret which enables significant reductions in message sizes. 483 The MAC is implemented with an AEAD algorithm. When using a static 484 Diffie-Hellman keys the Initiator's and Responder's private 485 authentication keys are called I and R, respectively, and the public 486 authentication keys are called G_I and G_R, respectively. 488 o Only the Responder SHALL have access to the Responder's private 489 authentication key. 491 o Only the Initiator SHALL have access to the Initiator's private 492 authentication key. 494 3.3.2. Identities 496 EDHOC assumes the existence of mechanisms (certification authority, 497 trusted third party, manual distribution, etc.) for specifying and 498 distributing authentication keys and identities. Policies are set 499 based on the identity of the other party, and parties typically only 500 allow connections from a specific identity or a small restricted set 501 of identities. For example, in the case of a device connecting to a 502 network, the network may only allow connections from devices which 503 authenticate with certificates having a particular range of serial 504 numbers in the subject field and signed by a particular CA. On the 505 other side, the device may only be allowed to connect to a network 506 which authenticate with a particular public key (information of which 507 may be provisioned, e.g., out of band or in the Auxiliary Data, see 508 Section 3.6). 510 The EDHOC implementation must be able to receive and enforce 511 information from the application about what is the intended peer 512 endpoint, and in particular whether it is a specific identity or a 513 set of identities. 515 o When a Public Key Infrastructure (PKI) is used, the trust anchor 516 is a Certification Authority (CA) certificate, and the identity is 517 the subject whose unique name (e.g. a domain name, NAI, or EUI) is 518 included in the endpoint's certificate. Before running EDHOC each 519 party needs at least one CA public key certificate, or just the 520 public key, and a specific identity or set of identities it is 521 allowed to communicate with. Only validated public-key 522 certificates with an allowed subject name, as specified by the 523 application, are to be accepted. EDHOC provides proof that the 524 other party possesses the private authentication key corresponding 525 to the public authentication key in its certificate. The 526 certification path provides proof that the subject of the 527 certificate owns the public key in the certificate. 529 o When public keys are used but not with a PKI (RPK, self-signed 530 certificate), the trust anchor is the public authentication key of 531 the other party. In this case, the identity is typically directly 532 associated to the public authentication key of the other party. 533 For example, the name of the subject may be a canonical 534 representation of the public key. Alternatively, if identities 535 can be expressed in the form of unique subject names assigned to 536 public keys, then a binding to identity can be achieved by 537 including both public key and associated subject name in the 538 protocol message computation: CRED_I or CRED_R may be a self- 539 signed certificate or COSE_Key containing the public 540 authentication key and the subject name, see Section 3.3.3. 541 Before running EDHOC, each endpoint needs a specific public 542 authentication key/unique associated subject name, or a set of 543 public authentication keys/unique associated subject names, which 544 it is allowed to communicate with. EDHOC provides proof that the 545 other party possesses the private authentication key corresponding 546 to the public authentication key. 548 3.3.3. Authentication Credentials 550 The authentication credentials, CRED_I and CRED_R, contain the public 551 authentication key of the Initiator and the Responder, respectively. 552 The Initiator and the Responder MAY use different types of 553 credentials, e.g. one uses an RPK and the other uses a public key 554 certificate. 556 The credentials CRED_I and CRED_R are signed or MAC:ed (depending on 557 method) by the Initiator and the Responder, respectively, see 558 Section 5.4 and Section 5.3. 560 When the credential is a certificate, CRED_x is an end-entity 561 certificate (i.e. not the certificate chain) encoded as a CBOR bstr. 562 In X.509 certificates, signature keys typically have key usage 563 "digitalSignature" and Diffie-Hellman keys typically have key usage 564 "keyAgreement" 566 When the credential is a COSE_Key, CRED_x is a CBOR map only 567 containing specific fields from the COSE_Key: 569 o For COSE_Keys of type OKP the CBOR map SHALL only include the 570 parameters 1 (kty), -1 (crv), and -2 (x-coordinate). 572 o For COSE_Keys of type EC2 the CBOR map SHALL only include the 573 parameters 1 (kty), -1 (crv), -2 (x-coordinate), and -3 574 (y-coordinate). 576 To prevent misbinding attacks in systems where an attacker can 577 register public keys without proving knowledge of the private key, 578 SIGMA [SIGMA] enforces a MAC to be calculated over the "Identity", 579 which in case of a X.509 certificate would be the 'subject' and 580 'subjectAltName' fields. EDHOC follows SIGMA by calculating a MAC 581 over the whole certificate. While SIGMA paper only focuses on the 582 identity, the same principle is true for any information such as 583 policies connected to the public key. 585 If the parties have agreed on an identity besides the public key, the 586 identity is included in the CBOR map with the label "subject name", 587 otherwise the subject name is the empty text string. The parameters 588 SHALL be encoded in decreasing order with int labels first and text 589 string labels last. An example of CRED_x when the RPK contains an 590 X25519 static Diffie-Hellman key and the parties have agreed on an 591 EUI-64 identity is shown below: 593 CRED_x = { 594 1: 1, 595 -1: 4, 596 -2: h'b1a3e89460e88d3a8d54211dc95f0b90 597 3ff205eb71912d6db8f4af980d2db83a', 598 "subject name" : "42-50-31-FF-EF-37-32-39" 599 } 601 3.3.4. Identification of Credentials 603 ID_CRED_I and ID_CRED_R are identifiers of the public authentication 604 keys of the Initiator and the Responder, respectively. ID_CRED_I and 605 ID_CRED_R do not have any cryptographic purpose in EDHOC. 607 o ID_CRED_R is intended to facilitate for the Initiator to retrieve 608 the Responder's public authentication key. 610 o ID_CRED_I is intended to facilitate for the Responder to retrieve 611 the Initiator's public authentication key. 613 The identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, i.e. 614 CBOR maps containing COSE Common Header Parameters, see Section 3.1 615 of [RFC8152]). In the following we give some examples of COSE 616 header_maps. 618 Raw public keys are most optimally stored as COSE_Key objects and 619 identified with a 'kid' parameter: 621 o ID_CRED_x = { 4 : kid_x }, where kid_x : bstr, for x = I or R. 623 Public key certificates can be identified in different ways. Header 624 parameters for identifying X.509 certificates are defined in 625 [I-D.ietf-cose-x509], for example: 627 o by a hash value with the 'x5t' parameter; 629 * ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, 631 o by a URL with the 'x5u' parameter; 633 * ID_CRED_x = { 35 : uri }, for x = I or R, 635 ID_CRED_x MAY contain the actual credential used for authentication, 636 CRED_x. It is RECOMMENDED that they uniquely identify the public 637 authentication key as the recipient may otherwise have to try several 638 keys. ID_CRED_I and ID_CRED_R are transported in the ciphertext, see 639 Section 5.4 and Section 5.3. 641 When ID_CRED_x does not contain the actual credential it may be very 642 short. One byte credential identifiers are realistic in many 643 scenarios as most constrained devices only have a few keys. In cases 644 where a node only has one key, the identifier may even be the empty 645 byte string. 647 3.4. Cipher Suites 649 An EDHOC cipher suite consists of an ordered set of COSE code points 650 from the "COSE Algorithms" and "COSE Elliptic Curves" registries: 652 o EDHOC AEAD algorithm 654 o EDHOC hash algorithm 656 o EDHOC ECDH curve 657 o EDHOC signature algorithm 659 o EDHOC signature algorithm curve 661 o Application AEAD algorithm 663 o Application hash algorithm 665 Each cipher suite is identified with a pre-defined int label. 667 EDHOC can be used with all algorithms and curves defined for COSE. 668 Implementation can either use one of the pre-defined cipher suites 669 (Section 9.1) or use any combination of COSE algorithms to define 670 their own private cipher suite. Private cipher suites can be 671 identified with any of the four values -24, -23, -22, -21. 673 The following cipher suites are for constrained IoT where message 674 overhead is a very important factor: 676 0. ( 10, -16, 4, -8, 6, 10, -16 ) 677 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519, 678 AES-CCM-16-64-128, SHA-256) 680 1. ( 30, -16, 4, -8, 6, 10, -16 ) 681 (AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519, 682 AES-CCM-16-64-128, SHA-256) 684 2. ( 10, -16, 1, -7, 1, 10, -16 ) 685 (AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256, 686 AES-CCM-16-64-128, SHA-256) 688 3. ( 30, -16, 1, -7, 1, 10, -16 ) 689 (AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256, 690 AES-CCM-16-64-128, SHA-256) 692 The following cipher suite is for general non-constrained 693 applications. It uses very high performance algorithms that also are 694 widely supported: 696 4. ( 1, -16, 4, -7, 1, 1, -16 ) 697 (A128GCM, SHA-256, X25519, ES256, P-256, 698 A128GCM, SHA-256) 700 The following cipher suite is for high security application such as 701 government use and financial applications. It is compatible with the 702 CNSA suite [CNSA]. 704 5. ( 3, -43, 2, -35, 2, 3, -43 ) 705 (A256GCM, SHA-384, P-384, ES384, P-384, 706 A256GCM, SHA-384) 708 The different methods use the same cipher suites, but some algorithms 709 are not used in some methods. The EDHOC signature algorithm and the 710 EDHOC signature algorithm curve are not used in methods without 711 signature authentication. 713 The Initiator needs to have a list of cipher suites it supports in 714 order of preference. The Responder needs to have a list of cipher 715 suites it supports. SUITES_I is a CBOR array containing cipher 716 suites that the Initiator supports. SUITES_I is formatted and 717 processed as detailed in Section 5.2.1 to secure the cipher suite 718 negotation. 720 3.5. Ephemeral Public Keys 722 The ECDH ephemeral public keys are formatted as a COSE_Key of type 723 EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only 724 the 'x' parameter is included G_X and G_Y. For Elliptic Curve Keys 725 of type EC2, compact representation as per [RFC6090] MAY be used also 726 in the COSE_Key. If the COSE implementation requires an 'y' 727 parameter, any of the possible values of the y-coordinate can be 728 used, see Appendix C of [RFC6090]. COSE [RFC8152] always use compact 729 output for Elliptic Curve Keys of type EC2. 731 3.6. Auxiliary Data 733 In order to reduce round trips and number of messages, and in some 734 cases also streamline processing, certain security applications may 735 be integrated into EDHOC by transporting auxiliary data together with 736 the messages. One example is the transport of third-party 737 authorization information protected outside of EDHOC 738 [I-D.selander-ace-ake-authz]. Another example is the embedding of a 739 certificate enrolment request or a newly issued certificate. 741 EDHOC allows opaque auxiliary data (AD) to be sent in the EDHOC 742 messages. Unprotected Auxiliary Data (AD_1, AD_2) may be sent in 743 message_1 and message_2, respectively. Protected Auxiliary Data 744 (AD_3) may be sent in message_3. 746 Since data carried in AD_1 and AD_2 may not be protected, and the 747 content of AD_3 is available to both the Initiator and the Responder, 748 special considerations need to be made such that the availability of 749 the data a) does not violate security and privacy requirements of the 750 service which uses this data, and b) does not violate the security 751 properties of EDHOC. 753 3.7. Communication of Protocol Features 755 EDHOC allows the communication or negotiation of various protocol 756 features during the execution of the protocol. 758 o The Initiator proposes a cipher suite (see Section 3.4), and the 759 Responder either accepts or rejects, and may make a counter 760 proposal. 762 o The Initiator decides on the correlation parameter corr (see 763 Section 3.2.4). This is typically given by the transport which 764 the Initiator and the Responder have agreed on beforehand. The 765 Responder either accepts or rejects. 767 o The Initiator decides on the method parameter, see Figure 4. The 768 Responder either accepts or rejects. 770 o The Initiator and the Responder decide on the representation of 771 the identifier of their respective credentials, ID_CRED_I and 772 ID_CRED_R. The decision is reflected by the label used in the 773 CBOR map, see for example Section 3.3.4. 775 Editor's note: This section needs to be aligned with Appendix C. 777 4. Key Derivation 779 EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm 780 in the selected cipher suite to derive keys. Extract is used to 781 derive fixed-length uniformly pseudorandom keys (PRK) from ECDH 782 shared secrets. Expand is used to derive additional output keying 783 material (OKM) from the PRKs. The PRKs are derived using Extract. 785 PRK = Extract( salt, IKM ) 787 If the EDHOC hash algorithm is SHA-2, then Extract( salt, IKM ) = 788 HKDF-Extract( salt, IKM ) [RFC5869]. If the EDHOC hash algorithm is 789 SHAKE128, then Extract( salt, IKM ) = KMAC128( salt, IKM, 256, "" ). 790 If the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM ) = 791 KMAC256( salt, IKM, 512, "" ). 793 PRK_2e is used to derive key and IV to encrypt message_2. PRK_3e2m 794 is used to derive keys and IVs produce a MAC in message_2 and to 795 encrypt message_3. PRK_4x3m is used to derive keys and IVs produce a 796 MAC in message_3 and to derive application specific data. 798 PRK_2e is derived with the following input: 800 o The salt SHALL be the empty byte string. Note that [RFC5869] 801 specifies that if the salt is not provided, it is set to a string 802 of zeros (see Section 2.2 of [RFC5869]). For implementation 803 purposes, not providing the salt is the same as setting the salt 804 to the empty byte string. 806 o The input keying material (IKM) SHALL be the ECDH shared secret 807 G_XY (calculated from G_X and Y or G_Y and X) as defined in 808 Section 12.4.1 of [RFC8152]. 810 Example: Assuming the use of SHA-256 the extract phase of HKDF 811 produces PRK_2e as follows: 813 PRK_2e = HMAC-SHA-256( salt, G_XY ) 815 where salt = 0x (the empty byte string). 817 The pseudorandom keys PRK_3e2m and PRK_4x3m are defined as follow: 819 o If the Responder authenticates with a static Diffie-Hellman key, 820 then PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is the ECDH 821 shared secret calculated from G_R and X, or G_X and R, else 822 PRK_3e2m = PRK_2e. 824 o If the Initiator authenticates with a static Diffie-Hellman key, 825 then PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY is the ECDH 826 shared secret calculated from G_I and Y, or G_Y and I, else 827 PRK_4x3m = PRK_3e2m. 829 Example: Assuming the use of curve25519, the ECDH shared secrets 830 G_XY, G_RX, and G_IY are the outputs of the X25519 function 831 [RFC7748]: 833 G_XY = X25519( Y, G_X ) = X25519( X, G_Y ) 835 The keys and IVs used in EDHOC are derived from PRK using Expand 836 [RFC5869] where the EDHOC-KDF is instantiated with the EDHOC AEAD 837 algorithm in the selected cipher suite. 839 OKM = EDHOC-KDF( PRK, transcript_hash, label, length ) 840 = Expand( PRK, info, length ) 842 where info is the CBOR encoding of 843 info = [ 844 edhoc_aead_id : int / tstr, 845 transcript_hash : bstr, 846 label : tstr, 847 length : uint 848 ] 850 where 852 o edhoc_aead_id is an int or tstr containing the algorithm 853 identifier of the EDHOC AEAD algorithm in the selected cipher 854 suite encoded as defined in [RFC8152]. Note that a single fixed 855 edhoc_aead_id is used in all invocations of EDHOC-KDF, including 856 the derivation of K_2e and invocations of the EDHOC-Exporter. 858 o transcript_hash is a bstr set to one of the transcript hashes 859 TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.1. 861 o label is a tstr set to the name of the derived key or IV, i.e. 862 "K_2m", "IV_2m", "K_2e", "IV_2e", "K_3m", "IV_3m", "K_3ae", or 863 "IV_3ae". 865 o length is the length of output keying material (OKM) in bytes 867 If the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, length 868 ) = HKDF-Expand( PRK, info, length ) [RFC5869]. If the EDHOC hash 869 algorithm is SHAKE128, then Expand( PRK, info, length ) = KMAC128( 870 PRK, info, L, "" ). If the EDHOC hash algorithm is SHAKE256, then 871 Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ). 873 K_2e and IV_2e are derived using the transcript hash TH_2 and the 874 pseudorandom key PRK_2e. K_2m and IV_2m are derived using the 875 transcript hash TH_2 and the pseudorandom key PRK_3e2m. K_3ae and 876 IV_3ae are derived using the transcript hash TH_3 and the 877 pseudorandom key PRK_3e2m. K_3m and IV_3m are derived using the 878 transcript hash TH_3 and the pseudorandom key PRK_4x3m. IVs are only 879 used if the EDHOC AEAD algorithm uses IVs. 881 4.1. EDHOC-Exporter Interface 883 Application keys and other application specific data can be derived 884 using the EDHOC-Exporter interface defined as: 886 EDHOC-Exporter(label, length) 887 = EDHOC-KDF(PRK_4x3m, TH_4, label, length) 889 where label is a tstr defined by the application and length is a uint 890 defined by the application. The label SHALL be different for each 891 different exporter value. The transcript hash TH_4 is a CBOR encoded 892 bstr and the input to the hash function is a CBOR Sequence. 894 TH_4 = H( TH_3, CIPHERTEXT_3 ) 896 where H() is the hash function in the selected cipher suite. Example 897 use of the EDHOC-Exporter is given in Sections 7.1.1. 899 To provide forward secrecy in an even more efficient way than re- 900 running EDHOC, EDHOC provides the function EDHOC-Exporter-FS. When 901 EHDOC-Exporter-FS is called the old PRK_4x3m is deleted and the new 902 PRk_4x3m is calculated as a "hash" of the old key using the Extract 903 function as illustrated by the following pseudocode: 905 EHDOC-Exporter-FS( nonce ): 906 PRK_4x3m = Extract( [ "TH_4", nonce ], PRK_4x3m ) 908 5. Message Formatting and Processing 910 This section specifies formatting of the messages and processing 911 steps. Error messages are specified in Section 6. 913 An EDHOC message is encoded as a sequence of CBOR data (CBOR 914 Sequence, [RFC8742]). Additional optimizations are made to reduce 915 message overhead. 917 While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 918 structures, only a subset of the parameters is included in the EDHOC 919 messages. The unprotected COSE header in COSE_Sign1, and 920 COSE_Encrypt0 (not included in the EDHOC message) MAY contain 921 parameters (e.g. 'alg'). 923 5.1. Encoding of bstr_identifier 925 Byte strings are encoded in CBOR as two or more bytes, whereas 926 integers in the interval -24 to 23 are encoded in CBOR as one byte. 928 bstr_identifier is a special encoding of byte strings, used 929 throughout the protocol to enable the encoding of the shortest byte 930 strings as integers that only require one byte of CBOR encoding. 932 The bstr_identifier encoding is defined as follows: Byte strings in 933 the interval h'00' to h'2f' are encoded as the corresponding integer 934 minus 24, which are all represented by one byte CBOR ints. Other 935 byte strings are encoded as CBOR byte strings. 937 For example, the byte string h'59e9' encoded as a bstr_identifier is 938 equal to h'59e9', while the byte string h'2a' is encoded as the 939 integer 18. 941 The CDDL definition of the bstr_identifier is given below: 943 bstr_identifier = bstr / int 945 Note that, despite what could be interpreted by the CDDL definition 946 only, bstr_identifier once decoded are always byte strings. 948 5.2. EDHOC Message 1 950 5.2.1. Formatting of Message 1 952 message_1 SHALL be a CBOR Sequence (see Appendix A.1) as defined 953 below 955 message_1 = ( 956 METHOD_CORR : int, 957 SUITES_I : [ selected : suite, supported : 2* suite ] / suite, 958 G_X : bstr, 959 C_I : bstr_identifier, 960 ? AD_1 : bstr, 961 ) 963 suite = int 965 where: 967 o METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see 968 Figure 4) and the correlation parameter corr is chosen based on 969 the transport and determines which connection identifiers that are 970 omitted (see Section 3.2.4). 972 o SUITES_I - cipher suites which the Initiator supports in order of 973 (decreasing) preference. The list of supported cipher suites can 974 be truncated at the end, as is detailed in the processing steps 975 below. One of the supported cipher suites is selected. The 976 selected suite is the first suite in the SUITES_I CBOR array. If 977 a single supported cipher suite is conveyed then that cipher suite 978 is selected and the selected cipher suite is encoded as an int 979 instead of an array. 981 o G_X - the ephemeral public key of the Initiator 983 o C_I - variable length connection identifier, encoded as a 984 bstr_identifier (see Section 5.1). 986 o AD_1 - bstr containing unprotected opaque auxiliary data 988 5.2.2. Initiator Processing of Message 1 990 The Initiator SHALL compose message_1 as follows: 992 o The supported cipher suites and the order of preference MUST NOT 993 be changed based on previous error messages. However, the list 994 SUITES_I sent to the Responder MAY be truncated such that cipher 995 suites which are the least preferred are omitted. The amount of 996 truncation MAY be changed between sessions, e.g. based on previous 997 error messages (see next bullet), but all cipher suites which are 998 more preferred than the least preferred cipher suite in the list 999 MUST be included in the list. 1001 o Determine the cipher suite to use with the Responder in message_1. 1002 If the Initiator previously received from the Responder an error 1003 message to a message_1 with diagnostic payload identifying a 1004 cipher suite that the Initiator supports, then the Initiator SHALL 1005 use that cipher suite. Otherwise the first supported (i.e. the 1006 most preferred) cipher suite in SUITES_I MUST be used. 1008 o Generate an ephemeral ECDH key pair as specified in Section 5 of 1009 [SP-800-56A] using the curve in the selected cipher suite and 1010 format it as a COSE_Key. Let G_X be the 'x' parameter of the 1011 COSE_Key. 1013 o Choose a connection identifier C_I and store it for the length of 1014 the protocol. 1016 o Encode message_1 as a sequence of CBOR encoded data items as 1017 specified in Section 5.2.1 1019 5.2.3. Responder Processing of Message 1 1021 The Responder SHALL process message_1 as follows: 1023 o Decode message_1 (see Appendix A.1). 1025 o Verify that the selected cipher suite is supported and that no 1026 prior cipher suite in SUITES_I is supported. 1028 o Pass AD_1 to the security application. 1030 If any verification step fails, the Responder MUST send an EDHOC 1031 error message back, formatted as defined in Section 6, and the 1032 protocol MUST be discontinued. If the Responder does not support the 1033 selected cipher suite, then SUITES_R MUST include one or more 1034 supported cipher suites. If the Responder does not support the 1035 selected cipher suite, but supports another cipher suite in SUITES_I, 1036 then SUITES_R MUST include the first supported cipher suite in 1037 SUITES_I. 1039 5.3. EDHOC Message 2 1041 5.3.1. Formatting of Message 2 1043 message_2 and data_2 SHALL be CBOR Sequences (see Appendix A.1) as 1044 defined below 1046 message_2 = ( 1047 data_2, 1048 CIPHERTEXT_2 : bstr, 1049 ) 1051 data_2 = ( 1052 ? C_I : bstr_identifier, 1053 G_Y : bstr, 1054 C_R : bstr_identifier, 1055 ) 1057 where: 1059 o G_Y - the ephemeral public key of the Responder 1061 o C_R - variable length connection identifier, encoded as a 1062 bstr_identifier (see Section 5.1). 1064 5.3.2. Responder Processing of Message 2 1066 The Responder SHALL compose message_2 as follows: 1068 o If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted, 1069 otherwise C_I is not omitted. 1071 o Generate an ephemeral ECDH key pair as specified in Section 5 of 1072 [SP-800-56A] using the curve in the selected cipher suite and 1073 format it as a COSE_Key. Let G_Y be the 'x' parameter of the 1074 COSE_Key. 1076 o Choose a connection identifier C_R and store it for the length of 1077 the protocol. 1079 o Compute the transcript hash TH_2 = H(message_1, data_2) where H() 1080 is the hash function in the selected cipher suite. The transcript 1081 hash TH_2 is a CBOR encoded bstr and the input to the hash 1082 function is a CBOR Sequence. 1084 o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of 1085 [RFC8152], with the EDHOC AEAD algorithm in the selected cipher 1086 suite, K_2m, IV_2m, and the following parameters: 1088 * protected = << ID_CRED_R >> 1090 + ID_CRED_R - identifier to facilitate retrieval of CRED_R, 1091 see Section 3.3.4 1093 * external_aad = << TH_2, CRED_R, ? AD_2 >> 1095 + CRED_R - bstr containing the credential of the Responder, 1096 see Section 3.3.4. 1098 + AD_2 = bstr containing opaque unprotected auxiliary data 1100 * plaintext = h'' 1102 COSE constructs the input to the AEAD [RFC5116] as follows: 1104 * Key K = EDHOC-KDF( PRK_3e2m, TH_2, "K_2m", length ) 1106 * Nonce N = EDHOC-KDF( PRK_3e2m, TH_2, "IV_2m", length ) 1108 * Plaintext P = 0x (the empty string) 1110 * Associated data A = 1112 [ "Encrypt0", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >> ] 1114 MAC_2 is the 'ciphertext' of the inner COSE_Encrypt0. 1116 o If the Responder authenticates with a static Diffie-Hellman key 1117 (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the 1118 Responder authenticates with a signature key (method equals 0 or 1119 2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1 1120 object as defined in Section 4.4 of [RFC8152] using the signature 1121 algorithm in the selected cipher suite, the private authentication 1122 key of the Responder, and the following parameters: 1124 * protected = << ID_CRED_R >> 1126 * external_aad = << TH_2, CRED_R, ? AD_2 >> 1128 * payload = MAC_2 1129 COSE constructs the input to the Signature Algorithm as: 1131 * The key is the private authentication key of the Responder. 1133 * The message M to be signed = 1135 [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >>, 1136 MAC_2 ] 1138 o Compute an outer COSE_Encrypt0 as defined in Section 5.3 of 1139 [RFC8152], with the EDHOC AEAD algorithm in the selected cipher 1140 suite, K_2e, IV_2e, and the following parameters. The protected 1141 header SHALL be empty. 1143 * plaintext = ( ID_CRED_R / bstr_identifier, Signature_or_MAC_2, 1144 ? AD_2 ) 1146 + Note that if ID_CRED_R contains a single 'kid' parameter, 1147 i.e., ID_CRED_R = { 4 : kid_R }, only the byte string kid_R 1148 is conveyed in the plaintext encoded as a bstr_identifier, 1149 see Section 3.3.4 and Section 5.1. 1151 COSE constructs the input to the AEAD [RFC5116] as follows: 1153 * Key K = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length ) 1155 * Nonce N = EDHOC-KDF( PRK_2e, TH_2, "IV_2e", length ) 1157 * Plaintext P = ( ID_CRED_R / bstr_identifier, 1158 Signature_or_MAC_2, ? AD_2 ) 1160 * Associated data A = [ "Encrypt0", h'', TH_2 ] 1162 CIPHERTEXT_2 is the 'ciphertext' of the outer COSE_Encrypt0 with 1163 the tag removed. 1165 o Encode message_2 as a sequence of CBOR encoded data items as 1166 specified in Section 5.3.1. 1168 5.3.3. Initiator Processing of Message 2 1170 The Initiator SHALL process message_2 as follows: 1172 o Decode message_2 (see Appendix A.1). 1174 o Retrieve the protocol state using the connection identifier C_I 1175 and/or other external information such as the CoAP Token and the 1176 5-tuple. 1178 o Decrypt CIPHERTEXT_2 by computing an outer COSE_Encrypt0 as 1179 defined in see Section 5.3.2 and XORing CIPHERTEXT_2 with the 1180 'ciphertext' of the outer COSE_Encrypt0 with the tag removed. 1182 o Verify that the identity of the Responder is an allowed identity 1183 for this connection, see Section 3.3. 1185 o Verify Signature_or_MAC_2 using the algorithm in the selected 1186 cipher suite. The verification process depends on the method, see 1187 Section 5.3.2. 1189 o Pass AD_2 to the security application. 1191 If any verification step fails, the Responder MUST send an EDHOC 1192 error message back, formatted as defined in Section 6, and the 1193 protocol MUST be discontinued. 1195 5.4. EDHOC Message 3 1197 5.4.1. Formatting of Message 3 1199 message_3 and data_3 SHALL be CBOR Sequences (see Appendix A.1) as 1200 defined below 1202 message_3 = ( 1203 data_3, 1204 CIPHERTEXT_3 : bstr, 1205 ) 1207 data_3 = ( 1208 ? C_R : bstr_identifier, 1209 ) 1211 5.4.2. Initiator Processing of Message 3 1213 The Initiator SHALL compose message_3 as follows: 1215 o If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted, 1216 otherwise C_R is not omitted. 1218 o Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3) 1219 where H() is the hash function in the the selected cipher suite. 1220 The transcript hash TH_3 is a CBOR encoded bstr and the input to 1221 the hash function is a CBOR Sequence. 1223 o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of 1224 [RFC8152], with the EDHOC AEAD algorithm in the selected cipher 1225 suite, K_3m, IV_3m, and the following parameters: 1227 * protected = << ID_CRED_I >> 1229 + ID_CRED_I - identifier to facilitate retrieval of CRED_I, 1230 see Section 3.3.4 1232 * external_aad = << TH_3, CRED_I, ? AD_3 >> 1234 + CRED_I - bstr containing the credential of the Initiator, 1235 see Section 3.3.4. 1237 + AD_3 = bstr containing opaque protected auxiliary data 1239 * plaintext = h'' 1241 COSE constructs the input to the AEAD [RFC5116] as follows: 1243 * Key K = EDHOC-KDF( PRK_4x3m, TH_3, "K_3m", length ) 1245 * Nonce N = EDHOC-KDF( PRK_4x3m, TH_3, "IV_3m", length ) 1247 * Plaintext P = 0x (the empty string) 1249 * Associated data A = 1251 [ "Encrypt0", << ID_CRED_I >>, << TH_3, CRED_I, ? AD_3 >> ] 1253 MAC_3 is the 'ciphertext' of the inner COSE_Encrypt0. 1255 o If the Initiator authenticates with a static Diffie-Hellman key 1256 (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3. If the 1257 Initiator authenticates with a signature key (method equals 0 or 1258 1), then Signature_or_MAC_3 is the 'signature' of a COSE_Sign1 1259 object as defined in Section 4.4 of [RFC8152] using the signature 1260 algorithm in the selected cipher suite, the private authentication 1261 key of the Initiator, and the following parameters: 1263 * protected = << ID_CRED_I >> 1265 * external_aad = << TH_3, CRED_I, ? AD_3 >> 1267 * payload = MAC_3 1269 COSE constructs the input to the Signature Algorithm as: 1271 * The key is the private authentication key of the Initiator. 1273 * The message M to be signed = 1275 [ "Signature1", << ID_CRED_I >>, << TH_3, CRED_I, ? AD_3 >>, 1276 MAC_3 ] 1278 o Compute an outer COSE_Encrypt0 as defined in Section 5.3 of 1279 [RFC8152], with the EDHOC AEAD algorithm in the selected cipher 1280 suite, K_3ae, IV_3ae, and the following parameters. The protected 1281 header SHALL be empty. 1283 * external_aad = TH_3 1285 * plaintext = ( ID_CRED_I / bstr_identifier, Signature_or_MAC_3, 1286 ? AD_3 ) 1288 + Note that if ID_CRED_I contains a single 'kid' parameter, 1289 i.e., ID_CRED_I = { 4 : kid_I }, only the byte string kid_I 1290 is conveyed in the plaintext encoded as a bstr_identifier, 1291 see Section 3.3.4 and Section 5.1. 1293 COSE constructs the input to the AEAD [RFC5116] as follows: 1295 * Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length ) 1297 * Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length ) 1299 * Plaintext P = ( ID_CRED_I / bstr_identifier, 1300 Signature_or_MAC_3, ? AD_3 ) 1302 * Associated data A = [ "Encrypt0", h'', TH_3 ] 1304 CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0. 1306 o Encode message_3 as a sequence of CBOR encoded data items as 1307 specified in Section 5.4.1. 1309 Pass the connection identifiers (C_I, C_R) and the application 1310 algorithms in the selected cipher suite to the application. The 1311 application can now derive application keys using the EDHOC-Exporter 1312 interface. 1314 After sending message_3, the Initiator is assured that no other party 1315 than the Responder can compute the key PRK_4x3m (implicit key 1316 authentication). The Initiator does however not know that the 1317 Responder has actually computed the key PRK_4x3m. While the 1318 Initiator can securely send protected application data, the Initiator 1319 SHOULD NOT store the keying material PRK_4x3m and TH_4 until the 1320 Initiator is assured that the Responder has actually computed the key 1321 PRK_4x3m (explicit key confirmation). Explicit key confirmation is 1322 e.g. assured when the Initiator has verified an OSCORE message from 1323 the Responder. 1325 5.4.3. Responder Processing of Message 3 1327 The Responder SHALL process message_3 as follows: 1329 o Decode message_3 (see Appendix A.1). 1331 o Retrieve the protocol state using the connection identifier C_R 1332 and/or other external information such as the CoAP Token and the 1333 5-tuple. 1335 o Decrypt and verify the outer COSE_Encrypt0 as defined in 1336 Section 5.3 of [RFC8152], with the EDHOC AEAD algorithm in the 1337 selected cipher suite, K_3ae, and IV_3ae. 1339 o Verify that the identity of the Initiator is an allowed identity 1340 for this connection, see Section 3.3. 1342 o Verify Signature_or_MAC_3 using the algorithm in the selected 1343 cipher suite. The verification process depends on the method, see 1344 Section 5.4.2. 1346 o Pass AD_3, the connection identifiers (C_I, C_R), and the 1347 application algorithms in the selected cipher suite to the 1348 security application. The application can now derive application 1349 keys using the EDHOC-Exporter interface. 1351 If any verification step fails, the Responder MUST send an EDHOC 1352 error message back, formatted as defined in Section 6, and the 1353 protocol MUST be discontinued. 1355 After verifying message_3, the Responder is assured that the 1356 Initiator has calculated the key PRK_4x3m (explicit key confirmation) 1357 and that no other party than the Responder can compute the key. The 1358 Responder can securely send protected application data and store the 1359 keying material PRK_4x3m and TH_4. 1361 6. Error Handling 1363 6.1. EDHOC Error Message 1365 This section defines a message format for the EDHOC error message, 1366 used during the protocol. An EDHOC error message can be sent by both 1367 parties as a reply to any non-error EDHOC message. After sending an 1368 error message, the protocol MUST be discontinued. Errors at the 1369 EDHOC layer are sent as normal successful messages in the lower 1370 layers (e.g. CoAP POST and 2.04 Changed). An advantage of using 1371 such a construction is to avoid issues created by usage of cross 1372 protocol proxies (e.g. UDP to TCP). 1374 error SHALL be a CBOR Sequence (see Appendix A.1) as defined below 1376 error = ( 1377 ? C_x : bstr_identifier, 1378 ERR_MSG : tstr, 1379 ? SUITES_R : [ supported : 2* suite ] / suite, 1380 ) 1382 where: 1384 o C_x - (optional) variable length connection identifier, encoded as 1385 a bstr_identifier (see Section 5.1). If error is sent by the 1386 Responder and corr (METHOD_CORR mod 4) equals 0 or 2 then C_x is 1387 set to C_I, else if error is sent by the Initiator and corr 1388 (METHOD_CORR mod 4) equals 0 or 1 then C_x is set to C_R, else C_x 1389 is omitted. 1391 o ERR_MSG - text string containing the diagnostic payload, defined 1392 in the same way as in Section 5.5.2 of [RFC7252]. ERR_MSG MAY be 1393 a 0-length text string. This text string is mandatory and 1394 characteristic for error messages, which enables the receiver to 1395 distinguish between a normal message and an error message of the 1396 protocol. 1398 o SUITES_R - (optional) cipher suites from SUITES_I or the EDHOC 1399 cipher suites registry that the Responder supports. SUITES_R MUST 1400 only be included in replies to message_1. If a single supported 1401 cipher suite is conveyed then the supported cipher suite is 1402 encoded as an int instead of an array. 1404 After receiving SUITES_R, the Initiator can determine which selected 1405 cipher suite to use for the next EDHOC run with the Responder. If 1406 the Initiator intends to contact the Responder in the future, the 1407 Initiator SHOULD remember which selected cipher suite to use until 1408 the next message_1 has been sent, otherwise the Initiator and 1409 Responder will likely run into an infinite loop. After a successful 1410 run of EDHOC, the Initiator MAY remember the selected cipher suite to 1411 use in future EDHOC runs. Note that if the Initiator or Responder is 1412 updated with new cipher suite policies, any cached information may be 1413 outdated. 1415 6.1.1. Example Use of EDHOC Error Message with SUITES_R 1417 Assuming that the Initiator supports the five cipher suites 5, 6, 7, 1418 8, and 9 in decreasing order of preference, Figures 5 and 6 show 1419 examples of how the Initiator can truncate SUITES_I and how SUITES_R 1420 is used by the Responder to give the Initiator information about the 1421 cipher suites that the Responder supports. 1423 In Figure 5, the Responder supports cipher suite 6 but not the 1424 initially selected cipher suite 5. 1426 Initiator Responder 1427 | METHOD_CORR, SUITES_I = 5, G_X, C_I, AD_1 | 1428 +------------------------------------------------------------------>| 1429 | message_1 | 1430 | | 1431 | C_I, ERR_MSG, SUITES_R = 6 | 1432 |<------------------------------------------------------------------+ 1433 | error | 1434 | | 1435 | METHOD_CORR, SUITES_I = [6, 5, 6], G_X, C_I, AD_1 | 1436 +------------------------------------------------------------------>| 1437 | message_1 | 1439 Figure 5: Example use of error message with SUITES_R. 1441 In Figure 6, the Responder supports cipher suite 7 and 9 but not the 1442 more preferred (by the Initiator) cipher suites 5 and 6. The order 1443 of cipher suites in SUITES_R does not matter. 1445 Initiator Responder 1446 | METHOD_CORR, SUITES_I = 5, G_X, C_I, AD_1 | 1447 +------------------------------------------------------------------>| 1448 | message_1 | 1449 | | 1450 | C_I, ERR_MSG, SUITES_R = [9, 7] | 1451 |<------------------------------------------------------------------+ 1452 | error | 1453 | | 1454 | METHOD_CORR, SUITES_I = [7, 5, 6, 7], G_X, C_I, AD_1 | 1455 +------------------------------------------------------------------>| 1456 | message_1 | 1458 Figure 6: Example use of error message with SUITES_R. 1460 Note that the Initiator's list of supported cipher suites and order 1461 of preference is fixed (see Section 5.2.1 and Section 5.2.2). 1462 Furthermore, the Responder shall only accept message_1 if the 1463 selected cipher suite is the first cipher suite in SUITES_I that the 1464 Responder supports (see Section 5.2.3). Following this procedure 1465 ensures that the selected cipher suite is the most preferred (by the 1466 Initiator) cipher suite supported by both parties. 1468 If the selected cipher suite is not the first cipher suite which the 1469 Responder supports in SUITES_I received in message_1, then Responder 1470 MUST discontinue the protocol, see Section 5.2.3. If SUITES_I in 1471 message_1 is manipulated then the integrity verification of message_2 1472 containing the transcript hash TH_2 = H( message_1, data_2 ) will 1473 fail and the Initiator will discontinue the protocol. 1475 7. Transferring EDHOC and Deriving an OSCORE Context 1477 7.1. Transferring EDHOC in CoAP 1479 It is recommended to transport EDHOC as an exchange of CoAP [RFC7252] 1480 messages. CoAP is a reliable transport that can preserve packet 1481 ordering and handle message duplication. CoAP can also perform 1482 fragmentation and protect against denial of service attacks. It is 1483 recommended to carry the EDHOC messages in Confirmable messages, 1484 especially if fragmentation is used. 1486 By default, the CoAP client is the Initiator and the CoAP server is 1487 the Responder, but the roles SHOULD be chosen to protect the most 1488 sensitive identity, see Section 8. By default, EDHOC is transferred 1489 in POST requests and 2.04 (Changed) responses to the Uri-Path: 1490 "/.well-known/edhoc", but an application may define its own path that 1491 can be discovered e.g. using resource directory 1492 [I-D.ietf-core-resource-directory]. 1494 By default, the message flow is as follows: EDHOC message_1 is sent 1495 in the payload of a POST request from the client to the server's 1496 resource for EDHOC. EDHOC message_2 or the EDHOC error message is 1497 sent from the server to the client in the payload of a 2.04 (Changed) 1498 response. EDHOC message_3 or the EDHOC error message is sent from 1499 the client to the server's resource in the payload of a POST request. 1500 If needed, an EDHOC error message is sent from the server to the 1501 client in the payload of a 2.04 (Changed) response. 1503 An example of a successful EDHOC exchange using CoAP is shown in 1504 Figure 7. In this case the CoAP Token enables the Initiator to 1505 correlate message_1 and message_2 so the correlation parameter corr = 1506 1. 1508 Client Server 1509 | | 1510 +--------->| Header: POST (Code=0.02) 1511 | POST | Uri-Path: "/.well-known/edhoc" 1512 | | Content-Format: application/edhoc 1513 | | Payload: EDHOC message_1 1514 | | 1515 |<---------+ Header: 2.04 Changed 1516 | 2.04 | Content-Format: application/edhoc 1517 | | Payload: EDHOC message_2 1518 | | 1519 +--------->| Header: POST (Code=0.02) 1520 | POST | Uri-Path: "/.well-known/edhoc" 1521 | | Content-Format: application/edhoc 1522 | | Payload: EDHOC message_3 1523 | | 1524 |<---------+ Header: 2.04 Changed 1525 | 2.04 | 1526 | | 1528 Figure 7: Transferring EDHOC in CoAP when the Initiator is CoAP 1529 Client 1531 The exchange in Figure 7 protects the client identity against active 1532 attackers and the server identity against passive attackers. An 1533 alternative exchange that protects the server identity against active 1534 attackers and the client identity against passive attackers is shown 1535 in Figure 8. In this case the CoAP Token enables the Responder to 1536 correlate message_2 and message_3 so the correlation parameter corr = 1537 2. 1539 Client Server 1540 | | 1541 +--------->| Header: POST (Code=0.02) 1542 | POST | Uri-Path: "/.well-known/edhoc" 1543 | | 1544 |<---------+ Header: 2.04 Changed 1545 | 2.04 | Content-Format: application/edhoc 1546 | | Payload: EDHOC message_1 1547 | | 1548 +--------->| Header: POST (Code=0.02) 1549 | POST | Uri-Path: "/.well-known/edhoc" 1550 | | Content-Format: application/edhoc 1551 | | Payload: EDHOC message_2 1552 | | 1553 |<---------+ Header: 2.04 Changed 1554 | 2.04 | Content-Format: application/edhoc 1555 | | Payload: EDHOC message_3 1556 | | 1558 Figure 8: Transferring EDHOC in CoAP when the Initiator is CoAP 1559 Server 1561 To protect against denial-of-service attacks, the CoAP server MAY 1562 respond to the first POST request with a 4.01 (Unauthorized) 1563 containing an Echo option [I-D.ietf-core-echo-request-tag]. This 1564 forces the initiator to demonstrate its reachability at its apparent 1565 network address. If message fragmentation is needed, the EDHOC 1566 messages may be fragmented using the CoAP Block-Wise Transfer 1567 mechanism [RFC7959]. 1569 7.1.1. Deriving an OSCORE Context from EDHOC 1571 When EDHOC is used to derive parameters for OSCORE [RFC8613], the 1572 parties make sure that the EDHOC connection identifiers are unique, 1573 i.e. C_R MUST NOT be equal to C_I. The CoAP client and server MUST 1574 be able to retrieve the OSCORE protocol state using its chosen 1575 connection identifier and optionally other information such as the 1576 5-tuple. In case that the CoAP client is the Initiator and the CoAP 1577 server is the Responder: 1579 o The client's OSCORE Sender ID is C_R and the server's OSCORE 1580 Sender ID is C_I, as defined in this document 1582 o The AEAD Algorithm and the hash algorithm are the application AEAD 1583 and hash algorithms in the selected cipher suite. 1585 o The Master Secret and Master Salt are derived as follows where 1586 length is the key length (in bytes) of the application AEAD 1587 Algorithm. 1589 Master Secret = EDHOC-Exporter( "OSCORE Master Secret", length ) 1590 Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 ) 1592 8. Security Considerations 1594 8.1. Security Properties 1596 EDHOC inherits its security properties from the theoretical SIGMA-I 1597 protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides 1598 perfect forward secrecy, mutual authentication with aliveness, 1599 consistency, peer awareness. As described in [SIGMA], peer awareness 1600 is provided to the Responder, but not to the Initiator. 1602 EDHOC protects the credential identifier of the Initiator against 1603 active attacks and the credential identifier of the Responder against 1604 passive attacks. The roles should be assigned to protect the most 1605 sensitive identity/identifier, typically that which is not possible 1606 to infer from routing information in the lower layers. 1608 Compared to [SIGMA], EDHOC adds an explicit method type and expands 1609 the message authentication coverage to additional elements such as 1610 algorithms, auxiliary data, and previous messages. This protects 1611 against an attacker replaying messages or injecting messages from 1612 another session. 1614 EDHOC also adds negotiation of connection identifiers and downgrade 1615 protected negotiation of cryptographic parameters, i.e. an attacker 1616 cannot affect the negotiated parameters. A single session of EDHOC 1617 does not include negotiation of cipher suites, but it enables the 1618 Responder to verify that the selected cipher suite is the most 1619 preferred cipher suite by the Initiator which is supported by both 1620 the Initiator and the Responder. 1622 As required by [RFC7258], IETF protocols need to mitigate pervasive 1623 monitoring when possible. One way to mitigate pervasive monitoring 1624 is to use a key exchange that provides perfect forward secrecy. 1625 EDHOC therefore only supports methods with perfect forward secrecy. 1626 To limit the effect of breaches, it is important to limit the use of 1627 symmetrical group keys for bootstrapping. EDHOC therefore strives to 1628 make the additional cost of using raw public keys and self-signed 1629 certificates as small as possible. Raw public keys and self-signed 1630 certificates are not a replacement for a public key infrastructure, 1631 but SHOULD be used instead of symmetrical group keys for 1632 bootstrapping. 1634 Compromise of the long-term keys (private signature or static DH 1635 keys) does not compromise the security of completed EDHOC exchanges. 1636 Compromising the private authentication keys of one party lets an 1637 active attacker impersonate that compromised party in EDHOC exchanges 1638 with other parties, but does not let the attacker impersonate other 1639 parties in EDHOC exchanges with the compromised party. Compromise of 1640 the long-term keys does not enable a passive attacker to compromise 1641 future session keys. Compromise of the HDKF input parameters (ECDH 1642 shared secret) leads to compromise of all session keys derived from 1643 that compromised shared secret. Compromise of one session key does 1644 not compromise other session keys. 1646 If supported by the device, it is RECOMMENDED that at least the long- 1647 term private keys is stored in a Trusted Execution Environment (TEE) 1648 and that sensitive operations using these keys are performed inside 1649 the TEE. To achieve even higher security additional operation such 1650 as ephemeral key generation, all computations of shared secrets, and 1651 storage of the PRK keys can be done inside the TEE. Optimally, the 1652 whole EDHOC protocol can be implemented inside the TEE. Typically an 1653 adversary with physical access to a device can be assumed to gain 1654 access to all information outside of the TEE, but none of the 1655 information inside the TEE. 1657 Key compromise impersonation (KCI): In EDHOC authenticated with 1658 signature keys, EDHOC provides KCI protection against an attacker 1659 having access to the long term key or the ephemeral secret key. With 1660 static Diffie-Hellman key authentication, KCI protection would be 1661 provided against an attacker having access to the long-term Diffie- 1662 Hellman key, but not to an attacker having access to the ephemeral 1663 secret key. Note that the term KCI has typically been used for 1664 compromise of long-term keys, and that an attacker with access to the 1665 ephemeral secret key can only attack that specific protocol run. 1667 Repudiation: In EDHOC authenticated with signature keys, the 1668 Initiator could theoretically prove that the Responder performed a 1669 run of the protocol by presenting the private ephemeral key, and vice 1670 versa. Note that storing the private ephemeral keys violates the 1671 protocol requirements. With static Diffie-Hellman key 1672 authentication, both parties can always deny having participated in 1673 the protocol. 1675 8.2. Cryptographic Considerations 1677 The security of the SIGMA protocol requires the MAC to be bound to 1678 the identity of the signer. Hence the message authenticating 1679 functionality of the authenticated encryption in EDHOC is critical: 1680 authenticated encryption MUST NOT be replaced by plain encryption 1681 only, even if authentication is provided at another level or through 1682 a different mechanism. EDHOC implements SIGMA-I using the same Sign- 1683 then-MAC approach as TLS 1.3. 1685 To reduce message overhead EDHOC does not use explicit nonces and 1686 instead rely on the ephemeral public keys to provide randomness to 1687 each session. A good amount of randomness is important for the key 1688 generation, to provide liveness, and to protect against interleaving 1689 attacks. For this reason, the ephemeral keys MUST NOT be reused, and 1690 both parties SHALL generate fresh random ephemeral key pairs. 1692 The choice of key length used in the different algorithms needs to be 1693 harmonized, so that a sufficient security level is maintained for 1694 certificates, EDHOC, and the protection of application data. The 1695 Initiator and the Responder should enforce a minimum security level. 1697 The data rates in many IoT deployments are very limited. Given that 1698 the application keys are protected as well as the long-term 1699 authentication keys they can often be used for years or even decades 1700 before the cryptographic limits are reached. If the application keys 1701 established through EDHOC need to be renewed, the communicating 1702 parties can derive application keys with other labels or run EDHOC 1703 again. 1705 8.3. Cipher Suites 1707 Cipher suite number 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, 1708 Ed25519, AES-CCM-16-64-128, SHA-256) is mandatory to implement. 1709 Implementations only need to implement the algorithms needed for 1710 their supported methods. For many constrained IoT devices it is 1711 problematic to support more than one cipher suites, so some 1712 deployments with P-256 may not support the mandatory cipher suite. 1713 This is not a problem for local deployments. 1715 The HMAC algorithm HMAC 256/64 (HMAC w/ SHA-256 truncated to 64 bits) 1716 SHALL NOT be supported for use in EDHOC. 1718 8.4. Unprotected Data 1720 The Initiator and the Responder must make sure that unprotected data 1721 and metadata do not reveal any sensitive information. This also 1722 applies for encrypted data sent to an unauthenticated party. In 1723 particular, it applies to AD_1, ID_CRED_R, AD_2, and ERR_MSG. Using 1724 the same AD_1 in several EDHOC sessions allows passive eavesdroppers 1725 to correlate the different sessions. Another consideration is that 1726 the list of supported cipher suites may potentially be used to 1727 identify the application. 1729 The Initiator and the Responder must also make sure that 1730 unauthenticated data does not trigger any harmful actions. In 1731 particular, this applies to AD_1 and ERR_MSG. 1733 8.5. Denial-of-Service 1735 EDHOC itself does not provide countermeasures against Denial-of- 1736 Service attacks. By sending a number of new or replayed message_1 an 1737 attacker may cause the Responder to allocate state, perform 1738 cryptographic operations, and amplify messages. To mitigate such 1739 attacks, an implementation SHOULD rely on lower layer mechanisms such 1740 as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that 1741 forces the initiator to demonstrate reachability at its apparent 1742 network address. 1744 8.6. Implementation Considerations 1746 The availability of a secure pseudorandom number generator and truly 1747 random seeds are essential for the security of EDHOC. If no true 1748 random number generator is available, a truly random seed must be 1749 provided from an external source. As each pseudorandom number must 1750 only be used once, an implementation need to get a new truly random 1751 seed after reboot, or continuously store state in nonvolatile memory, 1752 see ([RFC8613], Appendix B.1.1) for issues and solution approaches 1753 for writing to nonvolatile memory. If ECDSA is supported, 1754 "deterministic ECDSA" as specified in [RFC6979] is RECOMMENDED. 1756 The referenced processing instructions in [SP-800-56A] must be 1757 complied with, including deleting the intermediate computed values 1758 along with any ephemeral ECDH secrets after the key derivation is 1759 completed. The ECDH shared secret, keys, and IVs MUST be secret. 1760 Implementations should provide countermeasures to side-channel 1761 attacks such as timing attacks. Depending on the selected curve, the 1762 parties should perform various validations of each other's public 1763 keys, see e.g. Section 5 of [SP-800-56A]. 1765 The Initiator and the Responder are responsible for verifying the 1766 integrity of certificates. The selection of trusted CAs should be 1767 done very carefully and certificate revocation should be supported. 1768 The private authentication keys MUST be kept secret. 1770 The Initiator and the Responder are allowed to select the connection 1771 identifiers C_I and C_R, respectively, for the other party to use in 1772 the ongoing EDHOC protocol as well as in a subsequent application 1773 protocol (e.g. OSCORE [RFC8613]). The choice of connection 1774 identifier is not security critical in EDHOC but intended to simplify 1775 the retrieval of the right security context in combination with using 1776 short identifiers. If the wrong connection identifier of the other 1777 party is used in a protocol message it will result in the receiving 1778 party not being able to retrieve a security context (which will 1779 terminate the protocol) or retrieve the wrong security context (which 1780 also terminates the protocol as the message cannot be verified). 1782 The Responder MUST finish the verification step of message_3 before 1783 passing AD_3 to the application. 1785 If two nodes unintentionally initiate two simultaneous EDHOC message 1786 exchanges with each other even if they only want to complete a single 1787 EDHOC message exchange, they MAY terminate the exchange with the 1788 lexicographically smallest G_X. If the two G_X values are equal, the 1789 received message_1 MUST be discarded to mitigate reflection attacks. 1790 Note that in the case of two simultaneous EDHOC exchanges where the 1791 nodes only complete one and where the nodes have different preferred 1792 cipher suites, an attacker can affect which of the two nodes' 1793 preferred cipher suites will be used by blocking the other exchange. 1795 8.7. Other Documents Referencing EDHOC 1797 EDHOC has been analyzed in several other documents. A formal 1798 verification of EDHOC was done in [SSR18], an analysis of EDHOC for 1799 certificate enrollment was done in [Kron18], the use of EDHOC in 1800 LoRaWAN is analyzed in [LoRa1] and [LoRa2], the use of EDHOC in IoT 1801 bootstrapping is analyzed in [Perez18], and the use of EDHOC in 1802 6TiSCH is described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. 1804 9. IANA Considerations 1806 9.1. EDHOC Cipher Suites Registry 1808 IANA has created a new registry titled "EDHOC Cipher Suites" under 1809 the new heading "EDHOC". The registration procedure is "Expert 1810 Review". The columns of the registry are Value, Array, Description, 1811 and Reference, where Value is an integer and the other columns are 1812 text strings. The initial contents of the registry are: 1814 Value: -24 1815 Algorithms: N/A 1816 Desc: Reserved for Private Use 1817 Reference: [[this document]] 1819 Value: -23 1820 Algorithms: N/A 1821 Desc: Reserved for Private Use 1822 Reference: [[this document]] 1823 Value: -22 1824 Algorithms: N/A 1825 Desc: Reserved for Private Use 1826 Reference: [[this document]] 1828 Value: -21 1829 Algorithms: N/A 1830 Desc: Reserved for Private Use 1831 Reference: [[this document]] 1833 Value: 0 1834 Array: 10, 5, 4, -8, 6, 10, 5 1835 Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519, 1836 AES-CCM-16-64-128, SHA-256 1837 Reference: [[this document]] 1839 Value: 1 1840 Array: 30, 5, 4, -8, 6, 10, 5 1841 Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519, 1842 AES-CCM-16-64-128, SHA-256 1843 Reference: [[this document]] 1845 Value: 2 1846 Array: 10, 5, 1, -7, 1, 10, 5 1847 Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256, 1848 AES-CCM-16-64-128, SHA-256 1849 Reference: [[this document]] 1851 Value: 3 1852 Array: 30, 5, 1, -7, 1, 10, 5 1853 Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256, 1854 AES-CCM-16-64-128, SHA-256 1855 Reference: [[this document]] 1857 Value: 4 1858 Array: 1, -16, 4, -7, 1, 1, -16 1859 Desc: A128GCM, SHA-256, X25519, ES256, P-256, 1860 A128GCM, SHA-256 1861 Reference: [[this document]] 1863 Value: 5 1864 Array: 3, -43, 2, -35, 2, 3, -43 1865 Desc: A256GCM, SHA-384, P-384, ES384, P-384, 1866 A256GCM, SHA-384 1867 Reference: [[this document]] 1869 9.2. EDHOC Method Type Registry 1871 IANA has created a new registry titled "EDHOC Method Type" under the 1872 new heading "EDHOC". The registration procedure is "Expert Review". 1873 The columns of the registry are Value, Description, and Reference, 1874 where Value is an integer and the other columns are text strings. 1875 The initial contents of the registry is shown in Figure 4. 1877 9.3. The Well-Known URI Registry 1879 IANA has added the well-known URI 'edhoc' to the Well-Known URIs 1880 registry. 1882 o URI suffix: edhoc 1884 o Change controller: IETF 1886 o Specification document(s): [[this document]] 1888 o Related information: None 1890 9.4. Media Types Registry 1892 IANA has added the media type 'application/edhoc' to the Media Types 1893 registry. 1895 o Type name: application 1897 o Subtype name: edhoc 1899 o Required parameters: N/A 1901 o Optional parameters: N/A 1903 o Encoding considerations: binary 1905 o Security considerations: See Section 7 of this document. 1907 o Interoperability considerations: N/A 1909 o Published specification: [[this document]] (this document) 1911 o Applications that use this media type: To be identified 1913 o Fragment identifier considerations: N/A 1915 o Additional information: 1917 * Magic number(s): N/A 1919 * File extension(s): N/A 1921 * Macintosh file type code(s): N/A 1923 o Person & email address to contact for further information: See 1924 "Authors' Addresses" section. 1926 o Intended usage: COMMON 1928 o Restrictions on usage: N/A 1930 o Author: See "Authors' Addresses" section. 1932 o Change Controller: IESG 1934 9.5. CoAP Content-Formats Registry 1936 IANA has added the media type 'application/edhoc' to the CoAP 1937 Content-Formats registry. 1939 o Media Type: application/edhoc 1941 o Encoding: 1943 o ID: TBD42 1945 o Reference: [[this document]] 1947 9.6. Expert Review Instructions 1949 The IANA Registries established in this document is defined as 1950 "Expert Review". This section gives some general guidelines for what 1951 the experts should be looking for, but they are being designated as 1952 experts for a reason so they should be given substantial latitude. 1954 Expert reviewers should take into consideration the following points: 1956 o Clarity and correctness of registrations. Experts are expected to 1957 check the clarity of purpose and use of the requested entries. 1958 Expert needs to make sure the values of algorithms are taken from 1959 the right registry, when that's required. Expert should consider 1960 requesting an opinion on the correctness of registered parameters 1961 from relevant IETF working groups. Encodings that do not meet 1962 these objective of clarity and completeness should not be 1963 registered. 1965 o Experts should take into account the expected usage of fields when 1966 approving point assignment. The length of the encoded value 1967 should be weighed against how many code points of that length are 1968 left, the size of device it will be used on, and the number of 1969 code points left that encode to that size. 1971 o Specifications are recommended. When specifications are not 1972 provided, the description provided needs to have sufficient 1973 information to verify the points above. 1975 10. References 1977 10.1. Normative References 1979 [I-D.ietf-core-echo-request-tag] 1980 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1981 Request-Tag, and Token Processing", draft-ietf-core-echo- 1982 request-tag-11 (work in progress), November 2020. 1984 [I-D.ietf-cose-x509] 1985 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1986 Header parameters for carrying and referencing X.509 1987 certificates", draft-ietf-cose-x509-08 (work in progress), 1988 December 2020. 1990 [I-D.ietf-lake-reqs] 1991 Vucinic, M., Selander, G., Mattsson, J., and D. Garcia- 1992 Carillo, "Requirements for a Lightweight AKE for OSCORE", 1993 draft-ietf-lake-reqs-04 (work in progress), June 2020. 1995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1996 Requirement Levels", BCP 14, RFC 2119, 1997 DOI 10.17487/RFC2119, March 1997, 1998 . 2000 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2001 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2002 . 2004 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2005 Key Derivation Function (HKDF)", RFC 5869, 2006 DOI 10.17487/RFC5869, May 2010, 2007 . 2009 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2010 Curve Cryptography Algorithms", RFC 6090, 2011 DOI 10.17487/RFC6090, February 2011, 2012 . 2014 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 2015 Algorithm (DSA) and Elliptic Curve Digital Signature 2016 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2017 2013, . 2019 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2020 Application Protocol (CoAP)", RFC 7252, 2021 DOI 10.17487/RFC7252, June 2014, 2022 . 2024 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2025 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2026 2016, . 2028 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2029 the Constrained Application Protocol (CoAP)", RFC 7959, 2030 DOI 10.17487/RFC7959, August 2016, 2031 . 2033 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2034 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2035 . 2037 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2038 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2039 May 2017, . 2041 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2042 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2043 . 2045 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2046 Definition Language (CDDL): A Notational Convention to 2047 Express Concise Binary Object Representation (CBOR) and 2048 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2049 June 2019, . 2051 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2052 "Object Security for Constrained RESTful Environments 2053 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2054 . 2056 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 2057 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 2058 . 2060 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2061 Representation (CBOR)", STD 94, RFC 8949, 2062 DOI 10.17487/RFC8949, December 2020, 2063 . 2065 10.2. Informative References 2067 [CborMe] Bormann, C., "CBOR Playground", May 2018, 2068 . 2070 [CNSA] (Placeholder), ., "Commercial National Security Algorithm 2071 Suite", August 2015, 2072 . 2075 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 2076 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 2077 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 2078 progress), July 2019. 2080 [I-D.ietf-ace-oauth-authz] 2081 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2082 H. Tschofenig, "Authentication and Authorization for 2083 Constrained Environments (ACE) using the OAuth 2.0 2084 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36 2085 (work in progress), November 2020. 2087 [I-D.ietf-core-resource-directory] 2088 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 2089 Stok, "CoRE Resource Directory", draft-ietf-core-resource- 2090 directory-26 (work in progress), November 2020. 2092 [I-D.ietf-lwig-security-protocol-comparison] 2093 Mattsson, J., Palombini, F., and M. Vucinic, "Comparison 2094 of CoAP Security Protocols", draft-ietf-lwig-security- 2095 protocol-comparison-05 (work in progress), November 2020. 2097 [I-D.ietf-tls-dtls13] 2098 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2099 Datagram Transport Layer Security (DTLS) Protocol Version 2100 1.3", draft-ietf-tls-dtls13-39 (work in progress), 2101 November 2020. 2103 [I-D.palombini-core-oscore-edhoc] 2104 Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., 2105 and G. Selander, "Combining EDHOC and OSCORE", draft- 2106 palombini-core-oscore-edhoc-01 (work in progress), 2107 November 2020. 2109 [I-D.selander-ace-ake-authz] 2110 Selander, G., Mattsson, J., Vucinic, M., Richardson, M., 2111 and A. Schellenbaum, "Lightweight Authorization for 2112 Authenticated Key Exchange.", draft-selander-ace-ake- 2113 authz-02 (work in progress), November 2020. 2115 [Kron18] Krontiris, A., "Evaluation of Certificate Enrollment over 2116 Application Layer Security", May 2018, 2117 . 2120 [LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., 2121 Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. 2122 Skarmeta, "Enhancing LoRaWAN Security through a 2123 Lightweight and Authenticated Key Management Approach", 2124 June 2018, 2125 . 2128 [LoRa2] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., 2129 Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. 2130 Skarmeta, "Internet Access for LoRaWAN Devices Considering 2131 Security Issues", June 2018, 2132 . 2134 [Perez18] Perez, S., Garcia-Carrillo, D., Marin-Lopez, R., 2135 Hernandez-Ramos, J., Marin-Perez, R., and A. Skarmeta, 2136 "Architecture of security association establishment based 2137 on bootstrapping technologies for enabling critical IoT 2138 K", October 2018, . 2143 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2144 Constrained-Node Networks", RFC 7228, 2145 DOI 10.17487/RFC7228, May 2014, 2146 . 2148 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2149 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2150 2014, . 2152 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2153 Kivinen, "Internet Key Exchange Protocol Version 2 2154 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2155 2014, . 2157 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2158 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2159 . 2161 [SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to 2162 Authenticated Diffie-Hellman and Its Use in the IKE- 2163 Protocols (Long version)", June 2003, 2164 . 2166 [SP-800-56A] 2167 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 2168 Davis, "Recommendation for Pair-Wise Key-Establishment 2169 Schemes Using Discrete Logarithm Cryptography", 2170 NIST Special Publication 800-56A Revision 3, April 2018, 2171 . 2173 [SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T., 2174 and C. Schuermann, "Formal Verification of Ephemeral 2175 Diffie-Hellman Over COSE (EDHOC)", November 2018, 2176 . 2180 Appendix A. Use of CBOR, CDDL and COSE in EDHOC 2182 This Appendix is intended to simplify for implementors not familiar 2183 with CBOR [RFC8949], CDDL [RFC8610], COSE [RFC8152], and HKDF 2184 [RFC5869]. 2186 A.1. CBOR and CDDL 2188 The Concise Binary Object Representation (CBOR) [RFC8949] is a data 2189 format designed for small code size and small message size. CBOR 2190 builds on the JSON data model but extends it by e.g. encoding binary 2191 data directly without base64 conversion. In addition to the binary 2192 CBOR encoding, CBOR also has a diagnostic notation that is readable 2193 and editable by humans. The Concise Data Definition Language (CDDL) 2194 [RFC8610] provides a way to express structures for protocol messages 2195 and APIs that use CBOR. [RFC8610] also extends the diagnostic 2196 notation. 2198 CBOR data items are encoded to or decoded from byte strings using a 2199 type-length-value encoding scheme, where the three highest order bits 2200 of the initial byte contain information about the major type. CBOR 2201 supports several different types of data items, in addition to 2202 integers (int, uint), simple values (e.g. null), byte strings (bstr), 2203 and text strings (tstr), CBOR also supports arrays [] of data items, 2204 maps {} of pairs of data items, and sequences [RFC8742] of data 2205 items. Some examples are given below. For a complete specification 2206 and more examples, see [RFC8949] and [RFC8610]. We recommend 2207 implementors to get used to CBOR by using the CBOR playground 2208 [CborMe]. 2210 Diagnostic Encoded Type 2211 ------------------------------------------------------------------ 2212 1 0x01 unsigned integer 2213 24 0x1818 unsigned integer 2214 -24 0x37 negative integer 2215 -25 0x3818 negative integer 2216 null 0xf6 simple value 2217 h'12cd' 0x4212cd byte string 2218 '12cd' 0x4431326364 byte string 2219 "12cd" 0x6431326364 text string 2220 { 4 : h'cd' } 0xa10441cd map 2221 << 1, 2, null >> 0x430102f6 byte string 2222 [ 1, 2, null ] 0x830102f6 array 2223 ( 1, 2, null ) 0x0102f6 sequence 2224 1, 2, null 0x0102f6 sequence 2225 ------------------------------------------------------------------ 2227 A.2. COSE 2229 CBOR Object Signing and Encryption (COSE) [RFC8152] describes how to 2230 create and process signatures, message authentication codes, and 2231 encryption using CBOR. COSE builds on JOSE, but is adapted to allow 2232 more efficient processing in constrained devices. EDHOC makes use of 2233 COSE_Key, COSE_Encrypt0, and COSE_Sign1 objects. 2235 Appendix B. Test Vectors 2237 This appendix provides detailed test vectors to ease implementation 2238 and ensure interoperability. In addition to hexadecimal, all CBOR 2239 data items and sequences are given in CBOR diagnostic notation. The 2240 test vectors use the default mapping to CoAP where the Initiator acts 2241 as CoAP client (this means that corr = 1). 2243 A more extensive test vector suite covering more combinations of 2244 authentication method used between Initiator and Responder and 2245 related code to generate them can be found at https://github.com/ 2246 lake-wg/edhoc/tree/master/test-vectors . 2248 B.1. Test Vectors for EDHOC Authenticated with Signature Keys (x5t) 2250 EDHOC with signature authentication and X.509 certificates is used. 2251 In this test vector, the hash value 'x5t' is used to identify the 2252 certificate. 2254 method (Signature Authentication) 2255 0 2257 CoAP is used as transport and the Initiator acts as CoAP client: 2259 corr (the Initiator can correlate message_1 and message_2) 2260 1 2262 From there, METHOD_CORR has the following value: 2264 METHOD_CORR (4 * method + corr) (int) 2265 1 2267 No unprotected opaque auxiliary data is sent in the message 2268 exchanges. 2270 The list of supported cipher suites of the Initiator in order of 2271 preference is the following: 2273 Supported Cipher Suites (4 bytes) 2274 00 01 02 03 2276 The cipher suite selected by the Initiator is the most preferred: 2278 Selected Cipher Suite (int) 2279 0 2281 The mandatory-to-implement cipher suite 0 is supported by both the 2282 Initiator and the Responder, see Section 8.3. 2284 B.1.1. Message_1 2286 X (Initiator's ephemeral private key) (32 bytes) 2287 8f 78 1a 09 53 72 f8 5b 6d 9f 61 09 ae 42 26 11 73 4d 7d bf a0 06 9a 2d 2288 f2 93 5b b2 e0 53 bf 35 2290 G_X (Initiator's ephemeral public key) (32 bytes) 2291 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 ec 07 6b ba 2292 02 59 d9 04 b7 ec 8b 0c 2294 The Initiator chooses a connection identifier C_I: 2296 Connection identifier chosen by Initiator (0 bytes) 2298 Since no unprotected opaque auxiliary data is sent in the message 2299 exchanges: 2301 AD_1 (0 bytes) 2303 Since the list of supported cipher suites needs to contain the 2304 selected cipher suite, the initiator truncates the list of supported 2305 cipher suites to one cipher suite only, 00. 2307 Because one single selected cipher suite is conveyed, it is encoded 2308 as an int instead of an array: 2310 SUITES_I (int) 2311 0 2313 With SUITES_I = 0, message_1 is constructed, as the CBOR Sequence of 2314 the CBOR data items above. 2316 message_1 = 2317 ( 2318 1, 2319 0, 2320 h'898ff79a02067a16ea1eccb90fa52246f5aa4dd6ec076bba0259d904b7ec8b0c', 2321 h'' 2322 ) 2324 message_1 (CBOR Sequence) (37 bytes) 2325 01 00 58 20 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 2326 ec 07 6b ba 02 59 d9 04 b7 ec 8b 0c 40 2328 B.1.2. Message_2 2330 Since METHOD_CORR mod 4 equals 1, C_I is omitted from data_2. 2332 Y (Responder's ephemeral private key) (32 bytes) 2333 fd 8c d8 77 c9 ea 38 6e 6a f3 4f f7 e6 06 c4 b6 4c a8 31 c8 ba 33 13 4f 2334 d4 cd 71 67 ca ba ec da 2336 G_Y (Responder's ephemeral public key) (32 bytes) 2337 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52 2338 81 75 4c 5e bc af 30 1e 2340 From G_X and Y or from G_Y and X the ECDH shared secret is computed: 2342 G_XY (ECDH shared secret) (32 bytes) 2343 2b b7 fa 6e 13 5b c3 35 d0 22 d6 34 cb fb 14 b3 f5 82 f3 e2 e3 af b2 b3 2344 15 04 91 49 5c 61 78 2b 2346 The key and nonce for calculating the ciphertext are calculated as 2347 follows, as specified in Section 4. 2349 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 2351 PRK_2e = HMAC-SHA-256(salt, G_XY) 2353 Salt is the empty byte string. 2355 salt (0 bytes) 2357 From there, PRK_2e is computed: 2359 PRK_2e (32 bytes) 2360 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f 2361 d8 2f be b7 99 71 39 4a 2363 SK_R (Responders's private authentication key) (32 bytes) 2364 df 69 27 4d 71 32 96 e2 46 30 63 65 37 2b 46 83 ce d5 38 1b fc ad cd 44 2365 0a 24 c3 91 d2 fe db 94 2367 Since neither the Initiator nor the Responder authenticates with a 2368 static Diffie-Hellman key, PRK_3e2m = PRK_2e 2370 PRK_3e2m (32 bytes) 2371 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f 2372 d8 2f be b7 99 71 39 4a 2374 The Responder chooses a connection identifier C_R. 2376 Connection identifier chosen by Responder (1 byte) 2377 2b 2379 Note that since C_R is a byte string of length one, it is encoded as 2380 the corresponding integer subtracted by 24 (see bstr_identifier in 2381 Section 5.1). Thus 0x2b = 43, 43 - 24 = 19, and 19 in CBOR encoding 2382 is equal to 0x13. 2384 C_R (1 byte) 2385 13 2387 Data_2 is constructed, as the CBOR Sequence of G_Y and C_R. 2389 data_2 = 2390 ( 2391 h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e', 2392 h'13' 2393 ) 2395 data_2 (CBOR Sequence) (35 bytes) 2396 58 20 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 2397 19 52 81 75 4c 5e bc af 30 1e 13 2399 From data_2 and message_1, compute the input to the transcript hash 2400 TH_2 = H( message_1, data_2 ), as a CBOR Sequence of these 2 data 2401 items. 2403 Input to calculate TH_2 (CBOR Sequence) (72 bytes) 2404 01 00 58 20 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 2405 ec 07 6b ba 02 59 d9 04 b7 ec 8b 0c 40 58 20 71 a3 d5 99 c2 1d a1 89 02 2406 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52 81 75 4c 5e bc af 30 1e 13 2408 And from there, compute the transcript hash TH_2 = SHA-256( 2409 message_1, data_2 ) 2411 TH_2 (32 bytes) 2412 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 b9 ca fb 60 2413 9d e4 f6 a1 76 0d 6c f7 2415 The Responder's subject name is the empty string: 2417 Responders's subject name (text string) 2418 "" 2420 CRED_R is the certificate (X509_R) encoded as a CBOR byte string: 2422 X509_R (110 bytes) 2423 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9 2424 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50 2425 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 18 0b 2426 5a 6a f3 1e 80 20 9a 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 0f fb 2427 8e 3f 9a 32 a5 08 59 ec d0 bf cf f2 c2 18 2429 CRED_R (112 bytes) 2430 58 6e 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 2431 4b f9 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 2432 5c 50 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 2433 18 0b 5a 6a f3 1e 80 20 9a 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 2434 0f fb 8e 3f 9a 32 a5 08 59 ec d0 bf cf f2 c2 18 2436 And because certificates are identified by a hash value with the 2437 'x5t' parameter, ID_CRED_R is the following: 2439 ID_CRED_R = { 34 : COSE_CertHash }. In this example, the hash 2440 algorithm used is SHA-2 256-bit with hash truncated to 64-bits (value 2441 -15). The hash value is calculated over the certificate X509_R. 2443 ID_CRED_R = 2444 { 2445 34: [-15, h'FC79990F2431A3F5'] 2446 } 2448 ID_CRED_R (14 bytes) 2449 a1 18 22 82 2e 48 fc 79 99 0f 24 31 a3 f5 2451 Since no unprotected opaque auxiliary data is sent in the message 2452 exchanges: 2454 AD_2 (0 bytes) 2456 The Plaintext is defined as the empty string: 2458 P_2m (0 bytes) 2460 The Enc_structure is defined as follows: [ "Encrypt0", 2461 << ID_CRED_R >>, << TH_2, CRED_R >> ] 2463 A_2m = 2464 [ 2465 "Encrypt0", 2466 h'A11822822E48FC79990F2431A3F5', 2467 h'5820B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF 2468 7586E47624DC9CDC6824B2A4C52E95EC9D6B0534B71C2B49E4BF9031500CEE6869979 2469 C297BB5A8B381E98DB714108415E5C50DB78974C271579B01633A3EF6271BE5C225EB 2470 28F9CF6180B5A6AF31E80209A085CFBF95F3FDCF9B18B693D6C0E0D0FFB8E3F9A32A5 2471 0859ECD0BFCFF2C218' 2472 ] 2474 Which encodes to the following byte string to be used as Additional 2475 Authenticated Data: 2477 A_2m (CBOR-encoded) (173 bytes) 2478 83 68 45 6e 63 72 79 70 74 30 4e a1 18 22 82 2e 48 fc 79 99 0f 24 31 a3 2479 f5 58 92 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 2480 47 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 58 6e 47 62 4d c9 cd c6 82 4b 2a 2481 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9 03 15 00 ce e6 86 99 79 c2 2482 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50 db 78 97 4c 27 15 79 b0 16 2483 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 18 0b 5a 6a f3 1e 80 20 9a 08 5c 2484 fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 0f fb 8e 3f 9a 32 a5 08 59 ec d0 2485 bf cf f2 c2 18 2487 info for K_2m is defined as follows: 2489 info for K_2m = 2490 [ 2491 10, 2492 h'B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF7', 2493 "K_2m", 2494 16 2495 ] 2497 Which as a CBOR encoded data item is: 2499 info for K_2m (CBOR-encoded) (42 bytes) 2500 84 0a 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 2501 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 64 4b 5f 32 6d 10 2503 From these parameters, K_2m is computed. Key K_2m is the output of 2504 HKDF-Expand(PRK_3e2m, info, L), where L is the length of K_2m, so 16 2505 bytes. 2507 K_2m (16 bytes) 2508 b7 48 6a 94 a3 6c f6 9e 67 3f c4 57 55 ee 6b 95 2510 info for IV_2m is defined as follows: 2512 info for IV_2m = 2513 [ 2514 10, 2515 h'B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF7', 2516 "IV_2m", 2517 13 2518 ] 2520 Which as a CBOR encoded data item is: 2522 info for IV_2m (CBOR-encoded) (43 bytes) 2523 84 0a 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 2524 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 65 49 56 5f 32 6d 0d 2526 From these parameters, IV_2m is computed. IV_2m is the output of 2527 HKDF-Expand(PRK_3e2m, info, L), where L is the length of IV_2m, so 13 2528 bytes. 2530 IV_2m (13 bytes) 2531 c5 b7 17 0e 65 d5 4f 1a e0 5d 10 af 56 2533 Finally, COSE_Encrypt0 is computed from the parameters above. 2535 o protected header = CBOR-encoded ID_CRED_R 2536 o external_aad = A_2m 2538 o empty plaintext = P_2m 2540 MAC_2 (8 bytes) 2541 cf 99 99 ae 75 9e c0 d8 2543 To compute the Signature_or_MAC_2, the key is the private 2544 authentication key of the Responder and the message M_2 to be signed 2545 = [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >>, MAC_2 2546 ] 2548 M_2 = 2549 [ 2550 "Signature1", 2551 h'A11822822E48FC79990F2431A3F5', 2552 h'5820B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF 2553 7586E47624DC9CDC6824B2A4C52E95EC9D6B0534B71C2B49E4BF9031500CEE6869979 2554 C297BB5A8B381E98DB714108415E5C50DB78974C271579B01633A3EF6271BE5C225EB 2555 28F9CF6180B5A6AF31E80209A085CFBF95F3FDCF9B18B693D6C0E0D0FFB8E3F9A32A5 2556 0859ECD0BFCFF2C218', 2557 h'CF9999AE759EC0D8' 2558 ] 2560 Which as a CBOR encoded data item is: 2562 M_2 (184 bytes) 2563 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 fc 79 99 0f 24 2564 31 a3 f5 58 92 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 2565 31 1a 47 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 58 6e 47 62 4d c9 cd c6 82 2566 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9 03 15 00 ce e6 86 99 2567 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50 db 78 97 4c 27 15 79 2568 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 18 0b 5a 6a f3 1e 80 20 9a 2569 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 0f fb 8e 3f 9a 32 a5 08 59 2570 ec d0 bf cf f2 c2 18 48 cf 99 99 ae 75 9e c0 d8 2572 From there Signature_or_MAC_2 is a signature (since method = 0): 2574 Signature_or_MAC_2 (64 bytes) 2575 45 47 81 ec ef eb b4 83 e6 90 83 9d 57 83 8d fe 24 a8 cf 3f 66 42 8a a0 2576 16 20 4a 22 61 84 4a f8 4f 98 b8 c6 83 4f 38 7f dd 60 6a 29 41 3a dd e3 2577 a2 07 74 02 13 74 01 19 6f 6a 50 24 06 6f ac 0e 2579 CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a 2580 plaintext constructed from the following parameters and the key K_2e. 2582 o plaintext = CBOR Sequence of the items ID_CRED_R and 2583 Singature_or_MAC_2, in this order. 2585 The plaintext is the following: 2587 P_2e (CBOR Sequence) (80 bytes) 2588 a1 18 22 82 2e 48 fc 79 99 0f 24 31 a3 f5 58 40 45 47 81 ec ef eb b4 83 2589 e6 90 83 9d 57 83 8d fe 24 a8 cf 3f 66 42 8a a0 16 20 4a 22 61 84 4a f8 2590 4f 98 b8 c6 83 4f 38 7f dd 60 6a 29 41 3a dd e3 a2 07 74 02 13 74 01 19 2591 6f 6a 50 24 06 6f ac 0e 2593 K_2e = HKDF-Expand( PRK, info, length ), where length is the length 2594 of the plaintext, so 80. 2596 info for K_2e = 2597 [ 2598 10, 2599 h'B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF7', 2600 "K_2e", 2601 80 2602 ] 2604 Which as a CBOR encoded data item is: 2606 info for K_2e (CBOR-encoded) (43 bytes) 2607 84 0a 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 2608 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 64 4b 5f 32 65 18 50 2610 From there, K_2e is computed: 2612 K_2e (80 bytes) 2613 38 cd 1a 83 89 6d 43 af 3d e8 39 35 27 42 0d ac 7d 7a 76 96 7e 85 74 58 2614 26 bb 39 e1 76 21 8d 7e 5f e7 97 60 14 c9 ed ba c0 58 ee 18 cd 57 71 80 2615 a4 4d de 0b 83 00 fe 8e 09 66 9a 34 d6 3e 3a e6 10 12 26 ab f8 5c eb 28 2616 05 dc 00 13 d1 78 2a 20 2618 Using the parameters above, the ciphertext CIPHERTEXT_2 can be 2619 computed: 2621 CIPHERTEXT_2 (80 bytes) 2622 99 d5 38 01 a7 25 bf d6 a4 e7 1d 04 84 b7 55 ec 38 3d f7 7a 91 6e c0 db 2623 c0 2b ba 7c 21 a2 00 80 7b 4f 58 5f 72 8b 67 1a d6 78 a4 3a ac d3 3b 78 2624 eb d5 66 cd 00 4f c6 f1 d4 06 f0 1d 97 04 e7 05 b2 15 52 a9 eb 28 ea 31 2625 6a b6 50 37 d7 17 86 2e 2627 message_2 is the CBOR Sequence of data_2 and CIPHERTEXT_2, in this 2628 order: 2630 message_2 = 2631 ( 2632 data_2, 2633 h'99d53801a725bfd6a4e71d0484b755ec383df77a916ec0dbc02bba7c21a200807b4f 2634 585f728b671ad678a43aacd33b78ebd566cd004fc6f1d406f01d9704e705b21552a9eb 2635 28ea316ab65037d717862e' 2636 ) 2638 Which as a CBOR encoded data item is: 2640 message_2 (CBOR Sequence) (117 bytes) 2641 58 20 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 2642 19 52 81 75 4c 5e bc af 30 1e 13 58 50 99 d5 38 01 a7 25 bf d6 a4 e7 1d 2643 04 84 b7 55 ec 38 3d f7 7a 91 6e c0 db c0 2b ba 7c 21 a2 00 80 7b 4f 58 2644 5f 72 8b 67 1a d6 78 a4 3a ac d3 3b 78 eb d5 66 cd 00 4f c6 f1 d4 06 f0 2645 1d 97 04 e7 05 b2 15 52 a9 eb 28 ea 31 6a b6 50 37 d7 17 86 2e 2647 B.1.3. Message_3 2649 Since corr equals 1, C_R is not omitted from data_3. 2651 SK_I (Initiator's private authentication key) (32 bytes) 2652 2f fc e7 a0 b2 b8 25 d3 97 d0 cb 54 f7 46 e3 da 3f 27 59 6e e0 6b 53 71 2653 48 1d c0 e0 12 bc 34 d7 2655 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 2657 PRK_4x3m = HMAC-SHA-256 (PRK_3e2m, G_IY) 2659 PRK_4x3m (32 bytes) 2660 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f 2661 d8 2f be b7 99 71 39 4a 2663 data 3 is equal to C_R. 2665 data_3 (CBOR Sequence) (1 bytes) 2666 13 2668 From data_3, CIPHERTEXT_2, and TH_2, compute the input to the 2669 transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3), as a CBOR 2670 Sequence of these 3 data items. 2672 Input to calculate TH_3 (CBOR Sequence) (117 bytes) 2673 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 b9 ca 2674 fb 60 9d e4 f6 a1 76 0d 6c f7 58 50 99 d5 38 01 a7 25 bf d6 a4 e7 1d 04 2675 84 b7 55 ec 38 3d f7 7a 91 6e c0 db c0 2b ba 7c 21 a2 00 80 7b 4f 58 5f 2676 72 8b 67 1a d6 78 a4 3a ac d3 3b 78 eb d5 66 cd 00 4f c6 f1 d4 06 f0 1d 2677 97 04 e7 05 b2 15 52 a9 eb 28 ea 31 6a b6 50 37 d7 17 86 2e 13 2678 And from there, compute the transcript hash TH_3 = SHA-256(TH_2 , 2679 CIPHERTEXT_2, data_3) 2681 TH_3 (32 bytes) 2682 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd 2683 b3 2e 4a 27 ce 93 58 da 2685 The initiator's subject name is the empty string: 2687 Initiator's subject name (text string) 2688 "" 2690 CRED_I is the certificate (X509_I) encoded as a CBOR byte string: 2692 X509_I (101 bytes) 2693 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79 2694 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60 2695 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37 2696 00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 2697 ec 3f f2 45 b7 2699 CRED_I (103 bytes) 2700 58 65 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f 2701 fc 79 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 2702 95 60 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 2703 88 37 00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2704 2b 87 ec 3f f2 45 b7 2706 And because certificates are identified by a hash value with the 2707 'x5t' parameter, ID_CRED_I is the following: 2709 ID_CRED_I = { 34 : COSE_CertHash }. In this example, the hash 2710 algorithm used is SHA-2 256-bit with hash truncated to 64-bits (value 2711 -15). The hash value is calculated over the certificate X509_I. 2713 ID_CRED_I = 2714 { 2715 34: [-15, h'FC79990F2431A3F5'] 2716 } 2718 ID_CRED_I (14 bytes) 2719 a1 18 22 82 2e 48 5b 78 69 88 43 9e bc f2 2721 Since no opaque auxiliary data is exchanged: 2723 AD_3 (0 bytes) 2725 The Plaintext of the COSE_Encrypt is the empty string: 2727 P_3m (0 bytes) 2729 The external_aad is the CBOR Sequence od CRED_I and TH_3, in this 2730 order: 2732 A_3m (CBOR-encoded) (164 bytes) 2733 83 68 45 6e 63 72 79 70 74 30 4e a1 18 22 82 2e 48 5b 78 69 88 43 9e bc 2734 f2 58 89 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 2735 3e f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 58 65 fa 34 b2 2a 9c a4 a1 e1 29 2736 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79 5f 88 af c4 9c be 8a fd d1 2737 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60 1f 6f 0a 08 52 97 8b d4 3d 2738 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37 00 16 b8 96 5b db 20 74 bf 2739 f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 ec 3f f2 45 b7 2741 Info for K_3m is computed as follows: 2743 info for K_3m = 2744 [ 2745 10, 2746 h'A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358DA', 2747 "K_3m", 2748 16 2749 ] 2751 Which as a CBOR encoded data item is: 2753 info for K_3m (CBOR-encoded) (42 bytes) 2754 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 2755 f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 64 4b 5f 33 6d 10 2757 From these parameters, K_3m is computed. Key K_3m is the output of 2758 HKDF-Expand(PRK_4x3m, info, L), where L is the length of K_2m, so 16 2759 bytes. 2761 K_3m (16 bytes) 2762 3d bb f0 d6 01 03 26 e8 27 3f c6 c6 c3 b0 de cd 2764 Nonce IV_3m is the output of HKDF-Expand(PRK_4x3m, info, L), where L 2765 = 13 bytes. 2767 Info for IV_3m is defined as follows: 2769 info for IV_3m = 2770 [ 2771 10, 2772 h'A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358DA', 2773 "IV_3m", 2774 13 2775 ] 2777 Which as a CBOR encoded data item is: 2779 info for IV_3m (CBOR-encoded) (43 bytes) 2780 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 2781 f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 65 49 56 5f 33 6d 0d 2783 From these parameters, IV_3m is computed: 2785 IV_3m (13 bytes) 2786 10 b6 f4 41 4a 2c 91 3c cd a1 96 42 e3 2788 MAC_3 is the ciphertext of the COSE_Encrypt0: 2790 MAC_3 (8 bytes) 2791 5e ef b8 85 98 3c 22 d9 2793 Since the method = 0, Signature_or_Mac_3 is a signature: 2795 o The message M_3 to be signed = [ "Signature1", << ID_CRED_I >>, 2796 << TH_3, CRED_I >>, MAC_3 ] 2798 o The signing key is the private authentication key of the 2799 Initiator. 2801 M_3 = 2802 [ 2803 "Signature1", 2804 h'A11822822E485B786988439EBCF2', 2805 h'5820A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358D 2806 A5865FA34B22A9CA4A1E12924EAE1D1766088098449CB848FFC795F88AFC49CBE8AFD 2807 D1BA009F21675E8F6C77A4A2C30195601F6F0A0852978BD43D28207D44486502FF7BD 2808 DA632C788370016B8965BDB2074BFF82E5A20E09BEC21F8406E86442B87EC3FF245 2809 B7', 2810 h'5EEFB885983C22D9'] 2812 Which as a CBOR encoded data item is: 2814 M_3 (175 bytes) 2815 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 5b 78 69 88 43 2816 9e bc f2 58 89 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 2817 6d 39 3e f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 58 65 fa 34 b2 2a 9c a4 a1 2818 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79 5f 88 af c4 9c be 8a 2819 fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60 1f 6f 0a 08 52 97 8b 2820 d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37 00 16 b8 96 5b db 20 2821 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 ec 3f f2 45 b7 48 5e 2822 ef b8 85 98 3c 22 d9 2824 From there, the signature can be computed: 2826 Signature_or_MAC_3 (64 bytes) 2827 b3 31 76 33 fa eb c7 f4 24 9c f3 ab 95 96 fd ae 2b eb c8 e7 27 5d 39 9f 2828 42 00 04 f3 76 7b 88 d6 0f fe 37 dc f3 90 a0 00 d8 5a b0 ad b0 d7 24 e3 2829 a5 7c 4d fe 24 14 a4 1e 79 78 91 b9 55 35 89 06 2831 Finally, the outer COSE_Encrypt0 is computed. 2833 The Plaintext is the following CBOR Sequence: plaintext = ( ID_CRED_I 2834 , Signature_or_MAC_3 ) 2836 P_3ae (CBOR Sequence) (80 bytes) 2837 a1 18 22 82 2e 48 5b 78 69 88 43 9e bc f2 58 40 b3 31 76 33 fa eb c7 f4 2838 24 9c f3 ab 95 96 fd ae 2b eb c8 e7 27 5d 39 9f 42 00 04 f3 76 7b 88 d6 2839 0f fe 37 dc f3 90 a0 00 d8 5a b0 ad b0 d7 24 e3 a5 7c 4d fe 24 14 a4 1e 2840 79 78 91 b9 55 35 89 06 2842 The Associated data A is the following: Associated data A = [ 2843 "Encrypt0", h'', TH_3 ] 2845 A_3ae (CBOR-encoded) (45 bytes) 2846 83 68 45 6e 63 72 79 70 74 30 40 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 2847 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 2849 Key K_3ae is the output of HKDF-Expand(PRK_3e2m, info, L). 2851 info is defined as follows: 2853 info for K_3ae = 2854 [ 2855 10, 2856 h'A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358DA', 2857 "K_3ae", 2858 16 2859 ] 2861 Which as a CBOR encoded data item is: 2863 info for K_3ae (CBOR-encoded) (43 bytes) 2864 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 2865 f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 65 4b 5f 33 61 65 10 2867 L is the length of K_3ae, so 16 bytes. 2869 From these parameters, K_3ae is computed: 2871 K_3ae (16 bytes) 2872 58 b5 2f 94 5b 30 9d 85 4c a7 36 cd 06 a9 62 95 2874 Nonce IV_3ae is the output of HKDF-Expand(PRK_3e2m, info, L). 2876 info is defined as follows: 2878 info for IV_3ae = 2879 [ 2880 10, 2881 h'A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358DA', 2882 "IV_3ae", 2883 13 2884 ] 2886 Which as a CBOR encoded data item is: 2888 info for IV_3ae (CBOR-encoded) (44 bytes) 2889 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 2890 f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 66 49 56 5f 33 61 65 0d 2892 L is the length of IV_3ae, so 13 bytes. 2894 From these parameters, IV_3ae is computed: 2896 IV_3ae (13 bytes) 2897 cf a9 a5 85 58 10 d6 dc e9 74 3c 3b c3 2899 Using the parameters above, the ciphertext CIPHERTEXT_3 can be 2900 computed: 2902 CIPHERTEXT_3 (88 bytes) 2903 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db a4 78 05 2904 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e af 56 e4 2905 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 e4 62 f5 2906 f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a 2908 From the parameter above, message_3 is computed, as the CBOR Sequence 2909 of the following items: (C_R, CIPHERTEXT_3). 2911 message_3 = 2912 ( 2913 h'13', 2914 h'' 2915 ) 2917 Which encodes to the following byte string: 2919 message_3 (CBOR Sequence) (91 bytes) 2920 13 58 58 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db 2921 a4 78 05 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e 2922 af 56 e4 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 2923 e4 62 f5 f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a 2925 B.2. Test Vectors for EDHOC Authenticated with Static Diffie-Hellman 2926 Keys 2928 EDHOC with static Diffie-Hellman keys is used. 2930 method (Static DH Based Authentication) 2931 3 2933 CoAP is used as transport and the Initiator acts as CoAP client: 2935 corr (the Initiator can correlate message_1 and message_2) 2936 1 2938 From there, METHOD_CORR has the following value: 2940 METHOD_CORR (4 * method + corr) (int) 2941 13 2943 No unprotected opaque auxiliary data is sent in the message 2944 exchanges. 2946 The list of supported cipher suites of the Initiator in order of 2947 preference is the following: 2949 Supported Cipher Suites (4 bytes) 2950 00 01 02 03 2952 The cipher suite selected by the Initiator is the most preferred: 2954 Selected Cipher Suite (int) 2955 0 2957 The mandatory-to-implement cipher suite 0 is supported by both the 2958 Initiator and the Responder, see Section 8.3. 2960 B.2.1. Message_1 2962 X (Initiator's ephemeral private key) (32 bytes) 2963 ae 11 a0 db 86 3c 02 27 e5 39 92 fe b8 f5 92 4c 50 d0 a7 ba 6e ea b4 ad 2964 1f f2 45 72 f4 f5 7c fa 2966 G_X (Initiator's ephemeral public key) (32 bytes) 2967 8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 a5 38 a4 44 2968 ee 9e 2b 57 e2 44 1a 7c 2970 The Initiator chooses a connection identifier C_I: 2972 Connection identifier chosen by Initiator (1 bytes) 2973 16 2975 Note that since C_I is a byte strings of length one, it is encoded as 2976 the corresponding integer - 24 (see bstr_identifier in Section 5.1), 2977 i.e. 0x16 = 22, 22 - 24 = -2, and -2 in CBOR encoding is equal to 2978 0x21. 2980 C_I (1 byte) 2981 21 2983 Since no unprotected opaque auxiliary data is sent in the message 2984 exchanges: 2986 AD_1 (0 bytes) 2988 Since the list of supported cipher suites needs to contain the 2989 selected cipher suite, the initiator truncates the list of supported 2990 cipher suites to one cipher suite only, 00. 2992 Because one single selected cipher suite is conveyed, it is encoded 2993 as an int instead of an array: 2995 SUITES_I (int) 2996 0 2998 With SUITES_I = 0, message_1 is constructed, as the CBOR Sequence of 2999 the CBOR data items above. 3001 message_1 = 3002 ( 3003 13, 3004 0, 3005 h'8D3EF56D1B750A4351D68AC250A0E883790EFC80A538A444EE9E2B57E2441A7C', 3006 -2 3007 ) 3009 message_1 (CBOR Sequence) (37 bytes) 3010 0d 00 58 20 8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 3011 a5 38 a4 44 ee 9e 2b 57 e2 44 1a 7c 21 3013 B.2.2. Message_2 3015 Since METHOD_CORR mod 4 equals 1, C_I is omitted from data_2. 3017 Y (Responder's ephemeral private key) (32 bytes) 3018 c6 46 cd dc 58 12 6e 18 10 5f 01 ce 35 05 6e 5e bc 35 f4 d4 cc 51 07 49 3019 a3 a5 e0 69 c1 16 16 9a 3021 G_Y (Responder's ephemeral public key) (32 bytes) 3022 52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33 3023 01 04 70 69 45 1b af 35 3025 From G_X and Y or from G_Y and X the ECDH shared secret is computed: 3027 G_XY (ECDH shared secret) (32 bytes) 3028 de fc 2f 35 69 10 9b 3d 1f a4 a7 3d c5 e2 fe b9 e1 15 0d 90 c2 5e e2 f0 3029 66 c2 d8 85 f4 f8 ac 4e 3031 The key and nonce for calculating the ciphertext are calculated as 3032 follows, as specified in Section 4. 3034 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 3036 PRK_2e = HMAC-SHA-256(salt, G_XY) 3038 Salt is the empty byte string. 3040 salt (0 bytes) 3042 From there, PRK_2e is computed: 3044 PRK_2e (32 bytes) 3045 93 9f cb 05 6d 2e 41 4f 1b ec 61 04 61 99 c2 c7 63 d2 7f 0c 3d 15 fa 16 3046 71 fa 13 4e 0d c5 a0 4d 3048 Since the Responder authenticates with a static Diffie-Hellman key, 3049 PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX is the ECDH 3050 shared secret calculated from G_R and X, or G_X and R. 3052 R (Responder's private authentication key) (32 bytes) 3053 bb 50 1a ac 67 b9 a9 5f 97 e0 ed ed 6b 82 a6 62 93 4f bb fc 7a d1 b7 4c 3054 1f ca d6 6a 07 94 22 d0 3055 G_R (Responder's public authentication key) (32 bytes) 3056 a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04 da d2 d4 09 66 ac 6b cb 62 20 51 3057 b8 46 59 18 4d 5d 9a 32 3059 From the Responder's authentication key and the Initiator's ephemeral 3060 key (see Appendix B.2.1), the ECDH shared secret G_RX is calculated. 3062 G_RX (ECDH shared secret) (32 bytes) 3063 21 c7 ef f4 fb 69 fa 4b 67 97 d0 58 84 31 5d 84 11 a3 fd a5 4f 6d ad a6 3064 1d 4f cd 85 e7 90 66 68 3066 PRK_3e2m (32 bytes) 3067 75 07 7c 69 1e 35 01 2d 48 bc 24 c8 4f 2b ab 89 f5 2f ac 03 fe dd 81 3e 3068 43 8c 93 b1 0b 39 93 07 3070 The Responder chooses a connection identifier C_R. 3072 Connection identifier chosen by Responder (1 byte) 3073 20 3075 Note that since C_R is a byte strings of length one, it is encoded as 3076 the corresponding integer - 24 (see bstr_identifier in Section 5.1), 3077 i.e. 0x20 = 32, 32 - 24 = 8, and 8 in CBOR encoding is equal to 0x08. 3079 C_R (1 byte) 3080 08 3082 Data_2 is constructed, as the CBOR Sequence of G_Y and C_R. 3084 data_2 = 3085 ( 3086 h'52FBA0BDC8D953DD86CE1AB2FD7C05A4658C7C30AFDBFC3301047069451BAF35', 3087 08 3088 ) 3090 data_2 (CBOR Sequence) (35 bytes) 3091 58 20 52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db 3092 fc 33 01 04 70 69 45 1b af 35 08 3094 From data_2 and message_1, compute the input to the transcript hash 3095 TH_2 = H( message_1, data_2 ), as a CBOR Sequence of these 2 data 3096 items. 3098 Input to calculate TH_2 (CBOR Sequence) (72 bytes) 3099 0d 00 58 20 8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 3100 a5 38 a4 44 ee 9e 2b 57 e2 44 1a 7c 21 58 20 52 fb a0 bd c8 d9 53 dd 86 3101 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33 01 04 70 69 45 1b af 35 08 3102 And from there, compute the transcript hash TH_2 = SHA-256( 3103 message_1, data_2 ) 3105 TH_2 (32 bytes) 3106 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 0c af 9c 49 3107 1a 52 e6 83 6a 25 64 ff 3109 The Responder's subject name is the empty string: 3111 Responders's subject name (text string) 3112 "" 3114 ID_CRED_R is the following: 3116 ID_CRED_R = 3117 { 3118 4: h'07' 3119 } 3121 ID_CRED_R (4 bytes) 3122 a1 04 41 07 3124 CRED_R is the following COSE_Key: 3126 { 3127 1: 1, 3128 -1: 4, 3129 -2: h'A3FF263595BEB377D1A0CE1D04DAD2D40966AC6BCB622051B84659184D5D9A32', 3130 "subject name": "" 3131 } 3133 Which encodes to the following byte string: 3135 CRED_R (54 bytes) 3136 a4 01 01 20 04 21 58 20 a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04 da d2 d4 3137 09 66 ac 6b cb 62 20 51 b8 46 59 18 4d 5d 9a 32 6c 73 75 62 6a 65 63 74 3138 20 6e 61 6d 65 60 3140 Since no unprotected opaque auxiliary data is sent in the message 3141 exchanges: 3143 AD_2 (0 bytes) 3145 The Plaintext is defined as the empty string: 3147 P_2m (0 bytes) 3148 The Enc_structure is defined as follows: [ "Encrypt0", 3149 << ID_CRED_R >>, << TH_2, CRED_R >> ] 3151 A_2m = 3152 [ 3153 "Encrypt0", 3154 h'A1044107', 3155 h'58206A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FFA401012004215820A3FF263595BEB377D1A0CE1D04DAD2D40966AC6BCB622051B84659184D5D9A326C7375626A656374206E616D6560' 3156 ] 3158 Which encodes to the following byte string to be used as Additional 3159 Authenticated Data: 3161 A_2m (CBOR-encoded) (105 bytes) 3162 83 68 45 6e 63 72 79 70 74 30 44 a1 04 41 07 58 58 58 20 6a 28 78 e8 4b 3163 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 0c af 9c 49 1a 52 e6 83 6a 3164 25 64 ff a4 01 01 20 04 21 58 20 a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04 3165 da d2 d4 09 66 ac 6b cb 62 20 51 b8 46 59 18 4d 5d 9a 32 6c 73 75 62 6a 3166 65 63 74 20 6e 61 6d 65 60 3168 info for K_2m is defined as follows: 3170 info for K_2m = 3171 [ 3172 10, 3173 h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF', 3174 "K_2m", 3175 16 3176 ] 3178 Which as a CBOR encoded data item is: 3180 info for K_2m (CBOR-encoded) (42 bytes) 3181 84 0a 58 20 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 3182 0c af 9c 49 1a 52 e6 83 6a 25 64 ff 64 4b 5f 32 6d 10 3184 From these parameters, K_2m is computed. Key K_2m is the output of 3185 HKDF-Expand(PRK_3e2m, info, L), where L is the length of K_2m, so 16 3186 bytes. 3188 K_2m (16 bytes) 3189 81 2a 48 87 d1 90 ff ed 2b 10 0b a7 a5 c2 5e 67 3191 info for IV_2m is defined as follows: 3193 info for IV_2m = 3194 [ 3195 10, 3196 h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF', 3197 "IV_2m", 3198 13 3199 ] 3201 Which as a CBOR encoded data item is: 3203 info for IV_2m (CBOR-encoded) (43 bytes) 3204 84 0a 58 20 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 3205 0c af 9c 49 1a 52 e6 83 6a 25 64 ff 65 49 56 5f 32 6d 0d 3207 From these parameters, IV_2m is computed. IV_2m is the output of 3208 HKDF-Expand(PRK_3e2m, info, L), where L is the length of IV_2m, so 13 3209 bytes. 3211 IV_2m (13 bytes) 3212 92 3c 0f 94 31 51 5b 69 21 30 49 2b 7f 3214 Finally, COSE_Encrypt0 is computed from the parameters above. 3216 o protected header = CBOR-encoded ID_CRED_R 3218 o external_aad = A_2m 3220 o empty plaintext = P_2m 3222 MAC_2 (8 bytes) 3223 64 21 0d 2e 18 b9 28 cd 3225 From there Signature_or_MAC_2 is the MAC (since method = 3): 3227 Signature_or_MAC_2 (8 bytes) 3228 64 21 0d 2e 18 b9 28 cd 3230 CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a 3231 plaintext constructed from the following parameters and the key K_2e. 3233 o plaintext = CBOR Sequence of the items ID_CRED_R and the CBOR 3234 encoded Signature_or_MAC_2, in this order. Note that since 3235 ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4 3236 : kid_R }, only the byte string kid_R is conveyed in the plaintext 3237 encoded as a bstr_identifier. kid_R is encoded as the 3238 corresponding integer - 24 (see bstr_identifier in Section 5.1), 3239 i.e. 0x07 = 7, 7 - 24 = -17, and -17 in CBOR encoding is equal to 3240 0x30. 3242 The plaintext is the following: 3244 P_2e (CBOR Sequence) (10 bytes) 3245 30 48 64 21 0d 2e 18 b9 28 cd 3247 K_2e = HKDF-Expand( PRK, info, length ), where length is the length 3248 of the plaintext, so 10. 3250 info for K_2e = 3251 [ 3252 10, 3253 h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF', 3254 "K_2e", 3255 10 3256 ] 3258 Which as a CBOR encoded data item is: 3260 info for K_2e (CBOR-encoded) (42 bytes) 3261 84 0a 58 20 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 3262 0c af 9c 49 1a 52 e6 83 6a 25 64 ff 64 4b 5f 32 65 0a 3264 From there, K_2e is computed: 3266 K_2e (10 bytes) 3267 ec be 9a bd 5f 62 3a fc 65 26 3269 Using the parameters above, the ciphertext CIPHERTEXT_2 can be 3270 computed: 3272 CIPHERTEXT_2 (10 bytes) 3273 dc f6 fe 9c 52 4c 22 45 4d eb 3275 message_2 is the CBOR Sequence of data_2 and CIPHERTEXT_2, in this 3276 order: 3278 message_2 = 3279 ( 3280 data_2, 3281 h'DCF6FE9C524C22454DEB' 3282 ) 3284 Which as a CBOR encoded data item is: 3286 message_2 (CBOR Sequence) (46 bytes) 3287 58 20 52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db 3288 fc 33 01 04 70 69 45 1b af 35 08 4a dc f6 fe 9c 52 4c 22 45 4d eb 3290 B.2.3. Message_3 3292 Since corr equals 1, C_R is not omitted from data_3. 3294 SK_I (Initiator's private authentication key) (32 bytes) 3295 2b be a6 55 c2 33 71 c3 29 cf bd 3b 1f 02 c6 c0 62 03 38 37 b8 b5 90 99 3296 a4 43 6f 66 60 81 b0 8e 3298 G_I (Initiator's public authentication key) (32 bytes) 3299 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae da fe 9c aa 4f 4e 7a bb 83 5e c3 3300 0f 1d e8 8a db 96 ff 71 3302 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 3304 From the Initiator's authentication key and the Responder's ephemeral 3305 key (see Appendix B.2.2), the ECDH shared secret G_IY is calculated. 3307 G_IY (ECDH shared secret) (32 bytes) 3308 cb ff 8c d3 4a 81 df ec 4c b6 5d 9a 57 2e bd 09 64 45 0c 78 56 3d a4 98 3309 1d 80 d3 6c 8b 1a 75 2a 3311 PRK_4x3m = HMAC-SHA-256 (PRK_3e2m, G_IY). 3313 PRK_4x3m (32 bytes) 3314 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f 3315 d8 2f be b7 99 71 39 4a 3317 data 3 is equal to C_R. 3319 data_3 (CBOR Sequence) (1 bytes) 3320 08 3322 From data_3, CIPHERTEXT_2, and TH_2, compute the input to the 3323 transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3), as a CBOR 3324 Sequence of these 3 data items. 3326 Input to calculate TH_3 (CBOR Sequence) (46 bytes) 3327 58 20 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 0c af 3328 9c 49 1a 52 e6 83 6a 25 64 ff 4a dc f6 fe 9c 52 4c 22 45 4d eb 08 3330 And from there, compute the transcript hash TH_3 = SHA-256(TH_2 , 3331 CIPHERTEXT_2, data_3) 3333 TH_3 (32 bytes) 3334 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc e4 80 16 07 3335 03 ee d9 c4 a1 bc b6 11 3337 The initiator's subject name is the empty string: 3339 Initiator's subject name (text string) 3340 "" 3342 And its credential is: 3344 ID_CRED_I = 3345 { 3346 4: h'24' 3347 } 3349 ID_CRED_I (4 bytes) 3350 a1 04 41 24 3352 CRED_I is the following COSE_Key: 3354 { 3355 1: 1, 3356 -1: 4, 3357 -2: h'2C440CC121F8D7F24C3B0E41AEDAFE9CAA4F4E7ABB835EC30F1DE88ADB96FF71', 3358 "subject name": "" 3359 } 3361 Which encodes to the following byte string: 3363 CRED_I (54 bytes) 3364 a4 01 01 20 04 21 58 20 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae da fe 9c 3365 aa 4f 4e 7a bb 83 5e c3 0f 1d e8 8a db 96 ff 71 6c 73 75 62 6a 65 63 74 3366 20 6e 61 6d 65 60 3368 Since no opaque auxiliary data is exchanged: 3370 AD_3 (0 bytes) 3372 The Plaintext of the COSE_Encrypt is the empty string: 3374 P_3m (0 bytes) 3376 The external_aad is the CBOR Sequence of CRED_I and TH_3, in this 3377 order: 3379 A_3m (CBOR-encoded) (105 bytes) 3380 83 68 45 6e 63 72 79 70 74 30 44 a1 04 41 24 58 58 58 20 51 dd 22 43 a6 3381 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc e4 80 16 07 03 ee d9 c4 a1 3382 bc b6 11 a4 01 01 20 04 21 58 20 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae 3383 da fe 9c aa 4f 4e 7a bb 83 5e c3 0f 1d e8 8a db 96 ff 71 6c 73 75 62 6a 3384 65 63 74 20 6e 61 6d 65 60 3386 Info for K_3m is computed as follows: 3388 info for K_3m = 3389 [ 3390 10, 3391 h'51DD2243A6B83F1316DC53291AE191CD93B444CCE480160703EED9C4A1BCB611', 3392 "K_3m", 3393 16 3394 ] 3396 Which as a CBOR encoded data item is: 3398 info for K_3m (CBOR-encoded) (42 bytes) 3399 84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc 3400 e4 80 16 07 03 ee d9 c4 a1 bc b6 11 64 4b 5f 33 6d 10 3402 From these parameters, K_3m is computed. Key K_3m is the output of 3403 HKDF-Expand(PRK_4x3m, info, L), where L is the length of K_2m, so 16 3404 bytes. 3406 K_3m (16 bytes) 3407 84 85 31 8a a3 08 6f d5 86 7a 02 8e 99 e2 40 30 3409 Nonce IV_3m is the output of HKDF-Expand(PRK_4x3m, info, L), where L 3410 = 13 bytes. 3412 Info for IV_3m is defined as follows: 3414 info for IV_3m = 3415 [ 3416 10, 3417 h'51DD2243A6B83F1316DC53291AE191CD93B444CCE480160703EED9C4A1BCB611', 3418 "IV_3m", 3419 13 3420 ] 3422 Which as a CBOR encoded data item is: 3424 info for IV_3m (CBOR-encoded) (43 bytes) 3425 84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc 3426 e4 80 16 07 03 ee d9 c4 a1 bc b6 11 65 49 56 5f 33 6d 0d 3428 From these parameters, IV_3m is computed: 3430 IV_3m (13 bytes) 3431 1e 10 5b 88 50 0e d5 ae b0 5d 00 6b ea 3433 MAC_3 is the ciphertext of the COSE_Encrypt0: 3435 MAC_3 (8 bytes) 3436 1f b7 5a c1 aa d2 34 25 3438 Since the method = 3, Signature_or_Mac_3 is the MAC_3: 3440 Signature_or_MAC_3 (8 bytes) 3441 1f b7 5a c1 aa d2 34 25 3443 Finally, the outer COSE_Encrypt0 is computed. 3445 The Plaintext is the following CBOR Sequence: plaintext = ( ID_CRED_I 3446 , Signature_or_MAC_3 ). Note that since ID_CRED_I contains a single 3447 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte 3448 string kid_I is conveyed in the plaintext encoded as a 3449 bstr_identifier. kid_I is encoded as the corresponding integer - 24 3450 (see bstr_identifier in Section 5.1), i.e. 0x24 = 36, 36 - 24 = 12, 3451 and 12 in CBOR encoding is equal to 0x0c. 3453 P_3ae (CBOR Sequence) (10 bytes) 3454 0c 48 1f b7 5a c1 aa d2 34 25 3456 The Associated data A is the following: Associated data A = [ 3457 "Encrypt0", h'', TH_3 ] 3459 A_3ae (CBOR-encoded) (45 bytes) 3460 83 68 45 6e 63 72 79 70 74 30 40 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 3461 29 1a e1 91 cd 93 b4 44 cc e4 80 16 07 03 ee d9 c4 a1 bc b6 11 3463 Key K_3ae is the output of HKDF-Expand(PRK_3e2m, info, L). 3465 info is defined as follows: 3467 info for K_3ae = 3468 [ 3469 10, 3470 h'51DD2243A6B83F1316DC53291AE191CD93B444CCE480160703EED9C4A1BCB611', 3471 "K_3ae", 3472 16 3473 ] 3475 Which as a CBOR encoded data item is: 3477 info for K_3ae (CBOR-encoded) (43 bytes) 3478 84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc 3479 e4 80 16 07 03 ee d9 c4 a1 bc b6 11 65 4b 5f 33 61 65 10 3481 L is the length of K_3ae, so 16 bytes. 3483 From these parameters, K_3ae is computed: 3485 K_3ae (16 bytes) 3486 bf 29 0b 7e e0 4b 86 5d e1 01 0a 81 1b 36 00 64 3488 Nonce IV_3ae is the output of HKDF-Expand(PRK_3e2m, info, L). 3490 info is defined as follows: 3492 info for IV_3ae = 3493 [ 3494 10, 3495 h'51DD2243A6B83F1316DC53291AE191CD93B444CCE480160703EED9C4A1BCB611', 3496 "IV_3ae", 3497 13 3498 ] 3500 Which as a CBOR encoded data item is: 3502 info for IV_3ae (CBOR-encoded) (44 bytes) 3503 84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc 3504 e4 80 16 07 03 ee d9 c4 a1 bc b6 11 66 49 56 5f 33 61 65 0d 3506 L is the length of IV_3ae, so 13 bytes. 3508 From these parameters, IV_3ae is computed: 3510 IV_3ae (13 bytes) 3511 0e 74 45 0a fc ec e9 73 af 64 e9 4d 46 3513 Using the parameters above, the ciphertext CIPHERTEXT_3 can be 3514 computed: 3516 CIPHERTEXT_3 (18 bytes) 3517 53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0 3519 From the parameter above, message_3 is computed, as the CBOR Sequence 3520 of the following items: (C_R, CIPHERTEXT_3). 3522 message_3 = 3523 ( 3524 h'08', 3525 h'53C3991999A5FFB86921E99B607C067770E0' 3526 ) 3528 Which encodes to the following byte string: 3530 message_3 (CBOR Sequence) (20 bytes) 3531 08 52 53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0 3533 Appendix C. Applicability Statement Template 3535 EDHOC requires certain parameters to be agreed upon between Initiator 3536 and Responder. A cipher suite is negotiated with the protocol, but 3537 certain other parameters need to be agreed beforehand: 3539 1. Method and correlation of underlying transport messages 3540 (METHOD_CORR, see Section 3.2.1 and Section 3.2.4). 3542 2. Type of authentication credentials (CRED_I, CRED_R, see 3543 Section 3.3.4). 3545 3. Type for identifying authentication credentials (ID_CRED_I, 3546 ID_CRED_R, see Section 3.3.4). 3548 4. Type and use of Auxiliary Data AD_1, AD_2, AD_3 (see 3549 Section 3.6). 3551 5. Identifier used as identity of endpoint (see Section 3.3). 3553 An example of an applicability statement is shown in the next 3554 section. 3556 Note that for some of the parameters, like METHOD_CORR, ID_CRED_x, 3557 type of AD_x, the receiver is able to assert whether it supports the 3558 parameter or not and thus, if it fails, to infer why. 3560 For other parameters, like type of authentication credential, it may 3561 be more difficult to detect if the receiver got the wrong type since 3562 the credential is not necessarily transported, and a failed integrity 3563 of the received message may be caused by other circumstances. For 3564 example in the case of public key certificates there is a large 3565 variety of profiles and alternative encodings, which the 3566 applicability statement needs to nail down. 3568 Note also that it is not always necessary for the endpoints to agree 3569 on the transport for the EDHOC messages. For example, a mix of CoAP 3570 and HTTP may be used along the path and still allow correlation 3571 between message_1 and message_2. 3573 C.1. Use of EDHOC in the XX Protocol 3575 For use of EDHOC in the XX protocol, the following assumptions are 3576 made on the parameters. 3578 o METHOD_CORR = 5 3580 * method = 1 (I uses signature key, R uses static DH key.) 3582 * corr = 1 (CoAP Token or other transport data enables 3583 correlation between message_1 and message_2.) 3585 o CRED_I is an 802.1AR IDevID encoded as a CBOR Certificate of type 3586 0 3588 * R acquires CRED_I out-of-band, indicated in AD_1 3590 * ID_CRED_I = {4: h''} is a kid with value empty byte string 3592 o CRED_R is a COSE_Key of type OKP as specified in Section 3.3.4. 3594 * The CBOR map has parameters 1 (kty), -1 (crv), and -2 3595 (x-coordinate). 3597 o ID_CRED_R = CRED_R 3599 o AD_1 contains Auxiliary Data of type A (TBD) 3601 o AD_2 contains Auxiliary Data of type B (TBD) 3603 Auxiliary Data is processed as specified in 3604 [I-D.ietf-ace-oauth-authz]. 3606 o Need to specify use of C_I/C_R ? (TBD) 3608 Acknowledgments 3610 The authors want to thank Alessandro Bruni, Karthikeyan Bhargavan, 3611 Martin Disch, Theis Groenbech Petersen, Dan Harkins, Klaus Hartke, 3612 Russ Housley, Alexandros Krontiris, Ilari Liusvaara, Karl Norrman, 3613 Salvador Perez, Eric Rescorla, Michael Richardson, Thorvald Sahl 3614 Joergensen, Jim Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav 3615 Smyshlyaev, Valery Smyslov, Rene Struik, Vaishnavi Sundararajan, Erik 3616 Thormarker, and Michel Veillette for reviewing and commenting on 3617 intermediate versions of the draft. We are especially indebted to 3618 Jim Schaad for his continuous reviewing and implementation of 3619 different versions of the draft. 3621 Authors' Addresses 3622 Goeran Selander 3623 Ericsson AB 3625 Email: goran.selander@ericsson.com 3627 John Preuss Mattsson 3628 Ericsson AB 3630 Email: john.mattsson@ericsson.com 3632 Francesca Palombini 3633 Ericsson AB 3635 Email: francesca.palombini@ericsson.com