idnits 2.17.1 draft-ietf-lake-edhoc-09.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2470): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2573): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2594): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2617): 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 (23 August 2021) is 975 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '6' on line 1872 -- Looks like a reference, but probably isn't: '5' on line 1872 -- Looks like a reference, but probably isn't: '9' on line 1868 -- Looks like a reference, but probably isn't: '8' on line 1872 -- Looks like a reference, but probably isn't: '7' on line 1872 == Missing Reference: 'RFC9052' is mentioned on line 2354, 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 (-09) exists of draft-ietf-rats-uccs-01 == 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 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: 24 February 2022 Ericsson 6 23 August 2021 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-ietf-lake-edhoc-09 11 Abstract 13 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 14 very compact and lightweight authenticated Diffie-Hellman key 15 exchange with ephemeral keys. EDHOC provides mutual authentication, 16 forward secrecy, and identity protection. EDHOC is intended for 17 usage in constrained scenarios and a main use case is to establish an 18 OSCORE security context. By reusing COSE for cryptography, CBOR for 19 encoding, and CoAP for transport, the additional code size can be 20 kept very low. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 24 February 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 5 59 1.4. Document Structure . . . . . . . . . . . . . . . . . . . 6 60 1.5. Terminology and Requirements Language . . . . . . . . . . 6 61 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 63 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.3. Connection Identifiers . . . . . . . . . . . . . . . . . 10 66 3.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.5. Authentication Parameters . . . . . . . . . . . . . . . . 12 68 3.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 18 69 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 20 70 3.8. External Authorization Data (EAD) . . . . . . . . . . . . 20 71 3.9. Applicability Statement . . . . . . . . . . . . . . . . . 21 72 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 23 73 4.1. Extract . . . . . . . . . . . . . . . . . . . . . . . . . 23 74 4.2. Expand . . . . . . . . . . . . . . . . . . . . . . . . . 24 75 4.3. EDHOC-Exporter . . . . . . . . . . . . . . . . . . . . . 26 76 4.4. EDHOC-KeyUpdate . . . . . . . . . . . . . . . . . . . . . 27 77 5. Message Formatting and Processing . . . . . . . . . . . . . . 27 78 5.1. Message Processing Outline . . . . . . . . . . . . . . . 27 79 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 28 80 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 30 81 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 32 82 5.5. EDHOC Message 4 . . . . . . . . . . . . . . . . . . . . . 36 83 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 37 84 6.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 39 85 6.2. Unspecified . . . . . . . . . . . . . . . . . . . . . . . 39 86 6.3. Wrong Selected Cipher Suite . . . . . . . . . . . . . . . 39 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 88 7.1. Security Properties . . . . . . . . . . . . . . . . . . . 41 89 7.2. Cryptographic Considerations . . . . . . . . . . . . . . 44 90 7.3. Cipher Suites and Cryptographic Algorithms . . . . . . . 45 91 7.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 45 92 7.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 46 93 7.6. Implementation Considerations . . . . . . . . . . . . . . 46 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 95 8.1. EDHOC Exporter Label . . . . . . . . . . . . . . . . . . 48 96 8.2. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 48 97 8.3. EDHOC Method Type Registry . . . . . . . . . . . . . . . 50 98 8.4. EDHOC Error Codes Registry . . . . . . . . . . . . . . . 50 99 8.5. COSE Header Parameters Registry . . . . . . . . . . . . . 50 100 8.6. COSE Header Parameters Registry . . . . . . . . . . . . . 51 101 8.7. COSE Key Common Parameters Registry . . . . . . . . . . . 51 102 8.8. The Well-Known URI Registry . . . . . . . . . . . . . . . 51 103 8.9. Media Types Registry . . . . . . . . . . . . . . . . . . 52 104 8.10. CoAP Content-Formats Registry . . . . . . . . . . . . . . 53 105 8.11. EDHOC External Authorization Data . . . . . . . . . . . . 53 106 8.12. Expert Review Instructions . . . . . . . . . . . . . . . 53 107 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 108 9.1. Normative References . . . . . . . . . . . . . . . . . . 54 109 9.2. Informative References . . . . . . . . . . . . . . . . . 56 110 Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 59 111 A.1. Selecting EDHOC Connection Identifier . . . . . . . . . . 59 112 A.2. Deriving the OSCORE Security Context . . . . . . . . . . 60 113 A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 61 114 Appendix B. Compact Representation . . . . . . . . . . . . . . . 64 115 Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 65 116 C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 65 117 C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 66 118 C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 68 119 Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 68 120 Appendix E. Applicability Template . . . . . . . . . . . . . . . 68 121 Appendix F. EDHOC Message Deduplication . . . . . . . . . . . . 69 122 Appendix G. Transports Not Natively Providing Correlation . . . 70 123 Appendix H. Change Log . . . . . . . . . . . . . . . . . . . . . 70 124 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 75 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 127 1. Introduction 129 1.1. Motivation 131 Many Internet of Things (IoT) deployments require technologies which 132 are highly performant in constrained environments [RFC7228]. IoT 133 devices may be constrained in various ways, including memory, 134 storage, processing capacity, and power. The connectivity for these 135 settings may also exhibit constraints such as unreliable and lossy 136 channels, highly restricted bandwidth, and dynamic topology. The 137 IETF has acknowledged this problem by standardizing a range of 138 lightweight protocols and enablers designed for the IoT, including 139 the Constrained Application Protocol (CoAP, [RFC7252]), Concise 140 Binary Object Representation (CBOR, [RFC8949]), and Static Context 141 Header Compression (SCHC, [RFC8724]). 143 The need for special protocols targeting constrained IoT deployments 144 extends also to the security domain [I-D.ietf-lake-reqs]. Important 145 characteristics in constrained environments are the number of round 146 trips and protocol message sizes, which if kept low can contribute to 147 good performance by enabling transport over a small number of radio 148 frames, reducing latency due to fragmentation or duty cycles, etc. 149 Another important criteria is code size, which may be prohibitive for 150 certain deployments due to device capabilities or network load during 151 firmware update. Some IoT deployments also need to support a variety 152 of underlying transport technologies, potentially even with a single 153 connection. 155 Some security solutions for such settings exist already. CBOR Object 156 Signing and Encryption (COSE, [I-D.ietf-cose-rfc8152bis-struct]) 157 specifies basic application-layer security services efficiently 158 encoded in CBOR. Another example is Object Security for Constrained 159 RESTful Environments (OSCORE, [RFC8613]) which is a lightweight 160 communication security extension to CoAP using CBOR and COSE. In 161 order to establish good quality cryptographic keys for security 162 protocols such as COSE and OSCORE, the two endpoints may run an 163 authenticated Diffie-Hellman key exchange protocol, from which shared 164 secret key material can be derived. Such a key exchange protocol 165 should also be lightweight; to prevent bad performance in case of 166 repeated use, e.g., due to device rebooting or frequent rekeying for 167 security reasons; or to avoid latencies in a network formation 168 setting with many devices authenticating at the same time. 170 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 171 lightweight authenticated key exchange protocol providing good 172 security properties including forward secrecy, identity protection, 173 and cipher suite negotiation. Authentication can be based on raw 174 public keys (RPK) or public key certificates and requires the 175 application to provide input on how to verify that endpoints are 176 trusted. This specification focuses on referencing instead of 177 transporting credentials to reduce message overhead. EDHOC does 178 currently not support pre-shared key (PSK) authentication as 179 authentication with static Diffie-Hellman public keys by reference 180 produces equally small message sizes but with much simpler key 181 distribution. 183 EDHOC makes use of known protocol constructions, such as SIGMA 184 [SIGMA] and Extract-and-Expand [RFC5869]. COSE also provides crypto 185 agility and enables the use of future algorithms targeting IoT. 187 1.2. Use of EDHOC 189 EDHOC is designed for highly constrained settings making it 190 especially suitable for low-power wide area networks [RFC8376] such 191 as Cellular IoT, 6TiSCH, and LoRaWAN. A main objective for EDHOC is 192 to be a lightweight authenticated key exchange for OSCORE, i.e., to 193 provide authentication and session key establishment for IoT use 194 cases such as those built on CoAP [RFC7252]. CoAP is a specialized 195 web transfer protocol for use with constrained nodes and networks, 196 providing a request/response interaction model between application 197 endpoints. As such, EDHOC is targeting a large variety of use cases 198 involving 'things' with embedded microcontrollers, sensors, and 199 actuators. 201 A typical setting is when one of the endpoints is constrained or in a 202 constrained network, and the other endpoint is a node on the Internet 203 (such as a mobile phone) or at the edge of the constrained network 204 (such as a gateway). Thing-to-thing interactions over constrained 205 networks are also relevant since both endpoints would then benefit 206 from the lightweight properties of the protocol. EDHOC could e.g., 207 be run when a device connects for the first time, or to establish 208 fresh keys which are not revealed by a later compromise of the long- 209 term keys. Further security properties are described in Section 7.1. 211 EDHOC enables the reuse of the same lightweight primitives as OSCORE: 212 CBOR for encoding, COSE for cryptography, and CoAP for transport. By 213 reusing existing libraries, the additional code size can be kept very 214 low. Note that, while CBOR and COSE primitives are built into the 215 protocol messages, EDHOC is not bound to a particular transport. 216 Transfer of EDHOC messages in CoAP payloads is detailed in 217 Appendix A.3. 219 1.3. Message Size Examples 221 Compared to the DTLS 1.3 handshake [I-D.ietf-tls-dtls13] with ECDHE 222 and connection ID, the number of bytes in EDHOC + CoAP can be less 223 than 1/6 when RPK authentication is used, see 224 [I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows two 225 examples of message sizes for EDHOC with different kinds of 226 authentication keys and different COSE header parameters for 227 identification: static Diffie-Hellman keys identified by 'kid' 228 [I-D.ietf-cose-rfc8152bis-struct], and X.509 signature certificates 229 identified by a hash value using 'x5t' [I-D.ietf-cose-x509]. 231 ================================= 232 kid x5t 233 --------------------------------- 234 message_1 37 37 235 message_2 45 116 236 message_3 19 90 237 --------------------------------- 238 Total 101 243 239 ================================= 241 Figure 1: Example of message sizes in bytes. 243 1.4. Document Structure 245 The remainder of the document is organized as follows: Section 2 246 outlines EDHOC authenticated with digital signatures, Section 3 247 describes the protocol elements of EDHOC, including formatting of the 248 ephemeral public keys, Section 4 specifies the key derivation, 249 Section 5 specifies message processing for EDHOC authenticated with 250 signature keys or static Diffie-Hellman keys, Section 6 describes the 251 error messages, and Appendix A shows how to transfer EDHOC with CoAP 252 and establish an OSCORE security context. 254 1.5. Terminology and Requirements Language 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 258 "OPTIONAL" in this document are to be interpreted as described in BCP 259 14 [RFC2119] [RFC8174] when, and only when, they appear in all 260 capitals, as shown here. 262 Readers are expected to be familiar with the terms and concepts 263 described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE 264 structures and process [I-D.ietf-cose-rfc8152bis-struct], COSE 265 algorithms [I-D.ietf-cose-rfc8152bis-algs], and CDDL [RFC8610]. The 266 Concise Data Definition Language (CDDL) is used to express CBOR data 267 structures [RFC8949]. Examples of CBOR and CDDL are provided in 268 Appendix C.1. When referring to CBOR, this specification always 269 refers to Deterministically Encoded CBOR as specified in Sections 270 4.2.1 and 4.2.2 of [RFC8949]. 272 The single output from authenticated encryption (including the 273 authentication tag) is called "ciphertext", following [RFC5116]. 275 We use the term Unprotected CWT Claims Set (UCCS) just as in 276 [I-D.ietf-rats-uccs] to denote a CBOR Web Token [RFC8392] without 277 wrapping it into a COSE object, i.e., a CBOR map consisting of 278 claims. 280 Editor's note: If [I-D.ietf-rats-uccs] completes before this draft, 281 make it a normative reference. 283 2. EDHOC Outline 285 EDHOC specifies different authentication methods of the Diffie- 286 Hellman key exchange: digital signatures and static Diffie-Hellman 287 keys. This section outlines the digital signature-based method. 288 Further details of protocol elements and other authentication methods 289 are provided in the remainder of this document. 291 SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a 292 large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS 293 1.3 [RFC8446], EDHOC authenticated with digital signatures is built 294 on a variant of the SIGMA protocol which provides identity protection 295 of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC 296 implements the SIGMA-I variant as MAC-then-Sign. The SIGMA-I 297 protocol using an authenticated encryption algorithm is shown in 298 Figure 2. 300 Initiator Responder 301 | G_X | 302 +-------------------------------------------------------->| 303 | | 304 | G_Y, AEAD( K_2; ID_CRED_R, Sig(R; CRED_R, G_X, G_Y) ) | 305 |<--------------------------------------------------------+ 306 | | 307 | AEAD( K_3; ID_CRED_I, Sig(I; CRED_I, G_Y, G_X) ) | 308 +-------------------------------------------------------->| 309 | | 311 Figure 2: Authenticated encryption variant of the SIGMA-I protocol. 313 The parties exchanging messages are called Initiator (I) and 314 Responder (R). They exchange ephemeral public keys, compute a shared 315 secret, and derive symmetric application keys used to protect 316 application data. 318 * G_X and G_Y are the ECDH ephemeral public keys of I and R, 319 respectively. 321 * CRED_I and CRED_R are the credentials containing the public 322 authentication keys of I and R, respectively. 324 * ID_CRED_I and ID_CRED_R are credential identifiers enabling the 325 recipient party to retrieve the credential of I and R, 326 respectively. 328 * Sig(I; . ) and Sig(R; . ) denote signatures made with the private 329 authentication key of I and R, respectively. 331 * AEAD(K; . ) denotes authenticated encryption with additional data 332 using a key K derived from the shared secret. 334 In order to create a "full-fledged" protocol some additional protocol 335 elements are needed. EDHOC adds: 337 * Transcript hashes (hashes of message data) TH_2, TH_3, TH_4 used 338 for key derivation and as additional authenticated data. 340 * Computationally independent keys derived from the ECDH shared 341 secret and used for authenticated encryption of different 342 messages. 344 * An optional fourth message giving explicit key confirmation to I 345 in deployments where no protected application data is sent from R 346 to I. 348 * A key material exporter and a key update function enabling forward 349 secrecy. 351 * Verification of a common preferred cipher suite: 353 - The Initiator lists supported cipher suites in order of 354 preference 356 - The Responder verifies that the selected cipher suite is the 357 first supported cipher suite (or else rejects and states 358 supported cipher suites). 360 * Method types and error handling. 362 * Selection of connection identifiers C_I and C_R which may be used 363 to identify established keys or protocol state. 365 * Transport of external authorization data. 367 EDHOC is designed to encrypt and integrity protect as much 368 information as possible, and all symmetric keys are derived using as 369 much previous information as possible. EDHOC is furthermore designed 370 to be as compact and lightweight as possible, in terms of message 371 sizes, processing, and the ability to reuse already existing CBOR, 372 COSE, and CoAP libraries. 374 To simplify for implementors, the use of CBOR and COSE in EDHOC is 375 summarized in Appendix C and test vectors including CBOR diagnostic 376 notation are given in Appendix D. 378 3. Protocol Elements 380 3.1. General 382 The EDHOC protocol consists of three mandatory messages (message_1, 383 message_2, message_3) between Initiator and Responder, an optional 384 fourth message (message_4), plus an error message. EDHOC messages 385 are CBOR Sequences [RFC8742], see Figure 3. The protocol elements in 386 the figure are introduced in the following sections. Message 387 formatting and processing is specified in Section 5 and Section 6. 388 An implementation may support only Initiator or only Responder. 390 Application data is protected using the agreed application algorithms 391 (AEAD, hash) in the selected cipher suite (see Section 3.6) and the 392 application can make use of the established connection identifiers 393 C_I and C_R (see Section 3.3). EDHOC may be used with the media type 394 application/edhoc defined in Section 8. 396 The Initiator can derive symmetric application keys after creating 397 EDHOC message_3, see Section 4.3. Protected application data can 398 therefore be sent in parallel or together with EDHOC message_3. 400 Initiator Responder 401 | METHOD, SUITES_I, G_X, C_I, EAD_1 | 402 +------------------------------------------------------------------>| 403 | message_1 | 404 | | 405 | G_Y, Enc(ID_CRED_R, Signature_or_MAC_2, EAD_2), C_R | 406 |<------------------------------------------------------------------+ 407 | message_2 | 408 | | 409 | AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, EAD_3) | 410 +------------------------------------------------------------------>| 411 | message_3 | 413 Figure 3: EDHOC Message Flow 415 3.2. Method 417 The data item METHOD in message_1 (see Section 5.2.1), is an integer 418 specifying the authentication method. EDHOC supports authentication 419 with signature or static Diffie-Hellman keys, as defined in the four 420 authentication methods: 0, 1, 2, and 3, see Figure 4. (Method 0 421 corresponds to the case outlined in Section 2 where both Initiator 422 and Responder authenticate with signature keys.) 424 An implementation may support only a single method. The Initiator 425 and the Responder need to have agreed on a single method to be used 426 for EDHOC, see Section 3.9. 428 +-------+-------------------+-------------------+-------------------+ 429 | Value | Initiator | Responder | Reference | 430 +-------+-------------------+-------------------+-------------------+ 431 | 0 | Signature Key | Signature Key | [[this document]] | 432 | 1 | Signature Key | Static DH Key | [[this document]] | 433 | 2 | Static DH Key | Signature Key | [[this document]] | 434 | 3 | Static DH Key | Static DH Key | [[this document]] | 435 +-------+-------------------+-------------------+-------------------+ 437 Figure 4: Method Types 439 3.3. Connection Identifiers 441 EDHOC includes the selection of connection identifiers (C_I, C_R) 442 identifying a connection for which keys are agreed. Connection 443 identifiers may be used in the ongoing EDHOC protocol (see 444 Section 3.3.2) or in a subsequent application protocol, e.g., OSCORE 445 (see Section 3.3.3). The connection identifiers do not have any 446 cryptographic purpose in EDHOC. 448 Connection identifiers in EDHOC are byte strings or integers, encoded 449 in CBOR. One byte connection identifiers (the integers -24 to 23 and 450 the empty byte string h'') are realistic in many scenarios as most 451 constrained devices only have a few connections. 453 3.3.1. Selection of Connection Identifiers 455 C_I and C_R are chosen by I and R, respectively. The Initiator 456 selects C_I and sends it in message_1 for the Responder to use as a 457 reference to the connection in communications with the Initiator. 458 The Responder selects C_R and sends in message_2 for the Initiator to 459 use as a reference to the connection in communications with the 460 Responder. 462 If connection identifiers are used by an application protocol for 463 which EDHOC establishes keys then the selected connection identifiers 464 SHALL adhere to the requirements for that protocol, see Section 3.3.3 465 for an example. 467 3.3.2. Use of Connection Identifiers with EDHOC 469 Connection identifiers may be used to correlate EDHOC messages and 470 facilitate the retrieval of protocol state during EDHOC protocol 471 execution. EDHOC transports that do not inherently provide 472 correlation across all messages of an exchange can send connection 473 identifiers along with EDHOC messages to gain that required 474 capability, see Section 3.4. For an example of using connection 475 identifiers when CoAP is used as transport, see Appendix A.3. 477 3.3.3. Use of Connection Identifiers with OSCORE 479 For OSCORE, the choice of a connection identifier results in the 480 endpoint selecting its Recipient ID, see Section 3.1 of [RFC8613], 481 for which certain uniqueness requirements apply, see Section 3.3 of 482 [RFC8613]. Therefore, the Initiator and the Responder MUST NOT 483 select connection identifiers such that it results in same OSCORE 484 Recipient ID. Since the Recipient ID is a byte string and a EDHOC 485 connection identifier is either a CBOR byte string or a CBOR integer, 486 care must be taken when selecting the connection identifiers and 487 converting them to Recipient IDs. A mapping from EDHOC connection 488 identifier to OSCORE Recipient ID is specified in Appendix A.1. 490 3.4. Transport 492 Cryptographically, EDHOC does not put requirements on the lower 493 layers. EDHOC is not bound to a particular transport layer and can 494 even be used in environments without IP. The transport is 495 responsible, where necessary, to handle: 497 * message loss, 499 * message reordering, 501 * message duplication, 503 * fragmentation, 505 * demultiplex EDHOC messages from other types of messages, and 507 * denial-of-service protection. 509 Besides these common transport-oriented properties, EDHOC transport 510 additionally needs to support the correlation between EDHOC messages, 511 including an indication of a message being message_1. The 512 correlation may reuse existing mechanisms in the transport protocol. 513 For example, the CoAP Token may be used to correlate EDHOC messages 514 in a CoAP response and an associated CoAP request. In the absence of 515 correlation between a message received and a message previously sent 516 inherent to the transport, the EDHOC connection identifiers may be 517 added, e.g., by prepending the appropriate connection identifier 518 (when available from the EDHOC protocol) to the EDHOC message. 519 Transport of EDHOC in CoAP payloads is described in Appendix A.3, 520 which also shows how to use connection identifiers and message_1 521 indication with CoAP. 523 The Initiator and the Responder need to have agreed on a transport to 524 be used for EDHOC, see Section 3.9. 526 3.5. Authentication Parameters 528 EDHOC enables public-key based authentication and supports various 529 settings for how the other endpoint's public key is transported, 530 identified, and trusted. 532 The authentication key (i.e., the public key) appears in different 533 functions: 535 1. as part of the authentication credential CRED_x included in the 536 integrity calculation 538 2. for verification of the Signature_or_MAC field in message_2 and 539 message_3 (see Section 5.3.2 and Section 5.4.2) 541 3. in the key derivation (in case of a static Diffie-Hellman key, 542 see Section 4). 544 The choice of authentication key has an impact on the message size 545 (see Section 3.5.1), and even more so the choice of authentication 546 credential (see Section 3.5.2) in case it is transported within the 547 protocol (see Section 3.5.4). EDHOC supports authentication 548 credentials for which COSE header parameters are defined, including: 550 * X.509 v3 certificate [RFC5280] 552 * C509 certificate [I-D.ietf-cose-cbor-encoded-cert] 554 * CBOR Web Token (CWT, [RFC8392]) 556 * Unprotected CWT Claims Set (UCCS, see Section 1.5) 557 For CWT and UCCS, the authentication key is represented with a 'cnf' 558 claim [RFC8747] containing a COSE_Key 559 [I-D.ietf-cose-rfc8152bis-struct]. UCCS can be seen as a generic 560 representation of a raw public key, see Section 3.5.2 for an example. 561 COSE_Key is omitted from the list above because of limitations to 562 represent the identity (see Section 3.5.3) and because it can easily 563 be embedded in a UCCS. 565 Identical authentication credentials need to be established in both 566 endpoints to accomplish item 1 above (see Section 3.5.2) but for many 567 settings it is not necessary to transport the authentication 568 credential over constrained links. It may, for example, be pre- 569 provisioned or acquired out-of-band over less constrained links. 570 ID_CRED_x coincides with the authentication credential CRED_x in case 571 it is transported, or else contains a reference to the authentication 572 credential to facilitate its retrieval (see Section 3.5.4). 574 The choice of authentication credential also depends on the trust 575 model. For example, a certificate or CWT may rely on a trusted third 576 party, whereas a UCCS may be used when trust in the public key can be 577 achieved by other means, or in the case of trust-on-first-use. A 578 UCCS as authentication credential provides essentially the same 579 trustworthiness as a self-signed certificate or CWT but has smaller 580 size. 582 More details are provided in the following subsections. 584 3.5.1. Authentication Keys 586 The authentication key MUST be a signature key or static Diffie- 587 Hellman key. The Initiator and the Responder MAY use different types 588 of authentication keys, e.g., one uses a signature key and the other 589 uses a static Diffie-Hellman key. When using a signature key, the 590 authentication is provided by a signature. When using a static 591 Diffie-Hellman key the authentication is provided by a Message 592 Authentication Code (MAC) computed from an ephemeral-static ECDH 593 shared secret which enables significant reductions in message sizes. 594 When using static Diffie-Hellman keys the Initiator's and Responder's 595 private authentication keys are called I and R, respectively, and the 596 public authentication keys are called G_I and G_R, respectively. 598 The authentication key algorithm needs to be specified with enough 599 parameters to make it completely determined. Note that for most 600 signature algorithms, the signature is determined jointly by the 601 signature algorithm and the authentication key algorithm. For 602 example, the curve used in the signature is typically determined by 603 the authentication key parameters. 605 * Only the Responder SHALL have access to the Responder's private 606 authentication key. 608 * Only the Initiator SHALL have access to the Initiator's private 609 authentication key. 611 3.5.2. Authentication Credentials 613 The authentication credentials, CRED_I and CRED_R, contain the public 614 authentication key of the Initiator and the Responder, respectively. 615 The Initiator and the Responder MAY use different types of 616 credentials, e.g., one uses an UCCS and the other uses an X.509 617 certificate. 619 The credentials CRED_I and CRED_R are MACed by the Initiator and the 620 Responder, respectively, see Section 5.4.2 and Section 5.3.2, and 621 thus included in the message integrity calculation. 623 To prevent misbinding attacks in systems where an attacker can 624 register public keys without proving knowledge of the private key, 625 SIGMA [SIGMA] enforces a MAC to be calculated over the "identity". 626 EDHOC follows SIGMA by calculating a MAC over the whole credential, 627 which in case of a X.509 or C509 certificate includes the "subject" 628 and "subjectAltName" fields, and in the case of CWT or UCCS includes 629 the "sub" claim, see Section 3.5.3. While the SIGMA paper only 630 focuses on the identity, the same principle is true for any 631 information such as policies connected to the public key. 633 When the credential is a certificate, CRED_x is an end-entity 634 certificate (i.e., not the certificate chain). In X.509 and C509 635 certificates, signature keys typically have key usage 636 "digitalSignature" and Diffie-Hellman public keys typically have key 637 usage "keyAgreement". 639 In case of elliptic curve based credential the claims set for CWT or 640 UCCS includes: 642 * the 'cnf' claim with value COSE_Key, see [RFC8747], where the 643 public key parameters depend on key type: 645 - for OKP the CBOR map typically includes the parameters 1 (kty), 646 -1 (crv), and -2 (x-coordinate) 648 - for EC2 the CBOR map typically includes the parameters 1 (kty), 649 -1 (crv), -2 (x-coordinate), and -3 (y-coordinate) 651 * the 'sub' (subject) claim containing the "identity", if the 652 parties have agreed on an identity besides the public key. 654 CRED_x needs to be defined such that it is identical when generated 655 by Initiator or Responder, see Section 3.9. The parameters SHALL be 656 encoded in bytewise lexicographic order of their deterministic 657 encodings as specified in Section 4.2.1 of [RFC8949]. 659 An example of CRED_x being a UCCS in bytewise lexicographic order 660 containing an X25519 static Diffie-Hellman key and where the parties 661 have agreed on an EUI-64 identity is shown below: 663 { /UCCS/ 664 2 : "42-50-31-FF-EF-37-32-39", /sub/ 665 8 : { /cnf/ 666 1 : { /COSE_Key/ 667 1 : 1, /kty/ 668 -1 : 4, /crv/ 669 -2 : h'b1a3e89460e88d3a8d54211dc95f0b90 /x/ 670 3ff205eb71912d6db8f4af980d2db83a' 671 } 672 } 673 } 675 3.5.3. Identities 677 EDHOC assumes the existence of mechanisms (certification authority, 678 trusted third party, pre-provisioning, etc.) for specifying and 679 distributing authentication keys and identities. Policies are 680 typically set based on the identity of the other party, and parties 681 typically only allow connections from a specific identity or a small 682 restricted set of identities. For example, in the case of a device 683 connecting to a network, the network may only allow connections from 684 devices which authenticate with certificates having a particular 685 range of serial numbers in the subject field and signed by a 686 particular CA. On the other side, the device may only be allowed to 687 connect to a network which authenticates with a particular public key 688 (information of which may be provisioned, e.g., out of band or in the 689 external authorization data, see Section 3.8). 691 The EDHOC implementation or the application must enforce information 692 about the intended endpoint, and in particular whether it is a 693 specific identity or a set of identities. Either EDHOC passes 694 information about identity to the application for a decision, or 695 EDHOC needs to have access to relevant information and makes the 696 decision on its own. 698 * When a Public Key Infrastructure (PKI) is used with certificates, 699 the trust anchor is a Certification Authority (CA) certificate, 700 and the identity is the subject whose unique name (e.g. a domain 701 name, NAI, or EUI) is included in the endpoint's certificate. 703 Before running EDHOC each party needs at least one CA public key 704 certificate, or just the public key, and a specific identity or 705 set of identities it is allowed to communicate with. Only 706 validated public-key certificates with an allowed subject name, as 707 specified by the application, are to be accepted. EDHOC provides 708 proof that the other party possesses the private authentication 709 key corresponding to the public authentication key in its 710 certificate. The certification path provides proof that the 711 subject of the certificate owns the public key in the certificate. 713 * Similarly, when a PKI is used with CWTs, each party needs to have 714 a trusted third party self-signed CWT, or just the UCCS/raw public 715 key, to verify the CWTs, and a specific identity or set of 716 identities in the 'sub'(subject) claim of the CWT to determine if 717 it is allowed to communicate with. 719 * When public keys are used but not with a PKI (UCCS, self-signed 720 certificate/CWT), the trust anchor is the authentication key of 721 the other party. In this case, the identity is typically directly 722 associated to the authentication key of the other party. For 723 example, the name of the subject may be a canonical representation 724 of the public key. Alternatively, if identities can be expressed 725 in the form of unique subject names assigned to public keys, then 726 a binding to identity can be achieved by including both public key 727 and associated subject name in the protocol message computation: 728 CRED_I or CRED_R may be a self-signed certificate/CWT or UCCS 729 containing the authentication key and the subject name, see 730 Section 3.5.2. Before running EDHOC, each endpoint needs a 731 specific authentication key/unique associated subject name, or a 732 set of public authentication keys/unique associated subject names, 733 which it is allowed to communicate with. EDHOC provides proof 734 that the other party possesses the private authentication key 735 corresponding to the public authentication key. 737 3.5.4. Identification of Credentials 739 ID_CRED_I and ID_CRED_R are used to identify and optionally transport 740 the public authentication keys of the Initiator and the Responder, 741 respectively. ID_CRED_I and ID_CRED_R do not have any cryptographic 742 purpose in EDHOC. 744 * ID_CRED_R is intended to facilitate for the Initiator to retrieve 745 the Responder's public authentication key. 747 * ID_CRED_I is intended to facilitate for the Responder to retrieve 748 the Initiator's public authentication key. 750 The identifiers ID_CRED_I and ID_CRED_R are registered in the "COSE 751 Header Parameters" IANA registry. As such, ID_CRED_I and ID_CRED_R 752 typically also provide information about the format of authentication 753 credential, CRED_I and CRED_R, respectively. ID_CRED_I and ID_CRED_R 754 MAY be of different types. 756 Public key certificates can be identified in different ways. COSE 757 header parameters for identifying X.509 or C509 certificates are 758 defined in [I-D.ietf-cose-x509] and 759 [I-D.ietf-cose-cbor-encoded-cert], for example: 761 * by a hash value with the 'x5t' or 'c5t' parameters, respectively: 763 - ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, 765 - ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R; 767 * or by a URI with the 'x5u' or 'c5u' parameters, respectively: 769 - ID_CRED_x = { 35 : uri }, for x = I or R, 771 - ID_CRED_x = { TBD4 : uri }, for x = I or R. 773 ID_CRED_x MAY contain the actual credential used for authentication, 774 CRED_x. For example, a certificate chain can be transported in 775 ID_CRED_x with COSE header parameter c5c or x5chain, defined in 776 [I-D.ietf-cose-cbor-encoded-cert] and [I-D.ietf-cose-x509]. 778 Credentials of type CWT and UCCS are transported with the COSE header 779 parameter registered in Section 8.5: 781 * ID_CRED_x = { TBD1 : CWT }, for x = I or R, 783 * ID_CRED_x = { TBD1 : UCCS }, for x = I or R. 785 It is RECOMMENDED that ID_CRED_x uniquely identify the public 786 authentication key as the recipient may otherwise have to try several 787 keys. ID_CRED_I and ID_CRED_R are transported in the 'ciphertext', 788 see Section 5.4.2 and Section 5.3.2. 790 When ID_CRED_x does not contain the actual credential, it may be very 791 short, e.g., if the endpoints have agreed to use a key identifier 792 parameter 'kid': 794 * ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or 795 R. 797 Note that 'kid' is extended to support int values to allow more one- 798 byte identifiers (see Section 8.6 and Section 8.7) which may be 799 useful in many scenarios since constrained devices only have a few 800 keys. 802 3.6. Cipher Suites 804 An EDHOC cipher suite consists of an ordered set of algorithms from 805 the "COSE Algorithms" and "COSE Elliptic Curves" registries as well 806 as the EDHOC MAC length. Algorithms need to be specified with enough 807 parameters to make them completely determined. Currently, none of 808 the algorithms require parameters. EDHOC is only specified for use 809 with key exchange algorithms of type ECDH curves. Use with other 810 types of key exchange algorithms would likely require a specification 811 updating EDHOC. Note that for most signature algorithms, the 812 signature is determined by the signature algorithm and the 813 authentication key algorithm together, see Section 3.5.1. 815 * EDHOC AEAD algorithm 817 * EDHOC hash algorithm 819 * EDHOC MAC length in bytes (Static DH) 821 * EDHOC key exchange algorithm (ECDH curve) 823 * EDHOC signature algorithm 825 * Application AEAD algorithm 827 * Application hash algorithm 829 Each cipher suite is identified with a pre-defined int label. 831 EDHOC can be used with all algorithms and curves defined for COSE. 832 Implementation can either use one of the pre-defined cipher suites 833 (Section 8.2) or use any combination of COSE algorithms and 834 parameters to define their own private cipher suite. Private cipher 835 suites can be identified with any of the four values -24, -23, -22, 836 -21. 838 The following CCM cipher suites are for constrained IoT where message 839 overhead is a very important factor. Cipher suites 1 and 3 use a 840 larger tag length (128-bit) in the EDHOC AEAD algorithm than the 841 Application AEAD algorithm (64-bit): 843 0. ( 10, -16, 8, 4, -8, 10, -16 ) 844 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, 845 AES-CCM-16-64-128, SHA-256) 847 1. ( 30, -16, 16, 4, -8, 10, -16 ) 848 (AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, 849 AES-CCM-16-64-128, SHA-256) 851 2. ( 10, -16, 8, 1, -7, 10, -16 ) 852 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, 853 AES-CCM-16-64-128, SHA-256) 855 3. ( 30, -16, 16, 1, -7, 10, -16 ) 856 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, 857 AES-CCM-16-64-128, SHA-256) 859 The following ChaCha20 cipher suites are for less constrained 860 applications and only use 128-bit tag lengths. 862 4. ( 24, -16, 16, 4, -8, 24, -16 ) 863 (ChaCha20/Poly1305, SHA-256, 16, X25519, EdDSA, 864 ChaCha20/Poly1305, SHA-256) 866 5. ( 24, -16, 16, 1, -7, 24, -16 ) 867 (ChaCha20/Poly1305, SHA-256, 16, P-256, ES256, 868 ChaCha20/Poly1305, SHA-256) 870 The following GCM cipher suite is for general non-constrained 871 applications. It uses high performance algorithms that are widely 872 supported: 874 6. ( 1, -16, 16, 4, -7, 1, -16 ) 875 (A128GCM, SHA-256, 16, X25519, ES256, 876 A128GCM, SHA-256) 878 The following two cipher suites are for high security application 879 such as government use and financial applications. The two cipher 880 suites do not share any algorithms. The first of the two cipher 881 suites is compatible with the CNSA suite [CNSA]. 883 24. ( 3, -43, 16, 2, -35, 3, -43 ) 884 (A256GCM, SHA-384, 16, P-384, ES384, 885 A256GCM, SHA-384) 887 25. ( 24, -45, 16, 5, -8, 24, -45 ) 888 (ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA, 889 ChaCha20/Poly1305, SHAKE256) 891 The different methods use the same cipher suites, but some algorithms 892 are not used in some methods. The EDHOC signature algorithm is not 893 used in methods without signature authentication. 895 The Initiator needs to have a list of cipher suites it supports in 896 order of preference. The Responder needs to have a list of cipher 897 suites it supports. SUITES_I is a CBOR array containing cipher 898 suites that the Initiator supports. SUITES_I is formatted and 899 processed as detailed in Section 5.2.1 to secure the cipher suite 900 negotiation. Examples of cipher suite negotiation are given in 901 Section 6.3.2. 903 3.7. Ephemeral Public Keys 905 EDHOC always uses compact representation of elliptic curve points, 906 see Appendix B. In COSE compact representation is achieved by 907 formatting the ECDH ephemeral public keys as COSE_Keys of type EC2 or 908 OKP according to Sections 7.1 and 7.2 of 909 [I-D.ietf-cose-rfc8152bis-algs], but only including the 'x' parameter 910 in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact 911 representation MAY be used also in the COSE_Key. If the COSE 912 implementation requires an 'y' parameter, the value y = false SHALL 913 be used. COSE always use compact output for Elliptic Curve Keys of 914 type EC2. 916 3.8. External Authorization Data (EAD) 918 In order to reduce round trips and number of messages or to simplify 919 processing, external security applications may be integrated into 920 EDHOC by transporting authorization related data in the messages. 921 One example is third-party identity and authorization information 922 protected out of scope of EDHOC [I-D.selander-ace-ake-authz]. 923 Another example is a certificate enrolment request or the resulting 924 issued certificate. 926 EDHOC allows opaque external authorization data (EAD) to be sent in 927 the EDHOC messages. External authorization data sent in message_1 928 (EAD_1) or message_2 (EAD_2) must be considered unprotected by EDHOC, 929 see Section 7.4. External authorization data sent in message_3 930 (EAD_3) or message_4 (EAD_4) is protected between Initiator and 931 Responder. 933 External authorization data is a CBOR sequence (see Appendix C.1) 934 consisting of one or more (type, ext_authz_data) pairs as defined 935 below: 937 ead = 1* ( 938 type : int, 939 ext_authz_data : any, 940 ) 942 where ext_authz_data is authorization related data defined in a 943 separate specification and its type is an int. Different types of 944 ext_authz_data are registered in Section 8.11. 946 The EAD fields of EDHOC are not intended for generic application 947 data. Since data carried in EAD_1 and EAD_2 fields may not be 948 protected, special considerations need to be made such that it does 949 not violate security and privacy requirements of the service which 950 uses this data. Moreover, the content in an EAD field may impact the 951 security properties provided by EDHOC. Security applications making 952 use of the EAD fields must perform the necessary security analysis. 954 3.9. Applicability Statement 956 EDHOC requires certain parameters to be agreed upon between Initiator 957 and Responder. Some parameters can be agreed through the protocol 958 execution (specifically cipher suite negotiation, see Section 3.6) 959 but other parameters may need to be known out-of-band (e.g., which 960 authentication method is used, see Section 3.2). 962 The purpose of the applicability statement is to describe the 963 intended use of EDHOC to allow for the relevant processing and 964 verifications to be made, including things like: 966 1. How the endpoint detects that an EDHOC message is received. This 967 includes how EDHOC messages are transported, for example in the 968 payload of a CoAP message with a certain Uri-Path or Content- 969 Format; see Appendix A.3. 971 * The method of transporting EDHOC messages may also describe 972 data carried along with the messages that are needed for the 973 transport to satisfy the requirements of Section 3.4, e.g., 974 connection identifiers used with certain messages, see 975 Appendix A.3. 977 2. Authentication method (METHOD; see Section 3.2). 979 3. Profile for authentication credentials (CRED_I, CRED_R; see 980 Section 3.5.2), e.g., profile for certificate or UCCS, including 981 supported authentication key algorithms (subject public key 982 algorithm in X.509 or C509 certificate). 984 4. Type used to identify authentication credentials (ID_CRED_I, 985 ID_CRED_R; see Section 3.5.4). 987 5. Use and type of external authorization data (EAD_1, EAD_2, EAD_3, 988 EAD_4; see Section 3.8). 990 6. Identifier used as identity of endpoint; see Section 3.5.3. 992 7. If message_4 shall be sent/expected, and if not, how to ensure a 993 protected application message is sent from the Responder to the 994 Initiator; see Section 5.5. 996 The applicability statement may also contain information about 997 supported cipher suites. The procedure for selecting and verifying 998 cipher suite is still performed as specified by the protocol, but it 999 may become simplified by this knowledge. 1001 An example of an applicability statement is shown in Appendix E. 1003 For some parameters, like METHOD, ID_CRED_x, type of EAD, the 1004 receiver is able to verify compliance with applicability statement, 1005 and if it needs to fail because of incompliance, to infer the reason 1006 why the protocol failed. 1008 For other parameters, like CRED_x in the case that it is not 1009 transported, it may not be possible to verify that incompliance with 1010 applicability statement was the reason for failure: Integrity 1011 verification in message_2 or message_3 may fail not only because of 1012 wrong authentication credential. For example, in case the Initiator 1013 uses public key certificate by reference (i.e., not transported 1014 within the protocol) then both endpoints need to use an identical 1015 data structure as CRED_I or else the integrity verification will 1016 fail. 1018 Note that it is not necessary for the endpoints to specify a single 1019 transport for the EDHOC messages. For example, a mix of CoAP and 1020 HTTP may be used along the path, and this may still allow correlation 1021 between messages. 1023 The applicability statement may be dependent on the identity of the 1024 other endpoint, or other information carried in an EDHOC message, but 1025 it then applies only to the later phases of the protocol when such 1026 information is known. (The Initiator does not know identity of 1027 Responder before having verified message_2, and the Responder does 1028 not know identity of the Initiator before having verified message_3.) 1029 Other conditions may be part of the applicability statement, such as 1030 target application or use (if there is more than one application/use) 1031 to the extent that EDHOC can distinguish between them. In case 1032 multiple applicability statements are used, the receiver needs to be 1033 able to determine which is applicable for a given session, for 1034 example based on URI or external authorization data type. 1036 4. Key Derivation 1038 EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm 1039 in the selected cipher suite to derive keys used in EDHOC and in the 1040 application. Extract is used to derive fixed-length uniformly 1041 pseudorandom keys (PRK) from ECDH shared secrets. Expand is used to 1042 derive additional output keying material (OKM) from the PRKs. 1044 This section defines Extract, Expand and other key derivation 1045 functions based on these: Expand is used to define EDHOC-KDF and in 1046 turn EDHOC-Exporter, whereas Extract is used to define EDHOC- 1047 KeyUpdate. 1049 4.1. Extract 1051 The pseudorandom keys (PRKs) are derived using Extract. 1053 PRK = Extract( salt, IKM ) 1055 where the input keying material (IKM) and salt are defined for each 1056 PRK below. 1058 The definition of Extract depends on the EDHOC hash algorithm of the 1059 selected cipher suite: 1061 * if the EDHOC hash algorithm is SHA-2, then Extract( salt, IKM ) = 1062 HKDF-Extract( salt, IKM ) [RFC5869] 1064 * if the EDHOC hash algorithm is SHAKE128, then Extract( salt, IKM ) 1065 = KMAC128( salt, IKM, 256, "" ) 1067 * if the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM ) 1068 = KMAC256( salt, IKM, 512, "" ) 1070 4.1.1. PRK_2e 1072 PRK_2e is used to derive a keystream to encrypt message_2. PRK_2e is 1073 derived with the following input: 1075 * The salt SHALL be the empty byte string. Note that [RFC5869] 1076 specifies that if the salt is not provided, it is set to a string 1077 of zeros (see Section 2.2 of [RFC5869]). For implementation 1078 purposes, not providing the salt is the same as setting the salt 1079 to the empty byte string. 1081 * The IKM SHALL be the ECDH shared secret G_XY (calculated from G_X 1082 and Y or G_Y and X) as defined in Section 6.3.1 of 1083 [I-D.ietf-cose-rfc8152bis-algs]. 1085 Example: Assuming the use of curve25519, the ECDH shared secret G_XY 1086 is the output of the X25519 function [RFC7748]: 1088 G_XY = X25519( Y, G_X ) = X25519( X, G_Y ) 1090 Example: Assuming the use of SHA-256 the extract phase of HKDF 1091 produces PRK_2e as follows: 1093 PRK_2e = HMAC-SHA-256( salt, G_XY ) 1095 where salt = 0x (the empty byte string). 1097 4.1.2. PRK_3e2m 1099 PRK_3e2m is used to produce a MAC in message_2 and to encrypt 1100 message_3. PRK_3e2m is derived as follows: 1102 If the Responder authenticates with a static Diffie-Hellman key, then 1103 PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is the ECDH shared 1104 secret calculated from G_R and X, or G_X and R, else PRK_3e2m = 1105 PRK_2e. 1107 4.1.3. PRK_4x3m 1109 PRK_4x3m is used to produce a MAC in message_3, to encrypt message_4, 1110 and to derive application specific data. PRK_4x3m is derived as 1111 follows: 1113 If the Initiator authenticates with a static Diffie-Hellman key, then 1114 PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY is the ECDH shared 1115 secret calculated from G_I and Y, or G_Y and I, else PRK_4x3m = 1116 PRK_3e2m. 1118 4.2. Expand 1120 The keys, IVs and MACs used in EDHOC are derived from the PRKs using 1121 Expand, and instantiated with the EDHOC AEAD algorithm in the 1122 selected cipher suite. 1124 OKM = EDHOC-KDF( PRK, transcript_hash, label, context, length ) 1125 = Expand( PRK, info, length ) 1127 where info is the CBOR encoding of 1129 info = [ 1130 edhoc_aead_id : int / tstr, 1131 transcript_hash : bstr, 1132 label : tstr, 1133 * context : any, 1134 length : uint, 1135 ] 1137 where 1139 * edhoc_aead_id is an int or tstr containing the algorithm 1140 identifier of the EDHOC AEAD algorithm in the selected cipher 1141 suite encoded as defined in [I-D.ietf-cose-rfc8152bis-algs]. Note 1142 that a single fixed edhoc_aead_id is used in all invocations of 1143 EDHOC-KDF, including the derivation of KEYSTREAM_2 and invocations 1144 of the EDHOC-Exporter (see Section 4.3). 1146 * transcript_hash is a bstr set to one of the transcript hashes 1147 TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.3. 1149 * label is a tstr set to the name of the derived key, IV or MAC; 1150 i.e., "KEYSTREAM_2", "MAC_2", "K_3ae", "IV_3ae", or "MAC_3". 1152 * context is a CBOR sequence, i.e., zero or more encoded CBOR data 1153 items 1155 * length is the length of output keying material (OKM) in bytes 1157 The definition of Expand depends on the EDHOC hash algorithm of the 1158 selected cipher suite: 1160 * if the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, 1161 length ) = HKDF-Expand( PRK, info, length ) [RFC5869] 1163 * if the EDHOC hash algorithm is SHAKE128, then Expand( PRK, info, 1164 length ) = KMAC128( PRK, info, L, "" ) 1166 * if the EDHOC hash algorithm is SHAKE256, then Expand( PRK, info, 1167 length ) = KMAC256( PRK, info, L, "" ) 1169 where L = 8*length, the output length in bits. 1171 The keys, IVs and MACs are derived as follows: 1173 * KEYSTREAM_2 is derived using the transcript hash TH_2 and the 1174 pseudorandom key PRK_2e. 1176 * MAC_2 is derived using the transcript hash TH_2 and the 1177 pseudorandom key PRK_3e2m. 1179 * K_3ae and IV_3ae are derived using the transcript hash TH_3 and 1180 the pseudorandom key PRK_3e2m. IVs are only used if the EDHOC 1181 AEAD algorithm uses IVs. 1183 * MAC_3 is derived using the transcript hash TH_3 and the 1184 pseudorandom key PRK_4x3m. 1186 KEYSTREAM_2, K_3ae, and IV_3ae do not use a context. MAC_2 and MAC_3 1187 use context as defined in Section 5.3.2 and Section 5.4.2, 1188 respectively. 1190 4.3. EDHOC-Exporter 1192 Application keys and other application specific data can be derived 1193 using the EDHOC-Exporter interface defined as: 1195 EDHOC-Exporter(label, context, length) 1196 = EDHOC-KDF(PRK_4x3m, TH_4, label, context, length) 1198 where label is a registered tstr from the EDHOC Exporter Label 1199 registry (Section 8.1), context is a CBOR sequence defined by the 1200 application, and length is a uint defined by the application. The 1201 (label, context) pair must be unique, i.e., a (label, context) MUST 1202 NOT be used for two different purposes. However an application can 1203 re-derive the same key several times as long as it is done in a 1204 secure way. For example, in most encryption algorithms the same 1205 (key, nonce) pair must not be reused. The context can for example be 1206 the empty (zero-length) sequence or a single CBOR byte string. 1208 The transcript hash TH_4 is a CBOR encoded bstr and the input to the 1209 hash function is a CBOR Sequence. 1211 TH_4 = H( TH_3, CIPHERTEXT_3 ) 1213 where H() is the hash function in the selected cipher suite. 1214 Examples of use of the EDHOC-Exporter are given in Section 5.5.2 and 1215 Appendix A. 1217 4.4. EDHOC-KeyUpdate 1219 To provide forward secrecy in an even more efficient way than re- 1220 running EDHOC, EDHOC provides the function EDHOC-KeyUpdate. When 1221 EDHOC-KeyUpdate is called the old PRK_4x3m is deleted and the new 1222 PRK_4x3m is calculated as a "hash" of the old key using the Extract 1223 function as illustrated by the following pseudocode: 1225 EDHOC-KeyUpdate( nonce ): 1226 PRK_4x3m = Extract( nonce, PRK_4x3m ) 1228 The EDHOC-KeyUpdate takes a nonce as input to guarantee that there 1229 are no short cycles. The Initiator and the Responder need to agree 1230 on the nonce, which can e.g., be a counter or a random number. While 1231 the KeyUpdate method provides forward secrecy it does not give as 1232 strong security properties as re-running EDHOC, see Section 7. 1234 5. Message Formatting and Processing 1236 This section specifies formatting of the messages and processing 1237 steps. Error messages are specified in Section 6. 1239 An EDHOC message is encoded as a sequence of CBOR data (CBOR 1240 Sequence, [RFC8742]). Additional optimizations are made to reduce 1241 message overhead. 1243 While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 1244 structures, only a subset of the parameters is included in the EDHOC 1245 messages, see Appendix C.3. The unprotected COSE header in 1246 COSE_Sign1, and COSE_Encrypt0 (not included in the EDHOC message) MAY 1247 contain parameters (e.g., 'alg'). 1249 5.1. Message Processing Outline 1251 This section outlines the message processing of EDHOC. 1253 For each session, the endpoints are assumed to keep an associated 1254 protocol state containing identifiers, keys, etc. used for subsequent 1255 processing of protocol related data. The protocol state is assumed 1256 to be associated to an applicability statement (Section 3.9) which 1257 provides the context for how messages are transported, identified, 1258 and processed. 1260 EDHOC messages SHALL be processed according to the current protocol 1261 state. The following steps are expected to be performed at reception 1262 of an EDHOC message: 1264 1. Detect that an EDHOC message has been received, for example by 1265 means of port number, URI, or media type (Section 3.9). 1267 2. Retrieve the protocol state according to the message correlation 1268 provided by the transport, see Section 3.4. If there is no 1269 protocol state, in the case of message_1, a new protocol state is 1270 created. The Responder endpoint needs to make use of available 1271 Denial-of-Service mitigation (Section 7.5). 1273 3. If the message received is an error message, then process 1274 according to Section 6, else process as the expected next message 1275 according to the protocol state. 1277 If the processing fails for some reason then, typically, an error 1278 message is sent, the protocol is discontinued, and the protocol state 1279 erased. Further details are provided in the following subsections 1280 and in Section 6. 1282 Different instances of the same message MUST NOT be processed in one 1283 session. Note that processing will fail if the same message appears 1284 a second time for EDHOC processing because the state of the protocol 1285 has moved on and now expects something else. This assumes that 1286 message duplication due to re-transmissions is handled by the 1287 transport protocol, see Section 3.4. The case when the transport 1288 does not support message deduplication is addressed in Appendix F. 1290 5.2. EDHOC Message 1 1292 5.2.1. Formatting of Message 1 1294 message_1 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1295 below 1297 message_1 = ( 1298 METHOD : int, 1299 SUITES_I : [ selected : suite, supported : 2* suite ] / suite, 1300 G_X : bstr, 1301 C_I : bstr / int, 1302 ? EAD_1 : ead, 1303 ) 1305 suite = int 1307 where: 1309 * METHOD = 0, 1, 2, or 3 (see Figure 4). 1311 * SUITES_I - cipher suites which the Initiator supports in order of 1312 (decreasing) preference. The list of supported cipher suites can 1313 be truncated at the end, as is detailed in the processing steps 1314 below and Section 6.3. One of the supported cipher suites is 1315 selected. The selected suite is the first suite in the SUITES_I 1316 CBOR array. If a single supported cipher suite is conveyed, then 1317 that cipher suite is selected and SUITES_I is encoded as an int 1318 instead of an array. 1320 * G_X - the ephemeral public key of the Initiator 1322 * C_I - variable length connection identifier 1324 * EAD_1 - unprotected external authorization data, see Section 3.8. 1326 5.2.2. Initiator Processing of Message 1 1328 The Initiator SHALL compose message_1 as follows: 1330 * The supported cipher suites and the order of preference MUST NOT 1331 be changed based on previous error messages. However, the list 1332 SUITES_I sent to the Responder MAY be truncated such that cipher 1333 suites which are the least preferred are omitted. The amount of 1334 truncation MAY be changed between sessions, e.g., based on 1335 previous error messages (see next bullet), but all cipher suites 1336 which are more preferred than the least preferred cipher suite in 1337 the list MUST be included in the list. 1339 * The Initiator MUST select its most preferred cipher suite, 1340 conditioned on what it can assume to be supported by the 1341 Responder. If the Initiator previously received from the 1342 Responder an error message with error code 2 (see Section 6.3) 1343 indicating cipher suites supported by the Responder which also are 1344 supported by the Initiator, then the Initiator SHOULD select the 1345 most preferred cipher suite of those (note that error messages are 1346 not authenticated and may be forged). 1348 * Generate an ephemeral ECDH key pair using the curve in the 1349 selected cipher suite and format it as a COSE_Key. Let G_X be the 1350 'x' parameter of the COSE_Key. 1352 * Choose a connection identifier C_I and store it for the length of 1353 the protocol. 1355 * Encode message_1 as a sequence of CBOR encoded data items as 1356 specified in Section 5.2.1 1358 5.2.3. Responder Processing of Message 1 1360 The Responder SHALL process message_1 as follows: 1362 * Decode message_1 (see Appendix C.1). 1364 * Verify that the selected cipher suite is supported and that no 1365 prior cipher suite in SUITES_I is supported. 1367 * Pass EAD_1 to the security application. 1369 If any processing step fails, the Responder SHOULD send an EDHOC 1370 error message back, formatted as defined in Section 6, and the 1371 session MUST be discontinued. Sending error messages is essential 1372 for debugging but MAY e.g., be skipped due to denial-of-service 1373 reasons, see Section 7. 1375 5.3. EDHOC Message 2 1377 5.3.1. Formatting of Message 2 1379 message_2 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1380 below 1382 message_2 = ( 1383 G_Y_CIPHERTEXT_2 : bstr, 1384 C_R : bstr / int, 1385 ) 1387 where: 1389 * G_Y_CIPHERTEXT_2 - the concatenation of G_Y, the ephemeral public 1390 key of the Responder, and CIPHERTEXT_2 1392 * C_R - variable length connection identifier 1394 5.3.2. Responder Processing of Message 2 1396 The Responder SHALL compose message_2 as follows: 1398 * Generate an ephemeral ECDH key pair using the curve in the 1399 selected cipher suite and format it as a COSE_Key. Let G_Y be the 1400 'x' parameter of the COSE_Key. 1402 * Choose a connection identifier C_R and store it for the length of 1403 the protocol. 1405 * Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R ) 1406 where H() is the hash function in the selected cipher suite. The 1407 transcript hash TH_2 is a CBOR encoded bstr and the input to the 1408 hash function is a CBOR Sequence. Note that H(message_1) can be 1409 computed and cached already in the processing of message_1. 1411 * Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", ( ID_CRED_R, 1412 CRED_R, ? EAD_2 ), mac_length ). If the Responder authenticates 1413 with a static Diffie-Hellman key (method equals 1 or 3), then 1414 mac_length is the EDHOC MAC length given by the cipher suite. If 1415 the Responder authenticates with a signature key (method equals 0 1416 or 2), then mac_length is equal to the output size of the EDHOC 1417 hash algorithm given by the cipher suite. 1419 - ID_CRED_R - identifier to facilitate retrieval of CRED_R, see 1420 Section 3.5.4 1422 - CRED_R - CBOR item containing the credential of the Responder, 1423 see Section 3.5.4 1425 - EAD_2 = unprotected external authorization data, see 1426 Section 3.8 1428 * If the Responder authenticates with a static Diffie-Hellman key 1429 (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the 1430 Responder authenticates with a signature key (method equals 0 or 1431 2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1 1432 object as defined in Section 4.4 of 1433 [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm in 1434 the selected cipher suite, the private authentication key of the 1435 Responder, and the following parameters: 1437 - protected = << ID_CRED_R >> 1439 - external_aad = << TH_2, CRED_R, ? EAD_2 >> 1441 - payload = MAC_2 1443 COSE constructs the input to the Signature Algorithm as: 1445 - The key is the private authentication key of the Responder. 1447 - The message M to be signed = 1449 [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? EAD_2 >>, 1450 MAC_2 ] 1452 * CIPHERTEXT_2 is encrypted by using the Expand function as a binary 1453 additive stream cipher. 1455 - plaintext = ( ID_CRED_R / bstr / int, Signature_or_MAC_2, ? 1456 EAD_2 ) 1458 o Note that if ID_CRED_R contains a single 'kid' parameter, 1459 i.e., ID_CRED_R = { 4 : kid_R }, only the byte string or 1460 integer kid_R is conveyed in the plaintext encoded as a bstr 1461 or int. 1463 - CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 1465 * Encode message_2 as a sequence of CBOR encoded data items as 1466 specified in Section 5.3.1. 1468 5.3.3. Initiator Processing of Message 2 1470 The Initiator SHALL process message_2 as follows: 1472 * Decode message_2 (see Appendix C.1). 1474 * Retrieve the protocol state using the message correlation provided 1475 by the transport (e.g., the CoAP Token and the 5-tuple as a 1476 client, or the prepended C_I as a server). 1478 * Decrypt CIPHERTEXT_2, see Section 5.3.2. 1480 * Pass EAD_2 to the security application. 1482 * Verify that the identity of the Responder is an allowed identity 1483 for this connection, see Section 3.5. 1485 * Verify Signature_or_MAC_2 using the algorithm in the selected 1486 cipher suite. The verification process depends on the method, see 1487 Section 5.3.2. 1489 If any processing step fails, the Initiator SHOULD send an EDHOC 1490 error message back, formatted as defined in Section 6. Sending error 1491 messages is essential for debugging but MAY e.g., be skipped if a 1492 session cannot be found or due to denial-of-service reasons, see 1493 Section 7. If an error message is sent, the session MUST be 1494 discontinued. 1496 5.4. EDHOC Message 3 1497 5.4.1. Formatting of Message 3 1499 message_3 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1500 below 1502 message_3 = ( 1503 CIPHERTEXT_3 : bstr, 1504 ) 1506 5.4.2. Initiator Processing of Message 3 1508 The Initiator SHALL compose message_3 as follows: 1510 * Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H() 1511 is the hash function in the selected cipher suite. The transcript 1512 hash TH_3 is a CBOR encoded bstr and the input to the hash 1513 function is a CBOR Sequence. Note that H(TH_2, CIPHERTEXT_2) can 1514 be computed and cached already in the processing of message_2. 1516 * Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", ( ID_CRED_I, 1517 CRED_I, ? EAD_3 ), mac_length ). If the Initiator authenticates 1518 with a static Diffie-Hellman key (method equals 2 or 3), then 1519 mac_length is the EDHOC MAC length given by the cipher suite. If 1520 the Initiator authenticates with a signature key (method equals 0 1521 or 1), then mac_length is equal to the output size of the EDHOC 1522 hash algorithm given by the cipher suite. 1524 - ID_CRED_I - identifier to facilitate retrieval of CRED_I, see 1525 Section 3.5.4 1527 - CRED_I - CBOR item containing the credential of the Initiator, 1528 see Section 3.5.4 1530 - EAD_3 = protected external authorization data, see Section 3.8 1532 * If the Initiator authenticates with a static Diffie-Hellman key 1533 (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3. If the 1534 Initiator authenticates with a signature key (method equals 0 or 1535 1), then Signature_or_MAC_3 is the 'signature' of a COSE_Sign1 1536 object as defined in Section 4.4 of 1537 [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm in 1538 the selected cipher suite, the private authentication key of the 1539 Initiator, and the following parameters: 1541 - protected = << ID_CRED_I >> 1543 - external_aad = << TH_3, CRED_I, ? EAD_3 >> 1544 - payload = MAC_3 1546 COSE constructs the input to the Signature Algorithm as: 1548 - The key is the private authentication key of the Initiator. 1550 - The message M to be signed = 1552 [ "Signature1", << ID_CRED_I >>, << TH_3, CRED_I, ? EAD_3 >>, 1553 MAC_3 ] 1555 * Compute an outer COSE_Encrypt0 as defined in Section 5.3 of 1556 [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm 1557 in the selected cipher suite, K_3ae, IV_3ae, and the following 1558 parameters. The protected header SHALL be empty. 1560 - external_aad = TH_3 1562 - plaintext = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? 1563 EAD_3 ) 1565 o Note that if ID_CRED_I contains a single 'kid' parameter, 1566 i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or 1567 integer kid_I is conveyed in the plaintext encoded as a bstr 1568 or int. 1570 COSE constructs the input to the AEAD [RFC5116] as follows: 1572 - Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length ) 1574 - Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length ) 1576 - Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? 1577 EAD_3 ) 1579 - Associated data A = [ "Encrypt0", h'', TH_3 ] 1581 CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0. 1583 * Encode message_3 as a sequence of CBOR encoded data items as 1584 specified in Section 5.4.1. 1586 Pass the connection identifiers (C_I, C_R) and the application 1587 algorithms in the selected cipher suite to the application. The 1588 application can now derive application keys using the EDHOC-Exporter 1589 interface, see Section 4.3. 1591 After sending message_3, the Initiator is assured that no other party 1592 than the Responder can compute the key PRK_4x3m (implicit key 1593 authentication). The Initiator can securely derive application keys 1594 and send protected application data. However, the Initiator does not 1595 know that the Responder has actually computed the key PRK_4x3m and 1596 therefore the Initiator SHOULD NOT permanently store the keying 1597 material PRK_4x3m and TH_4, or derived application keys, until the 1598 Initiator is assured that the Responder has actually computed the key 1599 PRK_4x3m (explicit key confirmation). This is similar to waiting for 1600 acknowledgement (ACK) in a transport protocol. Explicit key 1601 confirmation is e.g., assured when the Initiator has verified an 1602 OSCORE message or message_4 from the Responder. 1604 5.4.3. Responder Processing of Message 3 1606 The Responder SHALL process message_3 as follows: 1608 * Decode message_3 (see Appendix C.1). 1610 * Retrieve the protocol state using the message correlation provided 1611 by the transport (e.g., the CoAP Token and the 5-tuple as a 1612 client, or the prepended C_R as a server). 1614 * Decrypt and verify the outer COSE_Encrypt0 as defined in 1615 Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC 1616 AEAD algorithm in the selected cipher suite, K_3ae, and IV_3ae. 1618 * Pass EAD_3 to the security application. 1620 * Verify that the identity of the Initiator is an allowed identity 1621 for this connection, see Section 3.5. 1623 * Verify Signature_or_MAC_3 using the algorithm in the selected 1624 cipher suite. The verification process depends on the method, see 1625 Section 5.4.2. 1627 * Pass the connection identifiers (C_I, C_R), and the application 1628 algorithms in the selected cipher suite to the security 1629 application. The application can now derive application keys 1630 using the EDHOC-Exporter interface. 1632 If any processing step fails, the Responder SHOULD send an EDHOC 1633 error message back, formatted as defined in Section 6. Sending error 1634 messages is essential for debugging but MAY e.g., be skipped if a 1635 session cannot be found or due to denial-of-service reasons, see 1636 Section 7. If an error message is sent, the session MUST be 1637 discontinued. 1639 After verifying message_3, the Responder is assured that the 1640 Initiator has calculated the key PRK_4x3m (explicit key confirmation) 1641 and that no other party than the Responder can compute the key. The 1642 Responder can securely send protected application data and store the 1643 keying material PRK_4x3m and TH_4. 1645 5.5. EDHOC Message 4 1647 This section specifies message_4 which is OPTIONAL to support. Key 1648 confirmation is normally provided by sending an application message 1649 from the Responder to the Initiator protected with a key derived with 1650 the EDHOC-Exporter, e.g., using OSCORE (see Appendix A). In 1651 deployments where no protected application message is sent from the 1652 Responder to the Initiator, the Responder MUST send message_4. Two 1653 examples of such deployments: 1655 1. When EDHOC is only used for authentication and no application 1656 data is sent. 1658 2. When application data is only sent from the Initiator to the 1659 Responder. 1661 Further considerations are provided in Section 3.9. 1663 5.5.1. Formatting of Message 4 1665 message_4 SHALL be a CBOR Sequence (see Appendix C.1) as defined 1666 below 1668 message_4 = ( 1669 CIPHERTEXT_4 : bstr, 1670 ) 1672 5.5.2. Responder Processing of Message 4 1674 The Responder SHALL compose message_4 as follows: 1676 * Compute a COSE_Encrypt0 as defined in Section 5.3 of 1677 [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm 1678 in the selected cipher suite, and the following parameters. The 1679 protected header SHALL be empty. 1681 - protected = h'' 1683 - external_aad = TH_4 1685 - plaintext = ( ? EAD_4 ) 1686 where EAD_4 is protected external authorization data, see 1687 Section 3.8. COSE constructs the input to the AEAD [RFC5116] as 1688 follows: 1690 - Key K = EDHOC-Exporter( "EDHOC_message_4_Key", , length ) 1692 - Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", , length ) 1694 - Plaintext P = ( ? EAD_4 ) 1696 - Associated data A = [ "Encrypt0", h'', TH_4 ] 1698 CIPHERTEXT_4 is the ciphertext of the COSE_Encrypt0. 1700 * Encode message_4 as a sequence of CBOR encoded data items as 1701 specified in Section 5.5.1. 1703 5.5.3. Initiator Processing of Message 4 1705 The Initiator SHALL process message_4 as follows: 1707 * Decode message_4 (see Appendix C.1). 1709 * Retrieve the protocol state using the message correlation provided 1710 by the transport (e.g., the CoAP Token and the 5-tuple as a 1711 client, or the prepended C_I as a server). 1713 * Decrypt and verify the outer COSE_Encrypt0 as defined in 1714 Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC 1715 AEAD algorithm in the selected cipher suite, and the parameters 1716 defined in Section 5.5.2. 1718 * Pass EAD_4 to the security application. 1720 If any processing step fails, the Responder SHOULD send an EDHOC 1721 error message back, formatted as defined in Section 6. Sending error 1722 messages is essential for debugging but MAY e.g., be skipped if a 1723 session cannot be found or due to denial-of-service reasons, see 1724 Section 7. If an error message is sent, the session MUST be 1725 discontinued. 1727 6. Error Handling 1729 This section defines the format for error messages. 1731 An EDHOC error message can be sent by either endpoint as a reply to 1732 any non-error EDHOC message. How errors at the EDHOC layer are 1733 transported depends on lower layers, which need to enable error 1734 messages to be sent and processed as intended. 1736 Errors in EDHOC are fatal. After sending an error message, the 1737 sender MUST discontinue the protocol. The receiver SHOULD treat an 1738 error message as an indication that the other party likely has 1739 discontinued the protocol. But as the error message is not 1740 authenticated, a received error message might also have been sent by 1741 an attacker and the receiver MAY therefore try to continue the 1742 protocol. 1744 error SHALL be a CBOR Sequence (see Appendix C.1) as defined below 1746 error = ( 1747 ERR_CODE : int, 1748 ERR_INFO : any, 1749 ) 1751 Figure 5: EDHOC Error Message 1753 where: 1755 * ERR_CODE - error code encoded as an integer. The value 0 is used 1756 for success, all other values (negative or positive) indicate 1757 errors. 1759 * ERR_INFO - error information. Content and encoding depend on 1760 error code. 1762 The remainder of this section specifies the currently defined error 1763 codes, see Figure 6. Error codes 1 and 2 MUST be supported. 1764 Additional error codes and corresponding error information may be 1765 specified. 1767 +----------+---------------+----------------------------------------+ 1768 | ERR_CODE | ERR_INFO Type | Description | 1769 +==========+===============+========================================+ 1770 | 0 | any | Success | 1771 +----------+---------------+----------------------------------------+ 1772 | 1 | tstr | Unspecified | 1773 +----------+---------------+----------------------------------------+ 1774 | 2 | SUITES_R | Wrong selected cipher suite | 1775 +----------+---------------+----------------------------------------+ 1777 Figure 6: Error Codes and Error Information 1779 6.1. Success 1781 Error code 0 MAY be used internally in an application to indicate 1782 success, e.g., in log files. ERR_INFO can contain any type of CBOR 1783 item. Error code 0 MUST NOT be used as part of the EDHOC message 1784 exchange flow. 1786 6.2. Unspecified 1788 Error code 1 is used for errors that do not have a specific error 1789 code defined. ERR_INFO MUST be a text string containing a human- 1790 readable diagnostic message written in English. The diagnostic text 1791 message is mainly intended for software engineers that during 1792 debugging need to interpret it in the context of the EDHOC 1793 specification. The diagnostic message SHOULD be provided to the 1794 calling application where it SHOULD be logged. 1796 6.3. Wrong Selected Cipher Suite 1798 Error code 2 MUST only be used in a response to message_1 in case the 1799 cipher suite selected by the Initiator is not supported by the 1800 Responder, or if the Responder supports a cipher suite more preferred 1801 by the Initiator than the selected cipher suite, see Section 5.2.3. 1802 ERR_INFO is of type SUITES_R: 1804 SUITES_R : [ supported : 2* suite ] / suite 1806 If the Responder does not support the selected cipher suite, then 1807 SUITES_R MUST include one or more supported cipher suites. If the 1808 Responder does not support the selected cipher suite, but supports 1809 another cipher suite in SUITES_I, then SUITES_R MUST include the 1810 first supported cipher suite in SUITES_I. 1812 6.3.1. Cipher Suite Negotiation 1814 After receiving SUITES_R, the Initiator can determine which cipher 1815 suite to select for the next EDHOC run with the Responder. 1817 If the Initiator intends to contact the Responder in the future, the 1818 Initiator SHOULD remember which selected cipher suite to use until 1819 the next message_1 has been sent, otherwise the Initiator and 1820 Responder will likely run into an infinite loop. After a successful 1821 run of EDHOC, the Initiator MAY remember the selected cipher suite to 1822 use in future EDHOC runs. Note that if the Initiator or Responder is 1823 updated with new cipher suite policies, any cached information may be 1824 outdated. 1826 6.3.2. Examples 1828 Assume that the Initiator supports the five cipher suites 5, 6, 7, 8, 1829 and 9 in decreasing order of preference. Figures 7 and 8 show 1830 examples of how the Initiator can truncate SUITES_I and how SUITES_R 1831 is used by Responders to give the Initiator information about the 1832 cipher suites that the Responder supports. 1834 In the first example (Figure 7), the Responder supports cipher suite 1835 6 but not the initially selected cipher suite 5. 1837 Initiator Responder 1838 | METHOD, SUITES_I = 5, G_X, C_I, EAD_1 | 1839 +------------------------------------------------------------------>| 1840 | message_1 | 1841 | | 1842 | DIAG_MSG, SUITES_R = 6 | 1843 |<------------------------------------------------------------------+ 1844 | error | 1845 | | 1846 | METHOD, SUITES_I = [6, 5, 6], G_X, C_I, EAD_1 | 1847 +------------------------------------------------------------------>| 1848 | message_1 | 1850 Figure 7: Example of Responder supporting suite 6 but not suite 5. 1852 In the second example (Figure 8), the Responder supports cipher 1853 suites 8 and 9 but not the more preferred (by the Initiator) cipher 1854 suites 5, 6 or 7. To illustrate the negotiation mechanics we let the 1855 Initiator first make a guess that the Responder supports suite 6 but 1856 not suite 5. Since the Responder supports neither 5 nor 6, it 1857 responds with an error and SUITES_R, after which the Initiator 1858 selects its most preferred supported suite. The order of cipher 1859 suites in SUITES_R does not matter. (If the Responder had supported 1860 suite 5, it would include it in SUITES_R of the response, and it 1861 would in that case have become the selected suite in the second 1862 message_1.) 1863 Initiator Responder 1864 | METHOD, SUITES_I = [6, 5, 6], G_X, C_I, EAD_1 | 1865 +------------------------------------------------------------------>| 1866 | message_1 | 1867 | | 1868 | DIAG_MSG, SUITES_R = [9, 8] | 1869 |<------------------------------------------------------------------+ 1870 | error | 1871 | | 1872 | METHOD, SUITES_I = [8, 5, 6, 7, 8], G_X, C_I, EAD_1 | 1873 +------------------------------------------------------------------>| 1874 | message_1 | 1876 Figure 8: Example of Responder supporting suites 8 and 9 but not 1877 5, 6 or 7. 1879 Note that the Initiator's list of supported cipher suites and order 1880 of preference is fixed (see Section 5.2.1 and Section 5.2.2). 1881 Furthermore, the Responder shall only accept message_1 if the 1882 selected cipher suite is the first cipher suite in SUITES_I that the 1883 Responder supports (see Section 5.2.3). Following this procedure 1884 ensures that the selected cipher suite is the most preferred (by the 1885 Initiator) cipher suite supported by both parties. 1887 If the selected cipher suite is not the first cipher suite which the 1888 Responder supports in SUITES_I received in message_1, then Responder 1889 MUST discontinue the protocol, see Section 5.2.3. If SUITES_I in 1890 message_1 is manipulated, then the integrity verification of 1891 message_2 containing the transcript hash TH_2 will fail and the 1892 Initiator will discontinue the protocol. 1894 7. Security Considerations 1896 7.1. Security Properties 1898 EDHOC inherits its security properties from the theoretical SIGMA-I 1899 protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides 1900 forward secrecy, mutual authentication with aliveness, consistency, 1901 and peer awareness. As described in [SIGMA], peer awareness is 1902 provided to the Responder, but not to the Initiator. 1904 EDHOC protects the credential identifier of the Initiator against 1905 active attacks and the credential identifier of the Responder against 1906 passive attacks. The roles should be assigned to protect the most 1907 sensitive identity/identifier, typically that which is not possible 1908 to infer from routing information in the lower layers. 1910 Compared to [SIGMA], EDHOC adds an explicit method type and expands 1911 the message authentication coverage to additional elements such as 1912 algorithms, external authorization data, and previous messages. This 1913 protects against an attacker replaying messages or injecting messages 1914 from another session. 1916 EDHOC also adds selection of connection identifiers and downgrade 1917 protected negotiation of cryptographic parameters, i.e., an attacker 1918 cannot affect the negotiated parameters. A single session of EDHOC 1919 does not include negotiation of cipher suites, but it enables the 1920 Responder to verify that the selected cipher suite is the most 1921 preferred cipher suite by the Initiator which is supported by both 1922 the Initiator and the Responder. 1924 As required by [RFC7258], IETF protocols need to mitigate pervasive 1925 monitoring when possible. EDHOC therefore only supports methods with 1926 ephemeral Diffie-Hellman and provides a KeyUpdate function for 1927 lightweight application protocol rekeying with forward secrecy, in 1928 the sense that compromise of the private authentication keys does not 1929 compromise past session keys, and compromise of a session key does 1930 not compromise past session keys. 1932 While the KeyUpdate method can be used to meet cryptographic limits 1933 and provide partial protection against key leakage, it provides 1934 significantly weaker security properties than re-running EDHOC with 1935 ephemeral Diffie-Hellman. Even with frequent use of KeyUpdate, 1936 compromise of one session key compromises all future session keys, 1937 and an attacker therefore only needs to perform static key 1938 exfiltration [RFC7624]. Frequently re-running EDHOC with ephemeral 1939 Diffie-Hellman forces attackers to perform dynamic key exfiltration 1940 instead of static key exfiltration [RFC7624]. In the dynamic case, 1941 the attacker must have continuous interactions with the collaborator, 1942 which is more complicated and has a higher risk profile than the 1943 static case. 1945 To limit the effect of breaches, it is important to limit the use of 1946 symmetrical group keys for bootstrapping. EDHOC therefore strives to 1947 make the additional cost of using raw public keys and self-signed 1948 certificates as small as possible. Raw public keys and self-signed 1949 certificates are not a replacement for a public key infrastructure 1950 but SHOULD be used instead of symmetrical group keys for 1951 bootstrapping. 1953 Compromise of the long-term keys (private signature or static DH 1954 keys) does not compromise the security of completed EDHOC exchanges. 1955 Compromising the private authentication keys of one party lets an 1956 active attacker impersonate that compromised party in EDHOC exchanges 1957 with other parties but does not let the attacker impersonate other 1958 parties in EDHOC exchanges with the compromised party. Compromise of 1959 the long-term keys does not enable a passive attacker to compromise 1960 future session keys. Compromise of the HDKF input parameters (ECDH 1961 shared secret) leads to compromise of all session keys derived from 1962 that compromised shared secret. Compromise of one session key does 1963 not compromise other session keys. Compromise of PRK_4x3m leads to 1964 compromise of all exported keying material derived after the last 1965 invocation of the EDHOC-KeyUpdate function. 1967 EDHOC provides a minimum of 64-bit security against online brute 1968 force attacks and a minimum of 128-bit security against offline brute 1969 force attacks. This is in line with IPsec, TLS, and COSE. To break 1970 64-bit security against online brute force an attacker would on 1971 average have to send 4.3 billion messages per second for 68 years, 1972 which is infeasible in constrained IoT radio technologies. 1974 After sending message_3, the Initiator is assured that no other party 1975 than the Responder can compute the key PRK_4x3m (implicit key 1976 authentication). The Initiator does however not know that the 1977 Responder has actually computed the key PRK_4x3m. While the 1978 Initiator can securely send protected application data, the Initiator 1979 SHOULD NOT permanently store the keying material PRK_4x3m and TH_4 1980 until the Initiator is assured that the Responder has actually 1981 computed the key PRK_4x3m (explicit key confirmation). Explicit key 1982 confirmation is e.g., assured when the Initiator has verified an 1983 OSCORE message or message_4 from the Responder. After verifying 1984 message_3, the Responder is assured that the Initiator has calculated 1985 the key PRK_4x3m (explicit key confirmation) and that no other party 1986 than the Responder can compute the key. The Responder can securely 1987 send protected application data and store the keying material 1988 PRK_4x3m and TH_4. 1990 Key compromise impersonation (KCI): In EDHOC authenticated with 1991 signature keys, EDHOC provides KCI protection against an attacker 1992 having access to the long-term key or the ephemeral secret key. With 1993 static Diffie-Hellman key authentication, KCI protection would be 1994 provided against an attacker having access to the long-term Diffie- 1995 Hellman key, but not to an attacker having access to the ephemeral 1996 secret key. Note that the term KCI has typically been used for 1997 compromise of long-term keys, and that an attacker with access to the 1998 ephemeral secret key can only attack that specific protocol run. 2000 Repudiation: In EDHOC authenticated with signature keys, the 2001 Initiator could theoretically prove that the Responder performed a 2002 run of the protocol by presenting the private ephemeral key, and vice 2003 versa. Note that storing the private ephemeral keys violates the 2004 protocol requirements. With static Diffie-Hellman key 2005 authentication, both parties can always deny having participated in 2006 the protocol. 2008 Two earlier versions of EDHOC have been formally analyzed [Norrman20] 2009 [Bruni18] and the specification has been updated based on the 2010 analysis. 2012 7.2. Cryptographic Considerations 2014 The SIGMA protocol requires that the encryption of message_3 provides 2015 confidentiality against active attackers and EDHOC message_4 relies 2016 on the use of authenticated encryption. Hence the message 2017 authenticating functionality of the authenticated encryption in EDHOC 2018 is critical: authenticated encryption MUST NOT be replaced by plain 2019 encryption only, even if authentication is provided at another level 2020 or through a different mechanism. 2022 To reduce message overhead EDHOC does not use explicit nonces and 2023 instead rely on the ephemeral public keys to provide randomness to 2024 each session. A good amount of randomness is important for the key 2025 generation, to provide liveness, and to protect against interleaving 2026 attacks. For this reason, the ephemeral keys MUST NOT be reused, and 2027 both parties SHALL generate fresh random ephemeral key pairs. 2029 As discussed, the [SIGMA], the encryption of message_2 does only need 2030 to protect against passive attacker as active attackers can always 2031 get the Responders identity by sending their own message_1. EDHOC 2032 uses the Expand function (typically HKDF-Expand) as a binary additive 2033 stream cipher. HKDF-Expand provides better confidentiality than AES- 2034 CTR but is not often used as it is slow on long messages, and most 2035 applications require both IND-CCA confidentiality as well as 2036 integrity protection. For the encryption of message_2, any speed 2037 difference is negligible, IND-CCA does not increase security, and 2038 integrity is provided by the inner MAC (and signature depending on 2039 method). 2041 Requirement for how to securely generate, validate, and process the 2042 ephemeral public keys depend on the elliptic curve. For X25519 and 2043 X448, the requirements are defined in [RFC7748]. For secp256r1, 2044 secp384r1, and secp521r1, the requirements are defined in Section 5 2045 of [SP-800-56A]. For secp256r1, secp384r1, and secp521r1, at least 2046 partial public-key validation MUST be done. 2048 7.3. Cipher Suites and Cryptographic Algorithms 2050 For many constrained IoT devices it is problematic to support more 2051 than one cipher suite. Existing devices can be expected to support 2052 either ECDSA or EdDSA. To enable as much interoperability as we can 2053 reasonably achieve, less constrained devices SHOULD implement both 2054 cipher suite 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, AES-CCM- 2055 16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA-256, 2056 P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained endpoints 2057 SHOULD implement cipher suite 0 or cipher suite 2. Implementations 2058 only need to implement the algorithms needed for their supported 2059 methods. 2061 When using private cipher suite or registering new cipher suites, the 2062 choice of key length used in the different algorithms needs to be 2063 harmonized, so that a sufficient security level is maintained for 2064 certificates, EDHOC, and the protection of application data. The 2065 Initiator and the Responder should enforce a minimum security level. 2067 The hash algorithms SHA-1 and SHA-256/64 (256-bit Hash truncated to 2068 64-bits) SHALL NOT be supported for use in EDHOC except for 2069 certificate identification with x5u and c5u. Note that secp256k1 is 2070 only defined for use with ECDSA and not for ECDH. 2072 7.4. Unprotected Data 2074 The Initiator and the Responder must make sure that unprotected data 2075 and metadata do not reveal any sensitive information. This also 2076 applies for encrypted data sent to an unauthenticated party. In 2077 particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error 2078 messages. Using the same EAD_1 in several EDHOC sessions allows 2079 passive eavesdroppers to correlate the different sessions. Another 2080 consideration is that the list of supported cipher suites may 2081 potentially be used to identify the application. 2083 The Initiator and the Responder must also make sure that 2084 unauthenticated data does not trigger any harmful actions. In 2085 particular, this applies to EAD_1 and error messages. 2087 7.5. Denial-of-Service 2089 EDHOC itself does not provide countermeasures against Denial-of- 2090 Service attacks. By sending a number of new or replayed message_1 an 2091 attacker may cause the Responder to allocate state, perform 2092 cryptographic operations, and amplify messages. To mitigate such 2093 attacks, an implementation SHOULD rely on lower layer mechanisms such 2094 as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that 2095 forces the initiator to demonstrate reachability at its apparent 2096 network address. 2098 An attacker can also send faked message_2, message_3, message_4, or 2099 error in an attempt to trick the receiving party to send an error 2100 message and discontinue the session. EDHOC implementations MAY 2101 evaluate if a received message is likely to have been forged by and 2102 attacker and ignore it without sending an error message or 2103 discontinuing the session. 2105 7.6. Implementation Considerations 2107 The availability of a secure random number generator is essential for 2108 the security of EDHOC. If no true random number generator is 2109 available, a truly random seed MUST be provided from an external 2110 source and used with a cryptographically secure pseudorandom number 2111 generator. As each pseudorandom number must only be used once, an 2112 implementation needs to get a new truly random seed after reboot, or 2113 continuously store state in nonvolatile memory, see ([RFC8613], 2114 Appendix B.1.1) for issues and solution approaches for writing to 2115 nonvolatile memory. Intentionally or unintentionally weak or 2116 predictable pseudorandom number generators can be abused or exploited 2117 for malicious purposes. [RFC8937] describes a way for security 2118 protocol implementations to augment their (pseudo)random number 2119 generators using a long-term private key and a deterministic 2120 signature function. This improves randomness from broken or 2121 otherwise subverted random number generators. The same idea can be 2122 used with other secrets and functions such as a Diffie-Hellman 2123 function or a symmetric secret and a PRF like HMAC or KMAC. It is 2124 RECOMMENDED to not trust a single source of randomness and to not put 2125 unaugmented random numbers on the wire. 2127 If ECDSA is supported, "deterministic ECDSA" as specified in 2128 [RFC6979] MAY be used. Pure deterministic elliptic-curve signatures 2129 such as deterministic ECDSA and EdDSA have gained popularity over 2130 randomized ECDSA as their security do not depend on a source of high- 2131 quality randomness. Recent research has however found that 2132 implementations of these signature algorithms may be vulnerable to 2133 certain side-channel and fault injection attacks due to their 2134 determinism. See e.g., Section 1 of 2136 [I-D.mattsson-cfrg-det-sigs-with-noise] for a list of attack papers. 2137 As suggested in Section 6.1.2 of [I-D.ietf-cose-rfc8152bis-algs] this 2138 can be addressed by combining randomness and determinism. 2140 All private keys, symmetric keys, and IVs MUST be secret. 2141 Implementations should provide countermeasures to side-channel 2142 attacks such as timing attacks. Intermediate computed values such as 2143 ephemeral ECDH keys and ECDH shared secrets MUST be deleted after key 2144 derivation is completed. 2146 The Initiator and the Responder are responsible for verifying the 2147 integrity of certificates. The selection of trusted CAs should be 2148 done very carefully and certificate revocation should be supported. 2149 The private authentication keys MUST be kept secret. 2151 The Initiator and the Responder are allowed to select the connection 2152 identifiers C_I and C_R, respectively, for the other party to use in 2153 the ongoing EDHOC protocol as well as in a subsequent application 2154 protocol (e.g., OSCORE [RFC8613]). The choice of connection 2155 identifier is not security critical in EDHOC but intended to simplify 2156 the retrieval of the right security context in combination with using 2157 short identifiers. If the wrong connection identifier of the other 2158 party is used in a protocol message it will result in the receiving 2159 party not being able to retrieve a security context (which will 2160 terminate the protocol) or retrieve the wrong security context (which 2161 also terminates the protocol as the message cannot be verified). 2163 If two nodes unintentionally initiate two simultaneous EDHOC message 2164 exchanges with each other even if they only want to complete a single 2165 EDHOC message exchange, they MAY terminate the exchange with the 2166 lexicographically smallest G_X. If the two G_X values are equal, the 2167 received message_1 MUST be discarded to mitigate reflection attacks. 2168 Note that in the case of two simultaneous EDHOC exchanges where the 2169 nodes only complete one and where the nodes have different preferred 2170 cipher suites, an attacker can affect which of the two nodes' 2171 preferred cipher suites will be used by blocking the other exchange. 2173 If supported by the device, it is RECOMMENDED that at least the long- 2174 term private keys are stored in a Trusted Execution Environment (TEE) 2175 and that sensitive operations using these keys are performed inside 2176 the TEE. To achieve even higher security, it is RECOMMENDED that in 2177 additional operations such as ephemeral key generation, all 2178 computations of shared secrets, and storage of the pseudorandom keys 2179 (PRK) can be done inside the TEE. The use of a TEE enforces that 2180 code within that environment cannot be tampered with, and that any 2181 data used by such code cannot be read or tampered with by code 2182 outside that environment. Note that non-EDHOC code inside the TEE 2183 might still be able to read EDHOC data and tamper with EDHOC code, to 2184 protect against such attacks EDHOC needs to be in its own zone. To 2185 provide better protection against some forms of physical attacks, 2186 sensitive EDHOC data should be stored inside the SoC or encrypted and 2187 integrity protected when sent on a data bus (e.g., between the CPU 2188 and RAM or Flash). Secure boot can be used to increase the security 2189 of code and data in the Rich Execution Environment (REE) by 2190 validating the REE image. 2192 8. IANA Considerations 2194 8.1. EDHOC Exporter Label 2196 IANA has created a new registry titled "EDHOC Exporter Label" under 2197 the new heading "EDHOC". The registration procedure is "Expert 2198 Review". The columns of the registry are Label, Description, and 2199 Reference. All columns are text strings. The initial contents of 2200 the registry are: 2202 Label: EDHOC_message_4_Key 2203 Description: Key used to protect EDHOC message_4 2204 Reference: [[this document]] 2206 Label: EDHOC_message_4_Nonce 2207 Description: Nonce used to protect EDHOC message_4 2208 Reference: [[this document]] 2210 Label: OSCORE Master Secret 2211 Description: Derived OSCORE Master Secret 2212 Reference: [[this document]] 2214 Label: OSCORE Master Salt 2215 Description: Derived OSCORE Master Salt 2216 Reference: [[this document]] 2218 8.2. EDHOC Cipher Suites Registry 2220 IANA has created a new registry titled "EDHOC Cipher Suites" under 2221 the new heading "EDHOC". The registration procedure is "Expert 2222 Review". The columns of the registry are Value, Array, Description, 2223 and Reference, where Value is an integer and the other columns are 2224 text strings. The initial contents of the registry are: 2226 Value: -24 2227 Algorithms: N/A 2228 Desc: Reserved for Private Use 2229 Reference: [[this document]] 2230 Value: -23 2231 Algorithms: N/A 2232 Desc: Reserved for Private Use 2233 Reference: [[this document]] 2235 Value: -22 2236 Algorithms: N/A 2237 Desc: Reserved for Private Use 2238 Reference: [[this document]] 2240 Value: -21 2241 Algorithms: N/A 2242 Desc: Reserved for Private Use 2243 Reference: [[this document]] 2245 Value: 0 2246 Array: 10, -16, 4, -8, 10, -16 2247 Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA, 2248 AES-CCM-16-64-128, SHA-256 2249 Reference: [[this document]] 2251 Value: 1 2252 Array: 30, -16, 4, -8, 10, -16 2253 Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA, 2254 AES-CCM-16-64-128, SHA-256 2255 Reference: [[this document]] 2257 Value: 2 2258 Array: 10, -16, 1, -7, 10, -16 2259 Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, 2260 AES-CCM-16-64-128, SHA-256 2261 Reference: [[this document]] 2263 Value: 3 2264 Array: 30, -16, 1, -7, 10, -16 2265 Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256, 2266 AES-CCM-16-64-128, SHA-256 2267 Reference: [[this document]] 2269 Value: 4 2270 Array: 24, -16, 4, -8, 24, -16 2271 Desc: ChaCha20/Poly1305, SHA-256, X25519, EdDSA, 2272 ChaCha20/Poly1305, SHA-256 2273 Reference: [[this document]] 2274 Value: 5 2275 Array: 24, -16, 1, -7, 24, -16 2276 Desc: ChaCha20/Poly1305, SHA-256, P-256, ES256, 2277 ChaCha20/Poly1305, SHA-256 2278 Reference: [[this document]] 2280 Value: 6 2281 Array: 1, -16, 4, -7, 1, -16 2282 Desc: A128GCM, SHA-256, X25519, ES256, 2283 A128GCM, SHA-256 2284 Reference: [[this document]] 2286 Value: 24 2287 Array: 3, -43, 2, -35, 3, -43 2288 Desc: A256GCM, SHA-384, P-384, ES384, 2289 A256GCM, SHA-384 2290 Reference: [[this document]] 2292 Value: 25 2293 Array: 24, -45, 5, -8, 24, -45 2294 Desc: ChaCha20/Poly1305, SHAKE256, X448, EdDSA, 2295 ChaCha20/Poly1305, SHAKE256 2296 Reference: [[this document]] 2298 8.3. EDHOC Method Type Registry 2300 IANA has created a new registry entitled "EDHOC Method Type" under 2301 the new heading "EDHOC". The registration procedure is "Expert 2302 Review". The columns of the registry are Value, Description, and 2303 Reference, where Value is an integer and the other columns are text 2304 strings. The initial contents of the registry are shown in Figure 4. 2306 8.4. EDHOC Error Codes Registry 2308 IANA has created a new registry entitled "EDHOC Error Codes" under 2309 the new heading "EDHOC". The registration procedure is 2310 "Specification Required". The columns of the registry are ERR_CODE, 2311 ERR_INFO Type and Description, where ERR_CODE is an integer, ERR_INFO 2312 is a CDDL defined type, and Description is a text string. The 2313 initial contents of the registry are shown in Figure 6. 2315 8.5. COSE Header Parameters Registry 2317 This document registers the following entries in the "COSE Header 2318 Parameters" registry under the "CBOR Object Signing and Encryption 2319 (COSE)" heading. The value of the 'cwt' header parameter is a CWT 2320 [RFC8392] or an Unprotected CWT Claims Set, see Section 1.5. 2322 +-----------+-------+----------------+------------------------------+ 2323 | Name | Label | Value Type | Description | 2324 +===========+=======+================+==============================+ 2325 | cwt | TBD1 | COSE_Messages | A CBOR Web Token (CWT) or an | 2326 | | | / map | Unprotected CWT Claims Set | 2327 +-----------+-------+----------------+------------------------------+ 2329 8.6. COSE Header Parameters Registry 2331 IANA has extended the Value Type of the COSE Header Parameter 'kid' 2332 to also allow the Value Type int. The resulting Value Type is bstr / 2333 int. The 'kid' parameter can be used to identify a key stored in a 2334 UCCS, in a CWT, or in a public key certificate. (The Value Registry 2335 for this item is empty and omitted from the table below.) 2337 +------+-------+------------+----------------+-------------------+ 2338 | Name | Label | Value Type | Description | Reference | 2339 +------+-------+------------+----------------+-------------------+ 2340 | kid | 4 | bstr / int | Key identifier | [RFC9052] | 2341 | | | | | [[This document]] | 2342 +------+-------+------------+----------------+-------------------+ 2344 8.7. COSE Key Common Parameters Registry 2346 IANA has extended the Value Type of the COSE Key Common Parameter 2347 'kid' to the COSE Key Value Type int. The resulting Value Type is 2348 bstr / int. (The Value Registry for this item is empty and omitted 2349 from the table below.) 2351 +------+-------+------------+----------------+-------------------+ 2352 | Name | Label | Value Type | Description | Reference | 2353 +------+-------+------------+----------------+-------------------+ 2354 | kid | 2 | bstr / int | Key identifi- | [RFC9052] | 2355 | | | | cation value - | [[This document]] | 2356 | | | | match to kid | | 2357 | | | | in message | | 2358 +------+-------+------------+----------------+-------------------+ 2360 8.8. The Well-Known URI Registry 2362 IANA has added the well-known URI "edhoc" to the Well-Known URIs 2363 registry. 2365 * URI suffix: edhoc 2367 * Change controller: IETF 2369 * Specification document(s): [[this document]] 2370 * Related information: None 2372 8.9. Media Types Registry 2374 IANA has added the media type "application/edhoc" to the Media Types 2375 registry. 2377 * Type name: application 2379 * Subtype name: edhoc 2381 * Required parameters: N/A 2383 * Optional parameters: N/A 2385 * Encoding considerations: binary 2387 * Security considerations: See Section 7 of this document. 2389 * Interoperability considerations: N/A 2391 * Published specification: [[this document]] (this document) 2393 * Applications that use this media type: To be identified 2395 * Fragment identifier considerations: N/A 2397 * Additional information: 2399 - Magic number(s): N/A 2401 - File extension(s): N/A 2403 - Macintosh file type code(s): N/A 2405 * Person & email address to contact for further information: See 2406 "Authors' Addresses" section. 2408 * Intended usage: COMMON 2410 * Restrictions on usage: N/A 2412 * Author: See "Authors' Addresses" section. 2414 * Change Controller: IESG 2416 8.10. CoAP Content-Formats Registry 2418 IANA has added the media type "application/edhoc" to the CoAP 2419 Content-Formats registry. 2421 * Media Type: application/edhoc 2423 * Encoding: 2425 * ID: TBD42 2427 * Reference: [[this document]] 2429 8.11. EDHOC External Authorization Data 2431 IANA has created a new registry entitled "EDHOC External 2432 Authorization Data" under the new heading "EDHOC". The registration 2433 procedure is "Expert Review". The columns of the registry are Value, 2434 Description, and Reference, where Value is an integer and the other 2435 columns are text strings. 2437 8.12. Expert Review Instructions 2439 The IANA Registries established in this document is defined as 2440 "Expert Review". This section gives some general guidelines for what 2441 the experts should be looking for, but they are being designated as 2442 experts for a reason so they should be given substantial latitude. 2444 Expert reviewers should take into consideration the following points: 2446 * Clarity and correctness of registrations. Experts are expected to 2447 check the clarity of purpose and use of the requested entries. 2448 Expert needs to make sure the values of algorithms are taken from 2449 the right registry, when that is required. Expert should consider 2450 requesting an opinion on the correctness of registered parameters 2451 from relevant IETF working groups. Encodings that do not meet 2452 these objective of clarity and completeness should not be 2453 registered. 2455 * Experts should take into account the expected usage of fields when 2456 approving point assignment. The length of the encoded value 2457 should be weighed against how many code points of that length are 2458 left, the size of device it will be used on, and the number of 2459 code points left that encode to that size. 2461 * Specifications are recommended. When specifications are not 2462 provided, the description provided needs to have sufficient 2463 information to verify the points above. 2465 9. References 2467 9.1. Normative References 2469 [I-D.ietf-core-echo-request-tag] 2470 Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, 2471 Request-Tag, and Token Processing", Work in Progress, 2472 Internet-Draft, draft-ietf-core-echo-request-tag-13, 12 2473 July 2021, . 2476 [I-D.ietf-cose-rfc8152bis-algs] 2477 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2478 Initial Algorithms", Work in Progress, Internet-Draft, 2479 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2480 . 2483 [I-D.ietf-cose-rfc8152bis-struct] 2484 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2485 Structures and Process", Work in Progress, Internet-Draft, 2486 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2487 . 2490 [I-D.ietf-cose-x509] 2491 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2492 Header parameters for carrying and referencing X.509 2493 certificates", Work in Progress, Internet-Draft, draft- 2494 ietf-cose-x509-08, 14 December 2020, 2495 . 2498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2499 Requirement Levels", BCP 14, RFC 2119, 2500 DOI 10.17487/RFC2119, March 1997, 2501 . 2503 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2504 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2505 . 2507 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2508 Housley, R., and W. Polk, "Internet X.509 Public Key 2509 Infrastructure Certificate and Certificate Revocation List 2510 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2511 . 2513 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2514 Key Derivation Function (HKDF)", RFC 5869, 2515 DOI 10.17487/RFC5869, May 2010, 2516 . 2518 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2519 Curve Cryptography Algorithms", RFC 6090, 2520 DOI 10.17487/RFC6090, February 2011, 2521 . 2523 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 2524 Algorithm (DSA) and Elliptic Curve Digital Signature 2525 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2526 2013, . 2528 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2529 Application Protocol (CoAP)", RFC 7252, 2530 DOI 10.17487/RFC7252, June 2014, 2531 . 2533 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 2534 Trammell, B., Huitema, C., and D. Borkmann, 2535 "Confidentiality in the Face of Pervasive Surveillance: A 2536 Threat Model and Problem Statement", RFC 7624, 2537 DOI 10.17487/RFC7624, August 2015, 2538 . 2540 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2541 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2542 2016, . 2544 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2545 the Constrained Application Protocol (CoAP)", RFC 7959, 2546 DOI 10.17487/RFC7959, August 2016, 2547 . 2549 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2550 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2551 May 2017, . 2553 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2554 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2555 . 2557 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2558 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2559 May 2018, . 2561 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2562 Definition Language (CDDL): A Notational Convention to 2563 Express Concise Binary Object Representation (CBOR) and 2564 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2565 June 2019, . 2567 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2568 "Object Security for Constrained RESTful Environments 2569 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2570 . 2572 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2573 Zúñiga, "SCHC: Generic Framework for Static Context Header 2574 Compression and Fragmentation", RFC 8724, 2575 DOI 10.17487/RFC8724, April 2020, 2576 . 2578 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 2579 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 2580 . 2582 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2583 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2584 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2585 2020, . 2587 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2588 Representation (CBOR)", STD 94, RFC 8949, 2589 DOI 10.17487/RFC8949, December 2020, 2590 . 2592 9.2. Informative References 2594 [Bruni18] Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and 2595 C. Schürmann, "Formal Verification of Ephemeral Diffie- 2596 Hellman Over COSE (EDHOC)", November 2018, 2597 . 2601 [CborMe] Bormann, C., "CBOR Playground", May 2018, 2602 . 2604 [CNSA] (Placeholder), ., "Commercial National Security Algorithm 2605 Suite", August 2015, 2606 . 2609 [I-D.ietf-core-oscore-edhoc] 2610 Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., 2611 and G. Selander, "Combining EDHOC and OSCORE", Work in 2612 Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-01, 2613 12 July 2021, . 2616 [I-D.ietf-core-resource-directory] 2617 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 2618 D. Stok, "CoRE Resource Directory", Work in Progress, 2619 Internet-Draft, draft-ietf-core-resource-directory-28, 7 2620 March 2021, . 2623 [I-D.ietf-cose-cbor-encoded-cert] 2624 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 2625 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 2626 Certificates)", Work in Progress, Internet-Draft, draft- 2627 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 2628 . 2631 [I-D.ietf-lake-reqs] 2632 Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia- 2633 Carrillo, "Requirements for a Lightweight AKE for OSCORE", 2634 Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04, 2635 8 June 2020, . 2638 [I-D.ietf-lwig-security-protocol-comparison] 2639 Mattsson, J. P., Palombini, F., and M. Vucinic, 2640 "Comparison of CoAP Security Protocols", Work in Progress, 2641 Internet-Draft, draft-ietf-lwig-security-protocol- 2642 comparison-05, 2 November 2020, 2643 . 2646 [I-D.ietf-rats-uccs] 2647 Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. 2648 Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", 2649 Work in Progress, Internet-Draft, draft-ietf-rats-uccs-01, 2650 12 July 2021, . 2653 [I-D.ietf-tls-dtls13] 2654 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2655 Datagram Transport Layer Security (DTLS) Protocol Version 2656 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 2657 dtls13-43, 30 April 2021, . 2660 [I-D.mattsson-cfrg-det-sigs-with-noise] 2661 Mattsson, J. P., Thormarker, E., and S. Ruohomaa, 2662 "Deterministic ECDSA and EdDSA Signatures with Additional 2663 Randomness", Work in Progress, Internet-Draft, draft- 2664 mattsson-cfrg-det-sigs-with-noise-02, 11 March 2020, 2665 . 2668 [I-D.selander-ace-ake-authz] 2669 Selander, G., Mattsson, J. P., Vucinic, M., Richardson, 2670 M., and A. Schellenbaum, "Lightweight Authorization for 2671 Authenticated Key Exchange.", Work in Progress, Internet- 2672 Draft, draft-selander-ace-ake-authz-03, 4 May 2021, 2673 . 2676 [Norrman20] 2677 Norrman, K., Sundararajan, V., and A. Bruni, "Formal 2678 Analysis of EDHOC Key Establishment for Constrained IoT 2679 Devices", September 2020, 2680 . 2682 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2683 Constrained-Node Networks", RFC 7228, 2684 DOI 10.17487/RFC7228, May 2014, 2685 . 2687 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2688 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2689 2014, . 2691 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2692 Kivinen, "Internet Key Exchange Protocol Version 2 2693 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2694 2014, . 2696 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2697 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2698 . 2700 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 2701 and C. Wood, "Randomness Improvements for Security 2702 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 2703 . 2705 [SECG] "Standards for Efficient Cryptography 1 (SEC 1)", May 2706 2009, . 2708 [SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to 2709 Authenticated Diffie-Hellman and Its Use in the IKE- 2710 Protocols (Long version)", June 2003, 2711 . 2713 [SP-800-56A] 2714 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 2715 Davis, "Recommendation for Pair-Wise Key-Establishment 2716 Schemes Using Discrete Logarithm Cryptography", 2717 NIST Special Publication 800-56A Revision 3, April 2018, 2718 . 2720 Appendix A. Use with OSCORE and Transfer over CoAP 2722 This appendix describes how to select EDHOC connection identifiers 2723 and derive an OSCORE security context when OSCORE is used with EDHOC, 2724 and how to transfer EDHOC messages over CoAP. 2726 A.1. Selecting EDHOC Connection Identifier 2728 This section specifies a rule for converting from EDHOC connection 2729 identifier to OSCORE Sender/Recipient ID. (An identifier is Sender 2730 ID or Recipient ID depending on from which endpoint is the point of 2731 view, see Section 3.1 of [RFC8613].) 2733 * If the EDHOC connection identifier is numeric, i.e., encoded as a 2734 CBOR integer on the wire, it is converted to a (naturally byte- 2735 string shaped) OSCORE Sender/Recipient ID equal to its CBOR 2736 encoded form. 2738 For example, a numeric C_R equal to 10 (0x0A in CBOR encoding) is 2739 converted to a (typically client) Sender ID equal to 0x0A, while a 2740 numeric C_I equal to -12 (0x2B in CBOR encoding) is converted to a 2741 (typically client) Sender ID equal to 0x2B. 2743 * If the EDHOC connection identifier is byte-valued, hence encoded 2744 as a CBOR byte string on the wire, it is converted to an OSCORE 2745 Sender/Recipient ID equal to the byte string. 2747 For example, a byte-string valued C_R equal to 0xFF (0x41FF in CBOR 2748 encoding) is converted to a (typically client) Sender ID equal to 2749 0xFF. 2751 Two EDHOC connection identifiers are called "equivalent" if and only 2752 if, by applying the conversion above, they both result in the same 2753 OSCORE Sender/Recipient ID. For example, the two EDHOC connection 2754 identifiers with CBOR encoding 0x0A (numeric) and 0x410A (byte- 2755 valued) are equivalent since they both result in the same OSCORE 2756 Sender/Recipient ID 0x0A. 2758 When EDHOC is used to establish an OSCORE security context, the 2759 connection identifiers C_I and C_R MUST NOT be equivalent. 2760 Furthermore, in case of multiple OSCORE security contexts with 2761 potentially different endpoints, to facilitate retrieval of the 2762 correct OSCORE security context, an endpoint SHOULD select an EDHOC 2763 connection identifier that when converted to OSCORE Recipient ID does 2764 not coincide with its other Recipient IDs. 2766 A.2. Deriving the OSCORE Security Context 2768 This section specifies how to use EDHOC output to derive the OSCORE 2769 security context. 2771 After successful processing of EDHOC message_3, Client and Server 2772 derive Security Context parameters for OSCORE as follows (see 2773 Section 3.2 of [RFC8613]): 2775 * The Master Secret and Master Salt are derived by using the EDHOC- 2776 Exporter interface, see Section 4.3. 2778 The EDHOC Exporter Labels for deriving the OSCORE Master Secret and 2779 the OSCORE Master Salt, are "OSCORE Master Secret" and "OSCORE Master 2780 Salt", respectively. 2782 The context parameter is h'' (0x40), the empty CBOR byte string. 2784 By default, key_length is the key length (in bytes) of the 2785 application AEAD Algorithm of the selected cipher suite for the EDHOC 2786 session. Also by default, salt_length has value 8. The Initiator 2787 and Responder MAY agree out-of-band on a longer key_length than the 2788 default and on a different salt_length. 2790 Master Secret = EDHOC-Exporter( "OSCORE Master Secret", , key_length ) 2791 Master Salt = EDHOC-Exporter( "OSCORE Master Salt", , salt_length ) 2793 * The AEAD Algorithm is the application AEAD algorithm of the 2794 selected cipher suite for the EDHOC session. 2796 * The HKDF Algorithm is the one based on the application hash 2797 algorithm of the selected cipher suite for the EDHOC session. For 2798 example, if SHA-256 is the application hash algorithm of the 2799 selected ciphersuite, HKDF SHA-256 is used as HKDF Algorithm in 2800 the OSCORE Security Context. 2802 * In case the Client is Initiator and the Server is Responder, the 2803 Client's OSCORE Sender ID and the Server's OSCORE Sender ID are 2804 determined from the EDHOC connection identifiers C_R and C_I for 2805 the EDHOC session, respectively, by applying the conversion in 2806 Appendix A.1. The reverse applies in case the Client is the 2807 Responder and the Server is the Initiator. 2809 Client and Server use the parameters above to establish an OSCORE 2810 Security Context, as per Section 3.2.1 of [RFC8613]. 2812 From then on, Client and Server retrieve the OSCORE protocol state 2813 using the Recipient ID, and optionally other transport information 2814 such as the 5-tuple. 2816 A.3. Transferring EDHOC over CoAP 2818 This section specifies one instance for how EDHOC can be transferred 2819 as an exchange of CoAP [RFC7252] messages. CoAP is a reliable 2820 transport that can preserve packet ordering and handle message 2821 duplication. CoAP can also perform fragmentation and protect against 2822 denial-of-service attacks. According to this specification, EDHOC 2823 messages are carried in Confirmable messages, which is beneficial 2824 especially if fragmentation is used. 2826 By default, the CoAP client is the Initiator and the CoAP server is 2827 the Responder, but the roles SHOULD be chosen to protect the most 2828 sensitive identity, see Section 7. According to this specification, 2829 EDHOC is transferred in POST requests and 2.04 (Changed) responses to 2830 the Uri-Path: "/.well-known/edhoc". An application may define its 2831 own path that can be discovered, e.g., using resource directory 2832 [I-D.ietf-core-resource-directory]. 2834 By default, the message flow is as follows: EDHOC message_1 is sent 2835 in the payload of a POST request from the client to the server's 2836 resource for EDHOC. EDHOC message_2 or the EDHOC error message is 2837 sent from the server to the client in the payload of a 2.04 (Changed) 2838 response. EDHOC message_3 or the EDHOC error message is sent from 2839 the client to the server's resource in the payload of a POST request. 2840 If needed, an EDHOC error message is sent from the server to the 2841 client in the payload of a 2.04 (Changed) response. Alternatively, 2842 if EDHOC message_4 is used, it is sent from the server to the client 2843 in the payload of a 2.04 (Changed) response analogously to message_2. 2845 In order to correlate a message received from a client to a message 2846 previously sent by the server, messages sent by the client are 2847 prepended with the CBOR serialization of the connection identifier 2848 which the server has chosen. This applies independently of if the 2849 CoAP server is Responder or Initiator. For the default case when the 2850 server is Responder, the prepended connection identifier is C_R, and 2851 C_I if the server is Initiator. If message_1 is sent to the server, 2852 the CBOR simple value "true" (0xf5) is sent in its place (given that 2853 the server has not selected C_R yet). 2855 These identifiers are encoded in CBOR and thus self-delimiting. They 2856 are sent in front of the actual EDHOC message, and only the part of 2857 the body following the identifier is used for EDHOC processing. 2859 Consequently, the application/edhoc media type does not apply to 2860 these messages; their media type is unnamed. 2862 An example of a successful EDHOC exchange using CoAP is shown in 2863 Figure 9. In this case the CoAP Token enables correlation on the 2864 Initiator side, and the prepended C_R enables correlation on the 2865 Responder (server) side. 2867 Client Server 2868 | | 2869 +--------->| Header: POST (Code=0.02) 2870 | POST | Uri-Path: "/.well-known/edhoc" 2871 | | Payload: true, EDHOC message_1 2872 | | 2873 |<---------+ Header: 2.04 Changed 2874 | 2.04 | Content-Format: application/edhoc 2875 | | Payload: EDHOC message_2 2876 | | 2877 +--------->| Header: POST (Code=0.02) 2878 | POST | Uri-Path: "/.well-known/edhoc" 2879 | | Payload: C_R, EDHOC message_3 2880 | | 2881 |<---------+ Header: 2.04 Changed 2882 | 2.04 | 2883 | | 2885 Figure 9: Transferring EDHOC in CoAP when the Initiator is CoAP 2886 Client 2888 The exchange in Figure 9 protects the client identity against active 2889 attackers and the server identity against passive attackers. 2891 An alternative exchange that protects the server identity against 2892 active attackers and the client identity against passive attackers is 2893 shown in Figure 10. In this case the CoAP Token enables the 2894 Responder to correlate message_2 and message_3, and the prepended C_I 2895 enables correlation on the Initiator (server) side. If EDHOC 2896 message_4 is used, C_I is prepended, and it is transported with CoAP 2897 in the payload of a POST request with a 2.04 (Changed) response. 2899 Client Server 2900 | | 2901 +--------->| Header: POST (Code=0.02) 2902 | POST | Uri-Path: "/.well-known/edhoc" 2903 | | 2904 |<---------+ Header: 2.04 Changed 2905 | 2.04 | Content-Format: application/edhoc 2906 | | Payload: EDHOC message_1 2907 | | 2908 +--------->| Header: POST (Code=0.02) 2909 | POST | Uri-Path: "/.well-known/edhoc" 2910 | | Payload: C_I, EDHOC message_2 2911 | | 2912 |<---------+ Header: 2.04 Changed 2913 | 2.04 | Content-Format: application/edhoc 2914 | | Payload: EDHOC message_3 2915 | | 2917 Figure 10: Transferring EDHOC in CoAP when the Initiator is CoAP 2918 Server 2920 To protect against denial-of-service attacks, the CoAP server MAY 2921 respond to the first POST request with a 4.01 (Unauthorized) 2922 containing an Echo option [I-D.ietf-core-echo-request-tag]. This 2923 forces the initiator to demonstrate its reachability at its apparent 2924 network address. If message fragmentation is needed, the EDHOC 2925 messages may be fragmented using the CoAP Block-Wise Transfer 2926 mechanism [RFC7959]. 2928 EDHOC does not restrict how error messages are transported with CoAP, 2929 as long as the appropriate error message can to be transported in 2930 response to a message that failed (see Section 6). EDHOC error 2931 messages transported with CoAP are carried in the payload. 2933 A.3.1. Transferring EDHOC and OSCORE over CoAP 2935 When using EDHOC over CoAP for establishing an OSCORE Security 2936 Context, EDHOC error messages sent as CoAP responses MUST be sent in 2937 the payload of error responses, i.e., they MUST specify a CoAP error 2938 response code. In particular, it is RECOMMENDED that such error 2939 responses have response code either 4.00 (Bad Request) in case of 2940 client error (e.g., due to a malformed EDHOC message), or 5.00 2941 (Internal Server Error) in case of server error (e.g., due to failure 2942 in deriving EDHOC key material). The Content-Format of the error 2943 response MUST be set to application/edhoc. 2945 A method for combining EDHOC and OSCORE protocols in two round-trips 2946 is specified in [I-D.ietf-core-oscore-edhoc]. 2948 Appendix B. Compact Representation 2950 As described in Section 4.2 of [RFC6090] the x-coordinate of an 2951 elliptic curve public key is a suitable representative for the entire 2952 point whenever scalar multiplication is used as a one-way function. 2953 One example is ECDH with compact output, where only the x-coordinate 2954 of the computed value is used as the shared secret. 2956 This section defines a format for compact representation based on the 2957 Elliptic-Curve-Point-to-Octet-String Conversion defined in 2958 Section 2.3.3 of [SECG]. Using the notation from [SECG], the output 2959 is an octet string of length ceil( (log2 q) / 8 ). See [SECG] for a 2960 definition of q, M, X, xp, and ~yp. The steps in Section 2.3.3 of 2961 [SECG] are replaced by: 2963 1. Convert the field element xp to an octet string X of length ceil( 2964 (log2 q) / 8 ) octets using the conversion routine specified in 2965 Section 2.3.5 of [SECG]. 2967 2. Output M = X 2969 The encoding of the point at infinity is not supported. Compact 2970 representation does not change any requirements on validation. If a 2971 y-coordinate is required for validation or compatibily with APIs the 2972 value ~yp SHALL be set to zero. For such use, the compact 2973 representation can be transformed into the SECG point compressed 2974 format by prepending it with the single byte 0x02 (i.e., M = 0x02 || 2975 X). 2977 Using compact representation have some security benefits. An 2978 implementation does not need to check that the point is not the point 2979 at infinity (the identity element). Similarly, as not even the sign 2980 of the y-coordinate is encoded, compact representation trivially 2981 avoids so called "benign malleability" attacks where an attacker 2982 changes the sign, see [SECG]. 2984 Appendix C. Use of CBOR, CDDL and COSE in EDHOC 2986 This Appendix is intended to simplify for implementors not familiar 2987 with CBOR [RFC8949], CDDL [RFC8610], COSE 2988 [I-D.ietf-cose-rfc8152bis-struct], and HKDF [RFC5869]. 2990 C.1. CBOR and CDDL 2992 The Concise Binary Object Representation (CBOR) [RFC8949] is a data 2993 format designed for small code size and small message size. CBOR 2994 builds on the JSON data model but extends it by e.g., encoding binary 2995 data directly without base64 conversion. In addition to the binary 2996 CBOR encoding, CBOR also has a diagnostic notation that is readable 2997 and editable by humans. The Concise Data Definition Language (CDDL) 2998 [RFC8610] provides a way to express structures for protocol messages 2999 and APIs that use CBOR. [RFC8610] also extends the diagnostic 3000 notation. 3002 CBOR data items are encoded to or decoded from byte strings using a 3003 type-length-value encoding scheme, where the three highest order bits 3004 of the initial byte contain information about the major type. CBOR 3005 supports several different types of data items, in addition to 3006 integers (int, uint), simple values, byte strings (bstr), and text 3007 strings (tstr), CBOR also supports arrays [] of data items, maps {} 3008 of pairs of data items, and sequences [RFC8742] of data items. Some 3009 examples are given below. 3011 For a complete specification and more examples, see [RFC8949] and 3012 [RFC8610]. We recommend implementors to get used to CBOR by using 3013 the CBOR playground [CborMe]. 3015 Diagnostic Encoded Type 3016 ------------------------------------------------------------------ 3017 1 0x01 unsigned integer 3018 24 0x1818 unsigned integer 3019 -24 0x37 negative integer 3020 -25 0x3818 negative integer 3021 true 0xf5 simple value 3022 h'12cd' 0x4212cd byte string 3023 '12cd' 0x4431326364 byte string 3024 "12cd" 0x6431326364 text string 3025 { 4 : h'cd' } 0xa10441cd map 3026 << 1, 2, true >> 0x430102f5 byte string 3027 [ 1, 2, true ] 0x830102f5 array 3028 ( 1, 2, true ) 0x0102f5 sequence 3029 1, 2, true 0x0102f5 sequence 3030 ------------------------------------------------------------------ 3032 C.2. CDDL Definitions 3034 This sections compiles the CDDL definitions for ease of reference. 3036 suite = int 3038 ead = 1* ( 3039 type : int, 3040 ext_authz_data : any, 3041 ) 3043 message_1 = ( 3044 METHOD : int, 3045 SUITES_I : [ selected : suite, supported : 2* suite ] / suite, 3046 G_X : bstr, 3047 C_I : bstr / int, 3048 ? EAD_1 : ead, 3049 ) 3051 message_2 = ( 3052 G_Y_CIPHERTEXT_2 : bstr, 3053 C_R : bstr / int, 3054 ) 3056 message_3 = ( 3057 CIPHERTEXT_3 : bstr, 3058 ) 3060 message_4 = ( 3061 CIPHERTEXT_4 : bstr, 3062 ) 3064 SUITES_R : [ supported : 2* suite ] / suite 3066 error = ( 3067 ERR_CODE : int, 3068 ERR_INFO : any, 3069 ) 3071 info = [ 3072 edhoc_aead_id : int / tstr, 3073 transcript_hash : bstr, 3074 label : tstr, 3075 * context : any, 3076 length : uint, 3077 ] 3079 C.3. COSE 3081 CBOR Object Signing and Encryption (COSE) 3082 [I-D.ietf-cose-rfc8152bis-struct] describes how to create and process 3083 signatures, message authentication codes, and encryption using CBOR. 3084 COSE builds on JOSE, but is adapted to allow more efficient 3085 processing in constrained devices. EDHOC makes use of COSE_Key, 3086 COSE_Encrypt0, and COSE_Sign1 objects in the message processing: 3088 * ECDH ephemeral public keys of type EC2 or OKP in message_1 and 3089 message_2 consist of the COSE_Key parameter named 'x', see 3090 Section 7.1 and 7.2 of [I-D.ietf-cose-rfc8152bis-algs] 3092 * Certain ciphertexts in message_2 and message_3 consist of a subset 3093 of the single recipient encrypted data object COSE_Encrypt0, which 3094 is described in Sections 5.2-5.3 of 3095 [I-D.ietf-cose-rfc8152bis-struct]. The ciphertext is computed 3096 over the plaintext and associated data, using an encryption key 3097 and a nonce. The associated data is an Enc_structure consisting 3098 of protected headers and externally supplied data (external_aad). 3100 * Signatures in message_2 of method 0 and 2, and in message_3 of 3101 method 0 and 1, consist of a subset of the single signer data 3102 object COSE_Sign1, which is described in Sections 4.2-4.4 of 3103 [I-D.ietf-cose-rfc8152bis-struct]. The signature is computed over 3104 a Sig_structure containing payload, protected headers and 3105 externally supplied data (external_aad) using a private signature 3106 key and verified using the corresponding public signature key. 3108 Appendix D. Test Vectors 3110 TBD 3112 Appendix E. Applicability Template 3114 This appendix contains a rudimentary example of an applicability 3115 statement, see Section 3.9. 3117 For use of EDHOC in the XX protocol, the following assumptions are 3118 made: 3120 1. Transfer in CoAP as specified in Appendix A.3 with requests 3121 expected by the CoAP server (= Responder) at /app1-edh, no 3122 Content-Format needed. 3124 2. METHOD = 1 (I uses signature key, R uses static DH key.) 3125 3. CRED_I is an IEEE 802.1AR IDevID encoded as a C509 certificate of 3126 type 0 [I-D.ietf-cose-cbor-encoded-cert]. 3128 * R acquires CRED_I out-of-band, indicated in EAD_1. 3130 * ID_CRED_I = {4: h''} is a 'kid' with value empty byte string. 3132 4. CRED_R is a UCCS of type OKP as specified in Section 3.5.2. 3134 * The CBOR map has parameters 1 (kty), -1 (crv), and -2 3135 (x-coordinate). 3137 * ID_CRED_R = CRED_R 3139 5. External authorization data is defined and processed as specified 3140 in [I-D.selander-ace-ake-authz]. 3142 6. EUI-64 used as identity of endpoint. 3144 7. No use of message_4: the application sends protected messages 3145 from R to I. 3147 Appendix F. EDHOC Message Deduplication 3149 EDHOC by default assumes that message duplication is handled by the 3150 transport, in this section exemplified with CoAP. 3152 Deduplication of CoAP messages is described in Section 4.5 of 3153 [RFC7252]. This handles the case when the same Confirmable (CON) 3154 message is received multiple times due to missing acknowledgement on 3155 CoAP messaging layer. The recommended processing in [RFC7252] is 3156 that the duplicate message is acknowledged (ACK), but the received 3157 message is only processed once by the CoAP stack. 3159 Message deduplication is resource demanding and therefore not 3160 supported in all CoAP implementations. Since EDHOC is targeting 3161 constrained environments, it is desirable that EDHOC can optionally 3162 support transport layers which does not handle message duplication. 3163 Special care is needed to avoid issues with duplicate messages, see 3164 Section 5.1. 3166 The guiding principle here is similar to the deduplication processing 3167 on CoAP messaging layer: a received duplicate EDHOC message SHALL NOT 3168 result in a response consisting of another instance of the next EDHOC 3169 message. The result MAY be that a duplicate EDHOC response is sent, 3170 provided it is still relevant with respect the current protocol 3171 state. In any case, the received message MUST NOT be processed more 3172 than once in the same EDHOC session. This is called "EDHOC message 3173 deduplication". 3175 An EDHOC implementation MAY store the previously sent EDHOC message 3176 to be able to resend it. An EDHOC implementation MAY keep the 3177 protocol state to be able to recreate the previously sent EDHOC 3178 message and resend it. The previous message or protocol state MUST 3179 NOT be kept longer than what is required for retransmission, for 3180 example, in the case of CoAP transport, no longer than the 3181 EXCHANGE_LIFETIME (see Section 4.8.2 of [RFC7252]). 3183 Note that the requirements in Section 5.1 still apply because 3184 duplicate messages are not processed by the EDHOC state machine: 3186 * EDHOC messages SHALL be processed according to the current 3187 protocol state. 3189 * Different instances of the same message MUST NOT be processed in 3190 one session. 3192 Appendix G. Transports Not Natively Providing Correlation 3194 Protocols that do not natively provide full correlation between a 3195 series of messages can send the C_I and C_R identifiers along as 3196 needed. 3198 The transport over CoAP (Appendix A.3) can serve as a blueprint for 3199 other server-client protocols: The client prepends the C_x which the 3200 server selected (or, for message 1, the CBOR simple value 'true' 3201 which is not a valid C_x) to any request message it sends. The 3202 server does not send any such indicator, as responses are matched to 3203 request by the client-server protocol design. 3205 Protocols that do not provide any correlation at all can prescribe 3206 prepending of the peer's chosen C_x to all messages. 3208 Appendix H. Change Log 3210 RFC Editor: Please remove this appendix. 3212 Main changes: 3214 * From -08 to -09: 3216 - G_Y and CIPHERTEXT_2 are now included in one CBOR bstr 3218 - MAC_2 and MAC_3 are now generated with EDHOC-KDF 3220 - Info field "context" is now general and explicit in EDHOC-KDF 3222 - Restructured Section 4, Key Derivation 3224 - Added EDHOC MAC length to cipher suite for use with static DH 3226 - More details on the use of CWT and UCCS 3228 - Restructured and clarified Section 3.5, Authentication 3229 Parameters 3231 - Replaced 'kid2' with extension of 'kid' 3233 - EAD encoding now supports multiple ead types in one message 3235 - Clarified EAD type 3237 - Updated message sizes 3239 - Replaced "perfect forward secrecy" with "forward secrecy" 3241 - Updated security considerations 3243 - Replaced prepended 'null' with 'true' in the CoAP transport of 3244 message_1 3246 - Updated CDDL definitions 3248 - Expanded on the use of COSE 3250 * From -07 to -08: 3252 - Prepended C_x moved from the EDHOC protocol itself to the 3253 transport mapping 3255 - METHOD_CORR renamed to METHOD, corr removed 3257 - Removed bstr_identifier and use bstr / int instead; C_x can now 3258 be int without any implied bstr semantics 3260 - Defined COSE header parameter 'kid2' with value type bstr / int 3261 for use with ID_CRED_x 3263 - Updated message sizes 3265 - New cipher suites with AES-GCM and ChaCha20 / Poly1305 3267 - Changed from one- to two-byte identifier of CNSA compliant 3268 suite 3270 - Separate sections on transport and connection id with further 3271 sub-structure 3273 - Moved back key derivation for OSCORE from draft-ietf-core- 3274 oscore-edhoc 3276 - OSCORE and CoAP specific processing moved to new appendix 3278 - Message 4 section moved to message processing section 3280 * From -06 to -07: 3282 - Changed transcript hash definition for TH_2 and TH_3 3284 - Removed "EDHOC signature algorithm curve" from cipher suite 3286 - New IANA registry "EDHOC Exporter Label" 3288 - New application defined parameter "context" in EDHOC-Exporter 3290 - Changed normative language for failure from MUST to SHOULD send 3291 error 3293 - Made error codes non-negative and 0 for success 3295 - Added detail on success error code 3297 - Aligned terminology "protocol instance" -> "session" 3299 - New appendix on compact EC point representation 3301 - Added detail on use of ephemeral public keys 3303 - Moved key derivation for OSCORE to draft-ietf-core-oscore-edhoc 3305 - Additional security considerations 3307 - Renamed "Auxililary Data" as "External Authorization Data" 3309 - Added encrypted EAD_4 to message_4 3311 * From -05 to -06: 3313 - New section 5.2 "Message Processing Outline" 3315 - Optional inital byte C_1 = null in message_1 3317 - New format of error messages, table of error codes, IANA 3318 registry 3320 - Change of recommendation transport of error in CoAP 3322 - Merge of content in 3.7 and appendix C into new section 3.7 3323 "Applicability Statement" 3325 - Requiring use of deterministic CBOR 3327 - New section on message deduplication 3329 - New appendix containin all CDDL definitions 3331 - New appendix with change log 3333 - Removed section "Other Documents Referencing EDHOC" 3335 - Clarifications based on review comments 3337 * From -04 to -05: 3339 - EDHOC-Rekey-FS -> EDHOC-KeyUpdate 3341 - Clarification of cipher suite negotiation 3343 - Updated security considerations 3345 - Updated test vectors 3347 - Updated applicability statement template 3349 * From -03 to -04: 3351 - Restructure of section 1 3353 - Added references to C509 Certificates 3355 - Change in CIPHERTEXT_2 -> plaintext XOR KEYSTREAM_2 (test 3356 vector not updated) 3358 - "K_2e", "IV_2e" -> KEYSTREAM_2 3359 - Specified optional message 4 3361 - EDHOC-Exporter-FS -> EDHOC-Rekey-FS 3363 - Less constrained devices SHOULD implement both suite 0 and 2 3365 - Clarification of error message 3367 - Added exporter interface test vector 3369 * From -02 to -03: 3371 - Rearrangements of section 3 and beginning of section 4 3373 - Key derivation new section 4 3375 - Cipher suites 4 and 5 added 3377 - EDHOC-EXPORTER-FS - generate a new PRK_4x3m from an old one 3379 - Change in CIPHERTEXT_2 -> COSE_Encrypt0 without tag (no change 3380 to test vector) 3382 - Clarification of error message 3384 - New appendix C applicability statement 3386 * From -01 to -02: 3388 - New section 1.2 Use of EDHOC 3390 - Clarification of identities 3392 - New section 4.3 clarifying bstr_identifier 3394 - Updated security considerations 3396 - Updated text on cipher suite negotiation and key confirmation 3398 - Test vector for static DH 3400 * From -00 to -01: 3402 - Removed PSK method 3404 - Removed references to certificate by value 3406 Acknowledgments 3408 The authors want to thank Christian Amsuess, Alessandro Bruni, 3409 Karthikeyan Bhargavan, Timothy Claeys, Martin Disch, Theis Groenbech 3410 Petersen, Dan Harkins, Klaus Hartke, Russ Housley, Stefan Hristozov, 3411 Alexandros Krontiris, Ilari Liusvaara, Karl Norrman, Salvador Perez, 3412 Eric Rescorla, Michael Richardson, Thorvald Sahl Joergensen, Jim 3413 Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav Smyshlyaev, 3414 Valery Smyslov, Peter van der Stok, Rene Struik, Vaishnavi 3415 Sundararajan, Erik Thormarker, Marco Tiloca, Michel Veillette, and 3416 Malisa Vucinic for reviewing and commenting on intermediate versions 3417 of the draft. We are especially indebted to Jim Schaad for his 3418 continuous reviewing and implementation of different versions of the 3419 draft. 3421 Work on this document has in part been supported by the H2020 project 3422 SIFIS-Home (grant agreement 952652). 3424 Authors' Addresses 3426 Göran Selander 3427 Ericsson AB 3428 SE-164 80 Stockholm 3429 Sweden 3431 Email: goran.selander@ericsson.com 3433 John Preuß Mattsson 3434 Ericsson AB 3435 SE-164 80 Stockholm 3436 Sweden 3438 Email: john.mattsson@ericsson.com 3440 Francesca Palombini 3441 Ericsson AB 3442 SE-164 80 Stockholm 3443 Sweden 3445 Email: francesca.palombini@ericsson.com