idnits 2.17.1 draft-selander-ace-cose-ecdhe-02.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 (July 07, 2016) is 2840 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 (-24) exists of draft-ietf-cose-msg-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'SP-800-56a' == Outdated reference: A later version (-03) exists of draft-hartke-core-e2e-security-reqs-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-02 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) Summary: 0 errors (**), 0 flaws (~~), 4 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: January 8, 2017 Ericsson AB 6 July 07, 2016 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-selander-ace-cose-ecdhe-02 11 Abstract 13 This document specifies authenticated Diffie-Hellman key exchange 14 with ephemeral keys, embedded in messages encoded with the CBOR 15 Object Signing and Encryption (COSE) format. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 8, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Authentication methods . . . . . . . . . . . . . . . . . 6 55 3. Message formatting using COSE . . . . . . . . . . . . . . . . 7 56 3.1. ECDH Public Keys using COSE_Key . . . . . . . . . . . . . 7 57 3.2. Payload 1 formatting . . . . . . . . . . . . . . . . . . 7 58 3.3. Payload 2 formatting . . . . . . . . . . . . . . . . . . 8 59 3.4. Message Formatting with Symmetric Keys . . . . . . . . . 8 60 3.4.1. Message 1 with PSK . . . . . . . . . . . . . . . . . 8 61 3.4.2. Message 2 with PSK . . . . . . . . . . . . . . . . . 9 62 3.4.3. KDF Context with Symmetric Keys . . . . . . . . . . . 9 63 3.5. Message Formatting with Asymmetric Keys . . . . . . . . . 10 64 3.5.1. Message 1 with RPK . . . . . . . . . . . . . . . . . 10 65 3.5.2. Message 2 with RPK . . . . . . . . . . . . . . . . . 10 66 3.5.3. Message 1 with Cert . . . . . . . . . . . . . . . . . 11 67 3.5.4. Message 2 with Cert . . . . . . . . . . . . . . . . . 11 68 3.5.5. KDF Context with Asymmetric Keys . . . . . . . . . . 12 69 4. Message Processing . . . . . . . . . . . . . . . . . . . . . 12 70 4.1. U -> message_1 . . . . . . . . . . . . . . . . . . . . . 12 71 4.2. message_1 -> V . . . . . . . . . . . . . . . . . . . . . 13 72 4.3. message_2 <- V . . . . . . . . . . . . . . . . . . . . . 14 73 4.4. U <- message_2 . . . . . . . . . . . . . . . . . . . . . 14 74 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 15 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 81 10.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 83 A.1. ECDH Public Key . . . . . . . . . . . . . . . . . . . . . 18 84 A.2. Payload 1 . . . . . . . . . . . . . . . . . . . . . . . . 19 85 A.3. Payload 2 . . . . . . . . . . . . . . . . . . . . . . . . 19 86 A.4. Message 1 with PSK . . . . . . . . . . . . . . . . . . . 20 87 A.5. Message 2 with PSK . . . . . . . . . . . . . . . . . . . 21 88 A.6. Message 1 with RPK . . . . . . . . . . . . . . . . . . . 21 89 A.7. Message 2 with RPK . . . . . . . . . . . . . . . . . . . 22 90 A.8. Message 1 with Cert . . . . . . . . . . . . . . . . . . . 23 91 A.9. Message 2 with Cert . . . . . . . . . . . . . . . . . . . 24 92 Appendix B. Implementing EDHOC with CoAP . . . . . . . . . . . . 25 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 95 1. Introduction 97 Security at the application layer provides an attractive option for 98 protecting Internet of Things (IoT) deployments, for example where 99 transport layer security is not sufficient 100 [I-D.hartke-core-e2e-security-reqs]. IoT devices may be constrained 101 in various ways, including memory, storage, processing capacity, and 102 energy [RFC7228]. A method for protecting individual messages at 103 application layer, suitable for constrained devices, is provided by 104 COSE [I-D.ietf-cose-msg]). 106 In order for a communication session to provide forward secrecy, the 107 communicating parties can run a Diffie-Hellman (DH) key exchange 108 protocol with ephemeral keys, from which shared key material can be 109 derived. This document specifies authenticated DH protocols using 110 COSE objects for integrity protecting the transport of ephemeral 111 public keys. The DH key exchange messages may be authenticated using 112 either pre-shared keys, raw public keys or X.509 certificates. 113 Authentication is based on credentials established out of band, or 114 from a trusted third party, such as an Authorization Server as 115 specified by [I-D.ietf-ace-oauth-authz]. This document also 116 specifies the derivation of the shared key material. 118 The DH exchange and the key derivation follow [SP-800-56a] and HKDF 119 [RFC5869], and make use of the data structures of COSE which are 120 aligned with these standards. 122 1.1. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. These 127 words may also appear in this document in lowercase, absent their 128 normative meanings. 130 The parties exchanging messages are called "party U" and "party V", 131 and the ECDH ephemeral public keys of U and V are denoted "E_U" and 132 "E_V", respectively, see Figure 2. The messages in the authenticated 133 message exchange are called "message_1" and "message_2", see 134 Figure 3. 136 The keys used to authenticate the key exchange are either symmetric 137 or asymmetric. In case of symmetric, the pre-shared key is denoted 138 "PSK". In case of asymmetric, the public keys of U and V are denoted 139 "S_U" and "S_V", respectively. 141 Most keys used in this document have an associated identifier. The 142 identifiers used in the document are placeholders for values of the 143 identifiers. The following key identifiers/value representations are 144 used in the draft: 146 o kid_eu and kid_ev represent the values of the key identifiers of 147 the ephemeral public keys of U and V, respectively. 149 * kid_eu is a sequence number used for replay protection of 150 message_1. 152 * kid_ev is used to identify the resulting traffic key, as a 153 means for party V to ensure that different U establishing 154 traffic keys using this method have different identifiers. 156 o kid_psk represents the value of the key identifier of the pre- 157 shared key between U and V (Section 3.4). 159 o kid_su and kid_sv represent the values of the key identifiers of 160 the static public keys of U and V, respectively (Section 3.5). 162 The key notation is summarized in Figure 1. 164 +------------+-----+---------------------------------------------+ 165 | Key | Key | Use | 166 | Identifier | | | 167 +------------+-----+---------------------------------------------+ 168 | kid_eu | E_U | ECDH ephemeral public key of U | 169 | kid_ev | E_V | ECDH ephemeral public key of V | 170 | kid_psk | PSK | Pre-shared static symmetric key (Section 3) | 171 | kid_su | S_U | Static public key of U (Section 4) | 172 | kid_sv | S_V | Static public key of V (Section 4) | 173 +------------+-----+---------------------------------------------+ 175 Figure 1: Notation of keys and key identifiers. 177 2. Protocol Overview 179 EDHOC is a 2-pass message exchange of COSE objects. This section 180 gives an overview of the protocol, together with section Section 4, 181 which explains how the messages are processed, while section 182 Section 3 focuses on the detailed message formats embedded as COSE 183 objects. 185 The underlying scheme is the Elliptic Curve Cofactor Diffie-Hellman 186 with two ephemeral keys as specified in Section 6.1.2.2 of 187 [SP-800-56a], see Figure 2. U and V exchange their ephemeral public 188 keys E_U, E_V, computes the shared secret and derives the keying 189 material as described in [SP-800-56a]. 191 Party U Party V 192 | | 193 | E_U | 194 +---------------------->| 195 | | 196 | E_V | 197 |<----------------------+ 198 | | 199 Shared | | Shared 200 Secret Secret 201 | | 202 | Key Derivation | Key Derivation 203 V V 204 Derived Keying Material Derived Keying Material 206 Figure 2: Diffie-Hellman key exchange and key derivation 208 EDHOC makes the following additions to this scheme (see Figure 3): 210 o Negotiation of hash function used with HKDF in the key derivation: 212 * U proposes one or more hash functions (expressed as HKDF(s) 213 with different hash algorithms). 215 * V decides and responds with one function (expressed as HKDF 216 with a particular hash algorithm). 218 o Optional nonces (N_U, N_V) contributing to the salt used in the 219 extract phase of HKDF [RFC5869]. 221 o Negotiation of subsequent traffic crypto algorithm (TCA) to be 222 used between party U and V: 224 * U proposes one or more algorithms (TCA(s)). 226 * V decides and responds with one algorithm (TCA). 228 o Authentication, integrity and replay protection of protocol 229 messages 231 * Authentication and integrity protection using the COSE format 232 [I-D.ietf-cose-msg]. 234 + The MAC/Signature is calculated over the message as defined 235 by COSE. 237 + Information about keys, message protection algorithm and 238 replay parameter is included in the COSE Header, as 239 specified in the sections below. 241 * Authentication may be based on pre-shared keys, raw public keys 242 or X.509 certificates. In the latter case the message contains 243 the public key certificate of the sending endpoints (Cert_U, 244 Cert_V). 246 The key exchange messages are called "message_1" and "message_2", see 247 Figure 3. 249 Party U Party V 250 | | 251 | Header, HKDF(s), ?N_U, TCA(s), E_U, MAC/Signature, ?Cert_U | 252 +--------------------------------------------------------------> | 253 | message_1 | 254 | | 255 | Header, HKDF, ?N_V, TCA, E_V, MAC/Signature, ?Cert_V | 256 | <--------------------------------------------------------------+ 257 | message_2 | 258 | | 259 | Shared Shared | 260 Secret Secret 261 | | 262 | Key Derivation Key Derivation | 263 V V 264 traffic_secret_0 traffic_secret_0 266 Figure 3: EDHOC Overview. (Optionality indicated by '?'.) 268 2.1. Authentication methods 270 The EDHOC protocol messages are authenticated based on credentials 271 pre-established between U and V. The parties may have acquired such 272 a credential from the other party out of band or from a trusted third 273 party, such as an Authorization Server as specified in 274 [I-D.ietf-ace-oauth-authz]. The pre-established credentials are 275 either symmetric secret keys or public keys. The public keys may be 276 raw public keys (RPK), or public keys of a Certificate Authority (CA) 277 used as trust anchor for verification of received certificates. 279 o Pre-shared symmetric key (PSK). Each message contains a MAC over 280 the message generated by the sending party using PSK. 282 o Raw Public Keys (RPK). The pre-established credentials may be 283 static raw public keys of the other party (S_U and S_V, of party U 284 and V, respectively). Each message contain a signature over the 285 message generated by the sending party. 287 o X.509 Certificates (Cert). The pre-established credentials may 288 also be CA public keys, used to verify received public key 289 certificates. Each message contain the signature over the 290 message, excluding the certificate, generated by the sending 291 party. 293 3. Message formatting using COSE 295 This section details the format for the objects used. Examples are 296 provided for each object in Appendix A. 298 3.1. ECDH Public Keys using COSE_Key 300 This section defines the formatting of the ephemeral public keys E_U 301 and E_V. 303 The ECDH ephemeral public key SHALL be formatted as a COSE_Key with 304 the following fields and values (see [I-D.ietf-cose-msg]): 306 o kty: The value SHALL be 2 (Elliptic Curve Keys) 308 o kid: 310 o crv: The value of the Curve used. The value 1 SHALL be supported 311 by party V (NIST P-256 a.k.a. secp256r1 [RFC4492]) 313 o x: 315 o y: The value SHOULD be boolean. 317 TODO: Consider replacing P-256 with Curve25519 as mandatory 319 3.2. Payload 1 formatting 321 This section defines the formatting of the payload in message_1. 323 payload_1 is a CBOR array object containing: 325 o HKDFs: the set of proposed algorithms to indicate the key 326 derivation 328 o N_U: optional nonce for use in salt with HKDF 330 o TCAs: the set of proposed algorithms to use with the derived 331 secret 333 o E_U: the ephemeral public key (with 'kid' = kid_eu, which is a 334 sequence number) 336 payload_1 = [ 337 HKDFs : AlgID / [ + AlgID ], 338 N_U : nil / bstr, 339 TCAs : AlgID / [ + AlgID ], 340 E_U : COSE_Key 341 ] 343 AlgID : int / tstr 345 3.3. Payload 2 formatting 347 This section defines the formatting of the payload in message_2. 349 payload_2 is a CBOR array object containing: 351 o HKDF: the agreed key derivation algorithm 353 o N_V: optional nonce for use in salt with HKDF 355 o TCA: the agreed traffic crypto algorithm 357 o E_V: the ephemeral public key (with 'kid' = kid_ev) 359 payload_2 = [ 360 HKDF : int / tstr, 361 N_V : nil / bstr, 362 TCA : int / tstr, 363 E_V : COSE_Key 364 ] 366 3.4. Message Formatting with Symmetric Keys 368 Parties U and V are assumed to have a pre-shared key, PSK. The value 369 of the key identifier kid_psk SHALL be unique for U and V. 371 3.4.1. Message 1 with PSK 373 In case of PSK, message_1 SHALL have the COSE_Mac0_Tagged structure 374 [I-D.ietf-cose-msg] with the following fields and values: 376 o Header 378 * Protected 380 + Alg: 4 (HMAC 256/64) 381 + Kid: kid_psk 383 * Unprotected: Empty 385 o Payload: payload_1 as defined in Section 3.2 387 o MAC: As in section 6.3 of [I-D.ietf-cose-msg] 389 3.4.2. Message 2 with PSK 391 In case of PSK, message_2 SHALL have the COSE_Mac0_Tagged structure 392 [I-D.ietf-cose-msg] with the following fields and values: 394 o Header 396 * Protected 398 + Alg: 4 (HMAC 256/64) 400 + Kid: kid_psk 402 * Unprotected: empty 404 o Payload: payload_2 as defined in Section 3.3 406 o Tag: As in section 6.3 of [I-D.ietf-cose-msg], including the 407 external_aad in the MAC_structure. 409 The external authenticated data to use in the MAC_structure of 410 Section 6.3 of [I-D.ietf-cose-msg] is the MAC of message_1. 412 o external_aad: MAC 414 3.4.3. KDF Context with Symmetric Keys 416 The key derivation is specified in Section 5 using the following 417 context information COSE_KDF_Context for symmetric keys: 419 COSE_KDF_Context = [ 420 AlgorithmID : int / tstr, ; AlgID 421 SuppPubInfo : [ 422 keyDataLength : uint, ; length 423 protected : bstr, ; zero length bstr 424 other : bstr ; MAC message_1 || MAC message_2 425 ], 426 ] 428 3.5. Message Formatting with Asymmetric Keys 430 Parties U and V are assumed to have access to each other's public 431 key. 433 o Party U's public key, S_U, SHALL be uniquely identified at V by 434 kid_su. 436 o Party V's public key, S_V, SHALL be uniquely identified at U by 437 kid_sv. 439 3.5.1. Message 1 with RPK 441 In case of RPK message_1 SHALL have the COSE_Sign1_Tagged structure 442 [I-D.ietf-cose-msg], with the following fields and values: 444 o Header 446 * protected: 448 + alg: -7 (ECDSA 256) 450 + kid: kid_su 452 * unprotected: empty 454 o payload: payload_1 as defined in Section 3.2 456 o signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg} 458 3.5.2. Message 2 with RPK 460 In case of RPK, message_2 SHALL have the COSE_Sign1_Tagged structure 461 [I-D.ietf-cose-msg] with the following fields and values: 463 o Header 465 * Protected 467 + Alg: -7 (ECDSA 256) 469 + Kid: kid_sv 471 * Unprotected: empty 473 o payload: payload_2 as defined in Section 3.3 474 o signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg}, 475 including the external_aad in the Sig_structure. 477 The external authenticated data to use in the Sig_structure of 478 Section 4.4 of [I-D.ietf-cose-msg] is the signature in message_1. 480 o external_aad: signature 482 3.5.3. Message 1 with Cert 484 The case of Certificates is similar to RPK. message_1 SHALL have the 485 COSE_Sign1_Tagged structure [I-D.ietf-cose-msg], with the same fields 486 and values as Section 3.5.1 with the addition of the unprotected 487 header field "x5c" containing the X.509 certificate of S_U as a byte 488 string. 490 o Header 492 * protected: 494 + alg: -7 (ECDSA 256) 496 + kid: kid_su 498 * unprotected: 500 + x5c: bstr 502 o payload: payload_1 as defined in Section 3.2 504 o signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg} 506 3.5.4. Message 2 with Cert 508 message_2 is analogous to message_1. message_2 SHALL have the 509 COSE_Sign1_Tagged structure [I-D.ietf-cose-msg], with the same fields 510 and values as Section 3.5.2 and with the addition of the unprotected 511 header field "x5c" containing the X.509 certificate of S_V as a byte 512 string. 514 o Header 516 * Protected 518 + Alg: -7 (ECDSA 256) 520 + Kid: kid_sv 522 * Unprotected: 524 + x5c: bstr 526 o payload: payload_2 as defined in Section 3.3 528 o signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg}, 529 including the external_aad in the Sig_structure. 531 The external authenticated data to use in the Sig_structure of 532 Section 4.4 of [I-D.ietf-cose-msg] is the signature in message_1. 534 o external_aad: signature 536 3.5.5. KDF Context with Asymmetric Keys 538 The key derivation is specified in Section 5 using the following 539 context information COSE_KDF_Context for asymmetric keys: 541 COSE_KDF_Context = [ 542 AlgorithmID : int / tstr, ; AlgID 543 SuppPubInfo : [ 544 keyDataLength : uint, ; length 545 protected : bstr, ; zero length bstr 546 other : bstr ; signature of message_1 || 547 signature of message_2 548 ] 549 ] 551 4. Message Processing 553 Party U and V are assumed to have pre-established credentials as 554 described in Section 2.1. 556 4.1. U -> message_1 558 Party U processes message_1 for party V as follows: 560 o Party U SHALL generate a fresh ephemeral ECDH key pair as 561 specified in Section 5 of [SP-800-56a] using ECC domain parameters 562 of a curve complying with security policies for communicating with 563 party V. 565 o The ephemeral public key, E_U, SHALL be formatted as a COSE_key as 566 specified in Section 3.1. 568 o The key identifier kid_eu of the ephemeral public key E_U SHALL be 569 a sequence number initiated to 1 and increased by 1 for each 570 message_1 associated to a particular party V. 572 o Party U SHALL define the parameters and format payload_1 as 573 specified in Section 3.2 complying with the security policies for 574 communicating with party V. 576 o message_1 SHALL be formatted as a COSE message according to 577 [I-D.ietf-cose-msg] with parameters specified in Section 3.4.1 578 (PSK) , Section 3.5.1 (RPK) or Section 3.5.3 (Cert). Party U 579 SHALL cache the MAC/Signature value of the request. 581 o Party U sends message_1 to party V. 583 4.2. message_1 -> V 585 Party V processes the received message_1 as follows: 587 o If the message contains a certificate, party V SHALL verify the 588 certificate using the pre-established trust anchor and the 589 revocation verification policies relevant for party U. If the 590 verification fails the message is discarded. 592 o Party V SHALL verify that kid_eu is greater than a counter 593 tracking latest message associated with party U, identified with 594 the sending party key. (The counter is initialized to 0 at first 595 contact with party U.) If kid_eu is less than or equal than the 596 counter, the message is discarded. 598 o Party V SHALL verify the COSE message as specified in 599 [I-D.ietf-cose-msg] using the key associated to party U, 600 identified by the key identifier kid_psk/kid_su in the message 601 header, or in the verified received certificate. If the MAC/ 602 Signature of the received request can be verified, then the 603 counter associated to party U is updated with kid-eu, else the 604 message is discarded. 606 o Party V SHALL verify that the ECDH curve is compliant with its 607 security policy for communicating with U, or else respond with an 608 error. 610 o V SHALL select a preferred pair of (HKDF, TCA) out of those 611 proposed by U, compliant with the security policy relevant for 612 party U. If such a pair does not exist, V SHALL stop processing 613 the message and MAY respond with an error, indicating that no 614 common algorithm could be found. 616 4.3. message_2 <- V 618 Party V composes message_2 for party U as follows: 620 o Party V SHALL generate a fresh ephemeral ECDH key pair as 621 specified in Section 5 of [SP-800-56a] using same curve/ECC domain 622 parameters as used by party U. 624 o The ephemeral public key, E_V, SHALL be formatted as a COSE_key as 625 specified in Section 3.1. The key identifier kid_ev SHALL be 626 unique among key identifiers used for traffic keys by party V. 628 o Party SHALL define the parameters and format payload_2 as 629 specified in Section 3.3 complying with the security policies for 630 communicating with party V. 632 o message_2 SHALL be formatted as a COSE message according to 633 [I-D.ietf-cose-msg] with parameters specified in Section 3.4.2 634 (PSK) , Section 3.5.2 (RPK) or Section 3.5.4 (Cert) using the same 635 authentication scheme as in message_1. Note that the MAC/ 636 Signature value of the request is included as additional 637 authenticated data of the response. 639 Party V sends message_2 to party U. Then party V derives the 640 traffic_secret_0 key as specified Section 5, and labels it with 641 kid_ev. 643 4.4. U <- message_2 645 Party U processes the received message_2 as follows: 647 o If the message contains a certificate, party V SHALL verify the 648 certificate using the pre-established trust anchor and the 649 revocation verification policies relevant for party U. If the 650 verification fails the message is discarded. 652 o Party U SHALL verify the received COSE message as defined in 653 [I-D.ietf-cose-msg] using the key associated to the key identifier 654 (kid_psk/kid_su) in the message header, or in the verified 655 received certificate. Note the use of the cached MAC/Signature of 656 the request. If the COSE message cannot be verified, the message 657 is discarded. 659 o U SHALL verify that the received pair (HKDF, TCA) is one element 660 of those proposed in the request, else stop processing the 661 message. 663 o If the response is verified, U derives the traffic_secret_0 as 664 specified Section 5. 666 5. Key Derivation 668 The key derivation is identical to Section 11 of [I-D.ietf-cose-msg], 669 using HKDF [RFC5869] agreed during the message exchange. 671 o the secret SHALL be the ECDH shared secret as defined in 672 Section 12.4.1 of [I-D.ietf-cose-msg], where the computed secret 673 is specified in section 5.7.1.2 of [SP-800-56a] 675 o the salt SHALL be B1 XOR B2, where 677 * B1 = N_U || 00 .. 0, i.e. the nonce N_U, if present, appended 678 with padded zeros to the size of the hash function; or else 679 just an octet string of zeros 681 * B2 = 00... 0 || N_V, i.e. the nonce N_V, if present, prepended 682 with padded zeros to the size of the hash function; or else 683 just an octet string of zeros 685 * This corresponds to salt = N_U || N_V in the case of each party 686 contributing a nonce of half the size of the salt, but also 687 accommodates for nonces of different sizes. 689 o the length SHALL be the length of the key in TCA. 691 o the context information SHALL be the serialized COSE_KDF_Context 692 defined in the next paragraph. 694 o the PRF SHALL be the one indicated in HKDF using the Table 18 of 695 [I-D.ietf-cose-msg] (in our examples, -27 corresponds to HMAC with 696 SHA-256) 698 The context information COSE_KDF_Context is defined as follows: 700 o AlgorithmID SHALL be the algorithm for which the key material will 701 be derived. It's value is AlgID 703 o PartyUInfo SHALL be empty 705 o PartyVInfo SHALL be empty 707 o SuppPubInfo SHALL contain: 709 * KeyDataLength SHALL be equal to 'length' 710 * protected SHALL be a zero length bstr 712 * other SHALL be the concatenation of the MAC/Signature of 713 message_1 and the MAC/Signature of message_2 715 o SuppPrivInfo SHALL be empty 717 The tags are either MACs (PSK) or the Signatures (RPK, Cert) of the 718 COSE messages. 720 COSE\_KDF\_Context = [ 721 AlgorithmID : int / tstr, ; HKDF 722 SuppPubInfo : [ 723 keyDataLength : uint, ; length 724 protected : bstr, ; zero length bstr 725 other : bstr ; MAC/Signature message_1 726 || MAC/Signature message_2 727 ], 728 ] 730 The output from the key derivation is denoted "traffic_secret_0". 732 6. Security Considerations 734 For unauthenticated Diffie-Hellman it is recommended that public 735 information about parties U and V, such as their identifiers, is 736 included in the context information used in the key derivation. In 737 the present case the assumption is that the parties authenticate each 738 other with pre-established credentials, and the tag (MAC/Signature) 739 created with the pre-established credentials is included in the key 740 derivation context. 742 The referenced processing instructions in [SP-800-56a] must be 743 complied with, including deleting the intermediate computed values 744 along with any ephemeral ECDH secrets after the key derivation is 745 completed. 747 The choice of key length used in the different algorithms needs to be 748 harmonized, so that right security level is maintained throughout the 749 calculations. 751 The identifier of the ephemeral key of party U is used for replay 752 protection of U's requests. 754 With the current protocol, key confirmation of the Diffie-Hellman 755 shared secret/traffic keys is performed when the keys are 756 successfully used. The addition of key confirmation to the protocol 757 is for further study. 759 TODO: Expand on the security considerations in a future version of 760 the draft 762 7. Privacy Considerations 764 TODO 766 8. IANA Considerations 768 9. Acknowledgments 770 The authors wants to thank Ilari Liusvaara, Jim Schaad and Ludwig 771 Seitz for timely review and helpful comments. 773 10. References 775 10.1. Normative References 777 [I-D.ietf-cose-msg] 778 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 779 draft-ietf-cose-msg-14 (work in progress), June 2016. 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, 783 DOI 10.17487/RFC2119, March 1997, 784 . 786 [SP-800-56a] 787 Barker, E., Chen, L., Roginsky, A., and M. Smid, 788 "Recommendation for Pair-Wise Key Establishment Schemes 789 Using Discrete Logarithm Cryptography", NIST Special 790 Publication 800-56A, May 2013, 791 . 793 10.2. Informative References 795 [I-D.hartke-core-e2e-security-reqs] 796 Selander, G., Palombini, F., and K. Hartke, "Requirements 797 for CoAP End-To-End Security", draft-hartke-core-e2e- 798 security-reqs-01 (work in progress), July 2016. 800 [I-D.ietf-ace-oauth-authz] 801 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 802 H. Tschofenig, "Authentication and Authorization for 803 Constrained Environments (ACE)", draft-ietf-ace-oauth- 804 authz-02 (work in progress), June 2016. 806 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 807 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 808 for Transport Layer Security (TLS)", RFC 4492, 809 DOI 10.17487/RFC4492, May 2006, 810 . 812 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 813 Key Derivation Function (HKDF)", RFC 5869, 814 DOI 10.17487/RFC5869, May 2010, 815 . 817 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 818 Constrained-Node Networks", RFC 7228, 819 DOI 10.17487/RFC7228, May 2014, 820 . 822 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 823 Application Protocol (CoAP)", RFC 7252, 824 DOI 10.17487/RFC7252, June 2014, 825 . 827 Appendix A. Examples 829 A.1. ECDH Public Key 831 An example of COSE_Key structure, representing an ECDH public key, is 832 given in Figure 4, using CBOR's diagnostic notation. In this 833 example, the ephemeral key is identified by a 4 bytes 'kid'. 835 / ephemeral / -1:{ 836 / kty / 1:2, 837 / kid / 2:h'78f67901', 838 / crv / -1:1, 839 / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590b 840 bfbf054e1c7b4d91d6280', 841 / y / -3:true 842 } 844 Figure 4: Example of an ECDH public key formatted as a COSE_Key 846 The equivalent CBOR encoding is: h'a120a50102024478f67901200121582098 847 f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5', 848 which has a size of 51 bytes. 850 A.2. Payload 1 852 An example of COSE encoding for payload_1 is given in Figure 5, using 853 CBOR's diagnostic notation. In this example, the size of the 854 identifier of U's ephemeral key, kid_eu, is 1 byte. 856 The payload_1 is: 858 [ 859 -27, / HKDFs / 860 null, / N_U / 861 12, / TCAs / 862 h'a120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5a 863 d7590bbfbf054e1c7b4d91d628022f5' / COSE_Key E_U { / 864 / ephemeral -1:{ / 865 / kty 1:2, / 866 / kid 2:h'03', kid_eu / 867 / crv -1:1, / 868 / x -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb / 869 / f054e1c7b4d91d6280', / 870 / y -3:true / 871 / } / 872 / } / 873 ] 875 Figure 5: Example of payload of message_1 877 The equivalent CBOR encoding of the payload is: h'84381af60c582fa120a 878 50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf0 879 54e1c7b4d91d628022f5', which has a size of 54 bytes. 881 A.3. Payload 2 883 An example of COSE encoding for message_2 is given in Figure 6 using 884 CBOR's diagnostic notation. In this example, kid_ev, the identifier 885 of V's ephemeral public key, is 4 bytes. 887 The payload is: 889 [ 890 -27, / HKDF / 891 null, / N_V / 892 12, / TCA / 893 h'a120a5010202442edb61f92001215820acbee6672a28340affce41c721901eb 894 d7868231bd1d86e41888a07822214050022f5' / COSE_Key E_V { / 895 / ephemeral -1:{ / 896 / kty 1:2, / 897 / kid 2:h'2edb61f9', kid_ev / 898 / crv -1:1, / 899 / x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d / 900 / 86e41888a078222140500', / 901 / y -3:true / 902 / } / 903 / } / 904 ] 906 Figure 6: Example of payload of message_2 908 The equivalent CBOR encoding of the payload is: h'84381af60c5832a120a 909 5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1 910 d86e41888a07822214050022f5', which has a size of 57 bytes. 912 A.4. Message 1 with PSK 914 An example of COSE encoding for message_1 is given in Figure 7 using 915 CBOR's diagnostic notation. In this example, kid_psk, the identifier 916 of PSK is 4 bytes, and the payload is as in Appendix A.2. 918 The message_1 is: 920 996( 921 [ 922 / protected / h'a201040444e19648b5' / { / 923 / alg 1:4, HMAC 256//64 / 924 / kid 4:h'e19648b5' kid_psk / 925 / } / , 926 / unprotected / {}, 927 / payload / h'84381af60c582fa120a501020241032001215820 928 98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4 929 d91d628022f5', / payload_1 / 930 / tag / h'e77fe81c66c3b5c0' 931 ] 932 ) 934 Figure 7: Example of message_1 authenticated with PSK 936 The equivalent CBOR encoding is: h'd903e48449a201040444e19648b5a05836 937 84381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638e 938 a56c3f5ad7590bbfbf054e1c7b4d91d628022f548e77fe81c66c3b5c0', which has 939 a size of 80 bytes. 941 A.5. Message 2 with PSK 943 An example of COSE encoding for message_2 is given in Figure 8 using 944 CBOR's diagnostic notation. In this example, kid_psk, the identifier 945 of PSK, is 4 bytes, and the payload is as in Appendix A.3. 947 The message_2 is: 949 996( 950 [ 951 / protected / h'a201040444e19648b5' / { / 952 / alg 1:4, HMAC 256//64 / 953 / kid 4:h'e19648b5' kid_psk / 954 / } / , 955 / unprotected / {}, 956 / payload / h'84381af60c5832a120a5010202442edb61f92001215820 957 acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214 958 050022f5', / payload_2 / 959 / tag / h'6113268ad246f2c9' 960 ] 961 ) 963 Figure 8: Example of message_2 authenticated with PSK 965 The equivalent CBOR encoding is: h'd903e48449a201040444e19648b5a05839 966 84381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c 967 721901ebd7868231bd1d86e41888a07822214050022f5486113268ad246f2c9', 968 which has a size of 83 bytes. 970 A.6. Message 1 with RPK 972 An example of COSE encoding for message_1 is given in Figure 9, using 973 CBOR's diagnostic notation. In this example, the size of the 974 identifier of the static public key of U, kid_su, is 4 bytes, and the 975 payload is as in Appendix A.2. 977 The message_1 is: 979 997( 980 [ 981 / protected / h'a201260444c150d41c' / { / 982 / alg 1:-7, ECDSA 256 / 983 / kid 4:h'c150d41c', kid_c / 984 / } / , 985 / unprotected / {}, 986 / payload / h'84381af60c582fa120a501020241032001215820 987 98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4 988 d91d628022f5', / payload_1 / 989 / signature / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 990 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64 991 327be470355c9657ce0' 992 ] 993 ) 995 Figure 9: Example of message_1 authenticated with RPK 997 The equivalent CBOR encoding is: h'd903e58449a201260444c150d41ca05836 998 84381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638e 999 a56c3f5ad7590bbfbf054e1c7b4d91d628022f55840eae868ecc1276883766c5dc5ba 1000 5b8dca25dab3c2e56a51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f35 1001 06cd1a98a8fb64327be470355c9657ce0', which has a size of 137 bytes. 1003 A.7. Message 2 with RPK 1005 An example of COSE encoding for Message 2 is given in Figure 11, 1006 using CBOR's diagnostic notation. In this example, the size of the 1007 identifier of the public key of V, kid_sv, is 4 bytes, and the 1008 payload is as in Appendix A.3. 1010 The external_aad is the signature of message_1: 1012 / external\_aad / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 1013 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327 1014 be470355c9657ce0' 1016 Figure 10: Example of external additional authenticated data 1018 The message_2 is: 1020 997( 1021 [ 1022 / protected / h'a2012604447a2af164' / { / 1023 / alg 1:-7, ECDSA 256 / 1024 / kid 4:h'7a2af164', kid_sv / 1025 / } / , 1026 / unprotected / {}, 1027 / payload, / h'84381af60c5832a120a5010202442edb61f92001215820acb 1028 ee6672a28340affce41c721901ebd7868231bd1d86e41888a078222140 1029 50022f5', / payload_2 / 1030 / signature / h'2374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce 1031 5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327 1032 be470355c9657ce0' 1033 ] 1034 ) 1036 Figure 11: Example of message_2 authenticated with RPK. 1038 The equivalent CBOR encoding is: h'd903e58449a2012604447a2af164a05839 1039 84381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c 1040 721901ebd7868231bd1d86e41888a07822214050022f558402374e27a3d9eeb4f66c5 1041 dc5ba5b8dca25dab3c2e56a551ce5705b793914348e14eea4aee6e0c9f09db4ef3dde 1042 ca8f3506cd1a98a8fb64327be470355c9657ce0', which has a size of 140 1043 bytes. 1045 A.8. Message 1 with Cert 1047 An example of COSE encoding for message_1 is given in Figure 12, 1048 using CBOR's diagnostic notation. In this example, the size of the 1049 identifier of the static public key of U, kid_su, is 4 bytes, and the 1050 payload is as in Appendix A.2. 1052 The message_1 is: 1054 997( 1055 [ 1056 / protected / h'a201260444c150d41c' / { / 1057 / alg 1:-7, ECDSA 256 / 1058 / kid 4:h'c150d41c', kid_su / 1059 / } / , 1060 / unprotected / {"x5c": certificate-chain}, 1061 / payload / h'84381af60c582fa120a50102024103200121582098f 1062 50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d9 1063 1d628022f5', / payload_1 / 1064 / signature / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 1065 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64 1066 327be470355c9657ce0' 1067 ] 1068 ) 1070 Figure 12: Example of message_1 authenticated with Certificate 1072 The equivalent CBOR encoding is: 1073 h'd903e58449a201260444c150d41ca163783563 40... 583684381af60c582fa120 1074 a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf 1075 054e1c7b4d91d628022f55840eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 1076 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327b 1077 e470355c9657ce0', 1079 which has a size of 142 bytes plus the size of the certificate. 1081 A.9. Message 2 with Cert 1083 An example of COSE encoding for message_2 is given in Figure 13, 1084 using CBOR's diagnostic notation. In this example, the size of the 1085 identifier of the static public key of U, kid_su, is 4 bytes, and the 1086 payload is as in Appendix A.3. 1088 The message_2 is: 1090 997( 1091 [ 1092 / protected / h'a2012604447a2af164' / { / 1093 / alg 1:-7, ECDSA 256 / 1094 / kid 4:h'7a2af164', kid_sv / 1095 / } / , 1096 / unprotected / {"x5c": certificate-chain}, 1097 / payload / h'84381af60c5832a120a5010202442edb61f92001215820 1098 acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214 1099 050022f5', / payload_2 / 1100 / signature / h'2374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce 1101 5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327 1102 be470355c9657ce0' 1103 ] 1104 ) 1106 Figure 13: Example of message_2 authenticated with Certificate. 1108 The equivalent CBOR encoding is: 1109 h'd903e58449a2012604447a2af164a163783563 40... 583984381af60c5832a120 1110 a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd 1111 1d86e41888a07822214050022f558402374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c 1112 2e56a551ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb 1113 64327be470355c9657ce0', 1115 which has a size of 145 bytes plus the size of the certificate. 1117 Appendix B. Implementing EDHOC with CoAP 1119 The DH key exchange specified in this document can be implemented as 1120 a CoAP [RFC7252] message exchange with the CoAP client as party U and 1121 the CoAP server as party V. A strawman is sketched here. 1123 The CoAP client makes the following request: 1125 o The request method is POST 1127 o Content-Format is "application/cose+cbor" 1129 o The Uri-Path is "edhoc" 1131 o The Payload is message_1 1133 The CoAP server performs the verifications of the COSE object as 1134 specified in [I-D.ietf-cose-msg]. If successful, then the server 1135 provides the following response: 1137 o The response Code is 2.04 (Changed) 1138 o The Payload is message_2 1140 Authors' Addresses 1142 Goeran Selander 1143 Ericsson AB 1144 Farogatan 6 1145 Kista SE-16480 Stockholm 1146 Sweden 1148 Email: goran.selander@ericsson.com 1150 John Mattsson 1151 Ericsson AB 1152 Farogatan 6 1153 Kista SE-16480 Stockholm 1154 Sweden 1156 Email: john.mattsson@ericsson.com 1158 Francesca Palombini 1159 Ericsson AB 1160 Farogatan 6 1161 Kista SE-16480 Stockholm 1162 Sweden 1164 Email: francesca.palombini@ericsson.com