Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-selander-ace-cose-ecdhe-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Göran Selander , John Preuß Mattsson , Francesca Palombini | ||
| Last updated | 2016-07-07 | ||
| Replaced by | draft-selander-lake-edhoc | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-selander-ace-cose-ecdhe-02
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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://dx.doi.org/10.6028/NIST.SP.800-56Ar2>.
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,
<http://www.rfc-editor.org/info/rfc4492>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
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]