Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Göran Selander , John Preuß Mattsson , Francesca Palombini
Last updated 2018-07-02
Replaced by draft-selander-lake-edhoc
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-selander-ace-cose-ecdhe-09
ACE Working Group                                            G. Selander
Internet-Draft                                               J. Mattsson
Intended status: Standards Track                            F. Palombini
Expires: January 3, 2019                                     Ericsson AB
                                                           July 02, 2018

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

Abstract

   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
   compact, and lightweight authenticated Diffie-Hellman key exchange
   with ephemeral keys that can be used over any layer.  EDHOC messages
   are encoded with CBOR and COSE, allowing reuse of existing libraries.

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 https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Selander, et al.         Expires January 3, 2019                [Page 1]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
   3.  EDHOC Overview  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Ephemeral Public Keys . . . . . . . . . . . . . . . . . .   6
     3.2.  Key Derivation  . . . . . . . . . . . . . . . . . . . . .   6
   4.  EDHOC Authenticated with Asymmetric Keys  . . . . . . . . . .   7
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . .  11
     4.4.  EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . .  13
   5.  EDHOC Authenticated with Symmetric Keys . . . . . . . . . . .  15
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.2.  EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . .  15
     5.3.  EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . .  17
     5.4.  EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . .  19
   6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  21
     6.1.  Error Message Format  . . . . . . . . . . . . . . . . . .  21
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     7.1.  The Well-Known URI Registry . . . . . . . . . . . . . . .  21
     7.2.  Media Types Registry  . . . . . . . . . . . . . . . . . .  22
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  25
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  26
   Appendix B.  PSK Chaining . . . . . . . . . . . . . . . . . . . .  26
   Appendix C.  EDHOC with CoAP and OSCORE . . . . . . . . . . . . .  27
     C.1.  Transferring EDHOC in CoAP  . . . . . . . . . . . . . . .  27
     C.2.  Deriving an OSCORE context from EDHOC . . . . . . . . . .  28
   Appendix D.  Message Sizes  . . . . . . . . . . . . . . . . . . .  28
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

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] or where the protocol needs to
   work on a variety of underlying protocols.  IoT devices may be
   constrained in various ways, including memory, storage, processing
   capacity, and energy [RFC7228].  A method for protecting individual
   messages at the application layer suitable for constrained devices,
   is provided by CBOR Object Signing and Encryption (COSE) [RFC8152]),

Selander, et al.         Expires January 3, 2019                [Page 2]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   which builds on the Concise Binary Object Representation (CBOR)
   [RFC7049].

   In order for a communication session to provide forward secrecy, the
   communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH)
   key exchange protocol with ephemeral keys, from which shared key
   material can be derived.  This document specifies Ephemeral Diffie-
   Hellman Over COSE (EDHOC), an authenticated ECDH protocol using CBOR
   and COSE objects.  Authentication is based on credentials established
   out of band, e.g. from a trusted third party, such as an
   Authorization Server as specified by [I-D.ietf-ace-oauth-authz].
   EDHOC supports authentication using pre-shared keys (PSK), raw public
   keys (RPK), and certificates.  Note that this document focuses on
   authentication and key establishment: for integration with
   authorization of resource access, refer to
   [I-D.ietf-ace-oscore-profile].  This document also specifies the
   derivation of shared key material.

   The ECDH exchange and the key derivation follow [SIGMA], NIST SP-
   800-56a [SP-800-56a], and HKDF [RFC5869].  CBOR [RFC7049] and COSE
   [RFC8152] are used to implement these standards.

1.1.  Terminology

   This document uses the Concise Data Definition Language (CDDL)
   [I-D.ietf-cbor-cddl] to express CBOR data structures [RFC7049].  A
   vertical bar | denotes byte string concatenation.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Protocol Overview

   SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
   large number of variants [SIGMA].  Like IKEv2 and TLS 1.3, EDHOC is
   built on a variant of the SIGMA protocol which provide identity
   protection, and like TLS 1.3, EDHOC implements the SIGMA-I variant as
   Sign-then-MAC.  The SIGMA-I protocol using an AEAD algorithm is shown
   in Figure 1.

Selander, et al.         Expires January 3, 2019                [Page 3]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

      Party U                                                 Party V
         |                          E_U                          |
         +------------------------------------------------------>|
         |                                                       |
         |         E_V, Enc(K_2; ID_V, Sig(V; E_U, E_V);)        |
         |<------------------------------------------------------+
         |                                                       |
         |           Enc(K_3; ID_U, Sig(U; E_V, E_U);)           |
         +------------------------------------------------------>|
         |                                                       |

              Figure 1: AEAD variant of the SIGMA-I protocol

   The parties exchanging messages are called "U" and "V".  They
   exchange identities and ephemeral public keys, compute the shared
   secret, and derive the keying material.  The messages are signed,
   MACed, and encrypted.

   o  E_U and E_V are the ECDH ephemeral public keys of U and V,
      respectively.

   o  ID_U and ID_V are identifiers for the public keys of U and V,
      respectively.

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

   o  Enc(K; P; A) denotes AEAD encryption of plaintext P and additional
      authenticated data A using the key K derived from the shared
      secret.  The AEAD MUST NOT be replaced by plain encryption, see
      Section 8.

   As described in Appendix B of [SIGMA], in order to create a "full-
   fledged" protocol some additional protocol elements are needed.
   EDHOC adds:

   o  Explicit session identifiers S_U, S_V different from other
      concurrent session identifiers (EDHOC or other used protocol
      identifier) chosen by U and V, respectively.

   o  Computationally independent keys derived from the ECDH shared
      secret and used for encryption of different messages.

   EDHOC also makes the following additions:

   o  Negotiation of key derivation, encryption, and signature
      algorithms:

Selander, et al.         Expires January 3, 2019                [Page 4]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

      *  U proposes one or more algorithms of the following kinds:

         +  HKDF

         +  AEAD

         +  Signature verification

         +  Signature generation

      *  V selects one algorithm of each kind

   o  Verification of common preferred ECDH curve:

      *  U lists supported ECDH curves in order of preference

      *  V verifies that the ECDH curve of the ephemeral key is the most
         preferred common curve

   o  Transport of opaque application defined data.

   EDHOC is designed to encrypt and integrity protect as much
   information as possible, and all symmetric keys are derived using as
   much previous information as possible.  EDHOC is furthermore designed
   to be as compact and lightweight as possible, in terms of message
   sizes, processing, and the ability to reuse already existing CBOR and
   COSE libraries.  EDHOC does not put any requirement on the lower
   layers and can therefore be also be used e.g. in environments without
   IP.

   This paper is organized as follows: Section 3 specifies general
   properties of EDHOC, including formatting of the ephemeral public
   keys and key derivation, Section 4 specifies EDHOC with asymmetric
   key authentication, Section 5 specifies EDHOC with symmetric key
   authentication, and Appendix A provides a wealth of test vectors to
   ease implementation and ensure interoperability.

3.  EDHOC Overview

   EDHOC consists of three messages (message_1, message_2, message_3)
   that maps directly to the three messages in SIGMA-I, plus an EDHOC
   error message.  All EDHOC messages consists of a CBOR array where the
   first element is an int specifying the message type (MSG_TYPE).
   After creating EDHOC message_3, Party U can derive the traffic key
   (master secret) and protected application data can therefore be sent
   in parallel with EDHOC message_3.  The application data may be
   protected using the negotiated AEAD algorithm and the explicit

Selander, et al.         Expires January 3, 2019                [Page 5]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   session identifiers S_U and S_V.  EDHOC may be used with the media
   type application/edhoc defined in Section 7.

      Party U                                                 Party V
         |                                                       |
         | ------------------ EDHOC message_1 -----------------> |
         |                                                       |
         | <----------------- EDHOC message_2 ------------------ |
         |                                                       |
         | ------------------ EDHOC message_3 -----------------> |
         |                                                       |
         | <----------- Protected Application Data ------------> |
         |                                                       |

                       Figure 2: EDHOC message flow

   The EDHOC message exchange may be authenticated using pre-shared keys
   (PSK), raw public keys (RPK), or certificates.  EDHOC assumes the
   existence of mechanisms (certification authority, manual
   distribution, etc.) for binding identities with authentication keys
   (public or pre-shared).  EDHOC with symmetric key authentication is
   very similar to EDHOC with asymmetric key authentication, the
   difference being that information is only MACed, not signed.

   EDHOC also allows opaque application data (UAD and PAD) to be sent.
   Unprotected Application Data (UAD_1, UAD_2) may be sent in message_1
   and message_2, while Protected Application Data (PAD_3) may be send
   in message_3.

3.1.  Ephemeral Public Keys

   The ECDH ephemeral public keys are formatted as a COSE_Key of type
   EC2 or OKP according to section 13.1 and 13.2 of [RFC8152], but only
   a subset of the parameters are included in the EDHOC messages.  The
   curve X25519 is mandatory to implement.  For Elliptic Curve Keys of
   type EC2, compact representation and compact output as per [RFC6090]
   MAY be used, i.e. the 'y' parameter is not be present in the The
   COSE_Key object.  COSE [RFC8152] always use compact output for
   Elliptic Curve Keys of type EC2.

3.2.  Key Derivation

   Key and IV derivation SHALL be done as specified in Section 11.1 of
   [RFC8152] with the following input:

   o  The PRF SHALL be the HKDF [RFC5869] in the ECDH-SS w/ HKDF
      negotiated during the message exchange (HKDF_V).

Selander, et al.         Expires January 3, 2019                [Page 6]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   o  The secret SHALL be the ECDH shared secret as defined in
      Section 12.4.1 of [RFC8152].

   o  The salt SHALL be the PSK when EDHOC is authenticated with
      symmetric keys and the empty string "" when EDHOC is authenticated
      with asymmetric keys.

   o  The fields in the context information COSE_KDF_Context SHALL have
      the following values:

      *  AlgorithmID is an int or tstr as defined below

      *  PartyUInfo = PartyVInfo = ( nil, nil, nil )

      *  keyDataLength is a uint as defined below

      *  protected SHALL be a zero length bstr

      *  other is a bstr and SHALL be aad_2, aad_3, or exchange_hash

   where exchange_hash, in non-CDDL notation, is:

   exchange_hash = H( H( message_1 | message_2 ) | message_3 )

   where H() is the hash function in HKDF_V.

   For message_i the key, called K_i, SHALL be derived using other =
   aad_i, where i = 2 or 3.  The key SHALL be derived using AlgorithmID
   set to the integer value of the negotiated AEAD (AEAD_V), and
   keyDataLength equal to the key length of AEAD_V.

   If the AEAD algorithm requires an IV, then IV_i for message_i SHALL
   be derived using other = aad_i, where i = 2 or 3.  The IV SHALL be
   derived using AlgorithmID = "IV-GENERATION" as specified in section
   12.1.2. of [RFC8152], and keyDataLength equal to the IV length of
   AEAD_V.

   Application specific traffic keys and other data SHALL be derived
   using other = exchange_hash.  AlgorithmID SHALL be a tstr defined by
   the application and SHALL be different for different data being
   derived (an example is given in Appendix C.2). keyDataLength is set
   to the length of the data being derived.

4.  EDHOC Authenticated with Asymmetric Keys

Selander, et al.         Expires January 3, 2019                [Page 7]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

4.1.  Overview

   EDHOC supports authentication with raw public keys (RPK) and
   certificates with the requirements that:

   o  Party U SHALL be able to identify Party V's public key using ID_V.

   o  Party V SHALL be able to identify Party U's public key using ID_U.

   Raw public keys are stored as COSE_Key objects and identified with a
   'kid' value, see [RFC8152].  Certificates can be identified in
   different ways, ID_CRED_U and ID_CRED_V may contain the credential
   used for authentication (e.g. x5bag or x5chain) or identify the
   credential used for authentication (e.g. x5t, x5u), see
   [I-D.schaad-cose-x509].  The full credential (e.g.  X.509
   certificates or a COSE_Key) are included in CRED_V and CRED_U.

   Party U and Party V MAY use different type of credentials, e.g. one
   uses RPK and the other uses certificates.  Party U and Party V MAY
   use different signature algorithms.

   EDHOC with asymmetric key authentication is illustrated in Figure 3.

Party U                                                          Party V
|                        S_U, X_U, ALG_1, UAD_1                        |
+--------------------------------------------------------------------->|
|                               message_1                              |
|                                                                      |
|    S_U, S_V, X_V, ALG_2, UAD_2, Enc(K_2; Sig(V; CRED_V, aad_2); )    |
|<---------------------------------------------------------------------+
|                               message_2                              |
|                                                                      |
|            S_V, Enc(K_3; Sig(U; CRED_U, aad_3), PAD_3; )             |
+--------------------------------------------------------------------->|
|                               message_3                              |

            Figure 3: EDHOC with asymmetric key authentication.

4.1.1.  Mandatory to Implement Algorithms

   For EDHOC authenticated with asymmetric keys, the COSE algorithms
   ECDH-SS + HKDF-256, AES-CCM-64-64-128, and EdDSA are mandatory to
   implement.

Selander, et al.         Expires January 3, 2019                [Page 8]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

4.2.  EDHOC Message 1

4.2.1.  Formatting of Message 1

   message_1 SHALL be a CBOR array as defined below

   message_1 = [
     MSG_TYPE : int,
     S_U : bstr,
     ECDH-Curves_U : alg_array,
     ECDH-Curve_U : uint,
     X_U : bstr,
     HKDFs_U : alg_array,
     AEADs_U : alg_array,
     SIGs_V : alg_array,
     SIGs_U : alg_array,
     ? UAD_1 : bstr
   ]

   alg_array = [ + alg : int / tstr ]

   where:

   o  MSG_TYPE = 1

   o  S_U - variable length session identifier

   o  ECDH-Curves_U - EC curves for ECDH which Party U supports, in the
      order of decreasing preference

   o  ECDH-Curve_U - a single chosen algorithm from ECDH-Curves_U (array
      index with zero-based indexing)

   o  X_U - the x-coordinate of ephemeral public key of Party U

   o  HKDFs_U - supported ECDH-SS w/ HKDF algorithms

   o  AEADs_U - supported AEAD algorithms

   o  SIGs_V - signature algorithms, with which Party U supports
      verification

   o  SIGs_U - signature algorithms, with which Party U supports signing

   o  UAD_1 - bstr containing unprotected opaque application data

Selander, et al.         Expires January 3, 2019                [Page 9]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

4.2.2.  Party U Processing of Message 1

   Party U SHALL compose message_1 as follows:

   o  Determine which ECDH curve to use with Party V.  If U previously
      received from Party V an error message to message_1 with
      diagnostic payload identifying an ECDH curve in ECDH-Curves_U,
      then U SHALL generate an ephemeral from that curve.  Otherwise the
      first curve in ECDH-Curves_U MUST be used.  The content of ECDH-
      Curves_U SHALL be fixed, and SHALL not be changed based on
      previous error messages.

   o  Generate an ephemeral ECDH key pair as specified in Section 5 of
      [SP-800-56a] and format the ephemeral public key E_U as a COSE_key
      as specified in Section 3.1.  Let X_U be the x-coordinate of the
      ephemeral public key.

   o  Choose a session identifier S_U and store it for the length of the
      protocol.  Party U needs to be able to retrieve the protocol state
      using the session identifier S_U and other information such as the
      5-tuple.  The session identifier MAY be used with the protocol for
      which EDHOC establishes traffic keys/master secret, in which case
      S_U SHALL be different from the concurrently used session
      identifiers of that protocol.

   o  Format message_1 as specified in Section 4.2.1.

4.2.3.  Party V Processing of Message 1

   Party V SHALL process message_1 as follows:

   o  Verify that at least one of each kind of the proposed algorithms
      are supported.

   o  Verify that the ECDH curve indicated by ECDH-Curve_U is supported,
      and that no prior curve in ECDH-Curves_U is supported.

   o  Validate that there is a solution to the curve definition for the
      given x-coordinate X_U.

   If any verification step fails, Party V MUST send an EDHOC error
   message back, formatted as defined in Section 6.1, and the protocol
   MUST be discontinued.  If V does not support the curve ECDH-Curve_U,
   but supports another ECDH curves in ECDH-Curves_U, then the error
   message MUST include the following diagnostic payload describing the
   first supported ECDH curve in ECDH-Curves_U:

Selander, et al.         Expires January 3, 2019               [Page 10]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

ERR_MSG = "Curve not supported; Z"

where Z is the index of the first curve in ECDH-Curves_U that V supports

   o  Pass UAD_1 to the application.

4.3.  EDHOC Message 2

4.3.1.  Formatting of Message 2

   message_2 SHALL be a CBOR array as defined below

   message_2 = [
     data_2,
     CIPHERTEXT_2 : bstr
   ]

   data_2 = (
     MSG_TYPE : int,
     S_U : bstr / nil,
     S_V : bstr,
     X_V : bstr,
     HKDF_V : uint,
     AEAD_V : uint,
     SIG_V : uint,
     SIG_U : uint,
   )

   aad_2 : bstr

   where aad_2, in non-CDDL notation, is:

   aad_2 = H( message_1 | [ data_2 ] )

   where:

   o  MSG_TYPE = 2

   o  S_V - variable length session identifier

   o  X_V - the x-coordinate of ephemeral public key of Party V

   o  HKDF_V - a single chosen algorithm from HKDFs_U

   o  AEAD_V - a single chosen algorithm from AEADs_U

   o  SIG_V - a single chosen algorithm from SIGs_V with which Party V
      signs

Selander, et al.         Expires January 3, 2019               [Page 11]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   o  SIG_U - a single chosen algorithm from SIGs_U with which Party U
      signs

   o  H() - the hash function in HKDF_V

4.3.2.  Party V Processing of Message 2

   Party V SHALL compose message_2 as follows:

   o  Generate an ephemeral ECDH key pair as specified in Section 5 of
      [SP-800-56a] using the curve indicated by ECDH-Curve_U.  Format a
      ephemeral public key as a COSE_key as specified in Section 3.1.
      Let X_V be the x-coordinate of the ephemeral public key.

   o  Choose a session identifier S_V and store it for the length of the
      protocol.  Party V needs to be able to retrieve the protocol state
      using the session identifier S_V and other information such as the
      5-tuple.  The session identifier MAY be used with the protocol for
      which EDHOC establishes traffic keys/master secret, in which case
      S_V SHALL be different from the concurrently used session
      identifiers of that protocol.

   o  Select HKDF_V, AEAD_V, SIG_V, and SIG_U from the algorithms
      proposed in HKDFs_U, AEADs_U, SIGs_V, and SIGs_U.

   o  Compute COSE_Sign1 as defined in section 4.4 of [RFC8152], using
      algorithm SIG_V, the private key of Party V, and the following
      parameters.

      *  COSE_Sign1 = [ PROTECTED_2, '', [CRED_V, aad_2], SIGNATURE_2 ]

      *  PROTECTED_2 = { xyz : ID_CRED_V }

      *  xyz - any COSE map label that can identify a public key, see
         Section 4.1

      *  ID_CRED_V - identifier for the public key of Party V, see
         Section 4.1

      *  CRED_V - bstr containing the credential containing the public
         key of Party V, see Section 4.1

   o  Compute COSE_Encrypt0 as defined in section 5.3 of [RFC8152], with
      AEAD_V, K_2, and IV_2 and the following parameters.

      *  COSE_Encrypt0 = [ '', '', CIPHERTEXT_2 ]

      *  plaintext = [ PROTECTED_2, SIGNATURE_2, ? UAD_2 ]

Selander, et al.         Expires January 3, 2019               [Page 12]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

      *  UAD_2 = bstr containing opaque unprotected application data

   o  Format message_2 as specified in Section 4.3.1

4.3.3.  Party U Processing of Message 2

   Party U SHALL process message_2 as follows:

   o  Retrieve the protocol state using the session identifier S_U and
      other information such as the 5-tuple.

   o  Validate that there is a solution to the curve definition for the
      given x-coordinate X_V.

   o  Decrypt COSE_Encrypt0 as defined in section 5.3 of [RFC8152], with
      AEAD_V, K_2, and IV_2.

   o  Verify COSE_Sign1 as defined in section 4.4 of [RFC8152], using
      algorithm SIG_V and the public key of Party V.

   If any verification step fails, Party U MUST send an EDHOC error
   message back, formatted as defined in Section 6.1, and the protocol
   MUST be discontinued.

4.4.  EDHOC Message 3

4.4.1.  Formatting of Message 3

   message_3 SHALL be a CBOR array as defined below

   message_3 = [
     data_3,
     CIPHERTEXT_3 : bstr
   ]

   data_3 = (
     MSG_TYPE : int,
     S_V : bstr
   )

   aad_3 : bstr

   where aad_3, in non-CDDL notation, is:

   aad_3 = H( H( message_1 | message_2 ) | [ data_3 ] )

   where:

Selander, et al.         Expires January 3, 2019               [Page 13]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   o  MSG_TYPE = 3

4.4.2.  Party U Processing of Message 3

   Party U SHALL compose message_3 as follows:

   o  Compute COSE_Sign1 as defined in section 4.4 of [RFC8152], using
      algorithm SIG_U, the private key of Party U, and the following
      parameters.

      *  COSE_Sign1 = [ PROTECTED_3, '', [CRED_U, aad_3], SIGNATURE_3 ]

      *  PROTECTED_3 = { xyz : ID_CRED_U }

      *  ID_CRED_U - identifier for the public key of Party U, see
         Section 4.1

      *  CRED_U - bstr containing the credential containing the public
         key of Party U, see Section 4.1

   o  Compute COSE_Encrypt0 as defined in section 5.3 of [RFC8152], with
      AEAD_V, K_3, and IV_3 and the following parameters.

      *  COSE_Encrypt0 = [ '', '', CIPHERTEXT_3 ]

      *  plaintext = [ PROTECTED_3, SIGNATURE_3, ? PAD_3 ]

      *  PAD_3 = bstr containing opaque protected application data

   o  Format message_3 as specified in Section 4.4.1

4.4.3.  Party V Processing of Message 3

   Party V SHALL process message_3 as follows:

   o  Retrieve the protocol state using the session identifier S_V and
      other information such as the 5-tuple.

   o  Decrypt COSE_Encrypt0 as defined in section 5.3 of [RFC8152], with
      AEAD_V, K_3, and IV_3.

   o  Verify COSE_Sign1 as defined in section 4.4 of [RFC8152], using
      algorithm SIG_U and the public key of Party U.

   If any verification step fails, Party V MUST send an EDHOC error
   message back, formatted as defined in Section 6.1, and the protocol
   MUST be discontinued.

Selander, et al.         Expires January 3, 2019               [Page 14]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   o  Pass PAD_3 to the application.

5.  EDHOC Authenticated with Symmetric Keys

5.1.  Overview

   EDHOC supports authentication with pre-shared keys.  Party U and V
   are assumed to have a pre-shared key (PSK) with a good amount of
   randomness and the requirement that:

   o  Party V SHALL be able to identify the PSK using KID.

   KID may optionally contain information about how to retrieve the PSK.

   EDHOC with symmetric key authentication is illustrated in Figure 4.

   Party U                                                       Party V
   |                    S_U, X_U, ALG_1, KID, UAD_1                    |
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |                                                                   |
   |           S_U, S_V, X_V, ALG_2, Enc(K_2; UAD_2; aad_2)            |
   |<------------------------------------------------------------------+
   |                             message_2                             |
   |                                                                   |
   |                    S_V, Enc(K_3; PAD_3; aad_3)                    |
   +------------------------------------------------------------------>|
   |                             message_3                             |

            Figure 4: EDHOC with symmetric key authentication.

5.1.1.  Mandatory to Implement Algorithms

   For EDHOC authenticated with symmetric keys, the COSE algorithms
   ECDH-SS + HKDF-256 and AES-CCM-64-64-128 are mandatory to implement.

5.2.  EDHOC Message 1

5.2.1.  Formatting of Message 1

   message_1 SHALL be a CBOR array as defined below

Selander, et al.         Expires January 3, 2019               [Page 15]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   message_1 = [
     data_1
   ]

   data_1 = (
     MSG_TYPE : int,
     S_U : bstr,
     ECDH-Curves_U : alg_array,
     ECDH-Curve_U : uint,
     X_U : bstr,
     HKDFs_U : alg_array,
     AEADs_U : alg_array,
     KID : bstr,
     ? UAD_1 : bstr
   )

   serialized_COSE_Key = bstr .cbor COSE_Key

   alg_array = [ + alg : int / tstr ]

   where:

   o  MSG_TYPE = 4

   o  S_U - variable length session identifier

   o  ECDH-Curves_U - EC curves for ECDH which Party U supports, in the
      order of decreasing preference

   o  ECDH-Curve_U - a single chosen algorithm from ECDH-Curves_U (array
      index with zero-based indexing)

   o  X_U - the x-coordinate of ephemeral public key of Party U

   o  HKDFs_U - supported ECDH-SS w/ HKDF algorithms

   o  AEADs_U - supported AEAD algorithms

   o  KID - identifier of the pre-shared key

   o  UAD_1 - bstr containing unprotected opaque application data

5.2.2.  Party U Processing of Message 1

   Party U SHALL compose message_1 as follows:

   o  Determine which ECDH curve to use with Party V.  If U previously
      received from Party V an error message to message_1 with

Selander, et al.         Expires January 3, 2019               [Page 16]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

      diagnostic payload identifying an ECDH curve in ECDH-Curves_U,
      then U SHALL generate an ephemeral from that curve.  Otherwise the
      first curve in ECDH-Curves_U MUST be used.  The content of ECDH-
      Curves_U SHALL be fixed, and SHALL not be changed based on
      previous error messages.

   o  Generate an ephemeral ECDH key pair as specified in Section 5 of
      [SP-800-56a] and format the ephemeral public key E_U as a COSE_key
      as specified in Section 3.1.  Let X_U be the x-coordinate of the
      ephemeral public key.

   o  Choose a session identifier S_U and store it for the length of the
      protocol.  Party U needs to be able to retrieve the protocol state
      using the session identifier S_U and other information such as the
      5-tuple.  The session identifier MAY be used with the protocol for
      which EDHOC establishes traffic keys/master secret, in which case
      S_U SHALL be different from the concurrently used session
      identifiers of that protocol.

   o  Format message_1 as specified in Section 5.2.1.

5.2.3.  Party V Processing of Message 1

   Party V SHALL process message_1 as follows:

   o  Verify that at least one of each kind of the proposed algorithms
      are supported.

   o  Verify that the ECDH curve indicated by ECDH-Curve_U is supported,
      and that no prior curve in ECDH-Curves_U is supported.

   o  Validate that there is a solution to the curve definition for the
      given x-coordinate X_U.

   If any verification step fails, Party V MUST send an EDHOC error
   message back, formatted as defined in Section 6.1, and the protocol
   MUST be discontinued.  If V does not support the curve ECDH-Curve_U,
   but supports another ECDH curves in ECDH-Curves_U, then the error
   message MUST include a diagnostic payload describing the first
   supported ECDH curve in ECDH-Curves_U.

   o  Pass UAD_1 to the application.

5.3.  EDHOC Message 2

Selander, et al.         Expires January 3, 2019               [Page 17]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

5.3.1.  Formatting of Message 2

   message_2 SHALL be a CBOR array as defined below

   message_2 = [
     data_2,
     CIPHERTEXT_2 : bstr
   ]

   data_2 = (
     MSG_TYPE : int,
     S_U : bstr / nil,
     S_V : bstr,
     X_V : bstr,
     HKDF_V : uint,
     AEAD_V : uint
   )

   aad_2 : bstr

   where aad_2, in non-CDDL notation, is:

   aad_2 = H( message_1 | [ data_2 ] )

   where:

   o  MSG_TYPE = 5

   o  S_V - variable length session identifier

   o  X_V - the x-coordinate of ephemeral public key of Party V

   o  HKDF_V - an single chosen algorithm from HKDFs_U

   o  AEAD_V - an single chosen algorithm from AEADs_U

   o  H() - the hash function in HKDF_V

5.3.2.  Party V Processing of Message 2

   Party V SHALL compose message_2 as follows:

   o  Generate an ephemeral ECDH key pair as specified in Section 5 of
      [SP-800-56a] using the curve indicated by ECDH-Curve_U.  Format a
      ephemeral public key as a COSE_key as specified in Section 3.1.
      Let X_V be the x-coordinate of the ephemeral public key.

Selander, et al.         Expires January 3, 2019               [Page 18]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   o  Choose a session identifier S_V and store it for the length of the
      protocol.  Party V needs to be able to retrieve the protocol state
      using the session identifier S_V and other information such as the
      5-tuple.  The session identifier MAY be used with the protocol for
      which EDHOC establishes traffic keys/master secret, in which case
      S_V SHALL be different from the concurrently used session
      identifiers of that protocol.

   o  Select HKDF_V and AEAD_V from the algorithms proposed in HKDFs_U
      and AEADs_U.

   o  Compute COSE_Encrypt0 as defined in section 5.3 of [RFC8152], with
      AEAD_V, K_2, and IV_2 and the following parameters.

      *  COSE_Encrypt0 = [ '', '', CIPHERTEXT_2 ]

      *  external_aad = aad_2

      *  plaintext = ? UAD_2

      *  UAD_2 = bstr containing opaque unprotected application data

   o  Format message_2 as specified in Section 5.3.1

5.3.3.  Party U Processing of Message 2

   Party U SHALL process message_2 as follows:

   o  Retrieve the protocol state using the session identifier S_U and
      other information such as the 5-tuple.

   o  Validate that there is a solution to the curve definition for the
      given x-coordinate X_V.

   o  Decrypt and verify COSE_Encrypt0 as defined in section 5.3 of
      [RFC8152], with AEAD_V, K_2, and IV_2.

   If any verification step fails, Party U MUST send an EDHOC error
   message back, formatted as defined in Section 6.1, and the protocol
   MUST be discontinued.

   o  Pass UAD_2 to the application.

5.4.  EDHOC Message 3

Selander, et al.         Expires January 3, 2019               [Page 19]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

5.4.1.  Formatting of Message 3

   message_3 SHALL be a CBOR array as defined below

   message_3 = [
     data_3,
     CIPHERTEXT_3 : bstr
   ]

   data_3 = (
     MSG_TYPE : int,
     S_V : bstr
   )

   aad_3 : bstr

   where aad_3, in non-CDDL notation, is:

   aad_3 = H( H( message_1 | message_2 ) | [ data_3 ] )

   where:

   o  MSG_TYPE = 6

5.4.2.  Party U Processing of Message 3

   Party U SHALL compose message_3 as follows:

   o  Compute COSE_Encrypt0 as defined in section 5.3 of [RFC8152], with
      AEAD_V, K_3, and IV_3 and the following parameters.

      *  COSE_Encrypt0 = [ '', '', CIPHERTEXT_3 ]

      *  external_aad = aad_3

      *  plaintext = ? PAD_3

      *  PAD_2 = bstr containing opaque protected application data

   o  Format message_3 as specified in Section 5.4.1

5.4.3.  Party V Processing of Message 3

   Party V SHALL process message_3 as follows:

   o  Retrieve the protocol state using the session identifier S_V and
      other information such as the 5-tuple.

Selander, et al.         Expires January 3, 2019               [Page 20]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   o  Decrypt and verify COSE_Encrypt0 as defined in section 5.3 of
      [RFC8152], with AEAD_V, K_3, and IV_3.

   If any verification step fails, Party V MUST send an EDHOC error
   message back, formatted as defined in Section 6.1, and the protocol
   MUST be discontinued.

   o  Pass PAD_3 to the application.

6.  Error Handling

6.1.  Error Message Format

   This section defines a message format for an EDHOC error message,
   used during the protocol.  This is an error on EDHOC level and is
   independent of the lower layers used.  An advantage of using such a
   construction is to avoid issues created by usage of cross protocol
   proxies (e.g.  UDP to TCP).

   error SHALL be a CBOR array as defined below

   error = [
     MSG_TYPE : int,
     ? ERR_MSG : tstr
   ]

   where:

   o  MSG_TYPE = 0

   o  ERR_MSG is an optional text string containing the diagnostic
      payload, defined in the same way as in Section 5.5.2 of [RFC7252].

7.  IANA Considerations

7.1.  The Well-Known URI Registry

   IANA has added the well-known URI 'edhoc' in the Well-Known URIs
   registry.

   URI suffix: edhoc

   Change controller: IETF

   Specification document(s): [[this document]]

   Related information: None

Selander, et al.         Expires January 3, 2019               [Page 21]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

7.2.  Media Types Registry

   IANA has added the media type 'application/edhoc' to the Media Types
   registry:

       Type name: application

       Subtype name: edhoc

       Required parameters: N/A

       Optional parameters: N/A

       Encoding considerations: binary

       Security considerations: See Section 7 of this document.

       Interoperability considerations: N/A

       Published specification: [[this document]] (this document)

       Applications that use this media type: To be identified

       Fragment identifier considerations: N/A

       Additional information:

       * Magic number(s): N/A

       * File extension(s): N/A

       * Macintosh file type code(s): N/A

       Person & email address to contact for further information:
          Goeran Selander <goran.selander@ericsson.com>

       Intended usage: COMMON

       Restrictions on usage: N/A

       Author: Goeran Selander <goran.selander@ericsson.com>

       Change Controller: IESG

Selander, et al.         Expires January 3, 2019               [Page 22]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

8.  Security Considerations

   EDHOC builds on the SIGMA-I family of theoretical protocols that
   provides perfect forward secrecy and identity protection with a
   minimal number of messages.  The encryption algorithm of the SIGMA-I
   protocol provides identity protection, but the security of the
   protocol requires the MAC to cover the identity of the signer.  Hence
   the message authenticating functionality of the authenticated
   encryption in EDHOC is critical: authenticated encryption MUST NOT be
   replaced by plain encryption only, even if authentication is provided
   at another level or through a different mechanism.

   EDHOC adds an explicit message type and expands the message
   authentication coverage to additional elements such as algorithms,
   application data, and previous messages.  EDHOC uses the same Sign-
   then-MAC approach as TLS 1.3.

   EDHOC does not include negotiation of parameters related to the
   ephemeral key, but it enables Party V to verify that the ECDH curve
   used in the protocol is the most preferred curve by U which is
   supported by both U and V.

   Party U and V must make sure that unprotected data and metadata do
   not reveal any sensitive information.  This also applies for
   encrypted data sent to an unauthenticated party.  In particular, it
   applies to UAD_1 and UAD_2 in the asymmetric case, and UAD_1 and KID
   in the symmetric case.  The communicating parties may therefore
   anonymize KID.

   Using the same KID or unprotected application data in several EDHOC
   sessions allows passive eavesdroppers to correlate the different
   sessions.  Another consideration is that the list of supported
   algorithms may be used to identify the application.

   Party U and V are allowed to select the session identifiers S_U and
   S_V, respectively, for the other party to use in the ongoing EDHOC
   protocol as well as in a subsequent traffic protection protocol (e.g.
   OSCORE [I-D.ietf-core-object-security]).  The choice of session
   identifier is not security critical but intended to simplify the
   retrieval of the right security context in combination with using
   short identifiers.  If the wrong session identifier of the other
   party is used in a protocol message it will result in the receiving
   party not being able to retrieve a security context (which will
   terminate the protocol) or retrieving the wrong security context
   (which also terminates the protocol as the message cannot be
   verified).

Selander, et al.         Expires January 3, 2019               [Page 23]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   Party U and V must make sure that unprotected data does not trigger
   any harmful actions.  In particular, this applies to UAD_1 in the
   asymmetric case, and UAD_1 and KID in the symmetric case.  Party V
   should be aware that spoofed EDHOC message_1 cannot be detected.

   The availability of a secure pseudorandom number generator and truly
   random seeds are essential for the security of EDHOC.  If no true
   random number generator is available, a truly random seed must be
   provided from an external source.  If ECDSA is supported,
   "deterministic ECDSA" as specified in RFC6979 is RECOMMENDED.

   Ephemeral keys MUST NOT be reused, both parties SHALL generate fresh
   random ephemeral key pairs.

   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.

   Party U and V are responsible for verifying the integrity of
   certificates.  The selection of trusted CAs should be done very
   carefully and certificate revocation should be supported.

   The choice of key length used in the different algorithms needs to be
   harmonized, so that a sufficient security level is maintained for
   certificates, EDHOC, and the protection of application data.  Party U
   and V should enforce a minimum security level.

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

   Implementations should provide countermeasures to side-channel
   attacks such as timing attacks.

9.  References

9.1.  Normative References

   [I-D.schaad-cose-x509]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Headers for carrying and referencing X.509 certificates",
              draft-schaad-cose-x509-02 (work in progress), July 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Selander, et al.         Expires January 3, 2019               [Page 24]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
              Curve Cryptography Algorithms", RFC 6090,
              DOI 10.17487/RFC6090, February 2011,
              <https://www.rfc-editor.org/info/rfc6090>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [SIGMA]    Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to
              Authenticated Diffie-Hellman and Its Use in the IKE-
              Protocols (Long version)", June 2003,
              <http://webee.technion.ac.il/~hugo/sigma-pdf.pdf>.

   [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 Revision 2, May 2013,
              <http://dx.doi.org/10.6028/NIST.SP.800-56Ar2>.

9.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-03 (work in progress), July 2017.

   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE) using the OAuth 2.0
              Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-13
              (work in progress), July 2018.

   [I-D.ietf-ace-oscore-profile]
              Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander,
              "OSCORE profile of the Authentication and Authorization
              for Constrained Environments Framework", draft-ietf-ace-
              oscore-profile-02 (work in progress), June 2018.

Selander, et al.         Expires January 3, 2019               [Page 25]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   [I-D.ietf-cbor-cddl]
              Birkholz, H., Vigano, C., and C. Bormann, "Concise data
              definition language (CDDL): a notational convention to
              express CBOR data structures", draft-ietf-cbor-cddl-02
              (work in progress), February 2018.

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", draft-ietf-core-object-security-13 (work in
              progress), June 2018.

   [I-D.ietf-core-resource-directory]
              Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
              Amsuess, "CoRE Resource Directory", draft-ietf-core-
              resource-directory-14 (work in progress), July 2018.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://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,
              <https://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,
              <https://www.rfc-editor.org/info/rfc7252>.

Appendix A.  Test Vectors

   TODO: This section needs to be updated.

Appendix B.  PSK Chaining

   An application using EDHOC with symmetric keys may have a security
   policy to change the PSK as a result of successfully completing the
   EDHOC protocol.  In this case, the old PSK SHALL be replaced with a
   new PSK derived using other = exchange_hash, AlgorithmID = "EDHOC PSK
   Chaining" and keyDataLength equal to the key length of AEAD_V, see
   Section 3.2.

Selander, et al.         Expires January 3, 2019               [Page 26]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

Appendix C.  EDHOC with CoAP and OSCORE

C.1.  Transferring EDHOC in CoAP

   EDHOC can be transferred as an exchange of CoAP [RFC7252] messages,
   with the CoAP client as party U and the CoAP server as party V.  By
   default EDHOC is sent to the Uri-Path: "/.well-known/edhoc", but an
   application may define its own path that can be discovered e.g. using
   resource directory [I-D.ietf-core-resource-directory].

   In practice, EDHOC message_1 is sent in the payload of a POST request
   from the client to the server's resource for EDHOC.  EDHOC message_2
   or the EDHOC error message is sent from the server to the client in
   the payload of a 2.04 Changed response.  EDHOC message_3 or the EDHOC
   error message is sent from the client to the server's resource in the
   payload of a POST request.  If needed, an EDHOC error message is sent
   from the server to the client in the payload of a 2.04 Changed
   response

   An example of successful EDHOC exchange using CoAP is shown in
   Figure 5.

              Client    Server
                |          |
                +--------->| Header: POST (Code=0.02)
                |   POST   | Uri-Path: "/.well-known/edhoc"
                |          | Content-Type: application/edhoc
                |          | Payload: EDHOC message_1
                |          |
                |<---------+ Header: 2.04 Changed
                |   2.04   | Content-Type: application/edhoc
                |          | Payload: EDHOC message_2
                |          |
                +--------->| Header: POST (Code=0.02)
                |   POST   | Uri-Path: "/.well-known/edhoc"
                |          | Content-Type: application/edhoc
                |          | Payload: EDHOC message_3
                |          |
                |<---------+ Header: 2.04 Changed
                |   2.04   |
                |          |

                   Figure 5: Transferring EDHOC in CoAP

Selander, et al.         Expires January 3, 2019               [Page 27]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

C.2.  Deriving an OSCORE context from EDHOC

   When EDHOC is use to derive parameters for OSCORE
   [I-D.ietf-core-object-security], the parties must make sure that the
   EDHOC session identifiers are unique Recipient IDs in OSCORE.  In
   case that the CoAP client is party U and the CoAP server is party V:

   o  The AEAD Algorithm is AEAD_V, as defined in this document

   o  The Key Derivation Function (KDF) is HKDF_V, as defined in this
      document

   o  The Client's Sender ID is S_V, as defined in this document

   o  The Server's Sender ID is S_U, as defined in this document

   o  The Master Secret is derived as specified in Section 3.2 of this
      document, with other = exchange_hash, AlgorithmID = "EDHOC OSCORE
      Master Secret" and keyDataLength equal to the key length of
      AEAD_V.

   o  The Master Salt is derived as specified in Section 3.2 of this
      document, with other = exchange_hash, AlgorithmID = "EDHOC OSCORE
      Master Salt" and keyDataLength equal to 64 bits.

Appendix D.  Message Sizes

   This appendix gives an estimate of the message sizes when EDHOC is
   used with Raw Public Keys.  Note that the examples in this section
   and this section are not test vectors, the cryptographic parts are
   replaces with byte strings of the same length.  All examples are
   given in CBOR diagnostic notation.

   message1 = [
     1,
     h'c3',
     [4],
     0,
     'abcdefghijklmnopqrstuvwxyz123456',
     [-27],
     [10],
     [-8],
     [-8]
   ]

   The size of message_1 is 50 bytes

Selander, et al.         Expires January 3, 2019               [Page 28]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   plaintext = [
     { 4 : 'abba' },
     'abcdefghijklmnopqrstuvwxyz123456abcdefghijklmnopqrstuvwxyz123456'
   ]

   The size of plaintext is 74 bytes so the size of ciphertext is 82
   bytes

message2 = [
  2,
  null,
  h'c4',
  'abcdefghijklmnopqrstuvwxyz123456',
  0,
  0,
  0,
  0,
  'abcdefghijklmnopqrstuvwxyz123456abcdefghijklmnopqrstuvwxyz123456abcdefghijklmnopqr'
]

   The size of message_2 is 127 bytes

message3 = [
  3,
  h'c3',
  'abcdefghijklmnopqrstuvwxyz123456abcdefghijklmnopqrstuvwxyz123456abcdefghijklmnopqr'
]

   The size of message_3 is 88 bytes

Acknowledgments

   The authors want to thank Dan Harkins, Ilari Liusvaara, Jim Schaad
   and Ludwig Seitz for reviewing intermediate versions of the draft and
   contributing concrete proposals incorporated in this version.  We are
   especially indebted to Jim Schaad for his continuous reviewing and
   implementation of different versions of the draft.

   We are also grateful to Theis Groenbech Petersen, Thorvald Sahl
   Joergensen, Alessandro Bruni and Carsten Schuermann for their work on
   formal analysis of EDHOC.

Authors' Addresses

   Goeran Selander
   Ericsson AB

   Email: goran.selander@ericsson.com

Selander, et al.         Expires January 3, 2019               [Page 29]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC)      July 2018

   John Mattsson
   Ericsson AB

   Email: john.mattsson@ericsson.com

   Francesca Palombini
   Ericsson AB

   Email: francesca.palombini@ericsson.com

Selander, et al.         Expires January 3, 2019               [Page 30]