idnits 2.17.1 draft-ietf-lake-edhoc-11.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2546): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2649): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2670): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2693): 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 9 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 (24 September 2021) is 945 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 1869 -- Looks like a reference, but probably isn't: '6' on line 1869 -- Looks like a reference, but probably isn't: '9' on line 1865 -- Looks like a reference, but probably isn't: '8' on line 1869 -- Looks like a reference, but probably isn't: '7' on line 1869 == Missing Reference: 'RFC9052' is mentioned on line 2397, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-13 ** 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-01 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-02 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-security-protocol-comparison-05 == Outdated reference: A later version (-04) exists of draft-mattsson-cfrg-det-sigs-with-noise-02 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-03 == Outdated reference: A later version (-02) exists of draft-selander-lake-traces-00 Summary: 7 errors (**), 0 flaws (~~), 11 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: 28 March 2022 Ericsson 6 24 September 2021 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-ietf-lake-edhoc-11 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 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Discussion of this document takes place on the Lightweight 27 Authenticated Key Exchange Working Group mailing list 28 (lake@ietf.org), which is archived at 29 https://mailarchive.ietf.org/arch/browse/lake/. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/lake-wg/edhoc. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 28 March 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5 69 1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 6 70 1.4. Document Structure . . . . . . . . . . . . . . . . . . . 6 71 1.5. Terminology and Requirements Language . . . . . . . . . . 6 72 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.3. Connection Identifiers . . . . . . . . . . . . . . . . . 10 77 3.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.5. Authentication Parameters . . . . . . . . . . . . . . . . 12 79 3.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 18 80 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 20 81 3.8. External Authorization Data (EAD) . . . . . . . . . . . . 20 82 3.9. Applicability Statement . . . . . . . . . . . . . . . . . 21 83 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 23 84 4.1. Extract . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 4.2. Expand . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 4.3. EDHOC-Exporter . . . . . . . . . . . . . . . . . . . . . 26 87 4.4. EDHOC-KeyUpdate . . . . . . . . . . . . . . . . . . . . . 27 88 5. Message Formatting and Processing . . . . . . . . . . . . . . 27 89 5.1. Message Processing Outline . . . . . . . . . . . . . . . 27 90 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 28 91 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 30 92 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 32 93 5.5. EDHOC Message 4 . . . . . . . . . . . . . . . . . . . . . 36 94 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 38 95 6.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 39 96 6.2. Unspecified . . . . . . . . . . . . . . . . . . . . . . . 39 97 6.3. Wrong Selected Cipher Suite . . . . . . . . . . . . . . . 39 98 7. Mandatory-to-Implement Compliance Requirements . . . . . . . 41 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 100 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 42 101 8.2. Cryptographic Considerations . . . . . . . . . . . . . . 45 102 8.3. Cipher Suites and Cryptographic Algorithms . . . . . . . 45 103 8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 46 104 8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 46 105 8.6. Implementation Considerations . . . . . . . . . . . . . . 46 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 107 9.1. EDHOC Exporter Label Registry . . . . . . . . . . . . . . 48 108 9.2. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 49 109 9.3. EDHOC Method Type Registry . . . . . . . . . . . . . . . 51 110 9.4. EDHOC Error Codes Registry . . . . . . . . . . . . . . . 51 111 9.5. EDHOC External Authorization Data Registry . . . . . . . 51 112 9.6. COSE Header Parameters Registry . . . . . . . . . . . . . 51 113 9.7. COSE Header Parameters Registry . . . . . . . . . . . . . 52 114 9.8. COSE Key Common Parameters Registry . . . . . . . . . . . 52 115 9.9. CWT Confirmation Methods Registry . . . . . . . . . . . . 53 116 9.10. The Well-Known URI Registry . . . . . . . . . . . . . . . 53 117 9.11. Media Types Registry . . . . . . . . . . . . . . . . . . 53 118 9.12. CoAP Content-Formats Registry . . . . . . . . . . . . . . 54 119 9.13. Resource Type (rt=) Link Target Attribute Values 120 Registry . . . . . . . . . . . . . . . . . . . . . . . . 55 121 9.14. Expert Review Instructions . . . . . . . . . . . . . . . 55 122 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 123 10.1. Normative References . . . . . . . . . . . . . . . . . . 55 124 10.2. Informative References . . . . . . . . . . . . . . . . . 58 125 Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 61 126 A.1. Selecting EDHOC Connection Identifier . . . . . . . . . . 61 127 A.2. Deriving the OSCORE Security Context . . . . . . . . . . 62 128 A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 63 129 Appendix B. Compact Representation . . . . . . . . . . . . . . . 66 130 Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 66 131 C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 67 132 C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 68 133 C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 69 134 Appendix D. Applicability Template . . . . . . . . . . . . . . . 71 135 Appendix E. EDHOC Message Deduplication . . . . . . . . . . . . 72 136 Appendix F. Transports Not Natively Providing Correlation . . . 73 137 Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 73 138 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 78 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 141 1. Introduction 143 1.1. Motivation 145 Many Internet of Things (IoT) deployments require technologies which 146 are highly performant in constrained environments [RFC7228]. IoT 147 devices may be constrained in various ways, including memory, 148 storage, processing capacity, and power. The connectivity for these 149 settings may also exhibit constraints such as unreliable and lossy 150 channels, highly restricted bandwidth, and dynamic topology. The 151 IETF has acknowledged this problem by standardizing a range of 152 lightweight protocols and enablers designed for the IoT, including 153 the Constrained Application Protocol (CoAP, [RFC7252]), Concise 154 Binary Object Representation (CBOR, [RFC8949]), and Static Context 155 Header Compression (SCHC, [RFC8724]). 157 The need for special protocols targeting constrained IoT deployments 158 extends also to the security domain [I-D.ietf-lake-reqs]. Important 159 characteristics in constrained environments are the number of round 160 trips and protocol message sizes, which if kept low can contribute to 161 good performance by enabling transport over a small number of radio 162 frames, reducing latency due to fragmentation or duty cycles, etc. 163 Another important criteria is code size, which may be prohibitive for 164 certain deployments due to device capabilities or network load during 165 firmware update. Some IoT deployments also need to support a variety 166 of underlying transport technologies, potentially even with a single 167 connection. 169 Some security solutions for such settings exist already. CBOR Object 170 Signing and Encryption (COSE, [I-D.ietf-cose-rfc8152bis-struct]) 171 specifies basic application-layer security services efficiently 172 encoded in CBOR. Another example is Object Security for Constrained 173 RESTful Environments (OSCORE, [RFC8613]) which is a lightweight 174 communication security extension to CoAP using CBOR and COSE. In 175 order to establish good quality cryptographic keys for security 176 protocols such as COSE and OSCORE, the two endpoints may run an 177 authenticated Diffie-Hellman key exchange protocol, from which shared 178 secret key material can be derived. Such a key exchange protocol 179 should also be lightweight; to prevent bad performance in case of 180 repeated use, e.g., due to device rebooting or frequent rekeying for 181 security reasons; or to avoid latencies in a network formation 182 setting with many devices authenticating at the same time. 184 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 185 lightweight authenticated key exchange protocol providing good 186 security properties including forward secrecy, identity protection, 187 and cipher suite negotiation. Authentication can be based on raw 188 public keys (RPK) or public key certificates and requires the 189 application to provide input on how to verify that endpoints are 190 trusted. This specification focuses on referencing instead of 191 transporting credentials to reduce message overhead. EDHOC does 192 currently not support pre-shared key (PSK) authentication as 193 authentication with static Diffie-Hellman public keys by reference 194 produces equally small message sizes but with much simpler key 195 distribution and identity protection. 197 EDHOC makes use of known protocol constructions, such as SIGMA 198 [SIGMA] and Extract-and-Expand [RFC5869]. EDHOC uses COSE for 199 cryptography and identification of credentials (including COSE_Key, 200 CWT, CCS, X.509, C509, see Section 3.5.3). COSE provides crypto 201 agility and enables the use of future algorithms and credentials 202 targeting IoT. 204 1.2. Use of EDHOC 206 EDHOC is designed for highly constrained settings making it 207 especially suitable for low-power wide area networks [RFC8376] such 208 as Cellular IoT, 6TiSCH, and LoRaWAN. A main objective for EDHOC is 209 to be a lightweight authenticated key exchange for OSCORE, i.e., to 210 provide authentication and session key establishment for IoT use 211 cases such as those built on CoAP [RFC7252]. CoAP is a specialized 212 web transfer protocol for use with constrained nodes and networks, 213 providing a request/response interaction model between application 214 endpoints. As such, EDHOC is targeting a large variety of use cases 215 involving 'things' with embedded microcontrollers, sensors, and 216 actuators. 218 A typical setting is when one of the endpoints is constrained or in a 219 constrained network, and the other endpoint is a node on the Internet 220 (such as a mobile phone) or at the edge of the constrained network 221 (such as a gateway). Thing-to-thing interactions over constrained 222 networks are also relevant since both endpoints would then benefit 223 from the lightweight properties of the protocol. EDHOC could e.g., 224 be run when a device connects for the first time, or to establish 225 fresh keys which are not revealed by a later compromise of the long- 226 term keys. Further security properties are described in Section 8.1. 228 EDHOC enables the reuse of the same lightweight primitives as OSCORE: 229 CBOR for encoding, COSE for cryptography, and CoAP for transport. By 230 reusing existing libraries, the additional code size can be kept very 231 low. Note that, while CBOR and COSE primitives are built into the 232 protocol messages, EDHOC is not bound to a particular transport. 233 Transfer of EDHOC messages in CoAP payloads is detailed in 234 Appendix A.3. 236 1.3. Message Size Examples 238 Compared to the DTLS 1.3 handshake [I-D.ietf-tls-dtls13] with ECDHE 239 and connection ID, the number of bytes in EDHOC + CoAP can be less 240 than 1/6 when RPK authentication is used, see 241 [I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows 242 examples of message sizes for EDHOC with different kinds of 243 authentication keys and different COSE header parameters for 244 identification: static Diffie-Hellman keys or signature keys, either 245 in CBOR Web Token (CWT) / CWT Claims Set (CCS) [RFC8392] identified 246 by a key identifier using 'kid' [I-D.ietf-cose-rfc8152bis-struct], or 247 in X.509 certificates identified by a hash value using 'x5t' 248 [I-D.ietf-cose-x509]. 250 ======================================================== 251 Static DH Keys Signature Keys 252 -------------- -------------- 253 kid x5t kid x5t 254 -------------------------------------------------------- 255 message_1 37 37 37 37 256 message_2 45 58 102 115 257 message_3 19 33 77 90 258 -------------------------------------------------------- 259 Total 101 128 216 242 260 ======================================================== 262 Figure 1: Example of message sizes in bytes. 264 1.4. Document Structure 266 The remainder of the document is organized as follows: Section 2 267 outlines EDHOC authenticated with digital signatures, Section 3 268 describes the protocol elements of EDHOC, including formatting of the 269 ephemeral public keys, Section 4 specifies the key derivation, 270 Section 5 specifies message processing for EDHOC authenticated with 271 signature keys or static Diffie-Hellman keys, Section 6 describes the 272 error messages, and Appendix A shows how to transfer EDHOC with CoAP 273 and establish an OSCORE security context. 275 1.5. Terminology and Requirements Language 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 279 "OPTIONAL" in this document are to be interpreted as described in BCP 280 14 [RFC2119] [RFC8174] when, and only when, they appear in all 281 capitals, as shown here. 283 Readers are expected to be familiar with the terms and concepts 284 described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE 285 structures and processing [I-D.ietf-cose-rfc8152bis-struct], COSE 286 algorithms [I-D.ietf-cose-rfc8152bis-algs], CWT and CWT Claims Set 287 [RFC8392], and CDDL [RFC8610]. The Concise Data Definition Language 288 (CDDL) is used to express CBOR data structures [RFC8949]. Examples 289 of CBOR and CDDL are provided in Appendix C.1. When referring to 290 CBOR, this specification always refers to Deterministically Encoded 291 CBOR as specified in Sections 4.2.1 and 4.2.2 of [RFC8949]. The 292 single output from authenticated encryption (including the 293 authentication tag) is called "ciphertext", following [RFC5116]. 295 2. EDHOC Outline 297 EDHOC specifies different authentication methods of the Diffie- 298 Hellman key exchange: digital signatures and static Diffie-Hellman 299 keys. This section outlines the digital signature-based method. 300 Further details of protocol elements and other authentication methods 301 are provided in the remainder of this document. 303 SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a 304 large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS 305 1.3 [RFC8446], EDHOC authenticated with digital signatures is built 306 on a variant of the SIGMA protocol which provides identity protection 307 of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC 308 implements the MAC-then-Sign variant of the SIGMA-I protocol shown in 309 Figure 2. 311 Initiator Responder 312 | G_X | 313 +------------------------------------------------------------------>| 314 | | 315 | G_Y, Enc( ID_CRED_R, Sig( R; MAC( CRED_R, G_X, G_Y ) ) ) | 316 |<------------------------------------------------------------------+ 317 | | 318 | AEAD( ID_CRED_I, Sig( I; MAC( CRED_I, G_Y, G_X ) ) ) | 319 +------------------------------------------------------------------>| 320 | | 322 Figure 2: MAC-then-Sign variant of the SIGMA-I protocol. 324 The parties exchanging messages are called Initiator (I) and 325 Responder (R). They exchange ephemeral public keys, compute a shared 326 secret, and derive symmetric application keys used to protect 327 application data. 329 * G_X and G_Y are the ECDH ephemeral public keys of I and R, 330 respectively. 332 * CRED_I and CRED_R are the credentials containing the public 333 authentication keys of I and R, respectively. 335 * ID_CRED_I and ID_CRED_R are credential identifiers enabling the 336 recipient party to retrieve the credential of I and R, 337 respectively. 339 * Sig(I; . ) and Sig(R; . ) denote signatures made with the private 340 authentication key of I and R, respectively. 342 * Enc(), AEAD(), and MAC() denotes encryption, authenticated 343 encryption with additional data, and message authentication code 344 using keys derived from the shared secret. 346 In order to create a "full-fledged" protocol some additional protocol 347 elements are needed. EDHOC adds: 349 * Transcript hashes (hashes of message data) TH_2, TH_3, TH_4 used 350 for key derivation and as additional authenticated data. 352 * Computationally independent keys derived from the ECDH shared 353 secret and used for authenticated encryption of different 354 messages. 356 * An optional fourth message giving explicit key confirmation to I 357 in deployments where no protected application data is sent from R 358 to I. 360 * A key material exporter and a key update function enabling forward 361 secrecy. 363 * Verification of a common preferred cipher suite. 365 * Method types and error handling. 367 * Selection of connection identifiers C_I and C_R which may be used 368 to identify established keys or protocol state. 370 * Transport of external authorization data. 372 EDHOC is designed to encrypt and integrity protect as much 373 information as possible, and all symmetric keys are derived using as 374 much previous information as possible. EDHOC is furthermore designed 375 to be as compact and lightweight as possible, in terms of message 376 sizes, processing, and the ability to reuse already existing CBOR, 377 COSE, and CoAP libraries. 379 To simplify for implementors, the use of CBOR and COSE in EDHOC is 380 summarized in Appendix C. Test vectors including CBOR diagnostic 381 notation are provided in [I-D.selander-lake-traces]. 383 3. Protocol Elements 385 3.1. General 387 The EDHOC protocol consists of three mandatory messages (message_1, 388 message_2, message_3) between Initiator and Responder, an optional 389 fourth message (message_4), and an error message. All EDHOC messages 390 are CBOR Sequences [RFC8742]. Figure 3 illustrates an EDHOC message 391 flow with the optional fourth message as well as the content of each 392 message. The protocol elements in the figure are introduced in 393 Section 3 and Section 5. Message formatting and processing is 394 specified in Section 5 and Section 6. 396 Application data may be protected using the agreed application 397 algorithms (AEAD, hash) in the selected cipher suite (see 398 Section 3.6) and the application can make use of the established 399 connection identifiers C_I and C_R (see Section 3.3). EDHOC may be 400 used with the media type application/edhoc defined in Section 9. 402 The Initiator can derive symmetric application keys after creating 403 EDHOC message_3, see Section 4.3. Protected application data can 404 therefore be sent in parallel or together with EDHOC message_3. 405 EDHOC message_4 is typically not sent. 407 Initiator Responder 408 | METHOD, SUITES_I, G_X, C_I, EAD_1 | 409 +------------------------------------------------------------------>| 410 | message_1 | 411 | | 412 | G_Y, Enc( ID_CRED_R, Signature_or_MAC_2, EAD_2 ), C_R | 413 |<------------------------------------------------------------------+ 414 | message_2 | 415 | | 416 | AEAD( ID_CRED_I, Signature_or_MAC_3, EAD_3 ) | 417 +------------------------------------------------------------------>| 418 | message_3 | 419 | | 420 | AEAD( EAD_4 ) | 421 |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 422 | message_4 | 424 Figure 3: EDHOC Message Flow with the Optional Fourth Message 426 3.2. Method 428 The data item METHOD in message_1 (see Section 5.2.1), is an integer 429 specifying the authentication method. EDHOC supports authentication 430 with signature or static Diffie-Hellman keys, as defined in the four 431 authentication methods: 0, 1, 2, and 3, see Figure 4. When using a 432 static Diffie-Hellman key the authentication is provided by a Message 433 Authentication Code (MAC) computed from an ephemeral-static ECDH 434 shared secret which enables significant reductions in message sizes. 436 The Initiator and the Responder need to have agreed on a single 437 method to be used for EDHOC, see Section 3.9. 439 +-------+-------------------+-------------------+-------------------+ 440 | Value | Initiator | Responder | Reference | 441 +-------+-------------------+-------------------+-------------------+ 442 | 0 | Signature Key | Signature Key | [[this document]] | 443 | 1 | Signature Key | Static DH Key | [[this document]] | 444 | 2 | Static DH Key | Signature Key | [[this document]] | 445 | 3 | Static DH Key | Static DH Key | [[this document]] | 446 +-------+-------------------+-------------------+-------------------+ 448 Figure 4: Method Types 450 3.3. Connection Identifiers 452 EDHOC includes the selection of connection identifiers (C_I, C_R) 453 identifying a connection for which keys are agreed. 455 Connection identifiers may be used to correlate EDHOC messages and 456 facilitate the retrieval of protocol state during EDHOC protocol 457 execution (see Section 3.4) or in a subsequent application protocol, 458 e.g., OSCORE (see Section 3.3.2). The connection identifiers do not 459 have any cryptographic purpose in EDHOC. 461 Connection identifiers in EDHOC are byte strings or integers, encoded 462 in CBOR. One byte connection identifiers (the integers -24 to 23 and 463 the empty CBOR byte string h'') are realistic in many scenarios as 464 most constrained devices only have a few connections. 466 3.3.1. Selection of Connection Identifiers 468 C_I and C_R are chosen by I and R, respectively. The Initiator 469 selects C_I and sends it in message_1 for the Responder to use as a 470 reference to the connection in communications with the Initiator. 471 The Responder selects C_R and sends in message_2 for the Initiator to 472 use as a reference to the connection in communications with the 473 Responder. 475 If connection identifiers are used by an application protocol for 476 which EDHOC establishes keys then the selected connection identifiers 477 SHALL adhere to the requirements for that protocol, see Section 3.3.2 478 for an example. 480 3.3.2. Use of Connection Identifiers with OSCORE 482 For OSCORE, the choice of a connection identifier results in the 483 endpoint selecting its Recipient ID, see Section 3.1 of [RFC8613], 484 for which certain uniqueness requirements apply, see Section 3.3 of 485 [RFC8613]. Therefore, the Initiator and the Responder MUST NOT 486 select connection identifiers such that it results in same OSCORE 487 Recipient ID. Since the Recipient ID is a byte string and a EDHOC 488 connection identifier is either a CBOR byte string or a CBOR integer, 489 care must be taken when selecting the connection identifiers and 490 converting them to Recipient IDs. A mapping from EDHOC connection 491 identifier to OSCORE Recipient ID is specified in Appendix A.1. 493 3.4. Transport 495 Cryptographically, EDHOC does not put requirements on the lower 496 layers. EDHOC is not bound to a particular transport layer and can 497 even be used in environments without IP. The transport is 498 responsible, where necessary, to handle: 500 * message loss, 502 * message reordering, 504 * message duplication, 506 * fragmentation, 508 * demultiplex EDHOC messages from other types of messages, 510 * denial-of-service protection, 512 * message correlation. 514 The Initiator and the Responder need to have agreed on a transport to 515 be used for EDHOC, see Section 3.9. 517 3.4.1. Use of Connection Identifiers for EDHOC Message Correlation 519 The transport needs to support the correlation between EDHOC messages 520 and facilitate the retrieval of protocol state during EDHOC protocol 521 execution, including an indication of a message being message_1. The 522 correlation may reuse existing mechanisms in the transport protocol. 523 For example, the CoAP Token may be used to correlate EDHOC messages 524 in a CoAP response and an associated CoAP request. 526 Connection identifiers may be used to correlate EDHOC messages and 527 facilitate the retrieval of protocol state during EDHOC protocol 528 execution. EDHOC transports that do not inherently provide 529 correlation across all messages of an exchange can send connection 530 identifiers along with EDHOC messages to gain that required 531 capability, e.g., by prepending the appropriate connection identifier 532 (when available from the EDHOC protocol) to the EDHOC message. 533 Transport of EDHOC in CoAP payloads is described in Appendix A.3, 534 which also shows how to use connection identifiers and message_1 535 indication with CoAP. 537 3.5. Authentication Parameters 539 EDHOC supports various settings for how the other endpoint's 540 authentication (public) key is transported, identified, and trusted 541 as described in this section. 543 The authentication key (see Section 3.5.2) is used in several parts 544 of EDHOC: 546 1. as part of the authentication credential included in the 547 integrity calculation 549 2. for verification of the Signature_or_MAC field in message_2 and 550 message_3 (see Section 5.3.2 and Section 5.4.2) 552 3. in the key derivation (in case of a static Diffie-Hellman key, 553 see Section 4). 555 The authentication credential (CRED_x) contains, in addition to the 556 authentication key, also the authentication key algorithm and 557 optionally other parameters such as identity, key usage, expiry, 558 issuer, etc. (see Section 3.5.3). Identical authentication 559 credentials need to be established in both endpoints to be able to 560 verify integrity. For many settings it is not necessary to transport 561 the authentication credential within EDHOC over constrained links, 562 for example, it may be pre-provisioned or acquired out-of-band over 563 less constrained links. 565 EDHOC relies on COSE for identification of authentication credentials 566 (using ID_CRED_x, see Section 3.5.4) and supports all credential 567 types for which COSE header parameters are defined (see 568 Section 3.5.3). 570 The choice of authentication credential depends also on the trust 571 model (see Section 3.5.1). For example, a certificate or CWT may 572 rely on a trusted third party, whereas a CCS or a self-signed 573 certificate/CWT may be used when trust in the public key can be 574 achieved by other means, or in the case of trust-on-first-use. 576 The type of authentication key, authentication credential, and the 577 way to identify the credential have a large impact on the message 578 size. For example, the signature_or_MAC field is much smaller with a 579 static DH key than with a signature key. A CCS is much smaller than 580 a self-signed certificate/CWT, but if it is possible to reference the 581 credential with a COSE header like 'kid', then that is typically much 582 smaller than to transport a CCS. 584 3.5.1. Identities and trust anchors 586 Policies for what connections to allow are typically set based on the 587 identity of the other party, and parties typically only allow 588 connections from a specific identity or a small restricted set of 589 identities. For example, in the case of a device connecting to a 590 network, the network may only allow connections from devices which 591 authenticate with certificates having a particular range of serial 592 numbers and signed by a particular CA. On the other hand, the device 593 may only be allowed to connect to a network which authenticates with 594 a particular public key (information of which may be provisioned, 595 e.g., out of band or in the external authorization data, see 596 Section 3.8). The EDHOC implementation or the application must 597 enforce information about the intended endpoint, and in particular 598 whether it is a specific identity or a set of identities. Either 599 EDHOC passes information about identity to the application for a 600 decision, or EDHOC needs to have access to relevant information and 601 makes the decision on its own. 603 EDHOC assumes the existence of mechanisms (certification authority, 604 trusted third party, pre-provisioning, etc.) for specifying and 605 distributing authentication credentials. 607 * When a Public Key Infrastructure (PKI) is used with certificates, 608 the trust anchor is a Certification Authority (CA) certificate, 609 and the identity is the subject whose unique name (e.g., a domain 610 name, NAI, or EUI) is included in the endpoint's certificate. In 611 order to run EDHOC each party needs at least one CA public key 612 certificate, or just the public key, and a specific identity or 613 set of identities it is allowed to communicate with. Only 614 validated public-key certificates with an allowed subject name, as 615 specified by the application, are to be accepted. EDHOC provides 616 proof that the other party possesses the private authentication 617 key corresponding to the public authentication key in its 618 certificate. The certification path provides proof that the 619 subject of the certificate owns the public key in the certificate. 621 * Similarly, when a PKI is used with CWTs, each party needs to have 622 a trusted third party public key as trust anchor to verify the 623 end-entity CWTs, and a specific identity or set of identities in 624 the 'sub' (subject) claim of the CWT to determine if it is allowed 625 to communicate with. The trusted third party public key can, 626 e.g., be stored in a self-signed CWT or in a CCS. 628 * When PKI is not used (CCS, self-signed certificate/CWT), the trust 629 anchor is the authentication key of the other party. In this 630 case, the identity is typically directly associated to the 631 authentication key of the other party. For example, the name of 632 the subject may be a canonical representation of the public key. 633 Alternatively, if identities can be expressed in the form of 634 unique subject names assigned to public keys, then a binding to 635 identity can be achieved by including both public key and 636 associated subject name in the protocol message computation: 637 CRED_I or CRED_R may be a self-signed certificate/CWT or CCS 638 containing the authentication key and the subject name, see 639 Section 3.5.3. In order to run EDHOC, each endpoint needs a 640 specific authentication key/unique associated subject name, or a 641 set of public authentication keys/unique associated subject names, 642 which it is allowed to communicate with. EDHOC provides the proof 643 that the other party possesses the private authentication key 644 corresponding to the public authentication key. 646 To prevent misbinding attacks in systems where an attacker can 647 register public keys without proving knowledge of the private key, 648 SIGMA [SIGMA] enforces a MAC to be calculated over the "identity". 649 EDHOC follows SIGMA by calculating a MAC over the whole credential, 650 which in case of a X.509 or C509 certificate includes the "subject" 651 and "subjectAltName" fields, and in the case of CWT or CCS includes 652 the "sub" claim. While the SIGMA paper only focuses on the identity, 653 the same principle is true for other information such as policies 654 associated to the public key. 656 3.5.2. Authentication Keys 658 The authentication key (i.e. the public key used for authentication) 659 MUST be a signature key or static Diffie-Hellman key. The Initiator 660 and the Responder MAY use different types of authentication keys, 661 e.g., one uses a signature key and the other uses a static Diffie- 662 Hellman key. The authentication key algorithm needs to be compatible 663 with the method and the cipher suite. The authentication key 664 algorithm needs to be compatible with the EDHOC key exchange 665 algorithm when static Diffie-Hellman authentication is used and 666 compatible with the EDHOC signature algorithm when signature 667 authentication is used. 669 Note that for most signature algorithms, the signature is determined 670 by the signature algorithm and the authentication key algorithm 671 together. When using static Diffie-Hellman keys the Initiator's and 672 Responder's private authentication keys are called I and R, 673 respectively, and the public authentication keys are called G_I and 674 G_R, respectively. 676 For X.509 the authentication key is represented with a 677 SubjectPublicKeyInfo field. For CWT and CCS, the authentication key 678 is represented with a 'cnf' claim [RFC8747] containing a COSE_Key 679 [I-D.ietf-cose-rfc8152bis-struct]. 681 3.5.3. Authentication Credentials 683 The authentication credentials, CRED_I and CRED_R, contain the public 684 authentication key of the Initiator and the Responder, respectively. 686 EDHOC relies on COSE for identification of authentication credentials 687 (see Section 3.5.4) and supports all credential types for which COSE 688 header parameters are defined including X.509 [RFC5280], C509 689 [I-D.ietf-cose-cbor-encoded-cert], CWT [RFC8392] and CWT Claims Set 690 (CCS) [RFC8392]. When the identified credential is a chain or bag, 691 CRED_x is just the end-entity X.509 or C509 certificate / CWT. In 692 X.509 and C509 certificates, signature keys typically have key usage 693 "digitalSignature" and Diffie-Hellman public keys typically have key 694 usage "keyAgreement". 696 CRED_x needs to be defined such that it is identical when used by 697 Initiator or Responder. The Initiator and Responder are expected to 698 agree on a specific encoding of the credential, see Section 3.9. It 699 is RECOMMENDED that the COSE 'kid' parameter, when used, refers to a 700 specific encoding. The Initiator and Responder SHOULD use an 701 available authentication credential (transported in EDHOC or 702 otherwise provisioned) without re-encoding. If for some reason re- 703 encoding of the authentication credential may occur, then a potential 704 common encoding for CBOR based credentials is bytewise lexicographic 705 order of their deterministic encodings as specified in Section 4.2.1 706 of [RFC8949]. 708 * When the authentication credential is a X.509 certificate, CRED_x 709 SHALL be the end-entity DER encoded certificate wrapped in a bstr 710 [I-D.ietf-cose-x509]. 712 * When the authentication credential is a C509 certificate, CRED_x 713 SHALL be the end-entity C509Certificate 714 [I-D.ietf-cose-cbor-encoded-cert] 716 * When the authentication credential is a COSE_Key in a CWT, CRED_x 717 SHALL be the untagged CWT. 719 * When the authentication credential is a COSE_Key but not in a CWT, 720 CRED_x SHALL be an untagged CCS. * Naked COSE_Keys are thus 721 dressed as CCS when used in EDHOC, which is done by prefixing the 722 COSE_Key with 0xA108A101. 724 An example of a CRED_x is shown below: 726 { /CCS/ 727 2 : "42-50-31-FF-EF-37-32-39", /sub/ 728 8 : { /cnf/ 729 1 : { /COSE_Key/ 730 1 : 1, /kty/ 731 2 : 0, /kid/ 732 -1 : 4, /crv/ 733 -2 : h'b1a3e89460e88d3a8d54211dc95f0b90 /x/ 734 3ff205eb71912d6db8f4af980d2db83a' 735 } 736 } 737 } 739 Figure 5: A CCS Containing an X25519 Static Diffie-Hellman Key 740 and an EUI-64 Identity. 742 3.5.4. Identification of Credentials 744 ID_CRED_R and ID_CRED_I are transported in message_2 and message_3, 745 respectively (see Section 5.3.2 and Section 5.4.2). They are used to 746 identify and optionally transport the authentication keys of the 747 Initiator and the Responder, respectively. ID_CRED_I and ID_CRED_R 748 do not have any cryptographic purpose in EDHOC since EDHOC integrity 749 protects the authentication credential. EDHOC relies on COSE for 750 identification of authentication credentials and supports all COSE 751 header parameters used to identify authentication credentials 752 including X.509, C509, CWT and CCS. 754 * ID_CRED_R is intended to facilitate for the Initiator to retrieve 755 the Responder's authentication key. 757 * ID_CRED_I is intended to facilitate for the Responder to retrieve 758 the Initiator's authentication key. 760 ID_CRED_I and ID_CRED_R are COSE header maps and contains one or more 761 COSE header parameter. ID_CRED_I and ID_CRED_R MAY contain different 762 header parameters. The header parameters typically provide some 763 information about the format of authentication credential. 765 Example: X.509 certificates can be identified by a hash value using 766 the 'x5t' parameter: 768 * ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, 770 Example: CWT or CCS can be identified by a key identifier using the 771 'kid' parameter: 773 * ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or 774 R. 776 Note that 'kid' is extended to support int values to allow more one- 777 byte identifiers (see Section 9.7 and Section 9.8) which may be 778 useful in many scenarios since constrained devices only have a few 779 keys. As stated in Section 3.1 of [I-D.ietf-cose-rfc8152bis-struct], 780 applications MUST NOT assume that 'kid' values are unique and several 781 keys associated with a 'kid' may need to be checked before the 782 correct one is found. Applications might use additional information 783 such as 'kid context' or lower layers to determine which key to try 784 first. Applications should strive to make ID_CRED_x as unique as 785 possible, since the recipient may otherwise have to try several keys. 787 See Appendix C.3 for more examples. 789 3.6. Cipher Suites 791 An EDHOC cipher suite consists of an ordered set of algorithms from 792 the "COSE Algorithms" and "COSE Elliptic Curves" registries as well 793 as the EDHOC MAC length. Algorithms need to be specified with enough 794 parameters to make them completely determined. EDHOC is only 795 specified for use with key exchange algorithms of type ECDH curves. 796 Use with other types of key exchange algorithms would likely require 797 a specification updating EDHOC. Note that for most signature 798 algorithms, the signature is determined by the signature algorithm 799 and the authentication key algorithm together, see Section 3.5.2. 800 The authentication key algorithm needs to be compatible with the 801 EDHOC key exchange algorithm when static Diffie-Hellman 802 authentication is used and compatible with the EDHOC signature 803 algorithm when signature authentication is used. 805 * EDHOC AEAD algorithm 807 * EDHOC hash algorithm 809 * EDHOC MAC length in bytes (Static DH) 811 * EDHOC key exchange algorithm (ECDH curve) 813 * EDHOC signature algorithm 815 * Application AEAD algorithm 817 * Application hash algorithm 819 Each cipher suite is identified with a pre-defined int label. 821 EDHOC can be used with all algorithms and curves defined for COSE. 822 Implementation can either use one of the pre-defined cipher suites 823 (Section 9.2) or use any combination of COSE algorithms and 824 parameters to define their own private cipher suite. Private cipher 825 suites can be identified with any of the four values -24, -23, -22, 826 -21. 828 The following CCM cipher suites are for constrained IoT where message 829 overhead is a very important factor. Cipher suites 1 and 3 use a 830 larger tag length (128-bit) in EDHOC than in the Application AEAD 831 algorithm (64-bit): 833 0. ( 10, -16, 8, 4, -8, 10, -16 ) 834 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, 835 AES-CCM-16-64-128, SHA-256) 837 1. ( 30, -16, 16, 4, -8, 10, -16 ) 838 (AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, 839 AES-CCM-16-64-128, SHA-256) 841 2. ( 10, -16, 8, 1, -7, 10, -16 ) 842 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, 843 AES-CCM-16-64-128, SHA-256) 845 3. ( 30, -16, 16, 1, -7, 10, -16 ) 846 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, 847 AES-CCM-16-64-128, SHA-256) 849 The following ChaCha20 cipher suites are for less constrained 850 applications and only use 128-bit tag lengths. 852 4. ( 24, -16, 16, 4, -8, 24, -16 ) 853 (ChaCha20/Poly1305, SHA-256, 16, X25519, EdDSA, 854 ChaCha20/Poly1305, SHA-256) 856 5. ( 24, -16, 16, 1, -7, 24, -16 ) 857 (ChaCha20/Poly1305, SHA-256, 16, P-256, ES256, 858 ChaCha20/Poly1305, SHA-256) 860 The following GCM cipher suite is for general non-constrained 861 applications. It uses high performance algorithms that are widely 862 supported: 864 6. ( 1, -16, 16, 4, -7, 1, -16 ) 865 (A128GCM, SHA-256, 16, X25519, ES256, 866 A128GCM, SHA-256) 868 The following two cipher suites are for high security application 869 such as government use and financial applications. The two cipher 870 suites do not share any algorithms. The first of the two cipher 871 suites is compatible with the CNSA suite [CNSA]. 873 24. ( 3, -43, 16, 2, -35, 3, -43 ) 874 (A256GCM, SHA-384, 16, P-384, ES384, 875 A256GCM, SHA-384) 877 25. ( 24, -45, 16, 5, -8, 24, -45 ) 878 (ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA, 879 ChaCha20/Poly1305, SHAKE256) 881 The different methods use the same cipher suites, but some algorithms 882 are not used in some methods. The EDHOC signature algorithm is not 883 used in methods without signature authentication. 885 The Initiator needs to have a list of cipher suites it supports in 886 order of preference. The Responder needs to have a list of cipher 887 suites it supports. SUITES_I contains cipher suites supported by the 888 Initiator, formatted and processed as detailed in Section 5.2.1 to 889 secure the cipher suite negotiation. Examples of cipher suite 890 negotiation are given in Section 6.3.2. 892 3.7. Ephemeral Public Keys 894 EDHOC always uses compact representation of elliptic curve points, 895 see Appendix B. In COSE compact representation is achieved by 896 formatting the ECDH ephemeral public keys as COSE_Keys of type EC2 or 897 OKP according to Sections 7.1 and 7.2 of 898 [I-D.ietf-cose-rfc8152bis-algs], but only including the 'x' parameter 899 in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact 900 representation MAY be used also in the COSE_Key. If the COSE 901 implementation requires an 'y' parameter, the value y = false SHALL 902 be used. COSE always use compact output for Elliptic Curve Keys of 903 type EC2. 905 3.8. External Authorization Data (EAD) 907 In order to reduce round trips and number of messages or to simplify 908 processing, external security applications may be integrated into 909 EDHOC by transporting authorization related data in the messages. 910 One example is third-party identity and authorization information 911 protected out of scope of EDHOC [I-D.selander-ace-ake-authz]. 912 Another example is a certificate enrolment request or the resulting 913 issued certificate. 915 EDHOC allows opaque external authorization data (EAD) to be sent in 916 the EDHOC messages. External authorization data sent in message_1 917 (EAD_1) or message_2 (EAD_2) should be considered unprotected by 918 EDHOC, see Section 8.4. External authorization data sent in 919 message_3 (EAD_3) or message_4 (EAD_4) is protected between Initiator 920 and Responder. 922 External authorization data is a CBOR sequence (see Appendix C.1) 923 consisting of one or more (ead_label, ead_value) pairs as defined 924 below: 926 ead = 1* ( 927 ead_label : int, 928 ead_value : any, 929 ) 931 Applications using external authorization data need to specify 932 format, processing, and security considerations and register the 933 (ead_label, ead_value) pair, see Section 9.5. The CDDL type of 934 ead_value is determined by the int ead_label and MUST be specified. 936 The EAD fields of EDHOC are not intended for generic application 937 data. Since data carried in EAD_1 and EAD_2 fields may not be 938 protected, special considerations need to be made such that it does 939 not violate security and privacy requirements of the service which 940 uses this data. Moreover, the content in an EAD field may impact the 941 security properties provided by EDHOC. Security applications making 942 use of the EAD fields must perform the necessary security analysis. 944 3.9. Applicability Statement 946 EDHOC requires certain parameters to be agreed upon between Initiator 947 and Responder. Some parameters can be agreed through the protocol 948 execution (specifically cipher suite negotiation, see Section 3.6) 949 but other parameters may need to be known out-of-band (e.g., which 950 authentication method is used, see Section 3.2). 952 The purpose of the applicability statement is to describe the 953 intended use of EDHOC to allow for the relevant processing and 954 verifications to be made, including things like: 956 1. How the endpoint detects that an EDHOC message is received. This 957 includes how EDHOC messages are transported, for example in the 958 payload of a CoAP message with a certain Uri-Path or Content- 959 Format; see Appendix A.3. 961 * The method of transporting EDHOC messages may also describe 962 data carried along with the messages that are needed for the 963 transport to satisfy the requirements of Section 3.4, e.g., 964 connection identifiers used with certain messages, see 965 Appendix A.3. 967 2. Authentication method (METHOD; see Section 3.2). 969 3. Profile for authentication credentials (CRED_I, CRED_R; see 970 Section 3.5.3), e.g., profile for certificate or CCS, including 971 supported authentication key algorithms (subject public key 972 algorithm in X.509 or C509 certificate). 974 4. Type used to identify authentication credentials (ID_CRED_I, 975 ID_CRED_R; see Section 3.5.4). 977 5. Use and type of external authorization data (EAD_1, EAD_2, EAD_3, 978 EAD_4; see Section 3.8). 980 6. Identifier used as identity of endpoint; see Section 3.5.1. 982 7. If message_4 shall be sent/expected, and if not, how to ensure a 983 protected application message is sent from the Responder to the 984 Initiator; see Section 5.5. 986 The applicability statement may also contain information about 987 supported cipher suites. The procedure for selecting and verifying 988 cipher suite is still performed as described in Section 5.2.1 and 989 Section 6.3, but it may become simplified by this knowledge. 991 An example of an applicability statement is shown in Appendix D. 993 For some parameters, like METHOD, ID_CRED_x, type of EAD, the 994 receiver is able to verify compliance with applicability statement, 995 and if it needs to fail because of incompliance, to infer the reason 996 why the protocol failed. 998 For other parameters, like CRED_x in the case that it is not 999 transported, it may not be possible to verify that incompliance with 1000 applicability statement was the reason for failure: Integrity 1001 verification in message_2 or message_3 may fail not only because of 1002 wrong authentication credential. For example, in case the Initiator 1003 uses public key certificate by reference (i.e., not transported 1004 within the protocol) then both endpoints need to use an identical 1005 data structure as CRED_I or else the integrity verification will 1006 fail. 1008 Note that it is not necessary for the endpoints to specify a single 1009 transport for the EDHOC messages. For example, a mix of CoAP and 1010 HTTP may be used along the path, and this may still allow correlation 1011 between messages. 1013 The applicability statement may be dependent on the identity of the 1014 other endpoint, or other information carried in an EDHOC message, but 1015 it then applies only to the later phases of the protocol when such 1016 information is known. (The Initiator does not know identity of 1017 Responder before having verified message_2, and the Responder does 1018 not know identity of the Initiator before having verified message_3.) 1019 Other conditions may be part of the applicability statement, such as 1020 target application or use (if there is more than one application/use) 1021 to the extent that EDHOC can distinguish between them. In case 1022 multiple applicability statements are used, the receiver needs to be 1023 able to determine which is applicable for a given session, for 1024 example based on URI or external authorization data type. 1026 4. Key Derivation 1028 EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm 1029 in the selected cipher suite to derive keys used in EDHOC and in the 1030 application. Extract is used to derive fixed-length uniformly 1031 pseudorandom keys (PRK) from ECDH shared secrets. Expand is used to 1032 derive additional output keying material (OKM) from the PRKs. 1034 This section defines Extract, Expand and other key derivation 1035 functions based on these: Expand is used to define EDHOC-KDF and in 1036 turn EDHOC-Exporter, whereas Extract is used to define EDHOC- 1037 KeyUpdate. 1039 4.1. Extract 1041 The pseudorandom keys (PRKs) are derived using Extract. 1043 PRK = Extract( salt, IKM ) 1045 where the input keying material (IKM) and salt are defined for each 1046 PRK below. 1048 The definition of Extract depends on the EDHOC hash algorithm of the 1049 selected cipher suite: 1051 * if the EDHOC hash algorithm is SHA-2, then Extract( salt, IKM ) = 1052 HKDF-Extract( salt, IKM ) [RFC5869] 1054 * if the EDHOC hash algorithm is SHAKE128, then Extract( salt, IKM ) 1055 = KMAC128( salt, IKM, 256, "" ) 1057 * if the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM ) 1058 = KMAC256( salt, IKM, 512, "" ) 1060 4.1.1. PRK_2e 1062 PRK_2e is used to derive a keystream to encrypt message_2. PRK_2e is 1063 derived with the following input: 1065 * The salt SHALL be a zero-length byte string. Note that [RFC5869] 1066 specifies that if the salt is not provided, it is set to a string 1067 of zeros (see Section 2.2 of [RFC5869]). For implementation 1068 purposes, not providing the salt is the same as setting the salt 1069 to the zero-length byte string (0x). 1071 * The IKM SHALL be the ECDH shared secret G_XY (calculated from G_X 1072 and Y or G_Y and X) as defined in Section 6.3.1 of 1073 [I-D.ietf-cose-rfc8152bis-algs]. 1075 Example: Assuming the use of curve25519, the ECDH shared secret G_XY 1076 is the output of the X25519 function [RFC7748]: 1078 G_XY = X25519( Y, G_X ) = X25519( X, G_Y ) 1080 Example: Assuming the use of SHA-256 the extract phase of HKDF 1081 produces PRK_2e as follows: 1083 PRK_2e = HMAC-SHA-256( salt, G_XY ) 1085 where salt = 0x (zero-length byte string). 1087 4.1.2. PRK_3e2m 1089 PRK_3e2m is used to produce a MAC in message_2 and to encrypt 1090 message_3. PRK_3e2m is derived as follows: 1092 If the Responder authenticates with a static Diffie-Hellman key, then 1093 PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is the ECDH shared 1094 secret calculated from G_R and X, or G_X and R, else PRK_3e2m = 1095 PRK_2e. 1097 4.1.3. PRK_4x3m 1099 PRK_4x3m is used to produce a MAC in message_3, to encrypt message_4, 1100 and to derive application specific data. PRK_4x3m is derived as 1101 follows: 1103 If the Initiator authenticates with a static Diffie-Hellman key, then 1104 PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY is the ECDH shared 1105 secret calculated from G_I and Y, or G_Y and I, else PRK_4x3m = 1106 PRK_3e2m. 1108 4.2. Expand 1110 The keys, IVs and MACs used in EDHOC are derived from the PRKs using 1111 Expand, and instantiated with the EDHOC AEAD algorithm in the 1112 selected cipher suite. 1114 OKM = EDHOC-KDF( PRK, transcript_hash, label, context, length ) 1115 = Expand( PRK, info, length ) 1117 where info is encoded as the CBOR sequence 1119 info = ( 1120 transcript_hash : bstr, 1121 label : tstr, 1122 context : bstr, 1123 length : uint, 1124 ) 1126 where 1128 * transcript_hash is a bstr set to one of the transcript hashes 1129 TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.3. 1131 * label is a tstr set to the name of the derived key, IV or MAC; 1132 i.e., "KEYSTREAM_2", "MAC_2", "K_3", "IV_3", or "MAC_3". 1134 * context is a bstr 1136 * length is the length of output keying material (OKM) in bytes 1138 The definition of Expand depends on the EDHOC hash algorithm of the 1139 selected cipher suite: 1141 * if the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, 1142 length ) = HKDF-Expand( PRK, info, length ) [RFC5869] 1144 * if the EDHOC hash algorithm is SHAKE128, then Expand( PRK, info, 1145 length ) = KMAC128( PRK, info, L, "" ) 1147 * if the EDHOC hash algorithm is SHAKE256, then Expand( PRK, info, 1148 length ) = KMAC256( PRK, info, L, "" ) 1150 where L = 8*length, the output length in bits. 1152 The keys, IVs and MACs are derived as follows: 1154 * KEYSTREAM_2 is derived using the transcript hash TH_2 and the 1155 pseudorandom key PRK_2e. 1157 * MAC_2 is derived using the transcript hash TH_2 and the 1158 pseudorandom key PRK_3e2m. 1160 * K_3 and IV_3 are derived using the transcript hash TH_3 and the 1161 pseudorandom key PRK_3e2m. IVs are only used if the EDHOC AEAD 1162 algorithm uses IVs. 1164 * MAC_3 is derived using the transcript hash TH_3 and the 1165 pseudorandom key PRK_4x3m. 1167 KEYSTREAM_2, K_3, and IV_3 use an empty CBOR byte string h'' as 1168 context. MAC_2 and MAC_3 use context as defined in Section 5.3.2 and 1169 Section 5.4.2, respectively. 1171 4.3. EDHOC-Exporter 1173 Application keys and other application specific data can be derived 1174 using the EDHOC-Exporter interface defined as: 1176 EDHOC-Exporter(label, context, length) 1177 = EDHOC-KDF(PRK_4x3m, TH_4, label, context, length) 1179 where label is a registered tstr from the EDHOC Exporter Label 1180 registry (Section 9.1), context is a bstr defined by the application, 1181 and length is a uint defined by the application. The (label, 1182 context) pair must be unique, i.e., a (label, context) MUST NOT be 1183 used for two different purposes. However an application can re- 1184 derive the same key several times as long as it is done in a secure 1185 way. For example, in most encryption algorithms the same key kan be 1186 reused with different nonces. The context can for example be the 1187 empty (zero-length) sequence or a single CBOR byte string. 1189 The transcript hash TH_4 is a CBOR encoded bstr and the input to the 1190 hash function is a CBOR Sequence. 1192 TH_4 = H( TH_3, CIPHERTEXT_3 ) 1194 where H() is the hash function in the selected cipher suite. 1195 Examples of use of the EDHOC-Exporter are given in Section 5.5.2 and 1196 Appendix A. 1198 * K_4 and IV_4 are derived with the EDHOC-Exporter using the empty 1199 CBOR byte string h'' as context, and labels "EDHOC_K_4" and 1200 "EDHOC_IV_4", respectively. IVs are only used if the EDHOC AEAD 1201 algorithm uses IVs. 1203 4.4. EDHOC-KeyUpdate 1205 To provide forward secrecy in an even more efficient way than re- 1206 running EDHOC, EDHOC provides the function EDHOC-KeyUpdate. When 1207 EDHOC-KeyUpdate is called the old PRK_4x3m is deleted and the new 1208 PRK_4x3m is calculated as a "hash" of the old key using the Extract 1209 function as illustrated by the following pseudocode: 1211 EDHOC-KeyUpdate( nonce ): 1212 PRK_4x3m = Extract( nonce, PRK_4x3m ) 1214 The EDHOC-KeyUpdate takes a nonce as input to guarantee that there 1215 are no short cycles. The Initiator and the Responder need to agree 1216 on the nonce, which can e.g., be a counter or a random number. While 1217 the KeyUpdate method provides forward secrecy it does not give as 1218 strong security properties as re-running EDHOC, see Section 8. 1220 5. Message Formatting and Processing 1222 This section specifies formatting of the messages and processing 1223 steps. Error messages are specified in Section 6. 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 session, the endpoints are assumed to keep an associated 1240 protocol state containing identifiers, keys, etc. used for subsequent 1241 processing of protocol related data. The protocol state is assumed 1242 to be associated to an applicability statement (Section 3.9) which 1243 provides the context for how messages are transported, identified, 1244 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.5). 1259 3. If the message received is an error message, then process 1260 according to Section 6, else process as the expected next message 1261 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 because the state of the protocol 1271 has moved on and now expects something else. This assumes that 1272 message duplication due to re-transmissions is handled by the 1273 transport protocol, see Section 3.4. The case when the transport 1274 does not support message deduplication is addressed in Appendix E. 1276 5.2. EDHOC Message 1 1278 5.2.1. Formatting of Message 1 1280 message_1 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1281 below 1283 message_1 = ( 1284 METHOD : int, 1285 SUITES_I : suites, 1286 G_X : bstr, 1287 C_I : bstr / int, 1288 ? EAD_1 : ead, 1289 ) 1291 suites = [ 2* int ] / int 1293 where: 1295 * METHOD = 0, 1, 2, or 3 (see Figure 4). 1297 * SUITES_I - array of cipher suites which the Initiator supports in 1298 order of preference, starting with the most preferred and ending 1299 with the cipher suite selected for this session. If the most 1300 preferred cipher suite is selected then SUITES_I is encoded as 1301 that cipher suite, i.e., as an int. The processing steps are 1302 detailed below and in Section 6.3. 1304 * G_X - the ephemeral public key of the Initiator 1306 * C_I - variable length connection identifier 1308 * EAD_1 - unprotected external authorization data, see Section 3.8. 1310 5.2.2. Initiator Processing of Message 1 1312 The Initiator SHALL compose message_1 as follows: 1314 * The supported cipher suites and the order of preference MUST NOT 1315 be changed based on previous error messages. SUITES_I contains 1316 the ordered list of supported cipher suites, truncated after the 1317 cipher suite selected for this session. The selected cipher suite 1318 MAY be changed between sessions, e.g., based on previous error 1319 messages (see next bullet), but all cipher suites which are more 1320 preferred than the selected cipher suite in the list MUST be 1321 included in SUITES_I. 1323 * The Initiator MUST select its most preferred cipher suite, 1324 conditioned on what it can assume to be supported by the 1325 Responder. If the Initiator previously received from the 1326 Responder an error message with error code 2 (see Section 6.3) 1327 indicating cipher suites supported by the Responder, then the 1328 Initiator SHOULD select the most preferred supported cipher suite 1329 among those (note that error messages are not authenticated and 1330 may be forged). 1332 * Generate an ephemeral ECDH key pair using the curve in the 1333 selected cipher suite and format it as a COSE_Key. Let G_X be the 1334 'x' parameter of the COSE_Key. 1336 * Choose a connection identifier C_I and store it for the length of 1337 the protocol. 1339 * Encode message_1 as a sequence of CBOR encoded data items as 1340 specified in Section 5.2.1 1342 5.2.3. Responder Processing of Message 1 1344 The Responder SHALL process message_1 as follows: 1346 * Decode message_1 (see Appendix C.1). 1348 * Verify that the selected cipher suite is supported and that no 1349 prior cipher suite in SUITES_I is supported. 1351 * Pass EAD_1 to the security application. 1353 If any processing step fails, the Responder SHOULD send an EDHOC 1354 error message back, formatted as defined in Section 6, and the 1355 session MUST be discontinued. Sending error messages is essential 1356 for debugging but MAY e.g., be skipped due to denial-of-service 1357 reasons, see Section 8. 1359 5.3. EDHOC Message 2 1361 5.3.1. Formatting of Message 2 1363 message_2 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1364 below 1366 message_2 = ( 1367 G_Y_CIPHERTEXT_2 : bstr, 1368 C_R : bstr / int, 1369 ) 1371 where: 1373 * G_Y_CIPHERTEXT_2 - the concatenation of G_Y, the ephemeral public 1374 key of the Responder, and CIPHERTEXT_2 1376 * C_R - variable length connection identifier 1378 5.3.2. Responder Processing of Message 2 1380 The Responder SHALL compose message_2 as follows: 1382 * Generate an ephemeral ECDH key pair using the curve in the 1383 selected cipher suite and format it as a COSE_Key. Let G_Y be the 1384 'x' parameter of the COSE_Key. 1386 * Choose a connection identifier C_R and store it for the length of 1387 the protocol. 1389 * Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R ) 1390 where H() is the hash function in the selected cipher suite. The 1391 transcript hash TH_2 is a CBOR encoded bstr and the input to the 1392 hash function is a CBOR Sequence. Note that H(message_1) can be 1393 computed and cached already in the processing of message_1. 1395 * Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R, 1396 CRED_R, ? EAD_2 >>, mac_length_2 ). If the Responder 1397 authenticates with a static Diffie-Hellman key (method equals 1 or 1398 3), then mac_length_2 is the EDHOC MAC length given by the 1399 selected cipher suite. If the Responder authenticates with a 1400 signature key (method equals 0 or 2), then mac_length_2 is equal 1401 to the output size of the EDHOC hash algorithm given by the 1402 selected cipher suite. 1404 - ID_CRED_R - identifier to facilitate retrieval of CRED_R, see 1405 Section 3.5.4 1407 - CRED_R - CBOR item containing the credential of the Responder, 1408 see Section 3.5.4 1410 - EAD_2 = unprotected external authorization data, see 1411 Section 3.8 1413 * If the Responder authenticates with a static Diffie-Hellman key 1414 (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the 1415 Responder authenticates with a signature key (method equals 0 or 1416 2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1 1417 object as defined in Section 4.4 of 1418 [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm in 1419 the selected cipher suite, the private authentication key of the 1420 Responder, and the following parameters: 1422 - protected = << ID_CRED_R >> 1424 - external_aad = << TH_2, CRED_R, ? EAD_2 >> 1426 - payload = MAC_2 1428 COSE constructs the input to the Signature Algorithm as: 1430 - The key is the private authentication key of the Responder. 1432 - The message M to be signed = 1434 [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? EAD_2 >>, 1435 MAC_2 ] 1437 * CIPHERTEXT_2 is encrypted by using the Expand function as a binary 1438 additive stream cipher. 1440 - plaintext = ( ID_CRED_R / bstr / int, Signature_or_MAC_2, ? 1441 EAD_2 ) 1443 o Note that if ID_CRED_R contains a single 'kid' parameter, 1444 i.e., ID_CRED_R = { 4 : kid_R }, only the byte string or 1445 integer kid_R is conveyed in the plaintext encoded as a bstr 1446 or int. 1448 - CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 1450 * Encode message_2 as a sequence of CBOR encoded data items as 1451 specified in Section 5.3.1. 1453 5.3.3. Initiator Processing of Message 2 1455 The Initiator SHALL process message_2 as follows: 1457 * Decode message_2 (see Appendix C.1). 1459 * Retrieve the protocol state using the message correlation provided 1460 by the transport (e.g., the CoAP Token and the 5-tuple as a 1461 client, or the prepended C_I as a server). 1463 * Decrypt CIPHERTEXT_2, see Section 5.3.2. 1465 * Pass EAD_2 to the security application. 1467 * Verify that the identity of the Responder is an allowed identity 1468 for this connection, see Section 3.5. 1470 * Verify Signature_or_MAC_2 using the algorithm in the selected 1471 cipher suite. The verification process depends on the method, see 1472 Section 5.3.2. 1474 If any processing step fails, the Initiator SHOULD send an EDHOC 1475 error message back, formatted as defined in Section 6. Sending error 1476 messages is essential for debugging but MAY e.g., be skipped if a 1477 session cannot be found or due to denial-of-service reasons, see 1478 Section 8. If an error message is sent, the session MUST be 1479 discontinued. 1481 5.4. EDHOC Message 3 1482 5.4.1. Formatting of Message 3 1484 message_3 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1485 below 1487 message_3 = ( 1488 CIPHERTEXT_3 : bstr, 1489 ) 1491 5.4.2. Initiator Processing of Message 3 1493 The Initiator SHALL compose message_3 as follows: 1495 * Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H() 1496 is the hash function in the selected cipher suite. The transcript 1497 hash TH_3 is a CBOR encoded bstr and the input to the hash 1498 function is a CBOR Sequence. Note that H(TH_2, CIPHERTEXT_2) can 1499 be computed and cached already in the processing of message_2. 1501 * Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", << ID_CRED_I, 1502 CRED_I, ? EAD_3 >>, mac_length_3 ). If the Initiator 1503 authenticates with a static Diffie-Hellman key (method equals 2 or 1504 3), then mac_length_3 is the EDHOC MAC length given by the 1505 selected cipher suite. If the Initiator authenticates with a 1506 signature key (method equals 0 or 1), then mac_length_3 is equal 1507 to the output size of the EDHOC hash algorithm given by the 1508 selected cipher suite. 1510 - ID_CRED_I - identifier to facilitate retrieval of CRED_I, see 1511 Section 3.5.4 1513 - CRED_I - CBOR item containing the credential of the Initiator, 1514 see Section 3.5.4 1516 - EAD_3 = protected external authorization data, see Section 3.8 1518 * If the Initiator authenticates with a static Diffie-Hellman key 1519 (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3. If the 1520 Initiator authenticates with a signature key (method equals 0 or 1521 1), then Signature_or_MAC_3 is the 'signature' of a COSE_Sign1 1522 object as defined in Section 4.4 of 1523 [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm in 1524 the selected cipher suite, the private authentication key of the 1525 Initiator, and the following parameters: 1527 - protected = << ID_CRED_I >> 1529 - external_aad = << TH_3, CRED_I, ? EAD_3 >> 1530 - payload = MAC_3 1532 COSE constructs the input to the Signature Algorithm as: 1534 - The key is the private authentication key of the Initiator. 1536 - The message M to be signed = 1538 [ "Signature1", << ID_CRED_I >>, << TH_3, CRED_I, ? EAD_3 >>, 1539 MAC_3 ] 1541 * Compute an outer COSE_Encrypt0 as defined in Section 5.3 of 1542 [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm 1543 in the selected cipher suite, K_3, IV_3, and the following 1544 parameters. The protected header SHALL be the empty CBOR byte 1545 string. 1547 - protected = h'' 1549 - external_aad = TH_3 1551 - plaintext = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? 1552 EAD_3 ) 1554 o Note that if ID_CRED_I contains a single 'kid' parameter, 1555 i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or 1556 integer kid_I is conveyed in the plaintext encoded as a bstr 1557 or int. 1559 COSE constructs the input to the AEAD [RFC5116] as follows: 1561 - Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3", h'', length ) 1563 - Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3", h'', length ) 1565 - Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? 1566 EAD_3 ) 1568 - Associated data A = [ "Encrypt0", h'', TH_3 ] 1570 CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0. 1572 * Encode message_3 as a sequence of CBOR encoded data items as 1573 specified in Section 5.4.1. 1575 Pass the connection identifiers (C_I, C_R) and the application 1576 algorithms in the selected cipher suite to the application. The 1577 application can now derive application keys using the EDHOC-Exporter 1578 interface, see Section 4.3. 1580 After sending message_3, the Initiator is assured that no other party 1581 than the Responder can compute the key PRK_4x3m (implicit key 1582 authentication). The Initiator can securely derive application keys 1583 and send protected application data. However, the Initiator does not 1584 know that the Responder has actually computed the key PRK_4x3m and 1585 therefore the Initiator SHOULD NOT permanently store the keying 1586 material PRK_4x3m and TH_4, or derived application keys, until the 1587 Initiator is assured that the Responder has actually computed the key 1588 PRK_4x3m (explicit key confirmation). This is similar to waiting for 1589 acknowledgement (ACK) in a transport protocol. Explicit key 1590 confirmation is e.g., assured when the Initiator has verified an 1591 OSCORE message or message_4 from the Responder. 1593 5.4.3. Responder Processing of Message 3 1595 The Responder SHALL process message_3 as follows: 1597 * Decode message_3 (see Appendix C.1). 1599 * Retrieve the protocol state using the message correlation provided 1600 by the transport (e.g., the CoAP Token and the 5-tuple as a 1601 client, or the prepended C_R as a server). 1603 * Decrypt and verify the outer COSE_Encrypt0 as defined in 1604 Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC 1605 AEAD algorithm in the selected cipher suite, K_3, and IV_3. 1607 * Pass EAD_3 to the security application. 1609 * Verify that the identity of the Initiator is an allowed identity 1610 for this connection, see Section 3.5. 1612 * Verify Signature_or_MAC_3 using the algorithm in the selected 1613 cipher suite. The verification process depends on the method, see 1614 Section 5.4.2. 1616 * Pass the connection identifiers (C_I, C_R), and the application 1617 algorithms in the selected cipher suite to the security 1618 application. The application can now derive application keys 1619 using the EDHOC-Exporter interface. 1621 If any processing step fails, the Responder SHOULD send an EDHOC 1622 error message back, formatted as defined in Section 6. Sending error 1623 messages is essential for debugging but MAY e.g., be skipped if a 1624 session cannot be found or due to denial-of-service reasons, see 1625 Section 8. If an error message is sent, the session MUST be 1626 discontinued. 1628 After verifying message_3, the Responder is assured that the 1629 Initiator has calculated the key PRK_4x3m (explicit key confirmation) 1630 and that no other party than the Responder can compute the key. The 1631 Responder can securely send protected application data and store the 1632 keying material PRK_4x3m and TH_4. 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, the Responder MUST send message_4. Two 1642 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 are provided in Section 3.9. 1652 5.5.1. Formatting of Message 4 1654 message_4 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1655 below 1657 message_4 = ( 1658 CIPHERTEXT_4 : bstr, 1659 ) 1661 5.5.2. Responder Processing of Message 4 1663 The Responder SHALL compose message_4 as follows: 1665 * Compute a COSE_Encrypt0 as defined in Section 5.3 of 1666 [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm 1667 in the selected cipher suite, and the following parameters. The 1668 protected header SHALL be the empty CBOR byte string. 1670 - protected = h'' 1672 - external_aad = TH_4 1674 - plaintext = ( ? EAD_4 ), where EAD_4 is protected external 1675 authorization data, see Section 3.8 1677 - Key K_4 = EDHOC-Exporter( "EDHOC_K_4", h'', length ) 1679 - IV IV_4 = EDHOC-Exporter( "EDHOC_IV_4", h'', length ) 1681 COSE constructs the input to the AEAD [RFC5116] as follows: 1683 - Key K = K_4 1685 - Nonce N = IV_4 1687 - Plaintext P = ( ? EAD_4 ) 1689 - Associated data A = [ "Encrypt0", h'', TH_4 ] 1691 CIPHERTEXT_4 is the ciphertext of the COSE_Encrypt0. 1693 * Encode message_4 as a sequence of CBOR encoded data items as 1694 specified in Section 5.5.1. 1696 5.5.3. Initiator Processing of Message 4 1698 The Initiator SHALL process message_4 as follows: 1700 * Decode message_4 (see Appendix C.1). 1702 * Retrieve the protocol state using the message correlation provided 1703 by the transport (e.g., the CoAP Token and the 5-tuple as a 1704 client, or the prepended C_I as a server). 1706 * Decrypt and verify the outer COSE_Encrypt0 as defined in 1707 Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC 1708 AEAD algorithm in the selected cipher suite, and the parameters 1709 defined in Section 5.5.2. 1711 * Pass EAD_4 to the security application. 1713 If any processing step fails, the Responder SHOULD send an EDHOC 1714 error message back, formatted as defined in Section 6. Sending error 1715 messages is essential for debugging but MAY e.g., be skipped if a 1716 session cannot be found or due to denial-of-service reasons, see 1717 Section 8. If an error message is sent, the session MUST be 1718 discontinued. 1720 6. Error Handling 1722 This section defines the format for error messages. 1724 An EDHOC error message can be sent by either endpoint as a reply to 1725 any non-error EDHOC message. How errors at the EDHOC layer are 1726 transported depends on lower layers, which need to enable error 1727 messages to be sent and processed as intended. 1729 Errors in EDHOC are fatal. After sending an error message, the 1730 sender MUST discontinue the protocol. The receiver SHOULD treat an 1731 error message as an indication that the other party likely has 1732 discontinued the protocol. But as the error message is not 1733 authenticated, a received error message might also have been sent by 1734 an attacker and the receiver MAY therefore try to continue the 1735 protocol. 1737 error SHALL be a CBOR Sequence (see Appendix C.1) as defined below 1739 error = ( 1740 ERR_CODE : int, 1741 ERR_INFO : any, 1742 ) 1744 Figure 6: EDHOC Error Message 1746 where: 1748 * ERR_CODE - error code encoded as an integer. The value 0 is used 1749 for success, all other values (negative or positive) indicate 1750 errors. 1752 * ERR_INFO - error information. Content and encoding depend on 1753 error code. 1755 The remainder of this section specifies the currently defined error 1756 codes, see Figure 7. Additional error codes and corresponding error 1757 information may be specified. 1759 +----------+---------------+----------------------------------------+ 1760 | ERR_CODE | ERR_INFO Type | Description | 1761 +==========+===============+========================================+ 1762 | 0 | any | Success | 1763 +----------+---------------+----------------------------------------+ 1764 | 1 | tstr | Unspecified | 1765 +----------+---------------+----------------------------------------+ 1766 | 2 | suites | Wrong selected cipher suite | 1767 +----------+---------------+----------------------------------------+ 1769 Figure 7: Error Codes and Error Information 1771 6.1. Success 1773 Error code 0 MAY be used internally in an application to indicate 1774 success, e.g., in log files. ERR_INFO can contain any type of CBOR 1775 item. Error code 0 MUST NOT be used as part of the EDHOC message 1776 exchange flow. 1778 6.2. Unspecified 1780 Error code 1 is used for errors that do not have a specific error 1781 code defined. ERR_INFO MUST be a text string containing a human- 1782 readable diagnostic message written in English. The diagnostic text 1783 message is mainly intended for software engineers that during 1784 debugging need to interpret it in the context of the EDHOC 1785 specification. The diagnostic message SHOULD be provided to the 1786 calling application where it SHOULD be logged. 1788 6.3. Wrong Selected Cipher Suite 1790 Error code 2 MUST only be used in a response to message_1 in case the 1791 cipher suite selected by the Initiator is not supported by the 1792 Responder, or if the Responder supports a cipher suite more preferred 1793 by the Initiator than the selected cipher suite, see Section 5.2.3. 1794 ERR_INFO is in this case denoted SUITES_R and is of type suites, see 1795 Section 5.2.1. If the Responder does not support the selected cipher 1796 suite, then SUITES_R MUST include one or more supported cipher 1797 suites. If the Responder supports a cipher suite in SUITES_I other 1798 than the selected cipher suite (independently of if the selected 1799 cipher suite is supported or not) then SUITES_R MUST include the 1800 supported cipher suite in SUITES_I which is most preferred by the 1801 Initiator. SUITES_R MAY include a single cipher suite, i.e., be 1802 encoded as an int. If the Responder does not support any cipher 1803 suite in SUITES_I, then it SHOULD include all its supported cipher 1804 suites in SUITES_R in any order. 1806 6.3.1. Cipher Suite Negotiation 1808 After receiving SUITES_R, the Initiator can determine which cipher 1809 suite to select (if any) for the next EDHOC run with the Responder. 1811 If the Initiator intends to contact the Responder in the future, the 1812 Initiator SHOULD remember which selected cipher suite to use until 1813 the next message_1 has been sent, otherwise the Initiator and 1814 Responder will likely run into an infinite loop where the Initiator 1815 selects its most preferred and the Responder sends an error with 1816 supported cipher suites. After a successful run of EDHOC, the 1817 Initiator MAY remember the selected cipher suite to use in future 1818 EDHOC sessions. Note that if the Initiator or Responder is updated 1819 with new cipher suite policies, any cached information may be 1820 outdated. 1822 6.3.2. Examples 1824 Assume that the Initiator supports the five cipher suites 5, 6, 7, 8, 1825 and 9 in decreasing order of preference. Figures 8 and 9 show 1826 examples of how the Initiator can format SUITES_I and how SUITES_R is 1827 used by Responders to give the Initiator information about the cipher 1828 suites that the Responder supports. 1830 In the first example (Figure 8), the Responder supports cipher suite 1831 6 but not the initially selected cipher suite 5. 1833 Initiator Responder 1834 | METHOD, SUITES_I = 5, G_X, C_I, EAD_1 | 1835 +------------------------------------------------------------------>| 1836 | message_1 | 1837 | | 1838 | ERR_CODE = 2, SUITES_R = 6 | 1839 |<------------------------------------------------------------------+ 1840 | error | 1841 | | 1842 | METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1 | 1843 +------------------------------------------------------------------>| 1844 | message_1 | 1846 Figure 8: Example of Responder supporting suite 6 but not suite 5. 1848 In the second example (Figure 9), the Responder supports cipher 1849 suites 8 and 9 but not the more preferred (by the Initiator) cipher 1850 suites 5, 6 or 7. To illustrate the negotiation mechanics we let the 1851 Initiator first make a guess that the Responder supports suite 6 but 1852 not suite 5. Since the Responder supports neither 5 nor 6, it 1853 responds with SUITES_R containing the supported suites, after which 1854 the Initiator selects its most preferred supported suite. The order 1855 of cipher suites in SUITES_R does not matter. (If the Responder had 1856 supported suite 5, it would have included it in SUITES_R of the 1857 response, and it would in that case have become the selected suite in 1858 the second message_1.) 1860 Initiator Responder 1861 | METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1 | 1862 +------------------------------------------------------------------>| 1863 | message_1 | 1864 | | 1865 | ERR_CODE = 2, SUITES_R = [9, 8] | 1866 |<------------------------------------------------------------------+ 1867 | error | 1868 | | 1869 | METHOD, SUITES_I = [5, 6, 7, 8], G_X, C_I, EAD_1 | 1870 +------------------------------------------------------------------>| 1871 | message_1 | 1873 Figure 9: Example of Responder supporting suites 8 and 9 but not 1874 5, 6 or 7. 1876 Note that the Initiator's list of supported cipher suites and order 1877 of preference is fixed (see Section 5.2.1 and Section 5.2.2). 1878 Furthermore, the Responder shall only accept message_1 if the 1879 selected cipher suite is the first cipher suite in SUITES_I that the 1880 Responder supports (see Section 5.2.3). Following this procedure 1881 ensures that the selected cipher suite is the most preferred (by the 1882 Initiator) cipher suite supported by both parties. 1884 If the selected cipher suite is not the first cipher suite which the 1885 Responder supports in SUITES_I received in message_1, then Responder 1886 MUST discontinue the protocol, see Section 5.2.3. If SUITES_I in 1887 message_1 is manipulated, then the integrity verification of 1888 message_2 containing the transcript hash TH_2 will fail and the 1889 Initiator will discontinue the protocol. 1891 7. Mandatory-to-Implement Compliance Requirements 1893 An implementation may support only Initiator or only Responder. 1895 An implementation may support only a single method. None of the 1896 methods are mandatory-to-implement. 1898 Implementations MUST support the EDHOC-Exporter. Implementations 1899 SHOULD support EDHOC-KeyUpdate. 1901 Implementaions MAY support message_4. Error codes 1 and 2 MUST be 1902 supported. 1904 Implementations MUST support 'kid' parameters of type int. 1906 Editor's note: Is any COSE header parameters (kid, kcwt, kccs, x5t, 1907 c5c, etc. ) MTI? 1909 Editor's note: Is any credential type (CCS, CWT, X.509, C509) MTI? 1911 Editor's note: Is support of EAD MTI? 1913 For many constrained IoT devices it is problematic to support more 1914 than one cipher suite. Existing devices can be expected to support 1915 either ECDSA or EdDSA. To enable as much interoperability as we can 1916 reasonably achieve, less constrained devices SHOULD implement both 1917 cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES- 1918 CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA- 1919 256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained 1920 endpoints SHOULD implement cipher suite 0 or cipher suite 2. 1921 Implementations only need to implement the algorithms needed for 1922 their supported methods. 1924 8. Security Considerations 1926 8.1. Security Properties 1928 EDHOC inherits its security properties from the theoretical SIGMA-I 1929 protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides 1930 forward secrecy, mutual authentication with aliveness, consistency, 1931 and peer awareness. As described in [SIGMA], peer awareness is 1932 provided to the Responder, but not to the Initiator. 1934 EDHOC protects the credential identifier of the Initiator against 1935 active attacks and the credential identifier of the Responder against 1936 passive attacks. The roles should be assigned to protect the most 1937 sensitive identity/identifier, typically that which is not possible 1938 to infer from routing information in the lower layers. 1940 Compared to [SIGMA], EDHOC adds an explicit method type and expands 1941 the message authentication coverage to additional elements such as 1942 algorithms, external authorization data, and previous messages. This 1943 protects against an attacker replaying messages or injecting messages 1944 from another session. 1946 EDHOC also adds selection of connection identifiers and downgrade 1947 protected negotiation of cryptographic parameters, i.e., an attacker 1948 cannot affect the negotiated parameters. A single session of EDHOC 1949 does not include negotiation of cipher suites, but it enables the 1950 Responder to verify that the selected cipher suite is the most 1951 preferred cipher suite by the Initiator which is supported by both 1952 the Initiator and the Responder. 1954 As required by [RFC7258], IETF protocols need to mitigate pervasive 1955 monitoring when possible. EDHOC therefore only supports methods with 1956 ephemeral Diffie-Hellman and provides a KeyUpdate function for 1957 lightweight application protocol rekeying with forward secrecy, in 1958 the sense that compromise of the private authentication keys does not 1959 compromise past session keys, and compromise of a session key does 1960 not compromise past session keys. 1962 While the KeyUpdate method can be used to meet cryptographic limits 1963 and provide partial protection against key leakage, it provides 1964 significantly weaker security properties than re-running EDHOC with 1965 ephemeral Diffie-Hellman. Even with frequent use of KeyUpdate, 1966 compromise of one session key compromises all future session keys, 1967 and an attacker therefore only needs to perform static key 1968 exfiltration [RFC7624]. Frequently re-running EDHOC with ephemeral 1969 Diffie-Hellman forces attackers to perform dynamic key exfiltration 1970 instead of static key exfiltration [RFC7624]. In the dynamic case, 1971 the attacker must have continuous interactions with the collaborator, 1972 which is more complicated and has a higher risk profile than the 1973 static case. 1975 To limit the effect of breaches, it is important to limit the use of 1976 symmetrical group keys for bootstrapping. EDHOC therefore strives to 1977 make the additional cost of using raw public keys and self-signed 1978 certificates as small as possible. Raw public keys and self-signed 1979 certificates are not a replacement for a public key infrastructure 1980 but SHOULD be used instead of symmetrical group keys for 1981 bootstrapping. 1983 Compromise of the long-term keys (private signature or static DH 1984 keys) does not compromise the security of completed EDHOC exchanges. 1985 Compromising the private authentication keys of one party lets an 1986 active attacker impersonate that compromised party in EDHOC exchanges 1987 with other parties but does not let the attacker impersonate other 1988 parties in EDHOC exchanges with the compromised party. Compromise of 1989 the long-term keys does not enable a passive attacker to compromise 1990 future session keys. Compromise of the HDKF input parameters (ECDH 1991 shared secret) leads to compromise of all session keys derived from 1992 that compromised shared secret. Compromise of one session key does 1993 not compromise other session keys. Compromise of PRK_4x3m leads to 1994 compromise of all exported keying material derived after the last 1995 invocation of the EDHOC-KeyUpdate function. 1997 EDHOC provides a minimum of 64-bit security against online brute 1998 force attacks and a minimum of 128-bit security against offline brute 1999 force attacks. This is in line with IPsec, TLS, and COSE. To break 2000 64-bit security against online brute force an attacker would on 2001 average have to send 4.3 billion messages per second for 68 years, 2002 which is infeasible in constrained IoT radio technologies. 2004 After sending message_3, the Initiator is assured that no other party 2005 than the Responder can compute the key PRK_4x3m (implicit key 2006 authentication). The Initiator does however not know that the 2007 Responder has actually computed the key PRK_4x3m. While the 2008 Initiator can securely send protected application data, the Initiator 2009 SHOULD NOT permanently store the keying material PRK_4x3m and TH_4 2010 until the Initiator is assured that the Responder has actually 2011 computed the key PRK_4x3m (explicit key confirmation). Explicit key 2012 confirmation is e.g., assured when the Initiator has verified an 2013 OSCORE message or message_4 from the Responder. After verifying 2014 message_3, the Responder is assured that the Initiator has calculated 2015 the key PRK_4x3m (explicit key confirmation) and that no other party 2016 than the Responder can compute the key. The Responder can securely 2017 send protected application data and store the keying material 2018 PRK_4x3m and TH_4. 2020 Key compromise impersonation (KCI): In EDHOC authenticated with 2021 signature keys, EDHOC provides KCI protection against an attacker 2022 having access to the long-term key or the ephemeral secret key. With 2023 static Diffie-Hellman key authentication, KCI protection would be 2024 provided against an attacker having access to the long-term Diffie- 2025 Hellman key, but not to an attacker having access to the ephemeral 2026 secret key. Note that the term KCI has typically been used for 2027 compromise of long-term keys, and that an attacker with access to the 2028 ephemeral secret key can only attack that specific session. 2030 Repudiation: In EDHOC authenticated with signature keys, the 2031 Initiator could theoretically prove that the Responder performed a 2032 run of the protocol by presenting the private ephemeral key, and vice 2033 versa. Note that storing the private ephemeral keys violates the 2034 protocol requirements. With static Diffie-Hellman key 2035 authentication, both parties can always deny having participated in 2036 the protocol. 2038 Two earlier versions of EDHOC have been formally analyzed [Norrman20] 2039 [Bruni18] and the specification has been updated based on the 2040 analysis. 2042 8.2. Cryptographic Considerations 2044 The SIGMA protocol requires that the encryption of message_3 provides 2045 confidentiality against active attackers and EDHOC message_4 relies 2046 on the use of authenticated encryption. Hence the message 2047 authenticating functionality of the authenticated encryption in EDHOC 2048 is critical: authenticated encryption MUST NOT be replaced by plain 2049 encryption only, even if authentication is provided at another level 2050 or through a different mechanism. 2052 To reduce message overhead EDHOC does not use explicit nonces and 2053 instead rely on the ephemeral public keys to provide randomness to 2054 each session. A good amount of randomness is important for the key 2055 generation, to provide liveness, and to protect against interleaving 2056 attacks. For this reason, the ephemeral keys MUST NOT be used in 2057 more than one EDHOC message, and both parties SHALL generate fresh 2058 random ephemeral key pairs. Note that an ephemeral key may be used 2059 to calculate several ECDH shared secrets. When static Diffie-Hellman 2060 authentication is used the same ephemeral key is used in both 2061 ephemeral-ephemeral and ephemeral-static ECDH. 2063 As discussed in [SIGMA], the encryption of message_2 does only need 2064 to protect against passive attacker as active attackers can always 2065 get the Responders identity by sending their own message_1. EDHOC 2066 uses the Expand function (typically HKDF-Expand) as a binary additive 2067 stream cipher. HKDF-Expand provides better confidentiality than AES- 2068 CTR but is not often used as it is slow on long messages, and most 2069 applications require both IND-CCA confidentiality as well as 2070 integrity protection. For the encryption of message_2, any speed 2071 difference is negligible, IND-CCA does not increase security, and 2072 integrity is provided by the inner MAC (and signature depending on 2073 method). 2075 Requirement for how to securely generate, validate, and process the 2076 ephemeral public keys depend on the elliptic curve. For X25519 and 2077 X448, the requirements are defined in [RFC7748]. For secp256r1, 2078 secp384r1, and secp521r1, the requirements are defined in Section 5 2079 of [SP-800-56A]. For secp256r1, secp384r1, and secp521r1, at least 2080 partial public-key validation MUST be done. 2082 8.3. Cipher Suites and Cryptographic Algorithms 2084 When using private cipher suite or registering new cipher suites, the 2085 choice of key length used in the different algorithms needs to be 2086 harmonized, so that a sufficient security level is maintained for 2087 certificates, EDHOC, and the protection of application data. The 2088 Initiator and the Responder should enforce a minimum security level. 2090 The hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to 2091 64-bits) SHALL NOT be supported for use in EDHOC except for 2092 certificate identification with x5t and c5t. Note that secp256k1 is 2093 only defined for use with ECDSA and not for ECDH. Note that some 2094 COSE algorithms are marked as not recommended in the COSE IANA 2095 registry. 2097 8.4. Unprotected Data 2099 The Initiator and the Responder must make sure that unprotected data 2100 and metadata do not reveal any sensitive information. This also 2101 applies for encrypted data sent to an unauthenticated party. In 2102 particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error 2103 messages. Using the same EAD_1 in several EDHOC sessions allows 2104 passive eavesdroppers to correlate the different sessions. Another 2105 consideration is that the list of supported cipher suites may 2106 potentially be used to identify the application. 2108 The Initiator and the Responder must also make sure that 2109 unauthenticated data does not trigger any harmful actions. In 2110 particular, this applies to EAD_1 and error messages. 2112 8.5. Denial-of-Service 2114 EDHOC itself does not provide countermeasures against Denial-of- 2115 Service attacks. By sending a number of new or replayed message_1 an 2116 attacker may cause the Responder to allocate state, perform 2117 cryptographic operations, and amplify messages. To mitigate such 2118 attacks, an implementation SHOULD rely on lower layer mechanisms such 2119 as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that 2120 forces the initiator to demonstrate reachability at its apparent 2121 network address. 2123 An attacker can also send faked message_2, message_3, message_4, or 2124 error in an attempt to trick the receiving party to send an error 2125 message and discontinue the session. EDHOC implementations MAY 2126 evaluate if a received message is likely to have been forged by an 2127 attacker and ignore it without sending an error message or 2128 discontinuing the session. 2130 8.6. Implementation Considerations 2132 The availability of a secure random number generator is essential for 2133 the security of EDHOC. If no true random number generator is 2134 available, a truly random seed MUST be provided from an external 2135 source and used with a cryptographically secure pseudorandom number 2136 generator. As each pseudorandom number must only be used once, an 2137 implementation needs to get a new truly random seed after reboot, or 2138 continuously store state in nonvolatile memory, see ([RFC8613], 2139 Appendix B.1.1) for issues and solution approaches for writing to 2140 nonvolatile memory. Intentionally or unintentionally weak or 2141 predictable pseudorandom number generators can be abused or exploited 2142 for malicious purposes. [RFC8937] describes a way for security 2143 protocol implementations to augment their (pseudo)random number 2144 generators using a long-term private key and a deterministic 2145 signature function. This improves randomness from broken or 2146 otherwise subverted random number generators. The same idea can be 2147 used with other secrets and functions such as a Diffie-Hellman 2148 function or a symmetric secret and a PRF like HMAC or KMAC. It is 2149 RECOMMENDED to not trust a single source of randomness and to not put 2150 unaugmented random numbers on the wire. 2152 If ECDSA is supported, "deterministic ECDSA" as specified in 2153 [RFC6979] MAY be used. Pure deterministic elliptic-curve signatures 2154 such as deterministic ECDSA and EdDSA have gained popularity over 2155 randomized ECDSA as their security do not depend on a source of high- 2156 quality randomness. Recent research has however found that 2157 implementations of these signature algorithms may be vulnerable to 2158 certain side-channel and fault injection attacks due to their 2159 determinism. See e.g., Section 1 of 2160 [I-D.mattsson-cfrg-det-sigs-with-noise] for a list of attack papers. 2161 As suggested in Section 6.1.2 of [I-D.ietf-cose-rfc8152bis-algs] this 2162 can be addressed by combining randomness and determinism. 2164 All private keys, symmetric keys, and IVs MUST be secret. 2165 Implementations should provide countermeasures to side-channel 2166 attacks such as timing attacks. Intermediate computed values such as 2167 ephemeral ECDH keys and ECDH shared secrets MUST be deleted after key 2168 derivation is completed. 2170 The Initiator and the Responder are responsible for verifying the 2171 integrity of certificates. The selection of trusted CAs should be 2172 done very carefully and certificate revocation should be supported. 2173 The private authentication keys MUST be kept secret, only the 2174 Responder SHALL have access to the Responder's private authentication 2175 key and only the Initiator SHALL have access to the Initiator's 2176 private authentication key. 2178 The Initiator and the Responder are allowed to select the connection 2179 identifiers C_I and C_R, respectively, for the other party to use in 2180 the ongoing EDHOC protocol as well as in a subsequent application 2181 protocol (e.g., OSCORE [RFC8613]). The choice of connection 2182 identifier is not security critical in EDHOC but intended to simplify 2183 the retrieval of the right security context in combination with using 2184 short identifiers. If the wrong connection identifier of the other 2185 party is used in a protocol message it will result in the receiving 2186 party not being able to retrieve a security context (which will 2187 terminate the protocol) or retrieve the wrong security context (which 2188 also terminates the protocol as the message cannot be verified). 2190 If two nodes unintentionally initiate two simultaneous EDHOC message 2191 exchanges with each other even if they only want to complete a single 2192 EDHOC message exchange, they MAY terminate the exchange with the 2193 lexicographically smallest G_X. If the two G_X values are equal, the 2194 received message_1 MUST be discarded to mitigate reflection attacks. 2195 Note that in the case of two simultaneous EDHOC exchanges where the 2196 nodes only complete one and where the nodes have different preferred 2197 cipher suites, an attacker can affect which of the two nodes' 2198 preferred cipher suites will be used by blocking the other exchange. 2200 If supported by the device, it is RECOMMENDED that at least the long- 2201 term private keys are stored in a Trusted Execution Environment (TEE) 2202 and that sensitive operations using these keys are performed inside 2203 the TEE. To achieve even higher security it is RECOMMENDED that 2204 additional operations such as ephemeral key generation, all 2205 computations of shared secrets, and storage of the PRK keys can be 2206 done inside the TEE. The use of a TEE enforces that code within that 2207 environment cannot be tampered with, and that any data used by such 2208 code cannot be read or tampered with by code outside that 2209 environment. 2211 9. IANA Considerations 2213 9.1. EDHOC Exporter Label Registry 2215 IANA has created a new registry titled "EDHOC Exporter Label" under 2216 the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The 2217 registration procedure is "Expert Review". The columns of the 2218 registry are Label, Description, and Reference. All columns are text 2219 strings where Label consists only of the printable ASCII characters 2220 0x21 - 0x7e. Labels beginning with "PRIVATE" MAY be used for private 2221 use without registration. All other label values MUST be registered. 2222 The initial contents of the registry are: 2224 Label: EDHOC_K_4 2225 Description: Key used to protect EDHOC message_4 2226 Reference: [[this document]] 2228 Label: EDHOC_IV_4 2229 Description: IV used to protect EDHOC message_4 2230 Reference: [[this document]] 2231 Label: OSCORE_Master_Secret 2232 Description: Derived OSCORE Master Secret 2233 Reference: [[this document]] 2235 Label: OSCORE_Master_Salt 2236 Description: Derived OSCORE Master Salt 2237 Reference: [[this document]] 2239 9.2. EDHOC Cipher Suites Registry 2241 IANA has created a new registry titled "EDHOC Cipher Suites" under 2242 the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The 2243 registration procedure is "Expert Review". The columns of the 2244 registry are Value, Array, Description, and Reference, where Value is 2245 an integer and the other columns are text strings. The initial 2246 contents of the registry are: 2248 Value: -24 2249 Algorithms: N/A 2250 Desc: Reserved for Private Use 2251 Reference: [[this document]] 2253 Value: -23 2254 Algorithms: N/A 2255 Desc: Reserved for Private Use 2256 Reference: [[this document]] 2258 Value: -22 2259 Algorithms: N/A 2260 Desc: Reserved for Private Use 2261 Reference: [[this document]] 2263 Value: -21 2264 Algorithms: N/A 2265 Desc: Reserved for Private Use 2266 Reference: [[this document]] 2268 Value: 0 2269 Array: 10, -16, 8, 4, -8, 10, -16 2270 Desc: AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, 2271 AES-CCM-16-64-128, SHA-256 2272 Reference: [[this document]] 2274 Value: 1 2275 Array: 30, -16, 16, 4, -8, 10, -16 2276 Desc: AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, 2277 AES-CCM-16-64-128, SHA-256 2278 Reference: [[this document]] 2279 Value: 2 2280 Array: 10, -16, 8, 1, -7, 10, -16 2281 Desc: AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, 2282 AES-CCM-16-64-128, SHA-256 2283 Reference: [[this document]] 2285 Value: 3 2286 Array: 30, -16, 16, 1, -7, 10, -16 2287 Desc: AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, 2288 AES-CCM-16-64-128, SHA-256 2289 Reference: [[this document]] 2291 Value: 4 2292 Array: 24, -16, 16, 4, -8, 24, -16 2293 Desc: ChaCha20/Poly1305, SHA-256, 16, X25519, EdDSA, 2294 ChaCha20/Poly1305, SHA-256 2295 Reference: [[this document]] 2297 Value: 5 2298 Array: 24, -16, 16, 1, -7, 24, -16 2299 Desc: ChaCha20/Poly1305, SHA-256, 16, P-256, ES256, 2300 ChaCha20/Poly1305, SHA-256 2301 Reference: [[this document]] 2303 Value: 6 2304 Array: 1, -16, 16, 4, -7, 1, -16 2305 Desc: A128GCM, SHA-256, 16, X25519, ES256, 2306 A128GCM, SHA-256 2307 Reference: [[this document]] 2309 Value: 24 2310 Array: 3, -43, 16, 2, -35, 3, -43 2311 Desc: A256GCM, SHA-384, 16, P-384, ES384, 2312 A256GCM, SHA-384 2313 Reference: [[this document]] 2315 Value: 25 2316 Array: 24, -45, 16, 5, -8, 24, -45 2317 Desc: ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA, 2318 ChaCha20/Poly1305, SHAKE256 2319 Reference: [[this document]] 2321 9.3. EDHOC Method Type Registry 2323 IANA has created a new registry entitled "EDHOC Method Type" under 2324 the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The 2325 registration procedure is "Expert Review". The columns of the 2326 registry are Value, Description, and Reference, where Value is an 2327 integer and the other columns are text strings. The initial contents 2328 of the registry are shown in Figure 4. 2330 9.4. EDHOC Error Codes Registry 2332 IANA has created a new registry entitled "EDHOC Error Codes" under 2333 the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The 2334 registration procedure is "Expert Review". The columns of the 2335 registry are ERR_CODE, ERR_INFO Type and Description, where ERR_CODE 2336 is an integer, ERR_INFO is a CDDL defined type, and Description is a 2337 text string. The initial contents of the registry are shown in 2338 Figure 7. 2340 9.5. EDHOC External Authorization Data Registry 2342 IANA has created a new registry entitled "EDHOC External 2343 Authorization Data" under the new group name "Ephemeral Diffie- 2344 Hellman Over COSE (EDHOC)". The registration procedure is "Expert 2345 Review". The columns of the registry are Label, Description, Value 2346 Type, and Reference, where Label is an integer and the other columns 2347 are text strings. 2349 9.6. COSE Header Parameters Registry 2351 IANA has registered the following entries in the "COSE Header 2352 Parameters" registry under the group name "CBOR Object Signing and 2353 Encryption (COSE)". The value of the 'kcwt' header parameter is a 2354 COSE Web Token (CWT) [RFC8392], and the value of the 'kccs' header 2355 parameter is an CWT Claims Set (CCS), see Section 1.5. The CWT/CCS 2356 must contain a COSE_Key in a 'cnf' claim [RFC8747]. The Value 2357 Registry for this item is empty and omitted from the table below. 2359 +-----------+-------+----------------+---------------------------+ 2360 | Name | Label | Value Type | Description | 2361 +===========+=======+================+===========================+ 2362 | kcwt | TBD1 | COSE_Messages | A CBOR Web Token (CWT) | 2363 | | | | containing a COSE_Key in | 2364 | | | | a 'cnf' claim | 2365 +-----------+-------+----------------+---------------------------+ 2366 | kccs | TBD2 | map / #6(map) | A CWT Claims Set (CCS) | 2367 | | | | containing a COSE_Key in | 2368 | | | | a 'cnf' claim | 2369 +-----------+-------+----------------+---------------------------+ 2371 9.7. COSE Header Parameters Registry 2373 IANA has extended the Value Type of 'kid' in the "COSE Header 2374 Parameters" registry under the group name "CBOR Object Signing and 2375 Encryption (COSE)" to also allow the Value Type int. The resulting 2376 Value Type is bstr / int. The Value Registry for this item is empty 2377 and omitted from the table below. 2379 +------+-------+------------+----------------+-------------------+ 2380 | Name | Label | Value Type | Description | Reference | 2381 +------+-------+------------+----------------+-------------------+ 2382 | kid | 4 | bstr / int | Key identifier | [RFC9052] | 2383 | | | | | [[This document]] | 2384 +------+-------+------------+----------------+-------------------+ 2386 9.8. COSE Key Common Parameters Registry 2388 IANA has extended the Value Type of 'kid' in the "COSE Key Common 2389 Parameters" registry under the group name "CBOR Object Signing and 2390 Encryption (COSE)" to also allow the Value Type int. The resulting 2391 Value Type is bstr / int. The Value Registry for this item is empty 2392 and omitted from the table below. 2394 +------+-------+------------+----------------+-------------------+ 2395 | Name | Label | Value Type | Description | Reference | 2396 +------+-------+------------+----------------+-------------------+ 2397 | kid | 2 | bstr / int | Key identifi- | [RFC9052] | 2398 | | | | cation value - | [[This document]] | 2399 | | | | match to kid | | 2400 | | | | in message | | 2401 +------+-------+------------+----------------+-------------------+ 2403 9.9. CWT Confirmation Methods Registry 2405 IANA has extended the Value Type of 'kid' in the "CWT Confirmation 2406 Methods" registry under the group name "CBOR Web Token (CWT) Claims" 2407 to also allow the Value Type int. The incorrect term binary string 2408 has been corrected to bstr. The resulting Value Type is bstr / int. 2409 The new updated content for the 'kid' method is shown in the list 2410 below. 2412 * Confirmation Method Name: kid 2414 * Confirmation Method Description: Key Identifier 2416 * JWT Confirmation Method Name: kid 2418 * Confirmation Key: 3 2420 * Confirmation Value Type(s): bstr / int 2422 * Change Controller: IESG 2424 * Specification Document(s): Section 3.4 of RFC 8747 [[This 2425 document]] 2427 9.10. The Well-Known URI Registry 2429 IANA has added the well-known URI "edhoc" to the "Well-Known URIs" 2430 registry under the group name "Well-Known URIs". 2432 * URI suffix: edhoc 2434 * Change controller: IETF 2436 * Specification document(s): [[this document]] 2438 * Related information: None 2440 9.11. Media Types Registry 2442 IANA has added the media type "application/edhoc" to the "Media 2443 Types" registry. 2445 * Type name: application 2447 * Subtype name: edhoc 2449 * Required parameters: N/A 2450 * Optional parameters: N/A 2452 * Encoding considerations: binary 2454 * Security considerations: See Section 7 of this document. 2456 * Interoperability considerations: N/A 2458 * Published specification: [[this document]] (this document) 2460 * Applications that use this media type: To be identified 2462 * Fragment identifier considerations: N/A 2464 * Additional information: 2466 - Magic number(s): N/A 2468 - File extension(s): N/A 2470 - Macintosh file type code(s): N/A 2472 * Person & email address to contact for further information: See 2473 "Authors' Addresses" section. 2475 * Intended usage: COMMON 2477 * Restrictions on usage: N/A 2479 * Author: See "Authors' Addresses" section. 2481 * Change Controller: IESG 2483 9.12. CoAP Content-Formats Registry 2485 IANA has added the media type "application/edhoc" to the "CoAP 2486 Content-Formats" registry under the group name "Constrained RESTful 2487 Environments (CoRE) Parameters". 2489 * Media Type: application/edhoc 2491 * Encoding: 2493 * ID: TBD42 2495 * Reference: [[this document]] 2497 9.13. Resource Type (rt=) Link Target Attribute Values Registry 2499 IANA has added the resource type "core.edhoc" to the "Resource Type 2500 (rt=) Link Target Attribute Values" registry under the group name 2501 "Constrained RESTful Environments (CoRE) Parameters". 2503 * Value: "core.edhoc" 2505 * Description: EDHOC resource. 2507 * Reference: [[this document]] 2509 Client applications can use this resource type to discover a server's 2510 resource for EDHOC, where to send a request for executing the EDHOC 2511 protocol. 2513 9.14. Expert Review Instructions 2515 The IANA Registries established in this document is defined as 2516 "Expert Review". This section gives some general guidelines for what 2517 the experts should be looking for, but they are being designated as 2518 experts for a reason so they should be given substantial latitude. 2520 Expert reviewers should take into consideration the following points: 2522 * Clarity and correctness of registrations. Experts are expected to 2523 check the clarity of purpose and use of the requested entries. 2524 Expert needs to make sure the values of algorithms are taken from 2525 the right registry, when that is required. Expert should consider 2526 requesting an opinion on the correctness of registered parameters 2527 from relevant IETF working groups. Encodings that do not meet 2528 these objective of clarity and completeness should not be 2529 registered. 2531 * Experts should take into account the expected usage of fields when 2532 approving point assignment. The length of the encoded value 2533 should be weighed against how many code points of that length are 2534 left, the size of device it will be used on, and the number of 2535 code points left that encode to that size. 2537 * Specifications are recommended. When specifications are not 2538 provided, the description provided needs to have sufficient 2539 information to verify the points above. 2541 10. References 2543 10.1. Normative References 2545 [I-D.ietf-core-echo-request-tag] 2546 Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, 2547 Request-Tag, and Token Processing", Work in Progress, 2548 Internet-Draft, draft-ietf-core-echo-request-tag-13, 12 2549 July 2021, . 2552 [I-D.ietf-cose-rfc8152bis-algs] 2553 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2554 Initial Algorithms", Work in Progress, Internet-Draft, 2555 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2556 . 2559 [I-D.ietf-cose-rfc8152bis-struct] 2560 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2561 Structures and Process", Work in Progress, Internet-Draft, 2562 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2563 . 2566 [I-D.ietf-cose-x509] 2567 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2568 Header parameters for carrying and referencing X.509 2569 certificates", Work in Progress, Internet-Draft, draft- 2570 ietf-cose-x509-08, 14 December 2020, 2571 . 2574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2575 Requirement Levels", BCP 14, RFC 2119, 2576 DOI 10.17487/RFC2119, March 1997, 2577 . 2579 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2580 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2581 . 2583 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2584 Housley, R., and W. Polk, "Internet X.509 Public Key 2585 Infrastructure Certificate and Certificate Revocation List 2586 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2587 . 2589 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2590 Key Derivation Function (HKDF)", RFC 5869, 2591 DOI 10.17487/RFC5869, May 2010, 2592 . 2594 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2595 Curve Cryptography Algorithms", RFC 6090, 2596 DOI 10.17487/RFC6090, February 2011, 2597 . 2599 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 2600 Algorithm (DSA) and Elliptic Curve Digital Signature 2601 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2602 2013, . 2604 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2605 Application Protocol (CoAP)", RFC 7252, 2606 DOI 10.17487/RFC7252, June 2014, 2607 . 2609 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 2610 Trammell, B., Huitema, C., and D. Borkmann, 2611 "Confidentiality in the Face of Pervasive Surveillance: A 2612 Threat Model and Problem Statement", RFC 7624, 2613 DOI 10.17487/RFC7624, August 2015, 2614 . 2616 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2617 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2618 2016, . 2620 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2621 the Constrained Application Protocol (CoAP)", RFC 7959, 2622 DOI 10.17487/RFC7959, August 2016, 2623 . 2625 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2626 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2627 May 2017, . 2629 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2630 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2631 . 2633 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2634 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2635 May 2018, . 2637 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2638 Definition Language (CDDL): A Notational Convention to 2639 Express Concise Binary Object Representation (CBOR) and 2640 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2641 June 2019, . 2643 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2644 "Object Security for Constrained RESTful Environments 2645 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2646 . 2648 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2649 Zúñiga, "SCHC: Generic Framework for Static Context Header 2650 Compression and Fragmentation", RFC 8724, 2651 DOI 10.17487/RFC8724, April 2020, 2652 . 2654 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 2655 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 2656 . 2658 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2659 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2660 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2661 2020, . 2663 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2664 Representation (CBOR)", STD 94, RFC 8949, 2665 DOI 10.17487/RFC8949, December 2020, 2666 . 2668 10.2. Informative References 2670 [Bruni18] Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and 2671 C. Schürmann, "Formal Verification of Ephemeral Diffie- 2672 Hellman Over COSE (EDHOC)", November 2018, 2673 . 2677 [CborMe] Bormann, C., "CBOR Playground", May 2018, 2678 . 2680 [CNSA] (Placeholder), ., "Commercial National Security Algorithm 2681 Suite", August 2015, 2682 . 2685 [I-D.ietf-core-oscore-edhoc] 2686 Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., 2687 and G. Selander, "Combining EDHOC and OSCORE", Work in 2688 Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-01, 2689 12 July 2021, . 2692 [I-D.ietf-core-resource-directory] 2693 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 2694 D. Stok, "CoRE Resource Directory", Work in Progress, 2695 Internet-Draft, draft-ietf-core-resource-directory-28, 7 2696 March 2021, . 2699 [I-D.ietf-cose-cbor-encoded-cert] 2700 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 2701 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 2702 Certificates)", Work in Progress, Internet-Draft, draft- 2703 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 2704 . 2707 [I-D.ietf-lake-reqs] 2708 Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia- 2709 Carrillo, "Requirements for a Lightweight AKE for OSCORE", 2710 Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04, 2711 8 June 2020, . 2714 [I-D.ietf-lwig-security-protocol-comparison] 2715 Mattsson, J. P., Palombini, F., and M. Vucinic, 2716 "Comparison of CoAP Security Protocols", Work in Progress, 2717 Internet-Draft, draft-ietf-lwig-security-protocol- 2718 comparison-05, 2 November 2020, 2719 . 2722 [I-D.ietf-tls-dtls13] 2723 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2724 Datagram Transport Layer Security (DTLS) Protocol Version 2725 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 2726 dtls13-43, 30 April 2021, . 2729 [I-D.mattsson-cfrg-det-sigs-with-noise] 2730 Mattsson, J. P., Thormarker, E., and S. Ruohomaa, 2731 "Deterministic ECDSA and EdDSA Signatures with Additional 2732 Randomness", Work in Progress, Internet-Draft, draft- 2733 mattsson-cfrg-det-sigs-with-noise-02, 11 March 2020, 2734 . 2737 [I-D.selander-ace-ake-authz] 2738 Selander, G., Mattsson, J. P., Vucinic, M., Richardson, 2739 M., and A. Schellenbaum, "Lightweight Authorization for 2740 Authenticated Key Exchange.", Work in Progress, Internet- 2741 Draft, draft-selander-ace-ake-authz-03, 4 May 2021, 2742 . 2745 [I-D.selander-lake-traces] 2746 Selander, G. and J. P. Mattsson, "Traces of EDHOC", Work 2747 in Progress, Internet-Draft, draft-selander-lake-traces- 2748 00, 10 September 2021, . 2751 [Norrman20] 2752 Norrman, K., Sundararajan, V., and A. Bruni, "Formal 2753 Analysis of EDHOC Key Establishment for Constrained IoT 2754 Devices", September 2020, 2755 . 2757 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2758 Constrained-Node Networks", RFC 7228, 2759 DOI 10.17487/RFC7228, May 2014, 2760 . 2762 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2763 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2764 2014, . 2766 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2767 Kivinen, "Internet Key Exchange Protocol Version 2 2768 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2769 2014, . 2771 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2772 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2773 . 2775 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 2776 and C. Wood, "Randomness Improvements for Security 2777 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 2778 . 2780 [SECG] "Standards for Efficient Cryptography 1 (SEC 1)", May 2781 2009, . 2783 [SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to 2784 Authenticated Diffie-Hellman and Its Use in the IKE- 2785 Protocols (Long version)", June 2003, 2786 . 2788 [SP-800-56A] 2789 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 2790 Davis, "Recommendation for Pair-Wise Key-Establishment 2791 Schemes Using Discrete Logarithm Cryptography", 2792 NIST Special Publication 800-56A Revision 3, April 2018, 2793 . 2795 Appendix A. Use with OSCORE and Transfer over CoAP 2797 This appendix describes how to select EDHOC connection identifiers 2798 and derive an OSCORE security context when OSCORE is used with EDHOC, 2799 and how to transfer EDHOC messages over CoAP. 2801 A.1. Selecting EDHOC Connection Identifier 2803 This section specifies a rule for converting from EDHOC connection 2804 identifier to OSCORE Sender/Recipient ID. (An identifier is Sender 2805 ID or Recipient ID depending on from which endpoint is the point of 2806 view, see Section 3.1 of [RFC8613].) 2808 * If the EDHOC connection identifier is numeric, i.e., encoded as a 2809 CBOR integer on the wire, it is converted to a (naturally byte- 2810 string shaped) OSCORE Sender/Recipient ID equal to its CBOR 2811 encoded form. 2813 For example, a numeric C_R equal to 10 (0x0A in CBOR encoding) is 2814 converted to a (typically client) Sender ID equal to 0x0A, while a 2815 numeric C_I equal to -12 (0x2B in CBOR encoding) is converted to a 2816 (typically client) Sender ID equal to 0x2B. 2818 * If the EDHOC connection identifier is byte-valued, hence encoded 2819 as a CBOR byte string on the wire, it is converted to an OSCORE 2820 Sender/Recipient ID equal to the byte string. 2822 For example, a byte-string valued C_R equal to 0xFF (0x41FF in CBOR 2823 encoding) is converted to a (typically client) Sender ID equal to 2824 0xFF. 2826 Two EDHOC connection identifiers are called "equivalent" if and only 2827 if, by applying the conversion above, they both result in the same 2828 OSCORE Sender/Recipient ID. For example, the two EDHOC connection 2829 identifiers with CBOR encoding 0x0A (numeric) and 0x410A (byte- 2830 valued) are equivalent since they both result in the same OSCORE 2831 Sender/Recipient ID 0x0A. 2833 When EDHOC is used to establish an OSCORE security context, the 2834 connection identifiers C_I and C_R MUST NOT be equivalent. 2835 Furthermore, in case of multiple OSCORE security contexts with 2836 potentially different endpoints, to facilitate retrieval of the 2837 correct OSCORE security context, an endpoint SHOULD select an EDHOC 2838 connection identifier that when converted to OSCORE Recipient ID does 2839 not coincide with its other Recipient IDs. 2841 A.2. Deriving the OSCORE Security Context 2843 This section specifies how to use EDHOC output to derive the OSCORE 2844 security context. 2846 After successful processing of EDHOC message_3, Client and Server 2847 derive Security Context parameters for OSCORE as follows (see 2848 Section 3.2 of [RFC8613]): 2850 * The Master Secret and Master Salt are derived by using the EDHOC- 2851 Exporter interface, see Section 4.3. 2853 The EDHOC Exporter Labels for deriving the OSCORE Master Secret and 2854 the OSCORE Master Salt, are "OSCORE_Master_Secret" and 2855 "OSCORE_Master_Salt", respectively. 2857 The context parameter is h'' (0x40), the empty CBOR byte string. 2859 By default, key_length is the key length (in bytes) of the 2860 application AEAD Algorithm of the selected cipher suite for the EDHOC 2861 session. Also by default, salt_length has value 8. The Initiator 2862 and Responder MAY agree out-of-band on a longer key_length than the 2863 default and on a different salt_length. 2865 Master Secret = EDHOC-Exporter("OSCORE_Master_Secret", h'', key_length) 2866 Master Salt = EDHOC-Exporter("OSCORE_Master_Salt", h'', salt_length) 2868 * The AEAD Algorithm is the application AEAD algorithm of the 2869 selected cipher suite for the EDHOC session. 2871 * The HKDF Algorithm is the one based on the application hash 2872 algorithm of the selected cipher suite for the EDHOC session. For 2873 example, if SHA-256 is the application hash algorithm of the 2874 selected cipher suite, HKDF SHA-256 is used as HKDF Algorithm in 2875 the OSCORE Security Context. 2877 * In case the Client is Initiator and the Server is Responder, the 2878 Client's OSCORE Sender ID and the Server's OSCORE Sender ID are 2879 determined from the EDHOC connection identifiers C_R and C_I for 2880 the EDHOC session, respectively, by applying the conversion in 2881 Appendix A.1. The reverse applies in case the Client is the 2882 Responder and the Server is the Initiator. 2884 Client and Server use the parameters above to establish an OSCORE 2885 Security Context, as per Section 3.2.1 of [RFC8613]. 2887 From then on, Client and Server retrieve the OSCORE protocol state 2888 using the Recipient ID, and optionally other transport information 2889 such as the 5-tuple. 2891 A.3. Transferring EDHOC over CoAP 2893 This section specifies one instance for how EDHOC can be transferred 2894 as an exchange of CoAP [RFC7252] messages. CoAP provides a reliable 2895 transport that can preserve packet ordering and handle message 2896 duplication. CoAP can also perform fragmentation and protect against 2897 denial-of-service attacks. The underlying CoAP transport should be 2898 used in reliable mode, in particular when fragmentation is used, to 2899 avoid, e.g., situations with hanging endpoints waiting for each 2900 other. 2902 By default, the CoAP client is the Initiator and the CoAP server is 2903 the Responder, but the roles SHOULD be chosen to protect the most 2904 sensitive identity, see Section 8. According to this specification, 2905 EDHOC is transferred in POST requests and 2.04 (Changed) responses to 2906 the Uri-Path: "/.well-known/edhoc". An application may define its 2907 own path that can be discovered, e.g., using resource directory 2908 [I-D.ietf-core-resource-directory]. 2910 By default, the message flow is as follows: EDHOC message_1 is sent 2911 in the payload of a POST request from the client to the server's 2912 resource for EDHOC. EDHOC message_2 or the EDHOC error message is 2913 sent from the server to the client in the payload of a 2.04 (Changed) 2914 response. EDHOC message_3 or the EDHOC error message is sent from 2915 the client to the server's resource in the payload of a POST request. 2916 If needed, an EDHOC error message is sent from the server to the 2917 client in the payload of a 2.04 (Changed) response. Alternatively, 2918 if EDHOC message_4 is used, it is sent from the server to the client 2919 in the payload of a 2.04 (Changed) response analogously to message_2. 2921 In order to correlate a message received from a client to a message 2922 previously sent by the server, messages sent by the client are 2923 prepended with the CBOR serialization of the connection identifier 2924 which the server has chosen. This applies independently of if the 2925 CoAP server is Responder or Initiator. For the default case when the 2926 server is Responder, the prepended connection identifier is C_R, and 2927 C_I if the server is Initiator. If message_1 is sent to the server, 2928 the CBOR simple value "true" (0xf5) is sent in its place (given that 2929 the server has not selected C_R yet). 2931 These identifiers are encoded in CBOR and thus self-delimiting. They 2932 are sent in front of the actual EDHOC message, and only the part of 2933 the body following the identifier is used for EDHOC processing. 2935 Consequently, the application/edhoc media type does not apply to 2936 these messages; their media type is unnamed. 2938 An example of a successful EDHOC exchange using CoAP is shown in 2939 Figure 10. In this case the CoAP Token enables correlation on the 2940 Initiator side, and the prepended C_R enables correlation on the 2941 Responder (server) side. 2943 Client Server 2944 | | 2945 +--------->| Header: POST (Code=0.02) 2946 | POST | Uri-Path: "/.well-known/edhoc" 2947 | | Payload: true, EDHOC message_1 2948 | | 2949 |<---------+ Header: 2.04 Changed 2950 | 2.04 | Content-Format: application/edhoc 2951 | | Payload: EDHOC message_2 2952 | | 2953 +--------->| Header: POST (Code=0.02) 2954 | POST | Uri-Path: "/.well-known/edhoc" 2955 | | Payload: C_R, EDHOC message_3 2956 | | 2957 |<---------+ Header: 2.04 Changed 2958 | 2.04 | 2959 | | 2961 Figure 10: Transferring EDHOC in CoAP when the Initiator is CoAP 2962 Client 2964 The exchange in Figure 10 protects the client identity against active 2965 attackers and the server identity against passive attackers. 2967 An alternative exchange that protects the server identity against 2968 active attackers and the client identity against passive attackers is 2969 shown in Figure 11. In this case the CoAP Token enables the 2970 Responder to correlate message_2 and message_3, and the prepended C_I 2971 enables correlation on the Initiator (server) side. If EDHOC 2972 message_4 is used, C_I is prepended, and it is transported with CoAP 2973 in the payload of a POST request with a 2.04 (Changed) response. 2975 Client Server 2976 | | 2977 +--------->| Header: POST (Code=0.02) 2978 | POST | Uri-Path: "/.well-known/edhoc" 2979 | | 2980 |<---------+ Header: 2.04 Changed 2981 | 2.04 | Content-Format: application/edhoc 2982 | | Payload: EDHOC message_1 2983 | | 2984 +--------->| Header: POST (Code=0.02) 2985 | POST | Uri-Path: "/.well-known/edhoc" 2986 | | Payload: C_I, EDHOC message_2 2987 | | 2988 |<---------+ Header: 2.04 Changed 2989 | 2.04 | Content-Format: application/edhoc 2990 | | Payload: EDHOC message_3 2991 | | 2993 Figure 11: Transferring EDHOC in CoAP when the Initiator is CoAP 2994 Server 2996 To protect against denial-of-service attacks, the CoAP server MAY 2997 respond to the first POST request with a 4.01 (Unauthorized) 2998 containing an Echo option [I-D.ietf-core-echo-request-tag]. This 2999 forces the initiator to demonstrate its reachability at its apparent 3000 network address. If message fragmentation is needed, the EDHOC 3001 messages may be fragmented using the CoAP Block-Wise Transfer 3002 mechanism [RFC7959]. 3004 EDHOC does not restrict how error messages are transported with CoAP, 3005 as long as the appropriate error message can to be transported in 3006 response to a message that failed (see Section 6). EDHOC error 3007 messages transported with CoAP are carried in the payload. 3009 A.3.1. Transferring EDHOC and OSCORE over CoAP 3011 When using EDHOC over CoAP for establishing an OSCORE Security 3012 Context, EDHOC error messages sent as CoAP responses MUST be sent in 3013 the payload of error responses, i.e., they MUST specify a CoAP error 3014 response code. In particular, it is RECOMMENDED that such error 3015 responses have response code either 4.00 (Bad Request) in case of 3016 client error (e.g., due to a malformed EDHOC message), or 5.00 3017 (Internal Server Error) in case of server error (e.g., due to failure 3018 in deriving EDHOC key material). The Content-Format of the error 3019 response MUST be set to application/edhoc. 3021 A method for combining EDHOC and OSCORE protocols in two round-trips 3022 is specified in [I-D.ietf-core-oscore-edhoc]. 3024 Appendix B. Compact Representation 3026 As described in Section 4.2 of [RFC6090] the x-coordinate of an 3027 elliptic curve public key is a suitable representative for the entire 3028 point whenever scalar multiplication is used as a one-way function. 3029 One example is ECDH with compact output, where only the x-coordinate 3030 of the computed value is used as the shared secret. 3032 This section defines a format for compact representation based on the 3033 Elliptic-Curve-Point-to-Octet-String Conversion defined in 3034 Section 2.3.3 of [SECG]. Using the notation from [SECG], the output 3035 is an octet string of length ceil( (log2 q) / 8 ). See [SECG] for a 3036 definition of q, M, X, xp, and ~yp. The steps in Section 2.3.3 of 3037 [SECG] are replaced by: 3039 1. Convert the field element xp to an octet string X of length ceil( 3040 (log2 q) / 8 ) octets using the conversion routine specified in 3041 Section 2.3.5 of [SECG]. 3043 2. Output M = X 3045 The encoding of the point at infinity is not supported. Compact 3046 representation does not change any requirements on validation. If a 3047 y-coordinate is required for validation or compatibily with APIs the 3048 value ~yp SHALL be set to zero. For such use, the compact 3049 representation can be transformed into the SECG point compressed 3050 format by prepending it with the single byte 0x02 (i.e., M = 0x02 || 3051 X). 3053 Using compact representation have some security benefits. An 3054 implementation does not need to check that the point is not the point 3055 at infinity (the identity element). Similarly, as not even the sign 3056 of the y-coordinate is encoded, compact representation trivially 3057 avoids so called "benign malleability" attacks where an attacker 3058 changes the sign, see [SECG]. 3060 Appendix C. Use of CBOR, CDDL and COSE in EDHOC 3062 This Appendix is intended to simplify for implementors not familiar 3063 with CBOR [RFC8949], CDDL [RFC8610], COSE 3064 [I-D.ietf-cose-rfc8152bis-struct], and HKDF [RFC5869]. 3066 C.1. CBOR and CDDL 3068 The Concise Binary Object Representation (CBOR) [RFC8949] is a data 3069 format designed for small code size and small message size. CBOR 3070 builds on the JSON data model but extends it by e.g., encoding binary 3071 data directly without base64 conversion. In addition to the binary 3072 CBOR encoding, CBOR also has a diagnostic notation that is readable 3073 and editable by humans. The Concise Data Definition Language (CDDL) 3074 [RFC8610] provides a way to express structures for protocol messages 3075 and APIs that use CBOR. [RFC8610] also extends the diagnostic 3076 notation. 3078 CBOR data items are encoded to or decoded from byte strings using a 3079 type-length-value encoding scheme, where the three highest order bits 3080 of the initial byte contain information about the major type. CBOR 3081 supports several different types of data items, in addition to 3082 integers (int, uint), simple values, byte strings (bstr), and text 3083 strings (tstr), CBOR also supports arrays [] of data items, maps {} 3084 of pairs of data items, and sequences [RFC8742] of data items. Some 3085 examples are given below. 3087 The EDHOC specification sometimes use CDDL names in CBOR dignostic 3088 notation as in e.g., << ID_CRED_R, ? EAD_2 >>. This means that EAD_2 3089 is optional and that ID_CRED_R and EAD_2 should be substituted with 3090 their values before evaluation. I.e., if ID_CRED_R = { 4 : h'' } and 3091 EAD_2 is omitted then << ID_CRED_R, ? EAD_2 >> = << { 4 : h'' } >>, 3092 which encodes to 0x43a10440. 3094 For a complete specification and more examples, see [RFC8949] and 3095 [RFC8610]. We recommend implementors to get used to CBOR by using 3096 the CBOR playground [CborMe]. 3098 Diagnostic Encoded Type 3099 ------------------------------------------------------------------ 3100 1 0x01 unsigned integer 3101 24 0x1818 unsigned integer 3102 -24 0x37 negative integer 3103 -25 0x3818 negative integer 3104 true 0xf5 simple value 3105 h'' 0x40 byte string 3106 h'12cd' 0x4212cd byte string 3107 '12cd' 0x4431326364 byte string 3108 "12cd" 0x6431326364 text string 3109 { 4 : h'cd' } 0xa10441cd map 3110 << 1, 2, true >> 0x430102f5 byte string 3111 [ 1, 2, true ] 0x830102f5 array 3112 ( 1, 2, true ) 0x0102f5 sequence 3113 1, 2, true 0x0102f5 sequence 3114 ------------------------------------------------------------------ 3116 C.2. CDDL Definitions 3118 This sections compiles the CDDL definitions for ease of reference. 3120 suites = [ 2* int ] / int 3122 ead = 1* ( 3123 ead_label : int, 3124 ead_value : any, 3125 ) 3127 message_1 = ( 3128 METHOD : int, 3129 SUITES_I : suites, 3130 G_X : bstr, 3131 C_I : bstr / int, 3132 ? EAD_1 : ead, 3133 ) 3135 message_2 = ( 3136 G_Y_CIPHERTEXT_2 : bstr, 3137 C_R : bstr / int, 3138 ) 3140 message_3 = ( 3141 CIPHERTEXT_3 : bstr, 3142 ) 3144 message_4 = ( 3145 CIPHERTEXT_4 : bstr, 3146 ) 3148 error = ( 3149 ERR_CODE : int, 3150 ERR_INFO : any, 3151 ) 3153 info = ( 3154 transcript_hash : bstr, 3155 label : tstr, 3156 context : bstr, 3157 length : uint, 3158 ) 3160 C.3. COSE 3162 CBOR Object Signing and Encryption (COSE) 3163 [I-D.ietf-cose-rfc8152bis-struct] describes how to create and process 3164 signatures, message authentication codes, and encryption using CBOR. 3165 COSE builds on JOSE, but is adapted to allow more efficient 3166 processing in constrained devices. EDHOC makes use of COSE_Key, 3167 COSE_Encrypt0, and COSE_Sign1 objects in the message processing: 3169 * ECDH ephemeral public keys of type EC2 or OKP in message_1 and 3170 message_2 consist of the COSE_Key parameter named 'x', see 3171 Section 7.1 and 7.2 of [I-D.ietf-cose-rfc8152bis-algs] 3173 * Certain ciphertexts in message_2 and message_3 consist of a subset 3174 of the single recipient encrypted data object COSE_Encrypt0, which 3175 is described in Sections 5.2-5.3 of 3176 [I-D.ietf-cose-rfc8152bis-struct]. The ciphertext is computed 3177 over the plaintext and associated data, using an encryption key 3178 and a nonce. The associated data is an Enc_structure consisting 3179 of protected headers and externally supplied data (external_aad). 3181 * Signatures in message_2 of method 0 and 2, and in message_3 of 3182 method 0 and 1, consist of a subset of the single signer data 3183 object COSE_Sign1, which is described in Sections 4.2-4.4 of 3184 [I-D.ietf-cose-rfc8152bis-struct]. The signature is computed over 3185 a Sig_structure containing payload, protected headers and 3186 externally supplied data (external_aad) using a private signature 3187 key and verified using the corresponding public signature key. 3189 Different header parameters to identify X.509 or C509 certificates by 3190 reference are defined in [I-D.ietf-cose-x509] and 3191 [I-D.ietf-cose-cbor-encoded-cert]: 3193 * by a hash value with the 'x5t' or 'c5t' parameters, respectively: 3195 - ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, 3197 - ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R; 3199 * or by a URI with the 'x5u' or 'c5u' parameters, respectively: 3201 - ID_CRED_x = { 35 : uri }, for x = I or R, 3203 - ID_CRED_x = { TBD4 : uri }, for x = I or R. 3205 When ID_CRED_x does not contain the actual credential, it may be very 3206 short, e.g., if the endpoints have agreed to use a key identifier 3207 parameter 'kid': 3209 * ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or 3210 R. 3212 Note that a COSE header map can contain several header parameters, 3213 for example { x5u, x5t } or { kid, kid_context }. 3215 ID_CRED_x MAY also identify the authentication credential by value. 3216 For example, a certificate chain can be transported in ID_CRED_x with 3217 COSE header parameter c5c or x5chain, defined in 3218 [I-D.ietf-cose-cbor-encoded-cert] and [I-D.ietf-cose-x509] and 3219 credentials of type CWT and CCS can be transported with the COSE 3220 header parameters registered in Section 9.6. 3222 Appendix D. Applicability Template 3224 This appendix contains a rudimentary example of an applicability 3225 statement, see Section 3.9. 3227 For use of EDHOC in the XX protocol, the following assumptions are 3228 made: 3230 1. Transfer in CoAP as specified in Appendix A.3 with requests 3231 expected by the CoAP server (= Responder) at /app1-edh, no 3232 Content-Format needed. 3234 2. METHOD = 1 (I uses signature key, R uses static DH key.) 3236 3. CRED_I is an IEEE 802.1AR IDevID encoded as a C509 certificate of 3237 type 0 [I-D.ietf-cose-cbor-encoded-cert]. 3239 * R acquires CRED_I out-of-band, indicated in EAD_1. 3241 * ID_CRED_I = {4: h''} is a 'kid' with value empty CBOR byte 3242 string. 3244 4. CRED_R is a CCS of type OKP as specified in Section 3.5.3. 3246 * The CBOR map has parameters 1 (kty), -1 (crv), and -2 3247 (x-coordinate). 3249 * ID_CRED_R is {TBD2 : CCS}. Editor's note: TBD2 is the COSE 3250 header parameter value of 'kccs', see Section 9.6 3252 5. External authorization data is defined and processed as specified 3253 in [I-D.selander-ace-ake-authz]. 3255 6. EUI-64 used as identity of endpoint. 3257 7. No use of message_4: the application sends protected messages 3258 from R to I. 3260 Appendix E. EDHOC Message Deduplication 3262 EDHOC by default assumes that message duplication is handled by the 3263 transport, in this section exemplified with CoAP. 3265 Deduplication of CoAP messages is described in Section 4.5 of 3266 [RFC7252]. This handles the case when the same Confirmable (CON) 3267 message is received multiple times due to missing acknowledgement on 3268 CoAP messaging layer. The recommended processing in [RFC7252] is 3269 that the duplicate message is acknowledged (ACK), but the received 3270 message is only processed once by the CoAP stack. 3272 Message deduplication is resource demanding and therefore not 3273 supported in all CoAP implementations. Since EDHOC is targeting 3274 constrained environments, it is desirable that EDHOC can optionally 3275 support transport layers which does not handle message duplication. 3276 Special care is needed to avoid issues with duplicate messages, see 3277 Section 5.1. 3279 The guiding principle here is similar to the deduplication processing 3280 on CoAP messaging layer: a received duplicate EDHOC message SHALL NOT 3281 result in a response consisting of another instance of the next EDHOC 3282 message. The result MAY be that a duplicate EDHOC response is sent, 3283 provided it is still relevant with respect the current protocol 3284 state. In any case, the received message MUST NOT be processed more 3285 than once in the same EDHOC session. This is called "EDHOC message 3286 deduplication". 3288 An EDHOC implementation MAY store the previously sent EDHOC message 3289 to be able to resend it. An EDHOC implementation MAY keep the 3290 protocol state to be able to recreate the previously sent EDHOC 3291 message and resend it. The previous message or protocol state MUST 3292 NOT be kept longer than what is required for retransmission, for 3293 example, in the case of CoAP transport, no longer than the 3294 EXCHANGE_LIFETIME (see Section 4.8.2 of [RFC7252]). 3296 Note that the requirements in Section 5.1 still apply because 3297 duplicate messages are not processed by the EDHOC state machine: 3299 * EDHOC messages SHALL be processed according to the current 3300 protocol state. 3302 * Different instances of the same message MUST NOT be processed in 3303 one session. 3305 Appendix F. Transports Not Natively Providing Correlation 3307 Protocols that do not natively provide full correlation between a 3308 series of messages can send the C_I and C_R identifiers along as 3309 needed. 3311 The transport over CoAP (Appendix A.3) can serve as a blueprint for 3312 other server-client protocols: The client prepends the C_x which the 3313 server selected (or, for message 1, the CBOR simple value 'true' 3314 which is not a valid C_x) to any request message it sends. The 3315 server does not send any such indicator, as responses are matched to 3316 request by the client-server protocol design. 3318 Protocols that do not provide any correlation at all can prescribe 3319 prepending of the peer's chosen C_x to all messages. 3321 Appendix G. Change Log 3323 RFC Editor: Please remove this appendix. 3325 * From -10 to -11: 3327 - Restructured section on authentication parameters 3329 - Changed UCCS to CCS 3331 - Changed names and description of COSE header parameters for 3332 CWT/CCS 3334 - Changed several of the KDF and Exporter labels 3336 - Removed edhoc_aead_id from info (already in transcript_hash) 3338 - Added MTI section 3340 - EAD: changed CDDL names and added value type to registry 3342 - Updated Figures 1, 2, and 3 3344 - Some correction and clarifications 3346 - Added core.edhoc to CoRE Resource Type registry 3348 * From -09 to -10: 3350 - SUITES_I simplified to only contain the selected and more 3351 preferred suites 3353 - Info is a CBOR sequence and context is a bstr 3355 - Added kid to UCCS example 3357 - Separate header parameters for CWT and UCCS 3359 - CWT Confirmation Method kid extended to bstr / int 3361 * From -08 to -09: 3363 - G_Y and CIPHERTEXT_2 are now included in one CBOR bstr 3365 - MAC_2 and MAC_3 are now generated with EDHOC-KDF 3367 - Info field "context" is now general and explicit in EDHOC-KDF 3369 - Restructured Section 4, Key Derivation 3371 - Added EDHOC MAC length to cipher suite for use with static DH 3373 - More details on the use of CWT and UCCS 3375 - Restructured and clarified Section 3.5, Authentication 3376 Parameters 3378 - Replaced 'kid2' with extension of 'kid' 3380 - EAD encoding now supports multiple ead types in one message 3382 - Clarified EAD type 3384 - Updated message sizes 3386 - Replaced "perfect forward secrecy" with "forward secrecy" 3388 - Updated security considerations 3390 - Replaced prepended 'null' with 'true' in the CoAP transport of 3391 message_1 3393 - Updated CDDL definitions 3395 - Expanded on the use of COSE 3397 * From -07 to -08: 3399 - Prepended C_x moved from the EDHOC protocol itself to the 3400 transport mapping 3402 - METHOD_CORR renamed to METHOD, corr removed 3404 - Removed bstr_identifier and use bstr / int instead; C_x can now 3405 be int without any implied bstr semantics 3407 - Defined COSE header parameter 'kid2' with value type bstr / int 3408 for use with ID_CRED_x 3410 - Updated message sizes 3412 - New cipher suites with AES-GCM and ChaCha20 / Poly1305 3414 - Changed from one- to two-byte identifier of CNSA compliant 3415 suite 3417 - Separate sections on transport and connection id with further 3418 sub-structure 3420 - Moved back key derivation for OSCORE from draft-ietf-core- 3421 oscore-edhoc 3423 - OSCORE and CoAP specific processing moved to new appendix 3425 - Message 4 section moved to message processing section 3427 * From -06 to -07: 3429 - Changed transcript hash definition for TH_2 and TH_3 3431 - Removed "EDHOC signature algorithm curve" from cipher suite 3433 - New IANA registry "EDHOC Exporter Label" 3435 - New application defined parameter "context" in EDHOC-Exporter 3437 - Changed normative language for failure from MUST to SHOULD send 3438 error 3440 - Made error codes non-negative and 0 for success 3442 - Added detail on success error code 3444 - Aligned terminology "protocol instance" -> "session" 3446 - New appendix on compact EC point representation 3448 - Added detail on use of ephemeral public keys 3449 - Moved key derivation for OSCORE to draft-ietf-core-oscore-edhoc 3451 - Additional security considerations 3453 - Renamed "Auxililary Data" as "External Authorization Data" 3455 - Added encrypted EAD_4 to message_4 3457 * From -05 to -06: 3459 - New section 5.2 "Message Processing Outline" 3461 - Optional inital byte C_1 = null in message_1 3463 - New format of error messages, table of error codes, IANA 3464 registry 3466 - Change of recommendation transport of error in CoAP 3468 - Merge of content in 3.7 and appendix C into new section 3.7 3469 "Applicability Statement" 3471 - Requiring use of deterministic CBOR 3473 - New section on message deduplication 3475 - New appendix containin all CDDL definitions 3477 - New appendix with change log 3479 - Removed section "Other Documents Referencing EDHOC" 3481 - Clarifications based on review comments 3483 * From -04 to -05: 3485 - EDHOC-Rekey-FS -> EDHOC-KeyUpdate 3487 - Clarification of cipher suite negotiation 3489 - Updated security considerations 3491 - Updated test vectors 3493 - Updated applicability statement template 3495 * From -03 to -04: 3497 - Restructure of section 1 3499 - Added references to C509 Certificates 3501 - Change in CIPHERTEXT_2 -> plaintext XOR KEYSTREAM_2 (test 3502 vector not updated) 3504 - "K_2e", "IV_2e" -> KEYSTREAM_2 3506 - Specified optional message 4 3508 - EDHOC-Exporter-FS -> EDHOC-Rekey-FS 3510 - Less constrained devices SHOULD implement both suite 0 and 2 3512 - Clarification of error message 3514 - Added exporter interface test vector 3516 * From -02 to -03: 3518 - Rearrangements of section 3 and beginning of section 4 3520 - Key derivation new section 4 3522 - Cipher suites 4 and 5 added 3524 - EDHOC-EXPORTER-FS - generate a new PRK_4x3m from an old one 3526 - Change in CIPHERTEXT_2 -> COSE_Encrypt0 without tag (no change 3527 to test vector) 3529 - Clarification of error message 3531 - New appendix C applicability statement 3533 * From -01 to -02: 3535 - New section 1.2 Use of EDHOC 3537 - Clarification of identities 3539 - New section 4.3 clarifying bstr_identifier 3541 - Updated security considerations 3543 - Updated text on cipher suite negotiation and key confirmation 3544 - Test vector for static DH o 3546 * From -00 to -01: 3548 - Removed PSK method 3550 - Removed references to certificate by value 3552 Acknowledgments 3554 The authors want to thank Christian Amsuess, Alessandro Bruni, 3555 Karthikeyan Bhargavan, Timothy Claeys, Martin Disch, Loic Ferreira, 3556 Theis Groenbech Petersen, Dan Harkins, Klaus Hartke, Russ Housley, 3557 Stefan Hristozov, Alexandros Krontiris, Ilari Liusvaara, Karl 3558 Norrman, Salvador Perez, Eric Rescorla, Michael Richardson, Thorvald 3559 Sahl Joergensen, Jim Schaad, Carsten Schuermann, Ludwig Seitz, 3560 Stanislav Smyshlyaev, Valery Smyslov, Peter van der Stok, Rene 3561 Struik, Vaishnavi Sundararajan, Erik Thormarker, Marco Tiloca, Michel 3562 Veillette, and Malisa Vucinic for reviewing and commenting on 3563 intermediate versions of the draft. We are especially indebted to 3564 Jim Schaad for his continuous reviewing and implementation of 3565 different versions of the draft. 3567 Work on this document has in part been supported by the H2020 project 3568 SIFIS-Home (grant agreement 952652). 3570 Authors' Addresses 3572 Göran Selander 3573 Ericsson AB 3574 SE-164 80 Stockholm 3575 Sweden 3577 Email: goran.selander@ericsson.com 3579 John Preuß Mattsson 3580 Ericsson AB 3581 SE-164 80 Stockholm 3582 Sweden 3584 Email: john.mattsson@ericsson.com 3585 Francesca Palombini 3586 Ericsson AB 3587 SE-164 80 Stockholm 3588 Sweden 3590 Email: francesca.palombini@ericsson.com