idnits 2.17.1 draft-selander-ace-cose-ecdhe-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (January 02, 2019) is 1941 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-cbor-7049bis-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-06 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-03 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 ** Downref: Normative reference to an Informational draft: draft-schaad-cose-x509 (ref. 'I-D.schaad-cose-x509') ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 6090 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIGMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP-800-56A' == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-dtsecurity-zerotouch-join-03 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-17 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-05 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-18 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-30 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group G. Selander 3 Internet-Draft J. Mattsson 4 Intended status: Standards Track F. Palombini 5 Expires: July 6, 2019 Ericsson AB 6 January 02, 2019 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-selander-ace-cose-ecdhe-11 11 Abstract 13 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 14 very compact, and lightweight authenticated Diffie-Hellman key 15 exchange with ephemeral keys that can be used over any layer. EDHOC 16 provides mutual authentication, perfect forward secrecy, and identity 17 protection. EDHOC uses CBOR and COSE, allowing reuse of existing 18 libraries. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 6, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Rationale for EDHOC . . . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology and Requirements Language . . . . . . . . . . 5 57 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 8 61 3.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 8 62 4. EDHOC Authenticated with Asymmetric Keys . . . . . . . . . . 10 63 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 11 65 4.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 13 66 4.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 16 67 5. EDHOC Authenticated with Symmetric Keys . . . . . . . . . . . 18 68 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 69 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 19 70 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 19 71 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 20 72 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 20 73 6.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 20 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 75 7.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 21 76 7.2. Media Types Registry . . . . . . . . . . . . . . . . . . 21 77 7.3. CoAP Content-Formats Registry . . . . . . . . . . . . . . 22 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 23 80 8.2. Cryptographic Considerations . . . . . . . . . . . . . . 23 81 8.3. Mandatory to Implement Cipher Suite . . . . . . . . . . . 24 82 8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 24 83 8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 24 84 8.6. Implementation Considerations . . . . . . . . . . . . . . 25 85 8.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 25 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 88 9.2. Informative References . . . . . . . . . . . . . . . . . 27 89 Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 29 90 A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 29 91 A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 31 92 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 33 93 Appendix C. EDHOC PSK Chaining . . . . . . . . . . . . . . . . . 33 94 Appendix D. EDHOC with CoAP and OSCORE . . . . . . . . . . . . . 34 95 D.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 34 96 D.2. Deriving an OSCORE context from EDHOC . . . . . . . . . . 35 98 Appendix E. Message Sizes . . . . . . . . . . . . . . . . . . . 35 99 E.1. Message Sizes RPK . . . . . . . . . . . . . . . . . . . . 35 100 E.2. Message Sizes Certificates . . . . . . . . . . . . . . . 37 101 E.3. Message Sizes PSK . . . . . . . . . . . . . . . . . . . . 37 102 E.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 38 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 106 1. Introduction 108 Security at the application layer provides an attractive option for 109 protecting Internet of Things (IoT) deployments, for example where 110 transport layer security is not sufficient 111 [I-D.hartke-core-e2e-security-reqs] or where the protocol needs to 112 work on a variety of underlying protocols. IoT devices may be 113 constrained in various ways, including memory, storage, processing 114 capacity, and energy [RFC7228]. A method for protecting individual 115 messages at the application layer suitable for constrained devices, 116 is provided by CBOR Object Signing and Encryption (COSE) [RFC8152]), 117 which builds on the Concise Binary Object Representation (CBOR) 118 [I-D.ietf-cbor-7049bis]. 120 In order for a communication session to provide forward secrecy, the 121 communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH) 122 key exchange protocol with ephemeral keys, from which shared key 123 material can be derived. This document specifies Ephemeral Diffie- 124 Hellman Over COSE (EDHOC), a lightweight key exchange protocol 125 providing perfect forward secrecy and identity protection. EDHOC 126 uses CBOR and COSE, allowing reuse of existing libraries. 127 Authentication is based on credentials established out of band, e.g. 128 from a trusted third party, such as an Authorization Server as 129 specified by [I-D.ietf-ace-oauth-authz]. EDHOC supports 130 authentication using pre-shared keys (PSK), raw public keys (RPK), 131 and public key certificates. After successful completion of the 132 EDHOC protocol, application keys and other application specific data 133 can be derived using the EDHOC-Exporter interface. Note that this 134 document focuses on authentication and key establishment: for 135 integration with authorization of resource access, refer to 136 [I-D.ietf-ace-oscore-profile]. 138 EDHOC is designed to work in highly constrained scenarios making it 139 especially suitable for network technologies such as Cellular IoT, 140 6TiSCH [I-D.ietf-6tisch-dtsecurity-zerotouch-join], and LoRaWAN 141 [LoRa1][LoRa2]. Compared to the DTLS 1.3 handshake 142 [I-D.ietf-tls-dtls13] with ECDH and connection ID, the number of 143 bytes in EDHOC is less than 1/4 when PSK authentication is used and 144 less than 1/3 when RPK authentication is used, see Appendix E. 146 The ECDH exchange and the key derivation follow [SIGMA], NIST SP- 147 800-56A [SP-800-56A], and HKDF [RFC5869]. CBOR 148 [I-D.ietf-cbor-7049bis] and COSE [RFC8152] are used to implement 149 these standards. 151 This document is organized as follows: Section 2 describes how EDHOC 152 builds on SIGMA-I, Section 3 specifies general properties of EDHOC, 153 including message flow, formatting of the ephemeral public keys, and 154 key derivation, Section 4 specifies EDHOC with asymmetric key 155 authentication, Section 5 specifies EDHOC with symmetric key 156 authentication, Section 6 specifies the EDHOC error message, and 157 Appendix B provides a wealth of test vectors to ease implementation 158 and ensure interoperability. 160 1.1. Rationale for EDHOC 162 EDHOC is optimized for small message overhead. The message size of a 163 key exchange protocol may have a large impact on the performance of 164 an IoT deployment. For example, in a network bootstrapping setting a 165 large number of devices turned on in a short period of time may 166 result in large latencies caused by parallel key exchanges. 167 Requirements on network formation time can in constrained 168 environments be translated into key exchange overhead. 170 Power consumption for wireless devices is highly dependent on message 171 transmission and reception. For devices that only send a few bytes 172 occasionally, the battery lifetime may be significantly reduced by a 173 heavy key exchange protocol. Moreover, a key exchange may need to be 174 executed more than once, e.g. due to a device losing power or 175 rebooting for other reason. 177 EDHOC is adapted to primitives and protocols designed for the 178 Internet of Things: EDHOC is built on CBOR and COSE which enables 179 small message overhead and efficient parsing in constrained devices. 180 Since EDHOC is not bound to a particular transport layer, the 181 protocol messages can e.g. be carried as CoAP payload. By reusing 182 already existing IoT primitives in the device (CBOR, CoAP and COSE 183 encryption and signature formats) the additional code footprint can 184 be kept very low. 186 EDHOC is not bound to a particular communication security protocol 187 but works off-the-shelf with OSCORE [I-D.ietf-core-object-security] 188 providing the necessary input parameters with required properties. 189 Since EDHOC builds on the same IoT primitives and protocols as OSCORE 190 (CBOR, COAP, COSE encryption and signature formats) the device 191 footprint for EDHOC + OSCORE can be kept very low. The use of 192 compact native encoding formats reduces the need for a general 193 purpose compression algorithm with associated footprint. 195 1.2. Terminology and Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 The word "encryption" without qualification always refers to 204 authenticated encryption, in practice implemented with an 205 Authenticated Encryption with Additional Data (AEAD) algorithm, see 206 [RFC5116]. 208 This document uses the Concise Data Definition Language (CDDL) 209 [I-D.ietf-cbor-cddl] to express CBOR data structures 210 [I-D.ietf-cbor-7049bis]. The use of the CDDL unwrap operator "~" is 211 extended to unwrapping of byte strings. It is the inverse of "bstr 212 .cbor" that wraps a data item in a bstr, i.e. ~ bstr .cbor T = T. 213 Examples of CBOR and CDDL are provided in Appendix A.1. 215 2. Background 217 SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a 218 large number of variants [SIGMA]. Like IKEv2 and (D)TLS 1.3, EDHOC 219 is built on a variant of the SIGMA protocol which provide identity 220 protection of the initiator (SIGMA-I), and like (D)TLS 1.3, EDHOC 221 implements the SIGMA-I variant as Sign-then-MAC. The SIGMA-I 222 protocol using an authenticated encryption algorithm is shown in 223 Figure 1. 225 Party U Party V 226 | X_U | 227 +------------------------------------------------------>| 228 | | 229 | X_V, AE( K_2; ID_CRED_V, Sig(V; CRED_V, X_U, X_V) ) | 230 |<------------------------------------------------------+ 231 | | 232 | AE( K_3; ID_CRED_U, Sig(U; CRED_U, X_V, X_U) ) | 233 +------------------------------------------------------>| 234 | | 236 Figure 1: Authenticated encryption variant of the SIGMA-I protocol. 238 The parties exchanging messages are called "U" and "V". They 239 exchange identities and ephemeral public keys, compute the shared 240 secret, and derive symmetric application keys. 242 o X_U and X_V are the ECDH ephemeral public keys of U and V, 243 respectively. 245 o CRED_U and CRED_V are the credentials containing the public 246 authentication keys of U and V, respectively. 248 o ID_CRED_U and ID_CRED_V are data enabling the recipient party to 249 retrieve the credential of U and V, respectively 251 o Sig(U; . ) and S(V; . ) denote signatures made with the private 252 authentication key of U and V, respectively. 254 o AE(K; P) denotes authenticated encryption of plaintext P using the 255 key K derived from the shared secret. The authenticated 256 encryption MUST NOT be replaced by plain encryption, see 257 Section 8. 259 In order to create a "full-fledged" protocol some additional protocol 260 elements are needed. EDHOC adds: 262 o Explicit connection identifiers C_U, C_V chosen by U and V, 263 respectively, enabling the recipient to find the protocol state. 265 o An Authenticated Encryption with Additional Data (AEAD) algorithm 266 is used. 268 o Computationally independent keys derived from the ECDH shared 269 secret and used for encryption of different messages. 271 o Verification of a common preferred cipher suite (AEAD algorithm, 272 ECDH algorithm, ECDH curve, signature algorithm): 274 * U lists supported cipher suites in order of preference 276 * V verifies that the selected cipher suite is the first 277 supported cipher suite 279 o Message types and error handling. 281 o Transport of opaque application defined data. 283 EDHOC is designed to encrypt and integrity protect as much 284 information as possible, and all symmetric keys are derived using as 285 much previous information as possible. EDHOC is furthermore designed 286 to be as compact and lightweight as possible, in terms of message 287 sizes, processing, and the ability to reuse already existing CBOR and 288 COSE libraries. EDHOC does not put any requirement on the lower 289 layers and can therefore also be used e.g. in environments without 290 IP. 292 To simplify implementation, the use of CBOR and COSE in EDHOC is 293 summarized in Appendix A. 295 3. EDHOC Overview 297 EDHOC consists of three messages (message_1, message_2, message_3) 298 that maps directly to the three messages in SIGMA-I, plus an EDHOC 299 error message. All EDHOC messages consists of a sequence of CBOR 300 encoded data items, where the first data item of message_1 is an int 301 specifying the message type (MSG_TYPE). The messages may be viewed 302 as a CBOR encoding of an indefinite-length array without the first 303 and last byte, see Appendix A.1. 305 While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 306 structures, only a subset of the parameters are included in the EDHOC 307 messages. After creating EDHOC message_3, Party U can derive 308 symmetric application keys, and application protected data can 309 therefore be sent in parallel with EDHOC message_3. The application 310 may protect data using the algorithms (AEAD, HKDF, etc.) in the 311 selected cipher suite and the connection identifiers (C_U, C_V). 312 EDHOC may be used with the media type application/edhoc defined in 313 Section 7. 315 Party U Party V 316 | | 317 | ------------------ EDHOC message_1 -----------------> | 318 | | 319 | <----------------- EDHOC message_2 ------------------ | 320 | | 321 | ------------------ EDHOC message_3 -----------------> | 322 | | 323 | <----------- Application Protected Data ------------> | 324 | | 326 Figure 2: EDHOC message flow 328 The EDHOC message exchange may be authenticated using pre-shared keys 329 (PSK), raw public keys (RPK), or public key certificates. EDHOC 330 assumes the existence of mechanisms (certification authority, manual 331 distribution, etc.) for binding identities with authentication keys 332 (public or pre-shared). When a public key infrastructure is used, 333 the identity is included in the certificate and bound to the 334 authentication key by trust in the certification authority. When the 335 credential is manually distributed (PSK, RPK, self-signed 336 certificate), the identity and authentication key is distributed out- 337 of-band and bound together by trust in the distribution method. 338 EDHOC with symmetric key authentication is very similar to EDHOC with 339 asymmetric key authentication, the difference being that information 340 is only MACed, not signed. 342 EDHOC allows opaque application data (UAD and PAD) to be sent in the 343 EDHOC messages. Unprotected Application Data (UAD_1, UAD_2) may be 344 sent in message_1 and message_2, while Protected Application Data 345 (PAD_3) may be send in message_3. 347 3.1. Cipher Suites 349 EDHOC cipher suites consists of a set of COSE algorithms: an AEAD 350 algorithm, an ECDH algorithm, an ECDH curve (including HKDF 351 algorithm), and a signature algorithm. The signature algorithm is 352 not used when EDHOC is authenticated with symmetric keys. Each 353 cipher suite is associated with an integer value. 355 1. AES-CCM-64-64-128, ECDH-SS + HKDF-256, X25519, and Ed25519 357 2. AES-CCM-64-64-128, ECDH-SS + HKDF-256, P-256, and ES256 359 3. Application defined. 361 4. Application defined. 363 3.2. Ephemeral Public Keys 365 The ECDH ephemeral public keys are formatted as a COSE_Key of type 366 EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only 367 a subset of the parameters are included in the EDHOC messages. For 368 Elliptic Curve Keys of type EC2, compact representation as per 369 [RFC6090] MAY be used also in the COSE_Key. If the COSE 370 implementation requires an y-coordinate, any of the possible values 371 of the y-coordinate can be used, see Appendix C of [RFC6090]. COSE 372 [RFC8152] always use compact output for Elliptic Curve Keys of type 373 EC2. 375 3.3. Key Derivation 377 Key and IV derivation SHALL be performed as specified in Section 11 378 of [RFC8152] with the following input: 380 o The KDF SHALL be the HKDF [RFC5869] in the in the selected cipher 381 suite (CIPHER_SUITE_U). 383 o The secret (Section 11.1 of [RFC8152]) SHALL be the ECDH shared 384 secret as defined in Section 12.4.1 of [RFC8152]. 386 o The salt (Section 11.1 of [RFC8152]) SHALL be the PSK when EDHOC 387 is authenticated with symmetric keys, and the empty byte string 388 when EDHOC is authenticated with asymmetric keys. Note that 389 [RFC5869] specifies that if the salt is not provided, it is set to 390 a string of zeros (see Section 2.2 of [RFC5869]). For 391 implementation purposes, not providing the salt is the same as 392 setting the salt to the empty byte string. 394 o The fields in the context information COSE_KDF_Context 395 (Section 11.2 of [RFC8152]) SHALL have the following values: 397 * AlgorithmID is an int or tstr, see below 399 * PartyUInfo = PartyVInfo = ( null, null, null ) 401 * keyDataLength is a uint, see below 403 * protected SHALL be a zero length bstr 405 * other is a bstr and SHALL be aad_2, aad_3, or exchange_hash; 406 see below 408 * SuppPrivInfo is omitted 410 where exchange_hash, in non-CDDL notation, is: 412 exchange_hash = H( bstr .cborseq [ aad_3, CIPHERTEXT_3 ] ) 414 where H() is the hash function in the HKDF, which takes a CBOR byte 415 string (bstr) as input and produces a CBOR byte string as output. 416 The use of '.cborseq' is exemplified in Appendix A.1. 418 We define EDHOC-Key-Derivation to be the function which produces the 419 output as described in [RFC5869] and [RFC8152] depending on the 420 variable input AlgorithmID, keyDataLength, and other: 422 output = EDHOC-Key-Derivation(AlgorithmID, keyDataLength, other) 424 For message_i the key, called K_i, SHALL be derived using other = 425 aad_i, where i = 2 or 3. The key SHALL be derived using AlgorithmID 426 set to the integer value of the AEAD in the selected cipher suite 427 (CIPHER_SUITE_U), and keyDataLength equal to the key length of the 428 AEAD. 430 If the AEAD algorithm uses an IV, then IV_i for message_i SHALL be 431 derived using other = aad_i, where i = 2 or 3. The IV SHALL be 432 derived using AlgorithmID = "IV-GENERATION" as specified in 433 Section 12.1.2. of [RFC8152], and keyDataLength equal to the IV 434 length of the AEAD. 436 3.3.1. EDHOC-Exporter Interface 438 Application keys and other application specific data can be derived 439 using the EDHOC-Exporter interface defined as: 441 EDHOC-Exporter(label, length) = EDHOC-Key-Derivation(label, 8 * 442 length, exchange_hash) 444 The output of the EDHOC-Exporter function SHALL be derived using 445 other = exchange_hash, AlgorithmID = label, and keyDataLength = 8 * 446 length, where label is a tstr defined by the application and length 447 is a uint defined by the application. The label SHALL be different 448 for each different exporter value. An example use of the EDHOC- 449 Exporter is given in Appendix D.2). 451 4. EDHOC Authenticated with Asymmetric Keys 453 4.1. Overview 455 EDHOC supports authentication with raw public keys (RPK) and public 456 key certificates with the requirements that: 458 o Party U SHALL be able to retrieve Party V's public authentication 459 key using ID_CRED_V, 461 o Party V SHALL be able to retrieve Party U's public authentication 462 key using ID_CRED_U, 464 where ID_CRED_x, for x = U or V, is encoded in a COSE map, see 465 Appendix A.2. In the following we give some examples of possible 466 COSE map labels. 468 Raw public keys are most optimally stored as COSE_Key objects and 469 identified with a 'kid' value (see [RFC8152]): 471 o kid : ID_CRED_x, for x = U or V. 473 Public key certificates can be identified in different ways, for 474 example (see [I-D.schaad-cose-x509]): 476 o by a hash value; 478 * x5t : ID_CRED_x, for x = U or V, 480 o by a URL; 481 * x5u : ID_CRED_x, for x = U or V, 483 o by a certificate chain; 485 * x5chain : ID_CRED_x, for x = U or V, 487 o or by a bag of certificates. 489 * x5bag : ID_CRED_x, for x = U or V. 491 In the latter two examples, ID_CRED_U and ID_CRED_V contains the 492 actual credential used for authentication. ID_CRED_U and ID_CRED_V 493 do not need to uniquely identify the public authentication key, but 494 doing so is recommended as the recipient may otherwise have to try 495 several public keys. ID_CRED_U and ID_CRED_V are transported in the 496 ciphertext, see Section 4.3.2 and Section 4.4.2. 498 The actual credentials CRED_U and CRED_V (e.g. a COSE_Key or a single 499 X.509 certificate) are signed by party U and V, respectively, see 500 Section 4.4.1 and Section 4.3.1. Party U and Party V MAY use 501 different type of credentials, e.g. one uses RPK and the other uses 502 certificate. Party U and Party V MAY use different signature 503 algorithms. 505 EDHOC with asymmetric key authentication is illustrated in Figure 3. 507 Party U Party V 508 | C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U, UAD_1 | 509 +------------------------------------------------------------------>| 510 | message_1 | 511 | | 512 | C_U, C_V, X_V, AE(K_2; ID_CRED_V, Sig(V; CRED_V, aad_2), UAD_2) | 513 |<------------------------------------------------------------------+ 514 | message_2 | 515 | | 516 | C_V, AE(K_3; ID_CRED_U, Sig(U; CRED_U, aad_3), PAD_3) | 517 +------------------------------------------------------------------>| 518 | message_3 | 520 Figure 3: Overview of EDHOC with asymmetric key authentication. 522 4.2. EDHOC Message 1 524 4.2.1. Formatting of Message 1 526 message_1 SHALL be a sequence of CBOR data items (see Appendix A.1) 527 as defined below 528 message_1 = ( 529 MSG_TYPE : int, 530 C_U : bstr, 531 CIPHER_SUITEs_U : suites, 532 CIPHER_SUITE_U : uint, 533 X_U : bstr, 534 ? UAD_1 : bstr, 535 ) 537 suites : int / [ 2* int ] 539 where: 541 o MSG_TYPE = 1 543 o C_U - variable length connection identifier 545 o CIPHER_SUITEs_U - cipher suites which Party U supports, in order 546 of decreasing preference. If a single cipher suite is conveyed, 547 an int is used, if multiple cipher suites are conveyed, an array 548 of ints is used. 550 o CIPHER_SUITE_U - a single chosen cipher suite from CIPHER_SUITEs_U 551 (zero-based index, i.e. 0 for the first or only, 1 for the second, 552 etc.) 554 o X_U - the x-coordinate of the ephemeral public key of Party U 556 o UAD_1 - bstr containing unprotected opaque application data 558 4.2.2. Party U Processing of Message 1 560 Party U SHALL compose message_1 as follows: 562 o The supported cipher suites and the order of preference MUST NOT 563 be changed based on previous error messages. However, the list 564 CIPHER_SUITEs_U sent to Party V MAY be truncated such that cipher 565 suites which are the least preferred are omitted. The amount of 566 truncation MAY be changed between sessions, e.g. based on previous 567 error messages (see next bullet), but all cipher suites which are 568 more preferred than the least preferred cipher suite in the list 569 MUST be included in the list. 571 o Determine the cipher suite CIPHER_SUITE_U to use with Party V in 572 message_1. If Party U previously received from Party V an error 573 message to message_1 with diagnostic payload identifying a cipher 574 suite that U supports, then U SHALL use that cipher suite. 575 Otherwise the first cipher suite in CIPHER_SUITEs_U MUST be used. 577 o Generate an ephemeral ECDH key pair as specified in Section 5 of 578 [SP-800-56A] using the curve in the cipher suite CIPHER_SUITE_U. 579 Let X_U be the x-coordinate of the ephemeral public key. 581 o Choose a connection identifier C_U and store it for the length of 582 the protocol. Party U MUST be able to retrieve the protocol state 583 using the connection identifier C_U and optionally other 584 information such as the 5-tuple. The connection identifier MAY be 585 used with protocols for which EDHOC establishes application keys, 586 in which case C_U SHALL be different from the concurrently used 587 identifiers of that protocol. 589 o Format message_1 as the sequence of CBOR data items specified in 590 Section 4.2.1 and encode it to a byte string (see Appendix A.1). 592 4.2.3. Party V Processing of Message 1 594 Party V SHALL process message_1 as follows: 596 o Decode message_1 (see Appendix A.1). 598 o Verify that the cipher suite CIPHER_SUITE_U is supported and that 599 no prior cipher suites in CIPHER_SUITEs_U are supported. 601 o Validate that there is a solution to the curve definition for the 602 given x-coordinate X_U. 604 o Pass UAD_1 to the application. 606 If any verification step fails, Party V MUST send an EDHOC error 607 message back, formatted as defined in Section 6, and the protocol 608 MUST be discontinued. If V does not support the cipher suite 609 CIPHER_SUITE_U, then CIPHER_SUITEs_V MUST include one or more 610 supported cipher suites. If V does not support the cipher suite 611 CIPHER_SUITE_U, but supports another cipher suite in CIPHER_SUITEs_U, 612 then CIPHER_SUITEs_V MUST include the first supported cipher suite in 613 CIPHER_SUITEs_U. 615 4.3. EDHOC Message 2 617 4.3.1. Formatting of Message 2 619 message_2 SHALL be a sequence of CBOR data items (see Appendix A.1) 620 as defined below 621 message_2 = ( 622 data_2, 623 CIPHERTEXT_2 : bstr, 624 ) 626 data_2 = ( 627 C_U : bstr / nil, 628 C_V : bstr, 629 X_V : bstr, 630 ) 632 aad_2 : bstr 634 where aad_2, in non-CDDL notation, is: 636 aad_2 = H( bstr .cborseq [ message_1, data_2 ] ) 638 where: 640 o C_V - variable length connection identifier 642 o X_V - the x-coordinate of the ephemeral public key of Party V 644 o H() - the hash function in the HKDF, which takes a CBOR byte 645 string (bstr) as input and produces a CBOR byte string as output. 646 The use of '.cborseq' is exemplified in Appendix A.1. 648 4.3.2. Party V Processing of Message 2 650 Party V SHALL compose message_2 as follows: 652 o Generate an ephemeral ECDH key pair as specified in Section 5 of 653 [SP-800-56A] using the curve in the cipher suite CIPHER_SUITE_U. 654 Let X_V be the x-coordinate of the ephemeral public key. 656 o Choose a connection identifier C_V and store it for the length of 657 the protocol. Party V MUST be able to retrieve the protocol state 658 using the connection identifier C_V and optionally other 659 information such as the 5-tuple. The connection identifier MAY be 660 used with protocols for which EDHOC establishes application keys, 661 in which case C_V SHALL be different from the concurrently used 662 identifiers of that protocol. To reduce message overhead, party V 663 can set the message field C_U in message_2 to null (still storing 664 the actual value of C_U) if there is an external correlation 665 mechanism (e.g. the Token in CoAP) that enables Party U to 666 correlate message_1 and message_2. 668 o Compute COSE_Sign1 as defined in Section 4.4 of [RFC8152], using 669 the signature algorithm in the cipher suite CIPHER_SUITE_U, the 670 private authentication key of Party V, and the following 671 parameters (further clarifications in Appendix A.2.2). The 672 unprotected header MAY contain parameters (e.g. 'alg'). 674 * protected = bstr .cbor { abc : ID_CRED_V } 676 * payload = CRED_V 678 * external_aad = aad_2 680 * abc - any COSE map label that can identify a public 681 authentication key, see Section 4.1 683 * ID_CRED_V - bstr enabling the retrieval of the public 684 authentication key of Party V, see Section 4.1 686 * CRED_V - bstr credential containing the public authentication 687 key of Party V, see Section 4.1 689 Note that only 'protected' and 'signature' of the COSE_Sign1 690 object are used in message_2, see next bullet. 692 o Compute COSE_Encrypt0 as defined in Section 5.3 of [RFC8152], with 693 the AEAD algorithm in the cipher suite CIPHER_SUITE_U, K_2, IV_2, 694 and the following parameters (further clarifications in 695 Appendix A.2.2). The protected header SHALL be empty. The 696 unprotected header MAY contain parameters (e.g. 'alg'). 698 * plaintext = bstr .cborseq [ ~protected, signature, ? UAD_2 ] 700 * external_aad = aad_2 702 * UAD_2 = bstr containing opaque unprotected application data 704 Note that protected and signature in the plaintext are taken from 705 the COSE_Sign1 object, and that that only 'ciphertext' of the 706 COSE_Encrypt0 object are used in message_2, see next bullet. 708 o Format message_2 as the sequence of CBOR data items specified in 709 Section 4.3.1 and encode it to a byte string (see Appendix A.1). 710 CIPHERTEXT_2 is the COSE_Encrypt0 ciphertext. 712 4.3.3. Party U Processing of Message 2 714 Party U SHALL process message_2 as follows: 716 o Decode message_2 (see Appendix A.1). 718 o Retrieve the protocol state using the connection identifier C_U 719 and optionally other information such as the 5-tuple. 721 o Validate that there is a solution to the curve definition for the 722 given x-coordinate X_V. 724 o Decrypt and verify COSE_Encrypt0 as defined in Section 5.3 of 725 [RFC8152], with the AEAD algorithm in the cipher suite 726 CIPHER_SUITE_U, K_2, and IV_2. 728 o Verify COSE_Sign1 as defined in Section 4.4 of [RFC8152], using 729 the signature algorithm in the cipher suite CIPHER_SUITE_U and the 730 public authentication key of Party V. 732 If any verification step fails, Party U MUST send an EDHOC error 733 message back, formatted as defined in Section 6, and the protocol 734 MUST be discontinued. 736 4.4. EDHOC Message 3 738 4.4.1. Formatting of Message 3 740 message_3 SHALL be a sequence of CBOR data items (see Appendix A.1) 741 as defined below 743 message_3 = ( 744 data_3, 745 CIPHERTEXT_3 : bstr, 746 ) 748 data_3 = ( 749 C_V : bstr, 750 ) 752 aad_3 : bstr 754 where aad_3, in non-CDDL notation, is: 756 aad_3 = H( bstr .cborseq [ aad_2, CIPHERTEXT_2, data_3 ] ) 758 4.4.2. Party U Processing of Message 3 760 Party U SHALL compose message_3 as follows: 762 o Compute COSE_Sign1 as defined in Section 4.4 of [RFC8152], using 763 the signature algorithm in the cipher suite CIPHER_SUITE_U, the 764 private authentication key of Party U, and the following 765 parameters. The unprotected header MAY contain parameters (e.g. 766 'alg'). 768 * protected = bstr .cbor { abc : ID_CRED_U } 770 * payload = CRED_U 772 * external_aad = aad_3 774 * abc - any COSE map label that can identify a public 775 authentication key, see Section 4.1 777 * ID_CRED_U - bstr enabling the retrieval of the public 778 authentication key of Party U, see Section 4.1 780 * CRED_U - bstr credential containing the public authentication 781 key of Party U, see Section 4.1 783 Note that only 'protected' and 'signature' of the COSE_Sign1 784 object are used in message_3, see next bullet. 786 o Compute COSE_Encrypt0 as defined in Section 5.3 of [RFC8152], with 787 the AEAD algorithm in the cipher suite CIPHER_SUITE_U, K_3, and 788 IV_3 and the following parameters. The protected header SHALL be 789 empty. The unprotected header MAY contain parameters (e.g. 790 'alg'). 792 * plaintext = bstr .cborseq [ ~protected, signature, ? PAD_3 ] 794 * external_aad = aad_2 796 * PAD_3 = bstr containing opaque protected application data 798 Note that protected and signature in the plaintext are taken from 799 the COSE_Sign1 object, and that only 'ciphertext' of the 800 COSE_Encrypt0 object are used in message_3, see next bullet. 802 o Format message_3 as the sequence of CBOR data items specified in 803 Section 4.4.1 and encode it to a byte string (see Appendix A.1). 804 CIPHERTEXT_3 is the COSE_Encrypt0 ciphertext. 806 o Pass the connection identifiers (C_U, C_V) and the negotiated 807 cipher suite CIPHER_SUITE_U to the application. The application 808 can now derive application keys using the EDHOC-Exporter 809 interface. 811 4.4.3. Party V Processing of Message 3 813 Party V SHALL process message_3 as follows: 815 o Decode message_3 (see Appendix A.1). 817 o Retrieve the protocol state using the connection identifier C_V 818 and optionally other information such as the 5-tuple. 820 o Decrypt and verify COSE_Encrypt0 as defined in Section 5.3 of 821 [RFC8152], with the AEAD algorithm in the cipher suite 822 CIPHER_SUITE_U, K_3, and IV_3. 824 o Verify COSE_Sign1 as defined in Section 4.4 of [RFC8152], using 825 the signature algorithm in the cipher suite CIPHER_SUITE_U and the 826 public authentication key of Party U. 828 If any verification step fails, Party V MUST send an EDHOC error 829 message back, formatted as defined in Section 6, and the protocol 830 MUST be discontinued. 832 o Pass PAD_3, the connection identifiers (C_U, C_V), and the 833 negotiated cipher suite CIPHER_SUITE_U to the application. The 834 application can now derive application keys using the EDHOC- 835 Exporter interface. 837 5. EDHOC Authenticated with Symmetric Keys 839 5.1. Overview 841 EDHOC supports authentication with pre-shared keys. Party U and V 842 are assumed to have a pre-shared key (PSK) with a good amount of 843 randomness and the requirement that: 845 o Party V SHALL be able to retrieve the PSK using KID. 847 KID may optionally contain information about how to retrieve the PSK. 848 KID does not need to uniquely identify the PSK, but doing so is 849 recommended as the recipient may otherwise have to try several PSKs. 851 EDHOC with symmetric key authentication is illustrated in Figure 4. 853 Party U Party V 854 | C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U, KID, UAD_1 | 855 +------------------------------------------------------------------>| 856 | message_1 | 857 | | 858 | C_U, C_V, X_V, AE(K_2; UAD_2) | 859 |<------------------------------------------------------------------+ 860 | message_2 | 861 | | 862 | C_V, AE(K_3; PAD_3) | 863 +------------------------------------------------------------------>| 864 | message_3 | 866 Figure 4: Overview of EDHOC with symmetric key authentication. 868 EDHOC with symmetric key authentication is very similar to EDHOC with 869 asymmetric key authentication. In the following subsections the 870 differences compared to EDHOC with asymmetric key authentication are 871 described. 873 5.2. EDHOC Message 1 875 5.2.1. Formatting of Message 1 877 message_1 SHALL be a sequence of CBOR data items (see Appendix A.1) 878 as defined below 880 message_1 = ( 881 MSG_TYPE : int, 882 C_U : bstr, 883 CIPHER_SUITEs_U : suites, 884 CIPHER_SUITE_U : uint, 885 X_U : bstr, 886 KID : bstr, 887 ? UAD_1 : bstr, 888 ) 890 where: 892 o MSG_TYPE = 2 894 o KID - bstr enabling the retrieval of the pre-shared key 896 5.3. EDHOC Message 2 897 5.3.1. Processing of Message 2 899 o COSE_Sign1 is not used. 901 o COSE_Encrypt0 is computed as defined in Section 5.3 of [RFC8152], 902 with the AEAD algorithm in the cipher suite CIPHER_SUITE_U, K_2, 903 IV_2, and the following parameters. The protected header SHALL be 904 empty. The unprotected header MAY contain parameters (e.g. 905 'alg'). 907 * external_aad = aad_2 909 * plaintext = h'' / UAD_2 911 * UAD_2 = bstr containing opaque unprotected application data 913 5.4. EDHOC Message 3 915 5.4.1. Processing of Message 3 917 o COSE_Sign1 is not used. 919 o COSE_Encrypt0 is computed as defined in Section 5.3 of [RFC8152], 920 with the AEAD algorithm in the cipher suite CIPHER_SUITE_U, K_3, 921 IV_3, and the following parameters. The protected header SHALL be 922 empty. The unprotected header MAY contain parameters (e.g. 923 'alg'). 925 * external_aad = aad_3 927 * plaintext = h'' / PAD_3 929 * PAD_3 = bstr containing opaque protected application data 931 6. Error Handling 933 6.1. EDHOC Error Message 935 This section defines a message format for the EDHOC error message, 936 used during the protocol. An EDHOC error message can be send by both 937 parties as a response to any non-error EDHOC message. After sending 938 an error message, the protocol MUST be discontinued. Errors at the 939 EDHOC layer are sent as normal successful messages in the lower 940 layers (e.g. CoAP POST and 2.04 Changed). An advantage of using 941 such a construction is to avoid issues created by usage of cross 942 protocol proxies (e.g. UDP to TCP). 944 error SHALL be a sequence of CBOR data items (see Appendix A.1) as 945 defined below 947 error = ( 948 MSG_TYPE : int, 949 ERR_MSG : tstr, 950 ? CIPHER_SUITEs_V : suites, 951 ) 953 suites : int / [ 2* int ] 955 where: 957 o MSG_TYPE = 0 959 o ERR_MSG - text string containing the diagnostic payload, defined 960 in the same way as in Section 5.5.2 of [RFC7252] 962 o CIPHER_SUITEs_V - cipher suites from CIPHER_SUITEs_U or the EDHOC 963 cipher suites registry that V supports. Note that CIPHER_SUITEs_V 964 contains the values from the EDHOC cipher suites registry and not 965 indexes. 967 7. IANA Considerations 969 7.1. The Well-Known URI Registry 971 IANA has added the well-known URI 'edhoc' to the Well-Known URIs 972 registry. 974 o URI suffix: edhoc 976 o Change controller: IETF 978 o Specification document(s): [[this document]] 980 o Related information: None 982 7.2. Media Types Registry 984 IANA has added the media type 'application/edhoc' to the Media Types 985 registry. 987 o Type name: application 989 o Subtype name: edhoc 991 o Required parameters: N/A 992 o Optional parameters: N/A 994 o Encoding considerations: binary 996 o Security considerations: See Section 7 of this document. 998 o Interoperability considerations: N/A 1000 o Published specification: [[this document]] (this document) 1002 o Applications that use this media type: To be identified 1004 o Fragment identifier considerations: N/A 1006 o Additional information: 1008 * Magic number(s): N/A 1010 * File extension(s): N/A 1012 * Macintosh file type code(s): N/A 1014 o Person & email address to contact for further information: See 1015 "Authors' Addresses" section. 1017 o Intended usage: COMMON 1019 o Restrictions on usage: N/A 1021 o Author: See "Authors' Addresses" section. 1023 o Change Controller: IESG 1025 7.3. CoAP Content-Formats Registry 1027 IANA has added the media type 'application/edhoc' to the CoAP 1028 Content-Formats registry. 1030 o Media Type: application/edhoc 1032 o Encoding: 1034 o ID: TBD42 1036 o Reference: [[this document]] 1038 8. Security Considerations 1040 8.1. Security Properties 1042 EDHOC inherits its security properties from the theoretical SIGMA-I 1043 protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides 1044 perfect forward secrecy, mutual authentication with aliveness, 1045 consistency, peer awareness, and identity protection. As described 1046 in [SIGMA], peer awareness is provided to Party V, but not to Party 1047 U. 1049 EDHOC with asymmetric authentication offers identity protection of 1050 Party U against active attacks and identity protection of Party V 1051 against passive attacks. The roles should be assigned to protect the 1052 most sensitive identity, typically that which is not possible to 1053 infer from routing information in the lower layers. 1055 Compared to [SIGMA], EDHOC adds an explicit message type and expands 1056 the message authentication coverage to additional elements such as 1057 algorithms, application data, and previous messages. This protects 1058 against an attacker replaying messages or injecting messages from 1059 another session. 1061 EDHOC also adds negotiation of connection identifiers and downgrade 1062 protected negotiation of cryptographic parameters, i.e. an attacker 1063 cannot affect the negotiated parameters. A single session of EDHOC 1064 does not include negotiation of cipher suites, but it enables Party V 1065 to verify that the selected cipher suite is the most preferred cipher 1066 suite by U which is supported by both U and V. 1068 8.2. Cryptographic Considerations 1070 The security of the SIGMA protocol requires the MAC to be bound to 1071 the identity of the signer. Hence the message authenticating 1072 functionality of the authenticated encryption in EDHOC is critical: 1073 authenticated encryption MUST NOT be replaced by plain encryption 1074 only, even if authentication is provided at another level or through 1075 a different mechanism. EDHOC implements SIGMA-I using the same Sign- 1076 then-MAC approach as TLS 1.3. 1078 To reduce message overhead EDHOC does not use explicit nonces and 1079 instead rely on the ephemeral public keys to provide randomness to 1080 each session. A good amount of randomness is important for the key 1081 generation, to provide aliveness, and to protect against interleaving 1082 attacks. For this reason, the ephemeral keys MUST NOT be reused, and 1083 both parties SHALL generate fresh random ephemeral key pairs. 1085 The choice of key length used in the different algorithms needs to be 1086 harmonized, so that a sufficient security level is maintained for 1087 certificates, EDHOC, and the protection of application data. Party U 1088 and V should enforce a minimum security level. 1090 The data rates in many IoT deployments are very limited. Given that 1091 the application keys are protected as well as the long-term 1092 authentication keys they can often be used for years or even decades 1093 before the cryptographic limits are reached. If the application keys 1094 established through EDHOC need to be renewed, the communicating 1095 parties can derive application keys with other labels or run EDHOC 1096 again. 1098 8.3. Mandatory to Implement Cipher Suite 1100 Cipher suite number 1 (AES-CCM-64-64-128, ECDH-SS + HKDF-256, X25519, 1101 Ed25519) is mandatory to implement. For many constrained IoT devices 1102 it is problematic to support more than one cipher suites, so some 1103 deployments with P-256 may not support the mandatory cipher suite. 1104 This is not a problem for local deployments. 1106 8.4. Unprotected Data 1108 Party U and V must make sure that unprotected data and metadata do 1109 not reveal any sensitive information. This also applies for 1110 encrypted data sent to an unauthenticated party. In particular, it 1111 applies to UAD_1, ID_CRED_V, UAD_2, and ERR_MSG in the asymmetric 1112 case, and KID, UAD_1, and ERR_MSG in the symmetric case. Using the 1113 same KID or UAD_1 in several EDHOC sessions allows passive 1114 eavesdroppers to correlate the different sessions. The communicating 1115 parties may therefore anonymize KID. Another consideration is that 1116 the list of supported cipher suites may be used to identify the 1117 application. 1119 Party U and V must also make sure that unauthenticated data does not 1120 trigger any harmful actions. In particular, this applies to UAD_1 1121 and ERR_MSG in the asymmetric case, and KID, UAD_1, and ERR_MSG in 1122 the symmetric case. 1124 8.5. Denial-of-Service 1126 EDHOC itself does not provide countermeasures against Denial-of- 1127 Service attacks. By sending a number of new or replayed message_1 an 1128 attacker may cause Party V to allocate state, perform cryptographic 1129 operations, and amplify messages. To mitigate such attacks, an 1130 implementation SHOULD rely on lower layer mechanisms such as the Echo 1131 option in CoAP [I-D.ietf-core-echo-request-tag] that forces the 1132 initiator to demonstrate reachability at their apparent network 1133 address. 1135 8.6. Implementation Considerations 1137 The availability of a secure pseudorandom number generator and truly 1138 random seeds are essential for the security of EDHOC. If no true 1139 random number generator is available, a truly random seed must be 1140 provided from an external source. If ECDSA is supported, 1141 "deterministic ECDSA" as specified in RFC6979 is RECOMMENDED. 1143 The referenced processing instructions in [SP-800-56A] must be 1144 complied with, including deleting the intermediate computed values 1145 along with any ephemeral ECDH secrets after the key derivation is 1146 completed. The ECDH shared secret, keys (K_2, K_3), and IVs (IV_2, 1147 IV_3) MUST be secret. Implementations should provide countermeasures 1148 to side-channel attacks such as timing attacks. 1150 Party U and V are responsible for verifying the integrity of 1151 certificates. The selection of trusted CAs should be done very 1152 carefully and certificate revocation should be supported. The 1153 private authentication keys MUST be kept secret. 1155 Party U and V are allowed to select the connection identifiers C_U 1156 and C_V, respectively, for the other party to use in the ongoing 1157 EDHOC protocol as well as in a subsequent application protocol (e.g. 1158 OSCORE [I-D.ietf-core-object-security]). The choice of connection 1159 identifier is not security critical in EDHOC but intended to simplify 1160 the retrieval of the right security context in combination with using 1161 short identifiers. If the wrong connection identifier of the other 1162 party is used in a protocol message it will result in the receiving 1163 party not being able to retrieve a security context (which will 1164 terminate the protocol) or retrieve the wrong security context (which 1165 also terminates the protocol as the message cannot be verified). 1167 8.7. Other Documents Referencing EDHOC 1169 EDHOC has been analyzed in several other documents. A formal 1170 verification of EDHOC was done in [SSR18], an analysis of EDHOC for 1171 certificate enrollment was done in [Kron18], the use of EDHOC in 1172 LoRaWAN is analyzed in [LoRa1] and [LoRa2], the use of EDHOC in IoT 1173 bootstrapping is analyzed in [Perez18], and the use of EDHOC in 1174 6TiSCH is described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. 1176 9. References 1178 9.1. Normative References 1180 [I-D.ietf-cbor-7049bis] 1181 Bormann, C. and P. Hoffman, "Concise Binary Object 1182 Representation (CBOR)", draft-ietf-cbor-7049bis-04 (work 1183 in progress), October 2018. 1185 [I-D.ietf-cbor-cddl] 1186 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1187 definition language (CDDL): a notational convention to 1188 express CBOR and JSON data structures", draft-ietf-cbor- 1189 cddl-06 (work in progress), November 2018. 1191 [I-D.ietf-core-echo-request-tag] 1192 Amsuess, C., Mattsson, J., and G. Selander, "Echo and 1193 Request-Tag", draft-ietf-core-echo-request-tag-03 (work in 1194 progress), October 2018. 1196 [I-D.ietf-core-object-security] 1197 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1198 "Object Security for Constrained RESTful Environments 1199 (OSCORE)", draft-ietf-core-object-security-15 (work in 1200 progress), August 2018. 1202 [I-D.schaad-cose-x509] 1203 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1204 Headers for carrying and referencing X.509 certificates", 1205 draft-schaad-cose-x509-03 (work in progress), December 1206 2018. 1208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1209 Requirement Levels", BCP 14, RFC 2119, 1210 DOI 10.17487/RFC2119, March 1997, 1211 . 1213 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1214 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1215 . 1217 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1218 Key Derivation Function (HKDF)", RFC 5869, 1219 DOI 10.17487/RFC5869, May 2010, 1220 . 1222 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1223 Curve Cryptography Algorithms", RFC 6090, 1224 DOI 10.17487/RFC6090, February 2011, 1225 . 1227 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1228 Application Protocol (CoAP)", RFC 7252, 1229 DOI 10.17487/RFC7252, June 2014, 1230 . 1232 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1233 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1234 . 1236 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1237 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1238 May 2017, . 1240 [SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to 1241 Authenticated Diffie-Hellman and Its Use in the IKE- 1242 Protocols (Long version)", June 2003, 1243 . 1245 [SP-800-56A] 1246 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1247 Davis, "Recommendation for Pair-Wise Key-Establishment 1248 Schemes Using Discrete Logarithm Cryptography", 1249 NIST Special Publication 800-56A Revision 3, April 2018, 1250 . 1252 9.2. Informative References 1254 [CborMe] Bormann, C., "CBOR Playground", May 2018, 1255 . 1257 [I-D.hartke-core-e2e-security-reqs] 1258 Selander, G., Palombini, F., and K. Hartke, "Requirements 1259 for CoAP End-To-End Security", draft-hartke-core-e2e- 1260 security-reqs-03 (work in progress), July 2017. 1262 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 1263 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 1264 draft-ietf-6tisch-dtsecurity-zerotouch-join-03 (work in 1265 progress), October 2018. 1267 [I-D.ietf-ace-oauth-authz] 1268 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1269 H. Tschofenig, "Authentication and Authorization for 1270 Constrained Environments (ACE) using the OAuth 2.0 1271 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17 1272 (work in progress), November 2018. 1274 [I-D.ietf-ace-oscore-profile] 1275 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1276 "OSCORE profile of the Authentication and Authorization 1277 for Constrained Environments Framework", draft-ietf-ace- 1278 oscore-profile-05 (work in progress), November 2018. 1280 [I-D.ietf-core-resource-directory] 1281 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1282 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1283 resource-directory-18 (work in progress), December 2018. 1285 [I-D.ietf-tls-dtls13] 1286 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1287 Datagram Transport Layer Security (DTLS) Protocol Version 1288 1.3", draft-ietf-tls-dtls13-30 (work in progress), 1289 November 2018. 1291 [Kron18] Krontiris, A., "Evaluation of Certificate Enrollment over 1292 Application Layer Security", May 2018, 1293 . 1296 [LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., 1297 Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. 1298 Skarmeta, "Enhancing LoRaWAN Security through a 1299 Lightweight and Authenticated Key Management Approach", 1300 June 2018, 1301 . 1304 [LoRa2] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., 1305 Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. 1306 Skarmeta, "Internet Access for LoRaWAN Devices Considering 1307 Security Issues", June 2018, 1308 . 1310 [Perez18] Perez, S., Garcia-Carrillo, D., Marin-Lopez, R., 1311 Hernandez-Ramos, J., Marin-Perez, R., and A. Skarmeta, 1312 "Architecture of security association establishment based 1313 on bootstrapping technologies for enabling critical IoT 1314 infrastructures", October 2018, . 1319 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1320 Constrained-Node Networks", RFC 7228, 1321 DOI 10.17487/RFC7228, May 2014, 1322 . 1324 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1325 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1326 . 1328 [SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T., 1329 and C. Schuermann, "Formal Verification of Ephemeral 1330 Diffie-Hellman Over COSE (EDHOC)", November 2018, 1331 . 1335 Appendix A. Use of CBOR, CDDL and COSE in EDHOC 1337 This Appendix is intended to simplify for implementors not familiar 1338 with CBOR [I-D.ietf-cbor-7049bis], CDDL [I-D.ietf-cbor-cddl], COSE 1339 [RFC8152], and HKDF [RFC5869]. 1341 A.1. CBOR and CDDL 1343 The Concise Binary Object Representation (CBOR) 1344 [I-D.ietf-cbor-7049bis] is a data format designed for small code size 1345 and small message size. CBOR builds on the JSON data model but 1346 extends it by e.g. encoding binary data directly without base64 1347 conversion. In addition to the binary CBOR encoding, CBOR also has a 1348 diagnostic notation that is readable and editable by humans. The 1349 Concise Data Definition Language (CDDL) [I-D.ietf-cbor-cddl] provides 1350 a way to express structures for protocol messages and APIs that use 1351 CBOR. [I-D.ietf-cbor-cddl] also extends the diagnostic notation. 1353 CBOR data items are encoded to or decoded from byte strings using a 1354 type-length-value encoding scheme, where the three highest order bits 1355 of the initial byte contain information about the major type. CBOR 1356 supports several different types of data items, in addition to 1357 integers (int, uint), simple values (e.g. null), byte strings (bstr), 1358 and text strings (tstr), CBOR also supports arrays [] of data items 1359 and maps {} of pairs of data items. Some examples are given below. 1360 For a complete specification and more examples, see 1361 [I-D.ietf-cbor-7049bis] and [I-D.ietf-cbor-cddl]. We recommend 1362 implementors to get used to CBOR by using the CBOR playground 1363 [CborMe]. 1365 Diagnostic Encoded Type 1366 ------------------------------------------------------------------ 1367 1 0x01 unsigned integer 1368 24 0x1818 unsigned integer 1369 -24 0x37 negative integer 1370 -25 0x3818 negative integer 1371 null 0xf6 simple value 1372 h'12cd' 0x4212cd byte string 1373 '12cd' 0x4431326364 byte string 1374 "12cd" 0x6431326364 text string 1375 << 1, 2, null >> 0x430102f6 byte string 1376 [ 1, 2, null ] 0x830102f6 array 1377 [_ 1, 2, null ] 0x9f0102f6ff array (indefinite-length) 1378 ( 1, 2, null ) 0x0102f6 group 1379 { 4: h'cd' } 0xa10441cd map 1380 ------------------------------------------------------------------ 1382 All EDHOC messages consist of a sequence of CBOR encoded data items. 1383 While an EDHOC message in itself is not a CBOR data item, it may be 1384 viewed as the CBOR encoding of an indefinite-length array [_ 1385 message_i ] without the first byte (0x9f) and the last byte (0xff), 1386 for i = 1, 2 and 3. The same applies to the EDHOC error message. 1388 The message format specification uses the constructs '.cbor', 1389 '.cborseq' and '~' enabling conversion between different CDDL types 1390 matching different CBOR items with different encodings. Some 1391 examples are given below. 1393 A type (e.g. an uint) may be wrapped in a byte string (bstr), and 1394 back again: 1396 CDDL Type Diagnostic Encoded 1397 ------------------------------------------------------------------ 1398 uint 24 0x1818 1399 bstr .cbor uint << 24 >> 0x421818 1400 ~ bstr .cbor uint 24 0x1818 1401 ------------------------------------------------------------------ 1403 A array, say of an uint and a byte string, may be converted into a 1404 byte string (bstr): 1406 CDDL Type Diagnostic Encoded 1407 -------------------------------------------------------------------- 1408 bstr h'cd' 0x41cd 1409 [ uint, bstr ] [ 24, h'cd' ] 0x82181841cd 1410 bstr .cborseq [ uint, bstr ] << 24, h'cd' >> 0x44181841cd 1411 -------------------------------------------------------------------- 1413 A.2. COSE 1415 CBOR Object Signing and Encryption (COSE) [RFC8152] describes how to 1416 create and process signatures, message authentication codes, and 1417 encryption using CBOR. COSE builds on JOSE, but is adapted to allow 1418 more efficient processing in constrained devices. EDHOC makes use of 1419 COSE_Key, COSE_Encrypt0, COSE_Sign1, and COSE_KDF_Context objects. 1421 A.2.1. Encryption and Decryption 1423 The COSE parameters used in COSE_Encrypt0 (see Section 5.2 of 1424 [RFC8152]) are constructed as described below. Note that "i" in 1425 "K_i", "IV_i" and "aad_i" is a variable with value i = 2 or 3, 1426 depending on whether the calculation is made over message_2 or 1427 message_3. 1429 o The secret key K_i is a CBOR bstr, generated with the EDHOC-Key- 1430 Derivation function as defined in Section 3.3. 1432 o The initialization vector IV_i is a CBOR bstr, also generated with 1433 the EDHOC-Key-Derivation function as defined in Section 3.3. 1435 o The plaintext is a CBOR bstr. If the application data (UAD and 1436 PAD) is omitted, then plaintext = h'' in the symmetric case, and 1437 plaintext = << ~protected, signature >> in the asymmetric case. 1438 For instance, if protected = h'a10140' and signature = h'050607' 1439 (CBOR encoding 0x43050607), then plaintext = h'a1014043050607'. 1441 o The external_aad is a CBOR bstr. It is always set to aad_i. 1443 COSE constructs the input to the AEAD [RFC5116] as follows: 1445 o The key K is the value of the key K_i. 1447 o The nonce N is the value of the initialization vector IV_i. 1449 o The plaintext P is the value of the COSE plaintext. E.g. if the 1450 COSE plaintext = h'010203', then P = 0x010203. 1452 o The associated data A is the CBOR encoding of: 1454 [ "Encrypt0", h'', aad_i ] 1456 This equals the concatenation of 0x8368456e63727970743040 and the 1457 CBOR encoding of aad_i. For instance if aad_2 = h'010203' (CBOR 1458 encoding 0x43010203), then A = 0x8368456e6372797074304043010203. 1460 A.2.2. Signing and Verification 1462 The COSE parameters used in COSE_Sign1 (see Section 4.2 of [RFC8152]) 1463 are constructed as described below. Note that "i" in "aad_i" is a 1464 variable with values i = 2 or 3, depending on whether the calculation 1465 is made over message_2 or message_3. Note also that "x" in 1466 "ID_CRED_x" and "CRED_x" is a variable with values x = U or V, 1467 depending on whether it is the credential of U or of V that is used 1468 in the relevant protocol message. 1470 o The key is the private authentication key of U or V. This may be 1471 stored as a COSE_KEY object or as a certificate. 1473 o The protected parameter is a map { abc : ID_CRED_x } wrapped in a 1474 byte string. 1476 o The payload is a bstr containing the CBOR encoding of a COSE_KEY 1477 or a single certificate. 1479 o external_aad = aad_i. 1481 COSE constructs the input to the Signature Algorithm as follows: 1483 o The key is the private authentication key of U or V. 1485 o The message to be signed M is the CBOR encoding of: 1487 [ "Signature1", << { abc : ID_CRED_x } >>, aad_i, CRED_x ] 1489 For instance if abc = 4 (CBOR encoding 0x04), ID_CRED_U = h'1111' 1490 (CBOR encoding 0x421111), aad_3 = h'222222' (CBOR encoding 1491 0x43222222), and CRED_U = h'55555555' (CBOR encoding 1492 0x4455555555), then M = 1493 0x846a5369676e61747572653145A104421111432222224455555555. 1495 A.2.3. Key Derivation 1497 Assuming use of the mandatory-to-implement algorithms HKDF SHA-256 1498 and AES-CCM-16-64-128, the extract phase of HKDF produces a 1499 pseudorandom key (PRK) as follows: 1501 PRK = HMAC-SHA-256( salt, ECDH shared secret ) 1502 where salt = 0x in the asymmetric case and salt = PSK in the 1503 symmetric case. As the output length L is smaller than the hash 1504 function output size, the expand phase of HKDF consists of a single 1505 HMAC invocation, and K_i and IV_i are therefore the first 16 and 13 1506 bytes, respectively, of 1508 output parameter = HMAC-SHA-256( PRK, info || 0x01 ) 1510 where || means byte string concatenation, and info is the CBOR 1511 encoding of 1513 COSE_KDF_Context = [ 1514 AlgorithmID, 1515 [ null, null, null ], 1516 [ null, null, null ], 1517 [ keyDataLength, h'', aad_i ] 1518 ] 1520 If AES-CCM-16-64-128 then AlgorithmID = 10 and keyDataLength = 128 1521 for K_i, and AlgorithmID = "IV-GENERATION" (CBOR encoding 1522 0x6d49562d47454e45524154494f4e) and keyDataLength = 104 for IV_i. 1523 Hence, if aad_2 = h'aaaa' then 1525 K_2 = HMAC-SHA-256( PRK, 0x840a83f6f6f683f6f6f68318804042aaaa01 ) 1526 IV_2 = HMAC-SHA-256( PRK, 0x846d49562d47454e45524154494f4e 1527 83f6f6f683f6f6f68318804042aaaa01 ) 1529 Appendix B. Test Vectors 1531 This appendix provides a wealth of test vectors to ease 1532 implementation and ensure interoperability. 1534 TODO: This section needs to be updated. 1536 Appendix C. EDHOC PSK Chaining 1538 An application using EDHOC may want to derive new PSKs to use for 1539 authentication in future EDHOC sessions. In this case, the new PSK 1540 and KID SHOULD be derived as follows where length is the key length 1541 (in bytes) of the AEAD Algorithm. 1543 PSK = EDHOC-Exporter("EDHOC Chaining PSK", length) 1544 KID = EDHOC-Exporter("EDHOC Chaining KID", 4) 1546 Appendix D. EDHOC with CoAP and OSCORE 1548 D.1. Transferring EDHOC in CoAP 1550 EDHOC can be transferred as an exchange of CoAP [RFC7252] messages. 1551 By default, the CoAP client is Party U and the CoAP server is Party 1552 V, but the roles SHOULD be chosen to protect the most sensitive 1553 identity, see Section 8. By default, EDHOC is transferred in POST 1554 requests and 2.04 (Changed) responses to the Uri-Path: "/.well-known/ 1555 edhoc", but an application may define its own path that can be 1556 discovered e.g. using resource directory 1557 [I-D.ietf-core-resource-directory]. 1559 By default, the message flow is as follows: EDHOC message_1 is sent 1560 in the payload of a POST request from the client to the server's 1561 resource for EDHOC. EDHOC message_2 or the EDHOC error message is 1562 sent from the server to the client in the payload of a 2.04 (Changed) 1563 response. EDHOC message_3 or the EDHOC error message is sent from 1564 the client to the server's resource in the payload of a POST request. 1565 If needed, an EDHOC error message is sent from the server to the 1566 client in the payload of a 2.04 (Changed) response. 1568 An example of a successful EDHOC exchange using CoAP is shown in 1569 Figure 5. 1571 Client Server 1572 | | 1573 +--------->| Header: POST (Code=0.02) 1574 | POST | Uri-Path: "/.well-known/edhoc" 1575 | | Content-Format: application/edhoc 1576 | | Payload: EDHOC message_1 1577 | | 1578 |<---------+ Header: 2.04 Changed 1579 | 2.04 | Content-Format: application/edhoc 1580 | | Payload: EDHOC message_2 1581 | | 1582 +--------->| Header: POST (Code=0.02) 1583 | POST | Uri-Path: "/.well-known/edhoc" 1584 | | Content-Format: application/edhoc 1585 | | Payload: EDHOC message_3 1586 | | 1587 |<---------+ Header: 2.04 Changed 1588 | 2.04 | 1589 | | 1591 Figure 5: Example of transferring EDHOC in CoAP 1593 D.2. Deriving an OSCORE context from EDHOC 1595 When EDHOC is used to derive parameters for OSCORE 1596 [I-D.ietf-core-object-security], the parties must make sure that the 1597 EDHOC connection identifiers are unique, i.e. C_V MUST NOT be equal 1598 to C_U. In case that the CoAP client is party U and the CoAP server 1599 is party V: 1601 o The client's OSCORE Sender ID is C_V and the server's OSCORE 1602 Sender ID is C_U, as defined in this document 1604 o The AEAD Algorithm and the HMAC-based Key Derivation Function 1605 (HKDF) are the AEAD and HKDF algorithms in the cipher suite 1606 CIPHER_SUITE_U. 1608 o The Master Secret and Master Salt are derived as follows where 1609 length is the key length (in bytes) of the AEAD Algorithm. 1611 Master Secret = EDHOC-Exporter("OSCORE Master Secret", length) 1612 Master Salt = EDHOC-Exporter("OSCORE Master Salt", 8) 1614 Appendix E. Message Sizes 1616 This appendix gives an estimate of the message sizes of EDHOC with 1617 different authentication methods. Note that the examples in this 1618 appendix are not test vectors, the cryptographic parts are just 1619 replaced with byte strings of the same length. All examples are 1620 given in CBOR diagnostic notation and hexadecimal. 1622 E.1. Message Sizes RPK 1624 E.1.1. message_1 1626 message_1 = ( 1627 1, 1628 h'c3', 1629 0, 1630 0, 1631 h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d 1632 1e1f' 1633 ) 1635 message_1 (39 bytes): 1636 01 41 C3 00 00 58 20 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 1637 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 1639 E.1.2. message_2 1641 plaintext = << 1642 { 4 : 'acdc' }, 1643 h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d 1644 1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b 1645 3c3d3e3f' 1646 >> 1648 The protected header map is 7 bytes. The length of plaintext is 73 1649 bytes so assuming a 64-bit MAC value the length of ciphertext is 81 1650 bytes. 1652 message_2 = ( 1653 null, 1654 h'c4', 1655 h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d 1656 1e1f', 1657 h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d 1658 1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b 1659 3c3d3e3f404142434445464748494a4b4c4d4e4f50' 1660 ) 1662 message_2 (120 bytes): 1663 F6 41 C4 58 20 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 1664 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 58 51 00 1665 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 1666 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 1667 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 1668 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 1670 E.1.3. message_3 1672 The plaintext and ciphertext in message_3 are assumed to be of equal 1673 sizes as in message_2. 1675 message_3 = ( 1676 h'c3', 1677 h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d 1678 1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b 1679 3c3d3e3f404142434445464748494a4b4c4d4e4f50' 1680 ) 1681 message_3 (85 bytes): 1682 41 C3 58 51 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 1683 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 1684 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 1685 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 1686 4C 4D 4E 4F 50 1688 E.2. Message Sizes Certificates 1690 When the certificates are distributed out-of-band and identified with 1691 the x5t header and a SHA256/64 hash value, the protected header map 1692 will be 13 bytes instead of 7 bytes (assuming labels in the range 1693 -24...23). 1695 protected = << { TDB1 : [ TDB6, h'0001020304050607' ] } >> 1697 When the certificates are identified with the x5chain header, the 1698 message sizes depends on the size of the (truncated) certificate 1699 chains. The protected header map will be 3 bytes + the size of the 1700 certificate chain (assuming a label in the range -24...23). 1702 protected = << { TDB3 : h'0001020304050607...' } >> 1704 E.3. Message Sizes PSK 1706 E.3.1. message_1 1708 message_1 = ( 1709 2, 1710 h'c3', 1711 0, 1712 0, 1713 h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d 1714 1e1f', 1715 'abba' 1716 ) 1718 message_1 (44 bytes): 1719 02 41 C3 00 00 58 20 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 1720 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 1721 44 61 63 64 63 1723 E.3.2. message_2 1725 Assuming a 0 byte plaintext and a 64-bit MAC value the ciphertext is 1726 8 bytes 1727 message_2 = ( 1728 null, 1729 h'c4', 1730 h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d 1731 1e1f', 1732 h'0001020304050607' 1733 ) 1735 message_2 (46 bytes): 1736 F6 41 C4 58 20 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 1737 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 48 61 62 1738 63 64 65 66 67 68 1740 E.3.3. message_3 1742 The plaintext and ciphertext in message_3 are assumed to be of equal 1743 sizes as in message_2. 1745 message_3 = ( 1746 h'c3', 1747 h'0001020304050607' 1748 ) 1750 message_3 (11 bytes): 1751 41 C3 48 00 01 02 03 04 05 06 07 1753 E.4. Summary 1755 The previous estimates of typical message sizes are summarized in 1756 Figure 6. 1758 ===================================================================== 1759 PSK RPK x5t x5chain 1760 --------------------------------------------------------------------- 1761 message_1 44 39 39 39 1762 message_2 46 120 126 116 + Certificate chain 1763 message_3 11 85 91 81 + Certificate chain 1764 --------------------------------------------------------------------- 1765 Total 101 244 256 236 + Certificate chains 1766 ===================================================================== 1768 Figure 6: Typical message sizes in bytes 1770 Figure 7 compares of message sizes of EDHOC with the DTLS 1.3 1771 handshake [I-D.ietf-tls-dtls13] with connection ID. 1773 ===================================================================== 1774 Flight #1 #2 #3 Total 1775 --------------------------------------------------------------------- 1776 DTLS 1.3 RPK + ECDHE 149 373 213 735 1777 DTLS 1.3 PSK + ECDHE 186 190 57 433 1778 DTLS 1.3 PSK 136 150 57 343 1779 --------------------------------------------------------------------- 1780 EDHOC RPK + ECDHE 39 120 85 244 1781 EDHOC PSK + ECDHE 44 46 11 101 1782 ===================================================================== 1784 Figure 7: Comparison of message sizes in bytes with Connection ID 1786 Figure 8 compares of message sizes of EDHOC with the DTLS 1.3 1787 [I-D.ietf-tls-dtls13] and TLS 1.3 [RFC8446] handshakes without 1788 connection ID. 1790 ===================================================================== 1791 Flight #1 #2 #3 Total 1792 --------------------------------------------------------------------- 1793 DTLS 1.3 RPK + ECDHE 143 364 212 721 1794 DTLS 1.3 PSK + ECDHE 180 183 56 419 1795 DTLS 1.3 PSK 130 143 56 329 1796 --------------------------------------------------------------------- 1797 TLS 1.3 RPK + ECDHE 129 322 194 645 1798 TLS 1.3 PSK + ECDHE 166 157 50 373 1799 TLS 1.3 PSK 116 117 50 283 1800 --------------------------------------------------------------------- 1801 EDHOC RPK + ECDHE 38 119 84 241 1802 EDHOC PSK + ECDHE 44 45 10 98 1803 ===================================================================== 1805 Figure 8: Comparison of message sizes in bytes without Connection ID 1807 Acknowledgments 1809 The authors want to thank Alessandro Bruni, Theis Groenbech Petersen, 1810 Dan Harkins, Klaus Hartke, Alexandros Krontiris, Ilari Liusvaara, 1811 Salvador Perez, Michael Richardson, Thorvald Sahl Joergensen, Jim 1812 Schaad, Carsten Schuermann, and Ludwig Seitz for reviewing 1813 intermediate versions of the draft. We are especially indebted to 1814 Jim Schaad for his continuous reviewing and implementation of 1815 different versions of the draft. 1817 Authors' Addresses 1819 Goeran Selander 1820 Ericsson AB 1822 Email: goran.selander@ericsson.com 1824 John Mattsson 1825 Ericsson AB 1827 Email: john.mattsson@ericsson.com 1829 Francesca Palombini 1830 Ericsson AB 1832 Email: francesca.palombini@ericsson.com