idnits 2.17.1 draft-ietf-lake-edhoc-14.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2823): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 10 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 May 2022) is 709 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: '5' on line 1910 -- Looks like a reference, but probably isn't: '6' on line 1910 -- Looks like a reference, but probably isn't: '9' on line 1906 -- Looks like a reference, but probably isn't: '8' on line 1910 -- Looks like a reference, but probably isn't: '7' on line 1910 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-08 ** 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 7624 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8376 == Outdated reference: A later version (-11) exists of draft-ietf-core-oscore-edhoc-03 == Outdated reference: A later version (-07) exists of draft-ietf-core-oscore-key-update-01 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-03 == Outdated reference: A later version (-09) exists of draft-ietf-lake-traces-00 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-security-protocol-comparison-05 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-12 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 7 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. Preuß Mattsson 4 Intended status: Standards Track F. Palombini 5 Expires: 19 November 2022 Ericsson 6 18 May 2022 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-ietf-lake-edhoc-14 11 Abstract 13 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 14 very compact and lightweight authenticated Diffie-Hellman key 15 exchange with ephemeral keys. EDHOC provides mutual authentication, 16 forward secrecy, and identity protection. EDHOC is intended for 17 usage in constrained scenarios and a main use case is to establish an 18 OSCORE security context. By reusing COSE for cryptography, CBOR for 19 encoding, and CoAP for transport, the additional code size can be 20 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 19 November 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Message Size Examples . . . . . . . . . . . . . . . . . . 5 58 1.3. Document Structure . . . . . . . . . . . . . . . . . . . 6 59 1.4. Terminology and Requirements Language . . . . . . . . . . 6 60 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.3. Connection Identifiers . . . . . . . . . . . . . . . . . 10 65 3.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.5. Authentication Parameters . . . . . . . . . . . . . . . . 13 67 3.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 17 68 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 19 69 3.8. External Authorization Data (EAD) . . . . . . . . . . . . 19 70 3.9. Application Profile . . . . . . . . . . . . . . . . . . . 20 71 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 22 72 4.1. Keys for EDHOC Message Processing . . . . . . . . . . . . 22 73 4.2. Keys for EDHOC Applications . . . . . . . . . . . . . . . 25 74 5. Message Formatting and Processing . . . . . . . . . . . . . . 27 75 5.1. Message Processing Outline . . . . . . . . . . . . . . . 27 76 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 28 77 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 30 78 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 32 79 5.5. EDHOC Message 4 . . . . . . . . . . . . . . . . . . . . . 36 80 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 37 81 6.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 39 82 6.2. Unspecified Error . . . . . . . . . . . . . . . . . . . . 39 83 6.3. Wrong Selected Cipher Suite . . . . . . . . . . . . . . . 39 84 7. Compliance Requirements . . . . . . . . . . . . . . . . . . . 42 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 86 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 43 87 8.2. Cryptographic Considerations . . . . . . . . . . . . . . 45 88 8.3. Cipher Suites and Cryptographic Algorithms . . . . . . . 47 89 8.4. Post-Quantum Considerations . . . . . . . . . . . . . . . 47 90 8.5. Unprotected Data and Privacy . . . . . . . . . . . . . . 48 91 8.6. Updated Internet Threat Model Considerations . . . . . . 48 92 8.7. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 49 93 8.8. Implementation Considerations . . . . . . . . . . . . . . 49 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 95 9.1. EDHOC Exporter Label Registry . . . . . . . . . . . . . . 52 96 9.2. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 52 97 9.3. EDHOC Method Type Registry . . . . . . . . . . . . . . . 53 98 9.4. EDHOC Error Codes Registry . . . . . . . . . . . . . . . 54 99 9.5. EDHOC External Authorization Data Registry . . . . . . . 54 100 9.6. COSE Header Parameters Registry . . . . . . . . . . . . . 54 101 9.7. The Well-Known URI Registry . . . . . . . . . . . . . . . 54 102 9.8. Media Types Registry . . . . . . . . . . . . . . . . . . 55 103 9.9. CoAP Content-Formats Registry . . . . . . . . . . . . . . 57 104 9.10. Resource Type (rt=) Link Target Attribute Values 105 Registry . . . . . . . . . . . . . . . . . . . . . . . . 57 106 9.11. Expert Review Instructions . . . . . . . . . . . . . . . 57 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 58 109 10.2. Informative References . . . . . . . . . . . . . . . . . 61 110 Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 65 111 A.1. Deriving the OSCORE Security Context . . . . . . . . . . 65 112 A.2. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 66 113 Appendix B. Compact Representation . . . . . . . . . . . . . . . 70 114 Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 70 115 C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 71 116 C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 72 117 C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 73 118 Appendix D. Authentication Related Verifications . . . . . . . . 75 119 D.1. Validating the Authentication Credential . . . . . . . . 76 120 D.2. Identities . . . . . . . . . . . . . . . . . . . . . . . 76 121 D.3. Certification Path and Trust Anchors . . . . . . . . . . 77 122 D.4. Revocation Status . . . . . . . . . . . . . . . . . . . . 78 123 D.5. Trust-on-first-use . . . . . . . . . . . . . . . . . . . 78 124 Appendix E. Use of External Authorization Data . . . . . . . . . 78 125 Appendix F. Application Profile Example . . . . . . . . . . . . 80 126 Appendix G. EDHOC Message Deduplication . . . . . . . . . . . . 80 127 Appendix H. Transports Not Natively Providing Correlation . . . 82 128 Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 82 129 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 90 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 132 1. Introduction 134 1.1. Motivation 136 Many Internet of Things (IoT) deployments require technologies which 137 are highly performant in constrained environments [RFC7228]. IoT 138 devices may be constrained in various ways, including memory, 139 storage, processing capacity, and power. The connectivity for these 140 settings may also exhibit constraints such as unreliable and lossy 141 channels, highly restricted bandwidth, and dynamic topology. The 142 IETF has acknowledged this problem by standardizing a range of 143 lightweight protocols and enablers designed for the IoT, including 144 the Constrained Application Protocol (CoAP, [RFC7252]), Concise 145 Binary Object Representation (CBOR, [RFC8949]), and Static Context 146 Header Compression (SCHC, [RFC8724]). 148 The need for special protocols targeting constrained IoT deployments 149 extends also to the security domain [I-D.ietf-lake-reqs]. Important 150 characteristics in constrained environments are the number of round 151 trips and protocol message sizes, which if kept low can contribute to 152 good performance by enabling transport over a small number of radio 153 frames, reducing latency due to fragmentation or duty cycles, etc. 154 Another important criteria is code size, which may be prohibitive for 155 certain deployments due to device capabilities or network load during 156 firmware update. Some IoT deployments also need to support a variety 157 of underlying transport technologies, potentially even with a single 158 connection. 160 Some security solutions for such settings exist already. CBOR Object 161 Signing and Encryption (COSE, [I-D.ietf-cose-rfc8152bis-struct]) 162 specifies basic application-layer security services efficiently 163 encoded in CBOR. Another example is Object Security for Constrained 164 RESTful Environments (OSCORE, [RFC8613]) which is a lightweight 165 communication security extension to CoAP using CBOR and COSE. In 166 order to establish good quality cryptographic keys for security 167 protocols such as COSE and OSCORE, the two endpoints may run an 168 authenticated Diffie-Hellman key exchange protocol, from which shared 169 secret keying material can be derived. Such a key exchange protocol 170 should also be lightweight; to prevent bad performance in case of 171 repeated use, e.g., due to device rebooting or frequent rekeying for 172 security reasons; or to avoid latencies in a network formation 173 setting with many devices authenticating at the same time. 175 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 176 lightweight authenticated key exchange protocol providing good 177 security properties including forward secrecy, identity protection, 178 and cipher suite negotiation. Authentication can be based on raw 179 public keys (RPK) or public key certificates and requires the 180 application to provide input on how to verify that endpoints are 181 trusted. This specification emphasizes the possibility to reference 182 rather than to transport credentials in order to reduce message 183 overhead, but the latter is also supported. EDHOC does not currently 184 support pre-shared key (PSK) authentication as authentication with 185 static Diffie-Hellman public keys by reference produces equally small 186 message sizes but with much simpler key distribution and identity 187 protection. 189 EDHOC makes use of known protocol constructions, such as SIGMA 190 [SIGMA] and Extract-and-Expand [RFC5869]. EDHOC uses COSE for 191 cryptography and identification of credentials (including COSE_Key, 192 CBOR Web Token (CWT), CWT Claims Set (CCS), X.509, and CBOR encoded 193 X.509 (C509) certificates, see Section 3.5.2). COSE provides crypto 194 agility and enables the use of future algorithms and credential types 195 targeting IoT. 197 EDHOC is designed for highly constrained settings making it 198 especially suitable for low-power wide area networks [RFC8376] such 199 as Cellular IoT, 6TiSCH, and LoRaWAN. A main objective for EDHOC is 200 to be a lightweight authenticated key exchange for OSCORE, i.e., to 201 provide authentication and session key establishment for IoT use 202 cases such as those built on CoAP [RFC7252] involving 'things' with 203 embedded microcontrollers, sensors, and actuators. By reusing the 204 same lightweight primitives as OSCORE (CBOR, COSE, CoAP) the 205 additional code size can be kept very low. Note that while CBOR and 206 COSE primitives are built into the protocol messages, EDHOC is not 207 bound to a particular transport. 209 A typical setting is when one of the endpoints is constrained or in a 210 constrained network, and the other endpoint is a node on the Internet 211 (such as a mobile phone). Thing-to-thing interactions over 212 constrained networks are also relevant since both endpoints would 213 then benefit from the lightweight properties of the protocol. EDHOC 214 could, e.g., be run when a device connects for the first time, or to 215 establish fresh keys which are not revealed by a later compromise of 216 the long-term keys. 218 1.2. Message Size Examples 220 Compared to the DTLS 1.3 handshake [RFC9147] with ECDHE and 221 connection ID, the EDHOC message size when transferred in CoAP can be 222 less than 1/6 when RPK authentication is used, see 223 [I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows 224 examples of EDHOC message sizes based on the assumptions in Section 2 225 of [I-D.ietf-lwig-security-protocol-comparison], comparing different 226 kinds of authentication keys and COSE header parameters for 227 identification: static Diffie-Hellman keys or signature keys, either 228 in CBOR Web Token (CWT) / CWT Claims Set (CCS) [RFC8392] identified 229 by a key identifier using 'kid' [I-D.ietf-cose-rfc8152bis-struct], or 230 in X.509 certificates identified by a hash value using 'x5t' 231 [I-D.ietf-cose-x509]. 233 ======================================================== 234 Static DH Keys Signature Keys 235 -------------- -------------- 236 kid x5t kid x5t 237 -------------------------------------------------------- 238 message_1 37 37 37 37 239 message_2 45 58 102 115 240 message_3 19 33 77 90 241 -------------------------------------------------------- 242 Total 101 128 216 242 243 ======================================================== 245 Figure 1: Examples of EDHOC message sizes in bytes. 247 1.3. Document Structure 249 The remainder of the document is organized as follows: Section 2 250 outlines EDHOC authenticated with signature keys, Section 3 describes 251 the protocol elements of EDHOC, including formatting of the ephemeral 252 public keys, Section 4 specifies the key derivation, Section 5 253 specifies message processing for EDHOC authenticated with signature 254 keys or static Diffie-Hellman keys, Section 6 describes the error 255 messages, and Appendix A shows how to transfer EDHOC with CoAP and 256 establish an OSCORE security context. 258 1.4. Terminology and Requirements Language 260 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 262 "OPTIONAL" in this document are to be interpreted as described in BCP 263 14 [RFC2119] [RFC8174] when, and only when, they appear in all 264 capitals, as shown here. 266 Readers are expected to be familiar with the terms and concepts 267 described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE 268 structures and processing [I-D.ietf-cose-rfc8152bis-struct], COSE 269 algorithms [I-D.ietf-cose-rfc8152bis-algs], CWT and CWT Claims Set 270 [RFC8392], and the Concise Data Definition Language (CDDL, 271 [RFC8610]), which is used to express CBOR data structures. Examples 272 of CBOR and CDDL are provided in Appendix C.1. When referring to 273 CBOR, this specification always refers to Deterministically Encoded 274 CBOR as specified in Sections 4.2.1 and 4.2.2 of [RFC8949]. The 275 single output from authenticated encryption (including the 276 authentication tag) is called "ciphertext", following [RFC5116]. 278 2. EDHOC Outline 280 EDHOC specifies different authentication methods of the ephemeral 281 Diffie-Hellman key exchange: signature keys and static Diffie-Hellman 282 keys. This section outlines the signature key based method. Further 283 details of protocol elements and other authentication methods are 284 provided in the remainder of this document. 286 SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a 287 large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS 288 1.3 [RFC8446][RFC9147], EDHOC authenticated with signature keys is 289 built on a variant of the SIGMA protocol which provides identity 290 protection of the initiator (SIGMA-I) against active attackers, and 291 like IKEv2, EDHOC implements the MAC-then-Sign variant of the SIGMA-I 292 protocol shown in Figure 2. 294 Initiator Responder 295 | G_X | 296 +------------------------------------------------------------------>| 297 | | 298 | G_Y, Enc( ID_CRED_R, Sig( R; MAC( CRED_R, G_X, G_Y ) ) ) | 299 |<------------------------------------------------------------------+ 300 | | 301 | AEAD( ID_CRED_I, Sig( I; MAC( CRED_I, G_Y, G_X ) ) ) | 302 +------------------------------------------------------------------>| 303 | | 305 Figure 2: MAC-then-Sign variant of the SIGMA-I protocol used by 306 EDHOC. 308 The parties exchanging messages are called Initiator (I) and 309 Responder (R). They exchange ephemeral public keys, compute a shared 310 secret key PRK_out, and derive symmetric application keys used to 311 protect application data. 313 * G_X and G_Y are the ECDH ephemeral public keys of I and R, 314 respectively. 316 * CRED_I and CRED_R are the authentication credentials containing 317 the public authentication keys of I and R, respectively. 319 * ID_CRED_I and ID_CRED_R are used to identify and optionally 320 transport the credentials of the Initiator and the Responder, 321 respectively. 323 * Sig(I; . ) and Sig(R; . ) denote signatures made with the private 324 authentication key of I and R, respectively. 326 * Enc(), AEAD(), and MAC() denotes encryption, authenticated 327 encryption with additional data, and message authentication code 328 using keys derived from the shared secret. 330 In order to create a "full-fledged" protocol some additional protocol 331 elements are needed. EDHOC adds: 333 * Transcript hashes (hashes of message data) TH_2, TH_3, TH_4 used 334 for key derivation and as additional authenticated data. 336 * Computationally independent keys derived from the ECDH shared 337 secret and used for authenticated encryption of different 338 messages. 340 * An optional fourth message giving key confirmation to I in 341 deployments where no protected application data is sent from R to 342 I. 344 * A keying material exporter and a key update function with forward 345 secrecy. 347 * Verification of the selected cipher suite. 349 * Method types and error handling. 351 * Selection of connection identifiers C_I and C_R which may be used 352 in EDHOC to identify protocol state. 354 * Transport of external authorization data. 356 EDHOC is designed to encrypt and integrity protect as much 357 information as possible, and all symmetric keys are derived using as 358 much previous information as possible. EDHOC is furthermore designed 359 to be as compact and lightweight as possible, in terms of message 360 sizes, processing, and the ability to reuse already existing CBOR, 361 COSE, and CoAP libraries. 363 To simplify for implementors, the use of CBOR and COSE in EDHOC is 364 summarized in Appendix C. Test vectors including CBOR diagnostic 365 notation are provided in [I-D.ietf-lake-traces]. 367 3. Protocol Elements 368 3.1. General 370 The EDHOC protocol consists of three mandatory messages (message_1, 371 message_2, message_3) between Initiator and Responder, an optional 372 fourth message (message_4), and an error message. All EDHOC messages 373 are CBOR Sequences [RFC8742], and are deterministically encoded. 374 Figure 3 illustrates an EDHOC message flow with the optional fourth 375 message as well as the content of each message. The protocol 376 elements in the figure are introduced in Section 3 and Section 5. 377 Message formatting and processing are specified in Section 5 and 378 Section 6. 380 Application data may be protected using the agreed application 381 algorithms (AEAD, hash) in the selected cipher suite (see 382 Section 3.6) and the application can make use of the established 383 connection identifiers C_I and C_R (see Section 3.3). EDHOC may be 384 used with the media type application/edhoc+cbor-seq defined in 385 Section 9.8. 387 The Initiator can derive symmetric application keys after creating 388 EDHOC message_3, see Section 4.2.1. Protected application data can 389 therefore be sent in parallel or together with EDHOC message_3. 390 EDHOC message_4 is typically not sent. 392 Initiator Responder 393 | METHOD, SUITES_I, G_X, C_I, EAD_1 | 394 +------------------------------------------------------------------>| 395 | message_1 | 396 | | 397 | G_Y, Enc( ID_CRED_R, Signature_or_MAC_2, EAD_2 ), C_R | 398 |<------------------------------------------------------------------+ 399 | message_2 | 400 | | 401 | AEAD( ID_CRED_I, Signature_or_MAC_3, EAD_3 ) | 402 +------------------------------------------------------------------>| 403 | message_3 | 404 | | 405 | AEAD( EAD_4 ) | 406 |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 407 | message_4 | 409 Figure 3: EDHOC message flow including the optional fourth message. 411 3.2. Method 413 The data item METHOD in message_1 (see Section 5.2.1), is an integer 414 specifying the authentication method. EDHOC supports authentication 415 with signature or static Diffie-Hellman keys, as defined in the four 416 authentication methods: 0, 1, 2, and 3, see Figure 4. When using a 417 static Diffie-Hellman key the authentication is provided by a Message 418 Authentication Code (MAC) computed from an ephemeral-static ECDH 419 shared secret which enables significant reductions in message sizes. 421 The Initiator and the Responder need to have agreed on a single 422 method to be used for EDHOC, see Section 3.9. 424 +-------------+--------------------+--------------------+ 425 | Method Type | Initiator | Responder | 426 | Value | Authentication Key | Authentication Key | 427 +-------------+--------------------+--------------------+ 428 | 0 | Signature Key | Signature Key | 429 | 1 | Signature Key | Static DH Key | 430 | 2 | Static DH Key | Signature Key | 431 | 3 | Static DH Key | Static DH Key | 432 +-------------+--------------------+--------------------+ 434 Figure 4: Authentication Keys for Method Types 436 EDHOC does not have a dedicated message field to indicate protocol 437 version. Breaking changes to EDHOC can be introduced by specifying 438 and registering new methods. 440 3.3. Connection Identifiers 442 EDHOC includes the selection of connection identifiers (C_I, C_R) 443 identifying a connection for which keys are agreed. 445 Connection identifiers may be used to correlate EDHOC messages and 446 facilitate the retrieval of protocol state during EDHOC execution 447 (see Section 3.4) or in subsequent applications of EDHOC, e.g., in 448 OSCORE (see Section 3.3.3). The connection identifiers do not have 449 any cryptographic purpose in EDHOC except facilitating the retrieval 450 of security data associated to the protocol state. 452 Connection identifiers in EDHOC are CBOR byte strings. Since most 453 constrained devices only have a few connections, short identifiers 454 are desirable in many cases. However, except for the empty byte 455 string h'', which encodes as one byte (0x40), all byte strings are 456 CBOR encoded as two or more bytes. Therefore EDHOC specifies certain 457 byte strings to be represented as CBOR ints on the wire, see 458 Section 3.3.2. 460 3.3.1. Selection of Connection Identifiers 462 C_I and C_R are chosen by I and R, respectively. The Initiator 463 selects C_I and sends it in message_1 for the Responder to use as a 464 reference to the connection in communications with the Initiator. 465 The Responder selects C_R and sends it in message_2 for the Initiator 466 to use as a reference to the connection in communications with the 467 Responder. 469 If connection identifiers are used by an application protocol for 470 which EDHOC establishes keys then the selected connection identifiers 471 SHALL adhere to the requirements for that protocol, see Section 3.3.3 472 for an example. 474 3.3.2. Representation of Byte String Identifiers 476 To allow identifiers with minimal overhead on the wire, certain byte 477 strings are defined to have integer representations. 479 The integers with one-byte CBOR encoding are -24, ..., 23, see 480 Figure 5. This correspondence between integers and byte strings is a 481 natural mapping between the byte strings with CBOR diagnostic 482 notation h'00', h'01', ..., h'37' (except h'18', h'19', ..., h'1F') 483 and integers which are CBOR encoded as one byte. 485 Integer: -24 -23 ... -2 -1 0 1 ... 23 486 CBOR encoding (1 byte): 37 36 ... 21 20 00 01 ... 17 488 Figure 5: One-Byte CBOR Encoded Integers 490 The byte strings which coincide with a one-byte CBOR encoding of an 491 integer MUST be represented by the CBOR encoding of that integer. 492 Other byte strings are encoded as normal CBOR byte strings. 494 For example: 496 * h'21' is represented by 0x21 (CBOR encoding of the integer -2), 497 not by 0x4121. 499 * h'0D' is represented by 0x0D (CBOR encoding of the integer 13), 500 not by 0x410D. 502 * h'18' is represented by 0x4118. 504 * h'38' is represented by 0x4138. 506 * h'ABCD' is represented by 0x42ABCD. 508 One way to view this representation of byte strings is as a transport 509 encoding: A byte string which parses as a CBOR int in the range -24, 510 ..., 23 is just copied directly into the message, a byte string which 511 doesn't is encoded as a CBOR bstr during transport. 513 3.3.3. Use of Connection Identifiers with OSCORE 515 For OSCORE, the choice of connection identifier results in the 516 endpoint selecting its Recipient ID, see Section 3.1 of [RFC8613], 517 for which certain uniqueness requirements apply, see Section 3.3 of 518 [RFC8613]. Therefore, the Initiator and the Responder MUST NOT 519 select connection identifiers such that it results in same OSCORE 520 Recipient ID. Since the connection identifier is a byte string, it 521 is converted to an OSCORE Recipient ID equal to the byte string. 523 For example, a C_I equal to 0xFF is converted to a (typically client) 524 Responder ID equal to 0xFF; a C_R equal to 0x21 is converted to a 525 (typically server) Responder ID equal to 0x21. Note that the 526 representation of connection identifiers as CBOR byte strings or CBOR 527 ints in EDHOC messages as described in Section 3.3.2 has no impact on 528 this mapping. 530 3.4. Transport 532 Cryptographically, EDHOC does not put requirements on the lower 533 layers. EDHOC is not bound to a particular transport layer and can 534 even be used in environments without IP. In addition to transport of 535 messages including errors, the transport is responsible, where 536 necessary, to handle: 538 * message loss, 540 * message reordering, 542 * message duplication, 544 * fragmentation, 546 * demultiplex EDHOC messages from other types of messages, 548 * denial-of-service protection, 550 * message correlation. 552 The Initiator and the Responder need to have agreed on a transport to 553 be used for EDHOC, see Section 3.9. 555 3.4.1. Use of Connection Identifiers for EDHOC Message Correlation 557 The transport needs to support the correlation between EDHOC messages 558 and facilitate the retrieval of protocol state and security context 559 during EDHOC protocol execution, including an indication of a message 560 being message_1. The correlation may reuse existing mechanisms in 561 the transport protocol. For example, the CoAP Token may be used to 562 correlate EDHOC messages in a CoAP response and an associated CoAP 563 request. 565 Connection identifiers may be used to correlate EDHOC messages and 566 facilitate the retrieval of protocol state/security context during 567 EDHOC protocol execution. Transports that do not inherently provide 568 correlation across all EDHOC messages of an exchange can send 569 connection identifiers along with EDHOC messages to gain that 570 required capability, e.g., by prepending the appropriate connection 571 identifier (when available from the EDHOC protocol) to the EDHOC 572 message. Transport of EDHOC in CoAP payloads is described in 573 Appendix A.2, which also shows how to use connection identifiers and 574 message_1 indication with CoAP. 576 3.5. Authentication Parameters 578 EDHOC supports various settings for how the other endpoint's 579 authentication (public) key may be transported, identified, and 580 trusted. 582 EDHOC performs the following authentication related operations: 584 * EDHOC transports information about credentials in ID_CRED_I and 585 ID_CRED_R (described in Section 3.5.3). Based on this 586 information, the authentication credentials CRED_I and CRED_R 587 (described in Section 3.5.2) can be obtained. EDHOC may also 588 transport certain authentication related information as External 589 Authorization Data (see Section 3.8). 591 * EDHOC uses the authentication credentials in two ways (see 592 Section 5.3.2 and Section 5.4.2): 594 - The authentication credential is input to the integrity 595 verification using the MAC fields. 597 - The authentication key of the authentication credential is used 598 with the Signature_or_MAC field to verify proof-of-possession 599 of the private key. 601 Other authentication related verifications are out of scope for 602 EDHOC, and is the responsibility of the application. In particular, 603 the authentication credential needs to be validated in the context of 604 the connection for which EDHOC is used, see Appendix D. EDHOC MUST 605 allow the application to read received information about credential 606 (ID_CRED_R, ID_CRED_I). EDHOC MUST have access to the authentication 607 key and the authentication credential. 609 Note that the type of authentication key, authentication credential, 610 and the identification of the credential have a large impact on the 611 message size. For example, the signature_or_MAC field is much 612 smaller with a static DH key than with a signature key. A CCS is 613 much smaller than a self-signed certificate/CWT, but if it is 614 possible to reference the credential with a COSE header like 'kid', 615 then that is in turn much smaller than a CCS. 617 3.5.1. Authentication Keys 619 The authentication key (i.e. the public key used for authentication) 620 MUST be a signature key or static Diffie-Hellman key. The Initiator 621 and the Responder MAY use different types of authentication keys, 622 e.g., one uses a signature key and the other uses a static Diffie- 623 Hellman key. 625 The authentication key algorithm needs to be compatible with the 626 method and the cipher suite (see Section 3.6). The authentication 627 key algorithm needs to be compatible with the EDHOC key exchange 628 algorithm when static Diffie-Hellman authentication is used, and 629 compatible with the EDHOC signature algorithm when signature 630 authentication is used. 632 Note that for most signature algorithms, the signature is determined 633 by the signature algorithm and the authentication key algorithm 634 together. When using static Diffie-Hellman keys the Initiator's and 635 Responder's private authentication keys are denoted I and R, 636 respectively, and the public authentication keys are denoted G_I and 637 G_R, respectively. 639 For X.509 certificates the authentication key is represented with a 640 SubjectPublicKeyInfo field. For CWT and CCS (see Section 3.5.2)) the 641 authentication key is represented with a 'cnf' claim [RFC8747] 642 containing a COSE_Key [I-D.ietf-cose-rfc8152bis-struct]. 644 3.5.2. Authentication Credentials 646 The authentication credentials, CRED_I and CRED_R, contain the public 647 authentication key of the Initiator and the Responder, respectively. 649 EDHOC relies on COSE for identification of credentials (see 650 Section 3.5.3), for example X.509 certificates [RFC5280], C509 651 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and 652 CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a 653 chain or a bag, the authentication credential CRED_x is just the end 654 entity X.509 or C509 certificate / CWT. 656 Since CRED_R is used in the integrity verification, see 657 Section 5.3.2, it needs to be specified such that it is identical 658 when used by Initiator or Responder. Similarly for CRED_I, see 659 Section 5.4.2. The Initiator and Responder are expected to agree on 660 a specific encoding of the credential, see Section 3.9. 662 It is RECOMMENDED that the COSE 'kid' parameter, when used to 663 identify the authentication credential, refers to a specific 664 encoding. The Initiator and Responder SHOULD use an available 665 authentication credential (transported in EDHOC or otherwise 666 provisioned) without re-encoding. If for some reason re-encoding of 667 the authentication credential may occur, then a potential common 668 encoding for CBOR based credentials is bytewise lexicographic order 669 of their deterministic encodings as specified in Section 4.2.1 of 670 [RFC8949]. 672 * When the authentication credential is an X.509 certificate, CRED_x 673 SHALL be the DER encoded certificate, encoded as a bstr 674 [I-D.ietf-cose-x509]. 676 * When the authentication credential is a C509 certificate, CRED_x 677 SHALL be the C509Certificate [I-D.ietf-cose-cbor-encoded-cert]. 679 * When the authentication credential is a COSE_Key in a CWT, CRED_x 680 SHALL be the untagged CWT. 682 * When the authentication credential is a COSE_Key but not in a CWT, 683 CRED_x SHALL be an untagged CCS. 685 - Naked COSE_Keys are thus dressed as CCS when used in EDHOC, 686 which is done by prefixing the COSE_Key with 0xA108A101. 688 An example of a CRED_x is shown below: 690 { /CCS/ 691 2 : "42-50-31-FF-EF-37-32-39", /sub/ 692 8 : { /cnf/ 693 1 : { /COSE_Key/ 694 1 : 1, /kty/ 695 2 : h'00', /kid/ 696 -1 : 4, /crv/ 697 -2 : h'b1a3e89460e88d3a8d54211dc95f0b90 /x/ 698 3ff205eb71912d6db8f4af980d2db83a' 699 } 700 } 701 } 703 Figure 6: CWT Claims Set (CCS) containing an X25519 static 704 Diffie-Hellman key and an EUI-64 identity. 706 3.5.3. Identification of Credentials 708 ID_CRED_R and ID_CRED_I are transported in message_2 and message_3, 709 respectively, see Section 5.3.2 and Section 5.4.2. They are used to 710 identify and optionally transport credentials: 712 * ID_CRED_R is intended to facilitate for the Initiator to retrieve 713 the authentication credential CRED_R and the authentication key of 714 R. 716 * ID_CRED_I is intended to facilitate for the Responder to retrieve 717 the authentication credential CRED_I and the authentication key of 718 I. 720 ID_CRED_x may contain the authentication credential CRED_x, but for 721 many settings it is not necessary to transport the authentication 722 credential within EDHOC, for example, it may be pre-provisioned or 723 acquired out-of-band over less constrained links. ID_CRED_I and 724 ID_CRED_R do not have any cryptographic purpose in EDHOC since the 725 authentication credentials are integrity protected. 727 EDHOC relies on COSE for identification of credentials and supports 728 all credential types for which COSE header parameters are defined 729 including X.509 certificates ([I-D.ietf-cose-x509]), C509 730 certificates ([I-D.ietf-cose-cbor-encoded-cert]), CWT (Section 9.6) 731 and CWT Claims Set (CCS) (Section 9.6). 733 ID_CRED_I and ID_CRED_R are COSE header maps and contains one or more 734 COSE header parameters. ID_CRED_I and ID_CRED_R MAY contain 735 different header parameters. The header parameters typically provide 736 some information about the format of the credential. 738 Note that COSE header parameters in ID_CRED_x are used to identify 739 the sender's credential. There is therefore no reason to use the 740 "-sender" header parameters, such as x5t-sender, defined in Section 3 741 of [I-D.ietf-cose-x509]. Instead, the corresponding parameter 742 without "-sender", such as x5t, SHOULD be used. 744 Example: X.509 certificates can be identified by a hash value using 745 the 'x5t' parameter: 747 * ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, 749 Example: CWT or CCS can be identified by a key identifier using the 750 'kid' parameter: 752 * ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or 753 R. 755 The value of a COSE 'kid' parameter is a byte string. To allow one- 756 byte encodings of ID_CRED_x with key identifiers 'kid', which is 757 useful in scenarios with only a few keys, the integer representation 758 of identifiers in Section 3.3.2 MUST be applied. For details, see 759 Section 5.3.2 and Section 5.4.2. 761 As stated in Section 3.1 of [I-D.ietf-cose-rfc8152bis-struct], 762 applications MUST NOT assume that 'kid' values are unique and several 763 keys associated with a 'kid' may need to be checked before the 764 correct one is found. Applications might use additional information 765 such as 'kid context' or lower layers to determine which key to try 766 first. Applications should strive to make ID_CRED_x as unique as 767 possible, since the recipient may otherwise have to try several keys. 769 See Appendix C.3 for more examples. 771 3.6. Cipher Suites 773 An EDHOC cipher suite consists of an ordered set of algorithms from 774 the "COSE Algorithms" and "COSE Elliptic Curves" registries as well 775 as the EDHOC MAC length. All algorithm names and definitions follows 776 from COSE [I-D.ietf-cose-rfc8152bis-algs]. Note that COSE sometimes 777 uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for 778 AES-128, and Ed25519 for the curve edwards25519. Algorithms need to 779 be specified with enough parameters to make them completely 780 determined. The MAC length MUST be at least 8 bytes. Any 781 cryptographic algorithm used in the COSE header parameters in ID_CRED 782 is selected independently of the cipher suite. EDHOC is currently 783 only specified for use with key exchange algorithms of type ECDH 784 curves, but any Key Encapsulation Method (KEM), including Post- 785 Quantum Cryptography (PQC) KEMs, can be used in method 0, see 786 Section 8.4. Use of other types of key exchange algorithms to 787 replace static DH authentication (method 1,2,3) would likely require 788 a specification updating EDHOC with new methods. 790 EDHOC supports all signature algorithms defined by COSE. Just like 791 in (D)TLS 1.3 [RFC8446][RFC9147] and IKEv2 [RFC7296], a signature in 792 COSE is determined by the signature algorithm and the authentication 793 key algorithm together, see Section 3.5.1. The exact details of the 794 authentication key algorithm depend on the type of authentication 795 credential. COSE supports different formats for storing the public 796 authentication keys including COSE_Key and X.509, which use different 797 names and ways to represent the authentication key and the 798 authentication key algorithm. 800 An EDHOC cipher suite consists of the following parameters: 802 * EDHOC AEAD algorithm 804 * EDHOC hash algorithm 806 * EDHOC MAC length in bytes (Static DH) 808 * EDHOC key exchange algorithm (ECDH curve) 810 * EDHOC signature algorithm 812 * Application AEAD algorithm 814 * Application hash algorithm 816 Each cipher suite is identified with a pre-defined integer label. 818 EDHOC can be used with all algorithms and curves defined for COSE. 819 Implementations can either use any combination of COSE algorithms and 820 parameters to define their own private cipher suite, or use one of 821 the pre-defined cipher suites. Private cipher suites can be 822 identified with any of the four values -24, -23, -22, -21. The pre- 823 defined cipher suites are listed in the IANA registry (Section 9.2) 824 with initial content outlined here: 826 * Cipher suites 0-3, based on AES-CCM, are intended for constrained 827 IoT where message overhead is a very important factor. Note that 828 AES-CCM-16-64-128 and AES-CCM-16-64-128 are compatible with the 829 IEEE CCM* mode. 831 - Cipher suites 1 and 3 use a larger tag length (128-bit) in 832 EDHOC than in the Application AEAD algorithm (64-bit). 834 * Cipher suites 4 and 5, based on ChaCha20, are intended for less 835 constrained applications and only use 128-bit tag lengths. 837 * Cipher suite 6, based on AES-GCM, is for general non-constrained 838 applications. It consists of high performance algorithms that are 839 widely used in non-constrained applications. 841 * Cipher suites 24 and 25 are intended for high security 842 applications such as government use and financial applications. 843 These cipher suites do not share any algorithms. Cipher suite 24 844 consists of algorithms from the CNSA suite [CNSA]. 846 The different methods (Section 3.2) use the same cipher suites, but 847 some algorithms are not used in some methods. The EDHOC signature 848 algorithm is not used in methods without signature authentication. 850 The Initiator needs to have a list of cipher suites it supports in 851 order of preference. The Responder needs to have a list of cipher 852 suites it supports. SUITES_I contains cipher suites supported by the 853 Initiator, formatted and processed as detailed in Section 5.2.1 to 854 secure the cipher suite negotiation. Examples of cipher suite 855 negotiation are given in Section 6.3.2. 857 3.7. Ephemeral Public Keys 859 The ephemeral public keys in EDHOC (G_X and G_Y) use compact 860 representation of elliptic curve points, see Appendix B. In COSE 861 compact representation is achieved by formatting the ECDH ephemeral 862 public keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 863 and 7.2 of [I-D.ietf-cose-rfc8152bis-algs], but only including the 864 'x' parameter in G_X and G_Y. For Elliptic Curve Keys of type EC2, 865 compact representation MAY be used also in the COSE_Key. If the COSE 866 implementation requires a 'y' parameter, the value y = false SHALL be 867 used. COSE always use compact output for Elliptic Curve Keys of type 868 EC2. 870 3.8. External Authorization Data (EAD) 872 In order to reduce round trips and the number of messages or to 873 simplify processing, external security applications may be integrated 874 into EDHOC by transporting authorization related data in the 875 messages. 877 EDHOC allows opaque external authorization data (EAD) to be sent in 878 each of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4). 880 External authorization data is a CBOR sequence (see Appendix C.1) 881 consisting of one or more (ead_label, ead_value) pairs as defined 882 below: 884 ead = 1* ( 885 ead_label : int, 886 ead_value : bstr, 887 ) 889 A security application using external authorization data need to 890 register an ead_label, specify the ead_value format for each message 891 (see Section 9.5), and describe processing and security 892 considerations. 894 The EAD fields of EDHOC must not be used for generic application 895 data. Examples of the use of EAD is provided in Appendix E. 897 3.9. Application Profile 899 EDHOC requires certain parameters to be agreed upon between Initiator 900 and Responder. Some parameters can be negotiated through the 901 protocol execution (specifically, cipher suite, see Section 3.6) but 902 other parameters are only communicated and may not be negotiated 903 (e.g., which authentication method is used, see Section 3.2). Yet 904 other parameters need to be known out-of-band. 906 The purpose of an application profile is to describe the intended use 907 of EDHOC to allow for the relevant processing and verifications to be 908 made, including things like: 910 1. How the endpoint detects that an EDHOC message is received. This 911 includes how EDHOC messages are transported, for example in the 912 payload of a CoAP message with a certain Uri-Path or Content- 913 Format; see Appendix A.2. 915 * The method of transporting EDHOC messages may also describe 916 data carried along with the messages that are needed for the 917 transport to satisfy the requirements of Section 3.4, e.g., 918 connection identifiers used with certain messages, see 919 Appendix A.2. 921 2. Authentication method (METHOD; see Section 3.2). 923 3. Profile for authentication credentials (CRED_I, CRED_R; see 924 Section 3.5.2), e.g., profile for certificate or CCS, including 925 supported authentication key algorithms (subject public key 926 algorithm in X.509 or C509 certificate). 928 4. Type used to identify credentials (ID_CRED_I, ID_CRED_R; see 929 Section 3.5.3). 931 5. Use and type of external authorization data (EAD_1, EAD_2, EAD_3, 932 EAD_4; see Section 3.8). 934 6. Identifier used as the identity of the endpoint; see 935 Appendix D.2. 937 7. If message_4 shall be sent/expected, and if not, how to ensure a 938 protected application message is sent from the Responder to the 939 Initiator; see Section 5.5. 941 The application profile may also contain information about supported 942 cipher suites. The procedure for selecting and verifying a cipher 943 suite is still performed as described in Section 5.2.1 and 944 Section 6.3, but it may become simplified by this knowledge. 946 An example of an application profile is shown in Appendix F. 948 For some parameters, like METHOD, ID_CRED_x, type of EAD, the 949 receiver is able to verify compliance with the application profile, 950 and if it needs to fail because of incompliance, to infer the reason 951 why the protocol failed. 953 For other parameters, like the profile of CRED_x in the case that it 954 is not transported, it may not be possible to verify that 955 incompliance with the application profile was the reason for failure: 956 Integrity verification in message_2 or message_3 may fail not only 957 because of wrong credential. For example, in case the Initiator uses 958 public key certificate by reference (i.e., not transported within the 959 protocol) then both endpoints need to use an identical data structure 960 as CRED_I or else the integrity verification will fail. 962 Note that it is not necessary for the endpoints to specify a single 963 transport for the EDHOC messages. For example, a mix of CoAP and 964 HTTP may be used along the path, and this may still allow correlation 965 between messages. 967 The application profile may be dependent on the identity of the other 968 endpoint, or other information carried in an EDHOC message, but it 969 then applies only to the later phases of the protocol when such 970 information is known. (The Initiator does not know the identity of 971 the Responder before having verified message_2, and the Responder 972 does not know the identity of the Initiator before having verified 973 message_3.) 974 Other conditions may be part of the application profile, such as 975 target application or use (if there is more than one application/use) 976 to the extent that EDHOC can distinguish between them. In case 977 multiple application profiles are used, the receiver needs to be able 978 to determine which is applicable for a given session, for example 979 based on URI or external authorization data type. 981 4. Key Derivation 983 4.1. Keys for EDHOC Message Processing 985 EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm 986 in the selected cipher suite to derive keys used in message 987 processing. This section defines Extract (Section 4.1.1) and Expand 988 (Section 4.1.2), and how to use them to derive PRK_out 989 (Section 4.1.3) which is the shared secret key resulting from a 990 successful EDHOC exchange. 992 Extract is used to derive fixed-length uniformly pseudorandom keys 993 (PRK) from ECDH shared secrets. Expand is used to define EDHOC-KDF 994 for generating MACs and for deriving output keying material (OKM) 995 from PRKs. 997 In EDHOC a specific message is protected with a certain pseudorandom 998 key, but how the key is derived depends on the method as detailed in 999 Section 5. 1001 4.1.1. Extract 1003 The pseudorandom keys (PRKs) used for EDHOC message processing are 1004 derived using Extract: 1006 PRK = Extract( salt, IKM ) 1008 where the input keying material (IKM) and salt are defined for each 1009 PRK below. 1011 The definition of Extract depends on the EDHOC hash algorithm of the 1012 selected cipher suite: 1014 * if the EDHOC hash algorithm is SHA-2, then Extract( salt, IKM ) = 1015 HKDF-Extract( salt, IKM ) [RFC5869] 1017 * if the EDHOC hash algorithm is SHAKE128, then Extract( salt, IKM ) 1018 = KMAC128( salt, IKM, 256, "" ) 1020 * if the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM ) 1021 = KMAC256( salt, IKM, 512, "" ) 1023 The rest of the section defines the pseudo-random keys PRK_2e, 1024 PRK_3e2m and PRK_4e3m; their use is shown in Figure 7. 1026 4.1.1.1. PRK_2e 1028 The pseudo-random key PRK_2e is derived with the following input: 1030 * The salt SHALL be a zero-length byte string. Note that [RFC5869] 1031 specifies that if the salt is not provided, it is set to a string 1032 of zeros (see Section 2.2 of [RFC5869]). For implementation 1033 purposes, not providing the salt is the same as setting the salt 1034 to the zero-length byte string (0x). 1036 * The IKM SHALL be the ephemeral-ephemeral ECDH shared secret G_XY 1037 (calculated from G_X and Y or G_Y and X) as defined in 1038 Section 6.3.1 of [I-D.ietf-cose-rfc8152bis-algs]. The use of G_XY 1039 gives forward secrecy, in the sense that compromise of the private 1040 authentication keys does not compromise past session keys. 1042 Example: Assuming the use of curve25519, the ECDH shared secret G_XY 1043 is the output of the X25519 function [RFC7748]: 1045 G_XY = X25519( Y, G_X ) = X25519( X, G_Y ) 1047 Example: Assuming the use of SHA-256 the extract phase of HKDF 1048 produces PRK_2e as follows: 1050 PRK_2e = HMAC-SHA-256( salt, G_XY ) 1052 where salt = 0x (zero-length byte string). 1054 4.1.1.2. PRK_3e2m 1056 The pseudo-random key PRK_3e2m is derived as follows: 1058 If the Responder authenticates with a static Diffie-Hellman key, then 1059 PRK_3e2m = Extract( SALT_3e2m, G_RX ), where 1061 * SALT_3e2m is derived from PRK_2e, see Section 4.1.2, and 1063 * G_RX is the ECDH shared secret calculated from G_R and X, or G_X 1064 and R (the Responder's private authentication key, see 1065 Section 3.5.1), 1067 else PRK_3e2m = PRK_2e. 1069 4.1.1.3. PRK_4e3m 1071 The pseudo-random key PRK_4e3m is derived as follows: 1073 If the Initiator authenticates with a static Diffie-Hellman key, then 1074 PRK_4e3m = Extract( SALT_4e3m, G_IY ), where 1076 * SALT_4e3m is derived from PRK_3e2m, see Section 4.1.2, and 1078 * G_IY is the ECDH shared secret calculated from G_I and Y, or G_Y 1079 and I (the Initiator's private authentication key, see 1080 Section 3.5.1), 1082 else PRK_4e3m = PRK_3e2m. 1084 4.1.2. Expand and EDHOC-KDF 1086 The output keying material (OKM) - including keys, IVs, and salts - 1087 are derived from the PRKs using the EDHOC-KDF, which is defined 1088 through Expand: 1090 OKM = EDHOC-KDF( PRK, label, context, length ) 1091 = Expand( PRK, info, length ) 1093 where info is encoded as the CBOR sequence 1095 info = ( 1096 label : uint, 1097 context : bstr, 1098 length : uint, 1099 ) 1101 where 1103 * label is a uint 1105 * context is a bstr 1107 * length is the length of OKM in bytes 1109 When EDHOC-KDF is used to derive OKM for EDHOC message processing, 1110 then context includes one of the transcript hashes TH_2, TH_3, or 1111 TH_4 defined in Sections 5.3.2 and 5.4.2. 1113 The definition of Expand depends on the EDHOC hash algorithm of the 1114 selected cipher suite: 1116 * if the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, 1117 length ) = HKDF-Expand( PRK, info, length ) [RFC5869] 1119 * if the EDHOC hash algorithm is SHAKE128, then Expand( PRK, info, 1120 length ) = KMAC128( PRK, info, L, "" ) 1122 * if the EDHOC hash algorithm is SHAKE256, then Expand( PRK, info, 1123 length ) = KMAC256( PRK, info, L, "" ) 1125 where L = 8*length, the output length in bits. 1127 Figure 7 lists derivations made with EDHOC-KDF during message 1128 processing. How the output keying material is used is specified in 1129 Section 5. 1131 KEYSTREAM_2 = EDHOC-KDF( PRK_2e, 0, TH_2, plaintext_length ) 1132 SALT_3e2m = EDHOC-KDF( PRK_2e, 1, TH_2, hash_length ) 1133 MAC_2 = EDHOC-KDF( PRK_3e2m, 2, context_2, mac_length_2 ) 1134 K_3 = EDHOC-KDF( PRK_3e2m, 3, TH_3, key_length ) 1135 IV_3 = EDHOC-KDF( PRK_3e2m, 4, TH_3, iv_length ) 1136 SALT_4e3m = EDHOC-KDF( PRK_3e2m, 5, TH_3, hash_length ) 1137 MAC_3 = EDHOC-KDF( PRK_4e3m, 6, context_3, mac_length_3 ) 1138 PRK_out = EDHOC-KDF( PRK_4e3m, 7, TH_4, hash_length ) 1139 K_4 = EDHOC-KDF( PRK_4e3m, 8, TH_4, key_length ) 1140 IV_4 = EDHOC-KDF( PRK_4e3m, 9, TH_4, iv_length ) 1142 Figure 7: Key derivations using EDHOC-KDF. 1144 4.1.3. PRK_out 1146 The pseudo-random key PRK_out, derived as shown in Figure 7, is the 1147 only secret key shared between Initiator and Responder that needs to 1148 be stored after a successful EDHOC exchange, see Section 5.4. Keys 1149 for applications are derived from PRK_out, see Section 4.2.1. 1151 4.2. Keys for EDHOC Applications 1153 This section defines EDHOC-Exporter and EDHOC-KeyUpdate in terms of 1154 EDHOC-KDF and PRK_out. 1156 4.2.1. EDHOC-Exporter 1158 Keying material for the application can be derived using the EDHOC- 1159 Exporter interface defined as: 1161 EDHOC-Exporter(label, context, length) 1162 = EDHOC-KDF(PRK_exporter, label, context, length) 1164 where 1166 * label is a registered uint from the EDHOC Exporter Label registry 1167 (Section 9.1) 1169 * context is a bstr defined by the application 1171 * length is a uint defined by the application 1173 * PRK_exporter is derived from PRK_out: 1175 PRK_exporter = EDHOC-KDF( PRK_out, 10, h'', hash_length ) 1177 where hash_length denotes the length of the hash function output in 1178 bytes, as specified by the COSE hash algorithm definition. 1180 PRK_exporter MUST be derived anew if PRK_out is updated, in 1181 particular if EDHOC-KeyUpdate is used, see Section 4.2.2. 1183 The (label, context) pair must be unique, i.e., a (label, context) 1184 MUST NOT be used for two different purposes. However an application 1185 can re-derive the same key several times as long as it is done in a 1186 secure way. For example, in most encryption algorithms the same key 1187 can be reused with different nonces. The context can for example be 1188 the empty CBOR byte string. 1190 Examples of use of the EDHOC-Exporter are given in Appendix A. 1192 4.2.2. EDHOC-KeyUpdate 1194 To provide forward secrecy in an even more efficient way than re- 1195 running EDHOC, EDHOC provides the function EDHOC-KeyUpdate. When 1196 EDHOC-KeyUpdate is called, the old PRK_out is deleted and the new 1197 PRK_out is calculated as a "hash" of the old key using the Expand 1198 function as illustrated by the following pseudocode: 1200 EDHOC-KeyUpdate( context ): 1201 PRK_out = EDHOC-KDF( PRK_out, 11, context, hash_length ) 1203 where hash_length denotes the length of the hash function output in 1204 bytes, as specified by the COSE hash algorithm definition. 1206 The EDHOC-KeyUpdate takes a context as input to enable binding of the 1207 updated PRK_out to some event that triggered the keyUpdate. The 1208 Initiator and the Responder need to agree on the context, which can, 1209 e.g., be a counter or a pseudo-random number such as a hash. The 1210 Initiator and the Responder also need to cache the old PRK_out until 1211 it has verfied that the other endpoint has the correct new PRK_out. 1212 [I-D.ietf-core-oscore-key-update] describes key update for OSCORE 1213 using EDHOC-KeyUpdate. 1215 While this key update method provides forward secrecy it does not 1216 give as strong security properties as re-running EDHOC, see 1217 Section 8. 1219 5. Message Formatting and Processing 1221 This section specifies formatting of the messages and processing 1222 steps. Error messages are specified in Section 6. Annotated traces 1223 of EDHOC protocol runs are provided in [I-D.ietf-lake-traces]. 1225 An EDHOC message is encoded as a sequence of CBOR data items (CBOR 1226 Sequence, [RFC8742]). Additional optimizations are made to reduce 1227 message overhead. 1229 While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 1230 structures, only a subset of the parameters is included in the EDHOC 1231 messages, see Appendix C.3. The unprotected COSE header in 1232 COSE_Sign1, and COSE_Encrypt0 (not included in the EDHOC message) MAY 1233 contain parameters (e.g., 'alg'). 1235 5.1. Message Processing Outline 1237 This section outlines the message processing of EDHOC. 1239 For each new/ongoing session, the endpoints are assumed to keep an 1240 associated protocol state containing identifiers, keying material, 1241 etc. used for subsequent processing of protocol related data. The 1242 protocol state is assumed to be associated to an application profile 1243 (Section 3.9) which provides the context for how messages are 1244 transported, identified, and processed. 1246 EDHOC messages SHALL be processed according to the current protocol 1247 state. The following steps are expected to be performed at reception 1248 of an EDHOC message: 1250 1. Detect that an EDHOC message has been received, for example by 1251 means of port number, URI, or media type (Section 3.9). 1253 2. Retrieve the protocol state according to the message correlation 1254 provided by the transport, see Section 3.4. If there is no 1255 protocol state, in the case of message_1, a new protocol state is 1256 created. The Responder endpoint needs to make use of available 1257 Denial-of-Service mitigation (Section 8.7). 1259 3. If the message received is an error message, then process it 1260 according to Section 6, else process it as the expected next 1261 message according to the protocol state. 1263 If the processing fails for some reason then, typically, an error 1264 message is sent, the protocol is discontinued, and the protocol state 1265 erased. Further details are provided in the following subsections 1266 and in Section 6. 1268 Different instances of the same message MUST NOT be processed in one 1269 session. Note that processing will fail if the same message appears 1270 a second time for EDHOC processing in the same session because the 1271 state of the protocol has moved on and now expects something else. 1272 This assumes that message duplication due to re-transmissions is 1273 handled by the transport protocol, see Section 3.4. The case when 1274 the transport does not support message deduplication is addressed in 1275 Appendix G. 1277 5.2. EDHOC Message 1 1279 5.2.1. Formatting of Message 1 1281 message_1 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1282 below 1284 message_1 = ( 1285 METHOD : int, 1286 SUITES_I : suites, 1287 G_X : bstr, 1288 C_I : bstr / -24..23, 1289 ? EAD_1 : ead, 1290 ) 1292 suites = [ 2* int ] / int 1294 where: 1296 * METHOD - authentication method, see Section 3.2. 1298 * SUITES_I - array of cipher suites which the Initiator supports in 1299 order of preference, the first cipher suite in network byte order 1300 is the most preferred by I, the last is the one selected by I for 1301 this session. If the most preferred cipher suite is selected then 1302 SUITES_I contains only that cipher suite and is encoded as an int. 1303 The processing steps are detailed below and in Section 6.3. 1305 * G_X - the ephemeral public key of the Initiator 1307 * C_I - variable length connection identifier. Note that connection 1308 identifiers are byte strings but certain values are represented as 1309 integers in the message, see Section 3.3.2. 1311 * EAD_1 - external authorization data, see Section 3.8. 1313 5.2.2. Initiator Processing of Message 1 1315 The Initiator SHALL compose message_1 as follows: 1317 * Construct SUITES_I complying with the definition in 1318 Section 5.2.1}, and furthermore: 1320 - The Initiator MUST select its most preferred cipher suite, 1321 conditioned on what it can assume to be supported by the 1322 Responder. 1324 - The selected cipher suite (i.e. the last cipher suite in 1325 SUITES_I) MAY be different between sessions, e.g., based on 1326 previous error messages (see next bullet), but all cipher 1327 suites which are more preferred by I than the selected cipher 1328 suite MUST be included in SUITES_I. 1330 - If the Initiator previously received from the Responder an 1331 error message with error code 2 containing SUITES_R (see 1332 Section 6.3) which indicates cipher suites supported by the 1333 Responder, then the Initiator SHOULD select its most preferred 1334 supported cipher suite among those (bearing in mind that error 1335 messages are not authenticated and may be forged). 1337 - The Initiator MUST NOT change the supported cipher suites and 1338 the order of preference in SUITES_I based on previous error 1339 messages. 1341 * Generate an ephemeral ECDH key pair using the curve in the 1342 selected cipher suite and format it as a COSE_Key. Let G_X be the 1343 'x' parameter of the COSE_Key. 1345 * Choose a connection identifier C_I and store it for the length of 1346 the protocol. 1348 * Encode message_1 as a sequence of CBOR encoded data items as 1349 specified in Section 5.2.1 1351 5.2.3. Responder Processing of Message 1 1353 The Responder SHALL process message_1 as follows: 1355 * Decode message_1 (see Appendix C.1). 1357 * Verify that the selected cipher suite is supported and that no 1358 prior cipher suite in SUITES_I is supported. 1360 * If EAD_1 is present then make it available to the application for 1361 EAD processing. 1363 If any processing step fails, the Responder MUST send an EDHOC error 1364 message back, formatted as defined in Section 6, and the session MUST 1365 be discontinued. 1367 5.3. EDHOC Message 2 1369 5.3.1. Formatting of Message 2 1371 message_2 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1372 below 1374 message_2 = ( 1375 G_Y_CIPHERTEXT_2 : bstr, 1376 C_R : bstr / -24..23, 1377 ) 1379 where: 1381 * G_Y_CIPHERTEXT_2 - the concatenation of G_Y (i.e., the ephemeral 1382 public key of the Responder) and CIPHERTEXT_2. 1384 * C_R - variable length connection identifier. Note that connection 1385 identifiers are byte strings but certain values are represented as 1386 integers in the message, see Section 3.3.2. 1388 5.3.2. Responder Processing of Message 2 1390 The Responder SHALL compose message_2 as follows: 1392 * Generate an ephemeral ECDH key pair using the curve in the 1393 selected cipher suite and format it as a COSE_Key. Let G_Y be the 1394 'x' parameter of the COSE_Key. 1396 * Choose a connection identifier C_R and store it for the length of 1397 the protocol. 1399 * Compute the transcript hash TH_2 = H( G_Y, C_R, H(message_1) ) 1400 where H() is the EDHOC hash algorithm of the selected cipher 1401 suite. The transcript hash TH_2 is a CBOR encoded bstr and the 1402 input to the hash function is a CBOR Sequence. Note that 1403 H(message_1) can be computed and cached already in the processing 1404 of message_1. 1406 * Compute MAC_2 as in Section 4.1.2 with context_2 = << ID_CRED_R, 1407 TH_2, CRED_R, ? EAD_2 >> 1409 - If the Responder authenticates with a static Diffie-Hellman key 1410 (method equals 1 or 3), then mac_length_2 is the EDHOC MAC 1411 length given by the selected cipher suite. If the Responder 1412 authenticates with a signature key (method equals 0 or 2), then 1413 mac_length_2 is equal to the output size of the EDHOC hash 1414 algorithm given by the selected cipher suite. 1416 - ID_CRED_R - identifier to facilitate the retrieval of CRED_R, 1417 see Section 3.5.3 1419 - CRED_R - CBOR item containing the authentication credential of 1420 the Responder, see Section 3.5.2 1422 - EAD_2 - external authorization data, see Section 3.8 1424 * If the Responder authenticates with a static Diffie-Hellman key 1425 (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the 1426 Responder authenticates with a signature key (method equals 0 or 1427 2), then Signature_or_MAC_2 is the 'signature' field of a 1428 COSE_Sign1 object, computed as specified in Section 4.4 of 1429 [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm of 1430 the selected cipher suite, the private authentication key of the 1431 Responder, and the following parameters as input (see Appendix C.3 1432 for an overview of COSE and Appendix C.1 for notation): 1434 - protected = << ID_CRED_R >> 1436 - external_aad = << TH_2, CRED_R, ? EAD_2 >> 1438 - payload = MAC_2 1440 * CIPHERTEXT_2 is calculated by using the Expand function as a 1441 binary additive stream cipher over the following plaintext: 1443 - PLAINTEXT_2 = ( ? PAD, ID_CRED_R / bstr / -24..23, 1444 Signature_or_MAC_2, ? EAD_2 ) 1446 o If ID_CRED_R contains a single 'kid' parameter, i.e., 1447 ID_CRED_R = { 4 : kid_R }, then only the byte string kid_R 1448 is conveyed in the plaintext, represented as described in 1449 Section 3.3.2. 1451 o PAD = 1*true is padding that may be used to hide the length 1452 of the unpadded plaintext 1454 - Compute KEYSTREAM_2 as in Section 4.1.2, where plaintext_length 1455 is the length of PLAINTEXT_2. 1457 - CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 1459 * Encode message_2 as a sequence of CBOR encoded data items as 1460 specified in Section 5.3.1. 1462 5.3.3. Initiator Processing of Message 2 1464 The Initiator SHALL process message_2 as follows: 1466 * Decode message_2 (see Appendix C.1). 1468 * Retrieve the protocol state using the message correlation provided 1469 by the transport (e.g., the CoAP Token, the 5-tuple, or the 1470 prepended C_I, see Appendix A.2). 1472 * Decrypt CIPHERTEXT_2, see Section 5.3.2, and discard padding, if 1473 present. 1475 * Make ID_CRED_R and EAD_2 (if present) available to the application 1476 for authentication- and EAD processing. 1478 * Obtain the authentication credential (CRED_R) and the 1479 authentication key of R from the application (or by other means). 1481 * Verify Signature_or_MAC_2 using the algorithm in the selected 1482 cipher suite. The verification process depends on the method, see 1483 Section 5.3.2. 1485 If any processing step fails, the Responder MUST send an EDHOC error 1486 message back, formatted as defined in Section 6, and the session MUST 1487 be discontinued. 1489 5.4. EDHOC Message 3 1490 5.4.1. Formatting of Message 3 1492 message_3 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1493 below 1495 message_3 = ( 1496 CIPHERTEXT_3 : bstr, 1497 ) 1499 5.4.2. Initiator Processing of Message 3 1501 The Initiator SHALL compose message_3 as follows: 1503 * Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2) where H() 1504 is the EDHOC hash algorithm of the selected cipher suite. The 1505 transcript hash TH_3 is a CBOR encoded bstr and the input to the 1506 hash function is a CBOR Sequence. Note that H(TH_2, PLAINTEXT_2) 1507 can be computed and cached already in the processing of message_2. 1509 * Compute MAC_3 as in Section 4.1.2, with context_3 = << ID_CRED_I, 1510 TH_3, CRED_I, ? EAD_3 >> 1512 - If the Initiator authenticates with a static Diffie-Hellman key 1513 (method equals 2 or 3), then mac_length_3 is the EDHOC MAC 1514 length given by the selected cipher suite. If the Initiator 1515 authenticates with a signature key (method equals 0 or 1), then 1516 mac_length_3 is equal to the output size of the EDHOC hash 1517 algorithm given by the selected cipher suite. 1519 - ID_CRED_I - identifier to facilitate the retrieval of CRED_I, 1520 see Section 3.5.3 1522 - CRED_I - CBOR item containing the authentication credential of 1523 the Initiator, see Section 3.5.2 1525 - EAD_3 - external authorization data, see Section 3.8 1527 * If the Initiator authenticates with a static Diffie-Hellman key 1528 (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3. If the 1529 Initiator authenticates with a signature key (method equals 0 or 1530 1), then Signature_or_MAC_3 is the 'signature' field of a 1531 COSE_Sign1 object, computed as specified in Section 4.4 of 1532 [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm of 1533 the selected cipher suite, the private authentication key of the 1534 Initiator, and the following parameters as input (see 1535 Appendix C.3): 1537 - protected = << ID_CRED_I >> 1538 - external_aad = << TH_3, CRED_I, ? EAD_3 >> 1540 - payload = MAC_3 1542 * Compute a COSE_Encrypt0 object as defined in Sections 5.2 and 5.3 1543 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD 1544 algorithm of the selected cipher suite, using the encryption key 1545 K_3, the initialization vector IV_3 (if used by the AEAD 1546 algorithm), the plaintext PLAINTEXT_3, and the following 1547 parameters as input (see Appendix C.3): 1549 - protected = h'' 1551 - external_aad = TH_3 1553 - K_3 and IV_3 are defined in Section 4.1.2, with 1555 o key_length - length of the encryption key of the EDHOC AEAD 1556 algorithm 1558 o iv_length - length of the initialization vector of the EDHOC 1559 AEAD algorithm 1561 - PLAINTEXT_3 = ( ? PAD, ID_CRED_I / bstr / -24..23, 1562 Signature_or_MAC_3, ? EAD_3 ) 1564 o If ID_CRED_I contains a single 'kid' parameter, i.e., 1565 ID_CRED_I = { 4 : kid_I }, then only the byte string kid_I 1566 is conveyed in the plaintext, represented as described in 1567 Section 3.3.2. 1569 o PAD = 1*true is padding that may be used to hide the length 1570 of the unpadded plaintext 1572 CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. 1574 * Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3) where H() 1575 is the EDHOC hash algorithm of the selected cipher suite. The 1576 transcript hash TH_4 is a CBOR encoded bstr and the input to the 1577 hash function is a CBOR Sequence. 1579 * Calculate PRK_out as defined in Figure 7. The Initiator can now 1580 derive application keys using the EDHOC-Exporter interface, see 1581 Section 4.2.1. 1583 * Encode message_3 as a CBOR data item as specified in 1584 Section 5.4.1. 1586 * Make the connection identifiers (C_I, C_R) and the application 1587 algorithms in the selected cipher suite available to the 1588 application. 1590 The Initiator SHOULD NOT persistently store PRK_out or application 1591 keys until the Initiator has verified message_4 or a message 1592 protected with a derived application key, such as an OSCORE message, 1593 from the Responder. This is similar to waiting for acknowledgement 1594 (ACK) in a transport protocol. 1596 5.4.3. Responder Processing of Message 3 1598 The Responder SHALL process message_3 as follows: 1600 * Decode message_3 (see Appendix C.1). 1602 * Retrieve the protocol state using the message correlation provided 1603 by the transport (e.g., the CoAP Token, the 5-tuple, or the 1604 prepended C_R, see Appendix A.2). 1606 * Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 1607 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD 1608 algorithm in the selected cipher suite, and the parameters defined 1609 in Section 5.4.2. Discard padding, if present. 1611 * Make ID_CRED_I and EAD_3 (if present) available to the application 1612 for authentication- and EAD processing. 1614 * Obtain the authentication credential (CRED_I) and the 1615 authentication key of I from the application (or by other means). 1617 * Verify Signature_or_MAC_3 using the algorithm in the selected 1618 cipher suite. The verification process depends on the method, see 1619 Section 5.4.2. 1621 * Make the connection identifiers (C_I, C_R) and the application 1622 algorithms in the selected cipher suite available to the 1623 application. 1625 After verifying message_3, the Responder can compute PRK_out, see 1626 Section 4.1.3, derive application keys using the EDHOC-Exporter 1627 interface, see Section 4.2.1, persistently store the keying material, 1628 and send protected application data. 1630 If any processing step fails, the Responder MUST send an EDHOC error 1631 message back, formatted as defined in Section 6, and the session MUST 1632 be discontinued. 1634 5.5. EDHOC Message 4 1636 This section specifies message_4 which is OPTIONAL to support. Key 1637 confirmation is normally provided by sending an application message 1638 from the Responder to the Initiator protected with a key derived with 1639 the EDHOC-Exporter, e.g., using OSCORE (see Appendix A). In 1640 deployments where no protected application message is sent from the 1641 Responder to the Initiator, message_4 MUST be supported and MUST be 1642 used. Two examples of such deployments: 1644 1. When EDHOC is only used for authentication and no application 1645 data is sent. 1647 2. When application data is only sent from the Initiator to the 1648 Responder. 1650 Further considerations about when to use message_4 are provided in 1651 Section 3.9 and Section 8.1. 1653 5.5.1. Formatting of Message 4 1655 message_4 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1656 below 1658 message_4 = ( 1659 CIPHERTEXT_4 : bstr, 1660 ) 1662 5.5.2. Responder Processing of Message 4 1664 The Responder SHALL compose message_4 as follows: 1666 * Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of 1667 [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm 1668 of the selected cipher suite, using the encryption key K_4, the 1669 initialization vector IV_4 (if used by the AEAD algorithm), the 1670 plaintext PLAINTEXT_4, and the following parameters as input (see 1671 Appendix C.3): 1673 - protected = h'' 1675 - external_aad = TH_4 1677 - K_4 and IV_4 are defined in Section 4.1.2, with 1679 o key_length - length of the encryption key of the EDHOC AEAD 1680 algorithm 1682 o iv_length - length of the initialization vector of the EDHOC 1683 AEAD algorithm 1685 - PLAINTEXT_4 = ( ? PAD, ? EAD_4 ) 1687 o PAD = 1*true is padding that may be used to hide the length 1688 of the unpadded plaintext. 1690 o EAD_4 - external authorization data, see Section 3.8. 1692 CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0. 1694 * Encode message_4 as a CBOR data item as specified in 1695 Section 5.5.1. 1697 5.5.3. Initiator Processing of Message 4 1699 The Initiator SHALL process message_4 as follows: 1701 * Decode message_4 (see Appendix C.1). 1703 * Retrieve the protocol state using the message correlation provided 1704 by the transport (e.g., the CoAP Token, the 5-tuple, or the 1705 prepended C_I, see Appendix A.2). 1707 * Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 1708 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD 1709 algorithm in the selected cipher suite, and the parameters defined 1710 in Section 5.5.2. Discard padding, if present. 1712 * Make EAD_4 (if present) available to the application for EAD 1713 processing. 1715 If any processing step fails, the Responder MUST send an EDHOC error 1716 message back, formatted as defined in Section 6, and the session MUST 1717 be discontinued. 1719 After verifying message_4, the Initiator is assured that the 1720 Responder has calculated the key PRK_out (key confirmation) and that 1721 no other party can derive the key. 1723 6. Error Handling 1725 This section defines the format for error messages, and the 1726 processing associated to the currently defined error codes. 1727 Additional error codes may be registered, see Section 9.4. 1729 There are many kinds of errors that can occur during EDHOC 1730 processing. As in CoAP, an error can be triggered by errors in the 1731 received message or internal errors in the recieving endpoint. 1732 Except for processing and formatting errors, it is up to the 1733 implementation when to send an error message. Sending error messages 1734 is essential for debugging but MAY be skipped if, for example, a 1735 session cannot be found or due to denial-of-service reasons, see 1736 Section 8.7. Errors messages in EDHOC are always fatal. After 1737 sending an error message, the sender MUST discontinue the protocol. 1738 The receiver SHOULD treat an error message as an indication that the 1739 other party likely has discontinued the protocol. But as the error 1740 message is not authenticated, a received error message might also 1741 have been sent by an attacker and the receiver MAY therefore try to 1742 continue the protocol. 1744 An EDHOC error message can be sent by either endpoint as a reply to 1745 any non-error EDHOC message. How errors at the EDHOC layer are 1746 transported depends on lower layers, which need to enable error 1747 messages to be sent and processed as intended. 1749 error SHALL be a CBOR Sequence (see Appendix C.1) as defined below 1751 error = ( 1752 ERR_CODE : int, 1753 ERR_INFO : any, 1754 ) 1756 Figure 8: EDHOC error message. 1758 where: 1760 * ERR_CODE - error code encoded as an integer. The value 0 is used 1761 for success, all other values (negative or positive) indicate 1762 errors. 1764 * ERR_INFO - error information. Content and encoding depend on 1765 error code. 1767 The remainder of this section specifies the currently defined error 1768 codes, see Figure 9. Additional error codes and corresponding error 1769 information may be specified. 1771 +----------+---------------+----------------------------------------+ 1772 | ERR_CODE | ERR_INFO Type | Description | 1773 +==========+===============+========================================+ 1774 | 0 | any | Success | 1775 +----------+---------------+----------------------------------------+ 1776 | 1 | tstr | Unspecified error | 1777 +----------+---------------+----------------------------------------+ 1778 | 2 | suites | Wrong selected cipher suite | 1779 +----------+---------------+----------------------------------------+ 1781 Figure 9: Error codes and error information included in the EDHOC 1782 error message. 1784 6.1. Success 1786 Error code 0 MAY be used internally in an application to indicate 1787 success, i.e., as a standard value in case of no error, e.g., in 1788 status reporting or log files. ERR_INFO can contain any type of CBOR 1789 item, the content is out of scope for this specification. Error code 1790 0 MUST NOT be used as part of the EDHOC message exchange flow. If an 1791 endpoint receives an error message with error code 0, then it MUST 1792 discontinue the protocol and MUST NOT send an error message. 1794 6.2. Unspecified Error 1796 Error code 1 is used for errors that do not have a specific error 1797 code defined. ERR_INFO MUST be a text string containing a human- 1798 readable diagnostic message written in English, for example "Method 1799 not supported". The diagnostic text message is mainly intended for 1800 software engineers that during debugging need to interpret it in the 1801 context of the EDHOC specification. The diagnostic message SHOULD be 1802 provided to the calling application where it SHOULD be logged. 1804 6.3. Wrong Selected Cipher Suite 1806 Error code 2 MUST only be used when replying to message_1 in case the 1807 cipher suite selected by the Initiator is not supported by the 1808 Responder, or if the Responder supports a cipher suite more preferred 1809 by the Initiator than the selected cipher suite, see Section 5.2.3. 1810 ERR_INFO is in this case denoted SUITES_R and is of type suites, see 1811 Section 5.2.1. If the Responder does not support the selected cipher 1812 suite, then SUITES_R MUST include one or more supported cipher 1813 suites. If the Responder supports a cipher suite in SUITES_I other 1814 than the selected cipher suite (independently of if the selected 1815 cipher suite is supported or not) then SUITES_R MUST include the 1816 supported cipher suite in SUITES_I which is most preferred by the 1817 Initiator. SUITES_R MAY include a single cipher suite, i.e., be 1818 encoded as an int. If the Responder does not support any cipher 1819 suite in SUITES_I, then it SHOULD include all its supported cipher 1820 suites in SUITES_R. 1822 In contrast to SUITES_I, the order of the cipher suites in SUITES_R 1823 has no significance. 1825 6.3.1. Cipher Suite Negotiation 1827 After receiving SUITES_R, the Initiator can determine which cipher 1828 suite to select (if any) for the next EDHOC run with the Responder. 1830 If the Initiator intends to contact the Responder in the future, the 1831 Initiator SHOULD remember which selected cipher suite to use until 1832 the next message_1 has been sent, otherwise the Initiator and 1833 Responder will likely run into an infinite loop where the Initiator 1834 selects its most preferred and the Responder sends an error with 1835 supported cipher suites. After a successful run of EDHOC, the 1836 Initiator MAY remember the selected cipher suite to use in future 1837 EDHOC sessions. Note that if the Initiator or Responder is updated 1838 with new cipher suite policies, any cached information may be 1839 outdated. 1841 Note that the Initiator's list of supported cipher suites and order 1842 of preference is fixed (see Section 5.2.1 and Section 5.2.2). 1843 Furthermore, the Responder SHALL only accept message_1 if the 1844 selected cipher suite is the first cipher suite in SUITES_I that the 1845 Responder supports (see Section 5.2.3). Following this procedure 1846 ensures that the selected cipher suite is the most preferred (by the 1847 Initiator) cipher suite supported by both parties. 1849 If the selected cipher suite is not the first cipher suite which the 1850 Responder supports in SUITES_I received in message_1, then the 1851 Responder MUST discontinue the protocol, see Section 5.2.3. If 1852 SUITES_I in message_1 is manipulated, then the integrity verification 1853 of message_2 containing the transcript hash TH_2 will fail and the 1854 Initiator will discontinue the protocol. 1856 6.3.2. Examples 1858 Assume that the Initiator supports the five cipher suites 5, 6, 7, 8, 1859 and 9 in decreasing order of preference. Figures 10 and 11 show 1860 examples of how the Initiator can format SUITES_I and how SUITES_R is 1861 used by Responders to give the Initiator information about the cipher 1862 suites that the Responder supports. 1864 In the first example (Figure 10), the Responder supports cipher suite 1865 6 but not the initially selected cipher suite 5. 1867 Initiator Responder 1868 | METHOD, SUITES_I = 5, G_X, C_I, EAD_1 | 1869 +------------------------------------------------------------------>| 1870 | message_1 | 1871 | | 1872 | ERR_CODE = 2, SUITES_R = 6 | 1873 |<------------------------------------------------------------------+ 1874 | error | 1875 | | 1876 | METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1 | 1877 +------------------------------------------------------------------>| 1878 | message_1 | 1880 Figure 10: Example of an Initiator supporting suites 5, 6, 7, 8, 1881 and 9 in decreasing order of preference, and a Responder 1882 supporting suite 6 but not suite 5. The Responder rejects the 1883 first message_1 with an error indicating support for suite 6. 1884 The Initiator also supports suite 6, and therefore selects suite 1885 6 in the second message_1. The initiator prepends in SUITES_I 1886 the selected suite 6 with the more preferred suites, in this case 1887 suite 5, to mitigate a potential attack on the cipher suite 1888 negotiation. 1890 In the second example (Figure 11), the Responder supports cipher 1891 suites 8 and 9 but not the more preferred (by the Initiator) cipher 1892 suites 5, 6 or 7. To illustrate the negotiation mechanics we let the 1893 Initiator first make a guess that the Responder supports suite 6 but 1894 not suite 5. Since the Responder supports neither 5 nor 6, it 1895 responds with SUITES_R containing the supported suites, after which 1896 the Initiator selects its most preferred supported suite. (If the 1897 Responder had supported suite 5, it would have included it in 1898 SUITES_R of the response, and it would in that case have become the 1899 selected suite in the second message_1.) 1901 Initiator Responder 1902 | METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1 | 1903 +------------------------------------------------------------------>| 1904 | message_1 | 1905 | | 1906 | ERR_CODE = 2, SUITES_R = [9, 8] | 1907 |<------------------------------------------------------------------+ 1908 | error | 1909 | | 1910 | METHOD, SUITES_I = [5, 6, 7, 8], G_X, C_I, EAD_1 | 1911 +------------------------------------------------------------------>| 1912 | message_1 | 1913 Figure 11: Example of an Initiator supporting suites 5, 6, 7, 8, 1914 and 9 in decreasing order of preference, and a Responder 1915 supporting suites 8 and 9 but not 5, 6 or 7. The Responder 1916 rejects the first message_1 with an error indicating support for 1917 suites 8 and 9 (in any order). The Initiator also supports 1918 suites 8 and 9, and prefers suite 8, so therefore selects suite 8 1919 in the second message_1. The initiator prepends in SUITES_I the 1920 selected suite 8 with the more preferred suites in order of 1921 preference, in this case suites 5, 6 and 7, to mitigate a 1922 potential attack on the cipher suite negotiation. 1924 7. Compliance Requirements 1926 In the absence of an application profile specifying otherwise: 1928 An implementation MAY support only Initiator or only Responder. 1930 An implementation MAY support only a single method. None of the 1931 methods are mandatory-to-implement. 1933 Implementations MUST support 'kid' parameters. None of the other 1934 COSE header parameters are mandatory-to-implement. 1936 An implementation MAY support only a single credential type (CCS, 1937 CWT, X.509, C509). None of the credential types are mandatory-to- 1938 implement. 1940 Implementations MUST support the EDHOC-Exporter. Implementations 1941 SHOULD support EDHOC-KeyUpdate. 1943 Implementations MAY support message_4. Error codes (ERR_CODE) 1 and 1944 2 MUST be supported. 1946 Implementations MAY support EAD. 1948 Implementations MAY support padding of plaintext when sending 1949 messages. Implementations MUST support padding of plaintext when 1950 receiving messages, i.e. MUST be able to parse padded messages. 1952 Implementations MUST support cipher suite 2 and 3. Cipher suites 2 1953 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA- 1954 256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM- 1955 16-64-128, SHA-256) only differ in size of the MAC length, so 1956 supporting one or both of these is no essential difference. 1957 Implementations only need to implement the algorithms needed for 1958 their supported methods. 1960 8. Security Considerations 1962 8.1. Security Properties 1964 EDHOC inherits its security properties from the theoretical SIGMA-I 1965 protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides 1966 forward secrecy, mutual authentication with aliveness, consistency, 1967 and peer awareness. As described in [SIGMA], peer awareness is 1968 provided to the Responder, but not to the Initiator. 1970 As described in [SIGMA], different levels of identity protection are 1971 provided to the Initiator and the Responder. EDHOC protects the 1972 credential identifier of the Initiator against active attacks and the 1973 credential identifier of the Responder against passive attacks. An 1974 active attacker can get the credential identifier of the Responder by 1975 eavesdropping on the destination address used for transporting 1976 message_1 and send its own message_1 to the same address. The roles 1977 should be assigned to protect the most sensitive identity/identifier, 1978 typically that which is not possible to infer from routing 1979 information in the lower layers. 1981 Compared to [SIGMA], EDHOC adds an explicit method type and expands 1982 the message authentication coverage to additional elements such as 1983 algorithms, external authorization data, and previous messages. This 1984 protects against an attacker replaying messages or injecting messages 1985 from another session. 1987 EDHOC also adds selection of connection identifiers and downgrade 1988 protected negotiation of cryptographic parameters, i.e., an attacker 1989 cannot affect the negotiated parameters. A single session of EDHOC 1990 does not include negotiation of cipher suites, but it enables the 1991 Responder to verify that the selected cipher suite is the most 1992 preferred cipher suite by the Initiator which is supported by both 1993 the Initiator and the Responder. 1995 As required by [RFC7258], IETF protocols need to mitigate pervasive 1996 monitoring when possible. EDHOC therefore only supports methods with 1997 ephemeral Diffie-Hellman and provides a KeyUpdate function for 1998 lightweight application protocol rekeying with forward secrecy, in 1999 the sense that compromise of the private authentication keys does not 2000 compromise past session keys, and compromise of a session key does 2001 not compromise past session keys. 2003 While the KeyUpdate method can be used to meet cryptographic limits 2004 and provide partial protection against key leakage, it provides 2005 significantly weaker security properties than re-running EDHOC with 2006 ephemeral Diffie-Hellman. Even with frequent use of KeyUpdate, 2007 compromise of one session key compromises all future session keys, 2008 and an attacker therefore only needs to perform static key 2009 exfiltration [RFC7624]. Frequently re-running EDHOC with ephemeral 2010 Diffie-Hellman forces attackers to perform dynamic key exfiltration 2011 instead of static key exfiltration [RFC7624]. In the dynamic case, 2012 the attacker must have continuous interactions with the collaborator, 2013 which is more complicated and has a higher risk profile than the 2014 static case. 2016 To limit the effect of breaches, it is important to limit the use of 2017 symmetrical group keys for bootstrapping. EDHOC therefore strives to 2018 make the additional cost of using raw public keys and self-signed 2019 certificates as small as possible. Raw public keys and self-signed 2020 certificates are not a replacement for a public key infrastructure 2021 but SHOULD be used instead of symmetrical group keys for 2022 bootstrapping. 2024 Compromise of the long-term keys (private signature or static DH 2025 keys) does not compromise the security of completed EDHOC exchanges. 2026 Compromising the private authentication keys of one party lets an 2027 active attacker impersonate that compromised party in EDHOC exchanges 2028 with other parties but does not let the attacker impersonate other 2029 parties in EDHOC exchanges with the compromised party. Compromise of 2030 the long-term keys does not enable a passive attacker to compromise 2031 future session keys. Compromise of the HDKF input parameters (ECDH 2032 shared secret) leads to compromise of all session keys derived from 2033 that compromised shared secret. Compromise of one session key does 2034 not compromise other session keys. Compromise of PRK_out leads to 2035 compromise of all keying material derived with the EDHOC-Exporter 2036 since the last invocation (if any) of the EDHOC-KeyUpdate function. 2038 Based on the cryptographic algorithms requirements Section 8.3, EDHOC 2039 provides a minimum of 64-bit security against online brute force 2040 attacks and a minimum of 128-bit security against offline brute force 2041 attacks. To break 64-bit security against online brute force an 2042 attacker would on average have to send 4.3 billion messages per 2043 second for 68 years, which is infeasible in constrained IoT radio 2044 technologies. A forgery against a 64-bit MAC in EDHOC breaks the 2045 security of all future application data, while a forgery against a 2046 64-bit MAC in the subsequent application protocol (e.g., OSCORE 2047 [RFC8613]) typically only breaks the security of the data in the 2048 forged packet. 2050 After sending message_3, the Initiator is assured that no other party 2051 than the Responder can compute the key PRK_out. While the Initiator 2052 can securely send protected application data, the Initiator SHOULD 2053 NOT persistently store the keying material PRK_out until the 2054 Initiator has verified an OSCORE message or message_4 from the 2055 Responder. After verifying message_3, the Responder is assured that 2056 an honest Initiator has computed the key PRK_out. The Responder can 2057 securely derive and store the keying material PRK_out, and send 2058 protected application data. 2060 External authorization data sent in message_1 (EAD_1) or message_2 2061 (EAD_2) should be considered unprotected by EDHOC, see Section 8.5. 2062 EAD_2 is encrypted but the Responder has not yet authenticated the 2063 Initiator. External authorization data sent in message_3 (EAD_3) or 2064 message_4 (EAD_4) is protected between Initiator and Responder by the 2065 protocol, but note that EAD fields may be used by the application 2066 before the message verification is completed, see Section 3.8. 2067 Designing a secure mechanism that uses EAD is not necessarily 2068 straightforward. This document only provides the EAD transport 2069 mechanism, but the problem of agreeing on the surrounding context and 2070 the meaning of the information passed to and from the application 2071 remains. Any new uses of EAD should be subject to careful review. 2073 Key compromise impersonation (KCI): In EDHOC authenticated with 2074 signature keys, EDHOC provides KCI protection against an attacker 2075 having access to the long-term key or the ephemeral secret key. With 2076 static Diffie-Hellman key authentication, KCI protection would be 2077 provided against an attacker having access to the long-term Diffie- 2078 Hellman key, but not to an attacker having access to the ephemeral 2079 secret key. Note that the term KCI has typically been used for 2080 compromise of long-term keys, and that an attacker with access to the 2081 ephemeral secret key can only attack that specific session. 2083 Repudiation: If an endpoint authenticates with a signature, the other 2084 endpoint can prove that the endpoint performed a run of the protocol 2085 by presenting the data being signed as well as the signature itself. 2086 With static Diffie-Hellman key authentication, the authenticating 2087 endpoint can deny having participated in the protocol. 2089 Two earlier versions of EDHOC have been formally analyzed [Norrman20] 2090 [Bruni18] and the specification has been updated based on the 2091 analysis. 2093 8.2. Cryptographic Considerations 2095 The SIGMA protocol requires that the encryption of message_3 provides 2096 confidentiality against active attackers and EDHOC message_4 relies 2097 on the use of authenticated encryption. Hence the message 2098 authenticating functionality of the authenticated encryption in EDHOC 2099 is critical: authenticated encryption MUST NOT be replaced by plain 2100 encryption only, even if authentication is provided at another level 2101 or through a different mechanism. 2103 To reduce message overhead EDHOC does not use explicit nonces and 2104 instead relies on the ephemeral public keys to provide randomness to 2105 each session. A good amount of randomness is important for the key 2106 generation, to provide liveness, and to protect against interleaving 2107 attacks. For this reason, the ephemeral keys MUST NOT be used in 2108 more than one EDHOC message, and both parties SHALL generate fresh 2109 random ephemeral key pairs. Note that an ephemeral key may be used 2110 to calculate several ECDH shared secrets. When static Diffie-Hellman 2111 authentication is used the same ephemeral key is used in both 2112 ephemeral-ephemeral and ephemeral-static ECDH. 2114 As discussed in [SIGMA], the encryption of message_2 does only need 2115 to protect against passive attacker as active attackers can always 2116 get the Responder's identity by sending their own message_1. EDHOC 2117 uses the Expand function (typically HKDF-Expand) as a binary additive 2118 stream cipher which is proven secure as long as the expand function 2119 is a PRF. HKDF-Expand is not often used as a stream cipher as it is 2120 slow on long messages, and most applications require both IND-CCA 2121 confidentiality as well as integrity protection. For the encryption 2122 of message_2, any speed difference is negligible, IND-CCA does not 2123 increase security, and integrity is provided by the inner MAC (and 2124 signature depending on method). 2126 Requirements for how to securely generate, validate, and process the 2127 ephemeral public keys depend on the elliptic curve. For X25519 and 2128 X448, the requirements are defined in [RFC7748]. For secp256r1, 2129 secp384r1, and secp521r1, the requirements are defined in Section 5 2130 of [SP-800-56A]. For secp256r1, secp384r1, and secp521r1, at least 2131 partial public-key validation MUST be done. 2133 As noted in Section 12 of [I-D.ietf-cose-rfc8152bis-struct] the use 2134 of a single key for multiple algorithms is strongly disencouraged 2135 unless proven secure by a dedicated cryptographic analysis. In 2136 particular this recommendation applies to using the same private key 2137 for static Diffie-Hellman authentication and digital signature 2138 authentication. A preliminary conjecture is that a minor change to 2139 EDHOC may be sufficient to fit the analysis of secure shared 2140 signature and ECDH key usage in [Degabriele11] and [Thormarker21]. 2142 So-called selfie attacks are mitigated as long as the Initiator does 2143 not have its own identity in the set of Responder identities it is 2144 allowed to communicate with. In trust on first use (TOFU) use cases 2145 the Initiator should verify that the the Responder's identity is not 2146 equal to its own. Any future EHDOC methods using e.g., pre-shared 2147 keys might need to mitigate this in other ways. 2149 8.3. Cipher Suites and Cryptographic Algorithms 2151 When using private cipher suite or registering new cipher suites, the 2152 choice of key length used in the different algorithms needs to be 2153 harmonized, so that a sufficient security level is maintained for 2154 certificates, EDHOC, and the protection of application data. The 2155 Initiator and the Responder should enforce a minimum security level. 2157 The output size of the EDHOC hash algorithm MUST be at least 2158 256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256 2159 truncated to 64-bits) SHALL NOT be supported for use in EDHOC except 2160 for certificate identification with x5t and c5t. For security 2161 considerations of SHA-1, see [RFC6194]. As EDHOC integrity protects 2162 the whole authentication credential, the choice of hash algorithm in 2163 x5t and c5t does not affect security and it is RECOMMENDED to use the 2164 same hash algorithm as in the cipher suite but with as much 2165 truncation as possible, i.e, when the EDHOC hash algorithm is SHA-256 2166 it is RECOMMENDED to use SHA-256/64 in x5t and c5t. The EDHOC MAC 2167 length MUST be at least 8 bytes and the tag length of the EDHOC AEAD 2168 algorithm MUST be at least 64-bits. Note that secp256k1 is only 2169 defined for use with ECDSA and not for ECDH. Note that some COSE 2170 algorithms are marked as not recommended in the COSE IANA registry. 2172 8.4. Post-Quantum Considerations 2174 As of the publication of this specification, it is unclear when or 2175 even if a quantum computer of sufficient size and power to exploit 2176 public key cryptography will exist. Deployments that need to 2177 consider risks decades into the future should transition to Post- 2178 Quantum Cryptography (PQC) in the not-too-distant future. Many other 2179 systems should take a slower wait-and-see approach where PQC is 2180 phased in when the quantum threat is more imminent. Current PQC 2181 algorithms have limitations compared to Elliptic Curve Cryptography 2182 (ECC) and the data sizes would be problematic in many constrained IoT 2183 systems. 2185 Symmetric algorithms used in EDHOC such as SHA-256 and AES-CCM- 2186 16-64-128 are practically secure against even large quantum 2187 computers. EDHOC supports all signature algorithms defined by COSE, 2188 including PQC signature algorithms such as HSS-LMS. EDHOC is 2189 currently only specified for use with key exchange algorithms of type 2190 ECDH curves, but any Key Encapsulation Method (KEM), including PQC 2191 KEMs, can be used in method 0. While the key exchange in method 0 is 2192 specified with terms of the Diffie-Hellman protocol, the key exchange 2193 adheres to a KEM interface: G_X is then the public key of the 2194 Initiator, G_Y is the encapsulation, and G_XY is the shared secret. 2195 Use of PQC KEMs to replace static DH authentication would likely 2196 require a specification updating EDHOC with new methods. 2198 8.5. Unprotected Data and Privacy 2200 The Initiator and the Responder must make sure that unprotected data 2201 and metadata do not reveal any sensitive information. This also 2202 applies for encrypted data sent to an unauthenticated party. In 2203 particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error 2204 messages. Using the same EAD_1 in several EDHOC sessions allows 2205 passive eavesdroppers to correlate the different sessions. Another 2206 consideration is that the list of supported cipher suites may 2207 potentially be used to identify the application. The Initiator and 2208 the Responder must also make sure that unauthenticated data does not 2209 trigger any harmful actions. In particular, this applies to EAD_1 2210 and error messages. 2212 An attacker observing network traffic may use connection identifiers 2213 sent in clear in EDHOC or the subsequent application protocol to 2214 correlate packets sent on different paths or at different times. The 2215 attacker may use this information for traffic flow analysis or to 2216 track an endpoint. Application protocols using connection 2217 identifiers from EDHOC SHOULD provide mechanisms to update the 2218 connection identifier and MAY provide mechanisms to issue several 2219 simultaneously active connection identifiers. See [RFC9000] for a 2220 non-constrained example of such mechanisms. 2222 8.6. Updated Internet Threat Model Considerations 2224 Since the publication of [RFC3552] there has been an increased 2225 awareness of the need to protect against endpoints that are 2226 compromised, malicious, or whose interests simply do not align with 2227 the interests of users 2228 [I-D.arkko-arch-internet-threat-model-guidance]. [RFC7624] describes 2229 an updated threat model for Internet confidentiality, see 2230 Section 8.1. [I-D.arkko-arch-internet-threat-model-guidance] further 2231 expands the threat model. Implementations and users SHOULD consider 2232 these threat models. In particular, even data sent protected to the 2233 other endpoint such as ID_CRED and EAD can be used for tracking, see 2234 Section 2.7 of [I-D.arkko-arch-internet-threat-model-guidance]. 2236 The fields ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 have 2237 variable length and information regarding the length may leak to an 2238 attacker. An passive attacker may e.g., be able to differentiating 2239 endpoints using identifiers of different length. To mitigate this 2240 information leakage an inmplementation may ensure that the fields 2241 have fixed length or use padding. An implementation may e.g., only 2242 use fix length identifiers like 'kid' of length 1. Alternatively 2243 padding may be used to hide the true length of e.g., certificates by 2244 value in 'x5chain' or 'c5c'. 2246 8.7. Denial-of-Service 2248 EDHOC itself does not provide countermeasures against Denial-of- 2249 Service attacks. In particular, by sending a number of new or 2250 replayed message_1 an attacker may cause the Responder to allocate 2251 state, perform cryptographic operations, and amplify messages. To 2252 mitigate such attacks, an implementation SHOULD rely on lower layer 2253 mechanisms. For instance, when EDHOC is transferred as an exchange 2254 of CoAP messages, the CoAP server can use the Echo option defined in 2255 [RFC9175] which forces the CoAP client to demonstrate reachability at 2256 its apparent network address. 2258 An attacker can also send faked message_2, message_3, message_4, or 2259 error in an attempt to trick the receiving party to send an error 2260 message and discontinue the session. EDHOC implementations MAY 2261 evaluate if a received message is likely to have been forged by an 2262 attacker and ignore it without sending an error message or 2263 discontinuing the session. 2265 8.8. Implementation Considerations 2267 The availability of a secure random number generator is essential for 2268 the security of EDHOC. If no true random number generator is 2269 available, a random seed must be provided from an external source and 2270 used with a cryptographically secure pseudorandom number generator. 2271 As each pseudorandom number must only be used once, an implementation 2272 needs to get a unique input to the pseudorandom number generator 2273 after reboot, or continuously store state in nonvolatile memory. 2274 Appendix B.1.1 in [RFC8613] describes issues and solution approaches 2275 for writing to nonvolatile memory. Intentionally or unintentionally 2276 weak or predictable pseudorandom number generators can be abused or 2277 exploited for malicious purposes. [RFC8937] describes a way for 2278 security protocol implementations to augment their (pseudo)random 2279 number generators using a long-term private key and a deterministic 2280 signature function. This improves randomness from broken or 2281 otherwise subverted random number generators. The same idea can be 2282 used with other secrets and functions such as a Diffie-Hellman 2283 function or a symmetric secret and a PRF like HMAC or KMAC. It is 2284 RECOMMENDED to not trust a single source of randomness and to not put 2285 unaugmented random numbers on the wire. 2287 Implementations might consider deriving secret and non-secret 2288 randomness from different PNRG/PRF/KDF instances to limit the damage 2289 if the PNRG/PRF/KDF turns out to be fundamentally broken. NIST 2290 generally forbids deriving secret and non-secret randomness from the 2291 same KDF instance, but this decision has been criticized by Krawczyk 2292 [HKDFpaper] and doing so is common practice. In addition to IVs, 2293 other examples are the challenge in EAP-TTLS, the RAND in 3GPP AKAs, 2294 and the Session-Id in EAP-TLS 1.3. Note that part of KEYSTREAM_2 is 2295 also non-secret randomness as it is known or predictable to an 2296 attacker. As explained by Krawczyk, if any attack is mitigated by 2297 the NIST requirement it would mean that the KDF is fully broken and 2298 would have to be replaced anyway. 2300 For many constrained IoT devices it is problematic to support several 2301 crypto primitives. Existing devices can be expected to support 2302 either ECDSA or EdDSA. If ECDSA is supported, "deterministic ECDSA" 2303 as specified in [RFC6979] MAY be used. Pure deterministic elliptic- 2304 curve signatures such as deterministic ECDSA and EdDSA have gained 2305 popularity over randomized ECDSA as their security do not depend on a 2306 source of high-quality randomness. Recent research has however found 2307 that implementations of these signature algorithms may be vulnerable 2308 to certain side-channel and fault injection attacks due to their 2309 determinism. See e.g., Section 1 of 2310 [I-D.mattsson-cfrg-det-sigs-with-noise] for a list of attack papers. 2311 As suggested in Section 2.1.1 of [I-D.ietf-cose-rfc8152bis-algs] this 2312 can be addressed by combining randomness and determinism. 2314 Appendix D of [I-D.ietf-lwig-curve-representations] describes how 2315 Montgomery curves such as X25519 and X448 and (twisted) Edwards 2316 curves as curves such as Ed25519 and Ed448 can mapped to and from 2317 short-Weierstrass form for implementation on platforms that 2318 accelerate elliptic curve group operations in short-Weierstrass form. 2320 All private keys, symmetric keys, and IVs MUST be secret. 2321 Implementations should provide countermeasures to side-channel 2322 attacks such as timing attacks. Intermediate computed values such as 2323 ephemeral ECDH keys and ECDH shared secrets MUST be deleted after key 2324 derivation is completed. 2326 The Initiator and the Responder are responsible for verifying the 2327 integrity and validity of certificates. The selection of trusted CAs 2328 should be done very carefully and certificate revocation should be 2329 supported. The choice of revocation mechanism is left to the 2330 application. For example, in case of X.509 certificates, Certificate 2331 Revocation Lists [RFC5280] or OCSP [RFC6960] may be used. 2332 Verification of validity may require the use of a Real-Time Clock 2333 (RTC). The private authentication keys MUST be kept secret, only the 2334 Responder SHALL have access to the Responder's private authentication 2335 key and only the Initiator SHALL have access to the Initiator's 2336 private authentication key. 2338 The Initiator and the Responder are allowed to select its connection 2339 identifiers C_I and C_R, respectively, for the other party to use in 2340 the ongoing EDHOC protocol as well as in a subsequent application 2341 protocol (e.g., OSCORE [RFC8613]). The choice of connection 2342 identifier is not security critical in EDHOC but intended to simplify 2343 the retrieval of the right security context in combination with using 2344 short identifiers. If the wrong connection identifier of the other 2345 party is used in a protocol message it will result in the receiving 2346 party not being able to retrieve a security context (which will 2347 terminate the protocol) or retrieve the wrong security context (which 2348 also terminates the protocol as the message cannot be verified). 2350 If two nodes unintentionally initiate two simultaneous EDHOC message 2351 exchanges with each other even if they only want to complete a single 2352 EDHOC message exchange, they MAY terminate the exchange with the 2353 lexicographically smallest G_X. Note that in cases where several 2354 EDHOC exchanges with different parameter sets (method, COSE headers, 2355 etc.) are used, an attacker can affect which of the parameter sets 2356 that will be used by blocking some of the parameter sets. 2358 If supported by the device, it is RECOMMENDED that at least the long- 2359 term private keys are stored in a Trusted Execution Environment (TEE) 2360 and that sensitive operations using these keys are performed inside 2361 the TEE. To achieve even higher security it is RECOMMENDED that 2362 additional operations such as ephemeral key generation, all 2363 computations of shared secrets, and storage of the PRK keys can be 2364 done inside the TEE. The use of a TEE aims at preventing code within 2365 that environment to be tampered with, and preventing data used by 2366 such code to be read or tampered with by code outside that 2367 environment. 2369 Note that HKDF-Expand has a relativly small maximum output length of 2370 255 * hash_length. This means that when when SHA-256 is used as hash 2371 algorithm, message_2 cannot be longer than 8160 bytes. 2373 The sequence of transcript hashes in EHDOC (TH_2, TH_3, TH_4) do not 2374 make use of a so called running hash, this is a design choice as 2375 running hashes are often not supported on constrained platforms. 2377 When parsing a received EDHOC message, implementations MUST terminate 2378 the protocol if the message does not comply with the CDDL for that 2379 message. It is RECOMMENDED to terminate the protocol if the received 2380 EDHOC message is not deterministic CBOR. 2382 9. IANA Considerations 2383 9.1. EDHOC Exporter Label Registry 2385 IANA has created a new registry titled "EDHOC Exporter Label" under 2386 the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The 2387 registration procedure is "Expert Review". The columns of the 2388 registry are Label and Description. Label is a uint. Description is 2389 a text string. The initial contents of the registry are: 2391 Label: 0 2392 Description: Derived OSCORE Master Secret 2394 Label: 1 2395 Description: Derived OSCORE Master Salt 2397 9.2. EDHOC Cipher Suites Registry 2399 IANA has created a new registry titled "EDHOC Cipher Suites" under 2400 the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The 2401 registration procedure is "Expert Review". The columns of the 2402 registry are Value, Array and Description, where Value is an integer 2403 and the other columns are text strings. The initial contents of the 2404 registry are: 2406 Value: -24 2407 Algorithms: N/A 2408 Desc: Reserved for Private Use 2410 Value: -23 2411 Algorithms: N/A 2412 Desc: Reserved for Private Use 2414 Value: -22 2415 Algorithms: N/A 2416 Desc: Reserved for Private Use 2418 Value: -21 2419 Algorithms: N/A 2420 Desc: Reserved for Private Use 2422 Value: 0 2423 Array: 10, -16, 8, 4, -8, 10, -16 2424 Desc: AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, 2425 AES-CCM-16-64-128, SHA-256 2427 Value: 1 2428 Array: 30, -16, 16, 4, -8, 10, -16 2429 Desc: AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, 2430 AES-CCM-16-64-128, SHA-256 2432 Value: 2 2433 Array: 10, -16, 8, 1, -7, 10, -16 2434 Desc: AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, 2435 AES-CCM-16-64-128, SHA-256 2437 Value: 3 2438 Array: 30, -16, 16, 1, -7, 10, -16 2439 Desc: AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, 2440 AES-CCM-16-64-128, SHA-256 2442 Value: 4 2443 Array: 24, -16, 16, 4, -8, 24, -16 2444 Desc: ChaCha20/Poly1305, SHA-256, 16, X25519, EdDSA, 2445 ChaCha20/Poly1305, SHA-256 2447 Value: 5 2448 Array: 24, -16, 16, 1, -7, 24, -16 2449 Desc: ChaCha20/Poly1305, SHA-256, 16, P-256, ES256, 2450 ChaCha20/Poly1305, SHA-256 2452 Value: 6 2453 Array: 1, -16, 16, 4, -7, 1, -16 2454 Desc: A128GCM, SHA-256, 16, X25519, ES256, 2455 A128GCM, SHA-256 2457 Value: 24 2458 Array: 3, -43, 16, 2, -35, 3, -43 2459 Desc: A256GCM, SHA-384, 16, P-384, ES384, 2460 A256GCM, SHA-384 2462 Value: 25 2463 Array: 24, -45, 16, 5, -8, 24, -45 2464 Desc: ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA, 2465 ChaCha20/Poly1305, SHAKE256 2467 9.3. EDHOC Method Type Registry 2469 IANA has created a new registry entitled "EDHOC Method Type" under 2470 the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The 2471 registration procedure is "Specification Required". The columns of 2472 the registry are Value, Initiator Authentication Key, and Responder 2473 Authentication Key, where Value is an integer and the other columns 2474 are text strings describing the authentication keys. The initial 2475 contents of the registry are shown in Figure 4. 2477 9.4. EDHOC Error Codes Registry 2479 IANA has created a new registry entitled "EDHOC Error Codes" under 2480 the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The 2481 registration procedure is "Expert Review". The columns of the 2482 registry are ERR_CODE, ERR_INFO Type and Description, where ERR_CODE 2483 is an integer, ERR_INFO is a CDDL defined type, and Description is a 2484 text string. The initial contents of the registry are shown in 2485 Figure 9. 2487 9.5. EDHOC External Authorization Data Registry 2489 IANA has created a new registry entitled "EDHOC External 2490 Authorization Data" under the new group name "Ephemeral Diffie- 2491 Hellman Over COSE (EDHOC)". The registration procedure is 2492 "Specification Required". The columns of the registry are Label, 2493 Message, Description, and Reference, where Label is an integer and 2494 the other columns are text strings. 2496 9.6. COSE Header Parameters Registry 2498 IANA has registered the following entries in the "COSE Header 2499 Parameters" registry under the group name "CBOR Object Signing and 2500 Encryption (COSE)". The value of the 'kcwt' header parameter is a 2501 COSE Web Token (CWT) [RFC8392], and the value of the 'kccs' header 2502 parameter is a CWT Claims Set (CCS), see Section 1.4. The CWT/CCS 2503 must contain a COSE_Key in a 'cnf' claim [RFC8747]. The Value 2504 Registry for this item is empty and omitted from the table below. 2506 +-----------+-------+----------------+---------------------------+ 2507 | Name | Label | Value Type | Description | 2508 +===========+=======+================+===========================+ 2509 | kcwt | TBD1 | COSE_Messages | A CBOR Web Token (CWT) | 2510 | | | | containing a COSE_Key in | 2511 | | | | a 'cnf' claim | 2512 +-----------+-------+----------------+---------------------------+ 2513 | kccs | TBD2 | map / #6(map) | A CWT Claims Set (CCS) | 2514 | | | | containing a COSE_Key in | 2515 | | | | a 'cnf' claim | 2516 +-----------+-------+----------------+---------------------------+ 2518 9.7. The Well-Known URI Registry 2520 IANA has added the well-known URI "edhoc" to the "Well-Known URIs" 2521 registry under the group name "Well-Known URIs". 2523 * URI suffix: edhoc 2524 * Change controller: IETF 2526 * Specification document(s): [[this document]] 2528 * Related information: None 2530 9.8. Media Types Registry 2532 IANA has added the media types "application/edhoc+cbor-seq" and 2533 "application/cid-edhoc+cbor-seq" to the "Media Types" registry. 2535 9.8.1. application/edhoc+cbor-seq Media Type Registration 2537 * Type name: application 2539 * Subtype name: edhoc+cbor-seq 2541 * Required parameters: N/A 2543 * Optional parameters: N/A 2545 * Encoding considerations: binary 2547 * Security considerations: See Section 7 of this document. 2549 * Interoperability considerations: N/A 2551 * Published specification: [[this document]] (this document) 2553 * Applications that use this media type: To be identified 2555 * Fragment identifier considerations: N/A 2557 * Additional information: 2559 - Magic number(s): N/A 2561 - File extension(s): N/A 2563 - Macintosh file type code(s): N/A 2565 * Person & email address to contact for further information: See 2566 "Authors' Addresses" section. 2568 * Intended usage: COMMON 2570 * Restrictions on usage: N/A 2571 * Author: See "Authors' Addresses" section. 2573 * Change Controller: IESG 2575 9.8.2. application/cid-edhoc+cbor-seq Media Type Registration 2577 * Type name: application 2579 * Subtype name: cid-edhoc+cbor-seq 2581 * Required parameters: N/A 2583 * Optional parameters: N/A 2585 * Encoding considerations: binary 2587 * Security considerations: See Section 7 of this document. 2589 * Interoperability considerations: N/A 2591 * Published specification: [[this document]] (this document) 2593 * Applications that use this media type: To be identified 2595 * Fragment identifier considerations: N/A 2597 * Additional information: 2599 - Magic number(s): N/A 2601 - File extension(s): N/A 2603 - Macintosh file type code(s): N/A 2605 * Person & email address to contact for further information: See 2606 "Authors' Addresses" section. 2608 * Intended usage: COMMON 2610 * Restrictions on usage: N/A 2612 * Author: See "Authors' Addresses" section. 2614 * Change Controller: IESG 2616 9.9. CoAP Content-Formats Registry 2618 IANA has added the media types "application/edhoc+cbor-seq" and 2619 "application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats" 2620 registry under the group name "Constrained RESTful Environments 2621 (CoRE) Parameters". 2623 +--------------------------------+----------+------+-------------------+ 2624 | Media Type | Encoding | ID | Reference | 2625 +--------------------------------+----------+------+-------------------+ 2626 | application/edhoc+cbor-seq | - | TBD5 | [[this document]] | 2627 | application/cid-edhoc+cbor-seq | - | TBD6 | [[this document]] | 2628 +--------------------------------+----------+------+-------------------+ 2630 Figure 12: CoAP Content-Format IDs 2632 9.10. Resource Type (rt=) Link Target Attribute Values Registry 2634 IANA has added the resource type "core.edhoc" to the "Resource Type 2635 (rt=) Link Target Attribute Values" registry under the group name 2636 "Constrained RESTful Environments (CoRE) Parameters". 2638 * Value: "core.edhoc" 2640 * Description: EDHOC resource. 2642 * Reference: [[this document]] 2644 9.11. Expert Review Instructions 2646 The IANA Registries established in this document are defined as 2647 "Expert Review". This section gives some general guidelines for what 2648 the experts should be looking for, but they are being designated as 2649 experts for a reason so they should be given substantial latitude. 2651 Expert reviewers should take into consideration the following points: 2653 * Clarity and correctness of registrations. Experts are expected to 2654 check the clarity of purpose and use of the requested entries. 2655 Expert needs to make sure the values of algorithms are taken from 2656 the right registry, when that is required. Expert should consider 2657 requesting an opinion on the correctness of registered parameters 2658 from relevant IETF working groups. Encodings that do not meet 2659 these objective of clarity and completeness should not be 2660 registered. 2662 * Experts should take into account the expected usage of fields when 2663 approving point assignment. The length of the encoded value 2664 should be weighed against how many code points of that length are 2665 left, the size of device it will be used on, and the number of 2666 code points left that encode to that size. 2668 * Specifications are recommended. When specifications are not 2669 provided, the description provided needs to have sufficient 2670 information to verify the points above. 2672 10. References 2674 10.1. Normative References 2676 [I-D.ietf-cose-rfc8152bis-algs] 2677 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2678 Initial Algorithms", Work in Progress, Internet-Draft, 2679 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2680 . 2683 [I-D.ietf-cose-rfc8152bis-struct] 2684 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2685 Structures and Process", Work in Progress, Internet-Draft, 2686 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2687 . 2690 [I-D.ietf-cose-x509] 2691 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2692 Header parameters for carrying and referencing X.509 2693 certificates", Work in Progress, Internet-Draft, draft- 2694 ietf-cose-x509-08, 14 December 2020, 2695 . 2698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2699 Requirement Levels", BCP 14, RFC 2119, 2700 DOI 10.17487/RFC2119, March 1997, 2701 . 2703 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 2704 Identifiers for the Internet X.509 Public Key 2705 Infrastructure Certificate and Certificate Revocation List 2706 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2707 2002, . 2709 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 2710 Text on Security Considerations", BCP 72, RFC 3552, 2711 DOI 10.17487/RFC3552, July 2003, 2712 . 2714 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2715 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2716 . 2718 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2719 Housley, R., and W. Polk, "Internet X.509 Public Key 2720 Infrastructure Certificate and Certificate Revocation List 2721 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2722 . 2724 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2725 Key Derivation Function (HKDF)", RFC 5869, 2726 DOI 10.17487/RFC5869, May 2010, 2727 . 2729 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2730 Curve Cryptography Algorithms", RFC 6090, 2731 DOI 10.17487/RFC6090, February 2011, 2732 . 2734 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 2735 Galperin, S., and C. Adams, "X.509 Internet Public Key 2736 Infrastructure Online Certificate Status Protocol - OCSP", 2737 RFC 6960, DOI 10.17487/RFC6960, June 2013, 2738 . 2740 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 2741 Algorithm (DSA) and Elliptic Curve Digital Signature 2742 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2743 2013, . 2745 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2746 Application Protocol (CoAP)", RFC 7252, 2747 DOI 10.17487/RFC7252, June 2014, 2748 . 2750 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 2751 Trammell, B., Huitema, C., and D. Borkmann, 2752 "Confidentiality in the Face of Pervasive Surveillance: A 2753 Threat Model and Problem Statement", RFC 7624, 2754 DOI 10.17487/RFC7624, August 2015, 2755 . 2757 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2758 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2759 2016, . 2761 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2762 the Constrained Application Protocol (CoAP)", RFC 7959, 2763 DOI 10.17487/RFC7959, August 2016, 2764 . 2766 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2767 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2768 May 2017, . 2770 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2771 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2772 . 2774 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2775 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2776 May 2018, . 2778 [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for 2779 Ed25519, Ed448, X25519, and X448 for Use in the Internet 2780 X.509 Public Key Infrastructure", RFC 8410, 2781 DOI 10.17487/RFC8410, August 2018, 2782 . 2784 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2785 Definition Language (CDDL): A Notational Convention to 2786 Express Concise Binary Object Representation (CBOR) and 2787 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2788 June 2019, . 2790 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2791 "Object Security for Constrained RESTful Environments 2792 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2793 . 2795 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2796 Zuniga, "SCHC: Generic Framework for Static Context Header 2797 Compression and Fragmentation", RFC 8724, 2798 DOI 10.17487/RFC8724, April 2020, 2799 . 2801 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 2802 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 2803 . 2805 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2806 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2807 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2808 2020, . 2810 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2811 Representation (CBOR)", STD 94, RFC 8949, 2812 DOI 10.17487/RFC8949, December 2020, 2813 . 2815 [RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander, 2816 "Constrained Application Protocol (CoAP): Echo, Request- 2817 Tag, and Token Processing", RFC 9175, 2818 DOI 10.17487/RFC9175, February 2022, 2819 . 2821 10.2. Informative References 2823 [Bruni18] Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and 2824 C. Schürmann, "Formal Verification of Ephemeral Diffie- 2825 Hellman Over COSE (EDHOC)", November 2018, 2826 . 2830 [CborMe] Bormann, C., "CBOR Playground", May 2018, 2831 . 2833 [CNSA] (Placeholder), ., "Commercial National Security Algorithm 2834 Suite", August 2015, 2835 . 2838 [Degabriele11] 2839 Degabriele, J.P., Lehmann, A., Paterson, K.G., Smart, 2840 N.P., and M. Strefler, "On the Joint Security of 2841 Encryption and Signature in EMV", December 2011, 2842 . 2844 [HKDFpaper] 2845 Krawczyk, H., "Cryptographic Extraction and Key 2846 Derivation: The HKDF Scheme", May 2010, 2847 . 2849 [I-D.arkko-arch-internet-threat-model-guidance] 2850 Arkko, J. and S. Farrell, "Internet Threat Model 2851 Guidance", Work in Progress, Internet-Draft, draft-arkko- 2852 arch-internet-threat-model-guidance-00, 12 July 2021, 2853 . 2856 [I-D.ietf-core-oscore-edhoc] 2857 Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., 2858 and G. Selander, "Profiling EDHOC for CoAP and OSCORE", 2859 Work in Progress, Internet-Draft, draft-ietf-core-oscore- 2860 edhoc-03, 7 March 2022, . 2863 [I-D.ietf-core-oscore-key-update] 2864 Höglund, R. and M. Tiloca, "Key Update for OSCORE 2865 (KUDOS)", Work in Progress, Internet-Draft, draft-ietf- 2866 core-oscore-key-update-01, 7 March 2022, 2867 . 2870 [I-D.ietf-cose-cbor-encoded-cert] 2871 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 2872 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 2873 Certificates)", Work in Progress, Internet-Draft, draft- 2874 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 2875 . 2878 [I-D.ietf-lake-reqs] 2879 Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia- 2880 Carrillo, "Requirements for a Lightweight AKE for OSCORE", 2881 Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04, 2882 8 June 2020, . 2885 [I-D.ietf-lake-traces] 2886 Selander, G. and J. P. Mattsson, "Traces of EDHOC", Work 2887 in Progress, Internet-Draft, draft-ietf-lake-traces-00, 25 2888 November 2021, . 2891 [I-D.ietf-lwig-curve-representations] 2892 Struik, R., "Alternative Elliptic Curve Representations", 2893 Work in Progress, Internet-Draft, draft-ietf-lwig-curve- 2894 representations-23, 21 January 2022, 2895 . 2898 [I-D.ietf-lwig-security-protocol-comparison] 2899 Mattsson, J. P., Palombini, F., and M. Vucinic, 2900 "Comparison of CoAP Security Protocols", Work in Progress, 2901 Internet-Draft, draft-ietf-lwig-security-protocol- 2902 comparison-05, 2 November 2020, 2903 . 2906 [I-D.ietf-rats-eat] 2907 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 2908 Attestation Token (EAT)", Work in Progress, Internet- 2909 Draft, draft-ietf-rats-eat-12, 24 February 2022, 2910 . 2913 [I-D.mattsson-cfrg-det-sigs-with-noise] 2914 Mattsson, J. P., Thormarker, E., and S. Ruohomaa, 2915 "Deterministic ECDSA and EdDSA Signatures with Additional 2916 Randomness", Work in Progress, Internet-Draft, draft- 2917 mattsson-cfrg-det-sigs-with-noise-04, 15 February 2022, 2918 . 2921 [I-D.selander-ace-ake-authz] 2922 Selander, G., Mattsson, J. P., Vučinić, M., Richardson, 2923 M., and A. Schellenbaum, "Lightweight Authorization for 2924 Authenticated Key Exchange.", Work in Progress, Internet- 2925 Draft, draft-selander-ace-ake-authz-05, 18 April 2022, 2926 . 2929 [Norrman20] 2930 Norrman, K., Sundararajan, V., and A. Bruni, "Formal 2931 Analysis of EDHOC Key Establishment for Constrained IoT 2932 Devices", September 2020, 2933 . 2935 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2936 Request Syntax Specification Version 1.7", RFC 2986, 2937 DOI 10.17487/RFC2986, November 2000, 2938 . 2940 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 2941 Considerations for the SHA-0 and SHA-1 Message-Digest 2942 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 2943 . 2945 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2946 Constrained-Node Networks", RFC 7228, 2947 DOI 10.17487/RFC7228, May 2014, 2948 . 2950 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2951 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2952 2014, . 2954 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2955 Kivinen, "Internet Key Exchange Protocol Version 2 2956 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2957 2014, . 2959 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2960 "A Voucher Artifact for Bootstrapping Protocols", 2961 RFC 8366, DOI 10.17487/RFC8366, May 2018, 2962 . 2964 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2965 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2966 . 2968 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 2969 and C. Wood, "Randomness Improvements for Security 2970 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 2971 . 2973 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2974 Multiplexed and Secure Transport", RFC 9000, 2975 DOI 10.17487/RFC9000, May 2021, 2976 . 2978 [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2979 Datagram Transport Layer Security (DTLS) Protocol Version 2980 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 2981 . 2983 [RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and 2984 P. van der Stok, "Constrained RESTful Environments (CoRE) 2985 Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April 2986 2022, . 2988 [SECG] "Standards for Efficient Cryptography 1 (SEC 1)", May 2989 2009, . 2991 [SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to 2992 Authenticated Diffie-Hellman and Its Use in the IKE- 2993 Protocols (Long version)", June 2003, 2994 . 2996 [SP-800-56A] 2997 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 2998 Davis, "Recommendation for Pair-Wise Key-Establishment 2999 Schemes Using Discrete Logarithm Cryptography", 3000 NIST Special Publication 800-56A Revision 3, April 2018, 3001 . 3003 [Thormarker21] 3004 Thormarker, E., "On using the same key pair for Ed25519 3005 and an X25519 based KEM", April 2021, 3006 . 3008 Appendix A. Use with OSCORE and Transfer over CoAP 3010 This appendix describes how to derive an OSCORE security context when 3011 OSCORE is used with EDHOC, and how to transfer EDHOC messages over 3012 CoAP. 3014 A.1. Deriving the OSCORE Security Context 3016 This section specifies how to use EDHOC output to derive the OSCORE 3017 security context. 3019 After successful processing of EDHOC message_3, Client and Server 3020 derive Security Context parameters for OSCORE as follows (see 3021 Section 3.2 of [RFC8613]): 3023 * The Master Secret and Master Salt are derived by using the EDHOC- 3024 Exporter interface, see Section 4.2.1. 3026 The EDHOC Exporter Labels for deriving the OSCORE Master Secret and 3027 the OSCORE Master Salt, are the uints 0 and 1, respectively. 3029 The context parameter is h'' (0x40), the empty CBOR byte string. 3031 By default, oscore_key_length is the key length (in bytes) of the 3032 application AEAD Algorithm of the selected cipher suite for the EDHOC 3033 session. Also by default, oscore_salt_length has value 8. The 3034 Initiator and Responder MAY agree out-of-band on a longer 3035 oscore_key_length than the default and on a different 3036 oscore_salt_length. 3038 Master Secret = EDHOC-Exporter( 0, h'', oscore_key_length ) 3039 Master Salt = EDHOC-Exporter( 1, h'', oscore_salt_length ) 3041 * The AEAD Algorithm is the application AEAD algorithm of the 3042 selected cipher suite for the EDHOC session. 3044 * The HKDF Algorithm is the one based on the application hash 3045 algorithm of the selected cipher suite for the EDHOC session. For 3046 example, if SHA-256 is the application hash algorithm of the 3047 selected cipher suite, HKDF SHA-256 is used as HKDF Algorithm in 3048 the OSCORE Security Context. 3050 * In case the Client is Initiator and the Server is Responder, the 3051 Client's OSCORE Sender ID and the Server's OSCORE Sender ID are 3052 determined from the EDHOC connection identifiers C_R and C_I for 3053 the EDHOC session, respectively, by applying the conversion in 3054 Section 3.3.3. The reverse applies in case the Client is the 3055 Responder and the Server is the Initiator. 3057 Client and Server use the parameters above to establish an OSCORE 3058 Security Context, as per Section 3.2.1 of [RFC8613]. 3060 From then on, Client and Server retrieve the OSCORE protocol state 3061 using the Recipient ID, and optionally other transport information 3062 such as the 5-tuple. 3064 A.2. Transferring EDHOC over CoAP 3066 This section specifies one instance for how EDHOC can be transferred 3067 as an exchange of CoAP [RFC7252] messages. CoAP provides a reliable 3068 transport that can preserve packet ordering and handle message 3069 duplication. CoAP can also perform fragmentation and protect against 3070 denial-of-service attacks. The underlying CoAP transport should be 3071 used in reliable mode, in particular when fragmentation is used, to 3072 avoid, e.g., situations with hanging endpoints waiting for each 3073 other. 3075 By default, the CoAP client is the Initiator and the CoAP server is 3076 the Responder, but the roles SHOULD be chosen to protect the most 3077 sensitive identity, see Section 8. Client applications can use the 3078 resource type "core.edhoc" to discover a server's EDHOC resource, 3079 i.e., where to send a request for executing the EDHOC protocol, see 3080 Section 9.10. According to this specification, EDHOC is transferred 3081 in POST requests and 2.04 (Changed) responses to the Uri-Path: 3082 "/.well-known/edhoc", see Section 9.7. An application may define its 3083 own path that can be discovered, e.g., using a resource directory 3084 [RFC9176]. 3086 By default, the message flow is as follows: EDHOC message_1 is sent 3087 in the payload of a POST request from the client to the server's 3088 resource for EDHOC. EDHOC message_2 or the EDHOC error message is 3089 sent from the server to the client in the payload of the response, in 3090 the former case with response code 2.04 (Changed), in the latter with 3091 response code as specified in Appendix A.2.1. EDHOC message_3 or the 3092 EDHOC error message is sent from the client to the server's resource 3093 in the payload of a POST request. If EDHOC message_4 is used, or in 3094 case of an error message, it is sent from the server to the client in 3095 the payload of the response, with response codes analogously to 3096 message_2. In case of an error message in response to message_4, it 3097 is sent analogously to errors in response to message_2. 3099 In order for the server to correlate a message received from a client 3100 to a message previously sent in the same EDHOC session over CoAP, 3101 messages sent by the client are prepended with the CBOR serialization 3102 of the connection identifier which the server has chosen. This 3103 applies independently of if the CoAP server is Responder or 3104 Initiator. 3106 * For the default case when the server is Responder, message_3 is 3107 sent from the client prepended with the identifier C_R. In this 3108 case message_1 is also sent by the client, and to indicate that 3109 this is a new EDHOC session it is prepended with a dummy 3110 identifier, the CBOR simple value "true" (0xf5), since the server 3111 has not selected C_R yet. See Figure 13. 3113 * In the case when the server is Initiator, message_2 (and 3114 message_4, if present) is sent from the client prepended with the 3115 identifier C_I. See Figure 14. 3117 The prepended identifiers are encoded in CBOR and thus self- 3118 delimiting. The integer representation of identifiers described in 3119 Section 3.3.2 is used, when applicable. They are sent in front of 3120 the actual EDHOC message to keep track of messages in an EDHOC 3121 session, and only the part of the body following the identifier is 3122 used for EDHOC processing. In particular, the connection identifiers 3123 within the EDHOC messages are not impacted by the prepended 3124 identifiers. 3126 The application/edhoc+cbor-seq media type does not apply to these 3127 messages; their media type is application/cid-edhoc+cbor-seq. 3129 An example of a successful EDHOC exchange using CoAP is shown in 3130 Figure 13. In this case the CoAP Token enables correlation on the 3131 Initiator side, and the prepended C_R enables correlation on the 3132 Responder (server) side. 3134 Client Server 3135 | | 3136 +--------->| Header: POST (Code=0.02) 3137 | POST | Uri-Path: "/.well-known/edhoc" 3138 | | Content-Format: application/cid-edhoc+cbor-seq 3139 | | Payload: true, EDHOC message_1 3140 | | 3141 |<---------+ Header: 2.04 Changed 3142 | 2.04 | Content-Format: application/edhoc+cbor-seq 3143 | | Payload: EDHOC message_2 3144 | | 3145 +--------->| Header: POST (Code=0.02) 3146 | POST | Uri-Path: "/.well-known/edhoc" 3147 | | Content-Format: application/cid-edhoc+cbor-seq 3148 | | Payload: C_R, EDHOC message_3 3149 | | 3150 |<---------+ Header: 2.04 Changed 3151 | 2.04 | Content-Format: application/edhoc+cbor-seq 3152 | | Payload: EDHOC message_4 3153 | | 3155 Figure 13: Example of transferring EDHOC in CoAP when the 3156 Initiator is CoAP client. The optional message_4 is included in 3157 this example, without which that message needs no payload. 3159 The exchange in Figure 13 protects the client identity against active 3160 attackers and the server identity against passive attackers. 3162 An alternative exchange that protects the server identity against 3163 active attackers and the client identity against passive attackers is 3164 shown in Figure 14. In this case the CoAP Token enables the 3165 Responder to correlate message_2 and message_3, and the prepended C_I 3166 enables correlation on the Initiator (server) side. If EDHOC 3167 message_4 is used, C_I is prepended, and it is transported with CoAP 3168 in the payload of a POST request with a 2.04 (Changed) response. 3170 Client Server 3171 | | 3172 +--------->| Header: POST (Code=0.02) 3173 | POST | Uri-Path: "/.well-known/edhoc" 3174 | | 3175 |<---------+ Header: 2.04 Changed 3176 | 2.04 | Content-Format: application/edhoc+cbor-seq 3177 | | Payload: EDHOC message_1 3178 | | 3179 +--------->| Header: POST (Code=0.02) 3180 | POST | Uri-Path: "/.well-known/edhoc" 3181 | | Content-Format: application/cid-edhoc+cbor-seq 3182 | | Payload: C_I, EDHOC message_2 3183 | | 3184 |<---------+ Header: 2.04 Changed 3185 | 2.04 | Content-Format: application/edhoc+cbor-seq 3186 | | Payload: EDHOC message_3 3187 | | 3189 Figure 14: Example of transferring EDHOC in CoAP when the 3190 Initiator is CoAP server. 3192 To protect against denial-of-service attacks, the CoAP server MAY 3193 respond to the first POST request with a 4.01 (Unauthorized) 3194 containing an Echo option [RFC9175]. This forces the Initiator to 3195 demonstrate its reachability at its apparent network address. If 3196 message fragmentation is needed, the EDHOC messages may be fragmented 3197 using the CoAP Block-Wise Transfer mechanism [RFC7959]. 3199 EDHOC does not restrict how error messages are transported with CoAP, 3200 as long as the appropriate error message can to be transported in 3201 response to a message that failed (see Section 6). EDHOC error 3202 messages transported with CoAP are carried in the payload. 3204 A.2.1. Transferring EDHOC and OSCORE over CoAP 3206 When using EDHOC over CoAP for establishing an OSCORE Security 3207 Context, EDHOC error messages sent as CoAP responses MUST be sent in 3208 the payload of error responses, i.e., they MUST specify a CoAP error 3209 response code. In particular, it is RECOMMENDED that such error 3210 responses have response code either 4.00 (Bad Request) in case of 3211 client error (e.g., due to a malformed EDHOC message), or 5.00 3212 (Internal Server Error) in case of server error (e.g., due to failure 3213 in deriving EDHOC keying material). The Content-Format of the error 3214 response MUST be set to application/edhoc+cbor-seq, see Section 9.9. 3216 A method for combining EDHOC and OSCORE protocols in two round-trips 3217 is specified in [I-D.ietf-core-oscore-edhoc]. That specification 3218 also contains conversion from OSCORE Sender/Recipient IDs to EDHOC 3219 connection identifiers, web-linking and target attributes for 3220 discovering of EDHOC resources. 3222 Appendix B. Compact Representation 3224 As described in Section 4.2 of [RFC6090] the x-coordinate of an 3225 elliptic curve public key is a suitable representative for the entire 3226 point whenever scalar multiplication is used as a one-way function. 3227 One example is ECDH with compact output, where only the x-coordinate 3228 of the computed value is used as the shared secret. 3230 This section defines a format for compact representation based on the 3231 Elliptic-Curve-Point-to-Octet-String Conversion defined in 3232 Section 2.3.3 of [SECG]. In EDHOC, compact representation is used 3233 for the ephemeral public keys (G_X and G_Y), see Section 3.7. Using 3234 the notation from [SECG], the output is an octet string of length 3235 ceil( (log2 q) / 8 ). See [SECG] for a definition of q, M, X, xp, 3236 and ~yp. The steps in Section 2.3.3 of [SECG] are replaced by: 3238 1. Convert the field element xp to an octet string X of length ceil( 3239 (log2 q) / 8 ) octets using the conversion routine specified in 3240 Section 2.3.5 of [SECG]. 3242 2. Output M = X 3244 The encoding of the point at infinity is not supported. Compact 3245 representation does not change any requirements on validation. If a 3246 y-coordinate is required for validation or compatibility with APIs 3247 the value ~yp SHALL be set to zero. For such use, the compact 3248 representation can be transformed into the SECG point compressed 3249 format by prepending it with the single byte 0x02 (i.e., M = 0x02 || 3250 X). 3252 Using compact representation have some security benefits. An 3253 implementation does not need to check that the point is not the point 3254 at infinity (the identity element). Similarly, as not even the sign 3255 of the y-coordinate is encoded, compact representation trivially 3256 avoids so called "benign malleability" attacks where an attacker 3257 changes the sign, see [SECG]. 3259 Appendix C. Use of CBOR, CDDL and COSE in EDHOC 3261 This Appendix is intended to simplify for implementors not familiar 3262 with CBOR [RFC8949], CDDL [RFC8610], COSE 3263 [I-D.ietf-cose-rfc8152bis-struct], and HKDF [RFC5869]. 3265 C.1. CBOR and CDDL 3267 The Concise Binary Object Representation (CBOR) [RFC8949] is a data 3268 format designed for small code size and small message size. CBOR 3269 builds on the JSON data model but extends it by e.g., encoding binary 3270 data directly without base64 conversion. In addition to the binary 3271 CBOR encoding, CBOR also has a diagnostic notation that is readable 3272 and editable by humans. The Concise Data Definition Language (CDDL) 3273 [RFC8610] provides a way to express structures for protocol messages 3274 and APIs that use CBOR. [RFC8610] also extends the diagnostic 3275 notation. 3277 CBOR data items are encoded to or decoded from byte strings using a 3278 type-length-value encoding scheme, where the three highest order bits 3279 of the initial byte contain information about the major type. CBOR 3280 supports several different types of data items, in addition to 3281 integers (int, uint), simple values, byte strings (bstr), and text 3282 strings (tstr), CBOR also supports arrays [] of data items, maps {} 3283 of pairs of data items, and sequences [RFC8742] of data items. Some 3284 examples are given below. 3286 The EDHOC specification sometimes use CDDL names in CBOR diagnostic 3287 notation as in e.g., << ID_CRED_R, ? EAD_2 >>. This means that EAD_2 3288 is optional and that ID_CRED_R and EAD_2 should be substituted with 3289 their values before evaluation. I.e., if ID_CRED_R = { 4 : h'' } and 3290 EAD_2 is omitted then << ID_CRED_R, ? EAD_2 >> = << { 4 : h'' } >>, 3291 which encodes to 0x43a10440. 3293 For a complete specification and more examples, see [RFC8949] and 3294 [RFC8610]. We recommend implementors to get used to CBOR by using 3295 the CBOR playground [CborMe]. 3297 Diagnostic Encoded Type 3298 ------------------------------------------------------------------ 3299 1 0x01 unsigned integer 3300 24 0x1818 unsigned integer 3301 -24 0x37 negative integer 3302 -25 0x3818 negative integer 3303 true 0xf5 simple value 3304 h'' 0x40 byte string 3305 h'12cd' 0x4212cd byte string 3306 '12cd' 0x4431326364 byte string 3307 "12cd" 0x6431326364 text string 3308 { 4 : h'cd' } 0xa10441cd map 3309 << 1, 2, true >> 0x430102f5 byte string 3310 [ 1, 2, true ] 0x830102f5 array 3311 ( 1, 2, true ) 0x0102f5 sequence 3312 1, 2, true 0x0102f5 sequence 3313 ------------------------------------------------------------------ 3315 C.2. CDDL Definitions 3317 This sections compiles the CDDL definitions for ease of reference. 3319 suites = [ 2* int ] / int 3321 ead = 1* ( 3322 ead_label : int, 3323 ead_value : bstr, 3324 ) 3326 message_1 = ( 3327 METHOD : int, 3328 SUITES_I : suites, 3329 G_X : bstr, 3330 C_I : bstr / -24..23, 3331 ? EAD_1 : ead, 3332 ) 3334 message_2 = ( 3335 G_Y_CIPHERTEXT_2 : bstr, 3336 C_R : bstr / -24..23, 3337 ) 3339 message_3 = ( 3340 CIPHERTEXT_3 : bstr, 3341 ) 3343 message_4 = ( 3344 CIPHERTEXT_4 : bstr, 3345 ) 3347 error = ( 3348 ERR_CODE : int, 3349 ERR_INFO : any, 3350 ) 3352 info = ( 3353 label : tstr, 3354 context : bstr, 3355 length : uint, 3356 ) 3358 C.3. COSE 3360 CBOR Object Signing and Encryption (COSE) 3361 [I-D.ietf-cose-rfc8152bis-struct] describes how to create and process 3362 signatures, message authentication codes, and encryption using CBOR. 3363 COSE builds on JOSE, but is adapted to allow more efficient 3364 processing in constrained devices. EDHOC makes use of COSE_Key, 3365 COSE_Encrypt0, and COSE_Sign1 objects in the message processing: 3367 * ECDH ephemeral public keys of type EC2 or OKP in message_1 and 3368 message_2 consist of the COSE_Key parameter named 'x', see 3369 Section 7.1 and 7.2 of [I-D.ietf-cose-rfc8152bis-algs] 3371 * The ciphertexts in message_3 and message_4 consist of a subset of 3372 the single recipient encrypted data object COSE_Encrypt0, which is 3373 described in Sections 5.2-5.3 of 3374 [I-D.ietf-cose-rfc8152bis-struct]. The ciphertext is computed 3375 over the plaintext and associated data, using an encryption key 3376 and an initialization vector. The associated data is an 3377 Enc_structure consisting of protected headers and externally 3378 supplied data (external_aad). COSE constructs the input to the 3379 AEAD [RFC5116] for message_i (i = 3 or 4, see Section 5.4 and 3380 Section 5.5, respectively) as follows: 3382 - Secret key K = K_i 3384 - Nonce N = IV_i 3386 - Plaintext P for message_i 3388 - Associated Data A = [ "Encrypt0", h'', TH_i ] 3390 * Signatures in message_2 of method 0 and 2, and in message_3 of 3391 method 0 and 1, consist of a subset of the single signer data 3392 object COSE_Sign1, which is described in Sections 4.2-4.4 of 3393 [I-D.ietf-cose-rfc8152bis-struct]. The signature is computed over 3394 a Sig_structure containing payload, protected headers and 3395 externally supplied data (external_aad) using a private signature 3396 key and verified using the corresponding public signature key. 3397 For COSE_Sign1, the message to be signed is: 3399 [ "Signature1", protected, external_aad, payload ] 3401 where protected, external_aad and payload are specified in 3402 Section 5.3 and Section 5.4. 3404 Different header parameters to identify X.509 or C509 certificates by 3405 reference are defined in [I-D.ietf-cose-x509] and 3406 [I-D.ietf-cose-cbor-encoded-cert]: 3408 * by a hash value with the 'x5t' or 'c5t' parameters, respectively: 3410 - ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, 3412 - ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R; 3414 * or by a URI with the 'x5u' or 'c5u' parameters, respectively: 3416 - ID_CRED_x = { 35 : uri }, for x = I or R, 3418 - ID_CRED_x = { TBD4 : uri }, for x = I or R. 3420 When ID_CRED_x does not contain the actual credential, it may be very 3421 short, e.g., if the endpoints have agreed to use a key identifier 3422 parameter 'kid': 3424 * ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or 3425 R. 3427 Note that a COSE header map can contain several header parameters, 3428 for example { x5u, x5t } or { kid, kid_context }. 3430 ID_CRED_x MAY also identify the credential by value. For example, a 3431 certificate chain can be transported in ID_CRED_x with COSE header 3432 parameter c5c or x5chain, defined in 3433 [I-D.ietf-cose-cbor-encoded-cert] and [I-D.ietf-cose-x509] and 3434 credentials of type CWT and CCS can be transported with the COSE 3435 header parameters registered in Section 9.6. 3437 Appendix D. Authentication Related Verifications 3439 EDHOC performs certain authentication related operations, see 3440 Section 3.5, but in general it is necessary to make additional 3441 verifications beyond EDHOC message processing. What verifications 3442 are needed depend on the deployment, in particular the trust model 3443 and the security policies, but most commonly it can be expressed in 3444 terms of verifications of credential content. 3446 EDHOC assumes the existence of mechanisms (certification authority or 3447 other trusted third party, pre-provisioning, etc.) for generating and 3448 distributing authentication credentials and other credentials, as 3449 well as the existence of trust anchors (CA certificates, trusted 3450 public keys, etc.). For example, a public key certificate or CWT may 3451 rely on a trusted third party whose public key is pre-provisioned, 3452 whereas a CCS or a self-signed certificate/CWT may be used when trust 3453 in the public key can be achieved by other means, or in the case of 3454 trust-on-first-use, see Appendix D.5. 3456 In this section we provide some examples of such verifications. 3457 These verifications are the responsibility of the application but may 3458 be implemented as part of an EDHOC library. 3460 D.1. Validating the Authentication Credential 3462 The authentication credential may contain, in addition to the 3463 authentication key, other parameters that needs to be verified. For 3464 example: 3466 * In X.509 and C509 certificates, signature keys typically have key 3467 usage "digitalSignature" and Diffie-Hellman public keys typically 3468 have key usage "keyAgreement" [RFC3279][RFC8410]. 3470 * In X.509 and C509 certificates validity is expressed using Not 3471 After and Not Before. In CWT and CCS, the "exp" and "nbf" claims 3472 have similar meanings. 3474 D.2. Identities 3476 The application must decide on allowing a connection or not depending 3477 on the intended endpoint, and in particular whether it is a specific 3478 identity or a set of identities. To prevent misbinding attacks, the 3479 identity of the endpoint is included in a MAC verified through the 3480 protocol. More details and examples are provided in this section. 3482 Policies for what connections to allow are typically set based on the 3483 identity of the other endpoint, and endpoints typically only allow 3484 connections from a specific identity or a small restricted set of 3485 identities. For example, in the case of a device connecting to a 3486 network, the network may only allow connections from devices which 3487 authenticate with certificates having a particular range of serial 3488 numbers and signed by a particular CA. Conversely, a device may only 3489 be allowed to connect to a network which authenticates with a 3490 particular public key. 3492 * When a Public Key Infrastructure (PKI) is used with certificates, 3493 the identity is the subject whose unique name, e.g., a domain 3494 name, a Network Access Identifier (NAI), or an Extended Unique 3495 Identifier (EUI), is included in the endpoint's certificate. 3497 * Similarly, when a PKI is used with CWTs, the identity is the 3498 subject identified by the relevant claim(s), such as 'sub' 3499 (subject). 3501 * When PKI is not used (e.g., CCS, self-signed certificate/CWT) the 3502 identity is typically directly associated to the authentication 3503 key of the other party. For example, if identities can be 3504 expressed in the form of unique subject names assigned to public 3505 keys, then a binding to identity is achieved by including both 3506 public key and associated subject name in the authentication 3507 credential: CRED_I or CRED_R may be a self-signed certificate/CWT 3508 or CCS containing the authentication key and the subject name, see 3509 Section 3.5.2. Each endpoint thus needs to know the specific 3510 authentication key/unique associated subject name, or set of 3511 public authentication keys/unique associated subject names, which 3512 it is allowed to communicate with. 3514 To prevent misbinding attacks in systems where an attacker can 3515 register public keys without proving knowledge of the private key, 3516 SIGMA [SIGMA] enforces a MAC to be calculated over the "identity". 3517 EDHOC follows SIGMA by calculating a MAC over the whole 3518 authentication credential, which in case of an X.509 or C509 3519 certificate includes the "subject" and "subjectAltName" fields, and 3520 in the case of CWT or CCS includes the "sub" claim. 3522 (While the SIGMA paper only focuses on the identity, the same 3523 principle is true for other information such as policies associated 3524 to the public key.) 3526 D.3. Certification Path and Trust Anchors 3528 When a Public Key Infrastructure (PKI) is used with certificates, the 3529 trust anchor is a Certification Authority (CA) certificate. Each 3530 party needs at least one CA public key certificate, or just the CA 3531 public key. The certification path contains proof that the subject 3532 of the certificate owns the public key in the certificate. Only 3533 validated public-key certificates are to be accepted. 3535 Similarly, when a PKI is used with CWTs, each party needs to have at 3536 least one trusted third party public key as trust anchor to verify 3537 the end entity CWTs. The trusted third party public key can, e.g., 3538 be stored in a self-signed CWT or in a CCS. 3540 The signature of the authentication credential needs to be verified 3541 with the public key of the issuer. X.509 and C509 certificates 3542 includes the "Issuer" field. In CWT and CCS, the "iss" claim has a 3543 similar meaning. The public key is either a trust anchor or the 3544 public key in another valid and trusted credential in a certification 3545 path from trust anchor to authentication credential. 3547 Similar verifications as made with the authentication credential (see 3548 Appendix D.1) are also needed for the other credentials in the 3549 certification path. 3551 When PKI is not used (CCS, self-signed certificate/CWT), the trust 3552 anchor is the authentication key of the other party, in which case 3553 there is no certification path. 3555 D.4. Revocation Status 3557 The application may need to verify that the credentials are not 3558 revoked, see Section 8.8. Some use cases may be served by short- 3559 lived credentials, for example, where the validity of the credential 3560 is on par with with the interval between revocation checks. But, in 3561 general, credential life time and revokation checking are 3562 complementary measures to control credential status. Revocation 3563 information may be transported as External Authentication Data (EAD), 3564 see Appendix E. 3566 D.5. Trust-on-first-use 3568 TBD 3570 Appendix E. Use of External Authorization Data 3572 In order to reduce the number of messages and round trips, or to 3573 simplify processing, external security applications may be integrated 3574 into EDHOC by transporting external authorization related data (EAD) 3575 in the messages. 3577 The EAD format is specified in Section 3.8, this section contains 3578 examples and further details of how EAD may be used with an 3579 appropriate accompanying specification. 3581 * One example is third-party assisted authorization, requested with 3582 EAD_1, and an authorization artifact ("voucher", cf. [RFC8366]) 3583 returned in EAD_2, see [I-D.selander-ace-ake-authz]. 3585 * Another example is remote attestation, requested in EAD_2, and an 3586 Entity Attestation Token (EAT, [I-D.ietf-rats-eat]) returned in 3587 EAD_3. 3589 * A third example is certificate enrolment, where a Certificate 3590 Signing Request (CSR, [RFC2986]) is included EAD_3, and the issued 3591 public key certificate (X.509 [RFC5280], C509 3592 [I-D.ietf-cose-cbor-encoded-cert]) or a reference thereof is 3593 returned in EAD_4. 3595 External authorization data should be considered unprotected by 3596 EDHOC, and the protection of EAD is the responsibility of the 3597 security application (third party authorization, remote attestation, 3598 certificate enrolment, etc.). The security properties of the EAD 3599 fields (after EDHOC processing) are discussed in Section 8.1. 3601 The content of the EAD field may be used in the EDHOC processing of 3602 the message in which they are contained. For example, authentication 3603 related information like assertions and revocation information, 3604 transported in EAD fields may provide input about trust anchors or 3605 validity of credentials relevant to the authentication processing. 3606 The EAD fields (like ID_CRED fields) are therefore made available to 3607 the application before the message is verified, see details of 3608 message processing in Section 5. In the first example above, a 3609 voucher in EAD_2 made available to the application can enable the 3610 Initiator to verify the identity or public key of the Responder 3611 before verifying the signature. An application allowing EAD fields 3612 containing authentication information thus may need to handle 3613 authentication related verifications associated with EAD processing. 3615 Conversely, the security application may need to wait for EDHOC 3616 message verification to complete. In the third example above, the 3617 validation of a CSR carried in EAD_3 is not started by the Responder 3618 before EDHOC has successfully verified message_3 and proven the 3619 possession of the private key of the Initiator. 3621 The security application may reuse EDHOC protocol fields which 3622 therefore need to be available to the application. For example, the 3623 security application may use the same crypto algorithms as in the 3624 EDHOC session and therefore needs access to the selected cipher suite 3625 (or the whole SUITES_I). The application may use the ephemeral 3626 public keys G_X and G_Y, as ephemeral keys or as nonces, see 3627 [I-D.selander-ace-ake-authz]. 3629 The processing of (ead_label, ead_value) by the security application 3630 needs to be described in the specification where the ead_label is 3631 registered, see Section 9.5, including the ead_value for each message 3632 and actions in case of errors. An application may support multiple 3633 security applications that make use of EAD, which may result in 3634 multiple (ead_label, ead_value) pairs in one EAD field, see 3635 Section 3.8. Any dependencies on security applications with 3636 previously registered EAD fields needs to be documented, and the 3637 processing needs to consider their simultaneous use. 3639 Since data carried in EAD may not be protected, or be processed by 3640 the application before the EDHOC message is verified, special 3641 considerations need to be made such that it does not violate security 3642 and privacy requirements of the service which uses this data, see 3643 Section 8.5. The content in an EAD field may impact the security 3644 properties provided by EDHOC. Security applications making use of 3645 the EAD fields must perform the necessary security analysis. 3647 Appendix F. Application Profile Example 3649 This appendix contains a rudimentary example of an application 3650 profile, see Section 3.9. 3652 For use of EDHOC with application X the following assumptions are 3653 made: 3655 1. Transfer in CoAP as specified in Appendix A.2 with requests 3656 expected by the CoAP server (= Responder) at /app1-edh, no 3657 Content-Format needed. 3659 2. METHOD = 1 (I uses signature key, R uses static DH key.) 3661 3. CRED_I is an IEEE 802.1AR IDevID encoded as a C509 certificate of 3662 type 0 [I-D.ietf-cose-cbor-encoded-cert]. 3664 * R acquires CRED_I out-of-band, indicated in EAD_1. 3666 * ID_CRED_I = {4: h''} is a 'kid' with value empty CBOR byte 3667 string. 3669 4. CRED_R is a CCS of type OKP as specified in Section 3.5.2. 3671 * The CBOR map has parameters 1 (kty), -1 (crv), and -2 3672 (x-coordinate). 3674 * ID_CRED_R is {TBD2 : CCS}. Editor's note: TBD2 is the COSE 3675 header parameter value of 'kccs', see Section 9.6 3677 5. External authorization data is defined and processed as specified 3678 in [I-D.selander-ace-ake-authz]. 3680 6. EUI-64 is used as the identity of the endpoint (see example in 3681 Section 3.5.2). 3683 7. No use of message_4: the application sends protected messages 3684 from R to I. 3686 Appendix G. EDHOC Message Deduplication 3688 EDHOC by default assumes that message duplication is handled by the 3689 transport, in this section exemplified with CoAP. 3691 Deduplication of CoAP messages is described in Section 4.5 of 3692 [RFC7252]. This handles the case when the same Confirmable (CON) 3693 message is received multiple times due to missing acknowledgement on 3694 CoAP messaging layer. The recommended processing in [RFC7252] is 3695 that the duplicate message is acknowledged (ACK), but the received 3696 message is only processed once by the CoAP stack. 3698 Message deduplication is resource demanding and therefore not 3699 supported in all CoAP implementations. Since EDHOC is targeting 3700 constrained environments, it is desirable that EDHOC can optionally 3701 support transport layers which do not handle message duplication. 3702 Special care is needed to avoid issues with duplicate messages, see 3703 Section 5.1. 3705 The guiding principle here is similar to the deduplication processing 3706 on CoAP messaging layer: a received duplicate EDHOC message SHALL NOT 3707 result in another instance of the next EDHOC message. The result MAY 3708 be that a duplicate next EDHOC message is sent, provided it is still 3709 relevant with respect to the current protocol state. In any case, 3710 the received message MUST NOT be processed more than once in the same 3711 EDHOC session. This is called "EDHOC message deduplication". 3713 An EDHOC implementation MAY store the previously sent EDHOC message 3714 to be able to resend it. 3716 In principle, if the EDHOC implementation would deterministically 3717 regenerate the identical EDHOC message previously sent, it would be 3718 possible to instead store the protocol state to be able to recreate 3719 and resend the previously sent EDHOC message. However, even if the 3720 protocol state is fixed, the message generation may introduce 3721 differences which compromises security. For example, in the 3722 generation of message_3, if I is performing a (non-deterministic) 3723 ECDSA signature (say, method 0 or 1, cipher suite 2 or 3) then 3724 PLAINTEXT_3 is randomized, but K_3 and IV_3 are the same, leading to 3725 a key and nonce reuse. 3727 The EDHOC implementation MUST NOT store previous protocol state and 3728 regenerate an EDHOC message if there is a risk that the same key and 3729 IV are used for two (or more) distinct messages. 3731 The previous message or protocol state MUST NOT be kept longer than 3732 what is required for retransmission, for example, in the case of CoAP 3733 transport, no longer than the EXCHANGE_LIFETIME (see Section 4.8.2 of 3734 [RFC7252]). 3736 Appendix H. Transports Not Natively Providing Correlation 3738 Protocols that do not natively provide full correlation between a 3739 series of messages can send the C_I and C_R identifiers along as 3740 needed. 3742 The transport over CoAP (Appendix A.2) can serve as a blueprint for 3743 other server-client protocols: The client prepends the C_x which the 3744 server selected (or, for message_1, the CBOR simple value 'true' 3745 which is not a valid C_x) to any request message it sends. The 3746 server does not send any such indicator, as responses are matched to 3747 request by the client-server protocol design. 3749 Protocols that do not provide any correlation at all can prescribe 3750 prepending of the peer's chosen C_x to all messages. 3752 Appendix I. Change Log 3754 RFC Editor: Please remove this appendix. 3756 * From -13 to -14 3758 - Merge of section 1.1 and 1.2 3760 - Connection and key identifiers restricted to be byte strings 3762 - Representation of byte strings as one-byte CBOR ints (-24..23) 3764 - Simplified mapping between EDHOC and OSCORE identifiers 3766 - Rewrite of 3.5 3768 o Clarification of authentication related operations performed 3769 by EDHOC 3771 o Authentication related verifications, including old section 3772 3.5.1, moved to new appendix D 3774 - Rewrite of 3.8 3776 o Move content about use of EAD to new appendix E 3778 o ead_value changed to bstr 3780 - EDHOC-KDF updated 3782 o transcript_hash argument removed 3783 o TH included in context argument 3785 o label argument is now type uint, all labels replaced 3787 - Key schedule updated 3789 o New salts derived to avoid reuse of same key with expand and 3790 extract 3792 o PRK_4x3m renamed PRK_4e3m 3794 o K_4 and IV_4 derived from PRK_4e3m 3796 o New PRK: PRK_out derived from PRK_4e3m and TH_4 3798 o Clarified main output of EDHOC is the shared secret PRK_out 3800 o Exporter defined by EDHOC-KDF and new PRK PRK_exporter 3801 derived from PRK_out 3803 o Key update defined by Expand instead of Extract 3805 - All applications of EDHOC-KDF in one place 3807 - Update of processing 3809 o EAD and ID_CRED passed to application when available 3811 o identity verification and credential retrieval omitted in 3812 protocol description 3814 o Transcript hash defined by plaintext messages instead of 3815 ciphertext 3817 o Changed order of input to TH_2 3819 o Removed general G_X checking against selfie-attacks 3821 - Support for padding of plaintext 3823 - Updated compliance requirements 3825 - Updated security considerations 3827 o Updated and more clear requirements on MAC length 3829 o Clarification of key confirmation 3830 o Forbid use of same key for signature and static DH 3832 - Updated appendix on message deduplication 3834 - Clarifications of 3836 o connection identifiers 3838 o cipher suites, including negotiation 3840 o EAD 3842 o Error messages 3844 - Updated media types 3846 - Applicability template renamed application profile 3848 - Editorials 3850 * From -12 to -13 3852 - no changes 3854 * From -12: 3856 - Shortened labels to derive OSCORE key and salt 3858 - ead_value changed to bstr 3860 - Removed general G_X checking against selfie-attacks 3862 - Updated and more clear requirements on MAC length 3864 - Clarifications from Kathleen, Stephen, Marco, Sean, Stefan, 3866 - Authentication Related Verifications moved to appendix 3868 - Updated MTI section and cipher suite 3870 - Updated security considerations 3872 * From -11 to -12: 3874 - Clarified applicability to KEMs 3876 - Clarified use of COSE header parameters 3877 - Updates on MTI 3879 - Updated security considerations 3881 - New section on PQC 3883 - Removed duplicate definition of cipher suites 3885 - Explanations of use of COSE moved to Appendix C.3 3887 - Updated internal references 3889 * From -10 to -11: 3891 - Restructured section on authentication parameters 3893 - Changed UCCS to CCS 3895 - Changed names and description of COSE header parameters for 3896 CWT/CCS 3898 - Changed several of the KDF and Exporter labels 3900 - Removed edhoc_aead_id from info (already in transcript_hash) 3902 - Added MTI section 3904 - EAD: changed CDDL names and added value type to registry 3906 - Updated Figures 1, 2, and 3 3908 - Some correction and clarifications 3910 - Added core.edhoc to CoRE Resource Type registry 3912 * From -09 to -10: 3914 - SUITES_I simplified to only contain the selected and more 3915 preferred suites 3917 - Info is a CBOR sequence and context is a bstr 3919 - Added kid to UCCS example 3921 - Separate header parameters for CWT and UCCS 3923 - CWT Confirmation Method kid extended to bstr / int 3925 * From -08 to -09: 3927 - G_Y and CIPHERTEXT_2 are now included in one CBOR bstr 3929 - MAC_2 and MAC_3 are now generated with EDHOC-KDF 3931 - Info field "context" is now general and explicit in EDHOC-KDF 3933 - Restructured Section 4, Key Derivation 3935 - Added EDHOC MAC length to cipher suite for use with static DH 3937 - More details on the use of CWT and UCCS 3939 - Restructured and clarified Section 3.5, Authentication 3940 Parameters 3942 - Replaced 'kid2' with extension of 'kid' 3944 - EAD encoding now supports multiple ead types in one message 3946 - Clarified EAD type 3948 - Updated message sizes 3950 - Replaced "perfect forward secrecy" with "forward secrecy" 3952 - Updated security considerations 3954 - Replaced prepended 'null' with 'true' in the CoAP transport of 3955 message_1 3957 - Updated CDDL definitions 3959 - Expanded on the use of COSE 3961 * From -07 to -08: 3963 - Prepended C_x moved from the EDHOC protocol itself to the 3964 transport mapping 3966 - METHOD_CORR renamed to METHOD, corr removed 3968 - Removed bstr_identifier and use bstr / int instead; C_x can now 3969 be int without any implied bstr semantics 3971 - Defined COSE header parameter 'kid2' with value type bstr / int 3972 for use with ID_CRED_x 3974 - Updated message sizes 3976 - New cipher suites with AES-GCM and ChaCha20 / Poly1305 3978 - Changed from one- to two-byte identifier of CNSA compliant 3979 suite 3981 - Separate sections on transport and connection id with further 3982 sub-structure 3984 - Moved back key derivation for OSCORE from draft-ietf-core- 3985 oscore-edhoc 3987 - OSCORE and CoAP specific processing moved to new appendix 3989 - Message 4 section moved to message processing section 3991 * From -06 to -07: 3993 - Changed transcript hash definition for TH_2 and TH_3 3995 - Removed "EDHOC signature algorithm curve" from cipher suite 3997 - New IANA registry "EDHOC Exporter Label" 3999 - New application defined parameter "context" in EDHOC-Exporter 4001 - Changed normative language for failure from MUST to SHOULD send 4002 error 4004 - Made error codes non-negative and 0 for success 4006 - Added detail on success error code 4008 - Aligned terminology "protocol instance" -> "session" 4010 - New appendix on compact EC point representation 4012 - Added detail on use of ephemeral public keys 4014 - Moved key derivation for OSCORE to draft-ietf-core-oscore-edhoc 4016 - Additional security considerations 4018 - Renamed "Auxililary Data" as "External Authorization Data" 4020 - Added encrypted EAD_4 to message_4 4022 * From -05 to -06: 4024 - New section 5.2 "Message Processing Outline" 4026 - Optional inital byte C_1 = null in message_1 4028 - New format of error messages, table of error codes, IANA 4029 registry 4031 - Change of recommendation transport of error in CoAP 4033 - Merge of content in 3.7 and appendix C into new section 3.7 4034 "Applicability Statement" 4036 - Requiring use of deterministic CBOR 4038 - New section on message deduplication 4040 - New appendix containin all CDDL definitions 4042 - New appendix with change log 4044 - Removed section "Other Documents Referencing EDHOC" 4046 - Clarifications based on review comments 4048 * From -04 to -05: 4050 - EDHOC-Rekey-FS -> EDHOC-KeyUpdate 4052 - Clarification of cipher suite negotiation 4054 - Updated security considerations 4056 - Updated test vectors 4058 - Updated applicability statement template 4060 * From -03 to -04: 4062 - Restructure of section 1 4064 - Added references to C509 Certificates 4066 - Change in CIPHERTEXT_2 -> plaintext XOR KEYSTREAM_2 (test 4067 vector not updated) 4069 - "K_2e", "IV_2e" -> KEYSTREAM_2 4070 - Specified optional message 4 4072 - EDHOC-Exporter-FS -> EDHOC-Rekey-FS 4074 - Less constrained devices SHOULD implement both suite 0 and 2 4076 - Clarification of error message 4078 - Added exporter interface test vector 4080 * From -02 to -03: 4082 - Rearrangements of section 3 and beginning of section 4 4084 - Key derivation new section 4 4086 - Cipher suites 4 and 5 added 4088 - EDHOC-EXPORTER-FS - generate a new PRK_4x3m from an old one 4090 - Change in CIPHERTEXT_2 -> COSE_Encrypt0 without tag (no change 4091 to test vector) 4093 - Clarification of error message 4095 - New appendix C applicability statement 4097 * From -01 to -02: 4099 - New section 1.2 Use of EDHOC 4101 - Clarification of identities 4103 - New section 4.3 clarifying bstr_identifier 4105 - Updated security considerations 4107 - Updated text on cipher suite negotiation and key confirmation 4109 - Test vector for static DH 4111 * From -00 to -01: 4113 - Removed PSK method 4115 - Removed references to certificate by value 4117 Acknowledgments 4119 The authors want to thank Christian Amsuess, Alessandro Bruni, 4120 Karthikeyan Bhargavan, Carsten Bormann, Timothy Claeys, Martin Disch, 4121 Stephen Farrell, Loic Ferreira, Theis Groenbech Petersen, Felix 4122 Guenther, Dan Harkins, Klaus Hartke, Russ Housley, Stefan Hristozov, 4123 Marc Ilunga, Charlie Jacomme, Elise Klein, Steve Kremer, Alexandros 4124 Krontiris, Ilari Liusvaara, Kathleen Moriarty, David Navarro, Karl 4125 Norrman, Salvador Perez, Maiwenn Racouchot, Eric Rescorla, Michael 4126 Richardson, Thorvald Sahl Joergensen, Jim Schaad, Carsten Schuermann, 4127 Ludwig Seitz, Stanislav Smyshlyaev, Valery Smyslov, Peter van der 4128 Stok, Rene Struik, Vaishnavi Sundararajan, Erik Thormarker, Marco 4129 Tiloca, Sean Turner, Michel Veillette, and Malisa Vučinić 4130 for reviewing and commenting on intermediate versions of the draft. 4131 We are especially indebted to Jim Schaad for his continuous reviewing 4132 and implementation of different versions of the draft. 4134 Work on this document has in part been supported by the H2020 project 4135 SIFIS-Home (grant agreement 952652). 4137 Authors' Addresses 4139 Göran Selander 4140 Ericsson AB 4141 SE-164 80 Stockholm 4142 Sweden 4143 Email: goran.selander@ericsson.com 4145 John Preuß Mattsson 4146 Ericsson AB 4147 SE-164 80 Stockholm 4148 Sweden 4149 Email: john.mattsson@ericsson.com 4151 Francesca Palombini 4152 Ericsson AB 4153 SE-164 80 Stockholm 4154 Sweden 4155 Email: francesca.palombini@ericsson.com