Network Working Group                                        G. Selander
Internet-Draft                                         J. Preuß Mattsson
Intended status: Standards Track                            F. Palombini
Expires: January 13, 24 February 2022                                       Ericsson AB
                                                           July 12,
                                                          23 August 2021

               Ephemeral Diffie-Hellman Over COSE (EDHOC)
                        draft-ietf-lake-edhoc-08
                        draft-ietf-lake-edhoc-09

Abstract

   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
   very compact and lightweight authenticated Diffie-Hellman key
   exchange with ephemeral keys.  EDHOC provides mutual authentication,
   perfect
   forward secrecy, and identity protection.  EDHOC is intended for
   usage in constrained scenarios and a main use case is to establish an
   OSCORE security context.  By reusing COSE for cryptography, CBOR for
   encoding, and CoAP for transport, the additional code size can be
   kept very low.

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 13, 24 February 2022.

Copyright Notice

   Copyright (c) 2021 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) (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Use of EDHOC  . . . . . . . . . . . . . . . . . . . . . .   4   5
     1.3.  Message Size Examples . . . . . . . . . . . . . . . . . .   5
     1.4.  Document Structure  . . . . . . . . . . . . . . . . . . .   6
     1.5.  Terminology and Requirements Language . . . . . . . . . .   6
   2.  EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . .   6   7
   3.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . .   8   9
     3.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   8   9
     3.2.  Method  . . . . . . . . . . . . . . . . . . . . . . . . .   9  10
     3.3.  Connection Identifiers  . . . . . . . . . . . . . . . . .   9  10
     3.4.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.5.  Authentication Parameters . . . . . . . . . . . . . . . .  11  12
     3.6.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . .  16  18
     3.7.  Ephemeral Public Keys . . . . . . . . . . . . . . . . . .  18  20
     3.8.  External Authorization Data (EAD) . . . . . . . . . . . . . . .  18  20
     3.9.  Applicability Statement . . . . . . . . . . . . . . . . .  19  21
   4.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .  21  23
     4.1.  EDHOC-Exporter Interface  Extract . . . . . . . . . . . . . . . . . . . . . . . . .  23
     4.2.  Expand  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     4.3.  EDHOC-Exporter  . . . . . . . . . . . . . . . . . . . . .  26
     4.4.  EDHOC-KeyUpdate . . . . . . . . . . . . . . . . . . . . .  27
   5.  Message Formatting and Processing . . . . . . . . . . . . . .  24  27
     5.1.  Message Processing Outline  . . . . . . . . . . . . . . .  24  27
     5.2.  EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . .  25  28
     5.3.  EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . .  27  30
     5.4.  EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . .  30  32
     5.5.  EDHOC Message 4 . . . . . . . . . . . . . . . . . . . . .  33  36
   6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  35  37
     6.1.  Success . . . . . . . . . . . . . . . . . . . . . . . . .  36  39
     6.2.  Unspecified . . . . . . . . . . . . . . . . . . . . . . .  36  39
     6.3.  Wrong Selected Cipher Suite . . . . . . . . . . . . . . .  36  39
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  38  41
     7.1.  Security Properties . . . . . . . . . . . . . . . . . . .  38  41
     7.2.  Cryptographic Considerations  . . . . . . . . . . . . . .  40  44
     7.3.  Cipher Suites and Cryptographic Algorithms  . . . . . . .  41  45
     7.4.  Unprotected Data  . . . . . . . . . . . . . . . . . . . .  42  45
     7.5.  Denial-of-Service . . . . . . . . . . . . . . . . . . . .  42  46
     7.6.  Implementation Considerations . . . . . . . . . . . . . .  43  46
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  44  48
     8.1.  EDHOC Exporter Label  . . . . . . . . . . . . . . . . . .  44  48
     8.2.  EDHOC Cipher Suites Registry  . . . . . . . . . . . . . .  45  48
     8.3.  EDHOC Method Type Registry  . . . . . . . . . . . . . . .  47  50
     8.4.  EDHOC Error Codes Registry  . . . . . . . . . . . . . . .  47  50
     8.5.  COSE Header Parameters Registry . . . . . . . . . . . . .  47  50
     8.6.  COSE Header Parameters Registry . . . . . . . . . . . . .  47  51
     8.7.  COSE Key Common Parameters Registry . . . . . . . . . . .  48  51
     8.8.  The Well-Known URI Registry . . . . . . . . . . . . . . .  48  51
     8.9.  Media Types Registry  . . . . . . . . . . . . . . . . . .  48  52
     8.10. CoAP Content-Formats Registry . . . . . . . . . . . . . .  49  53
     8.11. EDHOC External Authorization Data . . . . . . . . . . . .  49  53
     8.12. Expert Review Instructions  . . . . . . . . . . . . . . .  50  53
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  50  54
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  50  54
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  53  56
   Appendix A.  Use with OSCORE and Transfer over CoAP . . . . . . .  55  59
     A.1.  Selecting EDHOC Connection Identifier . . . . . . . . . .  55  59
     A.2.  Deriving the OSCORE Security Context  . . . . . . . . . .  56  60
     A.3.  Transferring EDHOC over CoAP  . . . . . . . . . . . . . .  57  61
   Appendix B.  Compact Representation . . . . . . . . . . . . . . .  60  64
   Appendix C.  Use of CBOR, CDDL and COSE in EDHOC  . . . . . . . .  60  65
     C.1.  CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . .  60  65
     C.2.  CDDL Definitions  . . . . . . . . . . . . . . . . . . . .  61  66
     C.3.  COSE  . . . . . . . . . . . . . . . . . . . . . . . . . .  62  68
   Appendix D.  Test Vectors . . . . . . . . . . . . . . . . . . . .  63
     D.1.  Test Vectors for EDHOC Authenticated with Signature Keys
           (x5t)  68
   Appendix E.  Applicability Template . . . . . . . . . . . . . . .  68
   Appendix F.  EDHOC Message Deduplication  . . . . . . . . . . .  63
     D.2.  Test Vectors for EDHOC Authenticated with Static Diffie-
           Hellman Keys .  69
   Appendix G.  Transports Not Natively Providing Correlation  . . .  70
   Appendix H.  Change Log . . . . . . . . . . . . . . . . . .  81
   Appendix E.  Applicability Template . . .  70
   Acknowledgments . . . . . . . . . . . .  96
   Appendix F.  EDHOC Message Deduplication . . . . . . . . . . . .  96
   Appendix G.  Transports Not Natively Providing Correlation .  75
   Authors' Addresses  . .  97
   Appendix H.  Change Log . . . . . . . . . . . . . . . . . . . . .  98
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 101
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 101  75

1.  Introduction

1.1.  Motivation

   Many Internet of Things (IoT) deployments require technologies which
   are highly performant in constrained environments [RFC7228].  IoT
   devices may be constrained in various ways, including memory,
   storage, processing capacity, and power.  The connectivity for these
   settings may also exhibit constraints such as unreliable and lossy
   channels, highly restricted bandwidth, and dynamic topology.  The
   IETF has acknowledged this problem by standardizing a range of
   lightweight protocols and enablers designed for the IoT, including
   the Constrained Application Protocol (CoAP, [RFC7252]), Concise
   Binary Object Representation (CBOR, [RFC8949]), and Static Context
   Header Compression (SCHC, [RFC8724]).

   The need for special protocols targeting constrained IoT deployments
   extends also to the security domain [I-D.ietf-lake-reqs].  Important
   characteristics in constrained environments are the number of round
   trips and protocol message sizes, which if kept low can contribute to
   good performance by enabling transport over a small number of radio
   frames, reducing latency due to fragmentation or duty cycles, etc.
   Another important criteria is code size, which may be prohibitive for
   certain deployments due to device capabilities or network load during
   firmware update.  Some IoT deployments also need to support a variety
   of underlying transport technologies, potentially even with a single
   connection.

   Some security solutions for such settings exist already.  CBOR Object
   Signing and Encryption (COSE, [I-D.ietf-cose-rfc8152bis-struct])
   specifies basic application-layer security services efficiently
   encoded in CBOR.  Another example is Object Security for Constrained
   RESTful Environments (OSCORE, [RFC8613]) which is a lightweight
   communication security extension to CoAP using CBOR and COSE.  In
   order to establish good quality cryptographic keys for security
   protocols such as COSE and OSCORE, the two endpoints may run an
   authenticated Diffie-Hellman key exchange protocol, from which shared
   secret key material can be derived.  Such a key exchange protocol
   should also be lightweight; to prevent bad performance in case of
   repeated use, e.g., due to device rebooting or frequent rekeying for
   security reasons; or to avoid latencies in a network formation
   setting with many devices authenticating at the same time.

   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
   lightweight authenticated key exchange protocol providing good
   security properties including perfect forward secrecy, identity protection,
   and cipher suite negotiation.  Authentication can be based on raw
   public keys (RPK) or public key certificates, certificates and requires the
   application to provide input on how to verify that endpoints are
   trusted.  This specification focuses on referencing instead of
   transporting credentials to reduce message overhead.  EDHOC does
   currently not support pre-shared key (PSK) authentication as
   authentication with static Diffie-Hellman public keys by reference
   produces equally small message sizes but with much simpler key
   distribution.

   EDHOC makes use of known protocol constructions, such as SIGMA
   [SIGMA] and Extract-and-Expand [RFC5869].  COSE also provides crypto
   agility and enables the use of future algorithms targeting IoT.

1.2.  Use of EDHOC

   EDHOC is designed for highly constrained settings making it
   especially suitable for low-power wide area networks [RFC8376] such
   as Cellular IoT, 6TiSCH, and LoRaWAN.  A main objective for EDHOC is
   to be a lightweight authenticated key exchange for OSCORE, i.e. i.e., to
   provide authentication and session key establishment for IoT use
   cases such as those built on CoAP [RFC7252].  CoAP is a specialized
   web transfer protocol for use with constrained nodes and networks,
   providing a request/response interaction model between application
   endpoints.  As such, EDHOC is targeting a large variety of use cases
   involving 'things' with embedded microcontrollers, sensors, and
   actuators.

   A typical setting is when one of the endpoints is constrained or in a
   constrained network, and the other endpoint is a node on the Internet
   (such as a mobile phone) or at the edge of the constrained network
   (such as a gateway).  Thing-to-thing interactions over constrained
   networks are also relevant since both endpoints would then benefit
   from the lightweight properties of the protocol.  EDHOC could e.g. e.g.,
   be run when a device connects for the first time, or to establish
   fresh keys which are not revealed by a later compromise of the long-term long-
   term keys.  Further security properties are described in Section 7.1.

   EDHOC enables the reuse of the same lightweight primitives as OSCORE:
   CBOR for encoding, COSE for cryptography, and CoAP for transport.  By
   reusing existing libraries libraries, the additional code size can be kept very
   low.  Note that, while CBOR and COSE primitives are built into the
   protocol messages, EDHOC is not bound to a particular transport.
   However, it is recommended to transfer
   Transfer of EDHOC messages in CoAP payloads as is detailed in
   Appendix A.3.

1.3.  Message Size Examples

   Compared to the DTLS 1.3 handshake [I-D.ietf-tls-dtls13] with ECDHE
   and connection ID, the number of bytes in EDHOC + CoAP can be less
   than 1/6 when RPK authentication is used, see
   [I-D.ietf-lwig-security-protocol-comparison].  Figure 1 shows two
   examples of message sizes for EDHOC with different kinds of
   authentication keys and different COSE header parameters for
   identification: static Diffie-Hellman keys identified by 'kid'
   [I-D.ietf-cose-rfc8152bis-struct], and X.509 signature certificates
   identified by a hash value using 'x5t' [I-D.ietf-cose-x509].

                     =================================
                                         kid       x5t
                     ---------------------------------
                     message_1            37        37
                     message_2            45       116
                     message_3            20        91            19        90
                     ---------------------------------
                     Total               103       245               101       243
                     =================================

                Figure 1: Example of message sizes in bytes.

1.4.  Document Structure

   The remainder of the document is organized as follows: Section 2
   outlines EDHOC authenticated with digital signatures, Section 3
   describes the protocol elements of EDHOC, including message flow, and formatting of the
   ephemeral public keys, Section 4 describes specifies the key derivation,
   Section 5 specifies message processing for EDHOC authenticated with authentication based on
   signature keys or static Diffie-Hellman keys, Section 6 specifies describes the
   EDHOC
   error message, messages, and Appendix A describes shows how to transfer EDHOC can be
   transferred in with CoAP
   and used to establish an OSCORE security context.

1.5.  Terminology and 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.

   Readers are expected to be familiar with the terms and concepts
   described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE
   structures and process [I-D.ietf-cose-rfc8152bis-struct], COSE
   algorithms [I-D.ietf-cose-rfc8152bis-algs], and CDDL [RFC8610].  The
   Concise Data Definition Language (CDDL) is used to express CBOR data
   structures [RFC8949].  Examples of CBOR and CDDL are provided in
   Appendix C.1.  When referring to CBOR, this specification always
   refer
   refers to Deterministically Encoded CBOR as specified in Sections
   4.2.1 and 4.2.2 of [RFC8949].

   The single output from authenticated encryption (including the
   authentication tag) is called 'ciphertext', "ciphertext", following [RFC5116].

   We use the term Unprotected CWT Claims Set (UCCS) just as in
   [I-D.ietf-rats-uccs] to denote a CBOR Web Token [RFC8392] without
   wrapping it into a COSE object, i.e., a CBOR map consisting of
   claims.

   Editor's note: If [I-D.ietf-rats-uccs] completes before this draft,
   make it a normative reference.

2.  EDHOC Outline

   EDHOC specifies different authentication methods of the Diffie-
   Hellman key exchange: digital signatures and static Diffie-Hellman
   keys.  This section outlines the digital signature based signature-based method.
   Further details of protocol elements and other authentication methods
   are provided in the remainder of this document.

   SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
   large number of variants [SIGMA].  Like IKEv2 [RFC7296] and (D)TLS
   1.3 [RFC8446], EDHOC authenticated with digital signatures is built
   on a variant of the SIGMA protocol which provides identity protection
   of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC
   implements the SIGMA-I variant as MAC-then-Sign.  The SIGMA-I
   protocol using an authenticated encryption algorithm is shown in
   Figure 2.

     Initiator                                               Responder
        |                           G_X                           |
        +-------------------------------------------------------->|
        |                                                         |
        |  G_Y, AEAD( K_2; ID_CRED_R, Sig(R; CRED_R, G_X, G_Y) )  |
        |<--------------------------------------------------------+
        |                                                         |
        |     AEAD( K_3; ID_CRED_I, Sig(I; CRED_I, G_Y, G_X) )    |
        +-------------------------------------------------------->|
        |                                                         |

    Figure 2: Authenticated encryption variant of the SIGMA-I protocol.

   The parties exchanging messages are called Initiator (I) and
   Responder (R).  They exchange ephemeral public keys, compute a shared
   secret, and derive symmetric application keys used to protect
   application data.

   o

   *  G_X and G_Y are the ECDH ephemeral public keys of I and R,
      respectively.

   o

   *  CRED_I and CRED_R are the credentials containing the public
      authentication keys of I and R, respectively.

   o

   *  ID_CRED_I and ID_CRED_R are credential identifiers enabling the
      recipient party to retrieve the credential of I and R,
      respectively.

   o

   *  Sig(I; . ) and Sig(R; . ) denote signatures made with the private
      authentication key of I and R, respectively.

   o

   *  AEAD(K; . ) denotes authenticated encryption with additional data
      using a key K derived from the shared secret.

   In order to create a "full-fledged" protocol some additional protocol
   elements are needed.  EDHOC adds:

   o

   *  Transcript hashes (hashes of message data) TH_2, TH_3, TH_4 used
      for key derivation and as additional authenticated data.

   o

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

   o

   *  An optional fourth message giving explicit key confirmation to I
      in deployments where no protected application data is sent from R
      to I.

   o

   *  A key material exporter and a key update function enabling
      frequent forward
      secrecy.

   o

   *  Verification of a common preferred cipher suite:

      *

      -  The Initiator lists supported cipher suites in order of
         preference

      *

      -  The Responder verifies that the selected cipher suite is the
         first supported cipher suite (or else rejects and states
         supported cipher suites).

   o

   *  Method types and error handling.

   o

   *  Selection of connection identifiers C_I and C_R which may be used
      to identify established keys or protocol state.

   o

   *  Transport of external authorization 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,
   COSE, and CoAP libraries.

   To simplify for implementors, the use of CBOR and COSE in EDHOC is
   summarized in Appendix C and test vectors including CBOR diagnostic
   notation are given in Appendix D.

3.  Protocol Elements

3.1.  General

   An

   The EDHOC message flow protocol consists of three mandatory messages (message_1,
   message_2, message_3) between Initiator and Responder, an optional
   fourth message (message_4), plus an EDHOC error message.  EDHOC messages
   are CBOR Sequences [RFC8742], see Figure 3.  The protocol elements in
   the figure are introduced in the following sections.  Message
   formatting and processing is specified in Section 5 and Section 6.
   An implementation may support only Initiator or only Responder.

   Application data is protected using the agreed application algorithms
   (AEAD, hash) in the selected cipher suite (see Section 3.6) and the
   application can make use of the established connection identifiers
   C_I and C_R (see Section 3.3).  EDHOC may be used with the media type
   application/edhoc defined in Section 8.

   The Initiator can derive symmetric application keys after creating
   EDHOC message_3, see Section 4.1.  Application protected 4.3.  Protected application data can
   therefore be sent in parallel or together with EDHOC message_3.

   Initiator                                                   Responder
   |                 METHOD, SUITES_I, G_X, C_I, EAD_1                 |
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |                                                                   |
   |        G_Y, C_R, Enc(ID_CRED_R, Signature_or_MAC_2, EAD_2) EAD_2), C_R        |
   |<------------------------------------------------------------------+
   |                             message_2                             |
   |                                                                   |
   |         AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, EAD_3)         |
   +------------------------------------------------------------------>|
   |                             message_3                             |

                        Figure 3: EDHOC Message Flow

3.2.  Method

   The data item METHOD in message_1 (see Section 5.2.1), is an integer
   specifying the authentication method.  EDHOC supports authentication
   with signature or static Diffie-Hellman keys, as defined in the four
   authentication methods: 0, 1, 2, and 3, see Figure 4.  (Method 0
   corresponds to the case outlined in Section 2 where both Initiator
   and Responder authenticate with signature keys.)

   An implementation may support only a single method.  The Initiator
   and the Responder need to have agreed on a single method to be used
   for EDHOC, see Section 3.9.

   +-------+-------------------+-------------------+-------------------+
   | Value | Initiator         | Responder         | Reference         |
   +-------+-------------------+-------------------+-------------------+
   |     0 | Signature Key     | Signature Key     | [[this document]] |
   |     1 | Signature Key     | Static DH Key     | [[this document]] |
   |     2 | Static DH Key     | Signature Key     | [[this document]] |
   |     3 | Static DH Key     | Static DH Key     | [[this document]] |
   +-------+-------------------+-------------------+-------------------+

                           Figure 4: Method Types

3.3.  Connection Identifiers

   EDHOC includes the selection of connection identifiers (C_I, C_R)
   identifying a connection for which keys are agreed.  Connection
   identifiers may be used in the ongoing EDHOC protocol (see
   Section 3.3.2) or in a subsequent application protocol, e.g., OSCORE
   (see Section 3.3.3).  The connection identifiers do not have any
   cryptographic purpose in EDHOC.

   Connection identifiers in EDHOC are byte strings or integers, encoded
   in CBOR.  One byte connection identifiers (the integers -24 to 23 and
   the empty bytestring byte string h'') are realistic in many scenarios as most
   constrained devices only have a few connections.

3.3.1.  Selection of Connection Identifiers

   C_I and C_R are chosen by I and R, respectively.  The Initiator
   selects C_I and sends it in message_1 for the Responder to use as a
   reference to the connection in communications with the Initiator.
   The Responder selects C_R and sends in message_2 for the Initiator to
   use as a reference to the connection in communications with the
   Responder.

   If connection identifiers are used by an application protocol for
   which EDHOC establishes keys then the selected connection identifiers
   SHALL adhere to the requirements for that protocol, see Section 3.3.3
   for an example.

3.3.2.  Use of Connection Identifiers in with EDHOC

   Connection identifiers may be used to correlate EDHOC messages and
   facilitate the retrieval of protocol state during EDHOC protocol
   execution.  EDHOC transports that do not inherently provide
   correlation across all messages of an exchange can send connection
   identifiers along with EDHOC messages to gain that required
   capability, see Section 3.4.  For an example of using connection
   identifiers when CoAP is used as transport, see Appendix A.3.

3.3.3.  Use of Connection Identifiers in with OSCORE

   For OSCORE, the choice of a connection identifier results in the
   endpoint selecting its Recipient ID, see Section 3.1 of [RFC8613]), [RFC8613],
   for which certain uniqueness requirements apply, see Section 3.3 of
   [RFC8613]).  Therefore
   [RFC8613].  Therefore, the Initiator and the Responder MUST NOT
   select connection identifiers such that it results in same OSCORE
   Recipient ID.  Since the Recipient ID is a byte string and a EDHOC
   connection identifier is either a CBOR byte string or a CBOR integer,
   care must be taken when selecting the connection identifiers and
   converting them to Recipient IDs.  A mapping from EDHOC connection
   identifier to OSCORE Recipient ID is specified in Appendix A.1.

3.4.  Transport

   Cryptographically, EDHOC does not put requirements on the lower
   layers.  EDHOC is not bound to a particular transport layer, layer and can
   even be used in environments without IP.  The transport is
   responsible, where necessary, to handle:

   o

   *  message loss,

   o

   *  message reordering,

   o

   *  message duplication,

   o

   *  fragmentation,

   o

   *  demultiplex EDHOC messages from other types of messages, and

   o  denial of service

   *  denial-of-service protection.

   Besides these common transport oriented transport-oriented properties, EDHOC transport
   additionally needs to support the correlation between EDHOC messages,
   including an indication of a message being message_1.  The
   correlation may reuse existing mechanisms in the transport protocol.
   For example, the CoAP Token may be used to correlate EDHOC messages
   in a CoAP response and an associated CoAP request.  In the absense absence of
   correlation between a message received and a message previously sent
   inherent to the transport, the EDHOC connection identifiers may be
   added, e.g. e.g., by prepending the appropriate connection identifier
   (when available from the EDHOC protocol) to the EDHOC message.
   Transport of EDHOC in CoAP payloads is described in Appendix A.3,
   which also shows how to use connection identifiers and message_1
   indication with CoAP.

   The Initiator and the Responder need to have agreed on a transport to
   be used for EDHOC, see Section 3.9.

3.5.  Authentication Parameters

3.5.1.  Authentication Keys

   The

   EDHOC enables public-key based authentication key MUST be a signature key or static Diffie-
   Hellman key.  The Initiator and supports various
   settings for how the Responder MAY use other endpoint's public key is transported,
   identified, and trusted.

   The authentication key (i.e., the public key) appears in different types
   functions:

   1.  as part of the authentication keys, e.g. one uses a signature key credential CRED_x included in the
       integrity calculation

   2.  for verification of the Signature_or_MAC field in message_2 and
       message_3 (see Section 5.3.2 and Section 5.4.2)

   3.  in the other
   uses key derivation (in case of a static Diffie-Hellman key.  When using a signature key, the
       see Section 4).

   The choice of authentication is provided by a signature.  When using a static
   Diffie-Hellman key has an impact on the message size
   (see Section 3.5.1), and even more so the choice of authentication is provided by a Message
   Authentication Code (MAC) computed from an ephemeral-static ECDH
   shared secret which enables significant reductions
   credential (see Section 3.5.2) in message sizes.

   The MAC case it is implemented with an AEAD algorithm.  When using static
   Diffie-Hellman keys transported within the Initiator's and Responder's private
   protocol (see Section 3.5.4).  EDHOC supports authentication keys
   credentials for which COSE header parameters are called I and R, respectively, defined, including:

   *  X.509 v3 certificate [RFC5280]

   *  C509 certificate [I-D.ietf-cose-cbor-encoded-cert]

   *  CBOR Web Token (CWT, [RFC8392])

   *  Unprotected CWT Claims Set (UCCS, see Section 1.5)
   For CWT and UCCS, the public
   authentication keys are called G_I and G_R, respectively.  The authentication key algorithm needs to specified is represented with enough
   parameters to make it completely determined.  Note that a 'cnf'
   claim [RFC8747] containing a COSE_Key
   [I-D.ietf-cose-rfc8152bis-struct].  UCCS can be seen as a generic
   representation of a raw public key, see Section 3.5.2 for most
   signature algorithms, the signature an example.
   COSE_Key is determined by the signature
   algorithm and the authentication key algorithm together.  For
   example, omitted from the curve used in list above because of limitations to
   represent the signature identity (see Section 3.5.3) and because it can easily
   be embedded in a UCCS.

   Identical authentication credentials need to be established in both
   endpoints to accomplish item 1 above (see Section 3.5.2) but for many
   settings it is typically determined by not necessary to transport the authentication key parameters.

   o  Only
   credential over constrained links.  It may, for example, be pre-
   provisioned or acquired out-of-band over less constrained links.
   ID_CRED_x coincides with the Responder SHALL have access authentication credential CRED_x in case
   it is transported, or else contains a reference to the Responder's private authentication key.

   o  Only the Initiator SHALL have access
   credential to the Initiator's private facilitate its retrieval (see Section 3.5.4).

   The choice of authentication key.

3.5.2.  Identities

   EDHOC assumes credential also depends on the existence of mechanisms (certification authority, trust
   model.  For example, a certificate or CWT may rely on a trusted third
   party, manual distribution, etc.) for specifying and
   distributing authentication keys and identities.  Policies are set
   based on the identity of whereas a UCCS may be used when trust in the public key can be
   achieved by other party, and parties typically only
   allow connections from a specific identity means, or a small restricted set
   of identities.  For example, in the case of a device connecting to a
   network, trust-on-first-use.  A
   UCCS as authentication credential provides essentially the network may only allow connections from devices which
   authenticate with certificates having same
   trustworthiness as a particular range of serial
   numbers self-signed certificate or CWT but has smaller
   size.

   More details are provided in the subject field following subsections.

3.5.1.  Authentication Keys

   The authentication key MUST be a signature key or static Diffie-
   Hellman key.  The Initiator and signed by the Responder MAY use different types
   of authentication keys, e.g., one uses a particular CA.  On signature key and the other side, the device may only be allowed to connect to
   uses a network
   which authenticates with static Diffie-Hellman key.  When using a particular public key (information of
   which may be provisioned, e.g., out of band or in the external
   authorization data, see Section 3.8).

   The EDHOC implementation must be able to receive and enforce
   information from the application about what is signature key, the intended endpoint,
   and in particular whether it
   authentication is provided by a specific identity or a set of
   identities.

   o signature.  When using a Public Key Infrastructure (PKI) is used, the trust anchor
      is a Certification Authority (CA) certificate, and static
   Diffie-Hellman key the identity authentication is
      the subject whose unique name (e.g. provided by a domain name, NAI, or EUI) is
      included Message
   Authentication Code (MAC) computed from an ephemeral-static ECDH
   shared secret which enables significant reductions in message sizes.
   When using static Diffie-Hellman keys the endpoint's certificate.  Before running EDHOC each
      party needs at least one CA public key certificate, or just Initiator's and Responder's
   private authentication keys are called I and R, respectively, and the
   public key, authentication keys are called G_I and a specific identity or set of identities it is
      allowed G_R, respectively.

   The authentication key algorithm needs to communicate with.  Only validated public-key
      certificates with an allowed subject name, as be specified by the
      application, are with enough
   parameters to be accepted.  EDHOC provides proof make it completely determined.  Note that for most
   signature algorithms, the
      other party possesses signature is determined jointly by the private authentication key corresponding
      to
   signature algorithm and the public authentication key in its certificate.  The
      certification path provides proof that algorithm.  For
   example, the subject of curve used in the
      certificate owns the public key in the certificate.

   o  When public keys are used but not with a PKI (RPK, self-signed
      certificate), the trust anchor is the public authentication key of
      the other party.  In this case, the identity signature is typically directly
      associated to the public authentication key of the other party.
      For example, the name of the subject may be a canonical
      representation of the public key.  Alternatively, if identities
      can be expressed in the form of unique subject names assigned to
      public keys, then a binding to identity can be achieved determined by
      including both public key and associated subject name in the
      protocol message computation: CRED_I or CRED_R may be a self-
      signed certificate or COSE_Key containing
   the public authentication key and parameters.

   *  Only the subject name, see Section 3.5.3.
      Before running EDHOC, each endpoint needs a specific public
      authentication key/unique associated subject name, or a set of
      public authentication keys/unique associated subject names, which
      it is allowed Responder SHALL have access to communicate with.  EDHOC provides proof that the
      other party possesses the Responder's private
      authentication key corresponding key.

   *  Only the Initiator SHALL have access to the public Initiator's private
      authentication key.

3.5.3.

3.5.2.  Authentication Credentials

   The authentication credentials, CRED_I and CRED_R, contain the public
   authentication key of the Initiator and the Responder, respectively.
   The Initiator and the Responder MAY use different types of
   credentials, e.g. e.g., one uses an RPK UCCS and the other uses a public key an X.509
   certificate.

   The credentials CRED_I and CRED_R are signed or MAC:ed (depending on
   method) MACed by the Initiator and the
   Responder, respectively, see Section 5.4 5.4.2 and Section 5.3.

   When the credential is a certificate, CRED_x is an end-entity
   certificate (i.e. not the certificate chain) encoded as a CBOR bstr.
   In X.509 certificates, signature keys typically have key usage
   "digitalSignature" 5.3.2, and Diffie-Hellman keys typically have key usage
   "keyAgreement".
   thus included in the message integrity calculation.

   To prevent misbinding attacks in systems where an attacker can
   register public keys without proving knowledge of the private key,
   SIGMA [SIGMA] enforces a MAC to be calculated over the "Identity",
   which in case of a X.509 certificate would be the 'subject' and
   'subjectAltName' fields. "identity".
   EDHOC follows SIGMA by calculating a MAC over the whole certificate.  While the SIGMA paper only focuses on
   the identity, credential,
   which in case of a X.509 or C509 certificate includes the "subject"
   and "subjectAltName" fields, and in the case of CWT or UCCS includes
   the "sub" claim, see Section 3.5.3.  While the SIGMA paper only
   focuses on the identity, the same principle is true for any
   information such as policies connected to the public key.

   When the credential is a COSE_Key, certificate, CRED_x is a an end-entity
   certificate (i.e., not the certificate chain).  In X.509 and C509
   certificates, signature keys typically have key usage
   "digitalSignature" and Diffie-Hellman public keys typically have key
   usage "keyAgreement".

   In case of elliptic curve based credential the claims set for CWT or
   UCCS includes:

   *  the 'cnf' claim with value COSE_Key, see [RFC8747], where the
      public key parameters depend on key type:

      -  for OKP the CBOR map only
   containing specific fields from typically includes the COSE_Key identifying parameters 1 (kty),
         -1 (crv), and -2 (x-coordinate)

      -  for EC2 the public
   key, CBOR map typically includes the parameters 1 (kty),
         -1 (crv), -2 (x-coordinate), and optionally -3 (y-coordinate)

   *  the 'sub' (subject) claim containing the "identity", if the
      parties have agreed on an identity besides the "Identity". public key.

   CRED_x needs to be defined such that it is identical when generated
   by Initiator or Responder. Responder, see Section 3.9.  The parameters SHALL be
   encoded in bytewise lexicographic order of their deterministic
   encodings as specified in Section 4.2.1 of [RFC8949].

   If the parties have agreed on an identity besides the public key, the
   identity is included in the CBOR map with the label "subject name",
   otherwise the subject name is the empty text string.  The public key
   parameters depend on key type.

   o  For COSE_Keys of type OKP the CBOR map SHALL, except for subject
      name, only include the parameters 1 (kty), -1 (crv), and -2
      (x-coordinate).

   o  For COSE_Keys of type EC2 the CBOR map SHALL, except for subject
      name, only include the parameters 1 (kty), -1 (crv), -2
      (x-coordinate), and -3 (y-coordinate).

   An example of CRED_x when the RPK contains being a UCCS in bytewise lexicographic order
   containing an X25519 static Diffie-
   Hellman Diffie-Hellman key and where the parties
   have agreed on an EUI-64 identity is shown below:

   CRED_x =

   {
     1:                                              /UCCS/
     2 : "42-50-31-FF-EF-37-32-39",               /sub/
     8 : {                                        /cnf/
       1 : {                                      /COSE_Key/
         1 : 1,
    -1:                                   /kty/
        -1 : 4,
    -2:  h'b1a3e89460e88d3a8d54211dc95f0b90
           3ff205eb71912d6db8f4af980d2db83a',
    "subject name"                                   /crv/
        -2 : "42-50-31-FF-EF-37-32-39" h'b1a3e89460e88d3a8d54211dc95f0b90   /x/
               3ff205eb71912d6db8f4af980d2db83a'
       }

3.5.4.  Identification of Credentials

   ID_CRED_I and ID_CRED_R are used to identify and optionally transport
     }
   }

3.5.3.  Identities

   EDHOC assumes the public authentication keys existence of the Initiator and the Responder,
   respectively.  ID_CRED_I and ID_CRED_R do not have any cryptographic
   purpose in EDHOC.

   o  ID_CRED_R is intended to facilitate for the Initiator to retrieve
      the Responder's public authentication key.

   o  ID_CRED_I is intended to facilitate mechanisms (certification authority,
   trusted third party, pre-provisioning, etc.) for the Responder to retrieve
      the Initiator's public specifying and
   distributing authentication key.

   The identifiers ID_CRED_I keys and ID_CRED_R identities.  Policies are COSE header_maps, i.e.
   CBOR maps containing Common COSE Header Parameters, see Section 3.1
   of [I-D.ietf-cose-rfc8152bis-struct]).  In
   typically set based on the following we give some
   examples identity of COSE header_maps.

   Raw public keys are most optimally stored as COSE_Key objects the other party, and
   identified with parties
   typically only allow connections from a 'kid2' parameter (see Section 8.6 and Section 8.7):

   o  ID_CRED_x = { 4 : kid_x }, where kid_x : bstr / int, for x = I specific identity or
      R.

   Note that a small
   restricted set of identities.  For example, in the integers -24 case of a device
   connecting to 23 and a network, the empty bytestring h'' are
   encoded as one byte.

   Public key certificates can be identified in different ways.  Header
   parameters for identifying C509 certificates and X.509 network may only allow connections from
   devices which authenticate with certificates
   are defined having a particular
   range of serial numbers in [I-D.ietf-cose-cbor-encoded-cert] the subject field and
   [I-D.ietf-cose-x509], for example:

   o signed by a hash value with
   particular CA.  On the 'c5t' or 'x5t' parameters;

      *  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,

      *  ID_CRED_x = { TDB3 : COSE_CertHash }, for x = I or R,

   o  by a URI with the 'c5u' or 'x5u' parameters;

      *  ID_CRED_x = { 35 : uri }, for x = I or R,

      *  ID_CRED_x = { TBD4 : uri }, for x = I or R,

   o  ID_CRED_x MAY contain other side, the actual credential used for
      authentication, CRED_x.  For example, a certificate chain can device may only be
      transported in ID_CRED_x allowed to
   connect to a network which authenticates with COSE header parameter c5c or
      x5chain, defined in [I-D.ietf-cose-cbor-encoded-cert] and
      [I-D.ietf-cose-x509].

   It is RECOMMENDED that ID_CRED_x uniquely identify the a particular public
   authentication key as the recipient
   (information of which may otherwise have to try several
   keys.  ID_CRED_I and ID_CRED_R are transported be provisioned, e.g., out of band or in the 'ciphertext',
   external authorization data, see Section 5.4 and Section 5.3.

   When ID_CRED_x does not contain 3.8).

   The EDHOC implementation or the actual credential it may be very
   short.  One byte credential identifiers are realistic application must enforce information
   about the intended endpoint, and in many
   scenarios as most constrained devices only have particular whether it is a few keys.  In cases
   where
   specific identity or a node only has one key, the identifier may even be the empty
   byte string.

3.6.  Cipher Suites

   An EDHOC cipher suite consists of an ordered set of algorithms from identities.  Either EDHOC passes
   information about identity to the "COSE Algorithms" and "COSE Elliptic Curves" registries.
   Algorithms need application for a decision, or
   EDHOC needs to be specified with enough parameters have access to make them
   completely determined.  Currently, none of relevant information and makes the algorithms require
   parameters.  EDHOC
   decision on its own.

   *  When a Public Key Infrastructure (PKI) is only specified for use with key exchange
   algorithms of type ECDH curves.  Use used with other types of key exchange
   algorithms would likely require a specification updating EDHOC.  Note
   that for most signature algorithms, certificates,
      the signature trust anchor is determined by
   the signature algorithm a Certification Authority (CA) certificate,
      and the authentication key algorithm
   together, see Section 3.5.1.

   o  EDHOC AEAD algorithm

   o  EDHOC hash algorithm

   o  EDHOC key exchange algorithm (ECDH curve)

   o  EDHOC signature algorithm

   o  Application AEAD algorithm

   o  Application hash algorithm

   Each cipher suite identity is identified with the subject whose unique name (e.g. a pre-defined int label. domain
      name, NAI, or EUI) is included in the endpoint's certificate.

      Before running EDHOC can be used with all algorithms and curves defined for COSE.
   Implementation can either use each party needs at least one of CA public key
      certificate, or just the pre-defined cipher suites
   (Section 8.2) public key, and a specific identity or use any combination
      set of COSE algorithms and
   parameters identities it is allowed to define their own private cipher suite.  Private cipher
   suites can be identified communicate with.  Only
      validated public-key certificates with any of an allowed subject name, as
      specified by the four values -24, -23, -22,
   -21.

   The following CCM cipher suites application, are for constrained IoT where message
   overhead is a very important factor.  Cipher suites 1 and 3 use a
   larger tag length (128-bit) in the to be accepted.  EDHOC AEAD algorithm than provides
      proof that the
   Application AEAD algorithm (64-bit):

      0. ( 10, -16, 4, -8, 10, -16 )
         (AES-CCM-16-64-128, SHA-256, X25519, EdDSA,
          AES-CCM-16-64-128, SHA-256)

      1. ( 30, -16, 4, -8, 10, -16 )
         (AES-CCM-16-128-128, SHA-256, X25519, EdDSA,
          AES-CCM-16-64-128, SHA-256)

      2. ( 10, -16, 1, -7, 10, -16 )
         (AES-CCM-16-64-128, SHA-256, P-256, ES256,
          AES-CCM-16-64-128, SHA-256)

      3. ( 30, -16, 1, -7, 10, -16 )
         (AES-CCM-16-128-128, SHA-256, P-256, ES256,
          AES-CCM-16-64-128, SHA-256)

   The following ChaCha20 cipher suites are for less constrained
   applications and only use 128-bit tag lengths.

      4. ( 24, -16, 4, -8, 24, -16 )
         (ChaCha20/Poly1305, SHA-256, X25519, EdDSA,
          ChaCha20/Poly1305, SHA-256)

      5. ( 24, -16, 1, -7, 24, -16 )
         (ChaCha20/Poly1305, SHA-256, P-256, ES256,
          ChaCha20/Poly1305, SHA-256) other party possesses the private authentication
      key corresponding to the public authentication key in its
      certificate.  The following GCM cipher suite is for general non-constrained
   applications.  It uses high performance algorithms certification path provides proof that are widely
   supported:

      6. ( 1, -16, 4, -7, 1, -16 )
         (A128GCM, SHA-256, X25519, ES256,
          A128GCM, SHA-256)

   The following two cipher suites are for high security application
   such as government use the
      subject of the certificate owns the public key in the certificate.

   *  Similarly, when a PKI is used with CWTs, each party needs to have
      a trusted third party self-signed CWT, or just the UCCS/raw public
      key, to verify the CWTs, and financial applications.  The two cipher
   suites do not share any algorithms.  The first a specific identity or set of
      identities in the two cipher
   suites 'sub'(subject) claim of the CWT to determine if
      it is compatible allowed to communicate with.

   *  When public keys are used but not with a PKI (UCCS, self-signed
      certificate/CWT), the CNSA suite [CNSA].

     24. ( 3, -43, 2, -35, 3, -43 )
         (A256GCM, SHA-384, P-384, ES384,
          A256GCM, SHA-384)

     25. ( 24, -45, 5, -8, 24, -45 )
         (ChaCha20/Poly1305, SHAKE256, X448, EdDSA,
          ChaCha20/Poly1305, SHAKE256)

   The different methods use the same cipher suites, but some algorithms
   are not used in some methods.  The EDHOC signature algorithm trust anchor is not
   used in methods without signature authentication.

   The Initiator needs to have a list of cipher suites it supports in
   order of preference.  The Responder needs to have a list the authentication key of cipher
   suites it supports.  SUITES_I is a CBOR array containing cipher
   suites that
      the Initiator supports.  SUITES_I other party.  In this case, the identity is formatted and
   processed as detailed in Section 5.2.1 typically directly
      associated to secure the cipher suite
   negotiation.  Examples authentication key of cipher suite negotiation are given in
   Section 6.3.2.

3.7.  Ephemeral Public Keys

   EDHOC always uses compact representation the other party.  For
      example, the name of elliptic curve points,
   see Appendix B.  In COSE compact the subject may be a canonical representation is achieved by
   formatting
      of the ECDH ephemeral public keys as COSE_Keys key.  Alternatively, if identities can be expressed
      in the form of type EC2 or
   OKP according unique subject names assigned to Sections 7.1 and 7.2 of
   [I-D.ietf-cose-rfc8152bis-algs], but only public keys, then
      a binding to identity can be achieved by including the 'x' parameter
   in G_X both public key
      and G_Y.  For Elliptic Curve Keys of type EC2, compact
   representation MAY be used also associated subject name in the COSE_Key.  If protocol message computation:
      CRED_I or CRED_R may be a self-signed certificate/CWT or UCCS
      containing the COSE
   implementation requires an 'y' parameter, authentication key and the value y = false SHALL
   be used.  COSE always use compact output for Elliptic Curve Keys subject name, see
      Section 3.5.2.  Before running EDHOC, each endpoint needs a
      specific authentication key/unique associated subject name, or a
      set of
   type EC2.

3.8.  External Authorization Data

   In order public authentication keys/unique associated subject names,
      which it is allowed to reduce round trips communicate with.  EDHOC provides proof
      that the other party possesses the private authentication key
      corresponding to the public authentication key.

3.5.4.  Identification of Credentials

   ID_CRED_I and number ID_CRED_R are used to identify and optionally transport
   the public authentication keys of messages or the Initiator and the Responder,
   respectively.  ID_CRED_I and ID_CRED_R do not have any cryptographic
   purpose in EDHOC.

   *  ID_CRED_R is intended to simplify
   processing, external security applications may be integrated into
   EDHOC by transporting authorization related data together with facilitate for the
   messages.  One example Initiator to retrieve
      the Responder's public authentication key.

   *  ID_CRED_I is intended to facilitate for the transport third-party identity Responder to retrieve
      the Initiator's public authentication key.

   The identifiers ID_CRED_I and
   authorization ID_CRED_R are registered in the "COSE
   Header Parameters" IANA registry.  As such, ID_CRED_I and ID_CRED_R
   typically also provide information protected out of scope of EDHOC
   [I-D.selander-ace-ake-authz].  Another example is about the embedding format of a
   certificate enrolment request or a newly issued certificate.

   EDHOC allows opaque external authorization data (EAD) to authentication
   credential, CRED_I and CRED_R, respectively.  ID_CRED_I and ID_CRED_R
   MAY be sent in
   the EDHOC messages.  External authorization data sent in message_1
   (EAD_1) or message_2 (EAD_2) must of different types.

   Public key certificates can be considered unprotected by EDHOC,
   see Section 7.4.  External authorization data sent identified in message_3
   (EAD_3) different ways.  COSE
   header parameters for identifying X.509 or message_4 (EAD_4) is protected between Initiator C509 certificates are
   defined in [I-D.ietf-cose-x509] and
   Responder.

   External authorization data is
   [I-D.ietf-cose-cbor-encoded-cert], for example:

   *  by a CBOR sequence (see Appendix C.1) as
   defined below:

   EAD hash value with the 'x5t' or 'c5t' parameters, respectively:

      -  ID_CRED_x = (
     type { 34 : int,
     1* ext_authz_data COSE_CertHash }, for x = I or R,

      -  ID_CRED_x = { TBD3 : any,
   )

   where type is an int and is followed COSE_CertHash }, for x = I or R;

   *  or by one a URI with the 'x5u' or more ext_authz_data
   depending on type as 'c5u' parameters, respectively:

      -  ID_CRED_x = { 35 : uri }, for x = I or R,

      -  ID_CRED_x = { TBD4 : uri }, for x = I or R.

   ID_CRED_x MAY contain the actual credential used for authentication,
   CRED_x.  For example, a certificate chain can be transported in
   ID_CRED_x with COSE header parameter c5c or x5chain, defined in a separate specification.

   The EAD fields
   [I-D.ietf-cose-cbor-encoded-cert] and [I-D.ietf-cose-x509].

   Credentials of EDHOC type CWT and UCCS are not intended for generic application
   data.  Since data carried transported with the COSE header
   parameter registered in EAD_1 and EAD_2 fields may not be
   protected, special considerations need to be made such Section 8.5:

   *  ID_CRED_x = { TBD1 : CWT }, for x = I or R,

   *  ID_CRED_x = { TBD1 : UCCS }, for x = I or R.

   It is RECOMMENDED that a) it
   does not violate security, privacy etc. requirements of ID_CRED_x uniquely identify the service
   which uses this data, and b) it does not violate the security
   properties of EDHOC.  Security applications making use of the EAD
   fields must perform public
   authentication key as the necessary security analysis.

3.9.  Applicability Statement

   EDHOC requires certain parameters recipient may otherwise have to be agreed upon between Initiator try several
   keys.  ID_CRED_I and Responder.  Some parameters can be agreed through ID_CRED_R are transported in the protocol
   execution (specifically cipher suite negotiation, 'ciphertext',
   see Section 3.6)
   but other parameters may need to be known out-of-band (e.g., which
   authentication method is used, see 5.4.2 and Section 3.2).

   The purpose of 5.3.2.

   When ID_CRED_x does not contain the applicability statement is describe actual credential, it may be very
   short, e.g., if the intended endpoints have agreed to use of EDHOC a key identifier
   parameter 'kid':

   *  ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or
      R.

   Note that 'kid' is extended to support int values to allow for more one-
   byte identifiers (see Section 8.6 and Section 8.7) which may be
   useful in many scenarios since constrained devices only have a few
   keys.

3.6.  Cipher Suites

   An EDHOC cipher suite consists of an ordered set of algorithms from
   the relevant processing "COSE Algorithms" and verifications "COSE Elliptic Curves" registries as well
   as the EDHOC MAC length.  Algorithms need to be made, including things like:

   1.  How specified with enough
   parameters to make them completely determined.  Currently, none of
   the endpoint detects that an algorithms require parameters.  EDHOC message is received.  This
       includes how EDHOC messages are transported, only specified for example in the
       payload use
   with key exchange algorithms of a CoAP message type ECDH curves.  Use with a certain Uri-Path or Content-
       Format; see Appendix A.3.  * The method other
   types of transporting EDHOC
       messages may also describe data carried along with the messages key exchange algorithms would likely require a specification
   updating EDHOC.  Note that are needed for most signature algorithms, the transport to satisfy
   signature is determined by the signature algorithm and the requirements of
       Section 3.4, e.g., connection identifiers used with certain
       messages, see Appendix A.3.

   2.  Authentication method (METHOD; see Section 3.2).

   3.  Profile for
   authentication credentials (CRED_I, CRED_R; key algorithm together, see Section 3.5.3), e.g., profile for certificate or COSE_key,
       including supported authentication key algorithms (subject public
       key 3.5.1.

   *  EDHOC AEAD algorithm

   *  EDHOC hash algorithm

   *  EDHOC MAC length in X.509 certificate).

   4.  Type bytes (Static DH)

   *  EDHOC key exchange algorithm (ECDH curve)

   *  EDHOC signature algorithm

   *  Application AEAD algorithm

   *  Application hash algorithm

   Each cipher suite is identified with a pre-defined int label.

   EDHOC can be used to identify authentication credentials (ID_CRED_I,
       ID_CRED_R; see Section 3.5.4).

   5.  Use with all algorithms and type curves defined for COSE.
   Implementation can either use one of external authorization data (EAD_1, EAD_2, EAD_3,
       EAD_4; see Section 3.8).

   6.  Identifier used as identity the pre-defined cipher suites
   (Section 8.2) or use any combination of endpoint; see Section 3.5.2.

   7.  If message_4 shall be sent/expected, COSE algorithms and if not, how to ensure a
       protected application message is sent from the Responder
   parameters to define their own private cipher suite.  Private cipher
   suites can be identified with any of the
       Initiator; see Section 5.5. four values -24, -23, -22,
   -21.

   The applicability statement may also contain information about
   supported following CCM cipher suites.  The procedure suites are for selecting constrained IoT where message
   overhead is a very important factor.  Cipher suites 1 and verifying 3 use a
   larger tag length (128-bit) in the EDHOC AEAD algorithm than the
   Application AEAD algorithm (64-bit):

      0. ( 10, -16, 8, 4, -8, 10, -16 )
         (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA,
          AES-CCM-16-64-128, SHA-256)

      1. ( 30, -16, 16, 4, -8, 10, -16 )
         (AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA,
          AES-CCM-16-64-128, SHA-256)

      2. ( 10, -16, 8, 1, -7, 10, -16 )
         (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256,
          AES-CCM-16-64-128, SHA-256)

      3. ( 30, -16, 16, 1, -7, 10, -16 )
         (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256,
          AES-CCM-16-64-128, SHA-256)

   The following ChaCha20 cipher suites are for less constrained
   applications and only use 128-bit tag lengths.

      4. ( 24, -16, 16, 4, -8, 24, -16 )
         (ChaCha20/Poly1305, SHA-256, 16, X25519, EdDSA,
          ChaCha20/Poly1305, SHA-256)

      5. ( 24, -16, 16, 1, -7, 24, -16 )
         (ChaCha20/Poly1305, SHA-256, 16, P-256, ES256,
          ChaCha20/Poly1305, SHA-256)

   The following GCM cipher suite is still performed for general non-constrained
   applications.  It uses high performance algorithms that are widely
   supported:

      6. ( 1, -16, 16, 4, -7, 1, -16 )
         (A128GCM, SHA-256, 16, X25519, ES256,
          A128GCM, SHA-256)

   The following two cipher suites are for high security application
   such as specified by the protocol, but it
   may become simplified by this knowledge.

   An example of an applicability statement is shown in Appendix E.

   For some parameters, like METHOD, ID_CRED_x, type government use and financial applications.  The two cipher
   suites do not share any algorithms.  The first of EAD, the
   receiver two cipher
   suites is able to verify compliance compatible with applicability statement,
   and if it needs to fail because of incompliance, to infer the reason
   why CNSA suite [CNSA].

     24. ( 3, -43, 16, 2, -35, 3, -43 )
         (A256GCM, SHA-384, 16, P-384, ES384,
          A256GCM, SHA-384)

     25. ( 24, -45, 16, 5, -8, 24, -45 )
         (ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA,
          ChaCha20/Poly1305, SHAKE256)

   The different methods use the protocol failed.

   For other parameters, like CRED_x same cipher suites, but some algorithms
   are not used in the case that it some methods.  The EDHOC signature algorithm is not
   transported,
   used in methods without signature authentication.

   The Initiator needs to have a list of cipher suites it may not be possible supports in
   order of preference.  The Responder needs to verify have a list of cipher
   suites it supports.  SUITES_I is a CBOR array containing cipher
   suites that incompliance with
   applicability statement was the reason for failure: Integrity
   verification Initiator supports.  SUITES_I is formatted and
   processed as detailed in message_2 or message_3 may fail not only because Section 5.2.1 to secure the cipher suite
   negotiation.  Examples of
   wrong authentication credential.  For example, cipher suite negotiation are given in case the Initiator
   Section 6.3.2.

3.7.  Ephemeral Public Keys

   EDHOC always uses public key certificate compact representation of elliptic curve points,
   see Appendix B.  In COSE compact representation is achieved by reference (i.e. not transported within
   formatting the protocol) then both endpoints need to use an identical data
   structure ECDH ephemeral public keys as CRED_I COSE_Keys of type EC2 or else the integrity verification will fail.

   Note that it is not necessary for the endpoints
   OKP according to specify a single
   transport for Sections 7.1 and 7.2 of
   [I-D.ietf-cose-rfc8152bis-algs], but only including the EDHOC messages. 'x' parameter
   in G_X and G_Y.  For example, a mix Elliptic Curve Keys of CoAP and
   HTTP may type EC2, compact
   representation MAY be used along the path, and this may still allow correlation
   between messages.

   The applicability statement may be dependent on the identity of also in the
   other endpoint, but this applies only to COSE_Key.  If the later phases of COSE
   implementation requires an 'y' parameter, the
   protocol when identities are known.  (Initiator does not know
   identity value y = false SHALL
   be used.  COSE always use compact output for Elliptic Curve Keys of Responder before having verified message_2,
   type EC2.

3.8.  External Authorization Data (EAD)

   In order to reduce round trips and Responder
   does not know identity number of Initiator before having verified
   message_3.)

   Other conditions messages or to simplify
   processing, external security applications may be part of integrated into
   EDHOC by transporting authorization related data in the applicability statement, such as
   target application or use (if there messages.
   One example is more than one application/use)
   to the extent that third-party identity and authorization information
   protected out of scope of EDHOC can distinguish between them.  In case
   multiple applicability statements are used, the receiver needs to be
   able to determine which [I-D.selander-ace-ake-authz].
   Another example is applicable for a given session, for
   example based on URI certificate enrolment request or the resulting
   issued certificate.

   EDHOC allows opaque external authorization data type.

4.  Key Derivation

   EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm
   in the selected cipher suite (EAD) to derive keys used be sent in
   the EDHOC and messages.  External authorization data sent in the
   application.  Extract message_1
   (EAD_1) or message_2 (EAD_2) must be considered unprotected by EDHOC,
   see Section 7.4.  External authorization data sent in message_3
   (EAD_3) or message_4 (EAD_4) is used to derive fixed-length uniformly
   pseudorandom keys (PRK) from ECDH shared secrets.  Expand is used to
   derive additional output keying material (OKM) from the PRKs.  The
   PRKs are derived using Extract.

      PRK = Extract( salt, IKM )

   If the EDHOC hash algorithm is SHA-2, then Extract( salt, IKM ) =
   HKDF-Extract( salt, IKM ) [RFC5869].  If the EDHOC hash algorithm protected between Initiator and
   Responder.

   External authorization data is
   SHAKE128, then Extract( salt, IKM ) a CBOR sequence (see Appendix C.1)
   consisting of one or more (type, ext_authz_data) pairs as defined
   below:

   ead = KMAC128( salt, IKM, 256, "" ).
   If the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM 1* (
     type : int,
     ext_authz_data : any,
   ) =
   KMAC256( salt, IKM, 512, "" ).

   PRK_2e is used to derive a keystream to encrypt message_2.  PRK_3e2m

   where ext_authz_data is used to derive keys and IVs to produce a MAC authorization related data defined in message_2 a
   separate specification and to
   encrypt message_3.  PRK_4x3m its type is used to derive keys and IVs to
   produce a MAC an int.  Different types of
   ext_authz_data are registered in message_3 and to derive Section 8.11.

   The EAD fields of EDHOC are not intended for generic application specific
   data.

   PRK_2e is derived with the following input:

   o  The salt SHALL  Since data carried in EAD_1 and EAD_2 fields may not be the empty byte string.  Note that [RFC5869]
      specifies
   protected, special considerations need to be made such that if the salt is not provided, it is set to a string
      of zeros (see Section 2.2 of [RFC5869]).  For implementation
      purposes, does
   not providing the salt is the same as setting the salt
      to violate security and privacy requirements of the empty byte string.

   o  The input keying material (IKM) SHALL be service which
   uses this data.  Moreover, the ECDH shared secret
      G_XY (calculated from G_X and Y or G_Y and X) as defined content in
      Section 6.3.1 of [I-D.ietf-cose-rfc8152bis-algs].

   Example: Assuming an EAD field may impact the
   security properties provided by EDHOC.  Security applications making
   use of SHA-256 the extract phase of HKDF
   produces PRK_2e as follows:

      PRK_2e = HMAC-SHA-256( salt, G_XY )

   where salt = 0x (the empty byte string).

   The pseudorandom keys PRK_3e2m and PRK_4x3m are defined as follow:

   o  If the Responder authenticates with a static Diffie-Hellman key,
      then PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is EAD fields must perform the ECDH
      shared secret calculated from G_R and X, or G_X necessary security analysis.

3.9.  Applicability Statement

   EDHOC requires certain parameters to be agreed upon between Initiator
   and R, else
      PRK_3e2m = PRK_2e.

   o  If Responder.  Some parameters can be agreed through the Initiator authenticates with a static Diffie-Hellman key,
      then PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY protocol
   execution (specifically cipher suite negotiation, see Section 3.6)
   but other parameters may need to be known out-of-band (e.g., which
   authentication method is used, see Section 3.2).

   The purpose of the ECDH
      shared secret calculated from G_I and Y, or G_Y and I, else
      PRK_4x3m = PRK_3e2m.

   Example: Assuming applicability statement is to describe the
   intended use of curve25519, EDHOC to allow for the ECDH shared secrets
   G_XY, G_RX, relevant processing and G_IY are the outputs of
   verifications to be made, including things like:

   1.  How the X25519 function
   [RFC7748]:

      G_XY = X25519( Y, G_X ) = X25519( X, G_Y )

   The keys and IVs used in endpoint detects that an EDHOC are derived from PRKs using Expand
   [RFC5869] where the EDHOC-KDF message is instantiated with the received.  This
       includes how EDHOC AEAD
   algorithm messages are transported, for example in the selected cipher suite.

      OKM = EDHOC-KDF( PRK, transcript_hash, label, length )
          = Expand( PRK, info, length )

   where info is the CBOR encoding
       payload of

   info = [
      edhoc_aead_id : int / tstr,
      transcript_hash : bstr,
      label : tstr,
      length : uint
   ]

   where

   o  edhoc_aead_id is an int a CoAP message with a certain Uri-Path or tstr containing the algorithm
      identifier Content-
       Format; see Appendix A.3.

       *  The method of the transporting EDHOC AEAD algorithm in messages may also describe
          data carried along with the selected cipher
      suite encoded as defined in [I-D.ietf-cose-rfc8152bis-algs].  Note messages that a single fixed edhoc_aead_id is used in all invocations of
      EDHOC-KDF, including the derivation of KEYSTREAM_2 and invocations
      of are needed for the EDHOC-Exporter.

   o  transcript_hash is a bstr set
          transport to one of satisfy the transcript hashes
      TH_2, TH_3, requirements of Section 3.4, e.g.,
          connection identifiers used with certain messages, see
          Appendix A.3.

   2.  Authentication method (METHOD; see Section 3.2).

   3.  Profile for authentication credentials (CRED_I, CRED_R; see
       Section 3.5.2), e.g., profile for certificate or TH_4 as defined UCCS, including
       supported authentication key algorithms (subject public key
       algorithm in Sections 5.3.1, 5.4.1, and 4.1.

   o  label is a tstr set X.509 or C509 certificate).

   4.  Type used to the name identify authentication credentials (ID_CRED_I,
       ID_CRED_R; see Section 3.5.4).

   5.  Use and type of the derived key or IV, i.e.
      "K_2m", "IV_2m", "KEYSTREAM_2", "K_3m", "IV_3m", "K_3ae", or
      "IV_3ae".

   o  length is the length external authorization data (EAD_1, EAD_2, EAD_3,
       EAD_4; see Section 3.8).

   6.  Identifier used as identity of output keying material (OKM) in bytes

   If the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, length
   ) = HKDF-Expand( PRK, info, length ) [RFC5869].  If the EDHOC hash
   algorithm is SHAKE128, then Expand( PRK, info, length ) = KMAC128(
   PRK, info, L, "" ). endpoint; see Section 3.5.3.

   7.  If the EDHOC hash algorithm is SHAKE256, then
   Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ).

   KEYSTREAM_2 are derived using the transcript hash TH_2 and the
   pseudorandom key PRK_2e.  K_2m and IV_2m are derived using the
   transcript hash TH_2 and the pseudorandom key PRK_3e2m.  K_3ae and
   IV_3ae are derived using the transcript hash TH_3 and the
   pseudorandom key PRK_3e2m.  K_3m and IV_3m are derived using the
   transcript hash TH_3 message_4 shall be sent/expected, and the pseudorandom key PRK_4x3m.  IVs are only
   used if the EDHOC AEAD algorithm uses IVs.

4.1.  EDHOC-Exporter Interface

   Application keys and other application specific data can be derived
   using the EDHOC-Exporter interface defined as:

      EDHOC-Exporter(label, context, length)
        = EDHOC-KDF(PRK_4x3m, TH_4, label_context, length)

   label_context is not, how to ensure a CBOR sequence:

   label_context = (
     label : tstr,
     context : bstr,
   )

   where label
       protected application message is a registered tstr sent from the EDHOC Exporter Label
   registry (Section 8.1), context is a bstr defined by Responder to the application,
       Initiator; see Section 5.5.

   The applicability statement may also contain information about
   supported cipher suites.  The procedure for selecting and length verifying
   cipher suite is a uint defined still performed as specified by the application.  The (label,
   context) pair must be unique, i.e. a (label, context) MUST NOT be
   used for two different purposes.  However an application can re-
   derive the same key several times as long as protocol, but it
   may become simplified by this knowledge.

   An example of an applicability statement is done shown in a secure
   way. Appendix E.

   For example, in most encryption algorithms some parameters, like METHOD, ID_CRED_x, type of EAD, the same (key,
   nonce) pair must not be reused.

   The transcript hash TH_4
   receiver is a CBOR encoded bstr able to verify compliance with applicability statement,
   and the input if it needs to fail because of incompliance, to infer the
   hash function is a CBOR Sequence.

      TH_4 = H( TH_3, CIPHERTEXT_3 )

   where H() is reason
   why the hash function protocol failed.

   For other parameters, like CRED_x in the selected cipher suite.
   Examples of use of case that it is not
   transported, it may not be possible to verify that incompliance with
   applicability statement was the EDHOC-Exporter are given reason for failure: Integrity
   verification in Section 5.5.2 and
   Appendix A.

   To provide forward secrecy message_2 or message_3 may fail not only because of
   wrong authentication credential.  For example, in case the Initiator
   uses public key certificate by reference (i.e., not transported
   within the protocol) then both endpoints need to use an even more efficient way than re-
   running EDHOC, EDHOC provides identical
   data structure as CRED_I or else the function EDHOC-KeyUpdate.  When
   EDHOC-KeyUpdate integrity verification will
   fail.

   Note that it is called not necessary for the old PRK_4x3m is deleted and endpoints to specify a single
   transport for the new
   PRK_4x3m is calculated as EDHOC messages.  For example, a "hash" mix of CoAP and
   HTTP may be used along the old key using the Extract
   function as illustrated by the following pseudocode:

      EDHOC-KeyUpdate( nonce ):
         PRK_4x3m = Extract( nonce, PRK_4x3m )

5.  Message Formatting path, and Processing

   This section specifies formatting this may still allow correlation
   between messages.

   The applicability statement may be dependent on the identity of the messages and processing
   steps.  Error messages are specified
   other endpoint, or other information carried in Section 6.

   An an EDHOC message is encoded as a sequence of CBOR data (CBOR
   Sequence, [RFC8742]).  Additional optimizations are made message, but
   it then applies only to reduce
   message overhead.

   While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
   structures, only a subset later phases of the parameters protocol when such
   information is included in the EDHOC
   messages.  The unprotected COSE header in COSE_Sign1, known.  (The Initiator does not know identity of
   Responder before having verified message_2, and
   COSE_Encrypt0 (not included in the EDHOC message) MAY contain
   parameters (e.g. 'alg').

5.1.  Message Processing Outline

   This section outlines the message processing Responder does
   not know identity of EDHOC.

   For each session, the endpoints are assumed to keep an associated
   protocol state containing identifiers, keys, etc. used for subsequent
   processing Initiator before having verified message_3.)
   Other conditions may be part of protocol related data.  The protocol state the applicability statement, such as
   target application or use (if there is assumed
   to be associated more than one application/use)
   to an applicability statement (Section 3.9) which
   provides the context for how messages are transported, identified and
   processed. extent that EDHOC messages SHALL can distinguish between them.  In case
   multiple applicability statements are used, the receiver needs to be processed according
   able to the current protocol
   state.  The following steps are expected to be performed at reception
   of an EDHOC message:

   1.  Detect that an EDHOC message has been received, determine which is applicable for a given session, for
   example by
       means of port number, URI, based on URI or media type (Section 3.9).

   2.  Retrieve the protocol state according to the message correlation
       provided by external authorization data type.

4.  Key Derivation

   EDHOC uses Extract-and-Expand [RFC5869] with the transport, see Section 3.4.  If there is no
       protocol state, EDHOC hash algorithm
   in the case of message_1, a new protocol state is
       created.  The Responder endpoint needs selected cipher suite to make use of available
       Denial-of-Service mitigation (Section 7.5).

   3.  If derive keys used in EDHOC and in the message received
   application.  Extract is an error message then process
       according used to Section 6, else process as the expected next message
       according derive fixed-length uniformly
   pseudorandom keys (PRK) from ECDH shared secrets.  Expand is used to
   derive additional output keying material (OKM) from the protocol state.

   If the processing fails, then the protocol PRKs.

   This section defines Extract, Expand and other key derivation
   functions based on these: Expand is discontinued, an error
   message sent, used to define EDHOC-KDF and in
   turn EDHOC-Exporter, whereas Extract is used to define EDHOC-
   KeyUpdate.

4.1.  Extract

   The pseudorandom keys (PRKs) are derived using Extract.

      PRK = Extract( salt, IKM )

   where the protocol state erased.  Further details input keying material (IKM) and salt are
   provided in defined for each
   PRK below.

   The definition of Extract depends on the following subsections.

   Different instances EDHOC hash algorithm of the same message MUST NOT be processed in one
   session.  Note that processing will fail
   selected cipher suite:

   *  if the same message appears
   a second time for EDHOC processing because hash algorithm is SHA-2, then Extract( salt, IKM ) =
      HKDF-Extract( salt, IKM ) [RFC5869]

   *  if the state of EDHOC hash algorithm is SHAKE128, then Extract( salt, IKM )
      = KMAC128( salt, IKM, 256, "" )

   *  if the protocol
   has moved on and now expects something else.  This assumes that
   message duplication due EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM )
      = KMAC256( salt, IKM, 512, "" )

4.1.1.  PRK_2e

   PRK_2e is used to re-transmissions derive a keystream to encrypt message_2.  PRK_2e is handled by
   derived with the
   transport protocol, see Section 3.4. following input:

   *  The case when salt SHALL be the transport
   does empty byte string.  Note that [RFC5869]
      specifies that if the salt is not support message deduplication provided, it is addressed in Appendix F.

5.2.  EDHOC Message 1

5.2.1.  Formatting set to a string
      of Message 1

   message_1 zeros (see Section 2.2 of [RFC5869]).  For implementation
      purposes, not providing the salt is the same as setting the salt
      to the empty byte string.

   *  The IKM SHALL be a CBOR Sequence (see Appendix C.1) the ECDH shared secret G_XY (calculated from G_X
      and Y or G_Y and X) as defined
   below

   message_1 in Section 6.3.1 of
      [I-D.ietf-cose-rfc8152bis-algs].

   Example: Assuming the use of curve25519, the ECDH shared secret G_XY
   is the output of the X25519 function [RFC7748]:

      G_XY = (
     METHOD : int,
     SUITES_I : [ selected : suite, supported : 2* suite ] / suite, X25519( Y, G_X : bstr,
     C_I : bstr / int,
     ? EAD ; EAD_1 )

   suite = int

   where:

   o  METHOD = 0, 1, 2, or 3 (see Figure 4).

   o  SUITES_I - cipher suites which X25519( X, G_Y )

   Example: Assuming the Initiator supports in order of
      (decreasing) preference.  The list use of supported cipher suites can
      be truncated at SHA-256 the end, extract phase of HKDF
   produces PRK_2e as follows:

      PRK_2e = HMAC-SHA-256( salt, G_XY )

   where salt = 0x (the empty byte string).

4.1.2.  PRK_3e2m

   PRK_3e2m is detailed used to produce a MAC in the processing steps
      below message_2 and Section 6.3.  One of the supported cipher suites to encrypt
   message_3.  PRK_3e2m is
      selected.  The selected suite derived as follows:

   If the Responder authenticates with a static Diffie-Hellman key, then
   PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is the first suite ECDH shared
   secret calculated from G_R and X, or G_X and R, else PRK_3e2m =
   PRK_2e.

4.1.3.  PRK_4x3m

   PRK_4x3m is used to produce a MAC in the SUITES_I
      CBOR array. message_3, to encrypt message_4,
   and to derive application specific data.  PRK_4x3m is derived as
   follows:

   If the Initiator authenticates with a single supported cipher suite is conveyed static Diffie-Hellman key, then
      that cipher suite
   PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY is selected the ECDH shared
   secret calculated from G_I and SUITES_I is encoded as an int
      instead of an array.

   o  G_X - Y, or G_Y and I, else PRK_4x3m =
   PRK_3e2m.

4.2.  Expand

   The keys, IVs and MACs used in EDHOC are derived from the ephemeral public key of PRKs using
   Expand, and instantiated with the Initiator

   o  C_I - variable EDHOC AEAD algorithm in the
   selected cipher suite.

      OKM = EDHOC-KDF( PRK, transcript_hash, label, context, length connection identifier

   o  EAD_1 - unprotected external authorization data, see Section 3.8.

5.2.2.  Initiator Processing of Message 1

   The Initiator SHALL compose message_1 as follows:

   o  The supported cipher suites and )
          = Expand( PRK, info, length )

   where info is the order CBOR encoding of preference MUST NOT
      be changed based on previous error messages.  However, the list
      SUITES_I sent to the Responder MAY be truncated such that cipher
      suites which are

   info = [
      edhoc_aead_id : int / tstr,
      transcript_hash : bstr,
      label : tstr,
      * context : any,
      length : uint,
   ]

   where

   *  edhoc_aead_id is an int or tstr containing the least preferred are omitted.  The amount algorithm
      identifier of
      truncation MAY be changed between sessions, e.g. based on previous
      error messages (see next bullet), but all cipher suites which are
      more preferred than the least preferred EDHOC AEAD algorithm in the selected cipher
      suite encoded as defined in the list
      MUST be included [I-D.ietf-cose-rfc8152bis-algs].  Note
      that a single fixed edhoc_aead_id is used in all invocations of
      EDHOC-KDF, including the list.

   o  The Initiator MUST select its most preferred cipher suite,
      conditioned on what it can assume to be supported by the
      Responder.  If the Initiator previously received from derivation of KEYSTREAM_2 and invocations
      of the
      Responder an error message with error code 2 EDHOC-Exporter (see Section 6.3)
      indicating cipher suites supported by the Responder which also are
      supported by 4.3).

   *  transcript_hash is a bstr set to one of the Initiator, then transcript hashes
      TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.3.

   *  label is a tstr set to the Initiator SHOULD select name of the
      most preferred cipher suite of those (note that error messages are
      not authenticated and may be forged).

   o  Generate an ephemeral ECDH key pair using derived key, IV or MAC;
      i.e., "KEYSTREAM_2", "MAC_2", "K_3ae", "IV_3ae", or "MAC_3".

   *  context is a CBOR sequence, i.e., zero or more encoded CBOR data
      items

   *  length is the curve length of output keying material (OKM) in bytes

   The definition of Expand depends on the EDHOC hash algorithm of the
   selected cipher suite and format it as a COSE_Key.  Let G_X be suite:

   *  if the
      'x' parameter of EDHOC hash algorithm is SHA-2, then Expand( PRK, info,
      length ) = HKDF-Expand( PRK, info, length ) [RFC5869]

   *  if the COSE_Key.

   o  Choose a connection identifier C_I and store it for EDHOC hash algorithm is SHAKE128, then Expand( PRK, info,
      length ) = KMAC128( PRK, info, L, "" )

   *  if the EDHOC hash algorithm is SHAKE256, then Expand( PRK, info,
      length of ) = KMAC256( PRK, info, L, "" )

   where L = 8*length, the protocol.

   o  Encode message_1 as a sequence of CBOR encoded data items as
      specified output length in Section 5.2.1

5.2.3.  Responder Processing of Message 1 bits.

   The Responder SHALL process message_1 keys, IVs and MACs are derived as follows:

   o  Decode message_1 (see Appendix C.1).

   o  Verify that the selected cipher suite

   *  KEYSTREAM_2 is supported derived using the transcript hash TH_2 and that no
      prior cipher suite in SUITES_I is supported.

   o  Pass EAD_1 to the security application.

   If any processing step fails,
      pseudorandom key PRK_2e.

   *  MAC_2 is derived using the Responder SHOULD send an EDHOC
   error message back, formatted as defined in Section 6, transcript hash TH_2 and the
   session MUST be discontinued.  Sending error messages is essential
   for debugging but MAY e.g. be skipped due to denial of service
   reasons, see Section 7.

5.3.  EDHOC Message 2

5.3.1.  Formatting of Message 2

   message_2
      pseudorandom key PRK_3e2m.

   *  K_3ae and data_2 SHALL be CBOR Sequences (see Appendix C.1) as
   defined below

   message_2 = (
     data_2,
     CIPHERTEXT_2 : bstr,
   )

   data_2 = (
     G_Y : bstr,
     C_R : bstr / int,
   )

   where:

   o  G_Y - IV_3ae are derived using the ephemeral public key of transcript hash TH_3 and
      the Responder

   o  C_R - variable length connection identifier

5.3.2.  Responder Processing of Message 2

   The Responder SHALL compose message_2 as follows:

   o  Generate an ephemeral ECDH pseudorandom key pair using PRK_3e2m.  IVs are only used if the curve in EDHOC
      AEAD algorithm uses IVs.

   *  MAC_3 is derived using the
      selected cipher suite transcript hash TH_3 and format it as a COSE_Key.  Let G_Y be the
      'x' parameter of the COSE_Key.

   o  Choose
      pseudorandom key PRK_4x3m.

   KEYSTREAM_2, K_3ae, and IV_3ae do not use a connection identifier C_R context.  MAC_2 and store it for the length of
      the protocol.

   o  Compute MAC_3
   use context as defined in Section 5.3.2 and Section 5.4.2,
   respectively.

4.3.  EDHOC-Exporter

   Application keys and other application specific data can be derived
   using the transcript hash TH_2 EDHOC-Exporter interface defined as:

      EDHOC-Exporter(label, context, length)
        = H( H(message_1), data_2 ) EDHOC-KDF(PRK_4x3m, TH_4, label, context, length)

   where
      H() label is a registered tstr from the hash function in the selected cipher suite.  The
      transcript hash TH_2 EDHOC Exporter Label
   registry (Section 8.1), context is a CBOR encoded bstr and the input to sequence defined by the
      hash function
   application, and length is a CBOR Sequence.  Note that H(message_1) can be
      computed and cached already in uint defined by the processing of message_1.

   o  Compute application.  The
   (label, context) pair must be unique, i.e., a (label, context) MUST
   NOT be used for two different purposes.  However an inner COSE_Encrypt0 application can
   re-derive the same key several times as defined long as it is done in Section 5.3 of
      [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm a
   secure way.  For example, in most encryption algorithms the selected cipher suite, K_2m, IV_2m, and same
   (key, nonce) pair must not be reused.  The context can for example be
   the following
      parameters:

      *  protected = << ID_CRED_R >>
         +  ID_CRED_R - identifier to facilitate retrieval of CRED_R,
            see Section 3.5.4

      *  external_aad = << TH_2, CRED_R, ? EAD_2 >>

         +  CRED_R - empty (zero-length) sequence or a single CBOR byte string.

   The transcript hash TH_4 is a CBOR encoded bstr containing the credential of the Responder,
            see Section 3.5.4

         +  EAD_2 = unprotected external authorization data, see
            Section 3.8

      *  plaintext = h''

      COSE constructs and the input to the AEAD [RFC5116] as follows:

      *  Key K = EDHOC-KDF( PRK_3e2m, TH_2, "K_2m", length )

      *  Nonce N
   hash function is a CBOR Sequence.

      TH_4 = EDHOC-KDF( PRK_3e2m, TH_2, "IV_2m", length H( TH_3, CIPHERTEXT_3 )

      *  Plaintext P = 0x (the empty string)

      *  Associated data A =

         [ "Encrypt0", << ID_CRED_R >>, << TH_2, CRED_R, ? EAD_2 >> ]

      MAC_2

   where H() is the 'ciphertext' hash function in the selected cipher suite.
   Examples of use of the inner COSE_Encrypt0.

   o  If EDHOC-Exporter are given in Section 5.5.2 and
   Appendix A.

4.4.  EDHOC-KeyUpdate

   To provide forward secrecy in an even more efficient way than re-
   running EDHOC, EDHOC provides the Responder authenticates with a static Diffie-Hellman key
      (method equals 1 or 3), then Signature_or_MAC_2 function EDHOC-KeyUpdate.  When
   EDHOC-KeyUpdate is MAC_2.  If called the
      Responder authenticates with a signature key (method equals 0 or
      2), then Signature_or_MAC_2 old PRK_4x3m is deleted and the 'signature' of a COSE_Sign1
      object new
   PRK_4x3m is calculated as defined in Section 4.4 a "hash" of
      [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm in
      the selected cipher suite, the private authentication old key of using the
      Responder, and Extract
   function as illustrated by the following parameters:

      *  protected = << ID_CRED_R >>

      *  external_aad = << TH_2, CRED_R, ? EAD_2 >>

      *  payload pseudocode:

      EDHOC-KeyUpdate( nonce ):
         PRK_4x3m = MAC_2

      COSE constructs the Extract( nonce, PRK_4x3m )

   The EDHOC-KeyUpdate takes a nonce as input to the Signature Algorithm as:

      * guarantee that there
   are no short cycles.  The key is the private authentication key of Initiator and the Responder.

      *  The message M Responder need to be signed =

         [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? EAD_2 >>,
         MAC_2 ]

   o  CIPHERTEXT_2 is encrypted by using agree
   on the Expand function as a binary
      additive stream cipher.

      *  plaintext = ( ID_CRED_R / bstr / int, Signature_or_MAC_2, ?
         EAD_2 )

         +  Note that if ID_CRED_R contains nonce, which can e.g., be a single 'kid2' parameter,
            i.e., ID_CRED_R = { 4 : kid_R }, only the byte string counter or
            integer kid_R is conveyed in the plaintext encoded as a bstr
            / int.

      *  CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2

   o  Encode message_2 random number.  While
   the KeyUpdate method provides forward secrecy it does not give as a sequence of CBOR encoded data items
   strong security properties as
      specified in re-running EDHOC, see Section 5.3.1.

5.3.3.  Initiator 7.

5.  Message Formatting and Processing

   This section specifies formatting of Message 2

   The Initiator SHALL process message_2 as follows:

   o  Decode message_2 (see Appendix C.1).

   o  Retrieve the protocol state using the message correlation provided
      by the transport (e.g., the CoAP Token messages and the 5-tuple as a
      client, or the prepended C_I processing
   steps.  Error messages are specified in Section 6.

   An EDHOC message is encoded as a server).

   o  Decrypt CIPHERTEXT_2, see Section 5.3.2.

   o  Pass EAD_2 sequence of CBOR data (CBOR
   Sequence, [RFC8742]).  Additional optimizations are made to reduce
   message overhead.

   While EDHOC uses the security application.

   o  Verify that the identity COSE_Key, COSE_Sign1, and COSE_Encrypt0
   structures, only a subset of the Responder parameters is an allowed identity
      for this connection, see Section 3.5.

   o  Verify Signature_or_MAC_2 using the algorithm included in the selected
      cipher suite. EDHOC
   messages, see Appendix C.3.  The verification process depends on unprotected COSE header in
   COSE_Sign1, and COSE_Encrypt0 (not included in the method, see
      Section 5.3.2.

   If any EDHOC message) MAY
   contain parameters (e.g., 'alg').

5.1.  Message Processing Outline

   This section outlines the message processing step fails, of EDHOC.

   For each session, the Initiator SHOULD send endpoints are assumed to keep an EDHOC
   error message back, formatted as defined in Section 6.  Sending error
   messages is essential associated
   protocol state containing identifiers, keys, etc. used for debugging but MAY e.g.be skipped if a
   session cannot subsequent
   processing of protocol related data.  The protocol state is assumed
   to be found or due associated to denial of service reasons, see
   Section 7.  If an error message is sent, applicability statement (Section 3.9) which
   provides the session MUST be
   discontinued.

5.4.  EDHOC Message 3

5.4.1.  Formatting of Message 3

   message_3 context for how messages are transported, identified,
   and processed.

   EDHOC messages SHALL be a CBOR Sequence (see Appendix C.1) as defined
   below

   message_3 = (
     CIPHERTEXT_3 : bstr,
   )

5.4.2.  Initiator Processing of Message 3 processed according to the current protocol
   state.  The Initiator SHALL compose message_3 as follows:

   o  Compute following steps are expected to be performed at reception
   of an EDHOC message:

   1.  Detect that an EDHOC message has been received, for example by
       means of port number, URI, or media type (Section 3.9).

   2.  Retrieve the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H()
      is protocol state according to the hash function message correlation
       provided by the transport, see Section 3.4.  If there is no
       protocol state, in the selected cipher suite. case of message_1, a new protocol state is
       created.  The transcript
      hash TH_3 Responder endpoint needs to make use of available
       Denial-of-Service mitigation (Section 7.5).

   3.  If the message received is a CBOR encoded bstr and an error message, then process
       according to Section 6, else process as the input expected next message
       according to the hash
      function protocol state.

   If the processing fails for some reason then, typically, an error
   message is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) can
      be computed sent, the protocol is discontinued, and cached already the protocol state
   erased.  Further details are provided in the processing of message_2.

   o  Compute an inner COSE_Encrypt0 as defined following subsections
   and in Section 5.3 6.

   Different instances of
      [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm same message MUST NOT be processed in one
   session.  Note that processing will fail if the selected cipher suite, K_3m, IV_3m, and the following
      parameters:

      *  protected = << ID_CRED_I >>

         +  ID_CRED_I - identifier to facilitate retrieval of CRED_I,
            see Section 3.5.4

      *  external_aad = << TH_3, CRED_I, ? EAD_3 >>

         +  CRED_I - bstr containing same message appears
   a second time for EDHOC processing because the credential state of the Initiator,
            see Section 3.5.4.

         +  EAD_3 = protected external authorization data, protocol
   has moved on and now expects something else.  This assumes that
   message duplication due to re-transmissions is handled by the
   transport protocol, see Section 3.8

      *  plaintext = h''

      COSE constructs the input to 3.4.  The case when the AEAD [RFC5116] transport
   does not support message deduplication is addressed in Appendix F.

5.2.  EDHOC Message 1

5.2.1.  Formatting of Message 1

   message_1 SHALL be a CBOR Sequence (see Appendix C.1) as follows:

      *  Key K defined
   below

   message_1 = EDHOC-KDF( PRK_4x3m, TH_3, "K_3m", length (
     METHOD : int,
     SUITES_I : [ selected : suite, supported : 2* suite ] / suite,
     G_X : bstr,
     C_I : bstr / int,
     ? EAD_1 : ead,
   )

      *  Nonce N

   suite = EDHOC-KDF( PRK_4x3m, TH_3, "IV_3m", length ) int

   where:

   *  Plaintext P  METHOD = 0x (the empty string) 0, 1, 2, or 3 (see Figure 4).

   *  Associated data A =

         [ "Encrypt0", << ID_CRED_I >>, << TH_3, CRED_I, ? EAD_3 >> ]

      MAC_3 is  SUITES_I - cipher suites which the 'ciphertext' Initiator supports in order of
      (decreasing) preference.  The list of supported cipher suites can
      be truncated at the inner COSE_Encrypt0.

   o  If the Initiator authenticates with a static Diffie-Hellman key
      (method equals 2 or 3), then Signature_or_MAC_3 end, as is MAC_3.  If detailed in the
      Initiator authenticates with a signature key (method equals 0 or
      1), then Signature_or_MAC_3 is the 'signature' of a COSE_Sign1
      object as defined in processing steps
      below and Section 4.4 6.3.  One of
      [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm supported cipher suites is
      selected.  The selected suite is the first suite in the selected SUITES_I
      CBOR array.  If a single supported cipher suite, suite is conveyed, then
      that cipher suite is selected and SUITES_I is encoded as an int
      instead of an array.

   *  G_X - the private authentication ephemeral public key of the
      Initiator, and the following parameters:

      *  protected = << ID_CRED_I >> Initiator

   *  external_aad = << TH_3, CRED_I, ? EAD_3 >>  C_I - variable length connection identifier

   *  payload = MAC_3

      COSE constructs the input to the Signature Algorithm as:  EAD_1 - unprotected external authorization data, see Section 3.8.

5.2.2.  Initiator Processing of Message 1

   The Initiator SHALL compose message_1 as follows:

   *  The key is supported cipher suites and the private authentication key order of preference MUST NOT
      be changed based on previous error messages.  However, the Initiator.

      *  The message M list
      SUITES_I sent to the Responder MAY be signed =

         [ "Signature1", << ID_CRED_I >>, << TH_3, CRED_I, ? EAD_3 >>,
         MAC_3 ]

   o  Compute an outer COSE_Encrypt0 as defined in Section 5.3 truncated such that cipher
      suites which are the least preferred are omitted.  The amount of
      [I-D.ietf-cose-rfc8152bis-struct], with
      truncation MAY be changed between sessions, e.g., based on
      previous error messages (see next bullet), but all cipher suites
      which are more preferred than the EDHOC AEAD algorithm least preferred cipher suite in
      the selected cipher suite, K_3ae, IV_3ae, and list MUST be included in the following
      parameters. list.

   *  The protected header SHALL Initiator MUST select its most preferred cipher suite,
      conditioned on what it can assume to be empty.

      *  external_aad = TH_3

      *  plaintext = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ?
         EAD_3 )

         +  Note supported by the
      Responder.  If the Initiator previously received from the
      Responder an error message with error code 2 (see Section 6.3)
      indicating cipher suites supported by the Responder which also are
      supported by the Initiator, then the Initiator SHOULD select the
      most preferred cipher suite of those (note that if ID_CRED_I contains a single 'kid2' parameter,
            i.e., ID_CRED_I = { 4 : kid_I }, only error messages are
      not authenticated and may be forged).

   *  Generate an ephemeral ECDH key pair using the byte string or
            integer kid_I is conveyed curve in the plaintext encoded
      selected cipher suite and format it as a bstr
            or int.

      COSE constructs COSE_Key.  Let G_X be the input to
      'x' parameter of the AEAD [RFC5116] as follows:

      *  Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length )
      *  Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length )

      *  Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ?
         EAD_3 ) COSE_Key.

   *  Associated data A = [ "Encrypt0", h'', TH_3 ]

      CIPHERTEXT_3 is  Choose a connection identifier C_I and store it for the 'ciphertext' length of
      the outer COSE_Encrypt0.

   o protocol.

   *  Encode message_3 message_1 as a sequence of CBOR encoded data items as
      specified in Section 5.4.1.

   Pass the connection identifiers (C_I, C_R) and the application
   algorithms in 5.2.1

5.2.3.  Responder Processing of Message 1

   The Responder SHALL process message_1 as follows:

   *  Decode message_1 (see Appendix C.1).

   *  Verify that the selected cipher suite to the application.  The
   application can now derive application keys using the EDHOC-Exporter
   interface.

   After sending message_3, the Initiator is assured supported and that no other party
   than the Responder can compute the key PRK_4x3m (implicit key
   authentication).  The Initiator can securely derive application keys
   and send protected application data.  However,
      prior cipher suite in SUITES_I is supported.

   *  Pass EAD_1 to the Initiator does not
   know that security application.

   If any processing step fails, the Responder has actually computed the key PRK_4x3m and
   therefore the Initiator SHOULD NOT permanently store the keying
   material PRK_4x3m send an EDHOC
   error message back, formatted as defined in Section 6, and TH_4, or derived application keys, until the
   Initiator is assured that the Responder has actually computed the key
   PRK_4x3m (explicit key confirmation).  This
   session MUST be discontinued.  Sending error messages is similar to waiting essential
   for
   acknowledgement (ACK) in debugging but MAY e.g., be skipped due to denial-of-service
   reasons, see Section 7.

5.3.  EDHOC Message 2

5.3.1.  Formatting of Message 2

   message_2 SHALL be a transport protocol.  Explicit key
   confirmation is e.g. assured when CBOR Sequence (see Appendix C.1) as defined
   below

   message_2 = (
     G_Y_CIPHERTEXT_2 : bstr,
     C_R : bstr / int,
   )

   where:

   *  G_Y_CIPHERTEXT_2 - the Initiator has verified an
   OSCORE message or message_4 from concatenation of G_Y, the Responder.

5.4.3. ephemeral public
      key of the Responder, and CIPHERTEXT_2

   *  C_R - variable length connection identifier

5.3.2.  Responder Processing of Message 3 2

   The Responder SHALL process message_3 compose message_2 as follows:

   o  Decode message_3 (see Appendix C.1).

   o  Retrieve the protocol state

   *  Generate an ephemeral ECDH key pair using the message correlation provided
      by the transport (e.g., curve in the CoAP Token
      selected cipher suite and the 5-tuple format it as a
      client, or COSE_Key.  Let G_Y be the prepended C_R as
      'x' parameter of the COSE_Key.

   *  Choose a server).

   o  Decrypt connection identifier C_R and verify store it for the outer COSE_Encrypt0 as defined in
      Section 5.3 length of [I-D.ietf-cose-rfc8152bis-struct], with
      the EDHOC
      AEAD algorithm protocol.

   *  Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R )
      where H() is the hash function in the selected cipher suite, K_3ae, suite.  The
      transcript hash TH_2 is a CBOR encoded bstr and IV_3ae.

   o  Pass EAD_3 the input to the security application.

   o  Verify
      hash function is a CBOR Sequence.  Note that H(message_1) can be
      computed and cached already in the identity processing of message_1.

   *  Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", ( ID_CRED_R,
      CRED_R, ? EAD_2 ), mac_length ).  If the Initiator Responder authenticates
      with a static Diffie-Hellman key (method equals 1 or 3), then
      mac_length is an allowed identity
      for this connection, see Section 3.5.

   o  Verify Signature_or_MAC_3 using the algorithm in EDHOC MAC length given by the selected cipher suite.  The verification process depends on  If
      the method, see
      Section 5.4.2.

   o  Pass Responder authenticates with a signature key (method equals 0
      or 2), then mac_length is equal to the connection identifiers (C_I, C_R), and output size of the application
      algorithms in EDHOC
      hash algorithm given by the selected cipher suite suite.

      -  ID_CRED_R - identifier to facilitate retrieval of CRED_R, see
         Section 3.5.4

      -  CRED_R - CBOR item containing the security
      application.  The application can now derive application keys
      using credential of the EDHOC-Exporter interface. Responder,
         see Section 3.5.4

      -  EAD_2 = unprotected external authorization data, see
         Section 3.8

   *  If any processing step fails, the Responder SHOULD send an EDHOC
   error message back, formatted as defined in Section 6.  Sending error
   messages is essential for debugging but MAY e.g.be skipped if authenticates with a
   session cannot be found or due to denial of service reasons, see
   Section 7.  If an error message is sent, the session MUST be
   discontinued.

   After verifying message_3, the Responder is assured that the
   Initiator has calculated the key PRK_4x3m (explicit static Diffie-Hellman key confirmation)
   and that no other party than the Responder can compute the key.  The
   Responder can securely send protected application data and store the
   keying material PRK_4x3m and TH_4.

5.5.  EDHOC Message 4

   This section specifies message_4 which is OPTIONAL to support.  Key
   confirmation
      (method equals 1 or 3), then Signature_or_MAC_2 is normally provided by sending an application message
   from MAC_2.  If the
      Responder to the Initiator protected authenticates with a signature key derived with
   the EDHOC-Exporter, e.g., using OSCORE (see Appendix A).  In
   deployments where no protected application message is sent from the
   Responder to the Initiator, the Responder MUST send message_4.  Two
   examples of such deployments:

   1.  When EDHOC is only used for authentication and no application
       data is sent.

   2.  When application data (method equals 0 or
      2), then Signature_or_MAC_2 is only sent from the Initiator to the
       Responder.

   Further considerations are provided in Section 3.9.

5.5.1.  Formatting of Message 4

   message_4 SHALL be a CBOR Sequence (see Appendix C.1) as defined
   below

   message_4 = (
     CIPHERTEXT_4 : bstr,
   )

5.5.2.  Responder Processing 'signature' of Message 4

   The Responder SHALL compose message_4 as follows:

   o  Compute a COSE_Encrypt0 COSE_Sign1
      object as defined in Section 5.3 4.4 of
      [I-D.ietf-cose-rfc8152bis-struct], with
      [I-D.ietf-cose-rfc8152bis-struct] using the EDHOC AEAD signature algorithm in
      the selected cipher suite, and the following parameters.  The
      protected header SHALL be empty.

      * private authentication key of the
      Responder, and the following parameters:

      -  protected = h''

      * << ID_CRED_R >>

      -  external_aad = TH_4

      *  plaintext = ( << TH_2, CRED_R, ? EAD_4 )

      where EAD_4 is protected external authorization data, see
      Section 3.8. EAD_2 >>

      -  payload = MAC_2

      COSE constructs the input to the AEAD [RFC5116] as
      follows:

      *  Key K = EDHOC-Exporter( "EDHOC_message_4_Key", h'', length )

      *  Nonce N Signature Algorithm as:

      -  The key is the private authentication key of the Responder.

      -  The message M to be signed = EDHOC-Exporter( "EDHOC_message_4_Nonce", h'', length
         )

         [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? EAD_2 >>,
         MAC_2 ]

   *  Plaintext P  CIPHERTEXT_2 is encrypted by using the Expand function as a binary
      additive stream cipher.

      -  plaintext = ( ID_CRED_R / bstr / int, Signature_or_MAC_2, ? EAD_4
         EAD_2 )

      *  Associated data A

         o  Note that if ID_CRED_R contains a single 'kid' parameter,
            i.e., ID_CRED_R = [ "Encrypt0", h'', TH_4 ]

      CIPHERTEXT_4 is { 4 : kid_R }, only the 'ciphertext' of byte string or
            integer kid_R is conveyed in the COSE_Encrypt0.

   o plaintext encoded as a bstr
            or int.

      -  CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2

   *  Encode message_4 message_2 as a sequence of CBOR encoded data items as
      specified in Section 5.5.1.

5.5.3. 5.3.1.

5.3.3.  Initiator Processing of Message 4 2

   The Initiator SHALL process message_4 message_2 as follows:

   o

   *  Decode message_4 message_2 (see Appendix C.1).

   o

   *  Retrieve the protocol state using the message correlation provided
      by the transport (e.g., the CoAP Token and the 5-tuple as a
      client, or the prepended C_I as a server).

   o

   *  Decrypt and verify the outer COSE_Encrypt0 as defined in CIPHERTEXT_2, see Section 5.3 5.3.2.

   *  Pass EAD_2 to the security application.

   *  Verify that the identity of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC
      AEAD Responder is an allowed identity
      for this connection, see Section 3.5.

   *  Verify Signature_or_MAC_2 using the algorithm in the selected
      cipher suite, and suite.  The verification process depends on the parameters
      defined in method, see
      Section 5.5.2.

   o  Pass EAD_4 to the security application. 5.3.2.

   If any verification processing step fails fails, the Initiator MUST SHOULD send an EDHOC
   error message back, formatted as defined in Section 6, and the session MUST
   be discontinued. 6.  Error Handling

   This section defines the format for error messages.

   An EDHOC  Sending error message can
   messages is essential for debugging but MAY e.g., be sent by either endpoint as skipped if a reply to
   any non-error EDHOC message.  How errors at the EDHOC layer are
   transported depends on lower layers, which need to enable error
   messages to
   session cannot be sent and processed as intended.

   Errors in EDHOC are fatal.  After sending an error message, the
   sender MUST discontinue the protocol.  The receiver SHOULD treat an
   error message as found or due to denial-of-service reasons, see
   Section 7.  If an indication that the other party likely has
   discontinued the protocol.  But as the error message is not
   authenticated, a received error message might also have been sent by
   an attacker and the receiver MAY therefore try to continue sent, the
   protocol.

   error session MUST be
   discontinued.

5.4.  EDHOC Message 3
5.4.1.  Formatting of Message 3

   message_3 SHALL be a CBOR Sequence (see Appendix C.1) as defined
   below

   error

   message_3 = (
     ERR_CODE : int,
     ERR_INFO
     CIPHERTEXT_3 : any bstr,
   )

                       Figure 5: EDHOC Error

5.4.2.  Initiator Processing of Message

   where:

   o  ERR_CODE - error code encoded 3

   The Initiator SHALL compose message_3 as an integer. follows:

   *  Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H()
      is the hash function in the selected cipher suite.  The value 0 transcript
      hash TH_3 is used
      for success, all other values (negative or positive) indicate
      errors.

   o  ERR_INFO - error information.  Content a CBOR encoded bstr and encoding depend on
      error code.

   The remainder of this section specifies the currently defined error
   codes, see Figure 6.  Error codes 1 and 2 MUST be supported.
   Additional error codes and corresponding error information may be
   specified.

   +----------+---------------+----------------------------------------+
   | ERR_CODE | ERR_INFO Type | Description                            |
   +==========+===============+========================================+
   |        0 | any           | Success                                |
   +----------+---------------+----------------------------------------+
   |        1 | tstr          | Unspecified                            |
   +----------+---------------+----------------------------------------+
   |        2 | SUITES_R      | Wrong selected cipher suite            |
   +----------+---------------+----------------------------------------+

                Figure 6: Error Codes and Error Information

6.1.  Success

   Error code 0 MAY be used internally in an application input to indicate
   success, e.g. in log files.  ERR_INFO can contain any type of CBOR
   item.  Error code 0 MUST NOT be used as part of the EDHOC message
   exchange flow.

6.2.  Unspecified

   Error code 1 hash
      function is used for errors that do not have a specific error
   code defined.  ERR_INFO MUST be a text string containing a human-
   readable diagnostic message written in English.  The diagnostic text
   message is mainly intended for software engineers CBOR Sequence.  Note that during
   debugging need to interpret it H(TH_2, CIPHERTEXT_2) can
      be computed and cached already in the context processing of message_2.

   *  Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", ( ID_CRED_I,
      CRED_I, ? EAD_3 ), mac_length ).  If the EDHOC
   specification.  The diagnostic message SHOULD be provided to the
   calling application where it SHOULD be logged.

6.3.  Wrong Selected Cipher Suite

   Error code 2 MUST only be used in Initiator authenticates
      with a response to message_1 in case static Diffie-Hellman key (method equals 2 or 3), then
      mac_length is the
   cipher suite selected EDHOC MAC length given by the cipher suite.  If
      the Initiator is not supported by the
   Responder, authenticates with a signature key (method equals 0
      or if 1), then mac_length is equal to the Responder supports a cipher suite more preferred
   by output size of the Initiator than EDHOC
      hash algorithm given by the selected cipher suite, suite.

      -  ID_CRED_I - identifier to facilitate retrieval of CRED_I, see
         Section 5.2.3.
   ERR_INFO is 3.5.4

      -  CRED_I - CBOR item containing the credential of type SUITES_R:

   SUITES_R : [ supported : 2* suite ] / suite

   If the Responder does not support Initiator,
         see Section 3.5.4

      -  EAD_3 = protected external authorization data, see Section 3.8

   *  If the selected cipher suite, then
   SUITES_R MUST include one Initiator authenticates with a static Diffie-Hellman key
      (method equals 2 or more supported cipher suites. 3), then Signature_or_MAC_3 is MAC_3.  If the
   Responder does not support
      Initiator authenticates with a signature key (method equals 0 or
      1), then Signature_or_MAC_3 is the selected cipher suite, but supports
   another cipher suite 'signature' of a COSE_Sign1
      object as defined in SUITES_I, then SUITES_R MUST include Section 4.4 of
      [I-D.ietf-cose-rfc8152bis-struct] using the
   first supported cipher suite signature algorithm in SUITES_I.

6.3.1.  Cipher Suite Negotiation

   After receiving SUITES_R,
      the Initiator can determine which selected cipher
   suite to select for suite, the next EDHOC run with private authentication key of the Responder.

   If
      Initiator, and the Initiator intends following parameters:

      -  protected = << ID_CRED_I >>

      -  external_aad = << TH_3, CRED_I, ? EAD_3 >>
      -  payload = MAC_3

      COSE constructs the input to contact the Responder in Signature Algorithm as:

      -  The key is the future, private authentication key of the
   Initiator SHOULD remember which selected cipher suite Initiator.

      -  The message M to use until
   the next message_1 has been sent, otherwise the Initiator and
   Responder will likely run into be signed =

         [ "Signature1", << ID_CRED_I >>, << TH_3, CRED_I, ? EAD_3 >>,
         MAC_3 ]

   *  Compute an infinite loop.  After a successful
   run outer COSE_Encrypt0 as defined in Section 5.3 of EDHOC,
      [I-D.ietf-cose-rfc8152bis-struct], with the Initiator MAY remember EDHOC AEAD algorithm
      in the selected cipher suite to
   use in future EDHOC runs. suite, K_3ae, IV_3ae, and the following
      parameters.  The protected header SHALL be empty.

      -  external_aad = TH_3

      -  plaintext = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ?
         EAD_3 )

         o  Note that if ID_CRED_I contains a single 'kid' parameter,
            i.e., ID_CRED_I = { 4 : kid_I }, only the Initiator byte string or Responder
            integer kid_I is
   updated with new cipher suite policies, any cached information may be
   outdated.

6.3.2.  Examples

   Assume that conveyed in the Initiator supports plaintext encoded as a bstr
            or int.

      COSE constructs the five cipher suites 5, 6, 7, 8,
   and 9 in decreasing order of preference.  Figures 7 and 8 show
   examples of how input to the Initiator can truncate SUITES_I and how SUITES_R AEAD [RFC5116] as follows:

      -  Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length )

      -  Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length )

      -  Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ?
         EAD_3 )

      -  Associated data A = [ "Encrypt0", h'', TH_3 ]

      CIPHERTEXT_3 is used by Responders to give the Initiator information about 'ciphertext' of the
   cipher suites that outer COSE_Encrypt0.

   *  Encode message_3 as a sequence of CBOR encoded data items as
      specified in Section 5.4.1.

   Pass the Responder supports.

   In the first example (Figure 7), connection identifiers (C_I, C_R) and the Responder supports cipher suite
   6 but not application
   algorithms in the initially selected cipher suite 5.

   Initiator                                                   Responder
   |              METHOD, SUITES_I = 5, G_X, C_I, EAD_1                |
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |                                                                   |
   |                      DIAG_MSG, SUITES_R = 6                       |
   |<------------------------------------------------------------------+
   |                               error                               |
   |                                                                   |
   |           METHOD, SUITES_I = [6, 5, 6], G_X, C_I, EAD_1           |
   +------------------------------------------------------------------>|
   |                             message_1                             |

    Figure 7: Example of Responder supporting suite 6 but not suite 5.

   In the second example (Figure 8), the Responder supports cipher
   suites 8 and 9 but not the more preferred (by to the Initiator) cipher
   suites 5, 6 or 7.  To illustrate application.  The
   application can now derive application keys using the negotiation mechanics we let EDHOC-Exporter
   interface, see Section 4.3.

   After sending message_3, the Initiator first make a guess is assured that no other party
   than the Responder supports suite 6 but
   not suite 5.  Since can compute the Responder supports neither 5 nor 6, it
   responds with an error key PRK_4x3m (implicit key
   authentication).  The Initiator can securely derive application keys
   and SUITES_R, after which send protected application data.  However, the Initiator
   selects its most preferred supported suite.  The order of cipher
   suites in SUITES_R does not matter.  (If
   know that the Responder had supported
   suite 5, it would include it in SUITES_R of has actually computed the response, key PRK_4x3m and it
   would in that case have become
   therefore the selected suite in Initiator SHOULD NOT permanently store the keying
   material PRK_4x3m and TH_4, or derived application keys, until the second
   message_1.)
   Initiator is assured that the Responder
   |          METHOD, SUITES_I = [6, 5, 6], G_X, C_I, EAD_1            |
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |                                                                   |
   |                     DIAG_MSG, SUITES_R = [9, 8]                   |
   |<------------------------------------------------------------------+
   |                               error                               |
   |                                                                   |
   |         METHOD, SUITES_I = [8, 5, 6, 7, 8], G_X, C_I, EAD_1       |
   +------------------------------------------------------------------>|
   |                             message_1                             |

   Figure 8: Example has actually computed the key
   PRK_4x3m (explicit key confirmation).  This is similar to waiting for
   acknowledgement (ACK) in a transport protocol.  Explicit key
   confirmation is e.g., assured when the Initiator has verified an
   OSCORE message or message_4 from the Responder.

5.4.3.  Responder Processing of Message 3

   The Responder supporting suites 8 SHALL process message_3 as follows:

   *  Decode message_3 (see Appendix C.1).

   *  Retrieve the protocol state using the message correlation provided
      by the transport (e.g., the CoAP Token and 9 but not 5, 6 the 5-tuple as a
      client, or 7.

   Note that the Initiator's list of supported cipher suites and order
   of preference is fixed (see Section 5.2.1 prepended C_R as a server).

   *  Decrypt and verify the outer COSE_Encrypt0 as defined in
      Section 5.2.2).
   Furthermore, 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the Responder shall only accept message_1 if EDHOC
      AEAD algorithm in the selected cipher suite is suite, K_3ae, and IV_3ae.

   *  Pass EAD_3 to the first cipher suite in SUITES_I security application.

   *  Verify that the
   Responder supports (see Section 5.2.3).  Following identity of the Initiator is an allowed identity
      for this procedure
   ensures that connection, see Section 3.5.

   *  Verify Signature_or_MAC_3 using the algorithm in the selected
      cipher suite is suite.  The verification process depends on the most preferred (by method, see
      Section 5.4.2.

   *  Pass the
   Initiator) connection identifiers (C_I, C_R), and the application
      algorithms in the selected cipher suite supported by both parties.

   If to the selected cipher suite is not security
      application.  The application can now derive application keys
      using the first cipher suite which EDHOC-Exporter interface.

   If any processing step fails, the Responder supports in SUITES_I received SHOULD send an EDHOC
   error message back, formatted as defined in message_1, then Responder
   MUST discontinue the protocol, Section 6.  Sending error
   messages is essential for debugging but MAY e.g., be skipped if a
   session cannot be found or due to denial-of-service reasons, see
   Section 5.2.3. 7.  If SUITES_I in
   message_1 an error message is manipulated then sent, the integrity verification of message_2
   containing session MUST be
   discontinued.

   After verifying message_3, the transcript hash TH_2 will fail and Responder is assured that the
   Initiator will
   discontinue has calculated the protocol.

7.  Security Considerations

7.1.  Security Properties

   EDHOC inherits its security properties from key PRK_4x3m (explicit key confirmation)
   and that no other party than the theoretical SIGMA-I
   protocol [SIGMA].  Using Responder can compute the terminology from [SIGMA], EDHOC provides
   perfect forward secrecy, mutual authentication with aliveness,
   consistency, key.  The
   Responder can securely send protected application data and peer awareness.  As described in [SIGMA], peer
   awareness store the
   keying material PRK_4x3m and TH_4.

5.5.  EDHOC Message 4

   This section specifies message_4 which is provided OPTIONAL to support.  Key
   confirmation is normally provided by sending an application message
   from the Responder, but not Responder to the Initiator.

   EDHOC protects the credential identifier of the Initiator against
   active attacks and protected with a key derived with
   the credential identifier of EDHOC-Exporter, e.g., using OSCORE (see Appendix A).  In
   deployments where no protected application message is sent from the
   Responder against
   passive attacks.  The roles should be assigned to protect the most
   sensitive identity/identifier, typically that which is not possible
   to infer from routing information in Initiator, the lower layers.

   Compared to [SIGMA], Responder MUST send message_4.  Two
   examples of such deployments:

   1.  When EDHOC adds an explicit method type is only used for authentication and expands no application
       data is sent.

   2.  When application data is only sent from the message authentication coverage Initiator to additional elements such the
       Responder.

   Further considerations are provided in Section 3.9.

5.5.1.  Formatting of Message 4

   message_4 SHALL be a CBOR Sequence (see Appendix C.1) as
   algorithms, external authorization data, and previous messages.  This
   protects against an attacker replaying messages or injecting messages
   from another session.

   EDHOC also adds selection defined
   below

   message_4 = (
     CIPHERTEXT_4 : bstr,
   )

5.5.2.  Responder Processing of connection identifiers and downgrade
   protected negotiation Message 4

   The Responder SHALL compose message_4 as follows:

   *  Compute a COSE_Encrypt0 as defined in Section 5.3 of cryptographic parameters, i.e. an attacker
   cannot affect
      [I-D.ietf-cose-rfc8152bis-struct], with the negotiated parameters.  A single session of EDHOC
   does not include negotiation of cipher suites, but it enables the
   Responder to verify that AEAD algorithm
      in the selected cipher suite is the most
   preferred cipher suite by the Initiator which is supported by both
   the Initiator suite, and the Responder.

   As required by [RFC7258], IETF protocols need to mitigate pervasive
   monitoring when possible.  One way to mitigate pervasive monitoring following parameters.  The
      protected header SHALL be empty.

      -  protected = h''

      -  external_aad = TH_4

      -  plaintext = ( ? EAD_4 )
      where EAD_4 is protected external authorization data, see
      Section 3.8.  COSE constructs the input to use a key exchange that provides perfect forward secrecy.
   EDHOC therefore only supports methods with perfect forward secrecy.
   To limit the effect of breaches, it AEAD [RFC5116] as
      follows:

      -  Key K = EDHOC-Exporter( "EDHOC_message_4_Key", , length )

      -  Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", , length )

      -  Plaintext P = ( ? EAD_4 )

      -  Associated data A = [ "Encrypt0", h'', TH_4 ]

      CIPHERTEXT_4 is important to limit the use ciphertext of
   symmetrical group keys for bootstrapping.  EDHOC therefore strives to
   make the additional cost of using raw public keys and self-signed
   certificates as small COSE_Encrypt0.

   *  Encode message_4 as possible.  Raw public keys and self-signed
   certificates are not a replacement for a public key infrastructure,
   but SHOULD be used instead sequence of symmetrical group keys for
   bootstrapping.

   Compromise CBOR encoded data items as
      specified in Section 5.5.1.

5.5.3.  Initiator Processing of Message 4

   The Initiator SHALL process message_4 as follows:

   *  Decode message_4 (see Appendix C.1).

   *  Retrieve the long-term keys (private signature protocol state using the message correlation provided
      by the transport (e.g., the CoAP Token and the 5-tuple as a
      client, or static DH
   keys) does not compromise the security of completed EDHOC exchanges.
   Compromising prepended C_I as a server).

   *  Decrypt and verify the private authentication keys of one party lets an
   active attacker impersonate that compromised party outer COSE_Encrypt0 as defined in EDHOC exchanges
      Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with other parties, but does not let the attacker impersonate other
   parties in EDHOC exchanges with
      AEAD algorithm in the compromised party.  Compromise of selected cipher suite, and the long-term keys does not enable a passive attacker parameters
      defined in Section 5.5.2.

   *  Pass EAD_4 to compromise
   future session keys.  Compromise of the HDKF input parameters (ECDH
   shared secret) leads to compromise of all session keys derived from
   that compromised shared secret.  Compromise of one session key does
   not compromise other security application.

   If any processing step fails, the Responder SHOULD send an EDHOC
   error message back, formatted as defined in Section 6.  Sending error
   messages is essential for debugging but MAY e.g., be skipped if a
   session keys.  Compromise of PRK_4x3m leads cannot be found or due to
   compromise of all exported keying material derived after denial-of-service reasons, see
   Section 7.  If an error message is sent, the last
   invocation of session MUST be
   discontinued.

6.  Error Handling

   This section defines the EDHOC-KeyUpdate function. format for error messages.

   An EDHOC provides a minimum of 64-bit security against online brute
   force attacks and error message can be sent by either endpoint as a minimum of 128-bit security against offline brute
   force attacks.  This is in line with IPsec, TLS, and COSE.  To break
   64-bit security against online brute force an attacker would reply to
   any non-error EDHOC message.  How errors at the EDHOC layer are
   transported depends on
   average have lower layers, which need to send 4.3 billion enable error
   messages per second for 68 years,
   which is infeasible to be sent and processed as intended.

   Errors in constrained IoT radio technologies. EDHOC are fatal.  After sending message_3, the Initiator is assured that no other party
   than an error message, the Responder can compute
   sender MUST discontinue the key PRK_4x3m (implicit key
   authentication). protocol.  The Initiator does however not know receiver SHOULD treat an
   error message as an indication that the
   Responder other party likely has actually computed the key PRK_4x3m.  While the
   Initiator can securely send protected application data, the Initiator
   SHOULD NOT permanently store the keying material PRK_4x3m and TH_4
   until the Initiator is assured that the Responder has actually
   computed
   discontinued the key PRK_4x3m (explicit key confirmation).  Explicit key
   confirmation is e.g. assured when protocol.  But as the Initiator has verified an
   OSCORE error message or message_4 from the Responder.  After verifying
   message_3, the Responder is assured that the Initiator has calculated
   the key PRK_4x3m (explicit key confirmation) and that no other party
   than the Responder can compute the key.  The Responder can securely
   send protected application data and store the keying material
   PRK_4x3m and TH_4.

   Key compromise impersonation (KCI): In EDHOC authenticated with
   signature keys, EDHOC provides KCI protection against not
   authenticated, a received error message might also have been sent by
   an attacker
   having access to the long term key or and the ephemeral secret key.  With
   static Diffie-Hellman key authentication, KCI protection would be
   provided against an attacker having access receiver MAY therefore try to continue the long-term Diffie-
   Hellman key, but not to
   protocol.

   error SHALL be a CBOR Sequence (see Appendix C.1) as defined below

   error = (
     ERR_CODE : int,
     ERR_INFO : any,
   )

                       Figure 5: EDHOC Error Message

   where:

   *  ERR_CODE - error code encoded as an attacker having access to the ephemeral
   secret key.  Note that the term KCI has typically been integer.  The value 0 is used
      for
   compromise of long-term keys, success, all other values (negative or positive) indicate
      errors.

   *  ERR_INFO - error information.  Content and that an attacker with access to the
   ephemeral secret key can only attack that specific protocol run.

   Repudiation: In EDHOC authenticated with signature keys, the
   Initiator could theoretically prove that the Responder performed a
   run of the protocol by presenting the private ephemeral key, and vice
   versa.  Note that storing the private ephemeral keys violates the
   protocol requirements.  With static Diffie-Hellman key
   authentication, both parties can always deny having participated in
   the protocol.

   Two earlier versions of EDHOC have been formally analyzed [Norrman20]
   [Bruni18] and the specification has been updated based encoding depend on the
   analysis.

7.2.  Cryptographic Considerations
      error code.

   The security remainder of this section specifies the SIGMA protocol requires the MAC to currently defined error
   codes, see Figure 6.  Error codes 1 and 2 MUST be bound supported.
   Additional error codes and corresponding error information may be
   specified.

   +----------+---------------+----------------------------------------+
   | ERR_CODE | ERR_INFO Type | Description                            |
   +==========+===============+========================================+
   |        0 | any           | Success                                |
   +----------+---------------+----------------------------------------+
   |        1 | tstr          | Unspecified                            |
   +----------+---------------+----------------------------------------+
   |        2 | SUITES_R      | Wrong selected cipher suite            |
   +----------+---------------+----------------------------------------+

                Figure 6: Error Codes and Error Information

6.1.  Success

   Error code 0 MAY be used internally in an application to
   the identity indicate
   success, e.g., in log files.  ERR_INFO can contain any type of the signer.  Hence the message authenticating
   functionality CBOR
   item.  Error code 0 MUST NOT be used as part of the authenticated encryption in EDHOC message
   exchange flow.

6.2.  Unspecified

   Error code 1 is critical:
   authenticated encryption used for errors that do not have a specific error
   code defined.  ERR_INFO MUST NOT be replaced by plain encryption
   only, even if authentication is provided at another level or through a different mechanism.  EDHOC implements SIGMA-I using text string containing a MAC-then-
   Sign approach.

   To reduce human-
   readable diagnostic message written in English.  The diagnostic text
   message overhead EDHOC does not use explicit nonces and
   instead rely on the ephemeral public keys to provide randomness to
   each session.  A good amount of randomness is important mainly intended for the key
   generation, to provide liveness, and software engineers that during
   debugging need to protect against interleaving
   attacks.  For this reason, interpret it in the ephemeral keys MUST NOT be reused, and
   both parties SHALL generate fresh random ephemeral key pairs.

   As discussed context of the [SIGMA], EDHOC
   specification.  The diagnostic message SHOULD be provided to the encryption of message_2 does
   calling application where it SHOULD be logged.

6.3.  Wrong Selected Cipher Suite

   Error code 2 MUST only need be used in a response to protect against passive attacker as active attackers can always
   get message_1 in case the Responders identity
   cipher suite selected by sending their own message_1.  EDHOC
   uses the Expand function (typically HKDF-Expand) as a binary additive
   stream cipher.  HKDF-Expand provides better confidentiality than AES-
   CTR but Initiator is not often used as it is slow on long messages, and most
   applications require both IND-CCA confidentiality as well as
   integrity protection.  For supported by the encryption of message_2, any speed
   difference
   Responder, or if the Responder supports a cipher suite more preferred
   by the Initiator than the selected cipher suite, see Section 5.2.3.
   ERR_INFO is negligible, IND-CCA of type SUITES_R:

   SUITES_R : [ supported : 2* suite ] / suite

   If the Responder does not increase security, and
   integrity is provided by support the inner MAC (and signature depending on
   method).

   The data rates selected cipher suite, then
   SUITES_R MUST include one or more supported cipher suites.  If the
   Responder does not support the selected cipher suite, but supports
   another cipher suite in many IoT deployments are very limited.  Given that SUITES_I, then SUITES_R MUST include the application keys are protected as well as
   first supported cipher suite in SUITES_I.

6.3.1.  Cipher Suite Negotiation

   After receiving SUITES_R, the long-term
   authentication keys they Initiator can often be used determine which cipher
   suite to select for years or even decades
   before the cryptographic limits are reached. next EDHOC run with the Responder.

   If the application keys
   established through EDHOC need Initiator intends to be renewed, contact the communicating
   parties can derive application keys with other labels or run EDHOC
   again.

   Requirement for how Responder in the future, the
   Initiator SHOULD remember which selected cipher suite to securely generate, validate, and process use until
   the
   ephermeral public keys depend on next message_1 has been sent, otherwise the elliptic curve.  For X25519 Initiator and
   X448,
   Responder will likely run into an infinite loop.  After a successful
   run of EDHOC, the requirements are defined Initiator MAY remember the selected cipher suite to
   use in [RFC7748].  For secp256r1,
   secp384r1, and secp521r1, future EDHOC runs.  Note that if the requirements are defined Initiator or Responder is
   updated with new cipher suite policies, any cached information may be
   outdated.

6.3.2.  Examples

   Assume that the Initiator supports the five cipher suites 5, 6, 7, 8,
   and 9 in Section 5 decreasing order of [SP-800-56A].  For secp256r1, secp384r1, preference.  Figures 7 and secp521r1, at least
   partial public-key validation MUST be done.

7.3.  Cipher Suites 8 show
   examples of how the Initiator can truncate SUITES_I and Cryptographic Algorithms

   For many constrained IoT devices it how SUITES_R
   is problematic used by Responders to support more
   than one give the Initiator information about the
   cipher suite.  Existing devices can be expected to support
   either ECDSA or EdDSA.  To enable as much interoperability as we can
   reasonably achieve, less constrained devices SHOULD implement both suites that the Responder supports.

   In the first example (Figure 7), the Responder supports cipher suite 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, AES-CCM-
   16-64-128, SHA-256) and
   6 but not the initially selected cipher suite 2 (AES-CCM-16-64-128, SHA-256,
   P-256, ES256, AES-CCM-16-64-128, SHA-256).  Constrained endpoints
   SHOULD implement cipher 5.

   Initiator                                                   Responder
   |              METHOD, SUITES_I = 5, G_X, C_I, EAD_1                |
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |                                                                   |
   |                      DIAG_MSG, SUITES_R = 6                       |
   |<------------------------------------------------------------------+
   |                               error                               |
   |                                                                   |
   |           METHOD, SUITES_I = [6, 5, 6], G_X, C_I, EAD_1           |
   +------------------------------------------------------------------>|
   |                             message_1                             |

     Figure 7: Example of Responder supporting suite 0 or cipher 6 but not suite 2.  Implementations
   only need to implement 5.

   In the algorithms needed for their supported
   methods.

   When using private second example (Figure 8), the Responder supports cipher suite or registering new
   suites 8 and 9 but not the more preferred (by the Initiator) cipher suites,
   suites 5, 6 or 7.  To illustrate the
   choice of key length used in negotiation mechanics we let the different algorithms needs to be
   harmonized, so that
   Initiator first make a sufficient security level is maintained for
   certificates, EDHOC, and guess that the protection of application data.  The
   Initiator and Responder supports suite 6 but
   not suite 5.  Since the Responder should enforce a minimum security level.

   The hash algorithms SHA-1 and SHA-256/64 (256-bit Hash truncated to
   64-bits) SHALL NOT be supported for use in EDHOC except for
   certificate identification with x5u and c5u.  Note that secp256k1 is
   only defined for use supports neither 5 nor 6, it
   responds with ECDSA an error and not for ECDH.

7.4.  Unprotected Data

   The SUITES_R, after which the Initiator and
   selects its most preferred supported suite.  The order of cipher
   suites in SUITES_R does not matter.  (If the Responder 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, had supported
   suite 5, it applies to EAD_1, ID_CRED_R, EAD_2, would include it in SUITES_R of the response, and error
   messages.  Using it
   would in that case have become the same EAD_1 selected suite in several EDHOC sessions allows
   passive eavesdroppers to correlate the different sessions.  Another
   consideration is second
   message_1.)
   Initiator                                                   Responder
   |          METHOD, SUITES_I = [6, 5, 6], G_X, C_I, EAD_1            |
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |                                                                   |
   |                     DIAG_MSG, SUITES_R = [9, 8]                   |
   |<------------------------------------------------------------------+
   |                               error                               |
   |                                                                   |
   |         METHOD, SUITES_I = [8, 5, 6, 7, 8], G_X, C_I, EAD_1       |
   +------------------------------------------------------------------>|
   |                             message_1                             |

      Figure 8: Example of Responder supporting suites 8 and 9 but not
                                 5, 6 or 7.

   Note that the Initiator's list of supported cipher suites may
   potentially be used to identify the application.

   The Initiator and order
   of preference is fixed (see Section 5.2.1 and Section 5.2.2).
   Furthermore, the Responder must also make sure shall only accept message_1 if the
   selected cipher suite is the first cipher suite in SUITES_I that
   unauthenticated data does not trigger any harmful actions.  In
   particular, the
   Responder supports (see Section 5.2.3).  Following this applies to EAD_1 and error messages.

7.5.  Denial-of-Service

   EDHOC itself does procedure
   ensures that the selected cipher suite is the most preferred (by the
   Initiator) cipher suite supported by both parties.

   If the selected cipher suite is not provide countermeasures against Denial-of-
   Service attacks.  By sending a number of new or replayed message_1 an
   attacker may cause the Responder to allocate state, perform
   cryptographic operations, and amplify messages.  To mitigate such
   attacks, an implementation SHOULD rely on lower layer mechanisms such
   as first cipher suite which the Echo option
   Responder supports in CoAP [I-D.ietf-core-echo-request-tag] that
   forces SUITES_I received in message_1, then Responder
   MUST discontinue the initiator to demonstrate reachability at its apparent
   network address.

   An attacker can also send faked message_2, message_3, message_4, or
   error protocol, see Section 5.2.3.  If SUITES_I in an attempt to trick
   message_1 is manipulated, then the receiving party to send an error
   message integrity verification of
   message_2 containing the transcript hash TH_2 will fail and the
   Initiator will discontinue the session. protocol.

7.  Security Considerations

7.1.  Security Properties

   EDHOC implementations MAY
   evaluate if a received message is likely to have be forged by and
   attacker and ignore it without sending an error message or
   discontinuing inherits its security properties from the session.

7.6.  Implementation Considerations

   The availability of a secure random number generator is essential for theoretical SIGMA-I
   protocol [SIGMA].  Using the security of EDHOC.  If no true random number generator is
   available, a truly random seed MUST be provided terminology from an external
   source and used [SIGMA], EDHOC provides
   forward secrecy, mutual authentication with a cryptographically secure pseudorandom number
   generator. aliveness, consistency,
   and peer awareness.  As each pseudorandom number must only be used once, an
   implementation need to get a new truly random seed after reboot, or
   continuously store state described in nonvolatile memory, see ([RFC8613],
   Appendix B.1.1) for issues and solution approaches for writing [SIGMA], peer awareness is
   provided to
   nonvolatile memory.  Intentionally or unintentionally weak or
   predictable pseudorandom number generators can be abused or exploited
   for malicious purposes.  [RFC8937] describes a way for security
   protocol implementations the Responder, but not to augment their (pseudo)random number
   generators using a long-term private keys the Initiator.

   EDHOC protects the credential identifier of the Initiator against
   active attacks and a deterministic
   signature function.  This improves randomness from broken or
   otherwise subverted random number generators. the credential identifier of the Responder against
   passive attacks.  The same idea can roles should be
   used with other secrets assigned to protect the most
   sensitive identity/identifier, typically that which is not possible
   to infer from routing information in the lower layers.

   Compared to [SIGMA], EDHOC adds an explicit method type and functions expands
   the message authentication coverage to additional elements such as a Diffie-Hellman
   function or a symmetric secret
   algorithms, external authorization data, and a PRF like HMAC previous messages.  This
   protects against an attacker replaying messages or KMAC.  It is
   RECOMMENDED to not trust a single source injecting messages
   from another session.

   EDHOC also adds selection of randomness connection identifiers and to not put
   unaugmented random numbers on downgrade
   protected negotiation of cryptographic parameters, i.e., an attacker
   cannot affect the wire.

   If ECDSA is supported, "deterministic ECDSA" as specified in
   [RFC6979] MAY be used.  Pure deterministic elliptic-curve signatures
   such as deterministic ECDSA and EdDSA have gained popularity over
   randomized ECDSA as their security do not depend on a source negotiated parameters.  A single session of high-
   quality randomness.  Recent research has however found that
   implementations EDHOC
   does not include negotiation of these signature algorithms may be vulnerable cipher suites, but it enables the
   Responder to
   certain side-channel verify that the selected cipher suite is the most
   preferred cipher suite by the Initiator which is supported by both
   the Initiator and fault injection attacks due to their
   determinism.  See e.g.  Section 1 of
   [I-D.mattsson-cfrg-det-sigs-with-noise] for a list of attack papers. the Responder.

   As suggested in Section 6.1.2 of [I-D.ietf-cose-rfc8152bis-algs] this
   can be addressed required by combining randomness and determinism.

   All private keys, symmetric keys, and IVs MUST be secret.
   Implementations should provide countermeasures [RFC7258], IETF protocols need to side-channel
   attacks such as timing attacks.  Intermediate computed values such as mitigate pervasive
   monitoring when possible.  EDHOC therefore only supports methods with
   ephemeral ECDH keys and ECDH shared secrets MUST be deleted after key
   derivation is completed.

   The Initiator Diffie-Hellman and the Responder are responsible provides a KeyUpdate function for verifying
   lightweight application protocol rekeying with forward secrecy, in
   the
   integrity of certificates.  The selection sense that compromise of trusted CAs should be
   done very carefully and certificate revocation should be supported.
   The the private authentication keys MUST be kept secret.

   The Initiator does not
   compromise past session keys, and compromise of a session key does
   not compromise past session keys.

   While the Responder are allowed KeyUpdate method can be used to select the connection
   identifiers C_I meet cryptographic limits
   and C_R, respectively, for the other party to use in
   the ongoing provide partial protection against key leakage, it provides
   significantly weaker security properties than re-running EDHOC protocol as well as in a subsequent application
   protocol (e.g.  OSCORE [RFC8613]).  The choice with
   ephemeral Diffie-Hellman.  Even with frequent use of connection
   identifier is not security critical in KeyUpdate,
   compromise of one session key compromises all future session keys,
   and an attacker therefore only needs to perform static key
   exfiltration [RFC7624].  Frequently re-running EDHOC but intended with ephemeral
   Diffie-Hellman forces attackers to simplify
   the retrieval perform dynamic key exfiltration
   instead of static key exfiltration [RFC7624].  In the right security context in combination with using
   short identifiers.  If dynamic case,
   the wrong connection identifier of attacker must have continuous interactions with the other
   party collaborator,
   which is used in more complicated and has a protocol message higher risk profile than the
   static case.

   To limit the effect of breaches, it will result in is important to limit the receiving
   party not being able use of
   symmetrical group keys for bootstrapping.  EDHOC therefore strives to retrieve
   make the additional cost of using raw public keys and self-signed
   certificates as small as possible.  Raw public keys and self-signed
   certificates are not a security context (which will
   terminate replacement for a public key infrastructure
   but SHOULD be used instead of symmetrical group keys for
   bootstrapping.

   Compromise of the protocol) long-term keys (private signature or retrieve static DH
   keys) does not compromise the wrong security context (which
   also terminates the protocol as of completed EDHOC exchanges.
   Compromising the message cannot be verified).

   If two nodes unintentionally initiate two simultaneous private authentication keys of one party lets an
   active attacker impersonate that compromised party in EDHOC message exchanges
   with each other even if they only want to complete a single
   EDHOC message exchange, they MAY terminate parties but does not let the exchange attacker impersonate other
   parties in EDHOC exchanges with the
   lexicographically smallest G_X.  If compromised party.  Compromise of
   the two G_X values are equal, long-term keys does not enable a passive attacker to compromise
   future session keys.  Compromise of the
   received message_1 MUST be discarded HDKF input parameters (ECDH
   shared secret) leads to mitigate reflection attacks.
   Note compromise of all session keys derived from
   that in the case compromised shared secret.  Compromise of two simultaneous EDHOC exchanges where the
   nodes only complete one and where the nodes have different preferred
   cipher suites, an attacker can affect which session key does
   not compromise other session keys.  Compromise of PRK_4x3m leads to
   compromise of all exported keying material derived after the two nodes'
   preferred cipher suites will be used by blocking the other exchange.

   If supported by last
   invocation of the device, it EDHOC-KeyUpdate function.

   EDHOC provides a minimum of 64-bit security against online brute
   force attacks and a minimum of 128-bit security against offline brute
   force attacks.  This is RECOMMENDED that at least the long-
   term private keys are stored in a Trusted Execution Environment (TEE) line with IPsec, TLS, and that sensitive operations using these keys are performed inside
   the TEE. COSE.  To achieve even higher break
   64-bit security it against online brute force an attacker would on
   average have to send 4.3 billion messages per second for 68 years,
   which is RECOMMENDED that infeasible in
   additional operations such as ephemeral key generation, all
   computations of shared secrets, and storage of constrained IoT radio technologies.

   After sending message_3, the pseudorandom keys
   (PRK) can be done inside Initiator is assured that no other party
   than the TEE. Responder can compute the key PRK_4x3m (implicit key
   authentication).  The use of a TEE enforces that
   code within Initiator does however not know that environment cannot be tampered with, the
   Responder has actually computed the key PRK_4x3m.  While the
   Initiator can securely send protected application data, the Initiator
   SHOULD NOT permanently store the keying material PRK_4x3m and TH_4
   until the Initiator is assured that any
   data used by such code cannot be read the Responder has actually
   computed the key PRK_4x3m (explicit key confirmation).  Explicit key
   confirmation is e.g., assured when the Initiator has verified an
   OSCORE message or tampered with by code
   outside message_4 from the Responder.  After verifying
   message_3, the Responder is assured that environment.  Note the Initiator has calculated
   the key PRK_4x3m (explicit key confirmation) and that non-EDHOC code inside no other party
   than the TEE
   might still be able to read EDHOC Responder can compute the key.  The Responder can securely
   send protected application data and tamper with store the keying material
   PRK_4x3m and TH_4.

   Key compromise impersonation (KCI): In EDHOC code, to
   protect against such attacks authenticated with
   signature keys, EDHOC needs to be in its own zone.  To
   provide better provides KCI protection against some forms of physical attacks,
   sensitive EDHOC data should be stored inside an attacker
   having access to the SoC long-term key or encrypted and
   integrity protected when sent on a data bus (e.g. between the CPU and
   RAM or Flash).  Secure boot can ephemeral secret key.  With
   static Diffie-Hellman key authentication, KCI protection would be used
   provided against an attacker having access to increase the security of
   code and data in long-term Diffie-
   Hellman key, but not to an attacker having access to the Rich Execution Environment (REE) by validating ephemeral
   secret key.  Note that the REE image.

8.  IANA Considerations

8.1.  EDHOC Exporter Label

   IANA term KCI has created a new registry titled "EDHOC Exporter Label" under
   the new heading "EDHOC".  The registration procedure is "Expert
   Review".  The columns typically been used for
   compromise of the registry are Label, Description, long-term keys, and
   Reference.  All columns are text strings.  The initial contents of
   the registry are:

   Label: EDHOC_message_4_Key
   Description: Key used to protect EDHOC message_4
   Reference: [[this document]]

   Label: EDHOC_message_4_Nonce
   Description: Nonce used that an attacker with access to protect EDHOC message_4
   Reference: [[this document]]

   Label: OSCORE Master Secret
   Description: Derived OSCORE Master Secret
   Reference: [[this document]]

   Label: OSCORE Master Salt
   Description: Derived OSCORE Master Salt
   Reference: [[this document]]

8.2. the
   ephemeral secret key can only attack that specific protocol run.

   Repudiation: In EDHOC Cipher Suites Registry

   IANA has created a new registry titled "EDHOC Cipher Suites" under authenticated with signature keys, the new heading "EDHOC".  The registration procedure is "Expert
   Review".  The columns
   Initiator could theoretically prove that the Responder performed a
   run of the registry are Value, Array, Description,
   and Reference, where Value is an integer protocol by presenting the private ephemeral key, and vice
   versa.  Note that storing the other columns are
   text strings.  The initial contents private ephemeral keys violates the
   protocol requirements.  With static Diffie-Hellman key
   authentication, both parties can always deny having participated in
   the protocol.

   Two earlier versions of EDHOC have been formally analyzed [Norrman20]
   [Bruni18] and the registry are:

   Value: -24
   Algorithms: N/A
   Desc: Reserved for Private Use
   Reference: [[this document]]

   Value: -23
   Algorithms: N/A
   Desc: Reserved for Private Use
   Reference: [[this document]]

   Value: -22
   Algorithms: N/A
   Desc: Reserved for Private Use
   Reference: [[this document]]

   Value: -21
   Algorithms: N/A
   Desc: Reserved for Private Use
   Reference: [[this document]]
   Value: 0
   Array: 10, -16, 4, -8, 10, -16
   Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA,
         AES-CCM-16-64-128, SHA-256
   Reference: [[this document]]

   Value: 1
   Array: 30, -16, 4, -8, 10, -16
   Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA,
         AES-CCM-16-64-128, SHA-256
   Reference: [[this document]]

   Value: 2
   Array: 10, -16, 1, -7, 10, -16
   Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256,
         AES-CCM-16-64-128, SHA-256
   Reference: [[this document]]

   Value: 3
   Array: 30, -16, 1, -7, 10, -16
   Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256,
         AES-CCM-16-64-128, SHA-256
   Reference: [[this document]]

   Value: 4
   Array: 24, -16, 4, -8, 24, -16
   Desc: ChaCha20/Poly1305, SHA-256, X25519, EdDSA,
         ChaCha20/Poly1305, SHA-256
   Reference: [[this document]]

   Value: 5
   Array: 24, -16, 1, -7, 24, -16
   Desc: ChaCha20/Poly1305, SHA-256, P-256, ES256,
         ChaCha20/Poly1305, SHA-256
   Reference: [[this document]]

   Value: 6
   Array: 1, -16, 4, -7, 1, -16
   Desc: A128GCM, SHA-256, X25519, ES256,
         A128GCM, SHA-256
   Reference: [[this document]]

   Value: 24
   Array: 3, -43, 2, -35, 3, -43
   Desc: A256GCM, SHA-384, P-384, ES384,
         A256GCM, SHA-384
   Reference: [[this document]]
   Value: 25
   Array: 24, -45, 5, -8, 24, -45
   Desc: ChaCha20/Poly1305, SHAKE256, X448, EdDSA,
         ChaCha20/Poly1305, SHAKE256
   Reference: [[this document]]

8.3.  EDHOC Method Type Registry

   IANA has created a new registry entitled "EDHOC Method Type" under
   the new heading "EDHOC".  The registration procedure is "Expert
   Review".  The columns of the registry are Value, Description, and
   Reference, where Value is an integer and the other columns are text
   strings.  The initial contents of the registry is shown in Figure 4.

8.4.  EDHOC Error Codes Registry

   IANA has created a new registry entitled "EDHOC Error Codes" under
   the new heading "EDHOC".  The registration procedure is
   "Specification Required".  The columns of the registry are ERR_CODE,
   ERR_INFO Type and Description, where ERR_CODE is an integer, ERR_INFO
   is a CDDL defined type, and Description is a text string.  The
   initial contents of the registry is shown in Figure 6.

8.5.  COSE Header Parameters Registry

   This document registers the following entries in the "COSE Header
   Parameters" registry under the "CBOR Object Signing and Encryption
   (COSE)" heading.  The value of the 'cwt' header parameter is a CWT
   [RFC8392] or an unprotected CWT Claims Set [I-D.ietf-rats-uccs].

   +-----------+-------+----------------+------------------------------+
   | Name      | Label | Value Type     | Description                  |
   +===========+=======+================+==============================+
   | cwt       |  TBD1 | COSE_Messages  | A CBOR Web Token (CWT) or an |
   |           |       | / map          | unprotected CWT Claims Set   |
   +-----------+-------+----------------+------------------------------+

8.6.  COSE Header Parameters Registry

   IANA has added the COSE header parameter 'kid2' to the COSE Header
   Parameters registry.  The kid2 parameter may point to a COSE key
   common parameter 'kid' or 'kid2'.  The kid2 parameter can be used to
   identify a key stored in a "raw" COSE_Key, in a CWT, or in a
   certificate.  The Value Reference for this item is empty and omitted
   from the table below.

   +------+-------+------------+----------------+-------------------+
   | Name | Label | Value Type | Description    | Reference         |
   +------+-------+------------+----------------+-------------------+
   | kid2 | TBD   | bstr / int | Key identifier | [[This document]] |
   +------+-------+------------+----------------+-------------------+

8.7.  COSE Key Common Parameters Registry

   IANA has added the COSE key common parameter 'kid2' to the COSE Key
   Common Parameters registry.  The Value Reference for this item is
   empty and omitted from the table below.

   +------+-------+------------+----------------+-------------------+
   | Name | Label | Value Type | Description    | Reference         |
   +------+-------+------------+----------------+-------------------+
   | kid2 | TBD   | bstr / int | Key identifi-  | [[This document]] |
   |      |       |            | cation value - |                   |
   |      |       |            | match to kid2  |                   |
   |      |       |            | in message     |                   |
   +------+-------+------------+----------------+-------------------+

8.8.  The Well-Known URI Registry

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

   o  URI suffix: edhoc

   o  Change controller: IETF

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

   o  Related information: None

8.9.  Media Types Registry

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

   o  Type name: application

   o  Subtype name: edhoc

   o  Required parameters: N/A

   o  Optional parameters: N/A

   o  Encoding considerations: binary
   o  Security considerations: See Section 7 of this document.

   o  Interoperability considerations: N/A

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

   o  Applications that use this media type: To be identified

   o  Fragment identifier considerations: N/A

   o  Additional information:

      *  Magic number(s): N/A

      *  File extension(s): N/A

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

   o  Person & email address to contact for further information: See
      "Authors' Addresses" section.

   o  Intended usage: COMMON

   o  Restrictions on usage: N/A

   o  Author: See "Authors' Addresses" section.

   o  Change Controller: IESG

8.10.  CoAP Content-Formats Registry

   IANA has added the media type 'application/edhoc' to the CoAP
   Content-Formats registry.

   o  Media Type: application/edhoc

   o  Encoding:

   o  ID: TBD42

   o  Reference: [[this document]]

8.11.  EDHOC External Authorization Data

   IANA has created a new registry entitled "EDHOC External
   Authorization Data" under the new heading "EDHOC".  The registration
   procedure is "Expert Review".  The columns of the registry are Value,
   Description, and Reference, where Value is an integer and the other
   columns are text strings.

8.12.  Expert Review Instructions

   The IANA Registries established in this document is defined as
   "Expert Review".  This section gives some general guidelines for what
   the experts should be looking for, but they are being designated as
   experts for a reason so they should be given substantial latitude.

   Expert reviewers should take into consideration the following points:

   o  Clarity and correctness of registrations.  Experts are expected to
      check the clarity of purpose and use of the requested entries.
      Expert needs to make sure the values of algorithms are taken from
      the right registry, when that's required.  Expert should consider
      requesting an opinion on the correctness of registered parameters
      from relevant IETF working groups.  Encodings that do not meet
      these objective of clarity and completeness should not be
      registered.

   o  Experts should take into account the expected usage of fields when
      approving point assignment.  The length of the encoded value
      should be weighed against how many code points of that length are
      left, the size of device it will be used on, and the number of
      code points left that encode to that size.

   o  Specifications are recommended.  When specifications are not
      provided, the description provided needs to have sufficient
      information to verify the points above.

9.  References

9.1.  Normative References

   [I-D.ietf-core-echo-request-tag]
              Amsuess, C., Mattsson, J. P., and G. Selander, "CoAP:
              Echo, Request-Tag, and Token Processing", draft-ietf-core-
              echo-request-tag-12 (work in progress), February 2021.

   [I-D.ietf-cose-rfc8152bis-algs]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12
              (work in progress), September 2020.

   [I-D.ietf-cose-rfc8152bis-struct]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", draft-ietf-cose-rfc8152bis-
              struct-15 (work in progress), February 2021.

   [I-D.ietf-cose-x509]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Header parameters for carrying and referencing X.509
              certificates", draft-ietf-cose-x509-08 (work in progress),
              December 2020.

   [I-D.ietf-lake-reqs]
              Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia-
              Carrillo, "Requirements for a Lightweight AKE for OSCORE",
              draft-ietf-lake-reqs-04 (work in progress), June 2020.

   [I-D.ietf-rats-uccs]
              Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
              Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
              draft-ietf-rats-uccs-00 (work in progress), May 2021.

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

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

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

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

   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
              Algorithm (DSA) and Elliptic Curve Digital Signature
              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
              2013, <https://www.rfc-editor.org/info/rfc6979>.

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

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/info/rfc7959>.

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

   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
              <https://www.rfc-editor.org/info/rfc8376>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.

   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/info/rfc8742>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

9.2.  Informative References

   [Bruni18]  Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T.,
              and C. Schuermann, "Formal Verification of Ephemeral
              Diffie-Hellman Over COSE (EDHOC)", November 2018,
              <https://www.springerprofessional.de/en/formal-
              verification-of-ephemeral-diffie-hellman-over-cose-
              edhoc/16284348>.

   [CborMe]   Bormann, C., "CBOR Playground", May 2018,
              <http://cbor.me/>.

   [CNSA]     (Placeholder), ., "Commercial National Security Algorithm
              Suite", August 2015,
              <https://apps.nsa.gov/iaarchive/programs/iad-initiatives/
              cnsa-suite.cfm>.

   [I-D.ietf-core-oscore-edhoc]
              Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S.,
              and G. Selander, "Combining EDHOC and OSCORE", draft-ietf-
              core-oscore-edhoc-00 (work in progress), April 2021.

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

   [I-D.ietf-cose-cbor-encoded-cert]
              Raza, S., Hoeglund, J., Selander, G., Mattsson, J. P., and
              M. Furuhed, "CBOR Encoded X.509 Certificates (C509
              Certificates)", draft-ietf-cose-cbor-encoded-cert-00 (work
              in progress), April 2021.

   [I-D.ietf-lwig-security-protocol-comparison]
              Mattsson, J. P., Palombini, F., and M. Vucinic,
              "Comparison of CoAP Security Protocols", draft-ietf-lwig-
              security-protocol-comparison-05 (work in progress),
              November 2020.

   [I-D.ietf-tls-dtls13]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", draft-ietf-tls-dtls13-43 (work in progress), April
              2021.

   [I-D.mattsson-cfrg-det-sigs-with-noise]
              Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
              "Deterministic ECDSA and EdDSA Signatures with Additional
              Randomness", draft-mattsson-cfrg-det-sigs-with-noise-02
              (work in progress), March 2020.

   [I-D.selander-ace-ake-authz]
              Selander, G., Mattsson, J. P., Vucinic, M., Richardson,
              M., and A. Schellenbaum, "Lightweight Authorization for
              Authenticated Key Exchange.", draft-selander-ace-ake-
              authz-02 (work in progress), November 2020.

   [Norrman20]
              Norrman, K., Sundararajan, V., and A. Bruni, "Formal
              Analysis of EDHOC Key Establishment for Constrained IoT
              Devices", September 2020,
              <https://arxiv.org/abs/2007.11427>.

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

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8937]  Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
              and C. Wood, "Randomness Improvements for Security
              Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
              <https://www.rfc-editor.org/info/rfc8937>.

   [SECG]     "Standards for Efficient Cryptography 1 (SEC 1)", May
              2009, <https://www.secg.org/sec1-v2.pdf>.

   [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., Vassilev, A., and R.
              Davis, "Recommendation for Pair-Wise Key-Establishment
              Schemes Using Discrete Logarithm Cryptography",
              NIST Special Publication 800-56A Revision 3, April 2018,
              <https://doi.org/10.6028/NIST.SP.800-56Ar3>.

Appendix A.  Use with OSCORE and Transfer over CoAP

   This sppendix describes how to select EDHOC connection identifiers
   and derive an OSCORE security context when OSCORE is used with EDHOC,
   and how to transfer EDHOC messages over CoAP.

A.1.  Selecting EDHOC Connection Identifier

   This section specifies a rule for converting from EDHOC connection
   identifier to OSCORE Sender/Recipient ID.  (An identifier is Sender
   ID or Recipient ID depending on from which endpoint is the point of
   view, see Section 3.1 of [RFC8613].)

   o  If the EDHOC connection identifier is numeric, i.e. encoded as a
      CBOR integer on the wire, it is converted to a (naturally byte-
      string shaped) OSCORE Sender/Recipient ID equal to its CBOR
      encoded form.

   For example, a numeric C_R equal to 10 (0x0A in CBOR encoding) is
   converted to a (typically client) Sender ID equal to 0x0A, while a
   numeric C_I equal to -12 (0x2B in CBOR encoding) is converted to a
   (typically client) Sender ID equal to 0x2B.

   o  If the EDHOC connection identifier is byte-valued, hence encoded
      as a CBOR byte string on the wire, it is converted to an OSCORE
      Sender/Recipient ID equal to the byte string.

   For example, a byte-string valued C_R equal to 0xFF (0x41FF in CBOR
   encoding) is converted to a (typically client) Sender ID equal to
   0xFF.

   Two EDHOC connection identifiers are called "equivalent" if and only
   if, by applying the conversion above, they both result in the same
   OSCORE Sender/Recipient ID.  For example, the two EDHOC connection
   identifiers with CBOR encoding 0x0A (numeric) and 0x410A (byte-
   valued) are equivalent since they both result in the same OSCORE
   Sender/Recipient ID 0x0A.

   When EDHOC is used to establish an OSCORE security context, the
   connection identifiers C_I and C_R MUST NOT be equivalent.
   Furthermore, in case of multiple OSCORE security contexts with
   potentially different endpoints, to facilitate retrieval of the
   correct OSCORE security context, an endpoint SHOULD select an EDHOC
   connection identifier that when converted to OSCORE Recipient ID does
   not coincide with its other Recipient IDs.

A.2.  Deriving the OSCORE Security Context

   This section specifies how to use EDHOC output to derive the OSCORE
   security context.

   After successful processing of EDHOC message_3, Client and Server
   derive Security Context parameters for OSCORE as follows (see
   Section 3.2 of [RFC8613]):

   o  The Master Secret and Master Salt are derived by using the EDHOC-
      Exporter interface, see Section 4.1.

   The EDHOC Exporter Labels for deriving the OSCORE Master Secret and
   the OSCORE Master Salt, are "OSCORE Master Secret" and "OSCORE Master
   Salt", respectively.

   The context parameter is h'' (0x40), the empty CBOR byte string.

   By default, key_length is the key length (in bytes) of the
   application AEAD Algorithm of the selected cipher suite for the EDHOC
   session.  Also by default, salt_length has value 8.  The Initiator
   and Responder MAY agree out-of-band on a longer key_length than the
   default and on a different salt_length.

Master Secret = EDHOC-Exporter( "OSCORE Master Secret", h'',  key_length )
Master Salt   = EDHOC-Exporter( "OSCORE Master Salt", h'',  salt_length )

   o  The AEAD Algorithm is the application AEAD algorithm of the
      selected cipher suite for the EDHOC session.

   o  The HKDF Algorithm is the one based on the application hash
      algorithm of the selected cipher suite for the EDHOC session.  For
      example, if SHA-256 is the application hash algorithm of the
      selected ciphersuite, HKDF SHA-256 is used as HKDF Algorithm in
      the OSCORE Security Context.

   o  In case the Client is Initiator and the Server is Responder, the
      Client's OSCORE Sender ID and the Server's OSCORE Sender ID are
      determined from the EDHOC connection identifiers C_R and C_I for
      the EDHOC session, respectively, by applying the conversion in
      Appendix A.1.  The reverse applies in case the Client is the
      Responder and the Server is the Initiator.

   Client and Server use the parameters above to establish an OSCORE
   Security Context, as per Section 3.2.1 of [RFC8613].

   From then on, Client and Server retrieve the OSCORE protocol state
   using the Recipient ID, and optionally other transport information
   such as the 5-tuple.

A.3.  Transferring EDHOC over CoAP

   This section specifies one instance for how EDHOC can be transferred
   as an exchange of CoAP [RFC7252] messages.  CoAP is a reliable
   transport that can preserve packet ordering and handle message
   duplication.  CoAP can also perform fragmentation and protect against
   denial of service attacks.  According to this specification, EDHOC
   messages are carried in Confirmable messages, which is beneficial
   especially if fragmentation is used.

   By default, the CoAP client is the Initiator and the CoAP server is
   the Responder, but the roles SHOULD be chosen to protect the most
   sensitive identity, see Section 7.  According to this specification,
   EDHOC is transferred in POST requests and 2.04 (Changed) responses to
   the Uri-Path: "/.well-known/edhoc".  An application may define its
   own path that can be discovered, e.g., using resource directory
   [I-D.ietf-core-resource-directory].

   By default, the message flow is as follows: 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.  Alternatively,
   if EDHOC message_4 is used, it is sent from the server to the client
   in the payload of a 2.04 (Changed) response analogously to message_2.

   In order to correlate a message received from a client to a message
   previously sent by the server, messages sent by the client are
   prepended with the CBOR serialization of the connection identifier
   which the server has chosen.  This applies independently of if the
   CoAP server is Responder or Initiator.  For the default case when the
   server is Responder, the prepended connection identifier is C_R, and
   C_I if the server is Initiator.  If message_1 is sent to the server,
   the CBOR simple value "null" (0xf6) is sent in its place (given that
   the server has not selected C_R yet).

   These identifiers are encoded in CBOR and thus self-delimiting.  They
   are sent in front of the actual EDHOC message, and only the part of
   the body following the identifier is used for EDHOC processing.

   Consequently, the application/edhoc media type does not apply to
   these messages; their media type is unnamed.

   An example of a successful EDHOC exchange using CoAP is shown in
   Figure 9.  In this case the CoAP Token enables correlation on the
   Initiator side, and the prepended C_R enables correlation on the
   Responder (server) side.

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

      Figure 9: Transferring EDHOC in CoAP when the Initiator is CoAP
                                  Client

   The exchange in Figure 9 protects the client identity against active
   attackers and the server identity against passive attackers.

   An alternative exchange that protects the server identity against
   active attackers and the client identity against passive attackers is
   shown in Figure 10.  In this case the CoAP Token enables the
   Responder to correlate message_2 and message_3, and the prepended C_I
   enables correlation on the Initiator (server) side.  If EDHOC
   message_4 is used, C_I is prepended, and it is transported with CoAP
   in the payload of a POST request with a 2.04 (Changed) response.

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

     Figure 10: Transferring EDHOC in CoAP when the Initiator is CoAP
                                  Server

   To protect against denial-of-service attacks, the CoAP server MAY
   respond to the first POST request with a 4.01 (Unauthorized)
   containing an Echo option [I-D.ietf-core-echo-request-tag].  This
   forces the initiator to demonstrate its reachability at its apparent
   network address.  If message fragmentation is needed, the EDHOC
   messages may be fragmented using the CoAP Block-Wise Transfer
   mechanism [RFC7959].  EDHOC does not restrict how error messages are
   transported with CoAP, as long as the appropriate error message can
   to be transported in response to a message that failed (see
   Section 6).

A.3.1.  Transferring EDHOC and OSCORE over CoAP

   A method for combining EDHOC and OSCORE protocols in two round-trips
   is specified in [I-D.ietf-core-oscore-edhoc].

   When using EDHOC over CoAP for establishing an OSCORE Security
   Context, EDHOC error messages sent as CoAP responses MUST be error
   responses, i.e., they MUST specify a CoAP error response code.  In
   particular, it is RECOMMENDED that such error responses have response
   code either 4.00 (Bad Request) in case of client error (e.g., due to
   a malformed EDHOC message), or 5.00 (Internal Server Error) in case
   of server error (e.g., due to failure in deriving EDHOC key
   material).

Appendix B.  Compact Representation

   As described in Section 4.2 of [RFC6090] the x-coordinate of an
   elliptic curve public key is a suitable representative for the entire
   point whenever scalar multiplication is used as a one-way function.
   One example is ECDH with compact output, where only the x-coordinate
   of the computed value is used as the shared secret.

   This section defines a format for compact representation based on the
   Elliptic-Curve-Point-to-Octet-String Conversion defined in
   Section 2.3.3 of [SECG].  Using the notation from [SECG], the output
   is an octet string of length ceil( (log2 q) / 8 ).  See [SECG] for a
   definition of q, M, X, xp, and ~yp.  The steps in Section 2.3.3 of
   [SECG] are replaced by:

   1.  Convert the field element xp to an octet string X of length ceil(
       (log2 q) / 8 ) octets using the conversion routine specified in
       Section 2.3.5 of [SECG].

   2.  Output M = X

   The encoding of the point at infinity is not supported.  Compact
   representation does not change any requirements on validation.  If a
   y-coordinate is required for validation or compatibily with APIs the
   value ~yp SHALL be set to zero.  For such use, the compact
   representation can be transformed into the SECG point compressed
   format by prepending it with the single byte 0x02 (i.e.  M = 0x02 ||
   X).

   Using compact representation have some security benefits.  An
   implementation does not need to check that the point is not the point
   at infinity (the identity element).  Similarly, as not even the sign
   of the y-coordinate is encoded, compact representation trivially
   avoids so called "benign malleability" attacks where an attacker
   changes the sign, see [SECG].

Appendix C.  Use of CBOR, CDDL and COSE in EDHOC

   This Appendix is intended to simplify for implementors not familiar
   with CBOR [RFC8949], CDDL [RFC8610], COSE
   [I-D.ietf-cose-rfc8152bis-struct], and HKDF [RFC5869].

C.1.  CBOR and CDDL

   The Concise Binary Object Representation (CBOR) [RFC8949] is a data
   format designed for small code size and small message size.  CBOR
   builds on the JSON data model but extends it by e.g. encoding binary
   data directly without base64 conversion.  In addition to the binary
   CBOR encoding, CBOR also has a diagnostic notation that is readable
   and editable by humans.  The Concise Data Definition Language (CDDL)
   [RFC8610] provides a way to express structures for protocol messages
   and APIs that use CBOR.  [RFC8610] also extends the diagnostic
   notation.

   CBOR data items are encoded to or decoded from byte strings using a
   type-length-value encoding scheme, where the three highest order bits
   of the initial byte contain information about the major type.  CBOR
   supports several different types of data items, in addition to
   integers (int, uint), simple values (e.g. null), byte strings (bstr),
   and text strings (tstr), CBOR also supports arrays [] of data items,
   maps {} of pairs of data items, and sequences [RFC8742] of data
   items.  Some examples are given below.  For a complete specification
   and more examples, see [RFC8949] and [RFC8610].  We recommend
   implementors to get used to CBOR by using the CBOR playground
   [CborMe].

    Diagnostic          Encoded              Type
    ------------------------------------------------------------------
    1                   0x01                 unsigned integer
    24                  0x1818               unsigned integer
    -24                 0x37                 negative integer
    -25                 0x3818               negative integer
    null                0xf6                 simple value
    h'12cd'             0x4212cd             byte string
    '12cd'              0x4431326364         byte string
    "12cd"              0x6431326364         text string
    { 4 : h'cd' }       0xa10441cd           map
    << 1, 2, null >>    0x430102f6           byte string
    [ 1, 2, null ]      0x830102f6           array
    ( 1, 2, null )      0x0102f6             sequence
    1, 2, null          0x0102f6             sequence
    ------------------------------------------------------------------

C.2.  CDDL Definitions

   This sections compiles the CDDL definitions for ease of reference.

   suite = int

   SUITES_R : [ supported : 2* suite ] / suite

   message_1 = (
     METHOD : int,
     SUITES_I : [ selected : suite, supported : 2* suite ] / suite,
     G_X : bstr,
     C_I : bstr / int,
     ? EAD ; EAD_1
   )

   message_2 = (
     data_2,
     CIPHERTEXT_2 : bstr,
   )

   data_2 = (
     G_Y : bstr,
     C_R : bstr / int,
   )

   message_3 = (
     CIPHERTEXT_3 : bstr,
   )

   message_4 = (
     CIPHERTEXT_4 : bstr,
   )

   error = (
     ERR_CODE : int,
     ERR_INFO : any
   )

   info = [
      edhoc_aead_id : int / tstr,
      transcript_hash : bstr,
      label : tstr,
      length : uint
   ]

C.3.  COSE

   CBOR Object Signing and Encryption (COSE)
   [I-D.ietf-cose-rfc8152bis-struct] describes how to create and process
   signatures, message authentication codes, and encryption using CBOR.
   COSE builds specification has been updated based on JOSE, but is adapted to allow more efficient
   processing in constrained devices.  EDHOC makes use of COSE_Key,
   COSE_Encrypt0, and COSE_Sign1 objects.

Appendix D.  Test Vectors

   NOTE 0.  These test vectors are compatible with versions -05 and -06
   of the specification.

   This appendix provides detailed test vectors to ease implementation
   and ensure interoperability.  In addition to hexadecimal, all CBOR
   data items and sequences are given in CBOR diagnostic notation.
   analysis.

7.2.  Cryptographic Considerations

   The
   test vectors use the default mapping to CoAP where the Initiator acts
   as CoAP client (this means SIGMA protocol requires that corr = 1).

   A more extensive test vector suite covering more combinations of
   authentication method used between Initiator and Responder and
   related code to generate them can be found at https://github.com/
   lake-wg/edhoc/tree/master/test-vectors-05.

   NOTE 1.  In the previous and current test vectors the same name is
   used for certain byte strings and their CBOR bstr encodings.  For
   example the transcript hash TH_2 is used to denote both the output encryption of
   the hash function message_3 provides
   confidentiality against active attackers and EDHOC message_4 relies
   on the input into use of authenticated encryption.  Hence the key derivation function,
   whereas message
   authenticating functionality of the latter 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 CBOR bstr encoding different mechanism.

   To reduce message overhead EDHOC does not use explicit nonces and
   instead rely on the ephemeral public keys to provide randomness to
   each session.  A good amount of randomness is important for the former.  Some
   attempts are made key
   generation, to clarify that in provide liveness, and to protect against interleaving
   attacks.  For this Appendix (e.g. using "CBOR
   encoded"/"CBOR unencoded").

   NOTE 2.  If not clear from reason, the context, remember that CBOR sequences
   and CBOR arrays assume CBOR encoded data items as elements.

D.1.  Test Vectors for EDHOC Authenticated with Signature Keys (x5t)

   EDHOC with signature authentication ephemeral keys MUST NOT be reused, and X.509 certificates is used.
   In this test vector,
   both parties SHALL generate fresh random ephemeral key pairs.

   As discussed, the hash value 'x5t' is used [SIGMA], the encryption of message_2 does only need
   to identify protect against passive attacker as active attackers can always
   get the
   certificate.  The optional C_1 in message_1 is omitted.  No external
   authorization data is sent in Responders identity by sending their own message_1.  EDHOC
   uses the message exchange.

   method (Signature Authentication)
   0

   CoAP Expand function (typically HKDF-Expand) as a binary additive
   stream cipher.  HKDF-Expand provides better confidentiality than AES-
   CTR but is not often used as transport and the Initiator acts as CoAP client:

   corr (the Initiator can correlate message_1 and message_2)
   1

   From there, METHOD_CORR has the following value:

   METHOD_CORR (4 * method + corr) (int)
   1

   The Initiator indicates only one cipher suite in it is slow on long messages, and most
   applications require both IND-CCA confidentiality as well as
   integrity protection.  For the (potentially
   truncated) list encryption of cipher suites.

   Supported Cipher Suites (1 byte)
   00

   The Initiator selected the indicated cipher suite.

   Selected Cipher Suite (int)
   0

   Cipher suite 0 message_2, any speed
   difference is supported negligible, IND-CCA does not increase security, and
   integrity is provided by both the Initiator inner MAC (and signature depending on
   method).

   Requirement for how to securely generate, validate, and process the Responder,
   see Section 3.6.

D.1.1.  Message_1

   The Initiator generates its ephemeral key pair.

 X (Initiator's ephemeral private key) (32 bytes)
 8f 78 1a 09 53 72 f8 5b 6d 9f 61 09 ae 42 26 11 73 4d 7d bf a0 06 9a 2d
 f2 93 5b b2 e0 53 bf 35

 G_X (Initiator's
   ephemeral public key, CBOR unencoded) (32 bytes)
 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 ec 07 6b ba
 02 59 d9 04 b7 ec 8b 0c

   The Initiator chooses a connection identifier C_I:

   Connection identifier chosen by Initiator (1 byte)
   09

   Note that since C_I is a byte string in keys depend on the interval h'00' to h'2f',
   it is encoded as elliptic curve.  For X25519 and
   X448, the corresponding integer subtracted by 24.  Thus
   0x09 = 09, 9 - 24 = -15, requirements are defined in [RFC7748].  For secp256r1,
   secp384r1, and -15 secp521r1, the requirements are defined in CBOR encoding Section 5
   of [SP-800-56A].  For secp256r1, secp384r1, and secp521r1, at least
   partial public-key validation MUST be done.

7.3.  Cipher Suites and Cryptographic Algorithms

   For many constrained IoT devices it is equal problematic to 0x2e.

   C_I (1 byte)
   2e

   Since no external authorization data is sent:

   EAD_1 (0 bytes)

   The list of supported support more
   than one cipher suites needs suite.  Existing devices can be expected to contain the selected support
   either ECDSA or EdDSA.  To enable as much interoperability as we can
   reasonably achieve, less constrained devices SHOULD implement both
   cipher suite.  The initiator truncates the list of supported suite 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, AES-CCM-
   16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA-256,
   P-256, ES256, AES-CCM-16-64-128, SHA-256).  Constrained endpoints
   SHOULD implement cipher
   suites to one suite 0 or cipher suite only.  In this case there is 2.  Implementations
   only one need to implement the algorithms needed for their supported
   methods.

   When using private cipher suite indicated, 00.

   Because one single selected or registering new cipher suite is conveyed, it is encoded
   as an int instead of an array:

   SUITES_I (int)
   0

   message_1 is constructed as suites, the CBOR Sequence
   choice of key length used in the data items above
   encoded as CBOR.  In CBOR diagnostic notation:

  message_1 =
  (
    1,
    0,
    h'898FF79A02067A16EA1ECCB90FA52246F5AA4DD6EC076BBA0259D904B7EC8B0C',
    -15
  )

   Which as different algorithms needs to be
   harmonized, so that a CBOR encoded data item is:

 message_1 (CBOR Sequence) (37 bytes)
 01 00 58 20 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6
 ec 07 6b ba 02 59 d9 04 b7 ec 8b 0c 2e

D.1.2.  Message_2

   Since METHOD_CORR mod 4 equals 1, C_I sufficient security level is omitted from data_2. maintained for
   certificates, EDHOC, and the protection of application data.  The Responder generates
   Initiator and the following ephemeral key pair.

 Y (Responder's ephemeral private key) (32 bytes)
 fd 8c d8 77 c9 ea 38 6e 6a f3 4f f7 e6 06 c4 b6 4c a8 31 c8 ba 33 13 4f
 d4 cd 71 67 ca ba ec da

 G_Y (Responder's ephemeral public key, CBOR unencoded) (32 bytes)
 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52
 81 75 4c 5e bc af 30 1e

   From G_X Responder should enforce a minimum security level.

   The hash algorithms SHA-1 and Y or from G_Y SHA-256/64 (256-bit Hash truncated to
   64-bits) SHALL NOT be supported for use in EDHOC except for
   certificate identification with x5u and X the ECDH shared secret c5u.  Note that secp256k1 is computed:

 G_XY (ECDH shared secret) (32 bytes)
 2b b7 fa 6e 13 5b c3 35 d0 22 d6 34 cb fb 14 b3 f5 82 f3 e2 e3 af b2 b3
 15 04 91 49 5c 61 78 2b

   The key
   only defined for use with ECDSA and nonce not for calculating ECDH.

7.4.  Unprotected Data

   The Initiator and the 'ciphertext' are calculated as
   follows, as specified Responder 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 EAD_1, ID_CRED_R, EAD_2, and error
   messages.  Using the same EAD_1 in Section 4.

   HKDF SHA-256 several EDHOC sessions allows
   passive eavesdroppers to correlate the different sessions.  Another
   consideration is that the HKDF used (as defined by list of supported cipher suite 0).

   PRK_2e = HMAC-SHA-256(salt, G_XY)

   Salt is suites may
   potentially be used to identify the empty byte string.

   salt (0 bytes)

   From there, PRK_2e is computed:

 PRK_2e (32 bytes)
 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f
 d8 2f be b7 99 71 39 4a application.

   The Responder's sign/verify key pair is the following:

 SK_R (Responder's private authentication key) (32 bytes)
 df 69 27 4d 71 32 96 e2 46 30 63 65 37 2b 46 83 ce d5 38 1b fc ad cd 44
 0a 24 c3 91 d2 fe db 94

 PK_R (Responder's public authentication key) (32 bytes)
 db d9 dc 8c d0 3f b7 c3 91 35 11 46 2b b2 38 16 47 7c 6b d8 d6 6e f5 a1
 a0 70 ac 85 4e d7 3f d2

   Since neither the Initiator nor and the Responder authenticates with a
   static Diffie-Hellman key, PRK_3e2m = PRK_2e

 PRK_3e2m (32 bytes)
 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f
 d8 2f be b7 99 71 39 4a

   The Responder chooses a connection identifier C_R.

   Connection identifier chosen by Responder (1 byte)
   00

   Note must also make sure that since C_R is
   unauthenticated data does not trigger any harmful actions.  In
   particular, this applies to EAD_1 and error messages.

7.5.  Denial-of-Service

   EDHOC itself does not provide countermeasures against Denial-of-
   Service attacks.  By sending a byte string in number of new or replayed message_1 an
   attacker may cause the interval h'00' Responder to h'2f',
   it is encoded allocate state, perform
   cryptographic operations, and amplify messages.  To mitigate such
   attacks, an implementation SHOULD rely on lower layer mechanisms such
   as the corresponding integer subtracted by 24.  Thus
   0x00 = 0, 0 - 24 = -24, and -24 Echo option in CBOR encoding CoAP [I-D.ietf-core-echo-request-tag] that
   forces the initiator to demonstrate reachability at its apparent
   network address.

   An attacker can also send faked message_2, message_3, message_4, or
   error in an attempt to trick the receiving party to send an error
   message and discontinue the session.  EDHOC implementations MAY
   evaluate if a received message is equal likely to 0x37.

   C_R (1 byte)
   37

   Data_2 have been forged by and
   attacker and ignore it without sending an error message or
   discontinuing the session.

7.6.  Implementation Considerations

   The availability of a secure random number generator is constructed as essential for
   the CBOR Sequence security of G_Y EDHOC.  If no true random number generator is
   available, a truly random seed MUST be provided from an external
   source and C_R, encoded as
   CBOR byte strings.  The CBOR diagnostic notation is:

  data_2 =
  (
    h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e',
    -24
  )

   Which as used with a CBOR encoded data item is:

 data_2 (CBOR Sequence) (35 bytes)
 58 20 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0
 19 52 81 75 4c 5e bc af 30 1e 37

   From data_2 cryptographically secure pseudorandom number
   generator.  As each pseudorandom number must only be used once, an
   implementation needs to get a new truly random seed after reboot, or
   continuously store state in nonvolatile memory, see ([RFC8613],
   Appendix B.1.1) for issues and message_1, compute the input solution approaches for writing to the transcript hash
   TH_2 = H( H(message_1), data_2 ), as
   nonvolatile memory.  Intentionally or unintentionally weak or
   predictable pseudorandom number generators can be abused or exploited
   for malicious purposes.  [RFC8937] describes a CBOR Sequence of these 2 data
   items.

 Input way for security
   protocol implementations to calculate TH_2 (CBOR Sequence) (72 bytes)
 01 00 58 20 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6
 ec 07 6b ba 02 59 d9 04 b7 ec 8b 0c 2e 58 20 71 a3 d5 99 c2 1d a1 89 02
 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52 81 75 4c 5e bc af 30 1e 37

   And augment their (pseudo)random number
   generators using a long-term private key and a deterministic
   signature function.  This improves randomness from there, compute the transcript hash TH_2 = SHA-256(
   H(message_1), data_2 )

 TH_2 (CBOR unencoded) (32 bytes)
 86 4e 32 b3 6a 7b 5f 21 f1 9e 99 f0 c6 6d 91 1e 0a ce 99 72 d3 76 d2 c2
 c1 53 c1 7f 8e 96 29 ff broken or
   otherwise subverted random number generators.  The Responder's subject name same idea can be
   used with other secrets and functions such as a Diffie-Hellman
   function or a symmetric secret and a PRF like HMAC or KMAC.  It is the empty string:

   Responder's subject name (text string)
   ""

   In this version
   RECOMMENDED to not trust a single source of randomness and to not put
   unaugmented random numbers on the test vectors CRED_R wire.

   If ECDSA is supported, "deterministic ECDSA" as specified in
   [RFC6979] MAY be used.  Pure deterministic elliptic-curve signatures
   such as deterministic ECDSA and EdDSA have gained popularity over
   randomized ECDSA as their security do not depend on a DER encoded X.509
   certificate, but a string source of random bytes.

 CRED_R (CBOR unencoded) (100 bytes)
 c7 88 37 00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86
 44 2b 87 ec 3f f2 45 b7 0a 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6
 b0 53 4b 71 c2 b4 9e 4b f9 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e
 98 db 71 41 08 41 5e 5c 50 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be
 5c 22 5e b2

   CRED_R is defined to high-
   quality randomness.  Recent research has however found that
   implementations of these signature algorithms may be the CBOR bstr containing the credential vulnerable to
   certain side-channel and fault injection attacks due to their
   determinism.  See e.g., Section 1 of
   the Responder.

 CRED_R (102 bytes)
 58 64 c7 88 37 00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40
 6e 86 44 2b 87 ec 3f f2 45 b7 0a 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e
 c9 d6 b0 53 4b 71 c2 b4 9e 4b f9 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b
 38 1e 98 db 71 41 08 41 5e 5c 50 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62
 71 be 5c 22 5e b2

   And because certificates are identified by

   [I-D.mattsson-cfrg-det-sigs-with-noise] for a hash value with the
   'x5t' parameter, ID_CRED_R is the following:

   ID_CRED_R = { 34 : COSE_CertHash }. In list of attack papers.
   As suggested in Section 6.1.2 of [I-D.ietf-cose-rfc8152bis-algs] this example, the hash
   algorithm used is SHA-2 256-bit with hash truncated to 64-bits (value
   -15).  The hash value is calculated over the CBOR unencoded CRED_R.
   The CBOR diagnostic notation is:

   ID_CRED_R =
   {
     34: [-15, h'6844078A53F312F5']
   }

   which when encoded as a CBOR map becomes:

   ID_CRED_R (14 bytes)
   a1 18 22 82 2e 48 68 44 07 8a 53 f3 12 f5

   Since no external authorization data is sent:

   EAD_2  (0 bytes)

   The plaintext is defined
   can be addressed by combining randomness and determinism.

   All private keys, symmetric keys, and IVs MUST be secret.
   Implementations should provide countermeasures to side-channel
   attacks such as the empty string:

   P_2m (0 bytes)

   The Enc_structure is defined timing attacks.  Intermediate computed values such as follows: [ "Encrypt0",
   << ID_CRED_R >>, << TH_2, CRED_R >> ], indicating that ID_CRED_R
   ephemeral ECDH keys and ECDH shared secrets MUST be deleted after key
   derivation is
   encoded as a CBOR byte string, completed.

   The Initiator and that the concatenation of Responder are responsible for verifying the CBOR
   byte strings TH_2
   integrity of certificates.  The selection of trusted CAs should be
   done very carefully and CRED_R is wrapped as a CBOR bstr. certificate revocation should be supported.
   The CBOR
   diagnostic notation is private authentication keys MUST be kept secret.

   The Initiator and the following:

A_2m =
[
  "Encrypt0",
  h'A11822822E486844078A53F312F5',
  h'5820864E32B36A7B5F21F19E99F0C66D911E0ACE9972D376D2C2C153C17F8E9629FF
  5864C788370016B8965BDB2074BFF82E5A20E09BEC21F8406E86442B87EC3FF245B70A
  47624DC9CDC6824B2A4C52E95EC9D6B0534B71C2B49E4BF9031500CEE6869979C297BB
  5A8B381E98DB714108415E5C50DB78974C271579B01633A3EF6271BE5C225EB2'
  ]
   Which encodes Responder are allowed to select the following byte string connection
   identifiers C_I and C_R, respectively, for the other party to be used use in
   the ongoing EDHOC protocol as Additional
   Authenticated Data:

 A_2m (CBOR-encoded) (163 bytes)
 83 68 45 6e 63 72 79 70 74 30 4e a1 18 22 82 2e 48 68 44 07 8a 53 f3 12
 f5 58 88 58 20 86 4e 32 b3 6a 7b 5f 21 f1 9e 99 f0 c6 6d 91 1e 0a ce 99
 72 d3 76 d2 c2 c1 53 c1 7f 8e 96 29 ff 58 64 c7 88 37 00 16 b8 96 5b db
 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 ec 3f f2 45 b7 0a
 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9
 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50
 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2

   info for K_2m is defined well as follows in CBOR diagnostic notation:

  info for K_2m =
  [
    10,
    h'864E32B36A7B5F21F19E99F0C66D911E0ACE9972D376D2C2C153C17F8E9629FF',
    "K_2m",
    16
  ]

   Which as a CBOR encoded data item is:

 info for K_2m (CBOR-encoded) (42 bytes)
 84 0a 58 20 86 4e 32 b3 6a 7b 5f 21 f1 9e 99 f0 c6 6d 91 1e 0a ce 99 72
 d3 76 d2 c2 c1 53 c1 7f 8e 96 29 ff 64 4b 5f 32 6d 10

   From these parameters, K_2m is computed.  Key K_2m is the output subsequent application
   protocol (e.g., OSCORE [RFC8613]).  The choice of
   HKDF-Expand(PRK_3e2m, info, L), where L connection
   identifier is not security critical in EDHOC but intended to simplify
   the length retrieval of K_2m, so 16
   bytes.

   K_2m (16 bytes)
   80 cc a7 49 ab 58 f5 69 ca 35 da ee 05 be d1 94

   info for IV_2m is defined as follows, the right security context in CBOR diagnostic notation (10
   is combination with using
   short identifiers.  If the COSE algorithm no. wrong connection identifier of the AEAD algorithm other
   party is used in a protocol message it will result in the selected
   cipher suite 0):

  info for IV_2m =
  [
    10,
    h'864E32B36A7B5F21F19E99F0C66D911E0ACE9972D376D2C2C153C17F8E9629FF',
    "IV_2m",
    13
  ]

   Which receiving
   party not being able to retrieve a security context (which will
   terminate the protocol) or retrieve the wrong security context (which
   also terminates the protocol as the message cannot be verified).

   If two nodes unintentionally initiate two simultaneous EDHOC message
   exchanges with each other even if they only want to complete a CBOR encoded data item is:

 info for IV_2m (CBOR-encoded) (43 bytes)
 84 0a 58 20 86 4e 32 b3 6a 7b 5f 21 f1 9e 99 f0 c6 6d 91 1e 0a ce 99 72
 d3 76 d2 c2 c1 53 c1 7f 8e 96 29 ff 65 49 56 5f 32 6d 0d

   From these parameters, IV_2m is computed.  IV_2m is single
   EDHOC message exchange, they MAY terminate the output exchange with the
   lexicographically smallest G_X.  If the two G_X values are equal, the
   received message_1 MUST be discarded to mitigate reflection attacks.
   Note that in the case of
   HKDF-Expand(PRK_3e2m, info, L), two simultaneous EDHOC exchanges where L is the length
   nodes only complete one and where the nodes have different preferred
   cipher suites, an attacker can affect which of IV_2m, so 13
   bytes.

   IV_2m (13 bytes)
   c8 1e 1a 95 cc 93 b3 36 69 6e d5 02 55

   Finally, COSE_Encrypt0 is computed from the parameters above.

   o  protected header = CBOR-encoded ID_CRED_R

   o  external_aad = A_2m

   o  empty plaintext = P_2m

   MAC_2 (CBOR unencoded) (8 bytes)
   fa bb a4 7e 56 71 a1 82

   To compute two nodes'
   preferred cipher suites will be used by blocking the Signature_or_MAC_2, other exchange.

   If supported by the key device, it is RECOMMENDED that at least the long-
   term private
   authentication keys are stored in a Trusted Execution Environment (TEE)
   and that sensitive operations using these keys are performed inside
   the TEE.  To achieve even higher security, it is RECOMMENDED that in
   additional operations such as ephemeral key generation, all
   computations of shared secrets, and storage of the Responder pseudorandom keys
   (PRK) can be done inside the TEE.  The use of a TEE enforces that
   code within that environment cannot be tampered with, and that any
   data used by such code cannot be read or tampered with by code
   outside that environment.  Note that non-EDHOC code inside the message M_2 TEE
   might still be able to read EDHOC data and tamper with EDHOC code, to
   protect against such attacks EDHOC needs to be signed
   = [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? EAD_2 >>, MAC_2
   ].  ID_CRED_R is encoded as a CBOR byte string, the concatenation in its own zone.  To
   provide better protection against some forms of physical attacks,
   sensitive EDHOC data should be stored inside the CBOR byte strings TH_2 and CRED_R is wrapped as a CBOR bstr, SoC or encrypted and
   MAC_2 is encoded as a CBOR bstr.

 M_2 =
 [
   "Signature1",
   h'A11822822E486844078A53F312F5',
   h'5820864E32B36A7B5F21F19E99F0C66D911E0ACE9972D376D2C2C153C17F8E9629F
   F5864C788370016B8965BDB2074BFF82E5A20E09BEC21F8406E86442B87EC3FF245B7
   0A47624DC9CDC6824B2A4C52E95EC9D6B0534B71C2B49E4BF9031500CEE6869979C29
   7BB5A8B381E98DB714108415E5C50DB78974C271579B01633A3EF6271BE5C225EB2',
   h'FABBA47E5671A182'
 ]

   Which as
   integrity protected when sent on a CBOR encoded data item is:

 M_2 (174 bytes)
 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 68 44 07 8a 53
 f3 12 f5 58 88 58 20 86 4e 32 b3 6a 7b 5f 21 f1 9e 99 f0 c6 6d 91 1e 0a
 ce 99 72 d3 76 d2 c2 c1 53 c1 7f 8e 96 29 ff 58 64 c7 88 37 00 16 b8 96
 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 ec 3f f2 45
 b7 0a 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e
 4b f9 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e
 5c 50 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 48 fa bb
 a4 7e 56 71 a1 82

   Since bus (e.g., between the method = 0, Signature_or_MAC_2 is a signature.  The
   algorithm with selected cipher suite 0 is Ed25519 CPU
   and RAM or Flash).  Secure boot can be used to increase the output is
   64 bytes.

 Signature_or_MAC_2 (CBOR unencoded) (64 bytes)
 1f 17 00 6a 98 48 c9 77 cb bd ca a7 57 b6 fd 46 82 c8 17 39 e1 5c 99 37
 c2 1c f5 e9 a0 e6 03 9f 54 fd 2a 6c 3a 11 18 f2 b9 d8 eb cd 48 23 48 b9
 9c 3e d7 ed 1b d9 80 6c 93 c8 90 68 e8 36 b4 0f

   CIPHERTEXT_2 is security
   of code and data in the Rich Execution Environment (REE) by
   validating the REE image.

8.  IANA Considerations

8.1.  EDHOC Exporter Label

   IANA has created a new registry titled "EDHOC Exporter Label" under
   the ciphertext resulting from XOR between plaintext
   and KEYSTREAM_2 which new heading "EDHOC".  The registration procedure is derived from TH_2 and the pseudorandom key
   PRK_2e.

   o  plaintext = CBOR Sequence "Expert
   Review".  The columns of the items ID_CRED_R registry are Label, Description, and
      Signature_or_MAC_2 encoded as CBOR byte strings, in this order
      (EAD_2 is empty).
   Reference.  All columns are text strings.  The plaintext initial contents of
   the registry are:

   Label: EDHOC_message_4_Key
   Description: Key used to protect EDHOC message_4
   Reference: [[this document]]

   Label: EDHOC_message_4_Nonce
   Description: Nonce used to protect EDHOC message_4
   Reference: [[this document]]

   Label: OSCORE Master Secret
   Description: Derived OSCORE Master Secret
   Reference: [[this document]]

   Label: OSCORE Master Salt
   Description: Derived OSCORE Master Salt
   Reference: [[this document]]

8.2.  EDHOC Cipher Suites Registry

   IANA has created a new registry titled "EDHOC Cipher Suites" under
   the new heading "EDHOC".  The registration procedure is "Expert
   Review".  The columns of the following:

 P_2e (CBOR Sequence) (80 bytes)
 a1 18 22 82 2e 48 68 44 07 8a 53 f3 12 f5 58 40 1f 17 00 6a 98 48 c9 77
 cb bd ca a7 57 b6 fd 46 82 c8 17 39 e1 5c 99 37 c2 1c f5 e9 a0 e6 03 9f
 54 fd 2a 6c 3a 11 18 f2 b9 d8 eb cd 48 23 48 b9 9c 3e d7 ed 1b d9 80 6c
 93 c8 90 68 e8 36 b4 0f

   KEYSTREAM_2 = HKDF-Expand( PRK_2e, info, length ), registry are Value, Array, Description,
   and Reference, where length Value is an integer and the length other columns are
   text strings.  The initial contents of the plaintext, so 80.

  info registry are:

   Value: -24
   Algorithms: N/A
   Desc: Reserved for KEYSTREAM_2 =
  [ Private Use
   Reference: [[this document]]
   Value: -23
   Algorithms: N/A
   Desc: Reserved for Private Use
   Reference: [[this document]]

   Value: -22
   Algorithms: N/A
   Desc: Reserved for Private Use
   Reference: [[this document]]

   Value: -21
   Algorithms: N/A
   Desc: Reserved for Private Use
   Reference: [[this document]]

   Value: 0
   Array: 10, -16, 4, -8, 10,
    h'864E32B36A7B5F21F19E99F0C66D911E0ACE9972D376D2C2C153C17F8E9629FF',
    "KEYSTREAM_2",
    80
  ]

   Which as a CBOR encoded data item is:

 info for KEYSTREAM_2 (CBOR-encoded) (50 bytes)
 84 0a 58 20 86 4e 32 b3 6a 7b 5f 21 f1 9e 99 f0 c6 6d 91 1e 0a ce 99 72
 d3 76 d2 c2 c1 53 c1 7f 8e 96 29 ff 6b 4b 45 59 53 54 52 45 41 4d 5f 32
 18 50

   From there, KEYSTREAM_2 is computed:

 KEYSTREAM_2 (80 bytes)
 ae ea 8e af 50 cf c6 70 09 da e8 2d 8d 85 b0 e7 60 91 bf 0f 07 0b 79 53
 6c 83 23 dc 3d 9d 61 13 10 35 94 63 f4 4b 12 4b ea b3 a1 9d 09 93 82 d7
 30 80 17 f4 92 62 06 e4 f5 44 9b 9f c9 -16
   Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA,
         AES-CCM-16-64-128, SHA-256
   Reference: [[this document]]

   Value: 1
   Array: 30, -16, 4, -8, 10, -16
   Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA,
         AES-CCM-16-64-128, SHA-256
   Reference: [[this document]]

   Value: 2
   Array: 10, -16, 1, -7, 10, -16
   Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256,
         AES-CCM-16-64-128, SHA-256
   Reference: [[this document]]

   Value: 3
   Array: 30, -16, 1, -7, 10, -16
   Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256,
         AES-CCM-16-64-128, SHA-256
   Reference: [[this document]]

   Value: 4
   Array: 24, -16, 4, -8, 24, -16
   Desc: ChaCha20/Poly1305, SHA-256, X25519, EdDSA,
         ChaCha20/Poly1305, SHA-256
   Reference: [[this document]]
   Value: 5
   Array: 24, -16, 1, -7, 24, -16
   Desc: ChaCha20/Poly1305, SHA-256, P-256, ES256,
         ChaCha20/Poly1305, SHA-256
   Reference: [[this document]]

   Value: 6
   Array: 1, -16, 4, -7, 1, -16
   Desc: A128GCM, SHA-256, X25519, ES256,
         A128GCM, SHA-256
   Reference: [[this document]]

   Value: 24 bc b6 bd 78 ec 45 0a 66 83 fb
 8a 2f 5f 92 4f c4 40 4f

   Using the parameters above,
   Array: 3, -43, 2, -35, 3, -43
   Desc: A256GCM, SHA-384, P-384, ES384,
         A256GCM, SHA-384
   Reference: [[this document]]

   Value: 25
   Array: 24, -45, 5, -8, 24, -45
   Desc: ChaCha20/Poly1305, SHAKE256, X448, EdDSA,
         ChaCha20/Poly1305, SHAKE256
   Reference: [[this document]]

8.3.  EDHOC Method Type Registry

   IANA has created a new registry entitled "EDHOC Method Type" under
   the ciphertext CIPHERTEXT_2 can be
   computed:

 CIPHERTEXT_2 (CBOR unencoded) (80 bytes)
 0f f2 ac 2d 7e 87 ae 34 0e 50 bb de 9f 70 e8 a7 7f 86 bf 65 9f 43 b0 24
 a7 3e e9 7b 6a 2b 9c 55 92 fd 83 5a 15 17 8b 7c 28 af 54 74 a9 75 81 48
 64 7d 3d 98 a8 73 1e 16 4c 9c 70 52 81 07 f4 0f 21 46 3b a8 11 bf 03 97
 19 e7 cf fa a7 f2 f4 40

   message_2 new heading "EDHOC".  The registration procedure is the CBOR Sequence "Expert
   Review".  The columns of data_2 the registry are Value, Description, and CIPHERTEXT_2,
   Reference, where Value is an integer and the other columns are text
   strings.  The initial contents of the registry are shown in this
   order:

message_2 =
(
  data_2,
  h'0FF2AC2D7E87AE340E50BBDE9F70E8A77F86BF659F43B024A73EE97B6A2B9C5592FD
  835A15178B7C28AF5474A9758148647D3D98A8731E164C9C70528107F40F21463BA811
  BF039719E7CFFAA7F2F440'
)

   Which as Figure 4.

8.4.  EDHOC Error Codes Registry

   IANA has created a CBOR encoded data item is:

 message_2 (CBOR Sequence) (117 bytes)
 58 20 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0
 19 52 81 75 4c 5e bc af 30 1e 37 58 50 0f f2 ac 2d 7e 87 ae 34 0e 50 bb
 de 9f 70 e8 a7 7f 86 bf 65 9f 43 b0 24 a7 3e e9 7b 6a 2b 9c 55 92 fd 83
 5a 15 17 8b 7c 28 af 54 74 a9 75 81 48 64 7d 3d 98 a8 73 1e 16 4c 9c 70
 52 81 07 f4 0f 21 46 3b a8 11 bf 03 97 19 e7 cf fa a7 f2 f4 40

D.1.3.  Message_3

   Since corr equals 1, C_R new registry entitled "EDHOC Error Codes" under
   the new heading "EDHOC".  The registration procedure is not omitted from data_3.
   "Specification Required".  The Initiator's sign/verify key pair columns of the registry are ERR_CODE,
   ERR_INFO Type and Description, where ERR_CODE is an integer, ERR_INFO
   is a CDDL defined type, and Description is a text string.  The
   initial contents of the following:

 SK_I (Initiator's private authentication key) (32 bytes)
 2f fc e7 a0 b2 b8 25 d3 97 d0 cb 54 f7 46 e3 da 3f 27 59 6e e0 6b 53 71
 48 1d c0 e0 12 bc 34 d7

 PK_I (Responder's public authentication key) (32 bytes)
 38 e5 d5 45 63 c2 b6 a4 ba 26 f3 01 5f 61 bb 70 6e 5c 2e fd b5 56 d2 e1
 69 0b 97 fc 3c 6d e1 49

   HKDF SHA-256 registry are shown in Figure 6.

8.5.  COSE Header Parameters Registry

   This document registers the following entries in the "COSE Header
   Parameters" registry under the "CBOR Object Signing and Encryption
   (COSE)" heading.  The value of the 'cwt' header parameter is a CWT
   [RFC8392] or an Unprotected CWT Claims Set, see Section 1.5.

   +-----------+-------+----------------+------------------------------+
   | Name      | Label | Value Type     | Description                  |
   +===========+=======+================+==============================+
   | cwt       |  TBD1 | COSE_Messages  | A CBOR Web Token (CWT) or an |
   |           |       | / map          | Unprotected CWT Claims Set   |
   +-----------+-------+----------------+------------------------------+

8.6.  COSE Header Parameters Registry

   IANA has extended the HKDF used (as defined by cipher suite 0).

   PRK_4x3m = HMAC-SHA-256 (PRK_3e2m, G_IY)

 PRK_4x3m (32 bytes)
 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f
 d8 2f be b7 99 71 39 4a

   data 3 Value Type of the COSE Header Parameter 'kid'
   to also allow the Value Type int.  The resulting Value Type is equal bstr /
   int.  The 'kid' parameter can be used to C_R.

   data_3 (CBOR Sequence) (1 byte)
   37

   From data_3, CIPHERTEXT_2, identify a key stored in a
   UCCS, in a CWT, or in a public key certificate.  (The Value Registry
   for this item is empty and TH_2, compute omitted from the input to table below.)

   +------+-------+------------+----------------+-------------------+
   | Name | Label | Value Type | Description    | Reference         |
   +------+-------+------------+----------------+-------------------+
   | kid  |   4   | bstr / int | Key identifier | [RFC9052]         |
   |      |       |            |                | [[This document]] |
   +------+-------+------------+----------------+-------------------+

8.7.  COSE Key Common Parameters Registry

   IANA has extended the
   transcript hash TH_3 = H( H(TH_2 , CIPHERTEXT_2), data_3), as a CBOR
   Sequence Value Type of 2 data items.

 Input the COSE Key Common Parameter
   'kid' to calculate TH_3 (CBOR Sequence) (117 bytes)
 58 20 86 4e 32 b3 6a 7b 5f 21 f1 9e 99 f0 c6 6d 91 1e 0a ce 99 72 d3 76
 d2 c2 c1 53 c1 7f 8e 96 29 ff 58 50 0f f2 ac 2d 7e 87 ae 34 0e 50 bb de
 9f 70 e8 a7 7f 86 bf 65 9f 43 b0 24 a7 3e e9 7b 6a 2b 9c 55 92 fd 83 5a
 15 17 8b 7c 28 af 54 74 a9 75 81 48 64 7d 3d 98 a8 73 1e 16 4c 9c 70 52
 81 07 f4 0f 21 46 3b a8 11 bf 03 97 19 e7 cf fa a7 f2 f4 40 37

   And the COSE Key Value Type int.  The resulting Value Type is
   bstr / int.  (The Value Registry for this item is empty and omitted
   from there, compute the transcript hash TH_3 = SHA-256( H(TH_2 ,
   CIPHERTEXT_2), data_3)

 TH_3 (CBOR unencoded) (32 bytes)
 f2 4d 18 ca fc e3 74 d4 e3 73 63 29 c1 52 ab 3a ea 9c 7c 0f 65 0c 30 70
 b6 f5 1e 68 e2 ae bb 60 table below.)

   +------+-------+------------+----------------+-------------------+
   | Name | Label | Value Type | Description    | Reference         |
   +------+-------+------------+----------------+-------------------+
   | kid  |   2   | bstr / int | Key identifi-  | [RFC9052]         |
   |      |       |            | cation value - | [[This document]] |
   |      |       |            | match to kid   |                   |
   |      |       |            | in message     |                   |
   +------+-------+------------+----------------+-------------------+

8.8.  The Initiator's subject name is Well-Known URI Registry

   IANA has added the empty string:

   Initiator's subject name (text string)
   ""

   In this version of well-known URI "edhoc" to the test vectors CRED_I is not a DER encoded X.509
   certificate, but a string of random bytes.

 CRED_I (CBOR unencoded) (101 bytes)
 54 13 20 4c 3e bc 34 28 a6 cf 57 e2 4c 9d ef 59 65 17 70 44 9b ce 7e c6
 56 1e 52 43 3a a5 5e 71 f1 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60
 88 09 84 49 cb 84 8f fc 79 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e
 8f 6c 77 a4 a2 c3 01 95 60 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65
 02 ff 7b dd a6

   CRED_I is defined Well-Known URIs
   registry.

   *  URI suffix: edhoc

   *  Change controller: IETF

   *  Specification document(s): [[this document]]
   *  Related information: None

8.9.  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: See
      "Authors' Addresses" section.

   *  Intended usage: COMMON

   *  Restrictions on usage: N/A

   *  Author: See "Authors' Addresses" section.

   *  Change Controller: IESG

8.10.  CoAP Content-Formats Registry

   IANA has added the CBOR bstr containing media type "application/edhoc" to the CoAP
   Content-Formats registry.

   *  Media Type: application/edhoc

   *  Encoding:

   *  ID: TBD42

   *  Reference: [[this document]]

8.11.  EDHOC External Authorization Data

   IANA has created a new registry entitled "EDHOC External
   Authorization Data" under the credential new heading "EDHOC".  The registration
   procedure is "Expert Review".  The columns of the Initiator.

 CRED_I (103 bytes)
 58 65 54 13 20 4c 3e bc 34 28 a6 cf 57 e2 4c 9d ef 59 65 17 70 44 9b ce
 7e c6 56 1e 52 43 3a a5 5e 71 f1 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1
 76 60 88 09 84 49 cb 84 8f fc 79 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21
 67 5e 8f 6c 77 a4 a2 c3 01 95 60 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44
 48 65 02 ff 7b dd a6

   And because certificates registry are identified by a hash value with the
   'x5t' parameter, ID_CRED_I Value,
   Description, and Reference, where Value is an integer and the following:

   ID_CRED_I = { 34 : COSE_CertHash }. In this example, the hash
   algorithm used is SHA-2 256-bit with hash truncated to 64-bits (value
   -15). other
   columns are text strings.

8.12.  Expert Review Instructions

   The hash value IANA Registries established in this document is calculated over defined as
   "Expert Review".  This section gives some general guidelines for what
   the CBOR unencoded CRED_I.

   ID_CRED_I =
   {
     34: [-15, h'705D5845F36FC6A6']
   }

   which when encoded experts should be looking for, but they are being designated as
   experts for a CBOR map becomes:

   ID_CRED_I (14 bytes)
   a1 18 22 82 2e 48 70 5d 58 45 f3 6f c6 a6

   Since no external authorization data is exchanged:

   EAD_3 (0 bytes)

   The plaintext reason so they should be given substantial latitude.

   Expert reviewers should take into consideration the following points:

   *  Clarity and correctness of registrations.  Experts are expected to
      check the COSE_Encrypt is clarity of purpose and use of the empty string:

   P_3m (0 bytes)

   The associated data is requested entries.
      Expert needs to make sure the following: [ "Encrypt0", << ID_CRED_I >>,
   << TH_3, CRED_I, ? EAD_3 >> ].

 A_3m (CBOR-encoded) (164 bytes)
 83 68 45 6e 63 72 79 70 74 30 4e a1 18 22 82 2e 48 70 5d 58 45 f3 6f c6
 a6 58 89 58 20 f2 4d 18 ca fc e3 74 d4 e3 73 63 29 c1 52 ab 3a ea 9c 7c
 0f 65 0c 30 70 b6 f5 1e 68 e2 ae bb 60 58 65 54 13 20 4c 3e bc 34 28 a6
 cf 57 e2 4c 9d ef 59 65 17 70 44 9b ce 7e c6 56 1e 52 43 3a a5 5e 71 f1
 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79
 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60
 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6

   Info for K_3m values of algorithms are taken from
      the right registry, when that is computed as follows:

  info for K_3m =
  [
    10,
    h'F24D18CAFCE374D4E3736329C152AB3AEA9C7C0F650C3070B6F51E68E2AEBB60',
    "K_3m",
    16
  ]

   Which as a CBOR encoded data item is:

 info for K_3m (CBOR-encoded) (42 bytes)
 84 0a 58 20 f2 4d 18 ca fc e3 74 d4 e3 73 63 29 c1 52 ab 3a ea 9c 7c 0f
 65 0c 30 70 b6 f5 1e 68 e2 ae bb 60 64 4b 5f 33 6d 10

   From required.  Expert should consider
      requesting an opinion on the correctness of registered parameters
      from relevant IETF working groups.  Encodings that do not meet
      these parameters, K_3m is computed.  Key K_3m is objective of clarity and completeness should not be
      registered.

   *  Experts should take into account the output expected usage of fields when
      approving point assignment.  The length of
   HKDF-Expand(PRK_4x3m, info, L), where L is the encoded value
      should be weighed against how many code points of that length are
      left, the size of K_2m, so 16
   bytes.

   K_3m (16 bytes)
   83 a9 c3 88 02 91 2e 7f 8f 0d 2b 84 14 d1 e5 2c

   Nonce IV_3m is device it will be used on, and the output number of HKDF-Expand(PRK_4x3m, info, L), where L
   = 13 bytes.

   Info for IV_3m is defined as follows:

  info
      code points left that encode to that size.

   *  Specifications are recommended.  When specifications are not
      provided, the description provided needs to have sufficient
      information to verify the points above.

9.  References

9.1.  Normative References

   [I-D.ietf-core-echo-request-tag]
              Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo,
              Request-Tag, and Token Processing", Work in Progress,
              Internet-Draft, draft-ietf-core-echo-request-tag-13, 12
              July 2021, <https://www.ietf.org/archive/id/draft-ietf-
              core-echo-request-tag-13.txt>.

   [I-D.ietf-cose-rfc8152bis-algs]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", Work in Progress, Internet-Draft,
              draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
              <https://www.ietf.org/archive/id/draft-ietf-cose-
              rfc8152bis-algs-12.txt>.

   [I-D.ietf-cose-rfc8152bis-struct]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", Work in Progress, Internet-Draft,
              draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021,
              <https://www.ietf.org/archive/id/draft-ietf-cose-
              rfc8152bis-struct-15.txt>.

   [I-D.ietf-cose-x509]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Header parameters for IV_3m =
  [
    10,
    h'F24D18CAFCE374D4E3736329C152AB3AEA9C7C0F650C3070B6F51E68E2AEBB60',
    "IV_3m",
    13
  ]

   Which as a CBOR encoded data item is:

 info carrying and referencing X.509
              certificates", Work in Progress, Internet-Draft, draft-
              ietf-cose-x509-08, 14 December 2020,
              <https://www.ietf.org/internet-drafts/draft-ietf-cose-
              x509-08.txt>.

   [RFC2119]  Bradner, S., "Key words for IV_3m (CBOR-encoded) (43 bytes)
 84 0a 58 20 f2 4d 18 ca fc e3 74 d4 e3 73 63 29 c1 52 ab 3a ea 9c 7c 0f
 65 0c 30 70 b6 f5 1e 68 e2 ae bb 60 65 49 56 5f 33 6d 0d

   From these parameters, IV_3m is computed:

   IV_3m (13 bytes)
   9c 83 9c 0e e8 36 42 50 5a 8e 1c 9f b2

   MAC_3 is the 'ciphertext' of the COSE_Encrypt0:

   MAC_3 (CBOR unencoded) (8 bytes)
   2f a1 e3 9e ae 7d 5f 8d

   Since the method = 0, Signature_or_MAC_3 is a signature.  The
   algorithm with selected cipher suite 0 is Ed25519.

   o  The message M_3 use in RFCs to be signed = [ "Signature1", << ID_CRED_I >>,
      << TH_3, CRED_I >>, MAC_3 ], i.e. ID_CRED_I encoded as CBOR bstr,
      the concatenation of the CBOR byte strings TH_3 Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5116]  McGrew, D., "An Interface and CRED_I wrapped
      as a CBOR bstr, Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and MAC_3 encoded as a CBOR bstr.

   o  The signing key is the private authentication key of the
      Initiator.

 M_3 =
 [
   "Signature1",
   h'A11822822E48705D5845F36FC6A6',
   h'5820F24D18CAFCE374D4E3736329C152AB3AEA9C7C0F650C3070B6F51E68E2AEBB6
   058655413204C3EBC3428A6CF57E24C9DEF59651770449BCE7EC6561E52433AA55E71
   F1FA34B22A9CA4A1E12924EAE1D1766088098449CB848FFC795F88AFC49CBE8AFDD1B
   A009F21675E8F6C77A4A2C30195601F6F0A0852978BD43D28207D44486502FF7BDD
   A6',
   h'2FA1E39EAE7D5F8D']

   Which as a CBOR encoded data item is:

 M_3 (175 bytes)
 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 70 5d 58 45 f3
 6f c6 a6 58 89 58 20 f2 4d 18 ca fc e3 74 d4 e3 73 63 29 c1 52 ab 3a ea
 9c 7c 0f 65 0c 30 70 b6 f5 1e 68 e2 ae bb 60 58 65 54 13 20 4c 3e bc 34
 28 a6 cf 57 e2 4c 9d ef 59 65 17 70 44 9b ce 7e c6 56 1e 52 43 3a a5 5e
 71 f1 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f
 fc 79 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01
 95 60 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 48 2f
 a1 e3 9e ae 7d 5f 8d
   From there, the 64 byte signature can be computed:

 Signature_or_MAC_3 (CBOR unencoded) (64 bytes)
 ab 9f 7b bd eb c4 eb f8 a3 d3 04 17 9b cc a3 9d 9c 8a 76 73 65 76 fb 3c
 32 d2 fa c7 e2 59 34 e5 33 dc c7 02 2e 4d 68 61 c8 f5 fe cb e9 2d 17 4e
 b2 be af 0a 59 a4 15 84 37 2f 43 2e 6b f4 7b 04

   Finally, W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

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

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

   [RFC6979]  Pornin, T., "Deterministic Usage of the outer COSE_Encrypt0 is computed.

   The plaintext is Digital Signature
              Algorithm (DSA) and Elliptic Curve Digital Signature
              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
              2013, <https://www.rfc-editor.org/info/rfc6979>.

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

   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
              Trammell, B., Huitema, C., and D. Borkmann,
              "Confidentiality in the CBOR Sequence Face of Pervasive Surveillance: A
              Threat Model and Problem Statement", RFC 7624,
              DOI 10.17487/RFC7624, August 2015,
              <https://www.rfc-editor.org/info/rfc7624>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the items ID_CRED_I Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/info/rfc7959>.

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

   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
              <https://www.rfc-editor.org/info/rfc8376>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zúñiga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.

   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/info/rfc8742>.

   [RFC8747]  Jones, M., Seitz, L., Selander, G., Erdtman, S., and the
   CBOR encoded Signature_or_MAC_3, in this order (EAD_3 is empty).

 P_3ae (CBOR Sequence) (80 bytes)
 a1 18 22 82 2e 48 70 5d 58 45 f3 6f c6 a6 58 40 ab 9f 7b bd eb c4 eb f8
 a3 d3 04 17 9b cc a3 9d 9c 8a 76 73 65 76 fb 3c 32 d2 fa c7 e2 59 34 e5
 33 dc c7 02 2e 4d 68 61 c8 f5 fe cb e9 2d 17 4e b2 be af 0a 59 a4 15 84
 37 2f 43 2e 6b f4 7b 04

   The Associated data A is the following: Associated data A = [
   "Encrypt0", h'', TH_3 ]

 A_3ae (CBOR-encoded) (45 bytes)
 83 68 45 6e 63 72 79 70 74 30 40 58 20 f2 4d 18 ca fc e3 74 d4 e3 73 63
 29 c1 52 ab 3a ea 9c 7c 0f 65 0c 30 70 b6 f5 1e 68 e2 ae bb 60 H.
              Tschofenig, "Proof-of-Possession Key K_3ae is the output of HKDF-Expand(PRK_3e2m, info, L).

   info is defined as follows:

  info Semantics for K_3ae =
  [
    10,
    h'F24D18CAFCE374D4E3736329C152AB3AEA9C7C0F650C3070B6F51E68E2AEBB60',
    "K_3ae",
    16
  ]

   Which as a CBOR encoded data item is:

 info for K_3ae (CBOR-encoded) (43 bytes)
 84 0a 58 20 f2 4d 18 ca fc e3 74 d4 e3 73 63 29 c1 52 ab 3a ea 9c 7c 0f
 65 0c 30 70 b6 f5 1e 68 e2 ae bb 60 65 4b 5f 33 61 65 10

   L is the length of K_3ae, so 16 bytes.

   From these parameters, K_3ae is computed:

   K_3ae (16 bytes)
   b8 79 9f e3 d1 50 4f d8 eb 22 c4 72 62 cd bb 05

   Nonce IV_3ae is the output
              Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
              2020, <https://www.rfc-editor.org/info/rfc8747>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

9.2.  Informative References

   [Bruni18]  Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and
              C. Schürmann, "Formal Verification of HKDF-Expand(PRK_3e2m, info, L).

   info is defined as follows:

  info Ephemeral Diffie-
              Hellman Over COSE (EDHOC)", November 2018,
              <https://www.springerprofessional.de/en/formal-
              verification-of-ephemeral-diffie-hellman-over-cose-
              edhoc/16284348>.

   [CborMe]   Bormann, C., "CBOR Playground", May 2018,
              <http://cbor.me/>.

   [CNSA]     (Placeholder), ., "Commercial National Security Algorithm
              Suite", August 2015,
              <https://apps.nsa.gov/iaarchive/programs/iad-initiatives/
              cnsa-suite.cfm>.

   [I-D.ietf-core-oscore-edhoc]
              Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S.,
              and G. Selander, "Combining EDHOC and OSCORE", Work in
              Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-01,
              12 July 2021, <https://www.ietf.org/archive/id/draft-ietf-
              core-oscore-edhoc-01.txt>.

   [I-D.ietf-core-resource-directory]
              Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V.
              D. Stok, "CoRE Resource Directory", Work in Progress,
              Internet-Draft, draft-ietf-core-resource-directory-28, 7
              March 2021, <https://www.ietf.org/archive/id/draft-ietf-
              core-resource-directory-28.txt>.

   [I-D.ietf-cose-cbor-encoded-cert]
              Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
              M. Furuhed, "CBOR Encoded X.509 Certificates (C509
              Certificates)", Work in Progress, Internet-Draft, draft-
              ietf-cose-cbor-encoded-cert-02, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-cose-cbor-
              encoded-cert-02.txt>.

   [I-D.ietf-lake-reqs]
              Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia-
              Carrillo, "Requirements for IV_3ae =
  [
    10,
    h'F24D18CAFCE374D4E3736329C152AB3AEA9C7C0F650C3070B6F51E68E2AEBB60',
    "IV_3ae",
    13
  ]

   Which as a CBOR encoded data item is:

 info Lightweight AKE for IV_3ae (CBOR-encoded) (44 bytes)
 84 0a 58 20 f2 4d 18 ca fc e3 74 d4 e3 73 63 29 c1 52 ab 3a ea 9c 7c 0f
 65 0c 30 70 b6 f5 1e 68 e2 ae bb 60 66 49 56 5f 33 61 65 0d

   L is the length of IV_3ae, so 13 bytes.

   From these parameters, IV_3ae is computed:

   IV_3ae (13 bytes)
   74 c7 de 41 b8 4a 5b b7 19 0a 85 98 dc

   Using the parameters above, the 'ciphertext' CIPHERTEXT_3 can be
   computed:

 CIPHERTEXT_3 (CBOR unencoded) (88 bytes)
 f5 f6 de bd 82 14 05 1c d5 83 c8 40 96 c4 80 1d eb f3 5b 15 36 3d d1 6e
 bd 85 30 df dc fb 34 fc d2 eb 6c ad 1d ac 66 a4 79 fb 38 de aa f1 d3 0a
 7e 68 17 a2 2a b0 4f 3d 5b 1e 97 2a 0d 13 ea 86 c6 6b 60 51 4c 96 57 ea
 89 c5 7b 04 01 ed c5 aa 8b bc ab 81 3c c5 d6 e7

   From the parameter above, message_3 is computed, as the CBOR Sequence OSCORE",
              Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04,
              8 June 2020, <https://www.ietf.org/archive/id/draft-ietf-
              lake-reqs-04.txt>.

   [I-D.ietf-lwig-security-protocol-comparison]
              Mattsson, J. P., Palombini, F., and M. Vucinic,
              "Comparison of the following CBOR encoded data items: (C_R, CIPHERTEXT_3).

message_3 =
(
  -24,
  h'F5F6DEBD8214051CD583C84096C4801DEBF35B15363DD16EBD8530DFDCFB34FCD2EB
  6CAD1DAC66A479FB38DEAAF1D30A7E6817A22AB04F3D5B1E972A0D13EA86C66B60514C
  9657EA89C57B0401EDC5AA8BBCAB813CC5D6E7'
)
   Which encodes to the following byte string:

 message_3 (CBOR Sequence) (91 bytes)
 37 58 58 f5 f6 de bd 82 14 05 1c d5 83 c8 40 96 c4 80 1d eb f3 5b 15 36
 3d d1 6e bd 85 30 df dc fb 34 fc d2 eb 6c ad 1d ac 66 a4 79 fb 38 de aa
 f1 d3 0a 7e 68 17 a2 2a b0 4f 3d 5b 1e 97 2a 0d 13 ea 86 c6 6b 60 51 4c
 96 57 ea 89 c5 7b 04 01 ed c5 aa 8b bc ab 81 3c c5 d6 e7

D.1.4.  OSCORE CoAP Security Context Derivation

   From here, the Initiator Protocols", Work in Progress,
              Internet-Draft, draft-ietf-lwig-security-protocol-
              comparison-05, 2 November 2020,
              <https://www.ietf.org/archive/id/draft-ietf-lwig-security-
              protocol-comparison-05.txt>.

   [I-D.ietf-rats-uccs]
              Birkholz, H., O'Donoghue, J., Cam-Winget, N., and the Responder can derive an OSCORE C.
              Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
              Work in Progress, Internet-Draft, draft-ietf-rats-uccs-01,
              12 July 2021, <https://www.ietf.org/archive/id/draft-ietf-
              rats-uccs-01.txt>.

   [I-D.ietf-tls-dtls13]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security Context, using the EDHOC-Exporter interface.

   From TH_3 (DTLS) Protocol Version
              1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
              dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
              drafts/draft-ietf-tls-dtls13-43.txt>.

   [I-D.mattsson-cfrg-det-sigs-with-noise]
              Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
              "Deterministic ECDSA and EdDSA Signatures with Additional
              Randomness", Work in Progress, Internet-Draft, draft-
              mattsson-cfrg-det-sigs-with-noise-02, 11 March 2020,
              <https://www.ietf.org/archive/id/draft-mattsson-cfrg-det-
              sigs-with-noise-02.txt>.

   [I-D.selander-ace-ake-authz]
              Selander, G., Mattsson, J. P., Vucinic, M., Richardson,
              M., and A. Schellenbaum, "Lightweight Authorization for
              Authenticated Key Exchange.", Work in Progress, Internet-
              Draft, draft-selander-ace-ake-authz-03, 4 May 2021,
              <https://www.ietf.org/archive/id/draft-selander-ace-ake-
              authz-03.txt>.

   [Norrman20]
              Norrman, K., Sundararajan, V., and CIPHERTEXT_3, compute the input to the transcript hash
   TH_4 = H( TH_3, CIPHERTEXT_3 ), as a CBOR Sequence A. Bruni, "Formal
              Analysis of these 2 data
   items.

 Input to calculate TH_4 (CBOR Sequence) (124 bytes)
 58 20 f2 4d 18 ca fc e3 74 d4 e3 73 63 29 c1 52 ab 3a ea 9c 7c 0f 65 0c
 30 70 b6 f5 1e 68 e2 ae bb 60 58 58 f5 f6 de bd 82 14 05 1c d5 83 c8 40
 96 c4 80 1d eb f3 5b 15 36 3d d1 6e bd 85 30 df dc fb 34 fc d2 eb 6c ad
 1d ac 66 a4 79 fb 38 de aa f1 d3 0a 7e 68 17 a2 2a b0 4f 3d 5b 1e 97 2a
 0d 13 ea 86 c6 6b 60 51 4c 96 57 ea 89 c5 7b 04 01 ed c5 aa 8b bc ab 81
 3c c5 d6 e7

   And from there, compute the transcript hash TH_4 = SHA-256(TH_3 ,
   CIPHERTEXT_4)

 TH_4 (CBOR unencoded) (32 bytes)
 3b 69 a6 7f ec 7e 73 6c c1 a9 52 6c da 00 02 d4 09 f5 b9 ea 0a 2b e9 60
 51 a6 e3 0d 93 05 fd 51

   The Master Secret and Master Salt are derived as follows:

   Master Secret = EDHOC-Exporter( "OSCORE Master Secret", 16 ) = EDHOC-
   KDF(PRK_4x3m, TH_4, "OSCORE Master Secret", 16) = HKDF-Expand(
   PRK_4x3m, info_ms, 16 )

   Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 ) = EDHOC-
   KDF(PRK_4x3m, TH_4, "OSCORE Master Salt", 8) = HKDF-Expand( PRK_4x3m,
   info_salt, 8 )

   info_ms EDHOC Key Establishment for OSCORE Master Secret is defined as follows:

  info_ms = [
    10,
    h'3B69A67FEC7E736CC1A9526CDA0002D409F5B9EA0A2BE96051A6E30D9305FD51',
    "OSCORE Master Secret",
    16
  ]

   Which as a CBOR encoded data item is:

 info_ms Constrained IoT
              Devices", September 2020,
              <https://arxiv.org/abs/2007.11427>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for OSCORE Master Secret (CBOR-encoded) (58 bytes)
 84 0a 58 20 3b 69 a6 7f ec 7e 73 6c c1 a9 52 6c da 00 02 d4 09 f5 b9 ea
 0a 2b e9 60 51 a6 e3 0d 93 05 fd 51 74 4f 53 43 4f 52 45 20 4d 61 73 74
 65 72 20 53 65 63 72 65 74 10

   info_salt
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8937]  Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
              and C. Wood, "Randomness Improvements for OSCORE Master Salt is defined as follows:

  info_salt = [
    10,
    h'3B69A67FEC7E736CC1A9526CDA0002D409F5B9EA0A2BE96051A6E30D9305FD51',
    "OSCORE Master Salt",
    8
  ]

   Which as a CBOR encoded data item is:

 info Security
              Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
              <https://www.rfc-editor.org/info/rfc8937>.

   [SECG]     "Standards for OSCORE Master Salt (CBOR-encoded) (56 Bytes)
 84 0a 58 20 3b 69 a6 7f ec 7e 73 6c c1 a9 52 6c da 00 02 d4 09 f5 b9 ea
 0a 2b e9 60 51 a6 e3 0d 93 05 fd 51 72 4f 53 43 4f 52 45 20 4d 61 73 74
 65 72 20 53 61 6c 74 08

   From these parameters, OSCORE Master Secret Efficient Cryptography 1 (SEC 1)", May
              2009, <https://www.secg.org/sec1-v2.pdf>.

   [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., Vassilev, A., and R.
              Davis, "Recommendation for Pair-Wise Key-Establishment
              Schemes Using Discrete Logarithm Cryptography",
              NIST Special Publication 800-56A Revision 3, April 2018,
              <https://doi.org/10.6028/NIST.SP.800-56Ar3>.

Appendix A.  Use with OSCORE Master Salt
   are computed:

   OSCORE Master Secret (16 bytes)
   96 aa 88 ce 86 5e ba 1f fa f3 89 64 13 2c c4 42 and Transfer over CoAP

   This appendix describes how to select EDHOC connection identifiers
   and derive an OSCORE Master Salt (8 bytes)
   5e c3 ee 41 7c fb ba e9

   The client's security context when OSCORE Sender ID is C_R used with EDHOC,
   and the server's how to transfer EDHOC messages over CoAP.

A.1.  Selecting EDHOC Connection Identifier

   This section specifies a rule for converting from EDHOC connection
   identifier to OSCORE Sender
   ID Sender/Recipient ID.  (An identifier is C_I.

   Client's OSCORE Sender
   ID (1 byte)
   00

   Server's OSCORE Sender or Recipient ID (1 byte)
   09
   The AEAD Algorithm and the hash algorithm are the application AEAD
   and hash algorithms in depending on from which endpoint is the point of
   view, see Section 3.1 of [RFC8613].)

   *  If the selected cipher suite.

   OSCORE AEAD Algorithm (int)
   10

   OSCORE Hash Algorithm (int)
   -16

D.2.  Test Vectors for EDHOC Authenticated with Static Diffie-Hellman
      Keys EDHOC with static Diffie-Hellman keys and raw public keys connection identifier is used.
   In this test vector, numeric, i.e., encoded as a key identifier
      CBOR integer on the wire, it is used converted to identify the raw
   public key.  The optional C_1 a (naturally byte-
      string shaped) OSCORE Sender/Recipient ID equal to its CBOR
      encoded form.

   For example, a numeric C_R equal to 10 (0x0A in message_1 is omitted.  No external
   authorization data CBOR encoding) is sent
   converted to a (typically client) Sender ID equal to 0x0A, while a
   numeric C_I equal to -12 (0x2B in the message exchange.

   method (Static DH Based Authentication)
   3

   CoAP CBOR encoding) is used as transport and the Initiator acts as CoAP client:

   corr (the Initiator can correlate message_1 and message_2)
   1

   From there, METHOD_CORR has the following value:

   METHOD_CORR (4 converted to a
   (typically client) Sender ID equal to 0x2B.

   * method + corr) (int)
   13

   The Initiator indicates only one cipher suite in the (potentially
   truncated) list of cipher suites.

   Supported Cipher Suites (1 byte)
   00

   The Initiator selected the indicated cipher suite.

   Selected Cipher Suite (int)
   0

   Cipher suite 0 is supported by both the Initiator and  If the Responder,
   see Section 3.6.

D.2.1.  Message_1

   The Initiator generates its ephemeral key pair.

 X (Initiator's ephemeral private key) (32 bytes)
 ae 11 a0 db 86 3c 02 27 e5 39 92 fe b8 f5 92 4c 50 d0 a7 ba 6e ea b4 ad
 1f f2 45 72 f4 f5 7c fa

 G_X (Initiator's ephemeral public key, CBOR unencoded) (32 bytes)
 8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 a5 38 a4 44
 ee 9e 2b 57 e2 44 1a 7c

   The Initiator chooses a EDHOC connection identifier C_I:

   Connection identifier chosen by Initiator (1 byte)
   16

   Note that since C_I is byte-valued, hence encoded
      as a CBOR byte string in on the interval h'00' to h'2f', wire, it is encoded as converted to an OSCORE
      Sender/Recipient ID equal to the corresponding integer - 24, i.e. 0x16 = 22, 22 -
   24 = -2, and -2 byte string.

   For example, a byte-string valued C_R equal to 0xFF (0x41FF in CBOR encoding
   encoding) is converted to a (typically client) Sender ID equal to 0x21.

   C_I (1 byte)
   21

   Since no external authorization data is sent:

   EAD_1 (0 bytes)

   Since
   0xFF.

   Two EDHOC connection identifiers are called "equivalent" if and only
   if, by applying the list of supported cipher suites needs to contain conversion above, they both result in the
   selected cipher suite, same
   OSCORE Sender/Recipient ID.  For example, the initiator truncates two EDHOC connection
   identifiers with CBOR encoding 0x0A (numeric) and 0x410A (byte-
   valued) are equivalent since they both result in the list of supported
   cipher suites to one cipher suite only, 00.

   Because one single selected cipher suite is conveyed, it same OSCORE
   Sender/Recipient ID 0x0A.

   When EDHOC is encoded
   as an int instead of used to establish an array:

   SUITES_I (int)
   0

   message_1 is constructed as OSCORE security context, the CBOR Sequence
   connection identifiers C_I and C_R MUST NOT be equivalent.
   Furthermore, in case of multiple OSCORE security contexts with
   potentially different endpoints, to facilitate retrieval of the data items above
   encoded as CBOR.  In CBOR diagnostic notation:

  message_1 =
  (
    13,
    0,
    h'8D3EF56D1B750A4351D68AC250A0E883790EFC80A538A444EE9E2B57E2441A7C',
    -2
  )
   Which as a CBOR encoded data item is:

 message_1 (CBOR Sequence) (37 bytes)
 0d 00 58 20 8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80
 a5 38 a4 44 ee 9e 2b 57 e2 44 1a 7c 21

D.2.2.  Message_2

   Since METHOD_CORR mod 4 equals 1, C_I is omitted from data_2.

   The Responder generates
   correct OSCORE security context, an endpoint SHOULD select an EDHOC
   connection identifier that when converted to OSCORE Recipient ID does
   not coincide with its other Recipient IDs.

A.2.  Deriving the following ephemeral key pair.

 Y (Responder's ephemeral private key) (32 bytes)
 c6 46 cd dc 58 12 6e 18 10 5f 01 ce 35 05 6e 5e bc 35 f4 d4 cc 51 07 49
 a3 a5 e0 69 c1 16 16 9a

 G_Y (Responder's ephemeral public key, CBOR unencoded) (32 bytes)
 52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33
 01 04 70 69 45 1b af 35

   From G_X OSCORE Security Context

   This section specifies how to use EDHOC output to derive the OSCORE
   security context.

   After successful processing of EDHOC message_3, Client and Y or from G_Y Server
   derive Security Context parameters for OSCORE as follows (see
   Section 3.2 of [RFC8613]):

   *  The Master Secret and X Master Salt are derived by using the ECDH shared secret is computed:

 G_XY (ECDH shared secret) (32 bytes)
 de fc 2f 35 69 10 9b 3d 1f a4 a7 3d c5 e2 fe b9 e1 15 0d 90 c2 5e e2 f0
 66 c2 d8 85 f4 f8 ac 4e EDHOC-
      Exporter interface, see Section 4.3.

   The key and nonce EDHOC Exporter Labels for calculating deriving the 'ciphertext' OSCORE Master Secret and
   the OSCORE Master Salt, are calculated as
   follows, as specified in Section 4.

   HKDF SHA-256 "OSCORE Master Secret" and "OSCORE Master
   Salt", respectively.

   The context parameter is h'' (0x40), the HKDF used (as defined by empty CBOR byte string.

   By default, key_length is the key length (in bytes) of the
   application AEAD Algorithm of the selected cipher suite 0).

   PRK_2e for the EDHOC
   session.  Also by default, salt_length has value 8.  The Initiator
   and Responder MAY agree out-of-band on a longer key_length than the
   default and on a different salt_length.

  Master Secret = HMAC-SHA-256(salt, G_XY) EDHOC-Exporter( "OSCORE Master Secret", , key_length )
  Master Salt   = EDHOC-Exporter( "OSCORE Master Salt", , salt_length )

   *  The AEAD Algorithm is the empty byte string.

   salt (0 bytes)

   From there, PRK_2e is computed:

 PRK_2e (32 bytes)
 93 9f cb 05 6d 2e 41 4f 1b ec 61 04 61 99 c2 c7 63 d2 7f 0c 3d 15 fa 16
 71 fa 13 4e 0d c5 a0 4d application AEAD algorithm of the
      selected cipher suite for the EDHOC session.

   *  The Responder's static Diffie-Hellman key pair HKDF Algorithm is the following:

 R (Responder's private authentication key) (32 bytes)
 bb 50 1a ac 67 b9 a9 5f 97 e0 ed ed 6b 82 a6 62 93 4f bb fc 7a d1 b7 4c
 1f ca d6 6a 07 94 22 d0
 G_R (Responder's public authentication key) (32 bytes)
 a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04 da d2 d4 09 66 ac 6b cb 62 20 51
 b8 46 59 18 4d 5d 9a 32

   Since one based on the application hash
      algorithm of the selected cipher suite for the EDHOC session.  For
      example, if SHA-256 is the Responder authenticates with a static Diffie-Hellman key,
   PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX application hash algorithm of the
      selected ciphersuite, HKDF SHA-256 is used as HKDF Algorithm in
      the ECDH
   shared secret calculated from G_R and X, or G_X OSCORE Security Context.

   *  In case the Client is Initiator and R.

   From the Responder's authentication key Server is Responder, the
      Client's OSCORE Sender ID and the Initiator's ephemeral
   key (see Appendix D.2.1), Server's OSCORE Sender ID are
      determined from the ECDH shared secret G_RX is calculated.

 G_RX (ECDH shared secret) (32 bytes)
 21 c7 ef f4 fb 69 fa 4b 67 97 d0 58 84 31 5d 84 11 a3 fd a5 4f 6d ad a6
 1d 4f cd 85 e7 90 66 68

 PRK_3e2m (32 bytes)
 75 07 7c 69 1e 35 01 2d 48 bc 24 c8 4f 2b ab 89 f5 2f ac 03 fe dd 81 3e
 43 8c 93 b1 0b 39 93 07

   The Responder chooses a EDHOC connection identifier C_R.

   Connection identifier chosen by Responder (1 byte)
   00

   Note that since identifiers C_R is a byte string and C_I for
      the EDHOC session, respectively, by applying the conversion in
      Appendix A.1.  The reverse applies in case the interval h'00' to h'2f',
   it Client is encoded as the corresponding integer - 24, i.e. 0x00 = 0, 0 -
   24 = -24,
      Responder and -24 in CBOR encoding is equal to 0x37.

   C_R (1 byte)
   37

   Data_2 the Server is constructed as the CBOR Sequence of G_Y Initiator.

   Client and C_R.

  data_2 =
  (
    h'52FBA0BDC8D953DD86CE1AB2FD7C05A4658C7C30AFDBFC3301047069451BAF35',
    -24
  )

   Which Server use the parameters above to establish an OSCORE
   Security Context, as a CBOR encoded data item is:

 data_2 (CBOR Sequence) (35 bytes)
 58 20 52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db
 fc 33 01 04 70 69 45 1b af 35 37 per Section 3.2.1 of [RFC8613].

   From data_2 then on, Client and message_1, compute Server retrieve the input to OSCORE protocol state
   using the transcript hash
   TH_2 = H( H(message_1), data_2 ), Recipient ID, and optionally other transport information
   such as the 5-tuple.

A.3.  Transferring EDHOC over CoAP

   This section specifies one instance for how EDHOC can be transferred
   as a CBOR Sequence an exchange of these 2 data
   items.

 Input CoAP [RFC7252] messages.  CoAP is a reliable
   transport that can preserve packet ordering and handle message
   duplication.  CoAP can also perform fragmentation and protect against
   denial-of-service attacks.  According to calculate TH_2 (CBOR Sequence) (72 bytes)
 0d 00 58 20 8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80
 a5 38 a4 44 ee 9e 2b 57 e2 44 1a 7c 21 58 20 52 fb a0 bd c8 d9 53 dd 86
 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33 01 04 70 69 45 1b af 35 37

   And from there, compute the transcript hash TH_2 = SHA-256(
   H(message_1), data_2 )

 TH_2 (CBOR unencoded) (32 bytes)
 de cf d6 4a 36 67 64 0a 02 33 b0 4a a8 aa 91 f6 89 56 b8 a5 36 d0 cf 8c
 73 a6 e8 a7 c3 62 1e 26

   The Responder's subject name this specification, EDHOC
   messages are carried in Confirmable messages, which is beneficial
   especially if fragmentation is used.

   By default, the empty string:

   Responder's subject name (text string)
   ""

   ID_CRED_R CoAP client is the following:

   ID_CRED_R =
   {
     4: h'05'
   }

   ID_CRED_R (4 bytes)
   a1 04 41 05

   CRED_R Initiator and the CoAP server is
   the following COSE_Key:

{
  1: 1,
 -1: 4,
 -2: h'A3FF263595BEB377D1A0CE1D04DAD2D40966AC6BCB622051B84659184D5D9A32,
  "subject name": ""
}

   Which encodes to Responder, but the following byte string:

 CRED_R (54 bytes)
 a4 01 01 20 04 21 58 20 a3 ff 26 35 95 roles SHOULD be b3 77 d1 a0 ce 1d 04 da d2 d4
 09 66 ac 6b cb 62 20 51 b8 46 59 18 4d 5d 9a 32 6c 73 75 62 6a 65 63 74
 20 6e 61 6d 65 60

   Since no external authorization data is sent:

   EAD_2  (0 bytes)

   The plaintext chosen to protect the most
   sensitive identity, see Section 7.  According to this specification,
   EDHOC is defined as transferred in POST requests and 2.04 (Changed) responses to
   the empty string:

   P_2m (0 bytes)

   The Enc_structure Uri-Path: "/.well-known/edhoc".  An application may define its
   own path that can be discovered, e.g., using resource directory
   [I-D.ietf-core-resource-directory].

   By default, the message flow is defined as follows: [ "Encrypt0",
   << ID_CRED_R >>, << TH_2, CRED_R >> ], so ID_CRED_R 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 encoded as a
   CBOR bstr, and
   sent from the concatenation server to the client in the payload of a 2.04 (Changed)
   response.  EDHOC message_3 or the CBOR byte strings TH_2 and
   CRED_R EDHOC error message is wrapped sent from
   the client to the server's resource in the payload of a CBOR bstr.

 A_2m =
 [
   "Encrypt0",
   h'A1044105',
   h'5820DECFD64A3667640A0233B04AA8AA91F68956B8A536D0CF8C73A6E8A7C3621E2
   6A401012004215820A3FF263595BEB377D1A0CE1D04DAD2D40966AC6BCB622051B846
   59184D5D9A326C7375626A656374206E616D6560'
 ]

   Which encodes to POST request.
   If needed, an EDHOC error message is sent from the following byte string server to be used as Additional
   Authenticated Data:

 A_2m (CBOR-encoded) (105 bytes)
 83 68 45 6e 63 72 79 70 74 30 44 a1 04 41 05 58 58 58 20 de cf d6 4a 36
 67 64 0a 02 33 b0 4a a8 aa 91 f6 89 56 b8 a5 36 d0 cf 8c 73 a6 e8 a7 c3
 62 1e 26 a4 01 01 20 04 21 58 20 a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04
 da d2 d4 09 66 ac 6b cb 62 20 51 b8 46 59 18 4d 5d 9a 32 6c 73 75 62 6a
 65 63 74 20 6e 61 6d 65 60

   info for K_2m is defined as follows:

  info for K_2m =
  [
    10,
    h'DECFD64A3667640A0233B04AA8AA91F68956B8A536D0CF8C73A6E8A7C3621E26',
    "K_2m",
    16
  ]

   Which as the
   client in the payload of a CBOR encoded data item is:

 info for K_2m (CBOR-encoded) (42 bytes)
 84 0a 58 20 de cf d6 4a 36 67 64 0a 02 33 b0 4a a8 aa 91 f6 89 56 b8 a5
 36 d0 cf 8c 73 a6 e8 a7 c3 62 1e 26 64 4b 5f 32 6d 10

   From these parameters, K_2m 2.04 (Changed) response.  Alternatively,
   if EDHOC message_4 is computed.  Key K_2m used, it is sent from the output of
   HKDF-Expand(PRK_3e2m, info, L), where L is server to the length client
   in the payload of K_2m, so 16
   bytes.

   K_2m (16 bytes)
   4e cd ef ba d8 06 81 8b 62 51 b9 d7 86 78 bc 76
   info for IV_2m is defined as follows:

  info for IV_2m =
  [
    10,
    h'A51C76463E8AE58FD3B8DC5EDE1E27143CC92D223EACD9E5FF6E3FAC876658A5',
    "IV_2m",
    13
  ]

   Which as a 2.04 (Changed) response analogously to message_2.

   In order to correlate a message received from a client to a message
   previously sent by the server, messages sent by the client are
   prepended with the CBOR encoded data item is:

 info for IV_2m (CBOR-encoded) (43 bytes)
 84 0a 58 20 de cf d6 4a 36 67 64 0a 02 33 b0 4a a8 aa 91 f6 89 56 b8 a5
 36 d0 cf 8c 73 a6 e8 a7 c3 62 1e 26 65 49 56 5f 32 6d 0d

   From these parameters, IV_2m serialization of the connection identifier
   which the server has chosen.  This applies independently of if the
   CoAP server is computed.  IV_2m Responder or Initiator.  For the default case when the
   server is Responder, the output of
   HKDF-Expand(PRK_3e2m, info, L), where L prepended connection identifier is C_R, and
   C_I if the length of IV_2m, so 13
   bytes.

   IV_2m (13 bytes)
   e9 b8 e4 b1 bd 02 f4 9a 82 0d d3 53 4f

   Finally, COSE_Encrypt0 server is computed from Initiator.  If message_1 is sent to the parameters above.

   o  protected header = CBOR-encoded ID_CRED_R

   o  external_aad = A_2m

   o  empty plaintext = P_2m

   MAC_2 server,
   the CBOR simple value "true" (0xf5) is sent in its place (given that
   the 'ciphertext' server has not selected C_R yet).

   These identifiers are encoded in CBOR and thus self-delimiting.  They
   are sent in front of the COSE_Encrypt0 with empty plaintext.
   In case actual EDHOC message, and only the part of cipher suite 0
   the AEAD is AES-CCM truncated to 8 bytes:

   MAC_2 (CBOR unencoded) (8 bytes)
   42 e7 99 78 43 1e 6b 8f

   Since method = 2, Signature_or_MAC_2 is MAC_2:

   Signature_or_MAC_2 (CBOR unencoded) (8 bytes)
   42 e7 99 78 43 1e 6b 8f

   CIPHERTEXT_2 is body following the ciphertext resulting from XOR between plaintext
   and KEYSTREAM_2 which identifier is derived from TH_2 and used for EDHOC processing.

   Consequently, the pseudorandom key
   PRK_2e.

   The plaintext application/edhoc media type does not apply to
   these messages; their media type is the CBOR Sequence unnamed.

   An example of a successful EDHOC exchange using CoAP is shown in
   Figure 9.  In this case the items ID_CRED_R CoAP Token enables correlation on the
   Initiator side, and the
   CBOR encoded Signature_or_MAC_2, prepended C_R enables correlation on the
   Responder (server) side.

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

      Figure 9: Transferring EDHOC in this order (EAD_2 is empty).

   Note that since ID_CRED_R contains a single 'kid' parameter, i.e.,
   ID_CRED_R = { 4 : kid_R }, only CoAP when the byte string kid_R Initiator is conveyed CoAP
                                   Client

   The exchange in Figure 9 protects the plaintext encoded as a bstr_identifier. kid_R is encoded as the
   corresponding integer - 24, i.e. 0x05 = 5, 5 - 24 = -19, client identity against active
   attackers and -19 in
   CBOR encoding is equal to 0x32.

   The plaintext is the following:

   P_2e (CBOR Sequence) (10 bytes)
   32 48 42 e7 99 78 43 1e 6b 8f

   KEYSTREAM_2 = HKDF-Expand( PRK_2e, info, length ), where length is
   the length of the plaintext, so 10.

  info for KEYSTREAM_2 =
  [
    10,
    h'DECFD64A3667640A0233B04AA8AA91F68956B8A536D0CF8C73A6E8A7C3621E26',
    "KEYSTREAM_2",
    10
  ]

   Which as a CBOR encoded data item is:

 info for KEYSTREAM_2 (CBOR-encoded) (49 bytes)
 84 0a 58 20 de cf d6 4a 36 67 64 0a 02 33 b0 4a a8 aa 91 f6 89 56 b8 a5
 36 d0 cf 8c 73 a6 e8 a7 c3 62 1e 26 6b 4b 45 59 53 54 52 45 41 4d 5f 32
 0a

   From there, KEYSTREAM_2 is computed:

   KEYSTREAM_2 (10 bytes)
   91 b9 ff ba 9b f5 5a d1 57 16

   Using server identity against passive attackers.

   An alternative exchange that protects the parameters above, server identity against
   active attackers and the ciphertext CIPHERTEXT_2 can be
   computed:

   CIPHERTEXT_2 (CBOR unencoded) (10 bytes)
   a3 f1 bd 5d 02 8d 19 cf 3c 99

   message_2 client identity against passive attackers is the CBOR Sequence of data_2 and CIPHERTEXT_2,
   shown in Figure 10.  In this
   order:

   message_2 =
   (
    data_2,
    h'A3F1BD5D028D19CF3C99'
   )
   Which as a CBOR encoded data item is:

 message_2 (CBOR Sequence) (46 bytes)
 58 20 52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db
 fc 33 01 04 70 69 45 1b af 35 37 4a a3 f1 bd 5d 02 8d 19 cf 3c 99

D.2.3.  Message_3

   Since corr equals 1, C_R is not omitted from data_3.

   The Initiator's static Diffie-Hellman key pair is the following:

 I (Initiator's private authentication key) (32 bytes)
 2b be a6 55 c2 33 71 c3 29 cf bd 3b 1f 02 c6 c0 62 03 38 37 b8 b5 90 99
 a4 43 6f 66 60 81 b0 8e

 G_I (Initiator's public authentication key, CBOR unencoded) (32 bytes)
 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae da fe 9c aa 4f 4e 7a bb 83 5e c3
 0f 1d e8 8a db 96 ff 71

   HKDF SHA-256 is case the HKDF used (as defined by cipher suite 0).

   From CoAP Token enables the Initiator's authentication key
   Responder to correlate message_2 and message_3, and the Responder's ephemeral
   key (see Appendix D.2.2), prepended C_I
   enables correlation on the ECDH shared secret G_IY Initiator (server) side.  If EDHOC
   message_4 is calculated.

 G_IY (ECDH shared secret) (32 bytes)
 cb ff 8c d3 4a 81 df ec 4c b6 5d 9a 57 2e bd 09 64 45 0c 78 56 3d a4 98
 1d 80 d3 6c 8b 1a 75 2a

   PRK_4x3m = HMAC-SHA-256 (PRK_3e2m, G_IY).

 PRK_4x3m (32 bytes)
 02 56 2f 1f 01 78 5c 0a a5 f5 94 64 0c 49 cb f6 9f 72 2e 9e 6c 57 83 7d
 8e 15 79 ec 45 fe 64 7a

   data 3 used, C_I is equal to C_R.

   data_3 (CBOR Sequence) (1 byte)
   37

   From data_3, CIPHERTEXT_2, prepended, and TH_2, compute the input to it is transported with CoAP
   in the
   transcript hash TH_3 = H( H(TH_2 , CIPHERTEXT_2), data_3), as a CBOR
   Sequence payload of these 2 data items.

 Input to calculate TH_3 (CBOR Sequence) (46 bytes)
 58 20 de cf d6 4a 36 67 64 0a 02 33 b0 4a a8 aa 91 f6 89 56 b8 a5 36 d0
 cf 8c 73 a6 e8 a7 c3 62 1e 26 4a a3 f1 bd 5d 02 8d 19 cf 3c 99 37
   And from there, compute the transcript hash TH_3 = SHA-256( H(TH_2 ,
   CIPHERTEXT_2), data_3)

 TH_3 (CBOR unencoded) (32 bytes)
 b6 cd 80 4f c4 b9 d7 ca c5 02 ab d7 7c da 74 e4 1c b0 11 82 d7 cb 8b 84
 db 03 ff a5 83 a3 5f cb

   The initiator's subject name is a POST request with a 2.04 (Changed) response.

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

      Figure 10: Transferring EDHOC in CoAP when the empty string:

   Initiator's subject name (text string)
   ""

   And its credential is:

   ID_CRED_I =
   {
     4: h'23'
   }

   ID_CRED_I (4 bytes)
   a1 04 41 23

   CRED_I Initiator is CoAP
                                   Server

   To protect against denial-of-service attacks, the following COSE_Key:

{
 1:1,
 -1:4,
 -2:h'2C440CC121F8D7F24C3B0E41AEDAFE9CAA4F4E7ABB835EC30F1DE88ADB96FF71',
 "subject name":""
 }

   Which encodes CoAP server MAY
   respond to the following byte string:

 CRED_I (54 bytes)
 a4 01 01 20 04 21 58 20 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae da fe 9c
 aa 4f 4e 7a bb 83 5e c3 0f 1d e8 8a db 96 ff 71 6c 73 75 62 6a 65 63 74
 20 6e 61 6d 65 60

   Since no external authorization data is exchanged:

   EAD_3 (0 bytes)

   The plaintext of first POST request with a 4.01 (Unauthorized)
   containing an Echo option [I-D.ietf-core-echo-request-tag].  This
   forces the COSE_Encrypt initiator to demonstrate its reachability at its apparent
   network address.  If message fragmentation is needed, the empty string:

   P_3m (0 bytes)

   The associated data is EDHOC
   messages may be fragmented using the following: [ "Encrypt0", << ID_CRED_I >>,
   << TH_3, CRED_I, ? EAD_3 >> ].

 A_3m (CBOR-encoded) (105 bytes)
 83 68 45 6e 63 72 79 70 74 30 44 a1 04 41 23 58 58 58 20 b6 cd 80 4f c4
 b9 d7 ca c5 02 ab d7 7c da 74 e4 1c b0 11 82 d7 cb 8b 84 db 03 ff a5 83
 a3 5f cb a4 01 01 20 04 21 58 20 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae
 da fe 9c aa 4f 4e 7a bb 83 5e c3 0f 1d e8 8a db 96 ff 71 6c 73 75 62 6a
 65 63 74 20 6e 61 6d 65 60

   Info for K_3m is computed CoAP Block-Wise Transfer
   mechanism [RFC7959].

   EDHOC does not restrict how error messages are transported with CoAP,
   as follows:

  info for K_3m =
  [
    10,
    h'B6CD804FC4B9D7CAC502ABD77CDA74E41CB01182D7CB8B84DB03FFA583A35FCB',
    "K_3m",
    16
  ]

   Which long as the appropriate error message can to be transported in
   response to a CBOR encoded data item is:

 info message that failed (see Section 6).  EDHOC error
   messages transported with CoAP are carried in the payload.

A.3.1.  Transferring EDHOC and OSCORE over CoAP

   When using EDHOC over CoAP for K_3m (CBOR-encoded) (42 bytes)
 84 0a 58 20 b6 cd 80 4f c4 b9 d7 ca c5 02 ab d7 7c da 74 e4 1c b0 11 82
 d7 cb 8b 84 db 03 ff a5 83 a3 5f cb 64 4b 5f 33 6d 10

   From these parameters, K_3m establishing an OSCORE Security
   Context, EDHOC error messages sent as CoAP responses MUST be sent in
   the payload of error responses, i.e., they MUST specify a CoAP error
   response code.  In particular, it is computed.  Key K_3m RECOMMENDED that such error
   responses have response code either 4.00 (Bad Request) in case of
   client error (e.g., due to a malformed EDHOC message), or 5.00
   (Internal Server Error) in case of server error (e.g., due to failure
   in deriving EDHOC key material).  The Content-Format of the error
   response MUST be set to application/edhoc.

   A method for combining EDHOC and OSCORE protocols in two round-trips
   is specified in [I-D.ietf-core-oscore-edhoc].

Appendix B.  Compact Representation

   As described in Section 4.2 of [RFC6090] the output x-coordinate of
   HKDF-Expand(PRK_4x3m, info, L), where L an
   elliptic curve public key is a suitable representative for the length of K_2m, so 16
   bytes.

   K_3m (16 bytes)
   02 c7 e7 93 89 9d 90 d1 28 28 10 26 96 94 c9 58

   Nonce IV_3m entire
   point whenever scalar multiplication is used as a one-way function.
   One example is ECDH with compact output, where only the output x-coordinate
   of HKDF-Expand(PRK_4x3m, info, L), where L
   = 13 bytes.

   Info for IV_3m the computed value is defined as follows:

  info for IV_3m =
  [
    10,
    h'B6CD804FC4B9D7CAC502ABD77CDA74E41CB01182D7CB8B84DB03FFA583A35FCB',
    "IV_3m",
    13
  ]

   Which used as the shared secret.

   This section defines a CBOR encoded data item is:

 info format for IV_3m (CBOR-encoded) (43 bytes)
 84 0a 58 20 b6 cd 80 4f c4 b9 d7 ca c5 02 ab d7 7c da 74 e4 1c b0 11 82
 d7 cb 8b 84 db 03 ff a5 83 a3 5f cb 65 49 56 5f 33 6d 0d
   From these parameters, IV_3m is computed:

   IV_3m (13 bytes)
   0d a7 cc 3a 6f 9a b2 48 52 ce 8b 37 a6

   MAC_3 is compact representation based on the 'ciphertext'
   Elliptic-Curve-Point-to-Octet-String Conversion defined in
   Section 2.3.3 of [SECG].  Using the COSE_Encrypt0 with empty plaintext.
   In case of cipher suite 0 notation from [SECG], the AEAD output
   is AES-CCM truncated an octet string of length ceil( (log2 q) / 8 ).  See [SECG] for a
   definition of q, M, X, xp, and ~yp.  The steps in Section 2.3.3 of
   [SECG] are replaced by:

   1.  Convert the field element xp to an octet string X of length ceil(
       (log2 q) / 8 bytes:

   MAC_3 (CBOR unencoded) (8 bytes)
   ee 59 8e a6 61 17 dc c3

   Since method ) octets using the conversion routine specified in
       Section 2.3.5 of [SECG].

   2.  Output M = 3, Signature_or_MAC_3 is MAC_3:

   Signature_or_MAC_3 (CBOR unencoded) (8 bytes)
   ee 59 8e a6 61 17 dc c3

   Finally, X

   The encoding of the outer COSE_Encrypt0 point at infinity is computed.

   The plaintext not supported.  Compact
   representation does not change any requirements on validation.  If a
   y-coordinate is required for validation or compatibily with APIs the CBOR Sequence of
   value ~yp SHALL be set to zero.  For such use, the compact
   representation can be transformed into the items ID_CRED_I and SECG point compressed
   format by prepending it with the
   CBOR encoded Signature_or_MAC_3, in this order (EAD_3 is empty).

   Note that since ID_CRED_I contains a single 'kid' parameter, i.e.,
   ID_CRED_I byte 0x02 (i.e., M = { 4 : kid_I }, only 0x02 ||
   X).

   Using compact representation have some security benefits.  An
   implementation does not need to check that the byte string kid_I point is conveyed in not the plaintext encoded point
   at infinity (the identity element).  Similarly, as a bstr_identifier. kid_I not even the sign
   of the y-coordinate is encoded as encoded, compact representation trivially
   avoids so called "benign malleability" attacks where an attacker
   changes the
   corresponding integer - 24, i.e. 0x23 = 35, 35 - 24 = 11, sign, see [SECG].

Appendix C.  Use of CBOR, CDDL and 11 COSE in
   CBOR encoding EDHOC

   This Appendix is equal intended to 0x0b.

   P_3ae (CBOR Sequence) (10 bytes)
   0b 48 ee 59 8e a6 61 17 dc c3 simplify for implementors not familiar
   with CBOR [RFC8949], CDDL [RFC8610], COSE
   [I-D.ietf-cose-rfc8152bis-struct], and HKDF [RFC5869].

C.1.  CBOR and CDDL

   The Associated data A is the following: Associated data A = [
   "Encrypt0", h'', TH_3 ]

 A_3ae (CBOR-encoded) (45 bytes)
 83 68 45 6e 63 72 79 70 74 30 40 58 20 b6 cd 80 4f c4 b9 d7 ca c5 02 ab
 d7 7c da 74 e4 1c b0 11 82 d7 cb 8b 84 db 03 ff a5 83 a3 5f cb

   Key K_3ae is the output of HKDF-Expand(PRK_3e2m, info, L).

   info Concise Binary Object Representation (CBOR) [RFC8949] is defined as follows:

  info for K_3ae =
  [
    10,
    h'B6CD804FC4B9D7CAC502ABD77CDA74E41CB01182D7CB8B84DB03FFA583A35FCB',
    "K_3ae",
    16
  ]
   Which as a CBOR encoded data item is:

 info
   format designed for K_3ae (CBOR-encoded) (43 bytes)
 84 0a 58 20 b6 cd 80 4f c4 b9 d7 ca c5 02 ab d7 7c da 74 e4 1c b0 11 82
 d7 cb 8b 84 db 03 ff a5 83 a3 5f cb 65 4b 5f 33 61 65 10

   L is small code size and small message size.  CBOR
   builds on the length of K_3ae, so 16 bytes.

   From these parameters, K_3ae is computed:

   K_3ae (16 bytes)
   6b a4 c8 83 1d e3 ae 23 e9 8e f7 35 08 d0 95 86

   Nonce IV_3ae is JSON data model but extends it by e.g., encoding binary
   data directly without base64 conversion.  In addition to the output of HKDF-Expand(PRK_3e2m, info, L).

   info binary
   CBOR encoding, CBOR also has a diagnostic notation that is defined as follows:

  info for IV_3ae =
  [
    10,
    h'97D8AD42334833EB25B960A5EB0704505F89671A0168AA1115FAF92D9E67EF04',
    "IV_3ae",
    13
  ]

   Which as readable
   and editable by humans.  The Concise Data Definition Language (CDDL)
   [RFC8610] provides a way to express structures for protocol messages
   and APIs that use CBOR.  [RFC8610] also extends the diagnostic
   notation.

   CBOR encoded data item is:

 info for IV_3ae (CBOR-encoded) (44 bytes)
 84 0a 58 20 b6 cd 80 4f c4 b9 d7 ca c5 02 ab d7 7c da 74 e4 1c b0 11 82
 d7 cb 8b 84 db 03 ff a5 83 a3 5f cb 66 49 56 5f 33 61 65 0d

   L is items are encoded to or decoded from byte strings using a
   type-length-value encoding scheme, where the length three highest order bits
   of IV_3ae, so 13 bytes.

   From these parameters, IV_3ae is computed:

   IV_3ae (13 bytes)
   6c 6d 0f e1 1e 9a 1a f3 7b 87 84 55 10

   Using the parameters above, the 'ciphertext' CIPHERTEXT_3 can be
   computed:

   CIPHERTEXT_3 (CBOR unencoded) (18 bytes)
   d5 53 5f 31 47 e8 5f 1c fa cd 9e 78 ab f9 e0 a8 1b bf

   From the parameter above, message_3 is computed, as initial byte contain information about the major type.  CBOR Sequence
   supports several different types of data items, in addition to
   integers (int, uint), simple values, byte strings (bstr), and text
   strings (tstr), CBOR also supports arrays [] of data items, maps {}
   of pairs of data items, and sequences [RFC8742] of data items.  Some
   examples are given below.

   For a complete specification and more examples, see [RFC8949] and
   [RFC8610].  We recommend implementors to get used to CBOR by using
   the following items: (C_R, CIPHERTEXT_3).

   message_3 = CBOR playground [CborMe].

    Diagnostic          Encoded              Type
    ------------------------------------------------------------------
    1                   0x01                 unsigned integer
    24                  0x1818               unsigned integer
    -24                 0x37                 negative integer
    -25                 0x3818               negative integer
    true                0xf5                 simple value
    h'12cd'             0x4212cd             byte string
    '12cd'              0x4431326364         byte string
    "12cd"              0x6431326364         text string
    { 4 : h'cd' }       0xa10441cd           map
    << 1, 2, true >>    0x430102f5           byte string
    [ 1, 2, true ]      0x830102f5           array
    (
     -24,
     h'D5535F3147E85F1CFACD9E78ABF9E0A81BBF' 1, 2, true )

   Which encodes to the following byte string:

   message_3 (CBOR Sequence) (20 bytes)
   37 52 d5 53 5f 31 47 e8 5f 1c fa cd 9e 78 ab f9 e0 a8 1b bf

D.2.4.  OSCORE Security Context Derivation

   From here, the Initiator and the Responder can derive an OSCORE
   Security Context, using the EDHOC-Exporter interface.

   From TH_3 and CIPHERTEXT_3, compute the input to      0x0102f5             sequence
    1, 2, true          0x0102f5             sequence
    ------------------------------------------------------------------

C.2.  CDDL Definitions

   This sections compiles the transcript hash
   TH_4 = H( TH_3, CIPHERTEXT_3 ), as a CBOR Sequence CDDL definitions for ease of these 2 data
   items.

 Input to calculate TH_4 (CBOR Sequence) (53 bytes)
 58 20 b6 cd 80 4f c4 b9 d7 ca c5 02 ab d7 7c da 74 e4 1c b0 11 82 d7 cb
 8b 84 db 03 ff a5 83 a3 5f cb 52 d5 53 5f 31 47 e8 5f 1c fa cd 9e 78 ab
 f9 e0 a8 1b bf

   And from there, compute the transcript hash TH_4 reference.

   suite = SHA-256(TH_3 ,
   CIPHERTEXT_4)

 TH_4 (CBOR unencoded) (32 bytes)
 7c cf de dc 2c 10 ca 03 56 e9 57 b9 f6 a5 92 e0 fa 74 db 2a b5 4f 59 24
 40 96 f9 a2 ac 56 d2 07

   The Master Secret and Master Salt are derived as follows:

   Master Secret int

   ead = EDHOC-Exporter( "OSCORE Master Secret", 16 1* (
     type : int,
     ext_authz_data : any,
   )

   message_1 = EDHOC-
   KDF(PRK_4x3m, TH_4, "OSCORE Master Secret", 16) = HKDF-Expand(
   PRK_4x3m, info_ms, 16 (
     METHOD : int,
     SUITES_I : [ selected : suite, supported : 2* suite ] / suite,
     G_X : bstr,
     C_I : bstr / int,
     ? EAD_1 : ead,
   )

   Master Salt

   message_2 = EDHOC-Exporter( "OSCORE Master Salt", 8 (
     G_Y_CIPHERTEXT_2 : bstr,
     C_R : bstr / int,
   )

   message_3 = EDHOC-
   KDF(PRK_4x3m, TH_4, "OSCORE Master Salt", 8) = HKDF-Expand( PRK_4x3m,
   info_salt, 8 (
     CIPHERTEXT_3 : bstr,
   )

   info_ms for OSCORE Master Secret is defined as follows:

  info_ms

   message_4 = (
     CIPHERTEXT_4 : bstr,
   )

   SUITES_R : [
    10,
    h'7CCFDEDC2C10CA0356E957B9F6A592E0FA74DB2AB54F59244096F9A2AC56D207',
    "OSCORE Master Secret",
    16
  ]

   Which as a CBOR encoded data item is:

 info_ms for OSCORE Master Secret (CBOR-encoded) (58 bytes)
 84 0a 58 20 7c cf de dc 2c 10 ca 03 56 e9 57 b9 f6 a5 92 e0 fa 74 db 2a
 b5 4f 59 24 40 96 f9 a2 ac 56 d2 07 74 4f 53 43 4f 52 45 20 4d 61 73 74
 65 72 20 53 65 63 72 65 74 10

   info_salt for OSCORE Master Salt is defined as follows:

  info_salt supported : 2* suite ] / suite

   error = (
     ERR_CODE : int,
     ERR_INFO : any,
   )

   info = [
    10,
    h'7CCFDEDC2C10CA0356E957B9F6A592E0FA74DB2AB54F59244096F9A2AC56D207',
    "OSCORE Master Salt",
    8
      edhoc_aead_id : int / tstr,
      transcript_hash : bstr,
      label : tstr,
      * context : any,
      length : uint,
   ]

   Which as a

C.3.  COSE

   CBOR encoded Object Signing and Encryption (COSE)
   [I-D.ietf-cose-rfc8152bis-struct] describes how to create and process
   signatures, message authentication codes, and encryption using CBOR.
   COSE builds on JOSE, but is adapted to allow more efficient
   processing in constrained devices.  EDHOC makes use of COSE_Key,
   COSE_Encrypt0, and COSE_Sign1 objects in the message processing:

   *  ECDH ephemeral public keys of type EC2 or OKP in message_1 and
      message_2 consist of the COSE_Key parameter named 'x', see
      Section 7.1 and 7.2 of [I-D.ietf-cose-rfc8152bis-algs]

   *  Certain ciphertexts in message_2 and message_3 consist of a subset
      of the single recipient encrypted data item is:

 info for OSCORE Master Salt (CBOR-encoded) (56 Bytes)
 84 0a 58 20 7c cf de dc 2c 10 ca 03 56 e9 57 b9 f6 a5 92 e0 fa 74 db 2a
 b5 4f 59 24 40 96 f9 a2 ac 56 d2 07 72 4f 53 43 4f 52 45 20 4d 61 73 74
 65 72 20 53 61 6c 74 08

   From these parameters, OSCORE Master Secret object COSE_Encrypt0, which
      is described in Sections 5.2-5.3 of
      [I-D.ietf-cose-rfc8152bis-struct].  The ciphertext is computed
      over the plaintext and OSCORE Master Salt
   are computed:

   OSCORE Master Secret (16 bytes)
   c3 4a 50 6d 0e bf bd 17 03 04 86 13 5f 9c b3 50

   OSCORE Master Salt (8 bytes)
   c2 24 34 9d 9b 34 ca 8c associated data, using an encryption key
      and a nonce.  The client's OSCORE Sender ID associated data is C_R an Enc_structure consisting
      of protected headers and externally supplied data (external_aad).

   *  Signatures in message_2 of method 0 and 2, and in message_3 of
      method 0 and 1, consist of a subset of the server's OSCORE Sender
   ID single signer data
      object COSE_Sign1, which is C_I.

   Client's OSCORE Sender ID (1 byte)
   00

   Server's OSCORE Sender ID (1 byte)
   16 described in Sections 4.2-4.4 of
      [I-D.ietf-cose-rfc8152bis-struct].  The AEAD Algorithm signature is computed over
      a Sig_structure containing payload, protected headers and the hash algorithm are the application AEAD
      externally supplied data (external_aad) using a private signature
      key and hash algorithms in verified using the selected cipher suite.

   OSCORE AEAD Algorithm (int)
   10

   OSCORE Hash Algorithm (int)
   -16 corresponding public signature key.

Appendix D.  Test Vectors

   TBD

Appendix E.  Applicability Template

   This appendix contains an a rudimentary example of an applicability
   statement, see Section 3.9.

   For use of EDHOC in the XX protocol, the following assumptions are
   made on
   made:

   1.  Transfer in CoAP as specified in Appendix A.3 with requests
       expected by the parameters:

   o CoAP server (= Responder) at /app1-edh, no
       Content-Format needed.

   2.  METHOD = 1 (I uses signature key, R uses static DH key.)

   o  EDHOC requests are expected by the server at /app1-edh, no
      Content-Format needed.

   o
   3.  CRED_I is an IEEE 802.1AR IDevID encoded as a C509 Certificate certificate of
       type 0 [I-D.ietf-cose-cbor-encoded-cert].

       *  R acquires CRED_I out-of-band, indicated in EAD_1 EAD_1.

       *  ID_CRED_I = {4: h''} is a kid 'kid' with value empty byte string

   o string.

   4.  CRED_R is a COSE_Key UCCS of type OKP as specified in Section 3.5.4. 3.5.2.

       *  The CBOR map has parameters 1 (kty), -1 (crv), and -2
          (x-coordinate).

   o

       *  ID_CRED_R = CRED_R

   o

   5.  External authorization data is defined and processed as specified
       in [I-D.selander-ace-ake-authz].

   6.  EUI-64 used as identity of endpoint.

   7.  No use of message_4: the application sends protected messages
       from R to I.

   o  External authorization data is defined and processed as specified
      in [I-D.selander-ace-ake-authz].

Appendix F.  EDHOC Message Deduplication

   EDHOC by default assumes that message duplication is handled by the
   transport, in this section exemplified with CoAP.

   Deduplication of CoAP messages is described in Section 4.5 of
   [RFC7252].  This handles the case when the same Confirmable (CON)
   message is received multiple times due to missing acknowledgement on
   CoAP messaging layer.  The recommended processing in [RFC7252] is
   that the duplicate message is acknowledged (ACK), but the received
   message is only processed once by the CoAP stack.

   Message deduplication is resource demanding and therefore not
   supported in all CoAP implementations.  Since EDHOC is targeting
   constrained environments, it is desirable that EDHOC can optionally
   support transport layers which does not handle message duplication.
   Special care is needed to avoid issues with duplicate messages, see
   Section 5.1.

   The guiding principle here is similar to the deduplication processing
   on CoAP messaging layer: a received duplicate EDHOC message SHALL NOT
   result in a response consisting of another instance of the next EDHOC
   message.  The result MAY be that a duplicate EDHOC response is sent,
   provided it is still relevant with respect the current protocol
   state.  In any case, the received message MUST NOT be processed more
   than once in the same EDHOC session.  This is called "EDHOC message
   deduplication".

   An EDHOC implementation MAY store the previously sent EDHOC message
   to be able to resend it.  An EDHOC implementation MAY keep the
   protocol state to be able to recreate the previously sent EDHOC
   message and resend it.  The previous message or protocol state MUST
   NOT be kept longer than what is required for retransmission, for
   example, in the case of CoAP transport, no longer than the
   EXCHANGE_LIFETIME (see Section 4.8.2 of [RFC7252]).

   Note that the requirements in Section 5.1 still apply because
   duplicate messages are not processed by the EDHOC state machine:

   o

   *  EDHOC messages SHALL be processed according to the current
      protocol state.

   o

   *  Different instances of the same message MUST NOT be processed in
      one session.

Appendix G.  Transports Not Natively Providing Correlation

   Protocols that do not natively provide full correlation between a
   series of messages can send the C_I and C_R identifiers along as
   needed.

   The transport over CoAP (Appendix A.3) can serve as a blueprint for
   other server-client protocols: The client prepends the C_x which the
   server selected (or, for message 1, a sentinel null value which is
   not a valid C_x) to any request 1, the CBOR simple value 'true'
   which is not a valid C_x) to any request message it sends.  The
   server does not send any such indicator, as responses are matched to
   request by the client-server protocol design.

   Protocols that do not provide any correlation at all can prescribe
   prepending of the peer's chosen C_x to all messages.

Appendix H.  Change Log

   RFC Editor: Please remove this appendix.

   Main changes:

   *  From -08 to -09:

      -  G_Y and CIPHERTEXT_2 are now included in one CBOR bstr

      -  MAC_2 and MAC_3 are now generated with EDHOC-KDF

      -  Info field "context" is now general and explicit in EDHOC-KDF

      -  Restructured Section 4, Key Derivation

      -  Added EDHOC MAC length to cipher suite for use with static DH

      -  More details on the use of CWT and UCCS

      -  Restructured and clarified Section 3.5, Authentication
         Parameters

      -  Replaced 'kid2' with extension of 'kid'

      -  EAD encoding now supports multiple ead types in one message

      -  Clarified EAD type

      -  Updated message it sends.  The server does
   not send any such indicator, as responses are matched to request by sizes

      -  Replaced "perfect forward secrecy" with "forward secrecy"

      -  Updated security considerations

      -  Replaced prepended 'null' with 'true' in the client-server protocol design.

   Protocols that do not provide any correlation at all can prescribe
   prepending CoAP transport of
         message_1

      -  Updated CDDL definitions

      -  Expanded on the peer's chosen C_x to all messages.

Appendix H.  Change Log

   Main changes:

   o use of COSE

   *  From -07 to -08:

      *

      -  Prepended C_x moved from the EDHOC protocol itself to the
         transport mapping

      *

      -  METHOD_CORR renamed to METHOD, corr removed

      *

      -  Removed bstr_identifier and use bstr / int instead; C_x can now
         be int without any implied bstr semantics

      *

      -  Defined COSE header parameter 'kid2' with value type bstr / int
         for use with ID_CRED_x

      *

      -  Updated message sizes

      *

      -  New cipher suites with AES-GCM and ChaCha20 / Poly1305

      *

      -  Changed from one- to two-byte identifier of CNSA compliant
         suite

      *

      -  Separate sections on transport and connection id with further
         sub-structure

      *

      -  Moved back key derivation for OSCORE from draft-ietf-core-
         oscore-edhoc

      *

      -  OSCORE and CoAP specific processing moved to new appendix

      *

      -  Message 4 section moved to message processing section

   o

   *  From -06 to -07:

      *

      -  Changed transcript hash definition for TH_2 and TH_3

      *

      -  Removed "EDHOC signature algorithm curve" from cipher suite
      *

      -  New IANA registry "EDHOC Exporter Label"

      *

      -  New application defined parameter "context" in EDHOC-Exporter

      *

      -  Changed normative language for failure from MUST to SHOULD send
         error

      *

      -  Made error codes non-negative and 0 for success

      *

      -  Added detail on success error code

      *

      -  Aligned terminology "protocol instance" -> "session"

      *

      -  New appendix on compact EC point representation

      *

      -  Added detail on use of ephemeral public keys

      *

      -  Moved key derivation for OSCORE to draft-ietf-core-oscore-edhoc

      *

      -  Additional security considerations

      *

      -  Renamed "Auxililary Data" as "External Authorization Data"

      *

      -  Added encrypted EAD_4 to message_4

   o

   *  From -05 to -06:

      *

      -  New section 5.2 "Message Processing Outline"

      *

      -  Optional inital byte C_1 = null in message_1

      *

      -  New format of error messages, table of error codes, IANA
         registry

      *

      -  Change of recommendation transport of error in CoAP

      *

      -  Merge of content in 3.7 and appendix C into new section 3.7
         "Applicability Statement"

      *

      -  Requiring use of deterministic CBOR

      *

      -  New section on message deduplication

      *

      -  New appendix containin all CDDL definitions

      *

      -  New appendix with change log

      *

      -  Removed section "Other Documents Referencing EDHOC"
      *

      -  Clarifications based on review comments

   o

   *  From -04 to -05:

      *

      -  EDHOC-Rekey-FS -> EDHOC-KeyUpdate

      *

      -  Clarification of cipher suite negotiation

      *

      -  Updated security considerations

      *

      -  Updated test vectors

      *

      -  Updated applicability statement template

   o

   *  From -03 to -04:

      *

      -  Restructure of section 1

      *

      -  Added references to C509 Certificates

      *

      -  Change in CIPHERTEXT_2 -> plaintext XOR KEYSTREAM_2 (test
         vector not updated)

      *

      -  "K_2e", "IV_2e" -> KEYSTREAM_2

      *
      -  Specified optional message 4

      *

      -  EDHOC-Exporter-FS -> EDHOC-Rekey-FS

      *

      -  Less constrained devices SHOULD implement both suite 0 and 2

      *

      -  Clarification of error message

      *

      -  Added exporter interface test vector

   o

   *  From -02 to -03:

      *

      -  Rearrangements of section 3 and beginning of section 4

      *

      -  Key derivation new section 4

      *

      -  Cipher suites 4 and 5 added

      *

      -  EDHOC-EXPORTER-FS - generate a new PRK_4x3m from an old one

      *

      -  Change in CIPHERTEXT_2 -> COSE_Encrypt0 without tag (no change
         to test vector)

      *

      -  Clarification of error message

      *

      -  New appendix C applicability statement

   o

   *  From -01 to -02:

      *

      -  New section 1.2 Use of EDHOC

      *

      -  Clarification of identities

      *

      -  New section 4.3 clarifying bstr_identifier

      *

      -  Updated security considerations

      *

      -  Updated text on cipher suite negotiation and key confirmation

      *

      -  Test vector for static DH

   o

   *  From -00 to -01:

      *

      -  Removed PSK method

      *

      -  Removed references to certificate by value

Acknowledgments

   The authors want to thank Christian Amsuess, Alessandro Bruni,
   Karthikeyan Bhargavan, Timothy Claeys, Martin Disch, Theis Groenbech
   Petersen, Dan Harkins, Klaus Hartke, Russ Housley, Stefan Hristozov,
   Alexandros Krontiris, Ilari Liusvaara, Karl Norrman, Salvador Perez,
   Eric Rescorla, Michael Richardson, Thorvald Sahl Joergensen, Jim
   Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav Smyshlyaev,
   Valery Smyslov, Peter van der Stok, Rene Struik, Vaishnavi
   Sundararajan, Erik Thormarker, Marco Tiloca, Michel Veillette, and
   Malisa Vucinic for reviewing and commenting on intermediate versions
   of the draft.  We are especially indebted to Jim Schaad for his
   continuous reviewing and implementation of different versions of the
   draft.

   Work on this document has in part been supported by the H2020 project
   SIFIS-Home (grant agreement 952652).

Authors' Addresses

   Goeran

   Göran Selander
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Email: goran.selander@ericsson.com

   John Preuss Preuß Mattsson
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Email: john.mattsson@ericsson.com

   Francesca Palombini
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Email: francesca.palombini@ericsson.com