ACE Working Group G. Selander
Internet-Draft J. Mattsson
Intended status: Standards Track F. Palombini
Expires: April 24, 2017 Ericsson AB
October 21, 2016
Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-selander-ace-cose-ecdhe-03
Abstract
This document specifies authenticated Diffie-Hellman key exchange
with ephemeral keys, embedded in messages encoded with CBOR and using
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 April 24, 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 April 24, 2017 [Page 1]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. ECDH Public Keys using COSE_Key . . . . . . . . . . . . . . . 5
4. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Message Formatting using COSE . . . . . . . . . . . . . . 7
4.1.1. Message 1 . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Message 2 . . . . . . . . . . . . . . . . . . . . . . 8
4.1.3. Message 3 . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Key Derivation with Asymmetric Keys . . . . . . . . . . . 11
4.3. Message Processing . . . . . . . . . . . . . . . . . . . 13
4.3.1. U -> message_1 . . . . . . . . . . . . . . . . . . . 13
4.3.2. message_1 -> V . . . . . . . . . . . . . . . . . . . 14
4.3.3. message_2 <- V . . . . . . . . . . . . . . . . . . . 14
4.3.4. U <- message_2 . . . . . . . . . . . . . . . . . . . 15
4.3.5. U -> message_3 . . . . . . . . . . . . . . . . . . . 16
4.3.6. message_3 -> V . . . . . . . . . . . . . . . . . . . 16
5. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Message Formatting using COSE . . . . . . . . . . . . . . 19
5.1.1. Message 1 . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2. Message 2 . . . . . . . . . . . . . . . . . . . . . . 19
5.1.3. Message 3 . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Key Derivation with Symmetric Keys . . . . . . . . . . . 22
5.3. Message Processing . . . . . . . . . . . . . . . . . . . 23
5.3.1. U -> message_1 . . . . . . . . . . . . . . . . . . . 23
5.3.2. message_1 -> V . . . . . . . . . . . . . . . . . . . 24
5.3.3. message_2 <- V . . . . . . . . . . . . . . . . . . . 24
5.3.4. U <- message_2 . . . . . . . . . . . . . . . . . . . 25
5.3.5. U -> message_3 . . . . . . . . . . . . . . . . . . . 26
5.3.6. message_3 -> V . . . . . . . . . . . . . . . . . . . 26
6. Derive Traffic Secret . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 30
A.1. ECDH Public Key . . . . . . . . . . . . . . . . . . . . . 30
Appendix B. Implementing EDHOC with CoAP and OSCOAP . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Selander, et al. Expires April 24, 2017 [Page 2]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 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]), which builds on CBOR [RFC7049].
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
CBOR and COSE objects. The DH key exchange messages may be
authenticated using either pre-shared keys (PSK), raw public keys
(RPK) or X.509 certificates (Cert). 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 shared key material.
The DH exchange and the key derviation follow [SIGMA], SP-800-56a
[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. The messages in the authenticated message
exchange are called "message_1", "message_2", and "message_3".
TBD
2. Protocol Overview
This section gives an overview of EDHOC, together with Section 4.3
and Section 5.3, which explains how the messages are processed, while
Section 4.1 and Section 5.1 focus on the detailed message formats
Selander, et al. Expires April 24, 2017 [Page 3]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
embedded as CBOR objects, and Section 4.2, Section 5.2, and Section 6
specify the key derivation.
EDHOC is built on the SIGMA family of protocols, with the basic
protocol specified in Section 5, here in variant (ii) as in
Section 5.4, of [SIGMA], see Figure 1.
Party U Party V
| |
| |
| E_U |
+------------------------------------------------------>|
| |
| E_V, ID_V, Sig(V; Mac(Km; E_U, E_V, ID_V)) |
|<------------------------------------------------------+
| |
| ID_U, Sig(U; Mac(Km; E_V, E_U, ID_U)) |
+------------------------------------------------------>|
| |
Figure 1: The basic SIGMA protocol
U and V exchange identities and ephemeral public keys E_U, E_V. They
compute the shared secret and derive the keying material. The
messages are signed and MAC:ed according to the SIGMA protocol:
o Mac(Km; . ) denote message authentication using keys derived from
the shared secret
o Sig(U; . ) and Sig(V; . ) denote signatures made with the private
key of U and V, respectively.
o ID_U and ID_V are used to identify U and V, respectively. In case
of public key certificate, C_U and C_V are used instead.
The protocol used with PSK is based on the basic SIGMA protocol. The
underlying scheme for asymmetric keys is the SIGMA-I protocol as
specified in Section 5.2, with variant (ii) in Section 5.4, of
[SIGMA], see Figure 2. This protocol adds encryption which is
required for identity protection in the asymmetric key case:
o Enc(Ke; .) denote encryption using keys derived from the shared
secret
Selander, et al. Expires April 24, 2017 [Page 4]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
Party U Party V
| |
| |
| E_U |
+------------------------------------------------------>|
| |
| E_V, Enc(Ke; ID_V, Sig(V; Mac(Km; E_U, E_V, ID_V))) |
|<------------------------------------------------------+
| |
| Enc(Ke; ID_U, Sig(U; Mac(Km; E_V, E_U, ID_U))) |
+------------------------------------------------------>|
| |
Figure 2: The SIGMA-I protocol
The protocols are detailed further in the following sections.
3. 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
4. Asymmetric Keys
In this section we assume that the protocol messages are
authenticated with asymmetric keys. Both the scenarios where the
parties use raw public keys (RPK) and X.509 certificates (Cert) are
supported.
o Party U's public key SHALL be uniquely identified at V by ID_U.
Selander, et al. Expires April 24, 2017 [Page 5]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
o Party V's public key SHALL be uniquely identified at U by ID_V.
ID_U and ID_V may be public key certificates [SIGMA], which we then
denote as C_U and C_V, respectively.
The pre-established credentials may thus be the public keys of U at
V, and of V at U. Alternatively, a pre-established public key of a
Certificate Authority (CA) may be used as trust anchor for
verification of received certificate.
The protocol is based on SIGMA-I (Section 2). As described in
Appendix B of [SIGMA], in order to create a "full-fledge" protocol
some additional protocol elements are needed:
o Explicit freshness nonces/session identifiers N_U, N_V chosen
freshly and anew with each session by U and V, respectively
o Computationally independent keys K_UE, K_UM, K_VE, K_VM derived
from the DH-shared secret and used for different directions and
operations.
EDHOC makes the following additions to this scheme (see Figure 3):
o Negotiation of algorithms used: AEAD-, signature- and MAC-
algorithm used in the protocol, and ECDH ES w/ HKDF algorithm used
in the key derivation:
* U proposes one or more algorithms (Alg_U).
* V decides and responds with selected algorithms (Alg_V).
* Subsequent traffic is protected with the AEAD agreed in this
negotiation.
Selander, et al. Expires April 24, 2017 [Page 6]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
Party U Party V
| |
| N_U, E_U, Alg_U |
+---------------------------------------------------------------> |
| message_1 |
| |
| |
| N_U, N_V, E_V, Alg_V, Enc(K_VE; ID_V, Sig(V; Mac(K_VM; prot_2)))|
| <---------------------------------------------------------------+
| message_2 |
| |
| |
| N_U, N_V, Enc(K_UE; ID_U, Sig(U; Mac(K_UM; prot_3))) |
+---------------------------------------------------------------> |
| message_3 |
| |
where prot_2 = N_U, N_V, E_V, Alg_V, ID_V
and prot_3 = N_U, N_V, E_U, Alg_U, ID_U
Figure 3: EDHOC with asymmetric keys.
4.1. Message Formatting using COSE
This section details the format for the objects used. Examples are
provided for each object in Appendix A.
Note that * identifies fields that do not exist in COSE structures
([I-D.ietf-cose-msg]), and are thus defined in this document.
4.1.1. Message 1
This section defines the formatting of message_1.
message_1 is a CBOR array object containing:
o N_U: nonce
o E_U: the ephemeral public key of Party U
o ECDH_arr: an array of proposed ECDH ES w/ HKDF algorithms
o AEAD_arr: an array of proposed AEAD algorithms
o SIG_arr: an array of proposed Signature algorithms
o MAC_arr: an array of proposed MAC algorithms
Selander, et al. Expires April 24, 2017 [Page 7]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
message_1 = [
N_U : bstr,
E_U : COSE_Key,
ALG_U : alg_arr
]
alg_arr = [
ECDH_arr : alg_array,
AEAD_arr : alg_array,
SIG_arr : alg_array,
MAC_arr : alg_array
]
alg_array = [ + alg : bstr/int ]
4.1.2. Message 2
In case of asymmetric keys, message_2 SHALL have the COSE_Encrypt
structure [I-D.ietf-cose-msg] with the following fields and values:
o Headers:
* protected:
+ alg: AEAD, the Authenticated Encryption with Additional Data
algorithm chosen by Party V from the set of proposed
algorithms AEAD_arr
* unprotected:
+ nonces*: nonce-array
o ciphertext: over the plaintext defined below
o recipient:
* Headers:
+ protected: ECDH-ES + HKDF algorithm chosen by Party V from
the set of proposed algorithms ECDH_arr (table 18 in
[I-D.ietf-cose-msg])
+ unprotected:
- E_V: COSE_Key
+ ciphertext: empty
Selander, et al. Expires April 24, 2017 [Page 8]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
nonce-array = [
N_U: bstr,
N_V: bstr
]
The plaintext for message_2 SHALL have the COSE_Sign1 structure
[I-D.ietf-cose-msg] with the following fields and values:
o Headers
* protected
+ alg: SIG, the Sign algorithm chosen by Party V from the set
of proposed algorithms SIG_arr
+ MAC-alg*: MAC, the MAC algorithm chosen by Party V from the
set of proposed algorithms MAC_arr
* Unprotected:
+ kid: ID_V (if raw public keys are used) or
+ x5c*: C_V (if certificates are used)
o detached payload: as defined below
o signature: computed as in Section 4.4 of [I-D.ietf-cose-msg]
The payload for COSE_Sign1 SHALL have the COSE_MAC0 structure
[I-D.ietf-cose-msg] with the following fields and values:
o Headers
* protected
+ alg: MAC (same value as MAC-alg in COSE_Sign1 structure
above)
* unprotected: empty
o payload: payl_2_rpk (resp payl_2_cert) as defined below if raw
public keys (resp certificates) are used
o tag
Selander, et al. Expires April 24, 2017 [Page 9]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
payl_2_rpk = [
N_U: bstr,
N_V: bstr,
E_V: COSE_Key,
ID_V: bstr
]
payl_2_cert = [
N_U: bstr,
N_V: bstr,
E_V: COSE_Key,
C_V: bstr
]
4.1.3. Message 3
In case of asymmetric keys, message_3 SHALL have the COSE_Encrypt0
structure [I-D.ietf-cose-msg] with the following fields and values:
o Headers:
* protected:
+ alg: AEAD
* unprotected:
+ nonces*: nonce-array
o ciphertext: over the plaintext defined below
The plaintext for message_3 SHALL have the COSE_Sign1 structure
[I-D.ietf-cose-msg] with the following fields and values:
o Headers
* protected
+ alg: SIG
+ MAC-alg*: MAC
* Unprotected:
+ kid: ID_U (if raw public keys are used) or
+ x5c*: C_U (if certificates are used)
Selander, et al. Expires April 24, 2017 [Page 10]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
o detached payload: as defined below
o signature: computed as in Section 4.4 of [I-D.ietf-cose-msg]
The payload for COSE_Sign1 SHALL have the COSE_MAC0 structure
[I-D.ietf-cose-msg] with the following fields and values:
o Headers
* protected
+ alg: MAC (same value as MAC-alg in COSE_Sign1 structure
above)
* unprotected: empty
o payload: payl_3_rpk (resp payl_3_cert) as defined below if raw
public keys (resp certificates) are used
o tag
payl_3_rpk = [
N_V : bstr,
N_U : bstr,
E_U : COSE_Key,
ALG_U : alg_arr,
ID_V : bstr
]
payl_3_cert = [
N_V : bstr,
N_U : bstr,
E_U : COSE_Key,
ALG_U : alg_arr,
C_V : bstr
]
4.2. Key Derivation with Asymmetric Keys
It is described in this section how the keys for encryption (K_UE,
K_VE) and MAC (K_UM, K_VM) are derived.
Party U and Party V SHALL derive K_UE, K_VE, K_UM, and K_VM from the
information available in message_1 and message_2 through the key
exchange, as described in this section.
Selander, et al. Expires April 24, 2017 [Page 11]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
The key derivation is identical to Section 11 of [I-D.ietf-cose-msg],
using HKDF [RFC5869] agreed as part of the ECDH ES w/ HKDF
negociation 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 the concatenation of N_U and N_V.
o the length SHALL be the length of the key, depending on the
algorithm used.
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 AEAD (to derive K_UE and K_VE) or MAC
(to derive K_UM and K_VM)
o PartyUInfo SHALL contain:
* nonce SHALL be equal to N_U
o PartyVInfo SHALL contain:
* nonce SHALL be equal to N_V
* identity SHALL be ID_V (resp C_V) if raw public keys (resp.
certificates) are used
o SuppPubInfo SHALL contain:
* KeyDataLength SHALL be equal to 'length'
* protected SHALL be a zero length bstr
* other SHALL contain the HMAC (as defined by the agreed HKDF) of
the concatenation of message_1, the COSE Headers of
COSE_Encrypt (message_2) and the string "PartyU" (resp
"PartyV") to derive K_UE or K_UM (resp K_VE or K_VM)
Selander, et al. Expires April 24, 2017 [Page 12]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
o SuppPrivInfo SHALL be empty
The key derivation is done using the following context information
COSE_KDF_Context for asymmetric keys:
COSE_KDF_Context = [
AlgorithmID : AEAD / MAC,
PartyUInfo : [ PartyInfo_U ],
PartyVInfo : [ PartyInfo_V ],
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; Hash(message_1 ||
unprotected of COSE_Encrypt
(message_2) ||
"PartyU"/"PartyV")
]
]
PartyInfo_U = (
nonce : N_U
)
PartyInfo_V = (
nonce : N_V
)
Using the different combination of these parameters creates the four
keys K_UE, K_UM, K_VE and K_VM when raw public keys or certificates
are used.
For example, to derive K_UE while asymmetric keys are used, the
context MUST include:
o AEAD as Algorithm ID
o "PartyU" as the chosen string in SuppPubInfo other
4.3. Message Processing
Party U and V are assumed to have pre-established credentials as
described in Section 4.
4.3.1. U -> message_1
Party U processes message_1 for party V as follows:
Selander, et al. Expires April 24, 2017 [Page 13]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
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.
o Party U SHALL generate a pseudo-random 64-bits nonce N_U and store
it for the length of the protocol, for future verifications.
o Party U SHALL set the proposed algorithms for communicating with
party V.
o Party U SHALL format message_1 as specified in Section 4.1.1.
o Party U sends message_1 to party V.
4.3.2. message_1 -> V
Party V processes the received message_1 as follows:
o Party V SHALL verify that the nonce has not been received before.
If the verification fails, the message MUST be discarded.
Otherwise, Party V SHALL store a representation of the nonce for
future verifications.
o Party V SHALL select a set of algorithms (AEAD, SIG, MAC, and
ECDH-ES) compliant with its security policy for communicating with
U. If no compliant algorithm was proposed by Party U, Party V
SHALL stop processing the message and MAY respond with an error,
indicating that no common algorithm could be found.
4.3.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.
* The ephemeral public key, E_V, SHALL be formatted as a COSE_key
as specified in Section 3.
o Party V SHALL generate a pseudo-random 64-bits nonce N_V and store
it for the length of the protocol, for future verifications.
Selander, et al. Expires April 24, 2017 [Page 14]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
o Party V SHALL derive K_UE, K_VE, K_UM and K_VM as defined in
Section 4.2.
o Party V SHALL format message_2 as specified in Section 4.1.2:
o COSE_MAC0 is computed as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_VM and algorithm MAC;
o COSE_Sign1 is computed as defined in section 4.4 of
[I-D.ietf-cose-msg], using the private key of Party V and
algorithm SIG;
o COSE_Encrypt is computed as defined in section 5.3 of
[I-D.ietf-cose-msg], with key K_VE and algorithm AEAD.
o Note that the COSE_Sign1 payload is detached (as defined in
section 4.1 of [I-D.ietf-cose-msg]).
o Note that in case of certificates, the certificate of Party V,
C_V, is sent in place of ID_V
o Party V sends message_2 to party U.
4.3.4. U <- message_2
Party U processes the received message_2 as follows:
o Party U SHALL verify than the received N_U is identical to the
saved nonce N_U.
o Party U SHALL verify that the nonce has not been received before.
If the verification fails, the message MUST be discarded.
Otherwise, Party U SHALL store a representation of the nonce for
future verifications.
o Party U SHALL derive K_UE, K_VE, K_UM and K_VM as defined in
Section 4.2.
o Party U SHALL verify message_2:
* COSE_Encrypt is decrypted and verified as defined in section
5.3 of [I-D.ietf-cose-msg], with key K_VE.
* If the message contains a certificate, party U SHALL verify the
certificate using the pre-established trust anchor and the
revokation verification policies relevant for party U. If the
verification fails the message is discarded.
Selander, et al. Expires April 24, 2017 [Page 15]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
* COSE_MAC0 is computed as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_VM. The result is inserted as
payload of the received COSE_Sign1 (which was sent with
detached payload);
* COSE_Sign1 is verified as defined in section 4.4 of
[I-D.ietf-cose-msg], using the public key of Party V;
* Note that Party U SHALL verify that the algorithms used in
message_2 are taken from the set of proposed algorithms in
message_1, else stop processing the message.
o If the verification of message_2 fails, the message MUST be
discarded and Party U SHALL discontinue the protocol.
4.3.5. U -> message_3
Party U composes message_3 for party V as follows:
o Party U SHALL format message_3 as specified in Section 4.1.3:
o COSE_MAC0 is computed as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_UM and algorithm MAC;
o COSE_Sign1 is computed as defined in section 4.4 of
[I-D.ietf-cose-msg], using the private key of Party U and
algorithm SIG;
o COSE_Encrypt is computed as defined in section 5.3 of
[I-D.ietf-cose-msg], with key K_UE and algorithm AEAD.
o Note that the COSE_Sign1 payload is detached (as defined in
section 4.1 of [I-D.ietf-cose-msg]).
o Note that in case of certificates, the certificate of Party U,
C_U, is sent in place of ID_U
o Party U sends message_3 to party V.
4.3.6. message_3 -> V
Party V processes the received message_3 as follows:
o Party V SHALL verify than the received N_V is identical to the
saved nonce N_V. If the verification fails, the message MUST be
discarded.
o Party U SHALL verify message_3:
Selander, et al. Expires April 24, 2017 [Page 16]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
* COSE_Encrypt is decrypted and verified as defined in section
5.3 of [I-D.ietf-cose-msg], with key K_UE.
* If the message contains a certificate, party U SHALL verify the
certificate using the pre-established trust anchor and the
revokation verification policies relevant for party U. If the
verification fails the message is discarded.
* COSE_MAC0 is computed as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_UM. The result is inserted as
payload of the received COSE_Sign1 (which was sent with
detached payload);
* COSE_Sign1 is verified as defined in section 4.4 of
[I-D.ietf-cose-msg], using the public key of Party U;
* Note that Party V SHALL verify that the set of algorithms sent
in message_3 is the same as sent in message_1, else stop
processing the message.
o If the verification of message_3 fails, the message MUST be
discarded and Party U SHALL discontinue the protocol.
5. Symmetric Keys
In this section we assume that the protocol messages are
authenticated with pre-shared symmetric keys.
Parties U and V are assumed to have a pre-shared uniformly random
key, PSK. The value of the key identifier kid_psk SHALL be unique
for U and V.
The protocol is based on the basic SIGMA protocol (Section 2), but
the signatures Sig(U; . ), Sig(V; . ) are replaced with message
authentication codes MAC(K_UMP; . ), MAC(K_VMP; . ), respectively.
K_UMP and K_VMP are computationally independent keys, associated to U
and V, respectively, and derived from PSK. Also, party U needs to
send kid_psk in message_1 to indicate what PSK that V should use
(kid_psk). In this case identity protection is achieved by
anonymizing the kid_psk (Section 7).
For a specific pre-shared key (and corresponding kid-psk):
o Party U SHALL be identified by ID_U.
o Party V SHALL be identified by ID_V.
Selander, et al. Expires April 24, 2017 [Page 17]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
Since kid-psk is unique, only one additional pre-established bit is
needed to identify the parties.
As in the asymmetric case, some additional protocol elements are
added to the final protocol:
o Explicit freshness nonces/session identifiers N_U, N_V chosen
freshly and anew with each session by U and V, respectively
o Computationally independent keys K_UM, K_VM derived from the DH-
shared secret and used for different directions and operations.
o Negotiation of algorithms:
* MAC-algorithm used in the protocol
* HKDF with hash algorithm used in the key derivation
* AEAD-algorithm used to protect subsequent traffic
* U proposes one or more algorithms (Alg_U).
* V decides and responds with selected algorithms (Alg_V).
Party U Party V
| |
| N_U, E_U, Kid, Alg_U |
+---------------------------------------------------------------> |
| message_1 |
| |
| |
| N_U, N_V, E_V, Kid, ID_V, Alg_V, Mac(K_VMP; Mac(K_VM; prot_2)) |
| <---------------------------------------------------------------+
| message_2 |
| |
| |
| N_U, N_V, Kid, ID_U, Mac(K_UMP; Mac(K_UM; prot_3)) |
+---------------------------------------------------------------> |
| message_3 |
| |
where prot_2 = N_U, N_V, E_V, Kid, ID_V, Alg_V
and prot_3 = N_U, N_V, E_U, Kid, ID_U, Alg_U
Figure 4: EDHOC with symmetric keys.
Selander, et al. Expires April 24, 2017 [Page 18]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
5.1. Message Formatting using COSE
This section details the format for the objects used. Examples are
provided for each object in Appendix A.
Note that * identifies fields that do not exist in COSE structures
([I-D.ietf-cose-msg]), and are thus defined in this document.
5.1.1. Message 1
This section defines the formatting of message_1.
message_1 is a CBOR array object containing:
o N_U: nonce
o E_U: the ephemeral public key of Party U
o kid_psk: identifier of the pre-shared key
o ECDH_arr: an array of proposed ECDH ES w/ HKDF algorithms
o AEAD_arr: an array of proposed AEAD algorithms
o MAC_arr: an array of proposed MAC algorithms
message_1 = [
N_U : bstr,
E_U : COSE_Key,
kid_psk: bstr,
ALG_U : alg_arr
]
alg_arr = [
ECDH_arr : alg_array,
AEAD_arr : alg_array,
MAC_arr : alg_array
]
alg_array = [
+ alg : bstr/int
]
5.1.2. Message 2
In case of pre-shared key, message_2 SHALL have the COSE_MAC
structure [I-D.ietf-cose-msg] with the following fields and values:
Selander, et al. Expires April 24, 2017 [Page 19]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
o Headers:
* protected:
+ alg: MAC
* unprotected:
+ nonces*: nonce-array
+ kid: kid_psk
+ sid*: ID_V
+ AEAD-alg*: AEAD
o detached payload: defined below
o tag: calculated as in section 6.3 of [I-D.ietf-cose-msg]
o recipient:
* Headers:
+ protected: ECDH-ES + HKDF algorithm chosen by Party V from
the set of proposed algorithms ECDH_arr (table 18 in
[I-D.ietf-cose-msg])
+ unprotected:
- E_U: COSE_Key
+ ciphertext: empty
nonce-array = [
N_U: bstr,
N_V: bstr
]
The payload for message_2 SHALL have the COSE_MAC0 structure
[I-D.ietf-cose-msg] with the following fields and values:
o Headers
* protected
+ alg: MAC (same value as MAC in COSE_MAC structure above)
Selander, et al. Expires April 24, 2017 [Page 20]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
* unprotected: empty
o payload: payl_2_psk as defined below
o tag: calculated as in section 6.3 of [I-D.ietf-cose-msg]
payl_2_psk = [
N_U: bstr,
N_V: bstr,
E_V: COSE_Key,
KID: bstr, ; has value kid_psk
ID_V: bstr,
ALG_V: alg_arr
]
5.1.3. Message 3
In case of symmetric keys, message_3 SHALL have the COSE_MAC0
structure [I-D.ietf-cose-msg] with the following fields and values:
o Headers:
* protected:
+ alg: MAC
* unprotected:
+ nonces*: nonce-array
+ kid: kid_psk
+ sid*: ID_U
o detached payload: defined below
o tag: calculated as in section 6.3 of [I-D.ietf-cose-msg]
The payload for message_3 SHALL have the COSE_MAC0 structure
[I-D.ietf-cose-msg] with the following fields and values:
o Headers
* protected
+ alg: MAC (same value as in COSE_MAC0 structure above)
* unprotected: empty
Selander, et al. Expires April 24, 2017 [Page 21]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
o payload: payl_3_psk as defined below
o tag: calculated as in section 6.3 of [I-D.ietf-cose-msg]
payl_3_psk = [
N_U: bstr,
N_V: bstr,
E_U: COSE_Key,
KID: bstr, ; has value kid_psk
ID_V: bstr,
ALG_U : alg_arr
]
5.2. Key Derivation with Symmetric Keys
It is described in this section how the keys for MAC (K_UM, K_VM,
K_UMP, K_VMP) are derived.
Party U and Party V SHALL derive K_UM, K_VM, K_UMP and K_VMP from the
information available in message_1 and message_2 through the key
exchange, as described in this section.
The key derivation is identical to Section 4.2, with 3 differences: *
to derive K_UM and K_VM, 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] * to
derive K_UMP and K_VMP, the secret SHALL be the pre-shared key * The
COSE_KDF_Context SHALL be the serialized COSE_KDF_Context defined in
the next paragraph.
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 MAC.
o PartyUInfo SHALL contain:
* nonce SHALL be equal to N_U
o PartyVInfo SHALL contain:
* nonce SHALL be equal to N_U
o SuppPubInfo SHALL contain:
* KeyDataLength SHALL be equal to 'length'
* protected SHALL be a zero length bstr
Selander, et al. Expires April 24, 2017 [Page 22]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
* other SHALL contain the HMAC (as defined by the agreed HKDF) of
the concatenation of message_1, the COSE Headers of message_2
and the string "PartyU" (resp "PartyV") to derive K_UM or K_UMP
(resp K_VM or K_VMP)
o SuppPrivInfo SHALL be empty
The key derivation is done using the following context information
COSE_KDF_Context for asymmetric keys:
COSE_KDF_Context = [
AlgorithmID : AEAD / MAC,
PartyUInfo : [ PartyInfo_U_psk ],
PartyVInfo : [ PartyInfo_V_psk ],
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; Hash(message_1 ||
COSE Headers message_2 ||
"PartyU"/"PartyV")
]
]
PartyInfo_U_psk = (
nonce : N_U
)
PartyInfo_V_psk = (
nonce : N_V
identity: ID_V
)
In practice, the difference in deriving K_UM or K_VM is in the
SuppPubInfo string: to derive K_UM the context MUST include "PartyU",
while to derive K_VM the context MUST include "PartyV".
5.3. Message Processing
Party U and V are assumed to have pre-established credentials as
described in Section 5.
5.3.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
Selander, et al. Expires April 24, 2017 [Page 23]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
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.
o Party U SHALL generate a pseudo-random 64-bits nonce N_U and store
it for the length of the protocol, for future verifications.
o Party U SHALL set the proposed algorithms for communicating with
party V.
o Party U SHALL format message_1 as specified in Section 5.1.1.
o Party U sends message_1 to party V.
5.3.2. message_1 -> V
Party V processes the received message_1 as follows:
o Party V SHALL verify that the nonce has not been received before.
If the verification fails, the message MUST be discarded.
Otherwise, Party V SHALL store a representation of the nonce for
future verifications.
o Party V SHALL select a set of algorithms (AEAD, MAC, and ECDH-ES)
compliant with its security policy for communicating with U. If
no compliant algorithm was proposed by Party U, Party V SHALL stop
processing the message and MAY respond with an error, indicating
that no common algorithm could be found.
5.3.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.
* The ephemeral public key, E_V, SHALL be formatted as a COSE_key
as specified in Section 3.
o Party V SHALL generate a pseudo-random 64-bits nonce N_V and store
it for the length of the protocol, for future verifications.
o Party V SHALL derive K_UM, K_VM, K_UMP and K_VMP as defined in
Section 5.2.
Selander, et al. Expires April 24, 2017 [Page 24]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
o Party V SHALL format message_2 as specified in Section 5.1.2:
o COSE_MAC0 is computed as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_VM and algorithm MAC;
o COSE_MAC is computed as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_VMP and algorithm MAC.
o Note that the COSE_MAC payload is detached (as defined in section
6.1 of [I-D.ietf-cose-msg]).
o Party V sends message_2 to party U.
5.3.4. U <- message_2
Party U processes the received message_2 as follows:
o Party U SHALL verify than the received N_U is identical to the
saved nonce N_U.
o Party U SHALL verify that the nonce has not been received before.
If the verification fails, the message MUST be discarded.
Otherwise, Party U SHALL store a representation of the nonce for
future verifications.
o Party U SHALL derive K_UM, K_VM, K_UMP and K_VMP as defined in
Section 5.2.
o Party U SHALL verify message_2:
* COSE_MAC0 is computed as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_VM. The result is inserted as
payload of the received COSE_MAC (which was sent with detached
payload);
* COSE_MAC is verified as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_VMP and algorithm MAC;
* Note that Party U SHALL verify that the MAC algorithm used and
the AEAD algorithm sent in message_2 are taken from the set of
proposed algorithms in message_1, else stop processing the
message.
o If the verification of message_2 fails, the message MUST be
discarded and Party U SHALL discontinue the protocol.
Selander, et al. Expires April 24, 2017 [Page 25]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
5.3.5. U -> message_3
Party U composes message_3 for party V as follows:
o Party U SHALL format message_3 as specified in Section 5.1.3:
o COSE_MAC0 (containing payl_3_psk) is computed as defined in
section 6.3 of [I-D.ietf-cose-msg], with key K_UM and algorithm
MAC;
o COSE_MAC0 is computed as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_UMP and algorithm MAC.
o Note that the second COSE_MAC0 payload is detached (as defined in
section 6.1 of [I-D.ietf-cose-msg]).
o Party U sends message_3 to party V.
5.3.6. message_3 -> V
Party V processes the received message_3 as follows:
o Party V SHALL verify than the received N_V is identical to the
saved nonce N_V. If the verification fails, the message MUST be
discarded.
o Party U SHALL verify message_3:
* COSE_MAC0 (containing payl_3_psk) is computed as defined in
section 6.3 of [I-D.ietf-cose-msg], with key K_UM. The result
is inserted as payload of the received COSE_MAC0 (which was
sent with detached payload);
* COSE_MAC0 is verified as defined in section 6.3 of
[I-D.ietf-cose-msg], with key K_UMP and algorithm MAC;
* Note that by verifying message_3, Party V ensures that
message_1 was not modified in transit.
o If the verification of message_3 fails, the message MUST be
discarded and Party U SHALL discontinue the protocol.
6. Derive Traffic Secret
It is described in this section how the traffic secret for further
communication is derived, based on the messages exchanged.
Selander, et al. Expires April 24, 2017 [Page 26]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
Party U and Party V SHALL derive the traffic secret (base_key) from
the information available in message_1, message_2 and message_3
through the key exchange, as described in this section.
The key derivation is identical to Section 11 of [I-D.ietf-cose-msg],
using HKDF [RFC5869] agreed as part of the ECDH ES w/ HKDF
negociation 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 the concatenation of N_U and N_V.
o the length SHALL be the length of the key, depending on the AEAD
algorithm with which the base_key will be used.
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 AEAD algorithm for which the key material
will be derived.
o PartyUInfo SHALL contain:
* nonce SHALL be equal to N_U
* identity SHALL be ID_U (resp C_U) if raw public keys (resp.
certificates) are used
o PartyVInfo SHALL contain:
* nonce SHALL be equal to N_V
* identity SHALL be ID_V (resp C_V) if raw public keys (resp.
certificates) are used
o SuppPubInfo SHALL contain:
* KeyDataLength SHALL be equal to 'length'
* protected SHALL be a zero length bstr
Selander, et al. Expires April 24, 2017 [Page 27]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
* other SHALL contain the HMAC (as defined by the agreed HKDF) of
the concatenation of message_1, message_2 and message_3.
o SuppPrivInfo SHALL be empty
The key derivation is done using the following context information
COSE_KDF_Context:
COSE_KDF_Context = [
AlgorithmID : AEAD,
PartyUInfo : [ PartyInfo_U ],
PartyVInfo : [ PartyInfo_V ],
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; Hash(message_1 ||
message_2 ||
message_3)
]
]
PartyInfo_U = (
nonce : N_U,
identity: ID_U / C_U
)
PartyInfo_V = (
nonce : N_V,
identity: ID_V / C_V
)
An example of key derivation for the traffic secret is given in TODO.
7. Security Considerations
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.
TODO: Expand on the security considerations in a future version of
the draft
Selander, et al. Expires April 24, 2017 [Page 28]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
8. Privacy Considerations
TODO
9. IANA Considerations
10. Acknowledgments
The authors wants to thank Ilari Liusvaara, Jim Schaad and Ludwig
Seitz for reviewing previous versions of the draft.
11. References
11.1. Normative References
[I-D.ietf-cose-msg]
Schaad, J., "CBOR Object Signing and Encryption (COSE)",
draft-ietf-cose-msg-20 (work in progress), October 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>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and Its Use in the IKE-
Protocols", Advances in Cryptology - CRYPTO 2003, 23rd
Annual International Cryptology Conference, Santa Barbara,
California, USA, August 17-21, 2003, Proceedings, August
2003, <http://dx.doi.org/10.1007/978-3-540-45146-4_24>.
[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>.
11.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.
Selander, et al. Expires April 24, 2017 [Page 29]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 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.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-ietf-core-
object-security-00 (work in progress), October 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 5, using CBOR's diagnostic notation. In this
example, the ephemeral key is identified by a 4 bytes 'kid'.
Selander, et al. Expires April 24, 2017 [Page 30]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
/ ephemeral / -1:{
/ kty / 1:2,
/ kid / 2:h'78f67901',
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590b
bfbf054e1c7b4d91d6280',
/ y / -3:true
}
Figure 5: 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.
More examples TBD
Appendix B. Implementing EDHOC with CoAP and OSCOAP
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. EDHOC and OSCOAP
[I-D.ietf-core-object-security] could be run in sequence embedded in
a 2-round trip message exchange, where the base_key used in OSCOAP is
obtained from EDHOC.
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 protocol as
specified in this document. If successful, then the server provides
the following response:
o The response Code is 2.04 (Changed)
o The Payload is message_2
The CoAP client verifies the message_2 as specified in this document.
If successful, the client generates the OSCOAP request, and includes
Selander, et al. Expires April 24, 2017 [Page 31]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) October 2016
message_3 in the unprotected part of the COSE Headers of the OSCOAP
COSE object.
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 April 24, 2017 [Page 32]