idnits 2.17.1 draft-selander-ace-cose-ecdhe-08.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 (March 05, 2018) is 2243 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 (-03) exists of draft-schaad-cose-x509-01 ** 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 6090 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** 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 (-46) exists of draft-ietf-ace-oauth-authz-10 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-00 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-02 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-08 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-12 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: September 6, 2018 Ericsson AB 6 March 05, 2018 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-selander-ace-cose-ecdhe-08 11 Abstract 13 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 14 compact, and lightweight authenticated Diffie-Hellman key exchange 15 with ephemeral keys that can be used over any layer. EDHOC messages 16 are encoded with CBOR and COSE, allowing reuse of existing libraries. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 6, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 56 3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Formatting of the Ephemeral Public Keys . . . . . . . . . 6 58 3.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . 6 59 4. EDHOC Authenticated with Asymmetric Keys . . . . . . . . . . 8 60 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 9 62 4.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 11 63 4.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 14 64 5. EDHOC Authenticated with Symmetric Keys . . . . . . . . . . . 15 65 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 66 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 16 67 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 19 68 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 21 69 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 22 70 6.1. Error Message Format . . . . . . . . . . . . . . . . . . 22 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 72 7.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 22 73 7.2. Media Types Registry . . . . . . . . . . . . . . . . . . 23 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 78 10.2. Informative References . . . . . . . . . . . . . . . . . 27 79 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 28 80 Appendix B. PSK Chaining . . . . . . . . . . . . . . . . . . . . 28 81 Appendix C. EDHOC with CoAP and OSCORE . . . . . . . . . . . . . 28 82 C.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 28 83 C.2. Deriving an OSCORE context from EDHOC . . . . . . . . . . 29 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 86 1. Introduction 88 Security at the application layer provides an attractive option for 89 protecting Internet of Things (IoT) deployments, for example where 90 transport layer security is not sufficient 91 [I-D.hartke-core-e2e-security-reqs] or where the protocol needs to 92 work on a variety of underlying protocols. IoT devices may be 93 constrained in various ways, including memory, storage, processing 94 capacity, and energy [RFC7228]. A method for protecting individual 95 messages at the application layer suitable for constrained devices, 96 is provided by CBOR Object Signing and Encryption (COSE) [RFC8152]), 97 which builds on the Concise Binary Object Representation (CBOR) 98 [RFC7049]. 100 In order for a communication session to provide forward secrecy, the 101 communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH) 102 key exchange protocol with ephemeral keys, from which shared key 103 material can be derived. This document specifies Ephemeral Diffie- 104 Hellman Over COSE (EDHOC), an authenticated ECDH protocol using CBOR 105 and COSE objects. Authentication is based on credentials established 106 out of band, e.g. from a trusted third party, such as an 107 Authorization Server as specified by [I-D.ietf-ace-oauth-authz]. 108 EDHOC supports authentication using pre-shared keys (PSK), raw public 109 keys (RPK), and certificates (Cert). Note that this document focuses 110 on authentication and key establishment: for integration with 111 authorization of resource access, refer to 112 [I-D.ietf-ace-oscore-profile]. This document also specifies the 113 derivation of shared key material. 115 The ECDH exchange and the key derivation follow [SIGMA], NIST SP- 116 800-56a [SP-800-56a], and HKDF [RFC5869]. CBOR [RFC7049] and COSE 117 [RFC8152] are used to implement these standards. 119 1.1. Terminology 121 This document use the same informational CBOR Data Definition 122 Language (CDDL) [I-D.ietf-cbor-cddl] grammar as COSE (see Section 1.3 123 of [RFC8152]). A vertical bar | denotes byte string concatenation. 125 1.2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. These 130 words may also appear in this document in lowercase, absent their 131 normative meanings. 133 2. Protocol Overview 135 SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a 136 large number of variants [SIGMA]. Like IKEv2 and TLS 1.3, EDHOC is 137 built on a variant of the SIGMA protocol which provide identity 138 protection, and like TLS 1.3, EDHOC implements the SIGMA-I variant as 139 Sign-then-MAC. The SIGMA-I protocol using an AEAD algorithm is shown 140 in Figure 1. 142 Party U Party V 143 | E_U | 144 +------------------------------------------------------>| 145 | | 146 | E_V, Enc(K_2; ID_V, Sig(V; E_U, E_V);) | 147 |<------------------------------------------------------+ 148 | | 149 | Enc(K_3; ID_U, Sig(U; E_V, E_U);) | 150 +------------------------------------------------------>| 151 | | 153 Figure 1: AEAD variant of the SIGMA-I protocol 155 The parties exchanging messages are called "U" and "V". They 156 exchange identities and ephemeral public keys, compute the shared 157 secret, and derive the keying material. The messages are signed, 158 MACed, and encrypted. 160 o E_U and E_V are the ECDH ephemeral public keys of U and V, 161 respectively. 163 o ID_U and ID_V are identifiers for the public keys of U and V, 164 respectively. 166 o Sig(U; . ) and S(V; . ) denote signatures made with the private 167 key of U and V, respectively. 169 o Enc(K; P; A) denotes AEAD encryption of plaintext P and additional 170 authenticated data A using the key K derived from the shared 171 secret. The AEAD MUST NOT be replaced by plain encryption, see 172 Section 8. 174 As described in Appendix B of [SIGMA], in order to create a "full- 175 fledged" protocol some additional protocol elements are needed. 176 EDHOC adds: 178 o Explicit session identifiers S_U, S_V different from other 179 concurrent session identifiers (EDHOC or other used protocol 180 identifier) chosen by U and V, respectively. 182 o Explicit nonces N_U, N_V chosen freshly and anew with each session 183 by U and V, respectively. 185 o Computationally independent keys derived from the ECDH shared 186 secret and used for encryption of different messages. 188 EDHOC also makes the following additions: 190 o Negotiation of key derivation, encryption, and signature 191 algorithms: 193 * U proposes one or more algorithms of the following kinds: 195 + HKDF 197 + AEAD 199 + Signature verification 201 + Signature generation 203 * V selects one algorithm of each kind 205 o Verification of common preferred ECDH curve: 207 * U lists supported ECDH curves in order of preference 209 * V verifies that the ECDH curve of the ephemeral key is the most 210 preferred common curve 212 o Transport of opaque application defined data. 214 EDHOC is designed to encrypt and integrity protect as much 215 information as possible, and all symmetric keys are derived using as 216 much previous information as possible. EDHOC is furthermore designed 217 to be as compact and lightweight as possible, in terms of message 218 sizes, processing, and the ability to reuse already existing CBOR and 219 COSE libraries. EDHOC does not put any requirement on the lower 220 layers and can therefore be also be used e.g. in environments without 221 IP. 223 This paper is organized as follows: Section 3 specifies general 224 properties of EDHOC, including formatting of the ephemeral public 225 keys and key derivation, Section 4 specifies EDHOC with asymmetric 226 key authentication, Section 5 specifies EDHOC with symmetric key 227 authentication, and Appendix A provides a wealth of test vectors to 228 ease implementation and ensure interoperability. 230 3. EDHOC Overview 232 EDHOC consists of three messages (message_1, message_2, message_3) 233 that maps directly to the three messages in SIGMA-I, plus an EDHOC 234 error message. All EDHOC messages consists of a CBOR array where the 235 first element is an int specifying the message type (MSG_TYPE). 236 After creating EDHOC message_3, Party U can derive the traffic key 237 (master secret) and protected application data can therefore be sent 238 in parallel with EDHOC message_3. The application data may be 239 protected using the negotiated AEAD algorithm and the explicit 240 session identifiers S_U and S_V. EDHOC may be used with the media 241 type application/edhoc defined in Section 7. 243 Party U Party V 244 | | 245 | ------------------ EDHOC message_1 -----------------> | 246 | | 247 | <----------------- EDHOC message_2 ------------------ | 248 | | 249 | ------------------ EDHOC message_3 -----------------> | 250 | | 251 | <----------- Protected Application Data ------------> | 252 | | 254 Figure 2: EDHOC message flow 256 The EDHOC message exchange may be authenticated using pre-shared keys 257 (PSK), raw public keys (RPK), or certificates (Cert). EDHOC assumes 258 the existence of mechanisms (certification authority, manual 259 distribution, etc.) for binding identities with authentication keys 260 (public or pre-shared). EDHOC with symmetric key authentication is 261 very similar to EDHOC with asymmetric key authentication, the 262 difference being that information is only MACed, not signed. 264 EDHOC also allows opaque application data (APP_1, APP_2, APP_3) to be 265 sent in the respective messages. APP_1 is unprotected, APP_2 is 266 protected (encrypted and integrity protected), and APP_3 is protected 267 and mutually authenticated. When EDHOC is used with asymmetric key 268 authentication APP_2 is sent to an unauthenticated party, but with 269 symmetric key authentication APP_2 is mutually authenticated. 271 3.1. Formatting of the Ephemeral Public Keys 273 The ECDH ephemeral public key SHALL be formatted as a COSE_Key of 274 type EC2 or OKP according to section 13.1 and 13.2 of [RFC8152]. The 275 curve X25519 is mandatory to implement. For Elliptic Curve Keys of 276 type EC2, compact representation and compact output as per [RFC6090] 277 SHALL be used, i.e. the 'y' parameter SHALL NOT be present in the The 278 COSE_Key object. COSE [RFC8152] always use compact output for 279 Elliptic Curve Keys of type EC2. 281 3.2. Key Derivation 283 Key and IV derivation SHALL be done as specified in Section 11.1 of 284 [RFC8152] with the following input: 286 o The PRF SHALL be the HKDF [RFC5869] in the ECDH-SS w/ HKDF 287 negotiated during the message exchange (HKDF_V). 289 o The secret SHALL be the ECDH shared secret as defined in 290 Section 12.4.1 of [RFC8152]. 292 o The salt SHALL be the PSK when EDHOC is authenticated with 293 symmetric keys and the empty string "" when EDHOC is authenticated 294 with asymmetric keys. 296 o The fields in the context information COSE_KDF_Context SHALL have 297 the following values: 299 * AlgorithmID is an int or tstr as defined below 301 * PartyUInfo = PartyVInfo = ( nil, nil, nil ) 303 * keyDataLength is a uint as defined below 305 * protected SHALL be a zero length bstr 307 * other is a bstr SHALL be aad_2, aad_3, or exchange_hash 309 where exchange_hash, in non-CDDL notation, is: 311 +---------------------------------+-------------+-------------+ 312 | exchange_hash = H( H( message_1 | message_2 ) | message_3 ) | 313 +---------------------------------+-------------+-------------+ 314 +---------------------------------+-------------+-------------+ 316 where H() is the hash function in HKDF_V. 318 For message_i the key, called K_i, SHALL be derived using other = 319 aad_i, where i = 2 or 3. The key SHALL be derived using AlgorithmID 320 set to the integer value of the negotiated AEAD (AEAD_V), and 321 keyDataLength equal to the key length of AEAD_V. 323 If the AEAD algorithm requires an IV, then IV_i for message_i SHALL 324 be derived using other = aad_i, where i = 2 or 3. The IV SHALL be 325 derived using AlgorithmID = "IV-GENERATION" as specified in section 326 12.1.2. of [RFC8152], and keyDataLength equal to the IV length of 327 AEAD_V. 329 Application specific traffic keys and other data SHALL be derived 330 using other = exchange_hash. AlgorithmID SHALL be a tstr defined by 331 the application and SHALL be different for different data being 332 derived (an example is given in Appendix C.2). keyDataLength is set 333 to the length of the data being derived. 335 4. EDHOC Authenticated with Asymmetric Keys 337 4.1. Overview 339 EDHOC supports authentication with raw public keys (RPK) and 340 certificates (Cert) with the requirements that: 342 o Party U SHALL be able to identify Party V's public key using ID_V. 344 o Party V SHALL be able to identify Party U's public key using ID_U. 346 ID_U and ID_V SHALL either contain the credential used for 347 authentication (e.g. x5bag or x5chain) or uniquely identify the 348 credential used for authentication (e.g. x5t), see 349 [I-D.schaad-cose-x509]. Party U and V MAY retrieve the other party's 350 credential out of band. Optionally, ID_U and ID_V are complemented 351 with the additional parameters HINT_ID_U and HINT_ID_V containing 352 information about how to retrieve the credential of Party U and Party 353 V, respectively (e.g. x5u), see [I-D.schaad-cose-x509]. 355 Party U and Party V MAY use different type of credentials, e.g. one 356 uses RPK and the other uses Cert. Party U and Party V MAY use 357 different signature algorithms. 359 EDHOC with asymmetric key authentication is illustrated in Figure 3. 361 Party U Party V 362 | S_U, N_U, E_U, ALG_1, APP_1 | 363 +--------------------------------------------------------------------->| 364 | message_1 | 365 | | 366 |S_U, S_V, N_V, E_V, ALG_2, Enc(K_2; Sig(V; ID_V, aad_2, APP_2); aad_2)| 367 |<---------------------------------------------------------------------+ 368 | message_2 | 369 | | 370 | S_V, Enc(K_3; Sig(U; ID_U, aad_3, APP_3); aad_3) | 371 +--------------------------------------------------------------------->| 372 | message_3 | 374 Figure 3: EDHOC with asymmetric key authentication. 376 4.1.1. Mandatory to Implement Algorithms 378 For EDHOC authenticated with asymmetric keys, the COSE algorithms 379 ECDH-SS + HKDF-256, AES-CCM-64-64-128, and EdDSA are mandatory to 380 implement. 382 4.2. EDHOC Message 1 384 4.2.1. Formatting of Message 1 386 message_1 SHALL be a CBOR array as defined below 388 message_1 = [ 389 MSG_TYPE : int, 390 S_U : bstr, 391 N_U : bstr, 392 E_U : serialized_COSE_Key, 393 ECDH-Curves_U : alg_array, 394 HKDFs_U : alg_array, 395 AEADs_U : alg_array, 396 SIGs_V : alg_array, 397 SIGs_U : alg_array, 398 ? APP_1 : bstr 399 ] 401 serialized_COSE_Key = bstr .cbor COSE_Key 403 alg_array = [ + alg : int / tstr ] 405 where: 407 o MSG_TYPE = 1 409 o S_U - variable length session identifier 411 o N_U - 64-bit random nonce 413 o E_U - the ephemeral public key of Party U 415 o ECDH-Curves_U - EC curves for ECDH which Party U supports, in the 416 order of decreasing preference 418 o HKDFs_U - supported ECDH-SS w/ HKDF algorithms 420 o AEADs_U - supported AEAD algorithms 422 o SIGs_V - signature algorithms, with which Party U supports 423 verification 425 o SIGs_U - signature algorithms, with which Party U supports signing 427 o APP_1 - bstr containing opaque application data 429 4.2.2. Party U Processing of Message 1 431 Party U SHALL compose message_1 as follows: 433 o Determine which ECDH curve to use with Party V. If U previously 434 received from Party V an error message to message_1 with 435 diagnostic payload identifying an ECDH curve in ECDH-Curves_U, 436 then U SHALL retrieve an ephemeral from that curve. Otherwise the 437 first curve in ECDH-Curves_U MUST be used. The content of ECDH- 438 Curves_U SHALL be fixed, and SHALL NOT be changed based on 439 previous error messages. 441 o Retrieve an ephemeral ECDH key pair generated as specified in 442 Section 5 of [SP-800-56a] and format the ephemeral public key E_U 443 as a COSE_key as specified in Section 3.1. 445 o Generate the pseudo-random nonce N_U. 447 o Choose a session identifier S_U which is not in use and store it 448 for the length of the protocol. The session identifier SHOULD be 449 different from other concurrent session identifiers used by Party 450 U. The session identifier MAY be used with the protocol for which 451 EDHOC establishes traffic keys/master secret, in which case S_U 452 SHALL be different from the concurrently used session identifiers 453 of that protocol. 455 o Format message_1 as specified in Section 4.2.1. 457 4.2.3. Party V Processing of Message 1 459 Party V SHALL process message_1 as follows: 461 o Verify (OPTIONAL) that N_U has not been received before. 463 o Verify that at least one of each kind of the proposed algorithms 464 are supported. 466 o Verify that the ECDH curve used in E_U is supported, and that no 467 prior curve in ECDH-Curves_U is supported. 469 o For elliptic curves, that E_U is a valid point by verifying that 470 there is a solution to the curve definition for the given 471 parameter 'x'. 473 If any verification step fails, Party V MUST send an EDHOC error 474 message back, formatted as defined in Section 6.1, and the protocol 475 MUST be discontinued. If V does not support the ECDH curve used in 476 E_U, but supports another ECDH curves in ECDH-Curves_U, then the 477 error message MUST include the following diagnostic payload 478 describing the first supported ECDH curve in ECDH-Curves_U: 480 ERR_MSG = "Curve not supported; X" 482 where X is the first curve in ECDH-Curves_U that V supports, 483 encoded as in Table 22 of {{RFC8152}}. 485 o Pass APP_1 to the application. 487 4.3. EDHOC Message 2 489 4.3.1. Formatting of Message 2 491 message_2 SHALL be a CBOR array as defined below 493 message_2 = [ 494 data_2, 495 COSE_ENC_2 : COSE_Encrypt0 496 ] 498 data_2 = ( 499 MSG_TYPE : int, 500 S_U : bstr, 501 S_V : bstr, 502 N_V : bstr, 503 E_V : serialized_COSE_Key, 504 HKDF_V : int / tstr, 505 AEAD_V : int / tstr, 506 SIG_V : int / tstr, 507 SIG_U : int / tstr 508 ) 510 aad_2 : bstr 512 where aad_2, in non-CDDL notation, is: 514 aad_2 = H( message_1 | [ data_2 ] ) 516 where: 518 o MSG_TYPE = 2 520 o S_V - variable length session identifier 522 o N_V - 64-bit random nonce 524 o E_V - the ephemeral public key of Party V 525 o HKDF_V - a single chosen algorithm from HKDFs_U 527 o AEAD_V - a single chosen algorithm from AEADs_U 529 o SIG_V - a single chosen algorithm from SIGs_V with which Party V 530 signs 532 o SIG_U - a single chosen algorithm from SIGs_U with which Party U 533 signs 535 o COSE_ENC_2 has the following fields and values: 537 * external_aad = aad_2 539 * plaintext = [ COSE_SIG_V, ? APP_2 ] 541 o COSE_SIG_V is a COSE_Sign1 object with the following fields and 542 values: 544 * protected = { abc : ID_V, ? xyz : HINT_ID_V } 546 * detached payload = aad_2, ? APP_2 548 o abc - any COSE map label that can identify a public key, see 549 Section 4.1 551 o ID_V - identifier for the public key of Party V 553 o xyz - any COSE map label for information about how to retrieve the 554 credential of Party V, see Section 4.1 556 o HINT_ID_V - information about how to retrieve the credential of 557 Party V 559 o APP_2 - bstr containing opaque application data 561 o H() - the hash function in HKDF_V 563 4.3.2. Party V Processing of Message 2 565 Party V SHALL compose message_2 as follows: 567 o Retrieve an ephemeral ECDH key pair generated as specified in 568 Section 5 of [SP-800-56a] using same curve as used in E_U. Format 569 the ephemeral public key E_V as a COSE_key as specified in 570 Section 3.1. 572 o Generate the pseudo-random nonce N_V. 574 o Choose a session identifier S_V which is not in use and store it 575 for the length of the protocol. The session identifier SHOULD be 576 different from other relevant concurrent session identifiers used 577 by Party V. The session identifier MAY be used with the protocol 578 for which EDHOC establishes traffic keys/master secret, in which 579 case S_V SHALL be different from the concurrently used session 580 identifiers of that protocol. 582 o Select HKDF_V, AEAD_V, SIG_V, and SIG_U from the algorithms 583 proposed in HKDFs_U, AEADs_U, SIGs_V, and SIGs_U. 585 o Format message_2 as specified in Section 4.3.1: 587 * COSE_Sign1 is computed as defined in section 4.4 of [RFC8152], 588 using algorithm SIG_V and the private key of Party V. 590 * COSE_Encrypt0 is computed as defined in section 5.3 of 591 [RFC8152], with AEAD_V, K_2, and IV_2. The AEAD algorithm MUST 592 NOT be replaced by plain encryption, see Section 8. 594 4.3.3. Party U Processing of Message 2 596 Party U SHALL process message_2 as follows: 598 o Use the session identifier S_U to retrieve the protocol state. 600 o Verify that HKDF_V, AEAD_V, SIG_V, and SIG_U were proposed in 601 HKDFs_U, AEADs_U, SIGs_V, and SIGs_U. 603 o Verify (OPTIONAL) that N_V has not been received before. 605 o For elliptic curves, validate that E_V is a valid point by 606 verifying that there is a solution to the curve definition for the 607 given parameter 'x'. 609 o Verify message_2 as specified in Section 4.3.1: 611 * COSE_Encrypt0 is decrypted defined in section 5.3 of [RFC8152], 612 with AEAD_V, K_2, and IV_2. 614 * COSE_Sign1 is verified as defined in section 4.4 of [RFC8152], 615 using algorithm SIG_V and the public key of Party V. 617 If any verification step fails, Party U MUST send an EDHOC error 618 message back, formatted as defined in Section 6.1, and the protocol 619 MUST be discontinued. 621 o Pass APP_2 to the application. 623 4.4. EDHOC Message 3 625 4.4.1. Formatting of Message 3 627 message_3 SHALL be a CBOR array as defined below 629 message_3 = [ 630 data_3, 631 COSE_ENC_3 : COSE_Encrypt0 632 ] 634 data_3 = ( 635 MSG_TYPE : int, 636 S_V : bstr 637 ) 639 aad_3 : bstr 641 where aad_3, in non-CDDL notation, is: 643 aad_3 = H( H( message_1 | message_2 ) | [ data_3 ] ) 645 where: 647 o MSG_TYPE = 3 649 o COSE_ENC_3 has the following fields and values: 651 * external_aad = aad_3 653 * plaintext = [ COSE_SIG_U, ? APP_3 ] 655 o COSE_SIG_U is a COSE_Sign1 object with the following fields and 656 values: 658 * protected = { abc : ID_U, ? xyz : HINT_ID_U } 660 * detached payload = aad_3, ? APP_3 662 o abc - any COSE map label that can identify a public key, see 663 Section 4.1 665 o ID_U - identifier for the public key of Party U 667 o xyz - any COSE map label for information about how to retrieve the 668 credential of Party U, see Section 4.1 670 o HINT_ID_V - information about how to retrieve the credential of 671 Party U 673 o APP_3 - bstr containing opaque application data 675 4.4.2. Party U Processing of Message 3 677 Party U SHALL compose message_3 as follows: 679 o Format message_3 as specified in Section 4.4.1: 681 * COSE_Sign1 is computed as defined in section 4.4 of [RFC8152], 682 using algorithm SIG_U and the private key of Party U. 684 * COSE_Encrypt0 is computed as defined in section 5.3 of 685 [RFC8152], with AEAD_V, K_3, and IV_3. The AEAD algorithm MUST 686 NOT be replaced by plain encryption, see Section 8. 688 4.4.3. Party V Processing of Message 3 690 Party V SHALL process message_3 as follows: 692 o Use the session identifier S_V to retrieve the protocol state. 694 o Verify message_3 as specified in Section 4.4.1: 696 * COSE_Encrypt0 is decrypted as defined in section 5.3 of 697 [RFC8152], with AEAD_V, K_3, and IV_3. 699 * COSE_Sign1 is verified as defined in section 4.4 of [RFC8152], 700 using algorithm SIG_U and the public key of Party U. 702 If any verification step fails, Party V MUST send an EDHOC error 703 message back, formatted as defined in Section 6.1, and the protocol 704 MUST be discontinued. 706 o Pass APP_3 to the application. 708 5. EDHOC Authenticated with Symmetric Keys 710 5.1. Overview 712 EDHOC supports authentication with pre-shared keys. Party U and V 713 are assumed to have a pre-shared uniformly random key (PSK) with the 714 requirement that: 716 o Party V SHALL be able to identify the PSK using KID. 718 KID may optionally contain information about how to retrieve the PSK. 720 EDHOC with symmetric key authentication is illustrated in Figure 4. 722 Party U Party V 723 | S_U, N_U, E_U, ALG_1, KID, APP_1 | 724 +------------------------------------------------------------------>| 725 | message_1 | 726 | | 727 | S_U, S_V, N_V, E_V, ALG_2, Enc(K_2; APP_2; aad_2) | 728 |<------------------------------------------------------------------+ 729 | message_2 | 730 | | 731 | S_V, Enc(K_3; APP_3; aad_3) | 732 +------------------------------------------------------------------>| 733 | message_3 | 735 Figure 4: EDHOC with symmetric key authentication. 737 5.1.1. Mandatory to Implement Algorithms 739 For EDHOC authenticated with symmetric keys, the COSE algorithms 740 ECDH-SS + HKDF-256 and AES-CCM-64-64-128 are mandatory to implement. 742 5.2. EDHOC Message 1 744 5.2.1. Formatting of Message 1 746 message_1 SHALL be a CBOR array as defined below 747 message_1 = [ 748 data_1 749 ] 751 data_1 = ( 752 MSG_TYPE : int, 753 S_U : bstr, 754 N_U : bstr, 755 E_U : serialized_COSE_Key, 756 ECDH-Curves_U : alg_array, 757 HKDFs_U : alg_array, 758 AEADs_U : alg_array, 759 KID : bstr, 760 ? APP_1 : bstr 761 ) 763 serialized_COSE_Key = bstr .cbor COSE_Key 765 alg_array = [ + alg : int / tstr ] 767 where: 769 o MSG_TYPE = 4 771 o S_U - variable length session identifier 773 o N_U - 64-bit random nonce 775 o E_U - the ephemeral public key of Party U 777 o ECDH-Curves_U - EC curves for ECDH which Party U supports, in the 778 order of decreasing preference 780 o HKDFs_U - supported ECDH-SS w/ HKDF algorithms 782 o AEADs_U - supported AEAD algorithms 784 o KID - identifier of the pre-shared key 786 o APP_1 - bstr containing opaque application data 788 5.2.2. Party U Processing of Message 1 790 Party U SHALL compose message_1 as follows: 792 o Determine which ECDH curve to use with Party V. If U previously 793 received from Party V an error message to message_1 with 794 diagnostic payload identifying an ECDH curve in ECDH-Curves_U, 795 then U SHALL retrieve an ephemeral from that curve. Otherwise the 796 first curve in ECDH-Curves_U MUST be used. 798 o Retrieve an ephemeral ECDH key pair generated as specified in 799 Section 5 of [SP-800-56a] and format the ephemeral public key E_U 800 as a COSE_key as specified in Section 3.1. 802 o Generate the pseudo-random nonce N_U. 804 o Choose a session identifier S_U which is not in use and store it 805 for the length of the protocol. The session identifier SHOULD be 806 different from other relevant concurrent session identifiers used 807 by Party U. The session identifier MAY be used with the protocol 808 for which EDHOC establishes traffic keys/master secret, in which 809 case S_U SHALL be different from the concurrently used session 810 identifiers of that protocol. 812 o Format message_1 as specified in Section 5.2.1. 814 5.2.3. Party V Processing of Message 1 816 Party V SHALL process message_1 as follows: 818 o Verify (OPTIONAL) that N_U has not been received before. 820 o Verify that at least one of each kind of the proposed algorithms 821 are supported. 823 o Verify that the ECDH curve used in E_U is supported, and that no 824 prior curve in ECDH-Curves_U is supported. 826 o For elliptic curves, validate that E_U is a valid point by 827 verifying that there is a solution to the curve definition for the 828 given parameter 'x'. 830 If any verification step fails, Party V MUST send an EDHOC error 831 message back, formatted as defined in Section 6.1, and the protocol 832 MUST be discontinued. If V does not support the ECDH curve used in 833 E_U, but supports another ECDH curves in ECDH-Curves_U, then the 834 error message SHOULD include a diagnostic payload describing the 835 first supported ECDH curve in ECDH-Curves_U. 837 o Pass APP_1 to the application. 839 5.3. EDHOC Message 2 841 5.3.1. Formatting of Message 2 843 message_2 SHALL be a CBOR array as defined below 845 message_2 = [ 846 data_2, 847 COSE_ENC_2 : COSE_Encrypt0 848 ] 850 data_2 = ( 851 MSG_TYPE : int, 852 S_U : bstr, 853 S_V : bstr, 854 N_V : bstr, 855 E_V : serialized_COSE_Key, 856 HKDF_V : int / tstr, 857 AEAD_V : int / tstr 858 ) 860 aad_2 : bstr 862 where aad_2, in non-CDDL notation, is: 864 aad_2 = H( message_1 | [ data_2 ] ) 866 where: 868 o MSG_TYPE = 5 870 o S_V - variable length session identifier 872 o N_V - 64-bit random nonce 874 o E_V - the ephemeral public key of Party V 876 o HKDF_V - an single chosen algorithm from HKDFs_U 878 o AEAD_V - an single chosen algorithm from AEADs_U 880 o COSE_ENC_2 has the following fields and values: 882 * external_aad = aad_2 884 * plaintext = ? APP_2 886 o APP_2 - bstr containing opaque application data 887 o H() - the hash function in HKDF_V 889 5.3.2. Party V Processing of Message 2 891 Party V SHALL compose message_2 as follows: 893 o Retrieve an ephemeral ECDH key pair generated as specified in 894 Section 5 of [SP-800-56a] using same curve as used in E_U. Format 895 the ephemeral public key E_V as a COSE_key as specified in 896 Section 3.1. 898 o Generate the pseudo-random nonce N_V. 900 o Choose a session identifier S_V which is not in use and store it 901 for the length of the protocol. The session identifier SHOULD be 902 different from other relevant concurrent session identifiers used 903 by Party V. The session identifier MAY be used with the protocol 904 for which EDHOC establishes traffic keys/master secret, in which 905 case S_V SHALL be different from the concurrently used session 906 identifiers of that protocol. 908 o Select HKDF_V and AEAD_V from the algorithms proposed in HKDFs_U 909 and AEADs_U. 911 o Format message_2 as specified in Section 5.3.1 where COSE_Encrypt0 912 is computed as defined in section 5.3 of [RFC8152], with AEAD_V, 913 K_2, and IV_2. 915 5.3.3. Party U Processing of Message 2 917 Party U SHALL process message_2 as follows: 919 o Use the session identifier S_U to retrieve the protocol state. 921 o For elliptic curves, validate that E_V is a valid point by 922 verifying that there is a solution to the curve definition for the 923 given parameter 'x'. 925 o Verify message_2 as specified in Section 5.3.1 where COSE_Encrypt0 926 is decrypted defined in section 5.3 of [RFC8152], with AEAD_V, 927 K_2, and IV_2. 929 If any verification step fails, Party U MUST send an EDHOC error 930 message back, formatted as defined in Section 6.1, and the protocol 931 MUST be discontinued. 933 o Pass APP_2 to the application. 935 5.4. EDHOC Message 3 937 5.4.1. Formatting of Message 3 939 message_3 SHALL be a CBOR array as defined below 941 message_3 = [ 942 data_3, 943 COSE_ENC_3 : COSE_Encrypt0 944 ] 946 data_3 = ( 947 MSG_TYPE : int, 948 S_V : bstr 949 ) 951 aad_3 : bstr 953 where aad_3, in non-CDDL notation, is: 955 aad_3 = H( H( message_1 | message_2 ) | [ data_3 ] ) 957 where: 959 o MSG_TYPE = 6 961 o COSE_ENC_3 has the following fields and values: 963 * external_aad = aad_3 965 * plaintext = ? APP_3 967 o APP_3 - bstr containing opaque application data 969 5.4.2. Party U Processing of Message 3 971 Party U SHALL compose message_3 as follows: 973 o Format message_3 as specified in Section 5.4.1 where COSE_Encrypt0 974 is computed as defined in section 5.3 of [RFC8152], with AEAD_V, 975 K_3, and IV_3. 977 5.4.3. Party V Processing of Message 3 979 Party V SHALL process message_3 as follows: 981 o Use the session identifier S_V to retrieve the protocol state. 983 o Verify message_3 as specified in Section 5.4.1 where COSE_Encrypt0 984 is decrypted and verified as defined in section 5.3 of [RFC8152], 985 with AEAD_V, K_3, and IV_3. 987 If any verification step fails, Party V MUST send an EDHOC error 988 message back, formatted as defined in Section 6.1, and the protocol 989 MUST be discontinued. 991 o Pass APP_3 to the application. 993 6. Error Handling 995 6.1. Error Message Format 997 This section defines a message format for an EDHOC error message, 998 used during the protocol. This is an error on EDHOC level and is 999 independent of the lower layers used. An advantage of using such a 1000 construction is to avoid issues created by usage of cross protocol 1001 proxies (e.g. UDP to TCP). 1003 error SHALL be a CBOR array as defined below 1005 error = [ 1006 MSG_TYPE : int, 1007 ? ERR_MSG : tstr 1008 ] 1010 where: 1012 o MSG_TYPE = 0 1014 o ERR_MSG is an optional text string containing the diagnostic 1015 payload, defined in the same way as in Section 5.5.2 of [RFC7252]. 1017 7. IANA Considerations 1019 7.1. The Well-Known URI Registry 1021 IANA has added the well-known URI 'edhoc' in the Well-Known URIs 1022 registry. 1024 URI suffix: edhoc 1026 Change controller: IETF 1028 Specification document(s): [[this document]] 1030 Related information: None 1032 7.2. Media Types Registry 1034 IANA has added the media type 'application/edhoc' to the Media Types 1035 registry: 1037 Type name: application 1039 Subtype name: edhoc 1041 Required parameters: N/A 1043 Optional parameters: N/A 1045 Encoding considerations: binary 1047 Security considerations: See Section 7 of this document. 1049 Interoperability considerations: N/A 1051 Published specification: [[this document]] (this document) 1053 Applications that use this media type: To be identified 1055 Fragment identifier considerations: N/A 1057 Additional information: 1059 * Magic number(s): N/A 1061 * File extension(s): N/A 1063 * Macintosh file type code(s): N/A 1065 Person & email address to contact for further information: 1066 Goeran Selander 1068 Intended usage: COMMON 1070 Restrictions on usage: N/A 1072 Author: Goeran Selander 1074 Change Controller: IESG 1076 8. Security Considerations 1078 EDHOC builds on the SIGMA-I family of theoretical protocols that 1079 provides perfect forward secrecy and identity protection with a 1080 minimal number of messages. The encryption algorithm of the SIGMA-I 1081 protocol provides identity protection, but the security of the 1082 protocol requires the MAC to cover the identity of the signer. Hence 1083 the message authenticating functionality of the authenticated 1084 encryption in EDHOC is critical: authenticated encryption MUST NOT be 1085 replaced by plain encryption only, even if authentication is provided 1086 at another level or through a different mechanism. 1088 EDHOC adds an explicit message type and expands the message 1089 authentication coverage to additional elements such as algorithms, 1090 application data, and previous messages. EDHOC uses the same Sign- 1091 then-MAC approach as TLS 1.3. 1093 EDHOC does not include negotiation of parameters related to the 1094 ephemeral key, but it enables Party V to verify that the ECDH curve 1095 used in the protocol is the most preferred curve by U which is 1096 supported by both U and V. 1098 Party U and V must make sure that unprotected data and metadata do 1099 not reveal any sensitive information. This also applies for 1100 encrypted data sent to an unauthenticated party. In particular, it 1101 applies to APP_1 and APP_2 in the asymmetric case, and APP_1 and KID 1102 in the symmetric case. The communicating parties may therefore 1103 anonymize KID. 1105 Using the same KID or unprotected application data in several EDHOC 1106 sessions allows passive eavesdroppers to correlate the different 1107 sessions. Another consideration is that the list of supported 1108 algorithms may be used to identify the application. 1110 Party U and V are allowed to select the session identifiers S_U and 1111 S_V, respectively, for the other party to use in the ongoing EDHOC 1112 protocol as well as in a subsequent traffic protection protocol (e.g. 1113 OSCORE [I-D.ietf-core-object-security]). The choice of session 1114 identifier is not security critical but intended to simplify the 1115 retrieval of the right security context in combination with using 1116 short identifiers. If the wrong session identifier of the other 1117 party is used in a protocol message it will result in the receiving 1118 party not being able to retrieve a security context (which will 1119 terminate the protocol) or retrieving the wrong security context 1120 (which also terminates the protocol as the message cannot be 1121 verified). 1123 Party U and V must make sure that unprotected data does not trigger 1124 any harmful actions. In particular, this applies to APP_1 in the 1125 asymmetric case, and APP_1 and KID in the symmetric case. Party V 1126 should be aware that replays of EDHOC message_1 cannot be detected 1127 unless previous nonces are stored. 1129 The availability of a secure pseudorandom number generator and truly 1130 random seeds are essential for the security of EDHOC. If no true 1131 random number generator is available, a truly random seed must be 1132 provided from an external source. If ECDSA is supported, 1133 "deterministic ECDSA" as specified in RFC6979 is RECOMMENDED. 1135 Nonces MUST NOT be reused, both parties MUST generate fresh random 1136 nonces. 1138 Ephemeral keys SHOULD NOT be reused, both parties SHOULD generate 1139 fresh random ephemeral key pairs. Party V MAY reuse the ephemeral 1140 key to limit the effect of certain DoS attacks. For example, to 1141 reduce processing costs in the case of repeated uncompleted protocol 1142 runs, party V MAY pre-compute its ephemeral key E_V and reuse it for 1143 a small number of concurrent EDHOC executions, for example until a 1144 number of EDHOC protocol instances has been successfully completed, 1145 which triggers party V to pre-compute a new ephemeral key E_V to use 1146 with subsequent protocol runs. 1148 The referenced processing instructions in [SP-800-56a] must be 1149 complied with, including deleting the intermediate computed values 1150 along with any ephemeral ECDH secrets after the key derivation is 1151 completed. 1153 Party U and V are responsible for verifying the integrity of 1154 certificates. The selection of trusted CAs should be done very 1155 carefully and certificate revocation should be supported. 1157 The choice of key length used in the different algorithms needs to be 1158 harmonized, so that a sufficient security level is maintained for 1159 certificates, EDHOC, and the protection of application data. Party U 1160 and V should enforce a minimum security level. 1162 Note that, depending on the application, the keys established through 1163 the EDHOC protocol will need to be renewed, in which case the 1164 communicating parties need to run the protocol again. 1166 Implementations should provide countermeasures to side-channel 1167 attacks such as timing attacks. 1169 9. Acknowledgments 1171 The authors want to thank Dan Harkins, Ilari Liusvaara, Jim Schaad 1172 and Ludwig Seitz for reviewing intermediate versions of the draft and 1173 contributing concrete proposals incorporated in this version. We are 1174 especially indebted to Jim Schaad for his continuous reviewing and 1175 implementation of different versions of the draft. 1177 TODO: This section should be after Appendices and before Authors' 1178 addresses according to RFC7322. 1180 10. References 1182 10.1. Normative References 1184 [I-D.schaad-cose-x509] 1185 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1186 Headers for carrying and referencing X.509 certificates", 1187 draft-schaad-cose-x509-01 (work in progress), May 2017. 1189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1190 Requirement Levels", BCP 14, RFC 2119, 1191 DOI 10.17487/RFC2119, March 1997, 1192 . 1194 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1195 Curve Cryptography Algorithms", RFC 6090, 1196 DOI 10.17487/RFC6090, February 2011, 1197 . 1199 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1200 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1201 October 2013, . 1203 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1204 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1205 . 1207 [SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to 1208 Authenticated Diffie-Hellman and Its Use in the IKE- 1209 Protocols (Long version)", June 2003, 1210 . 1212 [SP-800-56a] 1213 Barker, E., Chen, L., Roginsky, A., and M. Smid, 1214 "Recommendation for Pair-Wise Key Establishment Schemes 1215 Using Discrete Logarithm Cryptography", NIST Special 1216 Publication 800-56A Revision 2, May 2013, 1217 . 1219 10.2. Informative References 1221 [I-D.hartke-core-e2e-security-reqs] 1222 Selander, G., Palombini, F., and K. Hartke, "Requirements 1223 for CoAP End-To-End Security", draft-hartke-core-e2e- 1224 security-reqs-03 (work in progress), July 2017. 1226 [I-D.ietf-ace-oauth-authz] 1227 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1228 H. Tschofenig, "Authentication and Authorization for 1229 Constrained Environments (ACE)", draft-ietf-ace-oauth- 1230 authz-10 (work in progress), February 2018. 1232 [I-D.ietf-ace-oscore-profile] 1233 Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE 1234 profile of the Authentication and Authorization for 1235 Constrained Environments Framework", draft-ietf-ace- 1236 oscore-profile-00 (work in progress), December 2017. 1238 [I-D.ietf-cbor-cddl] 1239 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1240 definition language (CDDL): a notational convention to 1241 express CBOR data structures", draft-ietf-cbor-cddl-02 1242 (work in progress), February 2018. 1244 [I-D.ietf-core-object-security] 1245 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1246 "Object Security for Constrained RESTful Environments 1247 (OSCORE)", draft-ietf-core-object-security-08 (work in 1248 progress), January 2018. 1250 [I-D.ietf-core-resource-directory] 1251 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1252 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1253 resource-directory-12 (work in progress), October 2017. 1255 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1256 Key Derivation Function (HKDF)", RFC 5869, 1257 DOI 10.17487/RFC5869, May 2010, 1258 . 1260 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1261 Constrained-Node Networks", RFC 7228, 1262 DOI 10.17487/RFC7228, May 2014, 1263 . 1265 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1266 Application Protocol (CoAP)", RFC 7252, 1267 DOI 10.17487/RFC7252, June 2014, 1268 . 1270 Appendix A. Test Vectors 1272 TODO: This section needs to be updated. 1274 Appendix B. PSK Chaining 1276 An application using EDHOC with symmetric keys may have a security 1277 policy to change the PSK as a result of successfully completing the 1278 EDHOC protocol. In this case, the old PSK SHALL be replaced with a 1279 new PSK derived using other = exchange_hash, AlgorithmID = "EDHOC PSK 1280 Chaining" and keyDataLength equal to the key length of AEAD_V, see 1281 Section 3.2. 1283 Appendix C. EDHOC with CoAP and OSCORE 1285 C.1. Transferring EDHOC in CoAP 1287 EDHOC can be transferred as an exchange of CoAP [RFC7252] messages, 1288 with the CoAP client as party U and the CoAP server as party V. By 1289 default EDHOC is sent to the Uri-Path: "/.well-known/edhoc", but an 1290 application may define its own path that can be discovered e.g. using 1291 resource directory [I-D.ietf-core-resource-directory]. 1293 In practice, EDHOC message_1 is sent in the payload of a POST request 1294 from the client to the server's resource for EDHOC. EDHOC message_2 1295 or the EDHOC error message is sent from the server to the client in 1296 the payload of a 2.04 Changed response. EDHOC message_3 or the EDHOC 1297 error message is sent from the client to the server's resource in the 1298 payload of a POST request. If needed, an EDHOC error message is sent 1299 from the server to the client in the payload of a 2.04 Changed 1300 response 1302 An example of successful EDHOC exchange using CoAP is shown in 1303 Figure 5. 1305 Client Server 1306 | | 1307 +--------->| Header: POST (Code=0.02) 1308 | POST | Uri-Path: "/.well-known/edhoc" 1309 | | Content-Type: application/edhoc 1310 | | Payload: EDHOC message_1 1311 | | 1312 |<---------+ Header: 2.04 Changed 1313 | 2.04 | Content-Type: application/edhoc 1314 | | Payload: EDHOC message_2 1315 | | 1316 +--------->| Header: POST (Code=0.02) 1317 | POST | Uri-Path: "/.well-known/edhoc" 1318 | | Content-Type: application/edhoc 1319 | | Payload: EDHOC message_3 1320 | | 1321 |<---------+ Header: 2.04 Changed 1322 | 2.04 | 1323 | | 1325 Figure 5: Transferring EDHOC in CoAP 1327 C.2. Deriving an OSCORE context from EDHOC 1329 When EDHOC is use to derive parameters for OSCORE 1330 [I-D.ietf-core-object-security], the parties must make sure that the 1331 EDHOC session identifiers are unique Recipient IDs in OSCORE. In 1332 case that the CoAP client is party U and the CoAP server is party V: 1334 o The AEAD Algorithm is AEAD_V, as defined in this document 1336 o The Key Derivation Function (KDF) is HKDF_V, as defined in this 1337 document 1339 o The Client's Sender ID is S_V, as defined in this document 1341 o The Server's Sender ID is S_U, as defined in this document 1343 o The Master Secret is derived as specified in Section 3.2 of this 1344 document, with other = exchange_hash, AlgorithmID = "EDHOC OSCORE 1345 Master Secret" and keyDataLength equal to the key length of 1346 AEAD_V. 1348 o The Master Salt is derived as specified in Section 3.2 of this 1349 document, with other = exchange_hash, AlgorithmID = "EDHOC OSCORE 1350 Master Salt" and keyDataLength equal to 64 bits. 1352 Authors' Addresses 1354 Goeran Selander 1355 Ericsson AB 1357 Email: goran.selander@ericsson.com 1359 John Mattsson 1360 Ericsson AB 1362 Email: john.mattsson@ericsson.com 1364 Francesca Palombini 1365 Ericsson AB 1367 Email: francesca.palombini@ericsson.com