ACE Working Group G. Selander Internet-Draft J. Mattsson Intended status: Standards Track F. Palombini Expires: January 8, 2017 Ericsson AB July 07, 2016 Ephemeral Diffie-Hellman Over COSE (EDHOC) draft-selander-ace-cose-ecdhe-02 Abstract This document specifies authenticated Diffie-Hellman key exchange with ephemeral keys, embedded in messages encoded with the CBOR Object Signing and Encryption (COSE) format. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Selander, et al. Expires January 8, 2017 [Page 1] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Authentication methods . . . . . . . . . . . . . . . . . 6 3. Message formatting using COSE . . . . . . . . . . . . . . . . 7 3.1. ECDH Public Keys using COSE_Key . . . . . . . . . . . . . 7 3.2. Payload 1 formatting . . . . . . . . . . . . . . . . . . 7 3.3. Payload 2 formatting . . . . . . . . . . . . . . . . . . 8 3.4. Message Formatting with Symmetric Keys . . . . . . . . . 8 3.4.1. Message 1 with PSK . . . . . . . . . . . . . . . . . 8 3.4.2. Message 2 with PSK . . . . . . . . . . . . . . . . . 9 3.4.3. KDF Context with Symmetric Keys . . . . . . . . . . . 9 3.5. Message Formatting with Asymmetric Keys . . . . . . . . . 10 3.5.1. Message 1 with RPK . . . . . . . . . . . . . . . . . 10 3.5.2. Message 2 with RPK . . . . . . . . . . . . . . . . . 10 3.5.3. Message 1 with Cert . . . . . . . . . . . . . . . . . 11 3.5.4. Message 2 with Cert . . . . . . . . . . . . . . . . . 11 3.5.5. KDF Context with Asymmetric Keys . . . . . . . . . . 12 4. Message Processing . . . . . . . . . . . . . . . . . . . . . 12 4.1. U -> message_1 . . . . . . . . . . . . . . . . . . . . . 12 4.2. message_1 -> V . . . . . . . . . . . . . . . . . . . . . 13 4.3. message_2 <- V . . . . . . . . . . . . . . . . . . . . . 14 4.4. U <- message_2 . . . . . . . . . . . . . . . . . . . . . 14 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 A.1. ECDH Public Key . . . . . . . . . . . . . . . . . . . . . 18 A.2. Payload 1 . . . . . . . . . . . . . . . . . . . . . . . . 19 A.3. Payload 2 . . . . . . . . . . . . . . . . . . . . . . . . 19 A.4. Message 1 with PSK . . . . . . . . . . . . . . . . . . . 20 A.5. Message 2 with PSK . . . . . . . . . . . . . . . . . . . 21 A.6. Message 1 with RPK . . . . . . . . . . . . . . . . . . . 21 A.7. Message 2 with RPK . . . . . . . . . . . . . . . . . . . 22 A.8. Message 1 with Cert . . . . . . . . . . . . . . . . . . . 23 A.9. Message 2 with Cert . . . . . . . . . . . . . . . . . . . 24 Appendix B. Implementing EDHOC with CoAP . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Selander, et al. Expires January 8, 2017 [Page 2] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 1. Introduction Security at the application layer provides an attractive option for protecting Internet of Things (IoT) deployments, for example where transport layer security is not sufficient [I-D.hartke-core-e2e-security-reqs]. IoT devices may be constrained in various ways, including memory, storage, processing capacity, and energy [RFC7228]. A method for protecting individual messages at application layer, suitable for constrained devices, is provided by COSE [I-D.ietf-cose-msg]). In order for a communication session to provide forward secrecy, the communicating parties can run a Diffie-Hellman (DH) key exchange protocol with ephemeral keys, from which shared key material can be derived. This document specifies authenticated DH protocols using COSE objects for integrity protecting the transport of ephemeral public keys. The DH key exchange messages may be authenticated using either pre-shared keys, raw public keys or X.509 certificates. Authentication is based on credentials established out of band, or from a trusted third party, such as an Authorization Server as specified by [I-D.ietf-ace-oauth-authz]. This document also specifies the derivation of the shared key material. The DH exchange and the key derivation follow [SP-800-56a] and HKDF [RFC5869], and make use of the data structures of COSE which are aligned with these standards. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words may also appear in this document in lowercase, absent their normative meanings. The parties exchanging messages are called "party U" and "party V", and the ECDH ephemeral public keys of U and V are denoted "E_U" and "E_V", respectively, see Figure 2. The messages in the authenticated message exchange are called "message_1" and "message_2", see Figure 3. The keys used to authenticate the key exchange are either symmetric or asymmetric. In case of symmetric, the pre-shared key is denoted "PSK". In case of asymmetric, the public keys of U and V are denoted "S_U" and "S_V", respectively. Most keys used in this document have an associated identifier. The identifiers used in the document are placeholders for values of the Selander, et al. Expires January 8, 2017 [Page 3] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 identifiers. The following key identifiers/value representations are used in the draft: o kid_eu and kid_ev represent the values of the key identifiers of the ephemeral public keys of U and V, respectively. * kid_eu is a sequence number used for replay protection of message_1. * kid_ev is used to identify the resulting traffic key, as a means for party V to ensure that different U establishing traffic keys using this method have different identifiers. o kid_psk represents the value of the key identifier of the pre- shared key between U and V (Section 3.4). o kid_su and kid_sv represent the values of the key identifiers of the static public keys of U and V, respectively (Section 3.5). The key notation is summarized in Figure 1. +------------+-----+---------------------------------------------+ | Key | Key | Use | | Identifier | | | +------------+-----+---------------------------------------------+ | kid_eu | E_U | ECDH ephemeral public key of U | | kid_ev | E_V | ECDH ephemeral public key of V | | kid_psk | PSK | Pre-shared static symmetric key (Section 3) | | kid_su | S_U | Static public key of U (Section 4) | | kid_sv | S_V | Static public key of V (Section 4) | +------------+-----+---------------------------------------------+ Figure 1: Notation of keys and key identifiers. 2. Protocol Overview EDHOC is a 2-pass message exchange of COSE objects. This section gives an overview of the protocol, together with section Section 4, which explains how the messages are processed, while section Section 3 focuses on the detailed message formats embedded as COSE objects. The underlying scheme is the Elliptic Curve Cofactor Diffie-Hellman with two ephemeral keys as specified in Section 6.1.2.2 of [SP-800-56a], see Figure 2. U and V exchange their ephemeral public keys E_U, E_V, computes the shared secret and derives the keying material as described in [SP-800-56a]. Selander, et al. Expires January 8, 2017 [Page 4] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 Party U Party V | | | E_U | +---------------------->| | | | E_V | |<----------------------+ | | Shared | | Shared Secret Secret | | | Key Derivation | Key Derivation V V Derived Keying Material Derived Keying Material Figure 2: Diffie-Hellman key exchange and key derivation EDHOC makes the following additions to this scheme (see Figure 3): o Negotiation of hash function used with HKDF in the key derivation: * U proposes one or more hash functions (expressed as HKDF(s) with different hash algorithms). * V decides and responds with one function (expressed as HKDF with a particular hash algorithm). o Optional nonces (N_U, N_V) contributing to the salt used in the extract phase of HKDF [RFC5869]. o Negotiation of subsequent traffic crypto algorithm (TCA) to be used between party U and V: * U proposes one or more algorithms (TCA(s)). * V decides and responds with one algorithm (TCA). o Authentication, integrity and replay protection of protocol messages * Authentication and integrity protection using the COSE format [I-D.ietf-cose-msg]. + The MAC/Signature is calculated over the message as defined by COSE. Selander, et al. Expires January 8, 2017 [Page 5] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 + Information about keys, message protection algorithm and replay parameter is included in the COSE Header, as specified in the sections below. * Authentication may be based on pre-shared keys, raw public keys or X.509 certificates. In the latter case the message contains the public key certificate of the sending endpoints (Cert_U, Cert_V). The key exchange messages are called "message_1" and "message_2", see Figure 3. Party U Party V | | | Header, HKDF(s), ?N_U, TCA(s), E_U, MAC/Signature, ?Cert_U | +--------------------------------------------------------------> | | message_1 | | | | Header, HKDF, ?N_V, TCA, E_V, MAC/Signature, ?Cert_V | | <--------------------------------------------------------------+ | message_2 | | | | Shared Shared | Secret Secret | | | Key Derivation Key Derivation | V V traffic_secret_0 traffic_secret_0 Figure 3: EDHOC Overview. (Optionality indicated by '?'.) 2.1. Authentication methods The EDHOC protocol messages are authenticated based on credentials pre-established between U and V. The parties may have acquired such a credential from the other party out of band or from a trusted third party, such as an Authorization Server as specified in [I-D.ietf-ace-oauth-authz]. The pre-established credentials are either symmetric secret keys or public keys. The public keys may be raw public keys (RPK), or public keys of a Certificate Authority (CA) used as trust anchor for verification of received certificates. o Pre-shared symmetric key (PSK). Each message contains a MAC over the message generated by the sending party using PSK. o Raw Public Keys (RPK). The pre-established credentials may be static raw public keys of the other party (S_U and S_V, of party U Selander, et al. Expires January 8, 2017 [Page 6] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 and V, respectively). Each message contain a signature over the message generated by the sending party. o X.509 Certificates (Cert). The pre-established credentials may also be CA public keys, used to verify received public key certificates. Each message contain the signature over the message, excluding the certificate, generated by the sending party. 3. Message formatting using COSE This section details the format for the objects used. Examples are provided for each object in Appendix A. 3.1. ECDH Public Keys using COSE_Key This section defines the formatting of the ephemeral public keys E_U and E_V. The ECDH ephemeral public key SHALL be formatted as a COSE_Key with the following fields and values (see [I-D.ietf-cose-msg]): o kty: The value SHALL be 2 (Elliptic Curve Keys) o kid: o crv: The value of the Curve used. The value 1 SHALL be supported by party V (NIST P-256 a.k.a. secp256r1 [RFC4492]) o x: o y: The value SHOULD be boolean. TODO: Consider replacing P-256 with Curve25519 as mandatory 3.2. Payload 1 formatting This section defines the formatting of the payload in message_1. payload_1 is a CBOR array object containing: o HKDFs: the set of proposed algorithms to indicate the key derivation o N_U: optional nonce for use in salt with HKDF o TCAs: the set of proposed algorithms to use with the derived secret Selander, et al. Expires January 8, 2017 [Page 7] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 o E_U: the ephemeral public key (with 'kid' = kid_eu, which is a sequence number) payload_1 = [ HKDFs : AlgID / [ + AlgID ], N_U : nil / bstr, TCAs : AlgID / [ + AlgID ], E_U : COSE_Key ] AlgID : int / tstr 3.3. Payload 2 formatting This section defines the formatting of the payload in message_2. payload_2 is a CBOR array object containing: o HKDF: the agreed key derivation algorithm o N_V: optional nonce for use in salt with HKDF o TCA: the agreed traffic crypto algorithm o E_V: the ephemeral public key (with 'kid' = kid_ev) payload_2 = [ HKDF : int / tstr, N_V : nil / bstr, TCA : int / tstr, E_V : COSE_Key ] 3.4. Message Formatting with Symmetric Keys Parties U and V are assumed to have a pre-shared key, PSK. The value of the key identifier kid_psk SHALL be unique for U and V. 3.4.1. Message 1 with PSK In case of PSK, message_1 SHALL have the COSE_Mac0_Tagged structure [I-D.ietf-cose-msg] with the following fields and values: o Header * Protected + Alg: 4 (HMAC 256/64) Selander, et al. Expires January 8, 2017 [Page 8] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 + Kid: kid_psk * Unprotected: Empty o Payload: payload_1 as defined in Section 3.2 o MAC: As in section 6.3 of [I-D.ietf-cose-msg] 3.4.2. Message 2 with PSK In case of PSK, message_2 SHALL have the COSE_Mac0_Tagged structure [I-D.ietf-cose-msg] with the following fields and values: o Header * Protected + Alg: 4 (HMAC 256/64) + Kid: kid_psk * Unprotected: empty o Payload: payload_2 as defined in Section 3.3 o Tag: As in section 6.3 of [I-D.ietf-cose-msg], including the external_aad in the MAC_structure. The external authenticated data to use in the MAC_structure of Section 6.3 of [I-D.ietf-cose-msg] is the MAC of message_1. o external_aad: MAC 3.4.3. KDF Context with Symmetric Keys The key derivation is specified in Section 5 using the following context information COSE_KDF_Context for symmetric keys: COSE_KDF_Context = [ AlgorithmID : int / tstr, ; AlgID SuppPubInfo : [ keyDataLength : uint, ; length protected : bstr, ; zero length bstr other : bstr ; MAC message_1 || MAC message_2 ], ] Selander, et al. Expires January 8, 2017 [Page 9] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 3.5. Message Formatting with Asymmetric Keys Parties U and V are assumed to have access to each other's public key. o Party U's public key, S_U, SHALL be uniquely identified at V by kid_su. o Party V's public key, S_V, SHALL be uniquely identified at U by kid_sv. 3.5.1. Message 1 with RPK In case of RPK message_1 SHALL have the COSE_Sign1_Tagged structure [I-D.ietf-cose-msg], with the following fields and values: o Header * protected: + alg: -7 (ECDSA 256) + kid: kid_su * unprotected: empty o payload: payload_1 as defined in Section 3.2 o signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg} 3.5.2. Message 2 with RPK In case of RPK, message_2 SHALL have the COSE_Sign1_Tagged structure [I-D.ietf-cose-msg] with the following fields and values: o Header * Protected + Alg: -7 (ECDSA 256) + Kid: kid_sv * Unprotected: empty o payload: payload_2 as defined in Section 3.3 Selander, et al. Expires January 8, 2017 [Page 10] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 o signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg}, including the external_aad in the Sig_structure. The external authenticated data to use in the Sig_structure of Section 4.4 of [I-D.ietf-cose-msg] is the signature in message_1. o external_aad: signature 3.5.3. Message 1 with Cert The case of Certificates is similar to RPK. message_1 SHALL have the COSE_Sign1_Tagged structure [I-D.ietf-cose-msg], with the same fields and values as Section 3.5.1 with the addition of the unprotected header field "x5c" containing the X.509 certificate of S_U as a byte string. o Header * protected: + alg: -7 (ECDSA 256) + kid: kid_su * unprotected: + x5c: bstr o payload: payload_1 as defined in Section 3.2 o signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg} 3.5.4. Message 2 with Cert message_2 is analogous to message_1. message_2 SHALL have the COSE_Sign1_Tagged structure [I-D.ietf-cose-msg], with the same fields and values as Section 3.5.2 and with the addition of the unprotected header field "x5c" containing the X.509 certificate of S_V as a byte string. o Header * Protected + Alg: -7 (ECDSA 256) + Kid: kid_sv Selander, et al. Expires January 8, 2017 [Page 11] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 * Unprotected: + x5c: bstr o payload: payload_2 as defined in Section 3.3 o signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg}, including the external_aad in the Sig_structure. The external authenticated data to use in the Sig_structure of Section 4.4 of [I-D.ietf-cose-msg] is the signature in message_1. o external_aad: signature 3.5.5. KDF Context with Asymmetric Keys The key derivation is specified in Section 5 using the following context information COSE_KDF_Context for asymmetric keys: COSE_KDF_Context = [ AlgorithmID : int / tstr, ; AlgID SuppPubInfo : [ keyDataLength : uint, ; length protected : bstr, ; zero length bstr other : bstr ; signature of message_1 || signature of message_2 ] ] 4. Message Processing Party U and V are assumed to have pre-established credentials as described in Section 2.1. 4.1. U -> message_1 Party U processes message_1 for party V as follows: o Party U SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of [SP-800-56a] using ECC domain parameters of a curve complying with security policies for communicating with party V. o The ephemeral public key, E_U, SHALL be formatted as a COSE_key as specified in Section 3.1. Selander, et al. Expires January 8, 2017 [Page 12] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 o The key identifier kid_eu of the ephemeral public key E_U SHALL be a sequence number initiated to 1 and increased by 1 for each message_1 associated to a particular party V. o Party U SHALL define the parameters and format payload_1 as specified in Section 3.2 complying with the security policies for communicating with party V. o message_1 SHALL be formatted as a COSE message according to [I-D.ietf-cose-msg] with parameters specified in Section 3.4.1 (PSK) , Section 3.5.1 (RPK) or Section 3.5.3 (Cert). Party U SHALL cache the MAC/Signature value of the request. o Party U sends message_1 to party V. 4.2. message_1 -> V Party V processes the received message_1 as follows: o If the message contains a certificate, party V SHALL verify the certificate using the pre-established trust anchor and the revocation verification policies relevant for party U. If the verification fails the message is discarded. o Party V SHALL verify that kid_eu is greater than a counter tracking latest message associated with party U, identified with the sending party key. (The counter is initialized to 0 at first contact with party U.) If kid_eu is less than or equal than the counter, the message is discarded. o Party V SHALL verify the COSE message as specified in [I-D.ietf-cose-msg] using the key associated to party U, identified by the key identifier kid_psk/kid_su in the message header, or in the verified received certificate. If the MAC/ Signature of the received request can be verified, then the counter associated to party U is updated with kid-eu, else the message is discarded. o Party V SHALL verify that the ECDH curve is compliant with its security policy for communicating with U, or else respond with an error. o V SHALL select a preferred pair of (HKDF, TCA) out of those proposed by U, compliant with the security policy relevant for party U. If such a pair does not exist, V SHALL stop processing the message and MAY respond with an error, indicating that no common algorithm could be found. Selander, et al. Expires January 8, 2017 [Page 13] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 4.3. message_2 <- V Party V composes message_2 for party U as follows: o Party V SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of [SP-800-56a] using same curve/ECC domain parameters as used by party U. o The ephemeral public key, E_V, SHALL be formatted as a COSE_key as specified in Section 3.1. The key identifier kid_ev SHALL be unique among key identifiers used for traffic keys by party V. o Party SHALL define the parameters and format payload_2 as specified in Section 3.3 complying with the security policies for communicating with party V. o message_2 SHALL be formatted as a COSE message according to [I-D.ietf-cose-msg] with parameters specified in Section 3.4.2 (PSK) , Section 3.5.2 (RPK) or Section 3.5.4 (Cert) using the same authentication scheme as in message_1. Note that the MAC/ Signature value of the request is included as additional authenticated data of the response. Party V sends message_2 to party U. Then party V derives the traffic_secret_0 key as specified Section 5, and labels it with kid_ev. 4.4. U <- message_2 Party U processes the received message_2 as follows: o If the message contains a certificate, party V SHALL verify the certificate using the pre-established trust anchor and the revocation verification policies relevant for party U. If the verification fails the message is discarded. o Party U SHALL verify the received COSE message as defined in [I-D.ietf-cose-msg] using the key associated to the key identifier (kid_psk/kid_su) in the message header, or in the verified received certificate. Note the use of the cached MAC/Signature of the request. If the COSE message cannot be verified, the message is discarded. o U SHALL verify that the received pair (HKDF, TCA) is one element of those proposed in the request, else stop processing the message. Selander, et al. Expires January 8, 2017 [Page 14] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 o If the response is verified, U derives the traffic_secret_0 as specified Section 5. 5. Key Derivation The key derivation is identical to Section 11 of [I-D.ietf-cose-msg], using HKDF [RFC5869] agreed during the message exchange. o the secret SHALL be the ECDH shared secret as defined in Section 12.4.1 of [I-D.ietf-cose-msg], where the computed secret is specified in section 5.7.1.2 of [SP-800-56a] o the salt SHALL be B1 XOR B2, where * B1 = N_U || 00 .. 0, i.e. the nonce N_U, if present, appended with padded zeros to the size of the hash function; or else just an octet string of zeros * B2 = 00... 0 || N_V, i.e. the nonce N_V, if present, prepended with padded zeros to the size of the hash function; or else just an octet string of zeros * This corresponds to salt = N_U || N_V in the case of each party contributing a nonce of half the size of the salt, but also accommodates for nonces of different sizes. o the length SHALL be the length of the key in TCA. o the context information SHALL be the serialized COSE_KDF_Context defined in the next paragraph. o the PRF SHALL be the one indicated in HKDF using the Table 18 of [I-D.ietf-cose-msg] (in our examples, -27 corresponds to HMAC with SHA-256) The context information COSE_KDF_Context is defined as follows: o AlgorithmID SHALL be the algorithm for which the key material will be derived. It's value is AlgID o PartyUInfo SHALL be empty o PartyVInfo SHALL be empty o SuppPubInfo SHALL contain: * KeyDataLength SHALL be equal to 'length' Selander, et al. Expires January 8, 2017 [Page 15] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 * protected SHALL be a zero length bstr * other SHALL be the concatenation of the MAC/Signature of message_1 and the MAC/Signature of message_2 o SuppPrivInfo SHALL be empty The tags are either MACs (PSK) or the Signatures (RPK, Cert) of the COSE messages. COSE\_KDF\_Context = [ AlgorithmID : int / tstr, ; HKDF SuppPubInfo : [ keyDataLength : uint, ; length protected : bstr, ; zero length bstr other : bstr ; MAC/Signature message_1 || MAC/Signature message_2 ], ] The output from the key derivation is denoted "traffic_secret_0". 6. Security Considerations For unauthenticated Diffie-Hellman it is recommended that public information about parties U and V, such as their identifiers, is included in the context information used in the key derivation. In the present case the assumption is that the parties authenticate each other with pre-established credentials, and the tag (MAC/Signature) created with the pre-established credentials is included in the key derivation context. The referenced processing instructions in [SP-800-56a] must be complied with, including deleting the intermediate computed values along with any ephemeral ECDH secrets after the key derivation is completed. The choice of key length used in the different algorithms needs to be harmonized, so that right security level is maintained throughout the calculations. The identifier of the ephemeral key of party U is used for replay protection of U's requests. With the current protocol, key confirmation of the Diffie-Hellman shared secret/traffic keys is performed when the keys are successfully used. The addition of key confirmation to the protocol is for further study. Selander, et al. Expires January 8, 2017 [Page 16] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 TODO: Expand on the security considerations in a future version of the draft 7. Privacy Considerations TODO 8. IANA Considerations 9. Acknowledgments The authors wants to thank Ilari Liusvaara, Jim Schaad and Ludwig Seitz for timely review and helpful comments. 10. References 10.1. Normative References [I-D.ietf-cose-msg] Schaad, J., "CBOR Object Signing and Encryption (COSE)", draft-ietf-cose-msg-14 (work in progress), June 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [SP-800-56a] Barker, E., Chen, L., Roginsky, A., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, May 2013, . 10.2. Informative References [I-D.hartke-core-e2e-security-reqs] Selander, G., Palombini, F., and K. Hartke, "Requirements for CoAP End-To-End Security", draft-hartke-core-e2e- security-reqs-01 (work in progress), July 2016. [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE)", draft-ietf-ace-oauth- authz-02 (work in progress), June 2016. Selander, et al. Expires January 8, 2017 [Page 17] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . Appendix A. Examples A.1. ECDH Public Key An example of COSE_Key structure, representing an ECDH public key, is given in Figure 4, using CBOR's diagnostic notation. In this example, the ephemeral key is identified by a 4 bytes 'kid'. / ephemeral / -1:{ / kty / 1:2, / kid / 2:h'78f67901', / crv / -1:1, / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590b bfbf054e1c7b4d91d6280', / y / -3:true } Figure 4: Example of an ECDH public key formatted as a COSE_Key The equivalent CBOR encoding is: h'a120a50102024478f67901200121582098 f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5', which has a size of 51 bytes. Selander, et al. Expires January 8, 2017 [Page 18] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 A.2. Payload 1 An example of COSE encoding for payload_1 is given in Figure 5, using CBOR's diagnostic notation. In this example, the size of the identifier of U's ephemeral key, kid_eu, is 1 byte. The payload_1 is: [ -27, / HKDFs / null, / N_U / 12, / TCAs / h'a120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5a d7590bbfbf054e1c7b4d91d628022f5' / COSE_Key E_U { / / ephemeral -1:{ / / kty 1:2, / / kid 2:h'03', kid_eu / / crv -1:1, / / x -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb / / f054e1c7b4d91d6280', / / y -3:true / / } / / } / ] Figure 5: Example of payload of message_1 The equivalent CBOR encoding of the payload is: h'84381af60c582fa120a 50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf0 54e1c7b4d91d628022f5', which has a size of 54 bytes. A.3. Payload 2 An example of COSE encoding for message_2 is given in Figure 6 using CBOR's diagnostic notation. In this example, kid_ev, the identifier of V's ephemeral public key, is 4 bytes. The payload is: Selander, et al. Expires January 8, 2017 [Page 19] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 [ -27, / HKDF / null, / N_V / 12, / TCA / h'a120a5010202442edb61f92001215820acbee6672a28340affce41c721901eb d7868231bd1d86e41888a07822214050022f5' / COSE_Key E_V { / / ephemeral -1:{ / / kty 1:2, / / kid 2:h'2edb61f9', kid_ev / / crv -1:1, / / x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d / / 86e41888a078222140500', / / y -3:true / / } / / } / ] Figure 6: Example of payload of message_2 The equivalent CBOR encoding of the payload is: h'84381af60c5832a120a 5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1 d86e41888a07822214050022f5', which has a size of 57 bytes. A.4. Message 1 with PSK An example of COSE encoding for message_1 is given in Figure 7 using CBOR's diagnostic notation. In this example, kid_psk, the identifier of PSK is 4 bytes, and the payload is as in Appendix A.2. The message_1 is: 996( [ / protected / h'a201040444e19648b5' / { / / alg 1:4, HMAC 256//64 / / kid 4:h'e19648b5' kid_psk / / } / , / unprotected / {}, / payload / h'84381af60c582fa120a501020241032001215820 98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4 d91d628022f5', / payload_1 / / tag / h'e77fe81c66c3b5c0' ] ) Figure 7: Example of message_1 authenticated with PSK Selander, et al. Expires January 8, 2017 [Page 20] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 The equivalent CBOR encoding is: h'd903e48449a201040444e19648b5a05836 84381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638e a56c3f5ad7590bbfbf054e1c7b4d91d628022f548e77fe81c66c3b5c0', which has a size of 80 bytes. A.5. Message 2 with PSK An example of COSE encoding for message_2 is given in Figure 8 using CBOR's diagnostic notation. In this example, kid_psk, the identifier of PSK, is 4 bytes, and the payload is as in Appendix A.3. The message_2 is: 996( [ / protected / h'a201040444e19648b5' / { / / alg 1:4, HMAC 256//64 / / kid 4:h'e19648b5' kid_psk / / } / , / unprotected / {}, / payload / h'84381af60c5832a120a5010202442edb61f92001215820 acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214 050022f5', / payload_2 / / tag / h'6113268ad246f2c9' ] ) Figure 8: Example of message_2 authenticated with PSK The equivalent CBOR encoding is: h'd903e48449a201040444e19648b5a05839 84381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c 721901ebd7868231bd1d86e41888a07822214050022f5486113268ad246f2c9', which has a size of 83 bytes. A.6. Message 1 with RPK An example of COSE encoding for message_1 is given in Figure 9, using CBOR's diagnostic notation. In this example, the size of the identifier of the static public key of U, kid_su, is 4 bytes, and the payload is as in Appendix A.2. The message_1 is: Selander, et al. Expires January 8, 2017 [Page 21] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 997( [ / protected / h'a201260444c150d41c' / { / / alg 1:-7, ECDSA 256 / / kid 4:h'c150d41c', kid_c / / } / , / unprotected / {}, / payload / h'84381af60c582fa120a501020241032001215820 98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4 d91d628022f5', / payload_1 / / signature / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64 327be470355c9657ce0' ] ) Figure 9: Example of message_1 authenticated with RPK The equivalent CBOR encoding is: h'd903e58449a201260444c150d41ca05836 84381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638e a56c3f5ad7590bbfbf054e1c7b4d91d628022f55840eae868ecc1276883766c5dc5ba 5b8dca25dab3c2e56a51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f35 06cd1a98a8fb64327be470355c9657ce0', which has a size of 137 bytes. A.7. Message 2 with RPK An example of COSE encoding for Message 2 is given in Figure 11, using CBOR's diagnostic notation. In this example, the size of the identifier of the public key of V, kid_sv, is 4 bytes, and the payload is as in Appendix A.3. The external_aad is the signature of message_1: / external\_aad / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327 be470355c9657ce0' Figure 10: Example of external additional authenticated data The message_2 is: Selander, et al. Expires January 8, 2017 [Page 22] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 997( [ / protected / h'a2012604447a2af164' / { / / alg 1:-7, ECDSA 256 / / kid 4:h'7a2af164', kid_sv / / } / , / unprotected / {}, / payload, / h'84381af60c5832a120a5010202442edb61f92001215820acb ee6672a28340affce41c721901ebd7868231bd1d86e41888a078222140 50022f5', / payload_2 / / signature / h'2374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce 5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327 be470355c9657ce0' ] ) Figure 11: Example of message_2 authenticated with RPK. The equivalent CBOR encoding is: h'd903e58449a2012604447a2af164a05839 84381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c 721901ebd7868231bd1d86e41888a07822214050022f558402374e27a3d9eeb4f66c5 dc5ba5b8dca25dab3c2e56a551ce5705b793914348e14eea4aee6e0c9f09db4ef3dde ca8f3506cd1a98a8fb64327be470355c9657ce0', which has a size of 140 bytes. A.8. Message 1 with Cert An example of COSE encoding for message_1 is given in Figure 12, using CBOR's diagnostic notation. In this example, the size of the identifier of the static public key of U, kid_su, is 4 bytes, and the payload is as in Appendix A.2. The message_1 is: Selander, et al. Expires January 8, 2017 [Page 23] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 997( [ / protected / h'a201260444c150d41c' / { / / alg 1:-7, ECDSA 256 / / kid 4:h'c150d41c', kid_su / / } / , / unprotected / {"x5c": certificate-chain}, / payload / h'84381af60c582fa120a50102024103200121582098f 50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d9 1d628022f5', / payload_1 / / signature / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64 327be470355c9657ce0' ] ) Figure 12: Example of message_1 authenticated with Certificate The equivalent CBOR encoding is: h'd903e58449a201260444c150d41ca163783563 40... 583684381af60c582fa120 a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf 054e1c7b4d91d628022f55840eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327b e470355c9657ce0', which has a size of 142 bytes plus the size of the certificate. A.9. Message 2 with Cert An example of COSE encoding for message_2 is given in Figure 13, using CBOR's diagnostic notation. In this example, the size of the identifier of the static public key of U, kid_su, is 4 bytes, and the payload is as in Appendix A.3. The message_2 is: Selander, et al. Expires January 8, 2017 [Page 24] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 997( [ / protected / h'a2012604447a2af164' / { / / alg 1:-7, ECDSA 256 / / kid 4:h'7a2af164', kid_sv / / } / , / unprotected / {"x5c": certificate-chain}, / payload / h'84381af60c5832a120a5010202442edb61f92001215820 acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214 050022f5', / payload_2 / / signature / h'2374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce 5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327 be470355c9657ce0' ] ) Figure 13: Example of message_2 authenticated with Certificate. The equivalent CBOR encoding is: h'd903e58449a2012604447a2af164a163783563 40... 583984381af60c5832a120 a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd 1d86e41888a07822214050022f558402374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c 2e56a551ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb 64327be470355c9657ce0', which has a size of 145 bytes plus the size of the certificate. Appendix B. Implementing EDHOC with CoAP The DH key exchange specified in this document can be implemented as a CoAP [RFC7252] message exchange with the CoAP client as party U and the CoAP server as party V. A strawman is sketched here. The CoAP client makes the following request: o The request method is POST o Content-Format is "application/cose+cbor" o The Uri-Path is "edhoc" o The Payload is message_1 The CoAP server performs the verifications of the COSE object as specified in [I-D.ietf-cose-msg]. If successful, then the server provides the following response: o The response Code is 2.04 (Changed) Selander, et al. Expires January 8, 2017 [Page 25] Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) July 2016 o The Payload is message_2 Authors' Addresses Goeran Selander Ericsson AB Farogatan 6 Kista SE-16480 Stockholm Sweden Email: goran.selander@ericsson.com John Mattsson Ericsson AB Farogatan 6 Kista SE-16480 Stockholm Sweden Email: john.mattsson@ericsson.com Francesca Palombini Ericsson AB Farogatan 6 Kista SE-16480 Stockholm Sweden Email: francesca.palombini@ericsson.com Selander, et al. Expires January 8, 2017 [Page 26]