[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13

ACE Working Group                                            G. Selander
Internet-Draft                                               J. Mattsson
Intended status: Standards Track                            F. Palombini
Expires: May 4, 2017                                         Ericsson AB
                                                        October 31, 2016


               Ephemeral Diffie-Hellman Over COSE (EDHOC)
                    draft-selander-ace-cose-ecdhe-04

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 May 4, 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 May 4, 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  . . . . . . . . . . . . . . . . . . .  24
       5.3.1.  U -> message_1  . . . . . . . . . . . . . . . . . . .  24
       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 . . . . . . . . . . . . . . . . . . . .  27
   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 . . . . . . . . . . . . . . . . .  30
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  31
     A.1.  ECDH Public Key . . . . . . . . . . . . . . . . . . . . .  31
     A.2.  Example with Asymmetric Keys (RPK)  . . . . . . . . . . .  31
       A.2.1.  Message 1 . . . . . . . . . . . . . . . . . . . . . .  31
       A.2.2.  Message 2 . . . . . . . . . . . . . . . . . . . . . .  32
       A.2.3.  Message 3 . . . . . . . . . . . . . . . . . . . . . .  35
     A.3.  Example with Symmetric Keys (PSK) . . . . . . . . . . . .  36
       A.3.1.  Message 1 . . . . . . . . . . . . . . . . . . . . . .  36



Selander, et al.           Expires May 4, 2017                  [Page 2]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


       A.3.2.  Message 2 . . . . . . . . . . . . . . . . . . . . . .  37
       A.3.3.  Message 3 . . . . . . . . . . . . . . . . . . . . . .  40
   Appendix B.  Implementing EDHOC with CoAP and OSCOAP  . . . . . .  41
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44

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].  Note that this document focuses on
   authentication and key establishment: for integration with
   authorization of resource access, refer to
   [I-D.seitz-ace-oscoap-profile].  This document also specifies the
   derivation of shared key material.

   The DH exchange and the key derviation follow [SIGMA], NIST 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.

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 May 4, 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

   The parties exchanging messages are called "U" and "V".  U and V
   exchange identities and ephemeral public keys.  They compute the
   shared secret and derive the keying material.  The messages are
   signed and MAC:ed according to the SIGMA protocol (Figure 1):

   o  E_U and E_V are the ECDH ephemeral public keys 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.

   o  Sig(U; . ) and Sig(V; . ) denote signatures made with the private
      key of U and V, respectively.

   o  Mac(Km; . ) denote message authentication using keys derived from
      the shared secret

   EDHOC used with symmetric keys is based on the basic SIGMA protocol.
   The underlying scheme for EDHOC using 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 May 4, 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  crv: The value of the Curve used.

   o  x:

   o  y: The value SHOULD be boolean.

   For the field 'crv', refer to Table 22 of [I-D.ietf-cose-msg].  The
   value 1 MUST be supported by party V (NIST P-256 a.k.a. secp256r1
   [RFC4492]).

   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 May 4, 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 May 4, 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_V, N_U, 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 map 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 May 4, 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: encrypted plaintext as 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 May 4, 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 May 4, 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: encrypted plaintext as 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 May 4, 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 May 4, 2017                 [Page 11]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   The key derivation is identical to Section 11.1 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

   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)

   o  SuppPrivInfo SHALL be empty





Selander, et al.           Expires May 4, 2017                 [Page 12]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   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 ||
                                            COSE Headers 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 when 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:

   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 May 4, 2017                 [Page 13]


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 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.

   o  Party V SHALL derive K_UE, K_VE, K_UM and K_VM as defined in
      Section 4.2.




Selander, et al.           Expires May 4, 2017                 [Page 14]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   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.

      *  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




Selander, et al.           Expires May 4, 2017                 [Page 15]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


         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_Encrypt0 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_U and N_V are identical
      to the saved nonces N_U and N_V.  If the verification fails, the
      message MUST be discarded.

   o  Party V SHALL verify message_3:





Selander, et al.           Expires May 4, 2017                 [Page 16]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


      *  COSE_Encrypt0 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 V 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 V 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 the key identifier in message_1 to indicate what PSK that V
   should use (kid_psk).  In this case identity protection is achieved
   by anonymizing the kid (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 May 4, 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_V, N_U, E_U, Kid, ID_U, Alg_U

                   Figure 4: EDHOC with symmetric keys.





Selander, et al.           Expires May 4, 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 map object containing:

   o  N_U: nonce

   o  E_U: the ephemeral public key of Party U

   o  KID: identifier of the pre-shared key (it's value is kid_psk)

   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: 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 May 4, 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 May 4, 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_array  ; (ECDH, AEAD, MAC)
     ]

   Note that ALG_V contains the set of chosen algorithms, in order ECDH,
   AEAD, MAC, selected from the list provided in ALG_U.

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




Selander, et al.           Expires May 4, 2017                 [Page 21]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


         +  alg: MAC (same value as in COSE_MAC0 structure above)

      *  unprotected: empty

   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_V: bstr,
     N_U: 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:

   o  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]

   o  to derive K_UMP and K_VMP, the secret SHALL be the pre-shared key

   o  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:



Selander, et al.           Expires May 4, 2017                 [Page 22]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


      *  nonce SHALL be equal to N_V

      *  identity SHALL be equal to ID_V

   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 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 symmetric keys:

      COSE_KDF_Context = [
          AlgorithmID : 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 of COSE_MAC
                                             (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".





Selander, et al.           Expires May 4, 2017                 [Page 23]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


5.3.  Message Processing

   Party U and V are assumed to have pre-established credentials as
   previously 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
      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.  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:






Selander, et al.           Expires May 4, 2017                 [Page 24]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   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.

   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);




Selander, et al.           Expires May 4, 2017                 [Page 25]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


      *  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.

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_U and N_V are identical
      to the saved nonces N_U and N_V.  If the verification fails, the
      message MUST be discarded.

   o  Party V 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;





Selander, et al.           Expires May 4, 2017                 [Page 26]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


      *  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 V 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.

   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.1 of
   [I-D.ietf-cose-msg], using HKDF [RFC5869] agreed as part of the ECDH-
   ES w/ HKDF negotiation 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:



Selander, et al.           Expires May 4, 2017                 [Page 27]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


      *  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, 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
       )

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.



Selander, et al.           Expires May 4, 2017                 [Page 28]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   The choice of key length used in the different algorithms needs to be
   harmonized, so that right security level is maintained throughout the
   calculations.

   Note that, depending on the use, the key established through the
   EDHOC protocol will need to be renewed, in which case the
   communicating parties need to run the protocol again.

   In case of symmetric keys, the key identifier for the pre-shared
   secret identifies one party to the other.  The kid may reveal
   information about the communicating parties to others.  The
   communicating parties may protect against this by anonymizing the kid
   either only initially or between each run of the protocol.

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-23 (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>.



Selander, et al.           Expires May 4, 2017                 [Page 29]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   [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.

   [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-04 (work in progress), October 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.

   [I-D.seitz-ace-oscoap-profile]
              Seitz, L., "OSCOAP profile of ACE", draft-seitz-ace-
              oscoap-profile-00 (work in progress), 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>.







Selander, et al.           Expires May 4, 2017                 [Page 30]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   [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

   In this section we give examples of messages used in the protocol for
   the pre-shared key case and for the raw public keys case.  Note that
   the message size is not optimized, for example the labels could be
   registered and thereby reducing the overhead.

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.

      / ephemeral / -1:{
                  / kty / 1:2,
                  / 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'a120a40102200121582098f50a4ff6c058
   61c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5', which has a
   size of 44 bytes.

A.2.  Example with Asymmetric Keys (RPK)

   In this example, the identifier of V is 4 bytes.

A.2.1.  Message 1

   An example of COSE encoding for message_1 is given in Figure 6, using
   CBOR's diagnostic notation.

   The message_1 is:










Selander, et al.           Expires May 4, 2017                 [Page 31]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   {
     'N_U':h'5598a57b47db7f2c',
     'E_U':h'a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7
     590bbfbf054e1c7b4d91d628022f5', / COSE_Key E_U { /
       / ephemeral -1:{ /
       / kty 1:2, /
       / crv -1:1, /
       / x -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb /
       / f054e1c7b4d91d6280', /
       / y -3:true /
       / } /
     / } /
     'ALG_U' : h'8481381a810c81268104'
       / [ /
         / [ -27 ], ECDH-SS + HKDF-256 /
         / [ 12 ],  AES-CCM-64-64-128 /
         / [ -7 ],  ES256 /
         / [ 4 ]    HMAC 256-64 /
       / ] /
   }

                      Figure 6: Example of message_1

   The equivalent CBOR encoding of the message_1 is: h'a3434e5f55485598a
   57b47db7f2c43455f55582ca120a40102200121582098f50a4ff6c05861c8860d13a6
   38ea56c3f5ad7590bbfbf054e1c7b4d91d628022f545414c475f554a8481381a810c8
   1268104', which has a size of 81 bytes.  Note that by registering the
   labels 'N_U', 'E_U' and 'ALG_U' to unsigned values the size can be
   reduced to 70 bytes.

A.2.2.  Message 2

   An example of COSE encoding for message_2 is given in Figure 7 using
   CBOR's diagnostic notation.

   The payload of the COSE_MAC0 is:















Selander, et al.           Expires May 4, 2017                 [Page 32]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   [
     h'7ce4cae9c9698bac', / N_V /
     h'5598a57b47db7f2c', / N_U /
     h'a120a501022001215820acbee6672a28340affce41c721901eb
     d7868231bd1d86e41888a07822214050022f5', / COSE_Key E_V { /
       / ephemeral -1:{ /
       / kty 1:2, /
       / crv -1:1, /
       / x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
       / 86e41888a078222140500', /
       / y -3:true /
       / } /
     / } /
     h'0f4907e1' / ID_V /
   ]


   The equivalent CBOR encoding of the payload of the COSE_MAC0 is: h'84
   485598a57b47db7f2c487ce4cae9c9698bac5832a120a401022001215820acbee6672
   a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5440f4907e1
   ', which has a size of 70 bytes.  Note that these bytes are not sent
   in the message.

   The COSE_MAC0 is:

   [
     h'a10104', / protected : {01:04} /
     {}, / unprotected /
     h'84485598a57b47db7f2c487ce4cae9c9698bac5832a120a401022001215820acb
     ee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544
     0f4907e1', / payload /
     MAC / truncated 8-byte MAC /
   ]


   The equivalent CBOR encoding of the COSE_MAC0 is: h'8443a10104a058468
   4485598a57b47db7f2c487ce4cae9c9698bac5832a120a401022001215820acbee667
   2a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5440f4907e
   148'||MAC, which has a size of 87 bytes.  Note that these bytes are
   not sent in the message.

   The COSE_Sign1 is:









Selander, et al.           Expires May 4, 2017                 [Page 33]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   [
     h'a20126474d41432d616c6704', / protected : {1:-7, 'MAC-alg':04} /
     {04:h'00'}, / unprotected /
     h'', / detached payload /
     SIG  / 64-byte signature /
   ]

   The equivalent CBOR encoding of the COSE_Sign1 is:
   h'844ca20126474d41432d616c6704a1044100405840'||SIG, which has a size
   of 85 bytes.  Note that by registering the label 'MAC-alg' to
   unsigned values the size can be reduced to 78 bytes.

   The COSE_Encrypt is:

   [
     h'a1010c', / protected : {1:12} /
     {'nonces':h'82485598a57b47db7f2c487ce4cae9c9698bac'},/unprotected /
       / [ /
         /  h'5598a57b47db7f2c', N_U /
         /  h'7ce4cae9c9698bac' N_V /
       / ] /
     CIPH+TAG, / 85 bytes-cipher text + truncated 8-byte TAG /
     [ / recipients /
       [
         h'a101381a' / protected : {1:-27} / ,
         { / unprotected /
           'E_V':h'a120a401022001215820a
           cbee6672a28340affce41c721901ebd7868231bd1
           d86e41888a07822214050022f5' / COSE_Key E_V { /
             / ephemeral -1:{ /
             / kty 1:2, /
             / crv -1:1, /
             / x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
             / 86e41888a078222140500', /
             / y -3:true /
             / } /
           / } /
         },
         h'' / ciphertext /
       ]
     ]
   ]

                      Figure 7: Example of message_2

   The equivalent CBOR encoding of the COSE_Encrypt is: h'8443a1010ca146
   6e6f6e6365735382485598a57b47db7f2c487ce4cae9c9698bac585b'||CIPH+TAG||
   h'818344a101381aa143455f565832a120a5010202442edb61f92001215820acbee66



Selander, et al.           Expires May 4, 2017                 [Page 34]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   72a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f540',
   which has a size of 187 bytes.  Note that by registering the label
   'MAC-alg' and 'E_V' to unsigned values the size can be reduced to 177
   bytes.

A.2.3.  Message 3

   An example of COSE encoding for message_3 is given in Figure 8 using
   CBOR's diagnostic notation.

   The payload of the COSE_MAC0 is:

   [
     h'7ce4cae9c9698bac', / N_V /
     h'5598a57b47db7f2c', / N_U /
     h'a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
     bf054e1c7b4d91d628022f5', / COSE_Key E_U /
     h'8481381a810c81268104', / ALG_U /
       / [ /
         / [ -27 ], ECDH-SS + HKDF-256 /
         / [ 12 ],  AES-CCM-64-64-128 /
         / [ -7 ],  ES256 /
         / [ 4 ]    HMAC 256-64 /
       / ] /
     h'0f4907e1' / ID_V /
   ]


   The equivalent CBOR encoding of the payload of the COSE_MAC0 is: h'85
   487ce4cae9c9698bac485598a57b47db7f2c582ca120a40102200121582098f50a4ff
   6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f54a8481381a
   810c81268104440f4907e1', which has a size of 81 bytes.  Note that
   these bytes are not sent in the message.

   The COSE_MAC0 is:

   [
     h'a10104', / protected : {01:04} /
     {}, / unprotected /
     h'85487ce4cae9c9698bac485598a57b47db7f2c582ca120a40102200121582098f
     50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f54a
     8481381a810c81268104440f4907e1', / payload /
     MAC / truncated 8-byte MAC /
   ]


   The equivalent CBOR encoding of the COSE_MAC0 is: h'8443a10104a058518
   5487ce4cae9c9698bac485598a57b47db7f2c582ca120a40102200121582098f50a4f



Selander, et al.           Expires May 4, 2017                 [Page 35]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   f6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f54a8481381
   a810c81268104440f4907e148'||MAC, which has a size of 98 bytes.  Note
   that these bytes are not sent in the message.

   The COSE_Sign1 is:

   [
     h'a20126474d41432d616c6704', / protected : {1:-7, 'MAC-alg':4} /
     {04:h'0f4907e1'}, / unprotected /
     h'', / detached payload /
     SIG  / 64-byte signature /
   ]

   The equivalent CBOR encoding of the COSE_Sign1 is:
   h'844ca20126474d41432d616c6704a104440f4907e1405840'||SIG, which has a
   size of 88 bytes.  Note that by registering the label 'MAC-alg' to
   unsigned values the size can be reduced to 81 bytes.

   The COSE_Encrypt0 is:

   [
     h'a1010c', / protected : {01:12} /
     {'nonces':h'82485598a57b47db7f2c487ce4cae9c9698bac'},/unprotected /
       / 'nonces':[ /
         /  h'5598a57b47db7f2c', N_U /
         /  h'7ce4cae9c9698bac' N_V /
       / ] /
     CIPH+TAG / 88 bytes-cipher text + truncated 8-byte TAG /
   ]

                      Figure 8: Example of message_3

   The equivalent CBOR encoding of the COSE_Encrypt0 is: h'8343a1010ca14
   66e6f6e6365735382485598a57b47db7f2c487ce4cae9c9698bac5860'||CIPH+TAG,
   which has a size of 131 bytes.  Note that by registering the labels
   'MAC-alg' and 'nonces' to unsigned values the size can be reduced to
   118 bytes.

A.3.  Example with Symmetric Keys (PSK)

   In this example, the identifiers of U and V are 4 bytes.

A.3.1.  Message 1

   An example of COSE encoding for message_1 is given in Figure 9, using
   CBOR's diagnostic notation.

   The message_1 is:



Selander, et al.           Expires May 4, 2017                 [Page 36]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   {
     'N_U':h'5598a57b47db7f2c',
     'E_U':h'a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7
     590bbfbf054e1c7b4d91d628022f5', / COSE_Key E_U { /
       / ephemeral -1:{ /
       / kty 1:2, /
       / crv -1:1, /
       / x -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb /
       / f054e1c7b4d91d6280', /
       / y -3:true /
       / } /
     / } /
     'KID':h'e19648b5',
     'ALG_U':h'8381381a810c8104'
       / [ /
         / [ -27 ], ECDH-SS + HKDF-256 /
         / [ 12 ],  AES-CCM-64-64-128 /
         / [ 4 ]    HMAC 256-64 /
       / ] /
   }

                      Figure 9: Example of message_1

   The equivalent CBOR encoding of the message_1 is: h'a4434e5f55485598a
   57b47db7f2c43455f55582ca120a40102200121582098f50a4ff6c05861c8860d13a6
   38ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5434b494444e19648b545414c475
   f55488381381a810c8104', which has a size of 88 bytes.  Note that by
   registering the labels 'N_U', 'E_U', 'KID' and 'ALG_U' to unsigned
   values the size can be reduced to 74 bytes.

A.3.2.  Message 2

   An example of COSE encoding for message_2 is given in Figure 10 using
   CBOR's diagnostic notation.

   The payload of the COSE_MAC0 is:















Selander, et al.           Expires May 4, 2017                 [Page 37]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   [
     h'5598a57b47db7f2c', / N_U /
     h'7ce4cae9c9698bac', / N_V /
     h'a120a401022001215820acbee6672a28340affce41c721901eb
     d7868231bd1d86e41888a07822214050022f5', / COSE_Key E_V { /
       / ephemeral -1:{ /
       / kty 1:2, /
       / crv -1:1, /
       / x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
       / 86e41888a078222140500', /
       / y -3:true /
       / } /
     / } /
     h'e19648b5', / KID /
     h'0f4907e1', / ID_V /
     h'83381a0c04' / ALG_V /
       / [ /
         /-27 , ECDH-SS + HKDF-256 /
         / 12 , AES-CCM-64-64-128 /
         / 4    HMAC 256-64 /
       / ] /
   ]


   The equivalent CBOR encoding of the payload of the COSE_MAC0 is: h'86
   485598a57b47db7f2c487ce4cae9c9698bac582ca120a401022001215820acbee6672
   a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544e19648b5
   440f4907e14583381a0c04', which has a size of 81 bytes.  Note that
   these bytes are not sent in the message.

   The COSE_MAC0 is:

   [
     h'a10104', / protected : {01:04} /
     {}, / unprotected /
     h'86485598a57b47db7f2c487ce4cae9c9698bac582ca120a401022001215820acb
     ee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544
     e19648b5440f4907e14583381a0c04', / payload /
     MAC / truncated 8-byte MAC /
   ]


   The equivalent CBOR encoding of the COSE_MAC0 is: h'8443a10104a058518
   6485598a57b47db7f2c487ce4cae9c9698bac582ca120a401022001215820acbee667
   2a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544e19648b
   5440f4907e14583381a0c0448'||MAC, which has a size of 98 bytes.  Note
   that these bytes are not sent in the message.




Selander, et al.           Expires May 4, 2017                 [Page 38]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   The COSE_MAC is:

   [
     h'a10104', / protected : {01:04} /
     { / unprotected /
       'nonces':h'82485598a57b47db7f2c487ce4cae9c9698bac', / 'nonces':[/
         /  h'5598a57b47db7f2c', N_U /
         /  h'7ce4cae9c9698bac' N_V /
         / ] /
         04:h'e19648b5', / KID /
         'sid':h'0f4907e1', / ID_V /
         'AEAD-alg': 12
       },
     h'', / detached payload /
     TAG, / 8-byte truncated tag /
     [ / recipients /
       [
         h'a101381a' / protected : {1:-27} / ,
         { / unprotected /
           'E_V':h'a120a401022001215820a
           cbee6672a28340affce41c721901ebd7868231bd1
           d86e41888a07822214050022f5' / COSE_Key E_V { /
             / ephemeral -1:{ /
             / kty 1:2, /
             / crv -1:1, /
             / x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
             / 86e41888a078222140500', /
             / y -3:true /
             / } /
           / } /
         },
         h'' / ciphertext /
       ]
     ]
   ]

                      Figure 10: Example of message_2

   The equivalent CBOR encoding of the COSE_MAC is:

   h'8543a10104a4466e6f6e6365735382485598a57b47db7f2c487ce4cae9c9698bac0
   444e19648b543736964440f4907e148414541442d616c670c4048||MAC||818344a10
   1381aa143455f56582ca120a401022001215820acbee6672a28340affce41c721901e
   bd7868231bd1d86e41888a07822214050022f540', which has a size of 127
   bytes.  Note that by registering the labels 'nonces', 'sid', 'AEAD-
   alg' and 'E_V' to unsigned values the size can be reduced to 107
   bytes.




Selander, et al.           Expires May 4, 2017                 [Page 39]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


A.3.3.  Message 3

   An example of COSE encoding for message_3 is given in Figure 11 using
   CBOR's diagnostic notation.

   The payload of the COSE_MAC0 is:

   [
     h'5598a57b47db7f2c', / N_U /
     h'7ce4cae9c9698bac', / N_V /
     h'a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c
     3f5ad7590bbfbf054e1c7b4d91d628022f5', / COSE_Key E_U /
     h'e19648b5', / KID /
     h'0f4907e1', / ID_V /
     h'8381381a810c8104'
       / [ /
         / [ -27 ], ECDH-SS + HKDF-256 /
         / [ 12 ],  AES-CCM-64-64-128 /
         / [ 4 ]    HMAC 256-64 /
       / ] /
   ]


   The equivalent CBOR encoding of the payload of the COSE_MAC0 is: h'86
   485598a57b47db7f2c487ce4cae9c9698bac582fa120a40102200121582098f50a4ff
   6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f544e19648b5
   440f4907e1488381381a810c8104', which has a size of 84 bytes.  Note
   that these bytes are not sent in the message.

   The COSE_MAC0 is:

   [
     h'a10104', / protected : {01:04} /
     {}, / unprotected /
     h'86485598a57b47db7f2c487ce4cae9c9698bac582fa120a401022001215
     82098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d6280
     22f544e19648b5440f4907e1488381381a810c8104', / payload /
     MAC / truncated 8-byte MAC /
   ]


   The equivalent CBOR encoding of the COSE_MAC0 is: h'8444a10104a058548
   6485598a57b47db7f2c487ce4cae9c9698bac582fa120a40102200121582098f50a4f
   f6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f544e19648b
   5440f4907e1488381381a810c810448'||MAC, which has a size of 101 bytes.
   Note that these bytes are not sent in the message.

   The COSE_MAC0 is:



Selander, et al.           Expires May 4, 2017                 [Page 40]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   [
     h'a10104', / protected : {01:04} /
     { / unprotected /
       'nonces':h'82485598a57b47db7f2c487ce4cae9c9698bac',
       / [ /
         /  h'5598a57b47db7f2c', N_U /
         /  h'7ce4cae9c9698bac' N_V /
         / ] /
       04:h'e19648b5', / KID /
       'sid':h'dbabb666' / ID_U /
     },
     h'', / detached payload /
     MAC / truncated 8-byte MAC /
   ]

                      Figure 11: Example of message_3

   The equivalent CBOR encoding of the COSE_MAC0 is: h'8443a10104a3466e6
   f6e6365735382485598a57b47db7f2c487ce4cae9c9698bac0444e19648b543736964
   44dbabb6664048'||MAC, which has a size of 58 bytes.  Note that by
   registering the labels 'nonces' and 'sid' to unsigned values the size
   can be reduced to 49 bytes.

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.

   The process to run EDHOC over CoAP, combined with and followed by
   OSCOAP is described here and showed in Figure 12 and Figure 13.

           Client                                        Server
              | ------------- EDHOC message_1 ------------> |
              |                                             |
              | <------------ EDHOC message_2 ------------- |
              |                                             |
              | ---- OSCOAP Request + EDHOC message_3 ----> |
              |                                             |
              | <------------ OSCOAP Response ------------- |
              |                                             |


                        Figure 12: EDHOC and OSCOAP




Selander, et al.           Expires May 4, 2017                 [Page 41]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


             Client    Server
               |          |
               |          |
               +--------->| Header: POST (Code=0.02)
               | POST     | Uri-Path:"edhoc"
               |          | Content-Type: application/cbor
               |          | Payload: EDHOC message_1
               |          |
               |<---------+ Header: 2.04 Changed
               |          | Content-Type: application/cose+cbor
               | 2.05     | Payload: EDHOC message_2
               |          |
               |          |
               +--------->| CoAP message including:
               |  OSCOAP  | Object-Security option
               | request  | COSE_Encrypt0 includes
               |          | EDHOC message_3
               |          |
               |<---------+ CoAP message including:
               |  OSCOAP  | Object-Security option
               | response |
               |          |


                   Figure 13: Detail of EDHOC and OSCOAP

   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 EDHOC message_1, computed as defined in this
      document

   The CoAP server performs the first step of the protocol as specified
   in this document.  Then the server provides the following response:

   o  The response Code is 2.04 (Changed)

   o  The Payload is EDHOC message_2, computed as defined in this
      document

   The CoAP client verifies the message_2 as specified in this document.
   If successful, the client continues the protocol and generates EDHOC
   message_3.



Selander, et al.           Expires May 4, 2017                 [Page 42]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   The client derives OSCOAP Common Context (section 3.1 of
   [I-D.ietf-core-object-security]) from the messages exchanged:

   o  base_key is the traffic secret, output of EDHOC (section 6 of this
      document)

   o  Context Identifier is the HMAC computed over the hash of the
      concatenation of EDHOC message_1, message_2, and message_3 using
      the key base_key: Cid = HMAC(base_key, hash(message_1 ||
      message_2 || message_3))

   o  the Algorithm is the AEAD algorithm negotiated during EDHOC

   Additionally, we define here that:

   o  Sender ID for the CoAP client is set to '0'

   o  Recipient ID for the CoAP client is set to '1'

   With these parameters, the CoAP client can derive the full security
   context, following section 3.2 of [I-D.ietf-core-object-security].

   Finally, the client generates the OSCOAP request, containing the
   Object-Security option and the COSE_Encrypt0 object as defined in
   [I-D.ietf-core-object-security].  EDHOC message_3 is added to the
   unprotected part of the COSE_Encrypt0 Headers, with label 'edhoc_m3'.
   The OSCOAP request is sent, and includes also EDHOC message_3.  Note
   that this may considerably increase the size of the COSE_Encrypt0
   object (see {#ex-rpk3}), so in case the OSCOAP request method does
   not allow payload, the Object-Security option may become large.

   The server receives the message and extract the message_3 from the
   unprotected part of the COSE_Encrypt0 object of the OSCOAP request.
   If the object does not contain the 'edhoc_m3' label, or if the
   'edhoc_m3' value does not comply with the specifications, the message
   is discarded and the communication terminated.  Otherwise, the server
   process and verifies the EDHOC message_3 as described in this
   document.  If successful, the server derives OSCOAP Common Context
   (section 3.1 of [I-D.ietf-core-object-security]) from the messages
   exchanged:

   o  base_key is the traffic secret, output of EDHOC (section 6 of this
      document)

   o  Context Identifier is the HMAC computed over the hash of the
      concatenation of EDHOC message_1, message_2, and message_3 using
      the key base_key: Cid = HMAC(base_key, hash(message_1 ||
      message_2 || message_3))



Selander, et al.           Expires May 4, 2017                 [Page 43]


Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)   October 2016


   o  the Algorithm is the AEAD algorithm negotiated during EDHOC

   Additionally, we define here that:

   o  Sender ID for the CoAP server is set to '1'

   o  Recipient ID for the CoAP server is set to '0'

   With these parameters, the CoAP server can derive the full security
   context, following section 3.2 of [I-D.ietf-core-object-security].

   Finally, the client can verify the OSCOAP request using the security
   context, and act according to [I-D.ietf-core-object-security].
   Further communication can be protected using OSCOAP.

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 May 4, 2017                 [Page 44]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/