# drafts

name: draft-tschofenig-lamps-nonce-cmp-est
rev: 01
time: 2024-04-03T18:03:47Z
group_uri: /api/v1/group/group/2164/
expires: 2024-09-04T12:08:53Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081802+00:00
source: ietf
title:
  Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST)

abstract:
  Certificate Management Protocol (CMP) and Enrollment over Secure
     Transport (EST) define protocol messages for X.509v3 certificate
     creation and management.  Both protocol provide interactions between
     client systems and PKI management entities, such as a Registration
     Authority (RA) and a Certification Authority (CA).

     CMP and EST allow an RA/CA to request additional information it has
     to provide in a certification request.  When an end entity places
     attestation Evidence in a Certificate Signing Request (CSR) it may
     need to demonstrate freshness of the provided Evidence.  Attestation
     technology today often accomplishes this task via the help of nonces.

     This document specifies how nonces are provided by an RA/CA to the
     end entity for inclusion in Evidence.

full_text:
  LAMPS                                                      H. Tschofenig
  Internet-Draft                                              H. Brockhaus
  Intended status: Standards Track                                 Siemens
  Expires: 3 September 2024                                   2 March 2024


    Nonce-based Freshness for Remote Attestation in Certificate Signing
  Requests (CSRs) for the Certification Management Protocol (CMP) and for
                   Enrollment over Secure Transport (EST)
                  draft-tschofenig-lamps-nonce-cmp-est-01

  Abstract

     Certificate Management Protocol (CMP) and Enrollment over Secure
     Transport (EST) define protocol messages for X.509v3 certificate
     creation and management.  Both protocol provide interactions between
     client systems and PKI management entities, such as a Registration
     Authority (RA) and a Certification Authority (CA).

     CMP and EST allow an RA/CA to request additional information it has
     to provide in a certification request.  When an end entity places
     attestation Evidence in a Certificate Signing Request (CSR) it may
     need to demonstrate freshness of the provided Evidence.  Attestation
     technology today often accomplishes this task via the help of nonces.

     This document specifies how nonces are provided by an RA/CA to the
     end entity for inclusion in Evidence.

  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 3 September 2024.







  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 1]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology and Requirements Language . . . . . . . . . . . .   4
     3.  Conveying a Nonce in CMP  . . . . . . . . . . . . . . . . . .   5
     4.  Conveying a Nonce in EST  . . . . . . . . . . . . . . . . . .   6
     5.  Nonce Processing Guidelines . . . . . . . . . . . . . . . . .   8
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

  1.  Introduction

     Several protocols have been standardized to automate the management
     of certificates, such as certificate issuance, CA certificate
     provisioning, certificate renewal and certificate revocation.

     The Certificate Management Protocol (CMP) [I-D.ietf-lamps-rfc4210bis]
     defines protocol messages for X.509v3 certificate creation and
     management.  CMP provides interactions between end entities and PKI
     components, such as a Registration Authority (RA) and a Certification
     Authority (CA).

     Enrollment over Secure Transport (EST) [RFC7030][RFC8295] is another
     certificate management protocol, which provides a sub-set of the
     features offered by CMP.

     An end entity requesting a certificate from a Certification Authority
     (CA) may wish to offer believable claims about the protections
     afforded to the corresponding private key, such as whether the



  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 2]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


     private key resides on a hardware security module or the protection
     capabilities provided by the hardware, and claims about the platform
     itself.

     To convey these claims in Evidence, as part of remote attestation,
     the remote attestation extension [I-D.ietf-lamps-csr-attestation] has
     been defined.  It describes how to encode Evidence produced by an
     Attester for inclusion in Certificate Signing Requests (CSRs), and
     any certificates necessary for validating it.

     A Verifier or Relying Party might need to learn the point in time an
     Evidence has been produced.  This is essential in deciding whether
     the included Claims can be considered fresh, meaning they still
     reflect the latest state of the Attester.

     Attestation technology available today, such as [TPM20] and
     [I-D.tschofenig-rats-psa-token], often accomplish freshness with the
     help of nonces.  More details about ensuring freshness of Evidence
     can be found in Section 10 of [RFC9334].

     Since an end entity needs to obtain a nonce from the Verifier via the
     Relying Party, this leads to an additional roundtrip.  The CSR is,
     however, a one-shot message.  For this reason CMP and EST are used by
     the end entity to obtain the nonce from the RA/CA.

     CMP and EST conveniently offer a mechanism to request information
     from the RA/CA prior to a certification request.

     Once the nonce is obtained the end entity can issue an API call to
     the Attester to request Evidence and passes the nonce as an input
     parameter into the API call.  The returned Evidence is then embedded
     into a CSR and returned to the RA/CA in a certification request
     message.

     Figure 1 shows this interaction graphically.  The nonce is obtained
     in step (1) using the extension to CMP/EST defined in this document.
     The CSR extension of [I-D.ietf-lamps-csr-attestation] is used to
     convey Evidence to the RA/CA in step (2).  The Verifier processes the
     received information and returns an Attestation Result to the Relying
     Party in step (3).











  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 3]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


                                   .---------------.
                                   |               |
                                   |   Verifier    |
                                   |               |
                                   '---------------'
                                        |    ^  |    (3)
                                        |    |  | Attestation
                                        |    |  |   Result
                         (1)            |    |  v
      .------------.   Nonce in    .----|----|-----.
      |            |   CMP or EST  |    |    |     |
      |  End       |<-------------------+    |     |
      |  Entity    |               |         |     |
      |    ^       |-------------->|---------'     |
      |    |       |   Evidence    | Relying       |
      |    v       |   in CSR      | Party (RA/CA) |
      |  Attester  |     (2)       |               |
      |            |               |               |
      '------------'               '---------------'

              Figure 1: Architecture with Background Check Model.

     The functionality of this document is described in two sections,
     namely:

     *  Section 3 describes how to convey the nonce CMP, and

     *  Section 4 offers the equivalent functionality for EST.

  2.  Terminology and Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in RFC 2119 [RFC2119].

     The terms Attester, Relying Party, Verifier and Evidence are defined
     in [RFC9334].  The terms end entity, certification authority (CA),
     and registration authority (RA) are defined in [RFC5280].

     We use the terms Certificate Signing Request (CSR) and certification
     request interchangeably.










  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 4]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


  3.  Conveying a Nonce in CMP

     Section 5.3.19.16 of [I-D.ietf-lamps-rfc4210bis] defines the general
     request message (genm) and general response (genp).  The NonceRequest
     payload of the genm message, which is send by the end entity to
     request a nonce, contains optional details on the length of nonce the
     Attester requires.  The NonceResponse payload of the genp message,
     which is sent by the CA/RA in response to a request message by the
     end entity, contains the nonce.

      GenMsg:    {id-it TBD1}, NonceRequestValue
      GenRep:    {id-it TBD2}, NonceResponseValue | < absent >

      id-it-NonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 }
      NonceRequestValue ::= SEQUENCE {
         len INTEGER OPTIONAL,
         -- indicates the required length of the requested nonce
         hint EvidenceHint OPTIONAL
         -- indicates which Verifier to request a nonce from
      }

      id-it-NonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 }
      NonceResponseValue ::= SEQUENCE {
         nonce OCTET STRING
         -- contains the nonce of length len
         -- provided by the Verifier indicated with hint
         expiry Time OPTIONAL
         -- indicates how long the Verifier considers the
         -- nonce valid
      }

     Note: The EvidenceHint structure is defined in
     [I-D.ietf-lamps-csr-attestation].  The hint is intended for an
     Attester to indicate to the EST server which Verifier should be
     invoked to request a nonce.

     The use of the general request/response message exchange leads to an
     extra roundtrip to convey the nonce from the CA/RA to the end entity
     (and ultimately to the Attester inside the end entity).

     The end entity MUST construct a NonceRequest request message to
     trigger the RA/CA to transmit a nonce in the response.

     [Open Issue: Should request message indicate the remote attestation
     capability of the end entity rather than relying on "policy
     information"?  This may also allow to inform the CA/RA about the type
     of attestation technology/technologies available to the end entity.]




  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 5]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


     If the end entity supports remote attestation and the policy requires
     Evidence in a CSR to be provided, the RA/CA issues an NonceResponse
     response message containing a nonce.

     Figure 2 showns the interaction graphically.

     End Entity                                          RA/CA
     ==========                                      =============

                   -->>-- NonceRequest -->>--
                                                     Verify request
                                                     Generate nonce*
                                                     Create response
                   --<<-- NonceResponse --<<--
                           (nonce, expiry)

     Generate key pair
     Generate Evidence*
     Generate certification request message
                   -->>-- certification request -->>--
                         (+Evidence including nonce)
                                                    Verify request
                                                    Verify Evidence*
                                                    Check for replay*
                                                    Issue certificate
                                                    Create response
                   --<<-- certification response --<<--
     Handle response
     Store certificate

     *: These steps require interactions with the Attester
     (on the EE side) and with the Verifier (on the RA/CA side).

                Figure 2: CMP Exchange with Nonce and Evidence.

  4.  Conveying a Nonce in EST

     The EST client can request a nonce for its Attester.  This function
     is generally performed after requesting CA certificates and before
     other EST functions.

     The EST server MUST support the use of the path-prefix of "/.well-
     known/" as defined in [RFC5785] and the registered name of "est".
     Thus, a valid EST server URI path begins with
     "https://www.example.com/.well-known/est".  Each EST operation is
     indicated by a path-suffix that indicates the intended operation.

     The following operation is defined by this specificaion:



  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 6]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


      +------------------------+-----------------+-------------------+
      | Operation              |Operation path   | Details           |
      +========================+=================+===================+
      | Retrieval of a nonce   | /nonce          | This section      |
      +------------------------+-----------------+-------------------+

     The operation path is appended to the path-prefix to form the URI
     used with HTTP GET or POST to perform the desired EST operation.  An
     example valid URI absolute path for the "/nonce" operation is
     "/.well-known/est/nonce".

     An EST client uses a GET or a POST depending on whether parameters
     are included:

     *  A GET request MUST be used when the EST client does not want to
        convey extra parameters.

     *  A POST request MUST be used when parameters, like nonce length or
        a hint about the verification service, are included in the
        request.

   +-------------------+---------------------------------+---------------+
   | Message type      | Media type(s)                   | Reference     |
   | (per operation)   |                                 |               |
   +===================+=================================+===============+
   | Nonce Request     | N/A (for GET) or                | This section  |
   |                   | application/json (for POST)     |               |
   +===================+=================================+===============+
   | Nonce Response    | application/json                | This section  |
   |                   |                                 |               |
   +===================+=================================+===============+

     To retrieve a nonce using a GET, the EST client would use the
     following HTTP request-line:

     GET /.well-known/est/nonce HTTP/1.1

     To retrieve a nonce by specifying the size of the requested nonce
     (and/or by including a hint about the Verification service) a POST
     message is used, as shown below:

     POST /.well-known/est/nonce HTTP/1.1
     Content-Type: application/json
     {
       "len": 8,
       "hint": "https://example.com"
     }




  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 7]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


     The payload in a POST request MUST be of content-type of
     "application/json" and MUST contain a JSON object [RFC7159] with the
     member "len" and/or "hint".  The value of the "len" member indicates
     the length of the requested nonce value in bytes.  The "hint" member
     contains either be a rfc822Name, a dNSName, a uri, or a test value
     (based on the definition in the EvidenceHint structure from
     [I-D.ietf-lamps-csr-attestation]).

     The EST server MAY request HTTP-based client authentication, as
     explained in Section 3.2.3 of [RFC7030].

     If the request is successful, the EST server response MUST contain a
     HTTP 200 response code with a content-type of "application/json" and
     a JSON object [RFC7159] with the member nonce.  The expiry member is
     optional and indicates the time the nonce is considered valid.  After
     the expiry time is expired, the session is likely garbage collected.

     Below is a non-normative example of the response given by the EST
     server:

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
         "nonce": "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=",
         "expiry": "2031-10-12T07:20:50.52Z"
     }

     [Open Issue: Should we also register a content type for use with EST
     over CoAP where the nonce and the expiry field is encoded in a CBOR
     structure?]

  5.  Nonce Processing Guidelines

     When the RA/CA is requested or configured to transmit a nonce to an
     end entity then it interacts with the Verifier.  The Verifier is,
     according to the IETF RATS architecture [RFC9334], "a role performed
     by an entity that appraises the validity of Evidence about an
     Attester and produces Attestation Results to be used by a Relying
     Party."  Since the Verifier validates Evidence it is also the source
     of the nonce to check for replay.

     The nonce value MUST contain a random byte sequence whereby the
     length depends on the used remote attestation technology.  Since the
     nonce is relayed with the RA/CA, it MUST be copied to the respective
     structure, as described in Section 4 and Section 3, for transmission
     to the Attester.




  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 8]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


     For example, the PSA attestation token
     [I-D.tschofenig-rats-psa-token] supports nonces of length 32, 48 and
     64 bytes.  Other attestation technologies use nonces of similar
     length.  The assumption in this specification is that the RA/CA have
     out-of-band knowledge about the required nonce length required for
     the attestation technology used by the end entity.  The nonces of
     incorrect length will cause the remote attestation protocol to fail.

     When the end entity receives the nonce it MUST use it, if remote
     attestation is available and supports nonces.  It is better for an
     RA/CA to be aggressive in sending a nonce, at least where there is a
     reasonable chance the client supports remote attestation and the
     client should be allowed to ignore the nonce if it either does not
     support it or cannot use it for policy reasons.

     While the semantics of the attestation API and the software/hardware
     architecture is out-of-scope of this specification, the API will
     return Evidence from the Attester in a format specific to the
     attestation technology utilized.  The encoding of the returned
     evidence varies but will be placed inside the CSR, as specified in
     [I-D.ietf-lamps-csr-attestation].  The software creating the CSR will
     not have to interpret the Evidence format - it is treated as an
     opaque blob.  It is important to note that the nonce is carried in
     the Evidence, either implicitly or explicitly, and it MUST NOT be
     conveyed in CSR structures outside the Evidence payload.

     The processing of the CSR containing Evidence is described in
     [I-D.ietf-lamps-csr-attestation].  Note that the issued certificates
     does not contain the nonce, as explained in
     [I-D.ietf-lamps-csr-attestation].

  6.  IANA Considerations

     TBD:

  7.  Security Considerations

     This specification defines how to obtain a nonce via CMP and EST and
     assumes that the nonce does not require confidentiality protection
     without impacting the security property of the remote attestation
     protocol.  [RFC9334] defines the IETF remote attestation architecture
     discusses nonce-based freshness in great detail.

     Section 8.4 of [I-D.ietf-rats-eat] places randomness and privacy
     requirement on the generation of the nonce for use with an Entity
     Attestation Token (EAT).  These requirements have been adopted by
     attestation technologies, such as the PSA attestation token
     [I-D.tschofenig-rats-psa-token] and are of general utility:



  Tschofenig & Brockhaus  Expires 3 September 2024                [Page 9]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


     *  The nonce MUST have at least 64 bits of entropy.

     *  To avoid the conveyance of privacy-related information in the
        nonce, it should be derived using a salt that originates from a
        true and reliable random number generator or any other source of
        randomness.

     Since each specification of an attestation technology offers guidance
     for replay protection with nonces (and other techniques) this
     document needs to defer specific guidance to the respective
     specifications.

     For the use of Evidence in a CSR the security considerations of
     [I-D.ietf-lamps-csr-attestation] are relevant to this document.

  8.  References

  8.1.  Normative References

     [I-D.ietf-lamps-csr-attestation]
                Ounsworth, M., Tschofenig, H., and H. Birkholz, "Use of
                Remote Attestation with Certificate Signing Requests",
                Work in Progress, Internet-Draft, draft-ietf-lamps-csr-
                attestation-08, 1 March 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
                csr-attestation-08>.

     [I-D.ietf-lamps-rfc4210bis]
                Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
                "Internet X.509 Public Key Infrastructure -- Certificate
                Management Protocol (CMP)", Work in Progress, Internet-
                Draft, draft-ietf-lamps-rfc4210bis-08, 1 March 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
                rfc4210bis-08>.

     [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/rfc/rfc2119>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and 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/rfc/rfc5280>.






  Tschofenig & Brockhaus  Expires 3 September 2024               [Page 10]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


     [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
                Uniform Resource Identifiers (URIs)", RFC 5785,
                DOI 10.17487/RFC5785, April 2010,
                <https://www.rfc-editor.org/rfc/rfc5785>.

     [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
                "Enrollment over Secure Transport", RFC 7030,
                DOI 10.17487/RFC7030, October 2013,
                <https://www.rfc-editor.org/rfc/rfc7030>.

     [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
                2014, <https://www.rfc-editor.org/rfc/rfc7159>.

     [RFC8295]  Turner, S., "EST (Enrollment over Secure Transport)
                Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018,
                <https://www.rfc-editor.org/rfc/rfc8295>.

  8.2.  Informative References

     [I-D.ietf-rats-eat]
                Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", Work in
                Progress, Internet-Draft, draft-ietf-rats-eat-25, 15
                January 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-eat-25>.

     [I-D.tschofenig-rats-psa-token]
                Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
                T. Fossati, "Arm's Platform Security Architecture (PSA)
                Attestation Token", Work in Progress, Internet-Draft,
                draft-tschofenig-rats-psa-token-22, 21 February 2024,
                <https://datatracker.ietf.org/doc/html/draft-tschofenig-
                rats-psa-token-22>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

     [TPM20]    Trusted Computing Group, "Trusted Platform Module Library
                Specification, Family 2.0, Level 00, Revision 01.59",
                November 2019,
                <https://trustedcomputinggroup.org/resource/tpm-library-
                specification/>.






  Tschofenig & Brockhaus  Expires 3 September 2024               [Page 11]


  Internet-Draft         Nonce Extension for CMP/EST            March 2024


  Appendix A.  Acknowledgments

     We would like to thank Russ Housley, Thomas Fossati, Watson Ladd,
     Ionut Mihalcea and Carl Wallace for their review comments.

  Authors' Addresses

     Hannes Tschofenig
     Siemens
     Email: hannes.tschofenig@siemens.com


     Hendrik Brockhaus
     Siemens
     Email: hendrik.brockhaus@siemens.com




































  Tschofenig & Brockhaus  Expires 3 September 2024               [Page 12]


name: draft-tiloca-lake-edhoc-implem-cons
rev: 01
title: Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC)
time: 2024-02-13T15:05:29Z
group_uri: /api/v1/group/group/2249/
expires: 2024-08-15T08:48:56Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081809+00:00
source: ietf
abstract:
  This document provides considerations for guiding the implementation
     of the authenticated key exchange protocol Ephemeral Diffie-Hellman
     Over COSE (EDHOC).

full_text:
  LAKE Working Group                                             M. Tiloca
  Internet-Draft                                                   RISE AB
  Intended status: Informational                          12 February 2024
  Expires: 15 August 2024


    Implementation Considerations for Ephemeral Diffie-Hellman Over COSE
                                  (EDHOC)
                   draft-tiloca-lake-edhoc-implem-cons-01

  Abstract

     This document provides considerations for guiding the implementation
     of the authenticated key exchange protocol Ephemeral Diffie-Hellman
     Over COSE (EDHOC).

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Discussion of this document takes place on the Lightweight
     Authenticated Key Exchange Working Group mailing list
     (lake@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/lake/.

     Source for this draft and an issue tracker can be found at
     https://gitlab.com/crimson84/draft-tiloca-lake-edhoc-implem-cons.

  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 15 August 2024.







  Tiloca                   Expires 15 August 2024                 [Page 1]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Handling of Invalid EDHOC Sessions and Application Keys . . .   3
       2.1.  EDHOC Sessions Become Invalid . . . . . . . . . . . . . .   4
       2.2.  Application Keys Become Invalid . . . . . . . . . . . . .   5
       2.3.  Application Keys or Bound Access Rights Become Invalid  .   7
     3.  Trust Models for Learning New Authentication Credentials  . .  11
     4.  Side Processing of Incoming EDHOC Messages  . . . . . . . . .  13
       4.1.  EDHOC message_1 . . . . . . . . . . . . . . . . . . . . .  15
       4.2.  EDHOC message_4 . . . . . . . . . . . . . . . . . . . . .  16
       4.3.  EDHOC message_2 and message_3 . . . . . . . . . . . . . .  16
         4.3.1.  Pre-Verification Side Processing  . . . . . . . . . .  16
         4.3.2.  Post-Verification Side Processing . . . . . . . . . .  19
         4.3.3.  Flowcharts  . . . . . . . . . . . . . . . . . . . . .  19
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  24
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  25
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

  1.  Introduction

     Ephemeral Diffie-Hellman Over COSE (EDHOC) [I-D.ietf-lake-edhoc] is a
     lightweight authenticated key exchange protocol, especially intended
     for use in constrained scenarios.

     During the development of EDHOC, a number of side topics were raised
     and discussed, as emerging from reviews of the protocol latest design
     and from implementation activities.  These topics were identified as
     strongly pertaining to the implementation of EDHOC rather than to the



  Tiloca                   Expires 15 August 2024                 [Page 2]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     protocol in itself.  Hence, they are not discussed in
     [I-D.ietf-lake-edhoc], which rightly focuses on specifying the actual
     protocol.

     At the same time, implementors of an application using the EDHOC
     protocol or of an "EDHOC library" enabling its use cannot simply
     ignore such topics, and will have to take them into account
     throughout their implementation work.

     In order to prevent multiple, independent re-discoveries and
     assessments of those topics, as well as to facilitate and guide
     implementation activities, this document collects such topics and
     discusses them through considerations about the implementation of
     EDHOC.  At a high-level, the topics in question are summarized below.

     *  Handling of completed EDHOC sessions when they become invalid, and
        of application keys derived from an EDHOC session when those
        become invalid.  This topic is discussed in Section 2.

     *  Enforcing of different trust models, with respect to learning new
        authentication credentials during an execution of EDHOC.  This
        topic is discussed in Section 3.

     *  Branched-off, side processing of incoming EDHOC messages, with
        particular reference to: i) fetching and validation of
        authentication credentials; and ii) processing of External
        Authorization Data (EAD) items, which in turn might play a role in
        the fetching and validation of authentication credentials.  This
        topic is discussed in Section 4.

  1.1.  Terminology

     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.

     The reader is expected to be familiar with terms and concepts related
     to the EDHOC protocol and defined in [I-D.ietf-lake-edhoc].

  2.  Handling of Invalid EDHOC Sessions and Application Keys

     This section considers the most common situation where, given a
     certain peer, only the application at that peer has visibility and
     control of both:

     *  The EDHOC sessions at that peer; and



  Tiloca                   Expires 15 August 2024                 [Page 3]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     *  The application keys for that application at that peer, including
        the knowledge of whether they have been derived from an EDHOC
        session, i.e., by means of the EDHOC_Exporter interface after the
        successful completion of an execution of EDHOC (see Section 4.1 of
        [I-D.ietf-lake-edhoc]).

     Building on the above, the following expands on three relevant cases
     concerning the handling of EDHOC sessions and application keys, in
     the event that any of those becomes invalid.

     As a case in point to provide more concrete guidance, the following
     also considers the specific case where "applications keys" stands for
     the keying material and parameters that compose an OSCORE Security
     Context [RFC8613] and that are derived from an EDHOC session (see
     Appendix A.1 of [I-D.ietf-lake-edhoc]).

     Nevertheless, the same considerations are applicable in case EDHOC is
     used to derive other application keys, e.g., to key different
     security protocols than OSCORE or to provide the application with
     secure values bound to an EDHOC session.

  2.1.  EDHOC Sessions Become Invalid

     The application at a peer P may have learned that a completed EDHOC
     session S has to be invalidated.  When S is marked as invalid, the
     application at P purges S and deletes each set of application keys
     (e.g., the OSCORE Security Context) that was generated from S.

     Then, the applications runs a new execution of the EDHOC protocol
     with the other peer.  Upon successfully completing the EDHOC
     execution, the two peers derive and install a new set of application
     keys from this latest EDHOC session.

     The flowchart in Figure 1 shows the handling of an EDHOC session that
     has become invalid.

     Invalid     Delete the EDHOC session      Rerun     Derive and
     EDHOC   --> and the application keys  --> EDHOC --> install new
     session     derived from it                         application keys

         Figure 1: Handling of an EDHOC Session that has Become Invalid










  Tiloca                   Expires 15 August 2024                 [Page 4]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     An EDHOC session may have become invalid, for example, because an
     authentication credential CRED_X may have expired, or because P may
     have learned from a trusted source that CRED_X has been revoked.
     This effectively invalidates CRED_X, and therefore also invalidates
     any EDHOC session where CRED_X was used as authentication credential
     of either peer in the session (i.e., P itself or the other peer).  In
     such a case, the application at P has to additionally delete CRED_X
     and any stored, corresponding credential identifier.

  2.2.  Application Keys Become Invalid

     The application at a peer P may have learned that a set of
     application keys is not safe to use anymore.  When such a set is
     specifically an OSCORE Security Context, the application may have
     learned that from the used OSCORE library or from an OSCORE layer
     that takes part to the communication stack.

     A current set SET of application keys shared with another peer can
     become unsafe to use, for example, due to the following reasons.

     *  SET has reached its pre-determined expiration time; or

     *  SET has been established for a pre-defined, now elapsed amount of
        time, according to enforced application policies; or

     *  Some elements of SET have been used enough times to approach
        cryptographic limits that should not be passed, e.g., according to
        the properties of the specifically used security algorithms.  With
        particular reference to an OSCORE Security Context, such limits
        are discussed in [I-D.ietf-core-oscore-key-limits].

     When this happens, the application at the peer P proceeds as follows.

     1.  If the following conditions both hold, then the application moves
         to step 2.  Otherwise, it moves to step 3.

         *  Let us define S as the EDHOC session from which the peer P has
            derived SET or the eldest SET's ancestor set of application
            keys.  Then, since the completion of S with the other peer,
            the application at P has received from the other peer at least
            one message protected with any set of application keys derived
            from S.  That is, P has persisted S (see Section 5.4.2 of
            [I-D.ietf-lake-edhoc]).








  Tiloca                   Expires 15 August 2024                 [Page 5]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


         *  The peer P supports a key update protocol, as an alternative
            to performing a new execution of EDHOC with the other peer.
            When SET is specifically an OSCORE Security Context, this
            means that the peer P supports the key update protocol KUDOS
            defined in [I-D.ietf-core-oscore-key-update].

     2.  The application at P runs the key update protocol mentioned at
         step 1 with the other peer, in order to update SET.  When SET is
         specifically an OSCORE Security Context, this means that the
         application at P runs KUDOS with the other peer.

         If the key update protocol terminates successfully, the updated
         application keys are installed and no further actions are taken.
         Otherwise, the application at P moves to step 3.

     3.  The application at the peer P performs the following actions.

         *  It deletes SET.

         *  It deletes the EDHOC session from which SET was generated, or
            from which the eldest SET's ancestor set of application keys
            was generated before any key update occurred (e.g., by means
            of the EDHOC_KeyUpdate interface defined in Appendix H of
            [I-D.ietf-lake-edhoc] or other key update methods).

         *  It runs a new execution of the EDHOC protocol with the other
            peer.  Upon successfully completing the EDHOC execution, the
            two peers derive and install a new set of application keys
            from this latest EDHOC session.

     The flowchart in Figure 2 shows the handling of a set of application
     keys that has become invalid.



















  Tiloca                   Expires 15 August 2024                 [Page 6]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


    Invalid application keys

      |
      |
      v
                      NO
    Are the          ----> Delete the application     ----> Rerun
    application keys       keys and the EDHOC session       EDHOC
    persisted?
                                 ^        ^                   |
      |                          |        |                   |
      | YES                      |        |                   v
      v                          |        |
                                 |        |           Derive and install
    Is KUDOS    NO               |        |           new application keys
    supported? ------------------+        |
                                          |
      |                                   |
      | YES                               |
      v                                   |
                                          |
    Run KUDOS                             |
                                          |
      |                                   |
      |                                   |
      v                                   |
                                          |
    Has KUDOS   NO                        |
    succeeded? ---------------------------+

      |
      | YES
      v

    Install the updated
    application keys

       Figure 2: Handling of a set of Application Keys that has Become
                                   Invalid

  2.3.  Application Keys or Bound Access Rights Become Invalid

     The following considers two peers that use the ACE framework for
     authentication and authorization in constrained environments (ACE)
     [RFC9200], and specifically the EDHOC and OSCORE profile of ACE
     defined in [I-D.ietf-ace-edhoc-oscore-profile].





  Tiloca                   Expires 15 August 2024                 [Page 7]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     When doing so, one of the two peers acts as ACE Resource Server (RS)
     hosting protected resources.  The other peer acts as ACE Client,
     requests from an ACE Authorization Server (AS) an Access Token that
     specifies access rights for accessing protected resources at the RS,
     and uploads the Access Token to the RS as part of the ACE workflow.

     Consistent with the used EDHOC and OSCORE profile of ACE, the two
     peers run EDHOC in order to specifically derive an OSCORE Security
     Context as their shared set of application keys (see Appendix A.1 of
     [I-D.ietf-lake-edhoc]).  In particular, the peer acting as ACE Client
     acts as EDHOC Initiator, while the peer acting as ACE RS acts as
     EDHOC Responder (see Section 2 of [I-D.ietf-lake-edhoc]).  The
     successfully completed EDHOC session is bound to the Access Token.

     After that, the peer acting as ACE Client can access the protected
     resources hosted at the other peer, according to the access rights
     specified in the Access Token.  The communications between the two
     peers are protected by means of the established OSCORE Security
     Context, which is also bound to the used Access Token.

     Later on, the application at one of the two peers P may have learned
     that the established OSCORE Security Context CTX is not safe to use
     anymore, e.g., from the used OSCORE library or from an OSCORE layer
     that takes part to the communication stack.  The reasons that make
     CTX not safe to use anymore are the same ones discussed in
     Section 2.2 when considering a set of application keys in general,
     plus the event where the Access Token bound to CTX becomes invalid
     (e.g., it has expired or it has been revoked).

     When this happens, the application at the peer P proceeds as follows.

     1.  If the following conditions both hold, then the application moves
         to step 2.  Otherwise, it moves to step 3.

         *  The Access Token is still valid.  That is, it has not expired
            yet and the peer P is not aware that it has been revoked.

         *  Let us define S as the EDHOC session from which the peer P has
            derived CTX or the eldest CTX's ancestor OSCORE Security
            Context.  Then, since the completion of S with the other peer,
            the application at P has received from the other peer at least
            one message protected with any set of application keys derived
            from S.  That is, P has persisted S (see Section 5.4.2 of
            [I-D.ietf-lake-edhoc]).







  Tiloca                   Expires 15 August 2024                 [Page 8]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     2.  If the peer P supports the key update protocol KUDOS
         [I-D.ietf-core-oscore-key-update], then P runs KUDOS with the
         other peer, in order to update CTX.  If the execution of KUDOS
         terminates successfully, the updated OSCORE Security Context is
         installed and no further actions are taken.

         If the execution of KUDOS does not terminate successfully or if
         the peer P does not support KUDOS altogether, then the
         application at P moves to step 3.

     3.  The application at the peer P performs the following actions.

         *  If the Access Token is not valid anymore, the peer P deletes
            all the EDHOC sessions associated with the Access Token, as
            well as the OSCORE Security Context derived from each of those
            sessions.

            If the peer P acted as ACE Client, then P obtains a new Access
            Token from the ACE AS, and uploads it to the other peer acting
            as ACE RS.

            Finally, the application at P moves to step 4.

         *  If the Access Token is valid while the OSCORE Security Context
            CTX is not, then the peer P deletes CTX.

            After that, the peer P deletes the EDHOC session from which
            CTX was generated, or from which the eldest CTX's ancestor
            OSCORE Security Context was generated before any key update
            occurred (e.g., by means of KUDOS or other key update
            methods).

            Finally, the application at P moves to step 4.

     4.  The peer P runs a new execution of the EDHOC protocol with the
         other peer.  Upon successfully completing the EDHOC execution,
         the two peers derive and install a new OSCORE Security Context
         from this latest EDHOC session.

     The flowchart in Figure 3 shows the handling of an Access Token or of
     a set of application keys that have become invalid.

   Invalid token specifying CRED_I,
   or invalid application keys

     |
     |
     v



  Tiloca                   Expires 15 August 2024                 [Page 9]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


                 NO
   Is the token ----> Delete the associated --> Obtain and --> Rerun ---+
   still valid?       EDHOC sessions and        upload a       EDHOC    |
                      the application keys      new token               |
     |                derived from those                         ^      |
     |                                                           |      |
     | YES                                                       |      |
     v                                                           |      |
                                                                 |      |
   The application keys                                          |      |
   are not valid anymore                                         |      |
                                                                 |      |
     |                                                           |      |
     |                                                           |      |
     v                                                           |      |
                                                                 |      |
   Are the           NO                                          |      |
   application keys -----> Delete the application keys and ------+      |
   persisted?              the associated EDHOC session                 |
                                                                        |
     |                             ^        ^                           |
     | YES                         |        |                           |
     v                             |        |                           |
                                   |        |                           |
   Is KUDOS      NO                |        |                           |
   supported? ---------------------+        |                           v
                                            |
     |                                      |           Derive and install
     | YES                                  |         new application keys
     v                                      |
                                            |
   Run KUDOS                                |
                                            |
     |                                      |
     |                                      |
     v                                      |
                                            |
   Has KUDOS     NO                         |
   succeeded? ------------------------------+

     |
     | YES
     v

   Install the updated
   application keys





  Tiloca                   Expires 15 August 2024                [Page 10]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


      Figure 3: Handling of an Access Token or of a set of Application
                       Keys that have Become Invalid

  3.  Trust Models for Learning New Authentication Credentials

     A peer P relies on authentication credentials of other peers, in
     order to authenticate those peers when running EDHOC with them.

     There are different ways for P to acquire an authentication
     credential CRED of another peer.  For example, CRED can be supplied
     to P out-of-band by a trusted provider.

     Alternatively, CRED can be specified by the other peer during the
     EDHOC execution with P.  This relies on EDHOC message_2 or message_3,
     whose respective ID_CRED_R and ID_CRED_I can specify CRED by value,
     or instead a URI or other external reference where CRED can be
     retrieved from (see Section 3.5.3 of [I-D.ietf-lake-edhoc]).

     Also during the EDHOC execution, an External Authorization Data (EAD)
     field might include an EAD item that specifies CRED by value or
     reference.  This is the case, e.g., for the EAD item defined in
     [I-D.ietf-ace-edhoc-oscore-profile], which is used in the EAD_3 field
     of EDHOC message_3 and transports (a reference to) an Access Token
     that in turn specifies CRED_I by value or by reference.

     When obtaining a new credential CRED, the peer P has to validate it
     before storing it.  The validation steps to perform depend on the
     specific type of CRED (e.g., a public key certificate
     [RFC5280][I-D.ietf-cose-cbor-encoded-cert]), and can rely on (the
     authentication credential of) a trusted third party acting as a trust
     anchor.

     Upon retrieving a new CRED through the processing of a received EDHOC
     message and following the successful validation of CRED, the peer P
     stores CRED only if it assesses CRED to be also trusted, and must not
     store CRED otherwise.

     An exception applies for the two unauthenticated operations described
     in Appendix D.5 of [I-D.ietf-lake-edhoc], where a trust relationship
     with an unknown or not-yet-trusted endpoint is established later.
     That is, CRED is verified out-of-band at a later stage, or an EDHOC
     session key is bound to an identity out-of-band at a later stage.

     If P stores CRED, then P will consider CRED as valid and trusted
     until it possibly becomes invalid, e.g., because it expires or
     because P gains knowledge that it has been revoked.





  Tiloca                   Expires 15 August 2024                [Page 11]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     When storing CRED, the peer P should generate the authentication
     credential identifier(s) corresponding to CRED and store them as
     associated with CRED.  For example, if CRED is a public key
     certificate, an identifier of CRED can be the hash of the
     certificate.  In general, P should generate and associate with CRED
     one corresponding identifier for each type of authentication
     credential identifier that P supports and that is compatible with
     CRED.

     In future executions of EDHOC with the other peer associated with
     CRED, this allows such other peer to specify CRED by reference, e.g.,
     by indicating its credential identifier as ID_CRED_R/ID_CRED_I in the
     EDHOC message_2 or message_3 addressed to the peer P.  In turn, this
     allows P to retrieve CRED from its local storage.

     When processing a received EDHOC message M that specifies an
     authentication credential CRED, the peer P can enforce one of the
     following trust policies in order to determine whether to trust CRED.

     *  NO-LEARNING: according to this policy, the peer P trusts CRED if
        and only if P is already storing CRED at message reception time.

        That is, upon receiving M, the peer P can continue the execution
        of EDHOC only if both the following conditions hold.

        -  P currently stores CRED, as specified by reference or by value
           in ID_CRED_I/ID_CRED_R or in the value of an EAD item; and

        -  CRED is still valid, i.e., P believes CRED to not be expired or
           revoked.

     *  LEARNING: according to this policy, the peer P trusts CRED even if
        P is not already storing CRED at message reception time.

        That is, upon receiving M, the peer P performs the following
        steps.

        1.  P retrieves CRED, as specified by reference or by value in
            ID_CRED_I/ID_CRED_R or in the value of an EAD item.

        2.  P checks whether CRED is already being stored and if it is
            still valid.  In such a case, P trusts CRED and can continue
            the EDHOC execution.  Otherwise, P moves to step 3.

        3.  P attempts to validate CRED.  If the validation process is not
            successful, P aborts the EDHOC session with the other peer.
            Otherwise, P trusts and stores CRED, and can continue the
            EDHOC execution.



  Tiloca                   Expires 15 August 2024                [Page 12]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     Irrespective of the adopted trust policy, P actually uses CRED only
     if it is determined to be fine to use in the context of the ongoing
     EDHOC session, also depending on the specific identity of the other
     peer (see Sections 3.5 and D.2 of [I-D.ietf-lake-edhoc]).  If this is
     not the case, P aborts the EDHOC session with the other peer.

  4.  Side Processing of Incoming EDHOC Messages

     This section describes an approach that EDHOC peers can use upon
     receiving EDHOC messages, in order to fetch/validate authentication
     credentials and to process External Authorization Data (EAD) items.

     As per Section 9.1 of [I-D.ietf-lake-edhoc], the EDHOC protocol
     provides a transport mechanism for conveying EAD items, but
     specifications defining those items have to set the ground for
     "agreeing on the surrounding context and the meaning of the
     information passed to and from the application".

     The approach described in this section aims to help implementors
     navigate the surrounding context mentioned above, irrespective of the
     specific EAD items conveyed in the EDHOC messages.  In particular,
     the described approach takes into account the following points.

     *  The fetching and validation of the other peer's authentication
        credential relies on ID_CRED_I in EDHOC message_2, or on ID_CRED_R
        in EDHOC message_3, or on the value of an EAD item.  When this
        occurs upon receiving EDHOC message_2 or message_3, the decryption
        of the EDHOC message has to be completed first.

        The validation of the other peer's authentication credential might
        depend on using the value of an EAD item, which in turn has to be
        validated first.  For instance, an EAD item within the EAD_2 field
        may contain a voucher to be used for validating the other peer's
        authentication credential (see [I-D.ietf-lake-authz]).

     *  Some EAD items may be processed only after having successfully
        verified the EDHOC message, i.e., after a successful verification
        of the Signature_or_MAC field.

        For instance, an EAD item within the EAD_3 field may contain a
        Certificate Signing Request (CSR) [RFC2986].  Hence, such an EAD
        item can be processed only once the recipient peer has attained
        proof of the other peer possessing its private key.

     In order to conveniently handle such processing, the application can
     prepare in advance one "side-processor object" (SPO), which takes
     care of the operations above during the EDHOC execution.




  Tiloca                   Expires 15 August 2024                [Page 13]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     In particular, the application provides EDHOC with the SPO before
     starting an EDHOC execution, during which EDHOC will temporarily
     transfer control to the SPO at the right point in time, in order to
     perform the required side-processing of an incoming EDHOC message.

     Furthermore, the application has to instruct the SPO about how to
     prepare any EAD item such that: it has to be included in an outgoing
     EDHOC message; and it is independent of the processing of other EAD
     items included in incoming EDHOC messages.  This includes, for
     instance, the preparation of padding EAD items.

     At the right point in time during the processing of an incoming EDHOC
     message M at the peer P, EDHOC invokes the SPO and provides it with
     the following input:

     *  When M is EDHOC message_2 or message_3, an indication of whether
        this invocation is happening before or after the message
        verification (i.e., before or after having verified the
        Signature_or_MAC field).

     *  The full set of information related to the current EDHOC session.
        This especially includes the selected cipher suite and the
        ephemeral Diffie-Hellman public keys G_X and G_Y that the two
        peers have exchanged in the EDHOC session.

     *  The other peers' authentication credentials that the peer P
        stores.

     *  All the decrypted information elements retrieved from M.

     *  The EAD items included in M.

        -  Note that EDHOC might do some preliminary work on M before
           invoking the SPO, in order to provide the SPO only with
           actually relevant EAD items.  This requires the application to
           additionally provide EDHOC with the ead_labels of the EAD items
           that the peer P recognizes (see Section 3.8 of
           [I-D.ietf-lake-edhoc]).

           With such information available, EDHOC can early abort the
           current session in case M includes any EAD item which is both
           critical and not recognized by the peer P.









  Tiloca                   Expires 15 August 2024                [Page 14]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


           If no such EAD items are found, EDHOC can remove any padding
           EAD item (see Section 3.8.1 of [I-D.ietf-lake-edhoc]), as well
           as any EAD item which is neither critical nor recognized (since
           the SPO is going to ignore it anyway).  As a result, EDHOC is
           able to provide the SPO only with EAD items that will be
           recognized and that require actual processing.

        -  Note that, after having processed the EAD items, the SPO might
           actually need to store them throughout the whole EDHOC
           execution, e.g., in order to refer to them also when processing
           later EDHOC messages in the current EDHOC session.

     The SPO performs the following tasks on an incoming EDHOC message M.

     *  The SPO fetches and/or validates the other peer's authentication
        credential CRED, based on a dedicated EAD item of M or on the
        ID_CRED field of M (for EDHOC message_2 or message_3).

     *  The SPO processes the EAD items conveyed in the EAD field of M.

     *  The SPO stores the results of the performed operations, and makes
        such results available to the application.

     *  When the SPO has completed its side processing and transfers
        control back to EDHOC, the SPO provides EDHOC with the produced
        EAD items to include in the EAD field of the next outgoing EDHOC
        message.  The production of such EAD items can be triggered, e.g.,
        by:

        -  The consumption of EAD items included in M; and

        -  The execution of instructions that the SPO has received from
           the application, concerning EAD items to produce irrespective
           of other EAD items included in M.

     The following subsections describe more in detail the actions
     performed by the SPO on the different, incoming EDHOC messages.

  4.1.  EDHOC message_1

     During the processing of an incoming EDHOC message_1, EDHOC invokes
     the SPO only once, after the Responder peer has successfully decoded
     the message and accepted the selected cipher suite.

     If the EAD_1 field is present, the SPO processes the EAD items
     included therein.





  Tiloca                   Expires 15 August 2024                [Page 15]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     Once all such EAD items have been processed the SPO transfers control
     back to EDHOC.  When doing so, the SPO also provides EDHOC with any
     produced EAD items to include in the EAD field of the next outgoing
     EDHOC message.

     Then, EDHOC resumes its execution and advances its protocol state.

  4.2.  EDHOC message_4

     During the processing of an incoming EDHOC message_4, EDHOC invokes
     the SPO only once, after the Initiator peer has successfully
     decrypted the message.

     If the EAD_4 field is present, the SPO processes the EAD items
     included therein.

     Once all such EAD items have been processed, the SPO transfers
     control back to EDHOC, which resumes its execution and advances its
     protocol state.

  4.3.  EDHOC message_2 and message_3

     The following refers to "message_X" as an incoming EDHOC message_2 or
     message_3, and to "message verification" as the verification of
     Signature_or_MAC_X in message_X.

     During the processing of a message_X, EDHOC invokes the SPO two
     times:

     *  Right after message_X has been decrypted and before its
        verification starts.  Following this invocation, the SPO performs
        the actions described in Section 4.3.1.

     *  Right after message_X has been successfully verified.  Following
        this invocation, the SPO performs the actions described in
        Section 4.3.2.

     The flowcharts in Section 4.3.3 show the high-level interaction
     between the core EDHOC processing and the SPO, as well as the
     different steps taken for processing an incoming message_X.

  4.3.1.  Pre-Verification Side Processing

     The pre-verification side processing occurs in two sequential phases,
     namely PHASE_1 and PHASE_2.






  Tiloca                   Expires 15 August 2024                [Page 16]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     PHASE_1 - During PHASE_1, the SPO at the recipient peer P determines
     CRED, i.e., the other peer's authentication credential to use in the
     ongoing EDHOC session.  In particular, the SPO performs the following
     steps.

     1.   The SPO determines CRED based on ID_CRED_X or on an EAD item in
          message_X.

          Those may specify CRED by value or by reference, including a URI
          or other external reference where CRED can be retrieved from.

          If CRED is already installed, the SPO moves to step 2.
          Otherwise, the SPO moves to step 3.

     2.   The SPO determines if the stored CRED is currently valid, e.g.,
          by asserting that CRED has not expired and has not been revoked.

          Performing such a validation may require the SPO to first
          process an EAD item included in message_X.  For example, it can
          be an EAD item in EDHOC message_2, which confirms or revokes the
          validity of CRED_R specified by ID_CRED_R, as the result of an
          OCSP process [RFC6960].

          In case CRED is determined to be valid, the SPO moves to step 9.
          Otherwise, the SPO moves to step 11.

     3.   The SPO attempts to retrieve CRED, and then moves to step 4.

     4.   If the retrieval of CRED has succeeded, the SPO moves to step 5.
          Otherwise, the SPO moves to step 11.

     5.   If the enforced trust policy for new authentication credentials
          is "NO-LEARNING" (see Section 3), the SPO moves to step 11.
          Otherwise, the SPO moves to step 6.

     6.   If this step has been reached, the peer P enforces the trust
          policy "LEARNING" (see Section 3) and it is not already storing
          the retrieved CRED.

          Consistently, the SPO determines if CRED is currently valid,
          e.g., by asserting that CRED has not expired and has not been
          revoked.  Then, the SPO moves to step 7.









  Tiloca                   Expires 15 August 2024                [Page 17]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


          Validating CRED may require the SPO to first process an EAD item
          included in message_X.  For example, it can be an EAD item in
          EDHOC message_2 that: i) specifies a voucher for validating
          CRED_R as a CWT Claims Set (CCS) [RFC8392] transported by value
          in ID_CRED_R (see [I-D.ietf-lake-authz]); or instead ii) an OCSP
          response [RFC6960] for validating CRED_R as a certificate
          transported by value or reference in ID_CRED_R.

     7.   If CRED has been determined valid, the SPO moves to step 8.
          Otherwise, the SPO moves to step 11.

     8.   The SPO stores CRED as a valid and trusted authentication
          credential associated with the other peer, together with
          corresponding authentication credential identifiers (see
          Section 3).  Then, the SPO moves to step 9.

     9.   The SPO checks if CRED is fine to use in the context of the
          ongoing EDHOC session, also depending on the specific identity
          of the other peer (see Sections 3.5 and D.2 of
          [I-D.ietf-lake-edhoc]).

          If this is the case, the SPO moves to step 10.  Otherwise, the
          SPO moves to step 11.

     10.  P uses CRED as authentication credential of the other peer in
          the ongoing EDHOC session.

          Then, PHASE_1 ends, and the pre-verification side processing
          moves to the next PHASE_2 (see below).

     11.  The SPO has not found a valid authentication credential
          associated with the other peer that can be used in the ongoing
          EDHOC session.  Therefore, the EDHOC session with the other peer
          is aborted.

     PHASE_2 - During PHASE_2, the SPO processes any EAD item included in
     message_X such that both the following conditions hold.

     *  The EAD item has _not_ been already processed during PHASE_1.

     *  The EAD item can be processed before performing the verification
        of message_X.

     Once all such EAD items have been processed, the SPO transfers
     control back to EDHOC, which either aborts the ongoing EDHOC session
     or continues the processing of message_X with its corresponding
     message verification.




  Tiloca                   Expires 15 August 2024                [Page 18]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


  4.3.2.  Post-Verification Side Processing

     During the post-verification side processing, the SPO processes any
     EAD item included in message_X such that the processing of that EAD
     item had to wait for completing the successful message verification.

     The late processing of such EAD items is typically due to the fact
     that a pre-requirement has to be fulfilled first.  For example, the
     recipient peer P has to have first asserted that the other peer does
     possess the private key corresponding to the public key of the other
     peer's authentication credential CRED determined during the pre-
     verification side processing (see Section 4.3.1).  This requirement
     is fulfilled after a successful message verification of message_X.

     Once all such EAD items have been processed, the SPO transfers
     control back to EDHOC.  When doing so, the SPO also provides EDHOC
     with any produced EAD items to include in the EAD field of the next
     outgoing EDHOC message.

     Then, EDHOC resumes its execution and advances its protocol state.

  4.3.3.  Flowcharts

     The flowchart in Figure 4 shows the high-level interaction between
     the core EDHOC processing and the SPO, with particular reference to
     an incoming EDHOC message_2 or message_3.

   EDHOC message_X
   (X = 2 or 3)

         |
         |
   +-----|---------------------------------------------------------------+
   |     |                                         Core EDHOC processing |
   |     v                                                               |
   | +-----------+    +----------------+            +----------------+   |
   | | Decode    |--->| Retrieve the   |            | Advance the    |   |
   | | message_X |    | protocol state |            | protocol state |   |
   | +-----------+    +----------------+            +----------------+   |
   |                    |                             ^                  |
   |                    |                             |                  |
   |                    v                             |                  |
   |      +--------------+    +--------------------+  |                  |
   |      | Decrypt      |    | Verify             |  |                  |
   |      | CYPHERTEXT_X |    | Signature_or_MAC_X |  |                  |
   |      +--------------+    +--------------------+  |                  |
   |                |           ^           |         |                  |
   |                |           |           |         |                  |



  Tiloca                   Expires 15 August 2024                [Page 19]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


   +----------------|-----------|-----------|---------|------------------+
                    |           |           |         |
                    |           |           |         | .................
             Divert |      Get  |    Divert |    Get  | : EAD items     :
                    |      back |           |    back | : for the next  :
                    |           |           |         | : EDHOC message :
                    |           |           |         | :...............:
                    |           |           |         |
   +----------------|-----------|-----------|---------|------------------+
   |                |           |           |         |                  |
   |                v           |           v         |                  |
   | +---------------------------+     +-----------------------------+   |
   | | a) Retrieval and          |     | Processing of               |   |
   | |    validation of CRED_X;  |     | post-verification EAD items |   |
   | | b) Trust assessment       |     +-----------------------o-----+   |
   | |    of CRED_X;             |                             |         |
   | | c) Processing of          o-------- Shared state -------o         |
   | |    pre-verification       |                                       |
   | |    EAD items              |        ......................         |
   | |                           |        : Instructions about :         |
   | | - (a) and (c) might have  |        : EAD items to       :         |
   | |   to occur in parallel    |        : unconditionally    :         |
   | | - (b) depends on the      |        : produce for the    :         |
   | |   used trust model        |        : next EDHOC message :         |
   | +---------------------------+        :....................:         |
   |                                                                     |
   |                                               Side-Processor Object |
   +---------------------------------------------------------------------+

          Figure 4: High-Level Interaction Between the Core EDHOC
               Processing and the Side-Processor Object (SPO)

     The flowchart in Figure 5 shows the different steps taken for
     processing an incoming EDHOC message_2 and message_3.

       Incoming
       EDHOC message_X
       (X = 2 or 3)

               |
               |
               v
      +-------------------+
      | Decrypt message_X |  (Core EDHOC Processing)
      +-------------------+
               |
               |




  Tiloca                   Expires 15 August 2024                [Page 20]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


      Control transferred to
      the side-processor object

               |
     +---------|---------------------------------------------------------+
     |         |           Pre-verification side processing (PHASE_1)    |
     |         v                                                         |
     | +---------------------+     +--------------+    +-------------+   |
     | | 1. Does ID_CRED_X   | NO  | 3. Retrieve  |    | 4. Is the   |   |
     | | or an EAD item      |---->| CRED via     |--->| retrieval   |   |
     | | point to an already |     | ID_CRED_X or |    | of CRED     |   |
     | | stored CRED?        |     | an EAD item  |    | successful? |   |
     | +---------------------+     +--------------+    +-------------+   |
     |         |                                        |          |     |
     |         |                                        | NO       | YES |
     |         |                         +--------------+          |     |
     |         | YES                     |                         |     |
     |         v                         v                         v     |
     | +-----------------+ NO      +-----------+  YES +----------------+ |
     | | 2. Is this CRED |-------->| 11. Abort |<-----| 5. Is the      | |
     | | still valid?    |         | the EDHOC |      | used policy    | |
     | +-----------------+         | session   |      | "NO-LEARNING"? | |
     |         |                   |           |      +----------------+ |
     |         | YES               |           |                   |     |
     |         v                   |           |   The used policy | NO  |
     | +--------------------+ NO   |           |   is "LEARNING"   |     |
     | | 9. Is this CRED    |----->|           |                   v     |
     | | good to use in the |      +-----------+         +-------------+ |
     | | context of this    |               ^            | 6. Validate | |
     | | EDHOC session?     |<--+           |            | CRED        | |
     | +--------------------+   |           |            +-------------+ |
     |         |                |           |                      |     |
     |         | YES            |           | NO                   |     |
     |         |                |           |                      v     |
     |         |                |        +-----------------------------+ |
     |         |                |        | 7. Is CRED valid?           | |
     |         |                |        +-----------------------------+ |
     |         |                |           |                            |
     |         |                |           | YES                        |
     |         |                |           v                            |
     |         v                |        +-----------------------------+ |
     | +------------------+     |        | 8. Store CRED as valid and  | |
     | | 10. Continue by  |     +--------| trusted.                    | |
     | | considering this |              |                             | |
     | | CRED as the      |              | Pair CRED with consistent   | |
     | | authentication   |              | credential identifiers, for | |
     | | credential of    |              | each supported type of      | |
     | | the other peer   |              | credential identifier.      | |



  Tiloca                   Expires 15 August 2024                [Page 21]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     | +------------------+              +-----------------------------+ |
     |         |                                                         |
     +---------|---------------------------------------------------------+
               |
               |
     +---------|---------------------------------------------------------+
     |         |           Pre-verification side processing (PHASE_2)    |
     |         v                                                         |
     | +---------------------------------------------------------+       |
     | | Process the EAD items that have not been processed yet, |       |
     | | and that can be processed before message verification   |       |
     | +---------------------------------------------------------+       |
     |         |                                                         |
     +---------|---------------------------------------------------------+
               |
               |

      Control transferred back
      to the core EDHOC processing

               |
               |
               v
      +------------------+
      | Verify message_X | (core EDHOC processing)
      +------------------+
               |
               |

      Control transferred to
      the side-processor object

               |
     +---------|----------------------------------------+
     |         |           Post-verification processing |
     |         v                                        |
     | +---------------------------------------------+  |
     | | Process the EAD items that have to be       |  |
     | | processed (also) after message verification |  |
     | +---------------------------------------------+  |
     |         |                                        |
     |         |                                        |
     |         v                                        |
     | +--------------------------------------------+   |
     | | Make all the results of the EAD processing |   |
     | | available to build the next EDHOC message  |   |
     | +--------------------------------------------+   |
     |         |                                        |



  Tiloca                   Expires 15 August 2024                [Page 22]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     +---------|----------------------------------------+
               |
               |

      Control transferred back
      to the core EDHOC processing

               |
               |
               v
      +----------------+
      | Advance the    | (core EDHOC processing)
      | protocol state |
      +----------------+

          Figure 5: Processing steps for EDHOC message_2 and message_3

  5.  Security Considerations

     TBD

  6.  IANA Considerations

     This document has no actions for IANA.

  7.  References

  7.1.  Normative References

     [I-D.ietf-lake-edhoc]
                Selander, G., Mattsson, J. P., and F. Palombini,
                "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
                Progress, Internet-Draft, draft-ietf-lake-edhoc-23, 22
                January 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-lake-edhoc-23>.

     [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/rfc/rfc2119>.

     [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/rfc/rfc8174>.







  Tiloca                   Expires 15 August 2024                [Page 23]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     [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/rfc/rfc8613>.

  7.2.  Informative References

     [I-D.ietf-ace-edhoc-oscore-profile]
                Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund,
                "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object
                Security for Constrained Environments (OSCORE) Profile for
                Authentication and Authorization for Constrained
                Environments (ACE)", Work in Progress, Internet-Draft,
                draft-ietf-ace-edhoc-oscore-profile-03, 23 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
                edhoc-oscore-profile-03>.

     [I-D.ietf-core-oscore-key-limits]
                Höglund, R. and M. Tiloca, "Key Usage Limits for OSCORE",
                Work in Progress, Internet-Draft, draft-ietf-core-oscore-
                key-limits-02, 10 January 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-core-
                oscore-key-limits-02>.

     [I-D.ietf-core-oscore-key-update]
                Höglund, R. and M. Tiloca, "Key Update for OSCORE
                (KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
                core-oscore-key-update-06, 23 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-core-
                oscore-key-update-06>.

     [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-07, 20 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                cbor-encoded-cert-07>.

     [I-D.ietf-lake-authz]
                Selander, G., Mattsson, J. P., Vučinić, M., and M.
                Richardson, "Lightweight Authorization using Ephemeral
                Diffie-Hellman Over COSE", Work in Progress, Internet-
                Draft, draft-ietf-lake-authz-00, 23 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lake-
                authz-00>.





  Tiloca                   Expires 15 August 2024                [Page 24]


  Internet-Draft   Implementation Considerations for EDHOC   February 2024


     [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                DOI 10.17487/RFC2986, November 2000,
                <https://www.rfc-editor.org/rfc/rfc2986>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and 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/rfc/rfc5280>.

     [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
                Galperin, S., and C. Adams, "X.509 Internet Public Key
                Infrastructure Online Certificate Status Protocol - OCSP",
                RFC 6960, DOI 10.17487/RFC6960, June 2013,
                <https://www.rfc-editor.org/rfc/rfc6960>.

     [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/rfc/rfc8392>.

     [RFC9200]  Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
                H. Tschofenig, "Authentication and Authorization for
                Constrained Environments Using the OAuth 2.0 Framework
                (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9200>.

  Acknowledgments

     The author sincerely thanks Christian Amsüss, Geovane Fedrecheski,
     Rikard Höglund, John Preuß Mattsson, Göran Selander, and Mališa
     Vučinić for their comments and feedback.

  Author's Address

     Marco Tiloca
     RISE AB
     Isafjordsgatan 22
     SE-16440 Stockholm Kista
     Sweden
     Email: marco.tiloca@ri.se










  Tiloca                   Expires 15 August 2024                [Page 25]


name: draft-peterson-mimi-idprover
rev: 00
title: An Identitifier Proof-of-Possession Mechanism
time: 2024-09-05T07:06:22Z
group_uri: /api/v1/group/group/1027/
expires: 2024-09-05T18:21:24Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081824+00:00
source: ietf
abstract:
  This document specifies a means for a third-party service to prove
     and attest the association of a communications platform with a
     particular user's telephone number.  This capability supports secure
     enrollment for users of messaging platforms or similar real-time
     communication applications, for cases where users assert telephone
     numbers as communication identifiers, and interoperating platforms
     need to verify that identifiers are being properly attested.  This
     general approach can potentially work with other forms of Service
     Independent Identifiers (SIIs) in the More Instant Messaging
     Interoperability (MIMI) framework.

full_text:
  Network Working Group                                        J. Peterson
  Internet-Draft                                                TransUnion
  Intended status: Standards Track                            4 March 2024
  Expires: 5 September 2024


               An Identitifier Proof-of-Possession Mechanism
                      draft-peterson-mimi-idprover-00

  Abstract

     This document specifies a means for a third-party service to prove
     and attest the association of a communications platform with a
     particular user's telephone number.  This capability supports secure
     enrollment for users of messaging platforms or similar real-time
     communication applications, for cases where users assert telephone
     numbers as communication identifiers, and interoperating platforms
     need to verify that identifiers are being properly attested.  This
     general approach can potentially work with other forms of Service
     Independent Identifiers (SIIs) in the More Instant Messaging
     Interoperability (MIMI) framework.

  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 5 September 2024.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights



  Peterson                Expires 5 September 2024                [Page 1]


  Internet-Draft                  ID Prover                     March 2024


     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Overview of Operations  . . . . . . . . . . . . . . . . . . .   3
     4.  ACME Behavior . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
       10.2.  Informative References . . . . . . . . . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     Many applications and platforms rely the receipt of a text message,
     typically a Short Messaging Service (SMS) (typically [SMPP]) message,
     to enable users to prove their control or ownership of a telephone
     number.  During enrollment with a platform, services will send an SMS
     to the user's asserted telephone number containing a code or one-time
     URL; by interacting with that resource, the user proves receipt of
     the SMS, and thus validates the association of their telephone number
     with their account on that service.  Resources sent via SMS may be
     used continually after enrollment as a two-factor authentication
     (TFA) systems.

     While this mechanism may be sufficient to prove to the service in
     question that a user controls a telephone number, it does not help
     services prove to other services that users control telephone numbers
     and can legitimately assert them as identifiers in communications
     systems.  For example, if Alice enrolls a telephone number with
     Platform A, and uses that telephone number as her identifier for a
     messaging service communicating with Bob on Platform B, Platform B
     has no way of validating how or if Platform A verified Alice's
     telephone number.

     This issue arises in interoperable messaging systems that use Service
     Independent Identifiers (SIIs) as defined in
     [I-D.rosenberg-mimi-discovery-reqs], and in particular telephone
     numbers as SIIs.  There is a need in interoperable messaging for



  Peterson                Expires 5 September 2024                [Page 2]


  Internet-Draft                  ID Prover                     March 2024


     users to be able to assert an SII as an identity, per
     [I-D.mahy-mimi-identity], in a way that multiple platforms can rely
     on.  While this is often straightforward for Service Specific
     Identifiers (SSIs) of the form "user@example.com", where clearly
     "example.com" should can attest to the users of its service, it is
     more difficult for SIIs, as such identifiers are often not issued or
     controlled by the messaging platform.  This specification thus
     describes a service that can be invoked by a communications platform
     to validate a platform user's control of an SII in order to create a
     publicly-verifiable credential asserting te platform's association
     with the SII.  As prior work for X.509 credentials has been done
     along similar lines for ACME [RFC8555], this document builds on the
     existing ACME framework for telephone numbers [RFC9448].

     This mechanism might be used to prove possession of SIIs other than
     telephone numbers, including email addresses.  Moreover, this
     mechanism could be applied to proving identifiers for communications
     other than textual messaging, including most forms of real-time
     communications (e.g.  STIR [RFC8224]).  Note that the aim of this
     document is not to prove the assignment and delegation of resources
     in the telephone network: it is instead to establish whether
     Internet-enabled entites have effective control over the devices
     associated with those resources.  Such credentials are not mutually
     exclusive with credentials delegated from national authorities.

     Because the assignment of numbering resources can change over time,
     demonstrations of effective control must be regularly refreshed --
     though because of the diverse capabilities of the devices involved,
     different schemes for refreshing the challenge, ones that require
     less direct user supervision, may be available to some devices and
     not others.

  2.  Terminology

     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.

  3.  Overview of Operations

     The following details the basic flow of this identity proving
     mechanism.  Assume a case where a user, either a new user or an
     existing one updating their account, is interacting with a platform
     via an appp or over a web interface, and attempting to associate a
     new telephone number with their account.  The exact methods that
     platforms use to communicate with users in steps 1, 2, and 6 below



  Peterson                Expires 5 September 2024                [Page 3]


  Internet-Draft                  ID Prover                     March 2024


     are outside the scope of this document.

     *  A user enrolling with a communications platform asserts their
        ownership of the telephone number to the platform

     *  The platform instructs the user to await an SMS with a code

     *  Simultaneously, the platform contacts an ACME server with a new
        order for that telephone number

     *  The ACME server issues a challenge to the platform that requires a
        code to complete

     *  In parallel, the ACME server also sends an SMS with the code to
        the asserted telephone number (without sharing that code with the
        platform)

     *  Upon receipt of the code, the user inputs the code to the
        communications platform

     *  The platform then responds to the ACME challenge with the code

     *  Provided the challenge is correctly answered, the ACME platform
        issues the certificate to the communications platform

     At the end of this process, the platform has a certificate that could
     be to assert that SII identity in communication (per
     [I-D.mahy-mimi-identity]), as well as in support of various discovery
     functions as described in [I-D.rosenberg-mimi-discovery-reqs].  Any
     relying parties who trust the identity proving service can trust that
     the platform can assert the telephone number in question, and that
     the user of that SII is reachable at the platform.  Subordinate
     certificates of various kinds could then be issued to the enrolling
     user by the platform for various end-to-end security functions.

  4.  ACME Behavior

     New-order requests issued by platforms to ACME servers in this
     specification MUST utilize the TNAuthList ACME identifier type
     [RFC9448], with a TNAuthList value of a single telephone number.
     From there, the ACME flow follows that of [RFC8823], although it uses
     a new ACME challenge type identifier here, "sms-link-00."

        type (required, string): The string "sms-link-00"







  Peterson                Expires 5 September 2024                [Page 4]


  Internet-Draft                  ID Prover                     March 2024


        token (required, string): A random value that uniquely identifies
        the challenge.  This value MUST have at least 128 bits of entropy,
        in order to prevent an attacker from guessing it.  It MUST NOT
        contain any characters outside the URL-safe Base64 alphabet and
        MUST NOT contain any padding characters ("=").

     {
       "type": "sms-link-00",
     }

     A client's response to this challenge simply acknowledges that it is
     ready to receive the validation SMS from the server.

     On receiving a response, the identity proving service sends an SMS
     message to the TN being validated containing a code that the client
     must have a user access in order to complete the challenge.  This
     code is intended to be relayed to the platform to complete the ACME
     challenge.  By allowing a user action to complete the challenge, this
     validation method supports the use of ACME with SMS endpoints that do
     not support automated response to challenges; handset support for
     automated responses to these challenges is outside the scope of this
     document.  The use of six-digit numeric codes is however weidely
     supported for automatic responses on handsets today.

  5.  Example

     TBD.

  6.  Acknowledgments

     This document incorporates ideas and text from
     [I-D.ietf-acme-telephone].  Thanks as well go to Jonathan Rosenberg
     for his work on these ideas.

  7.  IANA Considerations

     TBD.

  8.  Privacy Considerations

     TBD.

  9.  Security Considerations

     TBD.

  10.  References




  Peterson                Expires 5 September 2024                [Page 5]


  Internet-Draft                  ID Prover                     March 2024


  10.1.  Normative References

     [I-D.barnes-mimi-arch]
                Barnes, R. L., "An Architecture for More Instant Messaging
                Interoperability (MIMI)", Work in Progress, Internet-
                Draft, draft-barnes-mimi-arch-03, 4 March 2024,
                <https://datatracker.ietf.org/api/v1/doc/document/draft-
                barnes-mimi-arch/>.

     [I-D.ietf-acme-telephone]
                Peterson, J. and R. Barnes, "ACME Identifiers and
                Challenges for Telephone Numbers", Work in Progress,
                Internet-Draft, draft-ietf-acme-telephone-01, 30 October
                2017, <https://datatracker.ietf.org/doc/html/draft-ietf-
                acme-telephone-01>.

     [I-D.mahy-mimi-identity]
                Mahy, R., "More Instant Messaging Interoperability (MIMI)
                Identity Concepts", Work in Progress, Internet-Draft,
                draft-mahy-mimi-identity-02, 10 July 2023,
                <https://datatracker.ietf.org/doc/html/draft-mahy-mimi-
                identity-02>.

     [I-D.rosenberg-mimi-discovery-reqs]
                Rosenberg, J., "MIMI Discovery Requirements and
                Considerations", Work in Progress, Internet-Draft, draft-
                rosenberg-mimi-discovery-reqs-00, 27 August 2023,
                <https://datatracker.ietf.org/doc/html/draft-rosenberg-
                mimi-discovery-reqs-00>.

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

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

     [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
                "Authenticated Identity Management in the Session
                Initiation Protocol (SIP)", RFC 8224,
                DOI 10.17487/RFC8224, February 2018,
                <https://www.rfc-editor.org/info/rfc8224>.







  Peterson                Expires 5 September 2024                [Page 6]


  Internet-Draft                  ID Prover                     March 2024


     [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
                Kasten, "Automatic Certificate Management Environment
                (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
                <https://www.rfc-editor.org/info/rfc8555>.

     [RFC8823]  Melnikov, A., "Extensions to Automatic Certificate
                Management Environment for End-User S/MIME Certificates",
                RFC 8823, DOI 10.17487/RFC8823, April 2021,
                <https://www.rfc-editor.org/info/rfc8823>.

     [RFC9448]  Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
                "TNAuthList Profile of Automated Certificate Management
                Environment (ACME) Authority Token", RFC 9448,
                DOI 10.17487/RFC9448, September 2023,
                <https://www.rfc-editor.org/info/rfc9448>.

  10.2.  Informative References

     [SMPP]     SMS Forum v5.0 | 19 February 2003, "Short Message Peer to
                Peer Protocol Specification", 2003.

  Author's Address

     Jon Peterson
     TransUnion
     Email: jon.peterson@transunion.com

























  Peterson                Expires 5 September 2024                [Page 7]


name: draft-song-lake-ra
rev: 02
title: Remote attestation over EDHOC
time: 2025-01-13T10:54:19Z
group_uri: /api/v1/group/group/2249/
expires: 2025-04-24T17:47:24Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/35/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081828+00:00
source: ietf
abstract:
  This document specifies how to perform remote attestation as part of
     the lightweight authenticated Diffie-Hellman key exchange protocol
     EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote
     ATtestation procedureS (RATS) architecture.

full_text:
  Lightweight Authenticated Key Exchange                           Y. Song
  Internet-Draft                                                     Inria
  Intended status: Standards Track                         21 October 2024
  Expires: 24 April 2025


                       Remote attestation over EDHOC
                           draft-song-lake-ra-02

  Abstract

     This document specifies how to perform remote attestation as part of
     the lightweight authenticated Diffie-Hellman key exchange protocol
     EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote
     ATtestation procedureS (RATS) architecture.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://ysong02.github.io/RemoteAttestation_overEDHOC/draft-song-
     lake-ra.html.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-song-lake-ra/.

     Discussion of this document takes place on the Lightweight
     Authenticated Key Exchange Working Group mailing list
     (mailto:lake@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/lake/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/lake/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ysong02/RemoteAttestation_overEDHOC.

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



  Song                      Expires 24 April 2025                 [Page 1]


  Internet-Draft                  RA-EDHOC                    October 2024


     This Internet-Draft will expire on 24 April 2025.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Remote Attestation in EDHOC . . . . . . . . . . . . . . . . .   6
       5.1.  Target  . . . . . . . . . . . . . . . . . . . . . . . . .   6
         5.1.1.  IoT Device Attestation (IoT)  . . . . . . . . . . . .   6
         5.1.2.  Network Service Attestation (Net) . . . . . . . . . .   6
       5.2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .   6
         5.2.1.  Background-check Model (BG) . . . . . . . . . . . . .   6
         5.2.2.  Passport Model (PP) . . . . . . . . . . . . . . . . .   9
       5.3.  EDHOC Message Flow  . . . . . . . . . . . . . . . . . . .  12
         5.3.1.  EDHOC Forward Message Flow (Fwd)  . . . . . . . . . .  12
         5.3.2.  EDHOC Reverse Message Flow (Rev)  . . . . . . . . . .  12
     6.  Instantiation of Remote Attestation Protocol  . . . . . . . .  12
       6.1.  (IoT, BG, Fwd): IoT Device Attestation  . . . . . . . . .  12
       6.2.  (Net, PP, Fwd): Network Service Attestation . . . . . . .  14
     7.  Mutual Attestation in EDHOC . . . . . . . . . . . . . . . . .  15
       7.1.  (IoT, BG, Fwd) - (Net, PP, Fwd) . . . . . . . . . . . . .  16
     8.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  18
       8.1.  EDHOC Error "Attestation failed"  . . . . . . . . . . . .  18
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
       10.1.  EDHOC External Authorization Data Registry . . . . . . .  19
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  20
       11.2.  Informative References . . . . . . . . . . . . . . . . .  20
     Appendix A.  Example: Remote Attestation Flow . . . . . . . . . .  21
     Appendix B.  Remote attestation in parallel with enrollment
             authorization . . . . . . . . . . . . . . . . . . . . . .  23



  Song                      Expires 24 April 2025                 [Page 2]


  Internet-Draft                  RA-EDHOC                    October 2024


     Appendix C.  Example: Firmware Version  . . . . . . . . . . . . .  23
     Appendix D.  Open discussion: remote attestation over EDHOC/ over
             OSCORE  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  25
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

  1.  Introduction

     Remote attestation is a security process which verifies and confirms
     the integrity and trustworthiness of a remote device or system in the
     network.  This process helps establish a level of trust in the remote
     system before allowing the device to e.g. join the network or get
     access to some sensitive information and resources.  The use cases
     that require remote attestation include secure boot and firmware
     management, cloud computing, network access control, etc.

     The IETF working group Remote ATtestation procedureS (RATS) has
     defined an architecture [RFC9334] for remote attestation.  The three
     main roles in the RATS architecture are the Attester, the Verifier
     and the Relying Party.  The Attester generates the evidence
     concerning its identity and integrity, which must be appraised by the
     Verifier for its validity.  Then, the Verifier produces the
     attestation result, which is consequently used by the Relying Party
     for the purposes of reliably applying application-specific actions.

     One type of interaction model defined in the RATS architecture is
     called the background-check model.  It resembles the procedure of how
     employers perform background checks to determine the prospective
     employee's trustworthiness, by contacting the respective organization
     that issues a report.  In this case, the employer acts as the Relying
     Party, the employee acts as the Attester and the organization acts as
     the Verifier.  The Attester conveys evidence directly to the Relying
     Party and the Relying Party forwards the evidence to the Verifier for
     appraisal.  Once the attestation result is computed by the Verifier,
     it is sent back to the Relying Party to decide what action to take
     based on the attestation result.  Another model is called passport
     model, where the Attester communicates directly with the Verifier.
     The Attester presents the evidence to the Verifier and gets an
     attestation result from the Verifier.  Then the Attester conveys the
     attestation result to the Relying Party.  This specification employs
     both the RATS background-check model and the passport model.










  Song                      Expires 24 April 2025                 [Page 3]


  Internet-Draft                  RA-EDHOC                    October 2024


     This document specifies the protocol between the Attester and the
     Relying Party.  The details of the protocol between the Relying Party
     and the Verifier in the background-check model, and the protocol
     between the Attester and the Verifier in the passport model are out
     of the scope.  This communication may be secured through protocols
     such as EDHOC, TLS or other security protocols that support the
     secure transmission to and from the Verifier.

     One way of conveying attestation evidence or the attestation result
     is the Entity Attestation Token (EAT) [I-D.ietf-rats-eat].  It
     provides an attested claims set which can be used to determine a
     level of trustworthiness.  This specification relies on the EAT as
     the format for attestation evidence and the attestation result.

     Ephemeral Diffie-Hellman over COSE (EDHOC) [RFC9528] is a lightweight
     authenticated key exchange protocol for highly constrained networks.
     In EDHOC, the two parties involved in the key exchange are referred
     to as the Initiator (I) and the Responder (R).  EDHOC supports the
     transport of external authorization data, through the dedicated EAD
     fields.  This specification delivers EAT through EDHOC.
     Specifically, EAT is transported as an EAD item.  This specification
     also defines new EAD items needed to perform remote attesation over
     EDHOC in Section 5.2.1.1 and Section 5.2.2.1.

     For the generation of evidence, the Attester incorporates an internal
     attestation service, including a specific trusted element known as
     the "root of trust".  Root of trust serves as the starting point for
     establishing and validating the trustworthiness appraisals of other
     components on the system.  The measurements signed by the attestation
     service are referred to as the Evidence.  The signing is requested
     through an attestation API.  How the components are separated between
     the secure and non-secure worlds on a device is out of scope of this
     specification.

  2.  Conventions and Definitions

     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.

     The reader is assumed to be familiar with the terms and concepts
     defined in EDHOC [RFC9528] and RATS architecture [RFC9334].







  Song                      Expires 24 April 2025                 [Page 4]


  Internet-Draft                  RA-EDHOC                    October 2024


  3.  Overview

     This specification describes how to perform remote attestation over
     the EDHOC protocol, following the RATS architecture.  EDHOC provides
     the benefit of minimal message overhead and reduced round trips for a
     lightweight authentication.  More importantly, by integrating remote
     attestation with EDHOC, attestation can be run in parallel with
     authentication, improving the efficiency and maintaining lightweight
     properties.

     Remote attestation protocol elements are carried within EDHOC's
     External Authorization Data (EAD) fields.  EDHOC [RFC9528] supports
     one or more EAD items in each EAD field.

     In Section 5, this document defines three independent dimensions for
     performing remote attestation over EDHOC:

     1.  Target (see Section 5.1) defining the entity that undergoes the
         attestation process (IoT device or network service).

     2.  Model (see Section 5.2) defining the attestation model in use
         based on the RATS architecture (background-check model or
         passport model).

     3.  Message Flow (see Section 5.3) defining the EDHOC message flow in
         use (forward message flow or reverse message flow).

     This document specifies the cases that are suited for constrained IoT
     environments.

     EDITOR NOTE: add an overview figure

  4.  Assumptions

     In background-check model, one assumption is that the Verifier
     outputs a fresh nonce and that same nonce is passed on to the EDHOC
     session.  The Verifier is assumed to know how to verify multiple
     formats of the evidence type.  This specification assumes that the
     Relying Party also has knowledge about the Attester, so it can narrow
     down the evidence type selection and send to the Attester only one
     format of the evidence type.  The Attester should have an explicit
     relation with the Verifier, such as from device manufacturing, so
     that the Verifier can evaluate the Evidence that is produced by the
     Attester.







  Song                      Expires 24 April 2025                 [Page 5]


  Internet-Draft                  RA-EDHOC                    October 2024


     In the passport model, the credential identity of the Verifier is
     assumed to be stored at the Attester and the Relying Party, which
     means the Verifier is trusted by the Attester and the Relying Party
     to obtain the attestation result.

     EDITOR NOTE: add attestation public key stored in Verifier

  5.  Remote Attestation in EDHOC

     This section specifies three independent dimensions that characterize
     the remote attestation process over EDHOC.

  5.1.  Target

     Defines the entity that undergoes the attestation process.

  5.1.1.  IoT Device Attestation (IoT)

     The IoT device acts as the Attester.

  5.1.2.  Network Service Attestation (Net)

     The network service acts as the Attester.

     Unlike IoT devices, network services typically have more
     computational power and capabilities, enabling them to handle complex
     attestation processes when more demanding tasks are required of the
     Attester.

  5.2.  Model

     Defines the attestation models based on RATS architecture.  This
     specification supports both the RATS background-check model (see
     Section 5.2.1) and the passport model (see Section 5.2.2).  The
     corresponding EAD items for background-check model and the passport
     model are independent of each other.  The EAD items are specified in
     Section 5.2.1.1 for the background-check model and in Section 5.2.2.1
     for the passport model.

  5.2.1.  Background-check Model (BG)

     In the background-check model, the Attester sends the evidence to the
     Relying Party.  The Relying Party transfers the evidence to the
     Verifier and gets back the attestation result from the Verifier.







  Song                      Expires 24 April 2025                 [Page 6]


  Internet-Draft                  RA-EDHOC                    October 2024


     An EDHOC session is established between the Attester and the Relying
     Party.  A negotiation of the evidence type is required before the
     Attester sends the evidence.  All three parties must agree on a
     selected evidence type.

     The Attester first sends a list of the proposed evidence types to the
     Relying Party.  The list is formatted as an Attestation proposal in
     an EDHOC EAD item.  The Relying Party relays the list to the Verifier
     and receives at least one supported evidence type from the Verifier
     in return.  If the Relying Party receives more than one evidence
     type, a single evidence type should be selected by the Relying Party
     based on its knowledge of the Attester.  The Relying Party then sends
     it back within the Attestation request to the Attester.

     A nonce, at least 8-bytes long [I-D.ietf-rats-eat]), guarantees the
     freshness of the attestation session.  The nonce is generated by the
     Verifier and sent to the Relying Party.  The Relying Party puts the
     nonce and the selected evidence type together in a tuple to generate
     an Attestation request.

     Once the Attester receives the Attestation request, it can call its
     attestation service to generate the evidence, with the nonce value as
     one of the inputs.

  5.2.1.1.  External Authorization Data (EAD) Items for background-check
            model

     EAD items that are used for the background-check model are defined in
     this section.

  5.2.1.1.1.  Attestation_proposal

     To propose a list of provided evidence types in background-check
     model, the Attester transports the Proposed_EvidenceType object.  It
     signals to the Relying Party the proposal to do remote attestation,
     as well as which types of the attestation claims the Attester
     supports.  The Proposed_EvidenceType is encoded in CBOR in the form
     of a sequence.

     The EAD item for an attestation proposal is:

     *  ead_label = TBD1

     *  ead_value = Attestation_proposal, which is a CBOR byte string:







  Song                      Expires 24 April 2025                 [Page 7]


  Internet-Draft                  RA-EDHOC                    October 2024


     Attestation_proposal = bstr .cbor Proposed_EvidenceType

     Proposed_EvidenceType = [ + content-format ]

     content-format = uint

     where

     *  Proposed_EvidenceType is an array that contains all the supported
        evidence types by the Attester.

     *  There MUST be at least one item in the array.

     *  content-format is an indicator of the format type (e.g.,
        application/eat+cwt with an appropriate eat_profile parameter
        set), from [IANA-CoAP-Content-Formats].

     The sign of ead_label TBD1 MUST be negative to indicate that the EAD
     item is critical.  If the receiver cannot recognize the critical EAD
     item, or cannot process the information in the critical EAD item,
     then the receiver MUST send an EDHOC error message back as defined in
     Section 6 of [RFC9528].

  5.2.1.1.2.  Attestation_request

     As a response to the attestation proposal, the Relying Party signals
     to the Attester the supported and requested evidence type.  In case
     none of the evidence types is supported, the Relying Party rejects
     the first message_1 with an error indicating support for another
     evidence type.

     The EAD item for an attestation request is:

     *  ead_label = TBD1

     *  ead_value = Attestation_request, which is a CBOR byte string:

     Attestation_request = bstr .cbor Selected_EvidenceType

     Selected_EvidenceType = (
       content-format: uint,
       nonce: bstr .size 8..64
     )

     where

     *  content-format is the selected evidence type by the Relying Party
        and supported by the Verifier.



  Song                      Expires 24 April 2025                 [Page 8]


  Internet-Draft                  RA-EDHOC                    October 2024


     *  nonce is generated by the Verifier and forwarded by the Relying
        Party.

     The sign of ead_label TBD2 MUST be negative to indicate that the EAD
     item is critical.  If the receiver cannot recognize the critical EAD
     item, or cannot process the information in the critical EAD item,
     then the receiver MUST send an EDHOC error message back as defined in
     Section 6 of [RFC9528].

  5.2.1.1.3.  Evidence

     As a response to the attestation request, the Attester calls its
     local attestation service to generate and return the serialized EAT
     [I-D.ietf-rats-eat] as Evidence.

     The EAD item is:

     *  ead_label = TBD1

     *  ead_value is a serialized EAT.

     EAT is specified in [I-D.ietf-rats-eat].

  5.2.1.1.4.  trigger_bg

     The EAD item trigger_bg is used when the sender triggers the receiver
     to start a remote attestation in the background-check model.  The
     receiver MUST reply with an EAD item corresponding to the background-
     check model.  The ead_value can be empty, as the ead_label serves as
     the trigger.

     The EAD item is:

     *  ead_label = TBD2

     *  ead_value = null

  5.2.2.  Passport Model (PP)

     In the passport model, the Attester sends the evidence to the
     Verifier.  After the Attester receives the attestation result from
     the Verifier, the Attester sends the attestation result to the
     Relying Party.

     An EDHOC session is established between the Attester and the Relying
     Party.  The Attester and the Relying Party should decide from which
     Verifier the Attester obtains the attestation result and transfers it
     to the Relying Party.  The Attester first sends a list of the



  Song                      Expires 24 April 2025                 [Page 9]


  Internet-Draft                  RA-EDHOC                    October 2024


     Verifier identities that it can get the attestation result.  The
     Relying Party selects one trusted Verifier identity and sends it back
     as a Result request.

     Regarding the freshness in passport model, the Attester could either
     establish a real-time connection with the selected Verifier, or use a
     pre-stored attestation result from the selected Verifier.  If the
     attestation result is not obtained via a real-time connection, it
     should include a time stamp and/or expiry time to indicate its
     validity.  Time synchronization is out of scope of this
     specification.

     Once the Attester obtains the attestation result from the selected
     Verifier, it sends the attestation result to the Relying Party.

  5.2.2.1.  External Authorization Data (EAD) Items for passport model

     EAD items that are used for the passport model are defined in this
     section.

  5.2.2.1.1.  Result_proposal

     An attestation result proposal contains the identification of the
     credentials of the Verifiers to indicate Verifiers' indentities.  The
     identification of credentials relies on COSE header parameters
     [IANA-COSE-Header-Parameters], with a header label and credential
     value.

     The EAD item for the attestation result proposal is:

     *  ead_label = TBD3

     *  ead_value = Result_proposal, which is a CBOR byte string:

     Result_proposal = bstr .cbor Proposed_VerifierIdentity
     Proposed_VerifierIdentity = [ + VerifierIdentity ]

     VerifierIdentity = {
       label => values
     }

     where

     *  Proposed_VerifierIdentity is defined as a list of one or more
        VerifierIdentity elements.

     *  Each VerifierIdentity within the list is a map defined in
        [IANA-COSE-Header-Parameters] that:



  Song                      Expires 24 April 2025                [Page 10]


  Internet-Draft                  RA-EDHOC                    October 2024


        -  label = int / tstr

        -  values = any

  5.2.2.1.2.  Result_request

     As a response to the attestation result proposal, the Relying Party
     signals to the Attester the trusted Verifier.  In case none of the
     Verifiers can be trusted by the Relying Party, the session is
     aborted.  Relying Party generates a nonce to ensure the freshness of
     the attestation result from the Verifier.

     The EAD item for an attestation result request is:

     *  ead_label = TBD3

     *  ead_value = Result_request, which is a CBOR byte string:

     Result_request = bstr .cbor Request_structure

     Request_structure = {
       selected_verifier: VerfierIdentity
     }

  5.2.2.1.3.  Result

     The attestation result is generated and signed by the Verifier as a
     serialized EAT [I-D.ietf-rats-eat].  The Relying Party can decide
     what action to take with regards to the Attester based on the
     information elements in attetation result.

     The EAD item is:

     *  ead_label = TBD3

     *  ead_value is a serialized EAT.

  5.2.2.1.4.  trigger_pp

     The EAD item trigger_pp is used when the sender triggers the receiver
     to start a remote attestation in the passport model.  The receiver
     MUST reply with an EAD item correspondign to the passport model.  The
     ead_value can be empty, as the ead_label serves as the trigger.

     The EAD item is:

     *  ead_label = TBD4




  Song                      Expires 24 April 2025                [Page 11]


  Internet-Draft                  RA-EDHOC                    October 2024


     *  ead_value = null

  5.3.  EDHOC Message Flow

     The EDHOC protocol defines two possible message flows, namely the
     EDHOC forward message flow and the EDHOC reverse message flow (see
     Appendix A.2.2 of [RFC9528]).  In this specification, both flows can
     be used to perform remote attestation.

  5.3.1.  EDHOC Forward Message Flow (Fwd)

     In forward message flow, EDHOC may run with the Initiator as a CoAP/
     HTTP client.  Remote attestation over EDHOC starts with a POST
     requests to the Uri-Path: "/.well-known/lake-ra".

  5.3.2.  EDHOC Reverse Message Flow (Rev)

     In the reverse message flow, the CoAP/HTTP client is the Responder
     and the server is the Initiator.  A new EDHOC session begins with an
     empty POST request to the server's resource for EDHOC.

  6.  Instantiation of Remote Attestation Protocol

     We use the format (Target, Model, Message Flow) to denote
     instantiations.  For example, (IoT, BG, Fwd) represents IoT device
     attestation using the background-check model with forward EDHOC
     message flow.

     Although there are 8 cases (IoT/Net, BG/PP, Fwd/Rev), this document
     specifies the most relevant instantiations for constrained IoT
     environments.

  6.1.  (IoT, BG, Fwd): IoT Device Attestation

     A common use case for (IoT, BG, Fwd) is to attest an IoT device to a
     network server.  For example, doing remote attestation to verify that
     the latest version of firmware is running on the IoT device before
     the network server allows it to join the network (see Appendix C).

     An overview of doing IoT device attestation in background-check model
     and EDHOC forward message flow is established in Figure 1.  EDHOC
     Initiator plays the role of the RATS Attester (A).  EDHOC Responder
     plays the role of the RATS Relying Party (RP).  The Attester and the
     Relying Party communicate by transporting messages within EDHOC's
     External Authorization Data (EAD) fields.  An external entity, out of
     scope of this specification, plays the role of the RATS Verifier (V).
     The EAD items specific to the background-check model are defined in
     Section 5.2.1.1.



  Song                      Expires 24 April 2025                [Page 12]


  Internet-Draft                  RA-EDHOC                    October 2024


     The Attester starts the attestation by sending an Attestation
     proposal in EDHOC message_1.  The Relying Party generates EAD_2 with
     the received evidence type and nonce from the Verifier, and sends it
     to the Attester.  The Attester sends the Evidence to the Relying
     Party in EAD_3.  The Verifier evaluates the Evidence and sends the
     Attestation result to the Relying Party.

  +-----------------+              +-----------------+
  |   IoT device    |              | Network service |
  +-----------------+              +-----------------+
  | EDHOC Initiator |              | EDHOC Responder |
  +-----------------+              +-----------------+            +----------+
  |     Attester    |              |  Relying Party  |            | Verifier |
  +--------+--------+              +--------+--------+            +-----+----+
           |                                |                           |
           |  EAD_1 = Attestation proposal  |                           |
           +------------------------------->|                           |
           |                                |                           |
           |                                | Attestation proposal, C_R |
           |                                +-------------------------->|
           |                                |<--------------------------+
           |                                |  EvidenceType(s), Nonce   |
           |                                |                           |
           |  EAD_2 = Attestation request   |                           |
           |<-------------------------------+                           |
           |                                |                           |
           |  EAD_3 = Evidence              |                           |
           +------------------------------->|                           |
           |                                |      Evidence, C_R        |
           |                                +-------------------------->|
           |                                |<--------------------------+
           |                                |    Attestation result     |
           |                                |                           |
           |                                |                           |
           |                                |                           |
           | <----------------------------> |                           |
           |         EDHOC session          |                           |

     Figure 1: Overview of IoT device attestation in background-check
      model and EDHOC forward message flow.  EDHOC is used between A
                                 and RP.










  Song                      Expires 24 April 2025                [Page 13]


  Internet-Draft                  RA-EDHOC                    October 2024


  6.2.  (Net, PP, Fwd): Network Service Attestation

     One use case for (Net, PP, Fwd) is when a network server needs to
     attest itself to a client (e.g., an IoT device).  For example, the
     client needs to send some sensitive data to the network server, which
     requires the network server to be attested first.  In (Net, PP, Fwd),
     the network server acts as an Attester and the client acts as a
     Relying Party.

     An overview of the message flow is illustrated in Figure 2.  EDHOC
     Initiator plays the role of the RATS Relying Party.  EDHOC Responder
     plays the role of the RATS Attester.  An external entity, out of
     scope of this specification, plays the role of the RATS Verifier.
     The EAD items specific to the passport model are defined in
     Section 5.2.2.1.

     The Relying Party asks the Attester to do a remote attestation by
     sending a trigger_pp (see Section 5.2.2.1.4) in EDHOC message_1.  The
     Attester replies to the Relying Party with a Result proposal in
     EAD_2.  Then the Relying Party selects a trusted Verifier identity
     and sends it as a Result request.  How the Attester negotiates with
     the selected Verifier to get the attestation result is out of scope
     of this specification.  A fourth EDHOC message is required to send
     the Result from the Attester to the Relying Party.



























  Song                      Expires 24 April 2025                [Page 14]


  Internet-Draft                  RA-EDHOC                    October 2024


  +-----------------+          +-----------------+
  |   IoT device    |          | Network service |
  +-----------------+          +-----------------+
  | EDHOC Initiator |          | EDHOC Responder |
  +-----------------+          +-----------------+            +----------+
  |  Relying Party  |          |     Attester    |            | Verifier |
  +--------+--------+          +--------+--------+            +-----+----+
           |                            |                           |
           |  EAD_1 = trigger_PP        |                           |
           +--------------------------->|                           |
           |                            |                           |
           |  EAD_2 = Result proposal   |                           |
           |<---------------------------+                           |
           |                            |                           |
           |  EAD_3 = Result request    |                           |
           +--------------------------->|        (request)          |
           |                            +---  ---  ---  ---  --- -->|
           |                            |<---  ---  ---  --- ---  --+
           |                            |         Result            |
           |  EAD_4 = Result            |                           |
           |<---------------------------+                           |
           |                            |                           |
           |                            |                           |
           |                            |                           |
           | <------------------------> |                           |
           |       EDHOC session        |                           |

      Figure 2: Overview of network service attestation in passport
     model and EDHOC forward message flow.  EDHOC is used between RP
      and A.  The dashed line illustrates a logical connection that
                   does not need to occur in real time.

  7.  Mutual Attestation in EDHOC

     Mutual attestation over EDHOC combines the cases where one of the
     EDHOC parties uses the IoT device attestation and the other uses the
     Network service attestation.  Performing mutual attestation to a
     single EDHOC message flow acheives a lightweight use with reduced
     message overhead.  Note that the message flow for the two parties in
     mutual attestation needs to be the same.

     In this specification, we list the most relevant mutual attestation
     example for constrained IoT environments.








  Song                      Expires 24 April 2025                [Page 15]


  Internet-Draft                  RA-EDHOC                    October 2024


  7.1.  (IoT, BG, Fwd) - (Net, PP, Fwd)

     In this example, the mutual attestation is performed in EDHOC forward
     message flow, by one IoT device attestation in background-check model
     and another network service attestation in passport model.  The
     process is illustrated in Figure 3.  How the Network service connects
     with the Verifier_1 and potential Verifier_2 is out of scope in this
     specification.

     The first remote attestation is initiated by the IoT device (A_1) in
     background-check model.  In parallel, the IoT device (A_1) requests
     the network service (A_2) to perform a remote attestation in passport
     model.  EAD_2 carries the EAD items Attestation request and Result
     proposal.  EAD_3 carries the EAD items Evidence and Result request.
     EAD_4 carries the EAD item Result for the passport model.




































  Song                      Expires 24 April 2025                [Page 16]


  Internet-Draft                  RA-EDHOC                    October 2024


  +-----------------+               +-----------------+
  |   IoT device    |               | Network service |
  +-----------------+               +-----------------+
  | EDHOC Initiator |               | EDHOC Responder |
  +-----------------+               +-----------------+            +------------+              +------------+
  |    A_1/RP_2     |               |    RP_1/A_2     |            | Verifier_1 |              | Verifier_2 |
  +--------+--------+               +--------+--------+            +------+-----+              +------+-----+
           |                                 |                            |                           |
           |  EAD_1 = Attestation proposal,  |                            |                           |
           |          trigger_PP             |                            |                           |
           +-------------------------------->|                            |                           |
           |                                 |                            |                           |
           |                                 |                            |                           |
           |                                 |  Attestation proposal, C_R |                           |
           |                                 +--------------------------->|                           |
           |                                 |<---------------------------+                           |
           |                                 |   EvidenceType(s), Nonce   |                           |
           |  EAD_2 = Attestation request,   |                            |                           |
           |          Result proposal        |                            |                           |
           |<--------------------------------+                            |                           |
           |                                 |                            |                           |
           |                                 |                            |                           |
           |  EAD_3 = Evidence,              |                            |                           |
           |          Result request         |                            |                           |
           +-------------------------------->|                            |                           |
           |                                 |                            |                           |
           |                                 |       Evidence, C_R        |                           |
           |                                 +--------------------------->|         (Request)         |
           |                                 +--- --- --- --- --- ---  ---+ ---  ---  --- --- --- --->|
           |                                 |                            |                           |
           |                                 |                            |                           |
           |                                 |    Attestation result      |                           |
           |                                 |<---------------------------+                           |
           |                                 |                            |                           |
           |                                 |<---  ---  ---  ---  ---  --+ ---  ---  --- ---  --- ---+
           |                                 |            Result          |                           |
           |  EAD_4 = Result                 |                            |                           |
           |<--------------------------------+                            |                           |
           |                                 |                            |                           |
           |                                 |                            |                           |
           |                                 |                            |                           |
           |                                 |                            |                           |
           | <-----------------------------> |                            |                           |
           |          EDHOC session          |                            |                           |







  Song                      Expires 24 April 2025                [Page 17]


  Internet-Draft                  RA-EDHOC                    October 2024


       Figure 3: Overview of mutual attestation of (IoT, BG, Fwd) -
    (Net, PP, Fwd).  EDHOC is used between A and RP.  The dashed line
     illustrates a logical connection that does not need to occur in
                                real time.

  8.  Error Handling

     This section specifies a new EDHOC error code and how it is used in
     the proposed protocol.

  8.1.  EDHOC Error "Attestation failed"

     This section specifies a new EDHOC error "Attestation failed".  The
     format of the error message follows the one in EDHOC protocol(see
     Section 6 of [RFC9528]).

    +----------+----------------+----------------------------------------+
    | ERR_CODE | ERR_INFO Type  | Description                            |
    +==========+================+========================================+
    |     TBD5 | attestation    | Attestation failed                     |
    +----------+----------------+----------------------------------------+

       Figure 4: EDHOC error code and error information for Attestation
                                   failed.

     Error code TBD5 indicates to the receiver that the remote attestation
     is failed after the evidence is sent.  This can occur in two cases:

     1.  The Verifier evaluates the attestation evidence and returns a
         negative result based on the Verifier's appraisal policy.

     2.  The Verifier provides a positive attestation result to the
         Relying Party, but the Relying Party can not establish a
         sufficient level of trust to proceed decision-specific actions
         based on its appraisal policy.

     In case 1, the Verifier signals the error to the Relying Party, which
     then generates an EDHOC "Attestation failed" error and send it to the
     Attester.  In case 2, the Relying Party directly generates and sends
     the "Attestation failed" error to the Attester.  The application
     decides how to handle the error message.

  9.  Security Considerations

     This specification is performed over EDHOC [RFC9528] by using EDHOC's
     EAD fields.  The privacy considerations of EADs in EDHOC apply to
     this specification.




  Song                      Expires 24 April 2025                [Page 18]


  Internet-Draft                  RA-EDHOC                    October 2024


     EAD_1 is not resistant to either active attackers or passive
     attackers, because neither the Initiator nor the Responder has been
     authenticated.

     Although EAD_2 is encrypted, the Initiator has not been
     authenticated, rendering EAD_2 vulnerable against the active
     attackers.

     The ead items in EAD_1 and EAD_2 MAY be very specific and potentially
     reveal sensitive information about the device.  The leaking of the
     data in EAD_1 and/or EAD_2 MAY risk to be used by the attackers for
     malicious purposes.  Data in EAD_3 and EAD_4 are protected between
     the Initiator and the Responder in EDHOC.

     Mutual attestation carries a lower risk for EAD items when the
     Responder is the Attester.  For the mutual attestation at the EDHOC
     Responder, only the Attestation_proposal/Result_proposal in EAD_2 is
     not protected to active attackers.  Both the Attestation_request/
     Result_request in EAD_3 and the Evidence/Result in EAD_4 are
     protected.

  10.  IANA Considerations

  10.1.  EDHOC External Authorization Data Registry

     IANA is requested to register the following entry in the "EDHOC
     External Authorization Data" registry under the group name "Ephemeral
     Diffie-Hellman Over Cose (EDHOC)".

     *  The ead_label = TBD1 corresponds to the ead_value
        Attestation_proposal in Section 5.2.1.1.1, Attestation_request in
        Section 5.2.1.1.2 and Evidence in Section 5.2.1.1.3.

     *  The ead_label = TBD2 corresponds to the EAT item trigger_bg as
        specified in Section 5.2.1.1.4.

     *  The ead_label = TBD3 corresponds to the ead_value Result_proposal
        in Section 5.2.2.1.1, Result_request in Section 5.2.2.1.2 and the
        Result in Section 5.2.2.1.3.

     *  The ead_label = TBD4 corresponds to the EAT item trigger_pp as
        specified in Section 5.2.2.1.4.









  Song                      Expires 24 April 2025                [Page 19]


  Internet-Draft                  RA-EDHOC                    October 2024


     +-----------+-------+------------------------+-------------------+
     | Name      | Label | Description            | Reference         |
     +===========+=======+========================+===================+
     | TBD       | TBD1  | BG model               |                   |
     |           |       | related information    | Section 5.2.1.1   |
     +-----------+-------+------------------------+-------------------+
     | TBD       | TBD2  | trigger to start       |                   |
     |           |       | attestation in BG      | Secion 5.2.1.1    |
     +-----------+-------+------------------------+-------------------+
     | TBD       | TBD3  | PP model               |                   |
     |           |       | related information    | Section 5.2.2.1   |
     +-----------+-------+------------------------+-------------------+
     | TBD       | TBD4  | trigger to start       |                   |
     |           |       | attestation in PP      | Secion 5.2.2.1    |
     +-----------+-------+------------------------+-------------------+

                             Figure 5: EAD labels.

  11.  References

  11.1.  Normative References

     [I-D.ietf-rats-eat]
                Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", Work in
                Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
                September 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-eat-31>.

     [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/rfc/rfc2119>.

     [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/rfc/rfc8174>.

     [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
                "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
                DOI 10.17487/RFC9528, March 2024,
                <https://www.rfc-editor.org/rfc/rfc9528>.

  11.2.  Informative References

     [I-D.ietf-lake-authz]
                Selander, G., Mattsson, J. P., Vučinić, M., Fedrecheski,
                G., and M. Richardson, "Lightweight Authorization using



  Song                      Expires 24 April 2025                [Page 20]


  Internet-Draft                  RA-EDHOC                    October 2024


                Ephemeral Diffie-Hellman Over COSE (ELA)", Work in
                Progress, Internet-Draft, draft-ietf-lake-authz-03, 21
                October 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-lake-authz-03>.

     [IANA-CoAP-Content-Formats]
                "CoAP Content-Formats", n.d.,
                <https://www.iana.org/assignments/core-parameters>.

     [IANA-COSE-Header-Parameters]
                "COSE Header Parameters", n.d.,
                <https://www.iana.org/cose/header-parameters>.

     [IANA.CWT.Claims]
                IANA, "CBOR Web Token (CWT) Claims",
                <https://www.iana.org/assignments/cwt>.

     [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/rfc/rfc8392>.

     [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/rfc/rfc8949>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

     [RFC9393]  Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
                Waltermire, "Concise Software Identification Tags",
                RFC 9393, DOI 10.17487/RFC9393, June 2023,
                <https://www.rfc-editor.org/rfc/rfc9393>.

  Appendix A.  Example: Remote Attestation Flow

   .--------------------------.
   |     EDHOC Initiator      |       .-------------------.
   +--------------------------+       |  EDHOC Responder  |
   | Attestation   | Attester |       +-------------------+   .----------.
   | Service       |          |       |  Relying Party    |   | Verifier |
   '--+----------------+------'       '---------+---------'   '-----+----'
      |                |                        |                   |
      |                |                        |                   |
      |                |EDHOC message_1         |                   |
      |                |  {...}                 |                   |



  Song                      Expires 24 April 2025                [Page 21]


  Internet-Draft                  RA-EDHOC                    October 2024


      |                |  EAD_1(                |                   |
      |                |    types(a,b,c)        |                   |
      |                |  )                     |                   |
      |                +----------------------->|                   |
      |                |                        |                   |
      |                |                        | types(a,b,c), C_R |
      |                |                        +------------------>|
      |                |                        |                   |
      |                |                        |                   |
      |                |                        | Body: {           |
      |                |                        |   nonce,          |
      |                | EDHOC message_2        |   types(a,b)      |
      |                |  {...}                 | }                 |
      |                |  EAD_2(                |<------------------+
      |                |    nonce,              |                   |
      |                |    type(a)             |                   |
      |                |  )                     |                   |
      |                |  Auth_CRED(Sig/MAC)    |                   |
      |                |<-----------------------+                   |
      |   Body:{       |                        |                   |
      |    nonce,      |                        |                   |
      |    type(a)     |                        |                   |
      |   }            |                        |                   |
      |<---------------+                        |                   |
      | Body:{         |                        |                   |
      |   Evidence     |                        |                   |
      | }              |                        |                   |
      +--------------->|                        |                   |
      |                | EDHOC message_3        |                   |
      |                |  {...}                 |                   |
      |                |  Evidence(EAT)         |                   |
      |                |  Auth_CRED(sig/MAC)    |                   |
      |                +----------------------->|                   |
      |                |                        |                   |
      |                |                        |                   |
      |                |                        |                   |
      |                |                        | Body: {           |
      |                |                        |  EAT, C_R}        |
      |                |                        +------------------>|
      |                |                        | Body: {           |
      |                |                        |  att-result: AR{} |
      |                |                        | }                 |
      |                |                        |<------------------+
      |                |                        +---.               |
      |                |                        |    | verify AR{}  |
      |                |                        |<--'               |
      |                |                        |                   |
      |                |    application data    |                   |



  Song                      Expires 24 April 2025                [Page 22]


  Internet-Draft                  RA-EDHOC                    October 2024


      |                |<---------------------->|                   |
      |                |                        |                   |

                  Figure 6: Example of remote attestation.

  Appendix B.  Remote attestation in parallel with enrollment
               authorization

     This section discusses the possibility of doing remote attestation in
     parallel with the enrollment authorization procedure defined in
     [I-D.ietf-lake-authz].  In this case, the message count is much
     decreased.

     The detailed procedure is TBD.

  Appendix C.  Example: Firmware Version

     The goal in this example is to verify that the firmware running on
     the device is the latest version, and is neither tampered or
     compromised.  A device acts as the Attester, currently in an
     untrusted state.  The Attester needs to generate the evidence to
     attest itself.  A gateway that can communicate with the Attester and
     can control its access to the network acts as the Relying Party.  The
     gateway will finally decide whether the device can join the network
     or not depending on the attestation result.  The attestation result
     is produced by the Verifier, which is a web server that can be seen
     as the manufacturer of the device.  Therefore it can appraise the
     evidence that is sent by the Attester.  The remote attestation
     session starts with the Attester sending EAD_1 in EDHOC message 1.

     An example of the EAD_1 in EDHOC message_1 could be:

     [60,61,258]

     If the Verifier and the Relying Party can support at least one
     evidence type that is proposed by the Attester, the Relying Party
     will include in the EAD_2 field the same evidence type, alongside a
     nonce for message freshness.

     (258, h'a29f62a4c6cdaae5')

     The Evidence in EAD_3 field is an Entity Attestation Token (EAT)
     [I-D.ietf-rats-eat], with the measurements claim formatted in
     CoSWID[RFC9393].  The components of the Evidence should at least be:







  Song                      Expires 24 April 2025                [Page 23]


  Internet-Draft                  RA-EDHOC                    October 2024


  {
  /eat-nonce/                 10: h'a29f62a4c6cdaae5',
  /ueid/                      256: 'aaabbcc',
  /measurements/              273: [
    /CoAP Content-Format ID/        [ 258,
    /evidence in CoSWID/              {
                                        0: 'tagID'             /tag-id/
                                        12: 0                  /tag-version/
                                        1: "DotBot firmware"   /software-name/
                                        2: {                   /entity/
                                            31: "Attester"     /entity-name/
                                            33: 1              /role, must be "tag-creator" which is 1/
                                            },
                                        3: {                   /evidence/
                                            17: [              /file/
                                                 {
                                                  24: "partition0-nrf52840dk.bin",   /fs-name/
                                                  7: [                               /hash of file/
                                                      1,                             /alg SHA-256/
                                                      h'06294f6806b9c685eea795048579cfd02a0c025bc8b5abca42a19ea0ec23e81a'
                                                      ]                              /hash value/
                                                  }
                                                 ]
                                            }
                                      }
                                    ]
                                   ]
  }

     The infomation above serves as the payload of the COSE object.  The
     complete resulting COSE object is:




















  Song                      Expires 24 April 2025                [Page 24]


  Internet-Draft                  RA-EDHOC                    October 2024


  18([
      /*protected header*/
      h'a10127',

      /*unprotected header*/
      {},

      /*payload*/
      h'A30A48A29F62A4C6CDAAE519010047616161626263631901118182190102A50045746
      16749440C00016F446F74426F74206669726D7761726502A2181F684174746573746572
      18210103A11181A218187819706172746974696F6E302D6E72663532383430646B2E626
      96E078201582006294F6806B9C685EEA795048579CFD02A0C025BC8B5ABCA42A19EA0EC
      23E81A',

      /*signature*/
      h'd4100901f4c3e51312c3110c6ddc8dcf7f68d8f5d3791c19133f2f0ac158c1f5ee6ed
      afe9d7c3d6eb3d2d197f82e733d375fdda9fb258b304961dfc38558950d'
  ])

     which has the following base16 encoding:

   D28443A10127A05890A30A48A29F62A4C6CDAAE51901004761616162626363190111818
   2190102A5004574616749440C00016F446F74426F74206669726D7761726502A2181F68
   417474657374657218210103A11181A218187819706172746974696F6E302D6E7266353
   2383430646B2E62696E078201582006294F6806B9C685EEA795048579CFD02A0C025BC8
   B5ABCA42A19EA0EC23E81A5840D4100901F4C3E51312C3110C6DDC8DCF7F68D8F5D3791
   C19133F2F0AC158C1F5EE6EDAFE9D7C3D6EB3D2D197F82E733D375FDDA9FB258B304961
   DFC38558950D

     The Relying Party (co-located with the gateway) then treats the
     Evidence as opaque and sends it to the Verifier.  Once the Verifier
     sends back the Attestation Result, the Relying Party can be assured
     on the version of the firmware that the device is running.

  Appendix D.  Open discussion: remote attestation over EDHOC/ over OSCORE

     TBD

  Acknowledgments

     The author would like to thank Thomas Fossati, Goran Selander, Malisa
     Vucinic, Ionut Mihalcea, Muhammad Usama Sardar, Michael Richardson
     and Geovane Fedrecheski for the provided ideas and feedback.

  Author's Address

     Yuxuan Song
     Inria



  Song                      Expires 24 April 2025                [Page 25]


  Internet-Draft                  RA-EDHOC                    October 2024


     Email: yuxuan.song@inria.fr


















































  Song                      Expires 24 April 2025                [Page 26]


name: draft-ietf-lake-edhoc
rev: 23
title: Ephemeral Diffie-Hellman Over COSE (EDHOC)
time: 2024-03-21T01:58:06Z
group_uri: /api/v1/group/group/2249/
expires: 2024-07-25T13:13:46Z
ad: /api/v1/person/person/112723/
shepherd: /api/v1/person/email/malisa.vucinic@inria.fr/
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081838+00:00
source: ietf
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,
     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.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/154/", "/api/v1/doc/state/115/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  LAKE Working Group                                           G. Selander
  Internet-Draft                                         J. Preuß Mattsson
  Intended status: Standards Track                            F. Palombini
  Expires: 25 July 2024                                           Ericsson
                                                           22 January 2024


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

  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,
     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 25 July 2024.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components



  Selander, et al.          Expires 25 July 2024                  [Page 1]


  Internet-Draft                    EDHOC                     January 2024


     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Message Size Examples . . . . . . . . . . . . . . . . . .   5
       1.3.  Document Structure  . . . . . . . . . . . . . . . . . . .   6
       1.4.  Terminology and Requirements Language . . . . . . . . . .   6
     2.  EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . .   9
       3.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.  Method  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.3.  Connection Identifiers  . . . . . . . . . . . . . . . . .  10
       3.4.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  12
       3.5.  Authentication Parameters . . . . . . . . . . . . . . . .  14
       3.6.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . .  20
       3.7.  Ephemeral Public Keys . . . . . . . . . . . . . . . . . .  21
       3.8.  External Authorization Data (EAD) . . . . . . . . . . . .  22
       3.9.  Application Profile . . . . . . . . . . . . . . . . . . .  24
     4.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .  25
       4.1.  Keys for EDHOC Message Processing . . . . . . . . . . . .  26
       4.2.  Keys for EDHOC Applications . . . . . . . . . . . . . . .  29
     5.  Message Formatting and Processing . . . . . . . . . . . . . .  30
       5.1.  EDHOC Message Processing Outline  . . . . . . . . . . . .  31
       5.2.  EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . .  32
       5.3.  EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . .  33
       5.4.  EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . .  36
       5.5.  EDHOC Message 4 . . . . . . . . . . . . . . . . . . . . .  39
     6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  41
       6.1.  Success . . . . . . . . . . . . . . . . . . . . . . . . .  42
       6.2.  Unspecified Error . . . . . . . . . . . . . . . . . . . .  42
       6.3.  Wrong Selected Cipher Suite . . . . . . . . . . . . . . .  43
       6.4.  Unknown Credential Referenced . . . . . . . . . . . . . .  45
     7.  EDHOC Message Deduplication . . . . . . . . . . . . . . . . .  46
     8.  Compliance Requirements . . . . . . . . . . . . . . . . . . .  47
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  47
       9.1.  Security Properties . . . . . . . . . . . . . . . . . . .  48
       9.2.  Cryptographic Considerations  . . . . . . . . . . . . . .  51
       9.3.  Cipher Suites and Cryptographic Algorithms  . . . . . . .  53
       9.4.  Post-Quantum Considerations . . . . . . . . . . . . . . .  53
       9.5.  Unprotected Data and Privacy  . . . . . . . . . . . . . .  54
       9.6.  Updated Internet Threat Model Considerations  . . . . . .  55
       9.7.  Denial-of-Service . . . . . . . . . . . . . . . . . . . .  55
       9.8.  Implementation Considerations . . . . . . . . . . . . . .  56
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  59



  Selander, et al.          Expires 25 July 2024                  [Page 2]


  Internet-Draft                    EDHOC                     January 2024


       10.1.  EDHOC Exporter Label Registry  . . . . . . . . . . . . .  59
       10.2.  EDHOC Cipher Suites Registry . . . . . . . . . . . . . .  60
       10.3.  EDHOC Method Type Registry . . . . . . . . . . . . . . .  62
       10.4.  EDHOC Error Codes Registry . . . . . . . . . . . . . . .  63
       10.5.  EDHOC External Authorization Data Registry . . . . . . .  63
       10.6.  COSE Header Parameters Registry  . . . . . . . . . . . .  64
       10.7.  The Well-Known URI Registry  . . . . . . . . . . . . . .  65
       10.8.  Media Types Registry . . . . . . . . . . . . . . . . . .  65
       10.9.  CoAP Content-Formats Registry  . . . . . . . . . . . . .  67
       10.10. Resource Type (rt=) Link Target Attribute Values
               Registry  . . . . . . . . . . . . . . . . . . . . . . .  67
       10.11. Expert Review Instructions . . . . . . . . . . . . . . .  67
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  68
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  68
       11.2.  Informative References . . . . . . . . . . . . . . . . .  71
     Appendix A.  Use with OSCORE and Transfer over CoAP . . . . . . .  76
       A.1.  Deriving the OSCORE Security Context  . . . . . . . . . .  76
       A.2.  Transferring EDHOC over CoAP  . . . . . . . . . . . . . .  78
     Appendix B.  Compact Representation . . . . . . . . . . . . . . .  82
     Appendix C.  Use of CBOR, CDDL, and COSE in EDHOC . . . . . . . .  83
       C.1.  CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . .  84
       C.2.  CDDL Definitions  . . . . . . . . . . . . . . . . . . . .  85
       C.3.  COSE  . . . . . . . . . . . . . . . . . . . . . . . . . .  86
     Appendix D.  Authentication Related Verifications . . . . . . . .  88
       D.1.  Validating the Authentication Credential  . . . . . . . .  88
       D.2.  Identities  . . . . . . . . . . . . . . . . . . . . . . .  89
       D.3.  Certification Path and Trust Anchors  . . . . . . . . . .  90
       D.4.  Revocation Status . . . . . . . . . . . . . . . . . . . .  91
       D.5.  Unauthenticated Operation . . . . . . . . . . . . . . . .  91
     Appendix E.  Use of External Authorization Data . . . . . . . . .  91
     Appendix F.  Application Profile Example  . . . . . . . . . . . .  93
     Appendix G.  Long PLAINTEXT_2 . . . . . . . . . . . . . . . . . .  94
     Appendix H.  EDHOC_KeyUpdate  . . . . . . . . . . . . . . . . . .  95
     Appendix I.  Example Protocol State Machine . . . . . . . . . . .  96
       I.1.  Initiator State Machine . . . . . . . . . . . . . . . . .  96
       I.2.  Responder State Machine . . . . . . . . . . . . . . . . .  98
     Appendix J.  Change Log . . . . . . . . . . . . . . . . . . . . . 100
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 112
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 112

  1.  Introduction










  Selander, et al.          Expires 25 July 2024                  [Page 3]


  Internet-Draft                    EDHOC                     January 2024


  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 criterion is code size, which may be prohibitively
     large 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, [RFC9052]) 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 keying 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 forward secrecy, identity protection,
     and cipher suite negotiation.  Authentication can be based on raw
     public keys (RPK) or public key certificates and requires the
     application to provide input on how to verify that endpoints are
     trusted.  This specification supports the referencing of credentials



  Selander, et al.          Expires 25 July 2024                  [Page 4]


  Internet-Draft                    EDHOC                     January 2024


     in order to reduce message overhead, but credentials may
     alternatively be embedded in the messages.  EDHOC does not currently
     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 and identity
     protection.

     EDHOC makes use of known protocol constructions, such as SIGMA
     [SIGMA], the Noise XX pattern [Noise], and Extract-and-Expand
     [RFC5869].  EDHOC uses COSE for cryptography and identification of
     credentials (including COSE_Key, CBOR Web Token (CWT), CWT Claims Set
     (CCS), X.509, and CBOR encoded X.509 (C509) certificates, see
     Section 3.5.2).  COSE provides crypto agility and enables the use of
     future algorithms and credential types targeting IoT.

     EDHOC is designed for highly constrained settings making it
     especially suitable for low-power 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., to provide
     authentication and session key establishment for IoT use cases such
     as those built on CoAP [RFC7252] involving 'things' with embedded
     microcontrollers, sensors, and actuators.  By reusing the same
     lightweight primitives as OSCORE (CBOR, COSE, CoAP) 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.

     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).  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., 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 keys.

  1.2.  Message Size Examples

     Examples of EDHOC message sizes are shown in Figure 1, using
     different kinds of authentication keys and COSE header parameters for
     identification: static Diffie-Hellman keys or signature keys, either
     in CBOR Web Token (CWT) / CWT Claims Set (CCS) [RFC8392] identified
     by a key identifier using 'kid' [RFC9052], or in X.509 certificates
     identified by a hash value using 'x5t' [RFC9360].  As a comparison,
     in the case of RPK authentication, the EDHOC message size when
     transferred in CoAP can be less than 1/7 of the DTLS 1.3 handshake
     [RFC9147] with ECDHE and connection ID, see Section 2 of
     [I-D.ietf-iotops-security-protocol-comparison].



  Selander, et al.          Expires 25 July 2024                  [Page 5]


  Internet-Draft                    EDHOC                     January 2024


          ----------------------------------------------------------
                               Static DH Keys        Signature Keys
                              ----------------      ----------------
                               kid        x5t        kid        x5t
          ----------------------------------------------------------
           message_1            37         37         37         37
           message_2            45         58        102        115
           message_3            19         33         77         90
          ----------------------------------------------------------
           Total               101        128        216        242
          ----------------------------------------------------------

              Figure 1: Examples of EDHOC message sizes in bytes.

  1.3.  Document Structure

     The remainder of the document is organized as follows: Section 2
     outlines EDHOC authenticated with signature keys, Section 3 describes
     the protocol elements of EDHOC, including formatting of the ephemeral
     public keys, Section 4 specifies the key derivation, Section 5
     specifies message processing for EDHOC authenticated with signature
     keys or static Diffie-Hellman keys, Section 6 describes the error
     messages, Section 7 describes EDHOC support for transport that does
     not handle message duplication, and Section 8 lists compliance
     requirements.  Note that normative text is also used in appendices,
     in particular Appendix A.

  1.4.  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 processing [RFC9052], COSE algorithms [RFC9053], CWT
     and CWT Claims Set [RFC8392], and the Concise Data Definition
     Language (CDDL, [RFC8610]), which is used to express CBOR data
     structures.  Examples of CBOR and CDDL are provided in Appendix C.1.
     When referring to CBOR, this specification always 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", following
     [RFC5116].





  Selander, et al.          Expires 25 July 2024                  [Page 6]


  Internet-Draft                    EDHOC                     January 2024


  2.  EDHOC Outline

     EDHOC specifies different authentication methods of the ephemeral-
     ephemeral Diffie-Hellman key exchange: signature keys and static
     Diffie-Hellman keys.  This section outlines the signature key 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 in IKEv2 [RFC7296] and (D)TLS
     1.3 [RFC8446][RFC9147], EDHOC authenticated with signature keys is
     built on a variant of the SIGMA protocol, SIGMA-I, which provides
     identity protection against active attacks on the party initiating
     the protocol.  Also like IKEv2, EDHOC implements the MAC-then-Sign
     variant of the SIGMA-I protocol.  The message flow (excluding an
     optional fourth message) is shown in Figure 2.

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

        Figure 2: MAC-then-Sign variant of the SIGMA-I protocol used by
                                EDHOC method 0.

     The parties exchanging messages in an EDHOC session are called
     Initiator (I) and Responder (R), where the Initiator sends message_1
     (see Section 3).  They exchange ephemeral public keys, compute a
     shared secret session key PRK_out, and derive symmetric application
     keys used to protect application data.

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

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

     *  ID_CRED_I and ID_CRED_R are used to identify and optionally
        transport the credentials of the Initiator and the Responder,
        respectively.




  Selander, et al.          Expires 25 July 2024                  [Page 7]


  Internet-Draft                    EDHOC                     January 2024


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

     *  Enc(), AEAD(), and MAC() denotes encryption, authenticated
        encryption with additional data, and message authentication code -
        crypto algorithms applied with keys derived from one or more
        shared secrets calculated during the protocol.

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

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

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

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

     *  A keying material exporter and a key update function with forward
        secrecy.

     *  Secure negotiation of cipher suite.

     *  Method types, error handling, and padding.

     *  Selection of connection identifiers C_I and C_R which may be used
        in EDHOC to identify protocol state.

     *  Transport of external authorization data.

     EDHOC is designed to encrypt and integrity protect as much
     information as possible.  Symmetric keys and random material used in
     EDHOC are derived using EDHOC_KDF with as much previous information
     as possible, see Figure 8.  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.  Like in (D)TLS, authentication is the responsibility
     of the application.  EDHOC identifies (and optionally transports)
     authentication credentials, and provides proof-of-possession of the
     private authentication key.

     To simplify for implementors, the use of CBOR and COSE in EDHOC is
     summarized in Appendix C.  Test vectors including CBOR diagnostic
     notation are provided in [I-D.ietf-lake-traces].



  Selander, et al.          Expires 25 July 2024                  [Page 8]


  Internet-Draft                    EDHOC                     January 2024


  3.  Protocol Elements

  3.1.  General

     The EDHOC protocol consists of three mandatory messages (message_1,
     message_2, message_3), an optional fourth message (message_4), and an
     error message, between an Initiator (I) and a Responder (R).  The odd
     messages are sent by I, the even by R.  Both I and R can send error
     messages.  The roles have slightly different security properties
     which should be considered when the roles are assigned, see
     Section 9.1.  All EDHOC messages are CBOR Sequences [RFC8742], and
     are defined to be deterministically encoded CBOR as specified in
     Section 4.2.1 of [RFC8949].  Figure 3 illustrates an EDHOC message
     flow with the optional fourth message as well as the content of each
     message.  The protocol elements in the figure are introduced in
     Section 3 and Section 5.  Message formatting and processing are
     specified in Section 5 and Section 6.

     Application data may be 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).  Media types
     that may be used for EDHOC are defined in Section 10.8.

     The Initiator can derive symmetric application keys after creating
     EDHOC message_3, see Section 4.2.1.  Protected application data can
     therefore be sent in parallel or together with EDHOC message_3.
     EDHOC message_4 is typically not sent.

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

      Figure 3: EDHOC message flow including the optional fourth message.




  Selander, et al.          Expires 25 July 2024                  [Page 9]


  Internet-Draft                    EDHOC                     January 2024


  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.  When using a
     static Diffie-Hellman key the authentication is provided by a Message
     Authentication Code (MAC) computed from an ephemeral-static ECDH
     shared secret which enables significant reductions in message sizes.
     Note that also in the static Diffie-Hellman based authentication
     methods there is an ephemeral-ephemeral Diffie-Hellman key exchange.

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

           +-------------+--------------------+--------------------+
           | Method Type | Initiator          | Responder          |
           |       Value | Authentication Key | Authentication Key |
           +=============+====================+====================+
           |           0 | Signature Key      | Signature Key      |
           |           1 | Signature Key      | Static DH Key      |
           |           2 | Static DH Key      | Signature Key      |
           |           3 | Static DH Key      | Static DH Key      |
           +-------------+--------------------+--------------------+

                Figure 4: Authentication keys for method types.

     EDHOC does not have a dedicated message field to indicate the
     protocol version.  Breaking changes to EDHOC can be introduced by
     specifying and registering new methods.

  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 to correlate EDHOC messages and
     facilitate the retrieval of protocol state during an EDHOC session
     (see Section 3.4), or may be used in applications of EDHOC, e.g., in
     OSCORE (see Section 3.3.3).  The connection identifiers do not have
     any cryptographic purpose in EDHOC and only facilitate the retrieval
     of security data associated with the protocol state.

     Connection identifiers in EDHOC are intrinsically byte strings.  Most
     constrained devices only have a few connections for which short
     identifiers may be sufficient.  In some cases minimum length
     identifiers are necessary to comply with overhead requirements.
     However, CBOR byte strings - with the exception of the empty byte



  Selander, et al.          Expires 25 July 2024                 [Page 10]


  Internet-Draft                    EDHOC                     January 2024


     string h’’ which encodes as one byte (0x40) - are encoded as two or
     more bytes.  To enable one-byte encoding of certain byte strings
     while maintaining CBOR encoding, EDHOC represents certain identifiers
     as CBOR integers on the wire, see Section 3.3.2.

  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 communication with the Initiator.  The
     Responder selects C_R and sends it 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.  Representation of Byte String Identifiers

     To allow identifiers with minimal overhead on the wire, certain byte
     strings used in connection identifiers and credential identifiers
     (see Section Section 3.5.3) are defined to have integer
     representations.

     The integers with one-byte CBOR encoding are -24, ..., 23, see
     Figure 5.

     Integer:  -24  -23  ... -11  ...  -2   -1    0    1  ...  15  ...  23
     Encoding:  37   36  ...  2A  ...  21   20   00   01  ...  0F  ...  17

                   Figure 5: One-byte CBOR encoded integers.

     The byte strings which coincide with a one-byte CBOR encoding of an
     integer MUST be represented by the CBOR encoding of that integer.
     Other byte strings are simply encoded as CBOR byte strings.

     For example:

     *  0x21 is represented by 0x21 (CBOR encoding of the integer -2), not
        by 0x4121 (CBOR encoding of the byte string 0x21).

     *  0x0D is represented by 0x0D (CBOR encoding of the integer 13), not
        by 0x410D (CBOR encoding of the byte string 0x0D).

     *  0x18 is represented by 0x4118 (CBOR encoding of the byte string
        0x18).



  Selander, et al.          Expires 25 July 2024                 [Page 11]


  Internet-Draft                    EDHOC                     January 2024


     *  0x38 is represented by 0x4138 (CBOR encoding of the byte string
        0x38).

     *  0xABCD is represented by 0x42ABCD (CBOR encoding of the byte
        string 0xABCD).

     One may view this representation of byte strings as a transport
     encoding: a byte string which parses as the one-byte CBOR encoding of
     an integer (i.e., integer in the interval -24, ..., 23) is just
     copied directly into the message, a byte string which does not is
     encoded as a CBOR byte string during transport.

     Implementation Note: When implementing the byte string identifier
     representation, it can in some programming languages help to define a
     new type, or other data structure, which (in its user facing API)
     behaves like a byte string, but when serializing to CBOR produces a
     CBOR byte string or a CBOR integer depending on its value.

  3.3.3.  Use of Connection Identifiers with OSCORE

     For OSCORE, the choice of connection identifier results in the
     endpoint selecting its Recipient ID, see Section 3.1 of [RFC8613],
     for which certain uniqueness requirements apply, see Section 3.3 of
     [RFC8613].  Therefore, the Initiator and the Responder MUST NOT
     select connection identifiers such that it results in the same OSCORE
     Recipient ID.  Since the connection identifier is a byte string, it
     is converted to an OSCORE Recipient ID equal to the byte string.

     Examples:

     *  A connection identifier 0xFF (represented in the EDHOC message as
        0x41FF, see Section 3.3.2) is converted to the OSCORE Recipient ID
        0xFF.

     *  A connection identifier 0x21 (represented in the EDHOC message as
        0x21, see Section 3.3.2) is converted to the OSCORE Recipient ID
        0x21.

  3.4.  Transport

     Cryptographically, EDHOC does not put requirements on the underlying
     layers.  Received messages are processed as the expected next message
     according to protocol state, see Section 5.  If processing fails for
     any reason then, typically, an error message is attempted to be sent
     and the EDHOC session is aborted.






  Selander, et al.          Expires 25 July 2024                 [Page 12]


  Internet-Draft                    EDHOC                     January 2024


     EDHOC is not bound to a particular transport layer and can even be
     used in environments without IP.  Ultimately, the application is free
     to choose how to transport EDHOC messages including errors.  In order
     to avoid unnecessary message processing or protocol termination, it
     is RECOMMENDED to use reliable transport, such as CoAP in reliable
     mode, which is the default transport, see Appendix A.2.  In general,
     the transport SHOULD handle:

     *  message loss,

     *  message duplication, see Section 7 for an alternative,

     *  flow control,

     *  congestion control,

     *  fragmentation and reassembly,

     *  demultiplexing EDHOC messages from other types of messages,

     *  denial-of-service mitigation,

     *  message correlation, see Section 3.4.1.

     EDHOC does not require error free transport since a change in message
     content is detected through the transcript hashes in a subsequent
     integrity verification, see Section 5.  The transport does not
     require additional means to handle message reordering because of the
     lockstep processing of EDHOC.

     EDHOC is designed to enable an authenticated key exchange with small
     messages, where the minimum message sizes are of the order
     illustrated in the first column of Figure 1.  There is no maximum
     message size specified by the protocol; this is for example dependent
     on the size of authentication credentials (if they are transported,
     see Section 3.5).

     The use of transport is specified in the application profile, which
     in particular may specify limitations in message sizes, see
     Section 3.9.











  Selander, et al.          Expires 25 July 2024                 [Page 13]


  Internet-Draft                    EDHOC                     January 2024


  3.4.1.  EDHOC Message Correlation

     Correlation between EDHOC messages is needed to facilitate the
     retrieval of protocol state and security context during an EDHOC
     session.  It is also helpful for the Responder to get an indication
     that a received EDHOC message is the beginning of a new EDHOC
     session, such that no existing protocol state or security context
     needs to be retrieved.

     Correlation may be based on existing mechanisms in the transport
     protocol, for example, the CoAP Token may be used to correlate EDHOC
     messages in a CoAP response and in an associated CoAP request.  The
     connection identifiers may also be used to correlate EDHOC messages.

     If correlation between consecutive messages is not provided by other
     means then the transport binding SHOULD mandate prepending of an
     appropriate connection identifier (when available from the EDHOC
     protocol) to the EDHOC message.  If message_1 indication is not
     provided by other means, then the transport binding SHOULD mandate
     prepending of message_1 with the CBOR simple value true (0xf5).

     Transport of EDHOC in CoAP payloads is described in Appendix A.2,
     including how to use connection identifiers and message_1 indication
     with CoAP.  A similar construction is possible for other client-
     server protocols.  Protocols that do not provide any correlation at
     all can prescribe prepending of the peer's connection identifier to
     all messages.

     Note that correlation between EDHOC messages may be obtained without
     transport support or connection identifiers, for example if the
     endpoints only accept a single instance of the protocol at a time,
     and execute conditionally on a correct sequence of messages.

  3.5.  Authentication Parameters

     EDHOC supports various settings for how the other endpoint's
     authentication (public) key may be transported, identified, and
     trusted.

     EDHOC performs the following authentication related operations:

     *  EDHOC transports information about credentials in ID_CRED_I and
        ID_CRED_R (described in Section 3.5.3).  Based on this
        information, the authentication credentials CRED_I and CRED_R
        (described in Section 3.5.2) can be obtained.  EDHOC may also
        transport certain authentication related information as External
        Authorization Data (see Section 3.8).




  Selander, et al.          Expires 25 July 2024                 [Page 14]


  Internet-Draft                    EDHOC                     January 2024


     *  EDHOC uses the authentication credentials in two ways (see
        Section 5.3.2 and Section 5.4.2):

        -  The authentication credential is input to the integrity
           verification using the MAC fields.

        -  The authentication key of the authentication credential is used
           with the Signature_or_MAC field to verify proof-of-possession
           of the private key.

     Other authentication related verifications are out of scope for
     EDHOC, and is the responsibility of the application.  In particular,
     the authentication credential needs to be validated in the context of
     the connection for which EDHOC is used, see Appendix D.  EDHOC MUST
     allow the application to read received information about credential
     (ID_CRED_R, ID_CRED_I).  EDHOC MUST have access to the authentication
     key and the authentication credential.

     Note that the type of authentication key, authentication credential,
     and the identification of the credential have a large impact on the
     message size.  For example, the Signature_or_MAC field is much
     smaller with a static DH key than with a signature key.  A CWT Claims
     Set (CCS) is much smaller than a self-signed certificate/CWT, but if
     it is possible to reference the credential with a COSE header like
     'kid', then that is in turn much smaller than a CCS.

  3.5.1.  Authentication Keys

     The authentication key (i.e., the public key used for authentication)
     MUST be a signature key or static Diffie-Hellman key.  The Initiator
     and the Responder MAY use different types of authentication keys,
     e.g., one uses a signature key and the other uses a static Diffie-
     Hellman key.

     The authentication key algorithm needs to be compatible with the
     method and the selected cipher suite (see Section 3.6).  The
     authentication key algorithm needs to be compatible with the EDHOC
     key exchange algorithm when static Diffie-Hellman authentication is
     used, and compatible with the EDHOC signature algorithm when
     signature authentication is used.

     Note that for most signature algorithms, the signature is determined
     by the signature algorithm and the authentication key algorithm
     together.  When using static Diffie-Hellman keys the Initiator's and
     Responder's private authentication keys are denoted as I and R,
     respectively, and the public authentication keys are denoted G_I and
     G_R, respectively.




  Selander, et al.          Expires 25 July 2024                 [Page 15]


  Internet-Draft                    EDHOC                     January 2024


     For X.509 certificates the authentication key is represented by a
     SubjectPublicKeyInfo field.  For CWT and CCS (see Section 3.5.2)) the
     authentication key is represented by a 'cnf' claim [RFC8747]
     containing a COSE_Key [RFC9052].  In EDHOC, a raw public key (RPK) is
     an authentication key encoded as a COSE_Key wrapped in a CCS.

  3.5.2.  Authentication Credentials

     The authentication credentials, CRED_I and CRED_R, contains the
     public authentication key of the Initiator and the Responder,
     respectively.  We use the notation CRED_x to refer to CRED_I or
     CRED_R.  Requirements on CRED_x applies both to CRED_I and to CRED_R.
     The authentication credential typically also contains other
     parameters that needs to be verified by the application, see
     Appendix D, and in particular information about the identity
     ("subject") of the endpoint to prevent misbinding attacks, see
     Appendix D.2.

     EDHOC relies on COSE for identification of credentials (see
     Section 3.5.3), for example X.509 certificates [RFC9360], C509
     certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and
     CWT Claims Sets (CCS) [RFC8392].  When the identified credential is a
     chain or a bag, the authentication credential CRED_x is just the end
     entity X.509 or C509 certificate / CWT.  In the choice between chain
     or bag it is RECOMMENDED to use a chain, since the certificates in a
     bag are unordered and may contain self-signed and extraneous
     certificates, which can add complexity to the process of extracting
     the end entity certificate.  The Initiator and the Responder MAY use
     different types of authentication credentials, e.g., one uses an RPK
     and the other uses a public key certificate.

     Since CRED_R is used in the integrity verification, see
     Section 5.3.2, it needs to be specified such that it is identical
     when used by Initiator or Responder.  Similarly for CRED_I, see
     Section 5.4.2.  The Initiator and Responder are expected to agree on
     the specific encoding of the authentication credentials, see
     Section 3.9.  It is RECOMMENDED that the COSE 'kid' parameter, when
     used to identify the authentication credential, refers to a such a
     specific encoding of the authentication credential.  The Initiator
     and Responder SHOULD use an available authentication credential
     (transported in EDHOC or otherwise provisioned) without re-encoding.
     If for some reason re-encoding of an authentication credential passed
     by reference may occur, then a potential common encoding for CBOR
     based credentials is deterministically encoded CBOR as specified in
     Sections 4.2.1 and 4.2.2 of [RFC8949].

     *  When the authentication credential is an X.509 certificate, CRED_x
        SHALL be the DER encoded certificate, encoded as a bstr [RFC9360].



  Selander, et al.          Expires 25 July 2024                 [Page 16]


  Internet-Draft                    EDHOC                     January 2024


     *  When the authentication credential is a C509 certificate, CRED_x
        SHALL be the C509Certificate [I-D.ietf-cose-cbor-encoded-cert].

     *  When the authentication credential is a CWT including a COSE_Key,
        CRED_x SHALL be the untagged CWT.

     *  When the authentication credential includes a COSE_Key but is not
        in a CWT, CRED_x SHALL be an untagged CWT Claims Set (CCS).  This
        is how RPKs are encoded, see Figure 6 for an example.

        -  Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in
           its simplest form by prefixing the COSE_Key with 0xA108A101 (a
           map with a 'cnf' claim).  In that case the resulting
           authentication credential contains no other identity than the
           public key itself, see Appendix D.2.

     An example of CRED_x is shown below:

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

           Figure 6: CWT Claims Set (CCS) containing an X25519 static
                   Diffie-Hellman key and an EUI-64 identity.

  3.5.3.  Identification of Credentials

     The ID_CRED fields, ID_CRED_R and ID_CRED_I, are transported in
     message_2 and message_3, respectively, see Section 5.3.2 and
     Section 5.4.2.  We use the notation ID_CRED_x to refer to ID_CRED_I
     or ID_CRED_R.  Requirements on ID_CRED_x applies both to ID_CRED_I
     and to ID_CRED_R.  The ID_CRED fields are used to identify and
     optionally transport credentials:

     *  ID_CRED_R is intended to facilitate for the Initiator retrieving
        the authentication credential CRED_R and the authentication key of
        R.





  Selander, et al.          Expires 25 July 2024                 [Page 17]


  Internet-Draft                    EDHOC                     January 2024


     *  ID_CRED_I is intended to facilitate for the Responder retrieving
        the authentication credential CRED_I and the authentication key of
        I.

     ID_CRED_x may contain the authentication credential CRED_x, for x = I
     or R, but for many settings it is not necessary to transport the
     authentication credential within EDHOC.  For example, it may be pre-
     provisioned or acquired out-of-band over less constrained links.
     ID_CRED_I and ID_CRED_R do not have any cryptographic purpose in
     EDHOC since the authentication credentials are integrity protected.

     EDHOC relies on COSE for identification of credentials and supports
     all credential types for which COSE header parameters are defined
     including X.509 certificates ([RFC9360]), C509 certificates
     ([I-D.ietf-cose-cbor-encoded-cert]), CWT (see Section 3.5.3.1) and
     CWT Claims Set (see Section 3.5.3.1).

     ID_CRED_I and ID_CRED_R are of type COSE header_map, as defined in
     Section 3 of [RFC9052], and contains one or more COSE header
     parameters.  If a map contains several header paramerers, the labels
     do not need to be sorted in bytewise lexicographic order.  ID_CRED_I
     and ID_CRED_R MAY contain different header parameters.  The header
     parameters typically provide some information about the format of the
     credential.

     Example: X.509 certificates can be identified by a hash value using
     the 'x5t' parameter, see Section 2 of [RFC9360]:

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

     Example: CWT or CCS can be identified by a key identifier using the
     'kid' parameter, see Section 3.1 of [RFC9052]:

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

     Note that COSE header parameters in ID_CRED_x are used to identify
     the message sender's credential.  There is therefore no reason to use
     the "-sender" header parameters, such as x5t-sender, defined in
     Section 3 of [RFC9360].  Instead, the corresponding parameter without
     "-sender", such as x5t, SHOULD be used.

     As stated in Section 3.1 of [RFC9052], applications MUST NOT assume
     that 'kid' values are unique and several keys associated with a 'kid'
     may need to be checked before the correct one is found.  Applications
     might use additional information such as 'kid context' or lower
     layers to determine which key to try first.  Applications should
     strive to make ID_CRED_x as unique as possible, since the recipient
     may otherwise have to try several keys.



  Selander, et al.          Expires 25 July 2024                 [Page 18]


  Internet-Draft                    EDHOC                     January 2024


     See Appendix C.3 for more examples.

  3.5.3.1.  COSE Header Parameters for CWT and CWT Claims Set

     This document registers two new COSE header parameters 'kcwt' and
     'kccs' for use with CBOR Web Token (CWT, [RFC8392]) and CWT Claims
     Set (CCS, [RFC8392]), respectively.  The CWT/CCS MUST contain a
     COSE_Key in a 'cnf' claim [RFC8747].  There may be any number of
     additional claims present in the CWT/CCS.

     CWTs sent in 'kcwt' are protected using a MAC or a signature and are
     similar to a certificate (when with public key cryptography) or a
     Kerberos ticket (when used with symmetric key cryptography).  CCSs
     sent in 'kccs' are not protected and are therefore similar to raw
     public keys or self-signed certificates.

     Security considerations for 'kcwt' and 'kccs' are made in
     Section 9.8.

  3.5.3.2.  Compact Encoding of ID_CRED Fields for 'kid'

     To comply with the LAKE message size requirements, see
     [I-D.ietf-lake-reqs], two optimizations are made for the case when
     ID_CRED_x, for x = I or R, contains a single 'kid' parameter.

     1.  The CBOR map { 4 : kid_x } is replaced by the byte string kid_x.

     2.  The representation of identifiers specified in Section 3.3.2 is
         applied to kid_x.

     These optimizations MUST be applied if and only if ID_CRED_x = { 4 :
     kid_x } and ID_CRED_x in PLAINTEXT_y of message_y, y = 2 or 3, see
     Section 5.3.2 and Section 5.4.2.  Note that these optimizations are
     not applied to instances of ID_CRED_x which have no impact on message
     size, e.g., context_y, or the COSE protected header.  Examples:

     *  For ID_CRED_x = { 4 : h'FF' }, the encoding in PLAINTEXT_y is not
        the CBOR map 0xA10441FF but the CBOR byte string h'FF', i.e.,
        0x41FF.

     *  For ID_CRED_x = { 4 : h'21' }, the encoding in PLAINTEXT_y is
        neither the CBOR map 0xA1044121, nor the CBOR byte string h'21',
        i.e., 0x4121, but the CBOR integer 0x21.








  Selander, et al.          Expires 25 July 2024                 [Page 19]


  Internet-Draft                    EDHOC                     January 2024


  3.6.  Cipher Suites

     An EDHOC cipher suite consists of an ordered set of algorithms from
     the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
     as the EDHOC MAC length.  All algorithm names and definitions follow
     from COSE algorithms [RFC9053].  Note that COSE sometimes uses
     peculiar names such as ES256 for ECDSA with SHA-256, A128 for AES-
     128, and Ed25519 for the curve edwards25519.  Algorithms need to be
     specified with enough parameters to make them completely determined.
     The EDHOC MAC length MUST be at least 8 bytes.  Any cryptographic
     algorithm used in the COSE header parameters in ID_CRED fields is
     selected independently of the selected cipher suite.  EDHOC is
     currently only specified for use with key exchange algorithms of type
     ECDH curves, but any Key Encapsulation Method (KEM), including Post-
     Quantum Cryptography (PQC) KEMs, can be used in method 0, see
     Section 9.4.  Use of other types of key exchange algorithms to
     replace static DH authentication (method 1,2,3) would likely require
     a specification updating EDHOC with new methods.

     EDHOC supports all signature algorithms defined by COSE.  Just like
     in (D)TLS 1.3 [RFC8446][RFC9147] and IKEv2 [RFC7296], a signature in
     COSE is determined by the signature algorithm and the authentication
     key algorithm together, see Section 3.5.1.  The exact details of the
     authentication key algorithm depend on the type of authentication
     credential.  COSE supports different formats for storing the public
     authentication keys including COSE_Key and X.509, which use different
     names and ways to represent the authentication key and the
     authentication key algorithm.

     An EDHOC cipher suite consists of the following parameters:

     *  EDHOC AEAD algorithm

     *  EDHOC hash algorithm

     *  EDHOC MAC length in 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 integer label.





  Selander, et al.          Expires 25 July 2024                 [Page 20]


  Internet-Draft                    EDHOC                     January 2024


     EDHOC can be used with all algorithms and curves defined for COSE.
     Implementations can either use any combination of COSE algorithms and
     parameters to define their own private cipher suite, or use one of
     the pre-defined cipher suites.  Private cipher suites can be
     identified with any of the four values -24, -23, -22, -21.  The pre-
     defined cipher suites are listed in the IANA registry (Section 10.2)
     with initial content outlined here:

     *  Cipher suites 0-3, based on AES-CCM, are intended for constrained
        IoT where message overhead is a very important factor.  Note that
        AES-CCM-16-64-128 and AES-CCM-16-128-128 are compatible with the
        IEEE CCM* mode.

        -  Cipher suites 1 and 3 use a larger tag length (128-bit) in
           EDHOC than in the Application AEAD algorithm (64-bit).

     *  Cipher suites 4 and 5, based on ChaCha20, are intended for less
        constrained applications and only use 128-bit tag lengths.

     *  Cipher suite 6, based on AES-GCM, is for general non-constrained
        applications.  It consists of high performance algorithms that are
        widely used in non-constrained applications.

     *  Cipher suites 24 and 25 are intended for high security
        applications such as government use and financial applications.
        These cipher suites do not share any algorithms.  Cipher suite 24
        consists of algorithms from the CNSA 1.0 suite [CNSA].

     The different methods (Section 3.2) use the same cipher suites, but
     some algorithms are not used in some methods.  The EDHOC signature
     algorithm 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 of cipher
     suites it supports.  SUITES_I contains cipher suites supported by the
     Initiator, formatted and processed as detailed in Section 5.2.1 to
     secure the cipher suite negotiation.  Examples of cipher suite
     negotiation are given in Section 6.3.2.

  3.7.  Ephemeral Public Keys

     The ephemeral public keys in EDHOC (G_X and G_Y) use compact
     representation of elliptic curve points, see Appendix B.  In COSE,
     compact representation is achieved by formatting the ECDH ephemeral
     public keys as COSE_Keys of type EC2 or OKP according to Sections 7.1
     and 7.2 of [RFC9053], but only including the 'x' parameter in G_X and
     G_Y.  For Elliptic Curve Keys of type EC2, compact representation MAY
     be used also in the COSE_Key.  COSE always uses compact output for



  Selander, et al.          Expires 25 July 2024                 [Page 21]


  Internet-Draft                    EDHOC                     January 2024


     Elliptic Curve Keys of type EC2.  If the COSE implementation requires
     a 'y' parameter, the value y = false or a calculated y-coordinate can
     be used, see Appendix B.

  3.8.  External Authorization Data (EAD)

     In order to reduce round trips and the number of messages, or to
     simplify processing, external security applications may be integrated
     into EDHOC by transporting authorization related data in the
     messages.

     EDHOC allows processing of external authorization data (EAD) to be
     defined in a separate specification, and sent in dedicated fields of
     the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4).  EAD is opaque
     data to EDHOC.

     Each EAD field, EAD_x for x = 1, 2, 3 or 4, is a CBOR sequence (see
     Appendix C.1) consisting of one or more EAD items.  An EAD item ead
     is a CBOR sequence of an ead_label and an optional ead_value, see
     Figure 7 and Appendix C.2 for the CDDL definitions.

     ead = (
       ead_label : int,
       ? ead_value : bstr,
     )

                              Figure 7: EAD item.

     A security application may register one or more EAD labels, see
     Section 10.5, and specify the associated processing and security
     considerations.  The IANA registry contains the absolute value of the
     ead_label, |ead_label|; the same ead_value applies independently of
     sign of ead_label.

     An EAD item can be either critical or non-critical, determined by the
     sign of the ead_label in the EAD item transported in the EAD field.
     A negative value indicates that the EAD item is critical and a non-
     negative value indicates that the EAD item is non-critical.

     If an endpoint receives a critical EAD item it does not recognize, or
     a critical EAD item that contains information that it cannot process,
     then the endpoint MUST send an EDHOC error message back as defined in
     Section 6, and the EDHOC session MUST be aborted.  The EAD item
     specification defines the error processing.  A non-critical EAD item
     can be ignored.






  Selander, et al.          Expires 25 July 2024                 [Page 22]


  Internet-Draft                    EDHOC                     January 2024


     The security application registering a new EAD item needs to describe
     under what conditions the EAD item is critical or non-critical, and
     thus whether the ead_label is used with negative or positive sign.
     ead_label = 0 is used for padding, see Section 3.8.1.

     The security application may define multiple uses of certain EAD
     items, e.g., the same EAD item may be used in different EDHOC
     messages.  Multiple occurrences of an EAD item in one EAD field may
     also be specified, but the criticality of the repeated EAD item is
     expected to be the same.

     The EAD fields of EDHOC MUST only be used with registered EAD items,
     see Section 10.5.  Examples of the use of EAD are provided in
     Appendix E.

  3.8.1.  Padding

     EDHOC message_1 and the plaintext of message_2, message_3 and
     message_4 can be padded with the use of the corresponding EAD_x
     field, for x = 1, 2, 3, 4.  Padding in EAD_1 mitigates amplification
     attacks (see Section 9.7), and padding in EAD_2, EAD_3, and EAD_4
     hides the true length of the plaintext (see Section 9.6).  Padding
     MUST be ignored and discarded by the receiving application.

     Padding is obtained by using an EAD item with ead_label = 0 and a
     (pseudo-)randomly generated byte string of appropriate length as
     ead_value, noting that the ead_label and the CBOR encoding of
     ead_value also add bytes.  Examples:

     *  One byte padding (optional ead_value omitted):

        -  EAD_x = 0x00

     *  Two bytes padding, using the empty byte string (0x40) as
        ead_value:

        -  EAD_x = 0x0040

     *  Three bytes padding, constructed from the pseudorandomly generated
        ead_value 0xe9 encoded as byte string:

        -  EAD_x = 0x0041e9

     Multiple occurrences of EAD items with ead_label = 0 are allowed.
     Certain padding lengths require the use of at least two such EAD
     items.





  Selander, et al.          Expires 25 July 2024                 [Page 23]


  Internet-Draft                    EDHOC                     January 2024


     Note that padding is non-critical because the intended behaviour when
     receiving is to ignore it.

  3.9.  Application Profile

     EDHOC requires certain parameters to be agreed upon between Initiator
     and Responder.  Some parameters can be negotiated through the
     protocol execution (specifically, cipher suite, see Section 3.6) but
     other parameters are only communicated and may not be negotiated
     (e.g., which authentication method is used, see Section 3.2).  Yet
     other parameters need to be known out-of-band to ensure successful
     completion, e.g., whether message_4 is used or not.  The application
     decides which endpoint is Initiator and which is Responder.

     The purpose of an application profile is to describe the intended use
     of EDHOC to allow for the relevant processing and verifications to be
     made, including things like:

     1.  How the endpoint detects that an EDHOC message is received.  This
         includes how EDHOC messages are transported, for example in the
         payload of a CoAP message with a certain Uri-Path or Content-
         Format; see Appendix A.2.

         *  The method of transporting EDHOC messages may also describe
            data carried along with the messages that are needed for the
            transport to satisfy the requirements of Section 3.4, e.g.,
            connection identifiers used with certain messages, see
            Appendix A.2.

     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 CCS, including
         supported authentication key algorithms (subject public key
         algorithm in X.509 or C509 certificate).

     4.  Type used to identify credentials (ID_CRED_I, ID_CRED_R; see
         Section 3.5.3).

     5.  Use and type of external authorization data (EAD_1, EAD_2, EAD_3,
         EAD_4; see Section 3.8).

     6.  Identifier used as the identity of the endpoint; see
         Appendix D.2.

     7.  If message_4 shall be sent/expected, and if not, how to ensure a
         protected application message is sent from the Responder to the
         Initiator; see Section 5.5.



  Selander, et al.          Expires 25 July 2024                 [Page 24]


  Internet-Draft                    EDHOC                     January 2024


     The application profile may also contain information about supported
     cipher suites.  The procedure for selecting and verifying a cipher
     suite is still performed as described in Section 5.2.1 and
     Section 6.3, but it may become simplified by this knowledge.  EDHOC
     messages can be processed without the application profile, i.e., the
     EDHOC messages includes information about the type and length of all
     fields.

     An example of an application profile is shown in Appendix F.

     For some parameters, like METHOD, type of ID_CRED field or EAD, the
     receiver of an EDHOC message is able to verify compliance with the
     application profile, and if it needs to fail because of lack of
     compliance, to infer the reason why the EDHOC session failed.

     For other encodings, like the profiling of CRED_x in the case that it
     is not transported, it may not be possible to verify that lack of
     compliance with the application profile was the reason for failure:
     Integrity verification in message_2 or message_3 may fail not only
     because of a wrong credential.  For example, in case the Initiator
     uses a public key certificate by reference (i.e., not transported
     within the protocol) then both endpoints need to use an identical
     data structure as CRED_I or else the integrity verification will
     fail.

     Note that it is not necessary for the endpoints to specify a single
     transport for the EDHOC messages.  For example, a mix of CoAP and
     HTTP may be used along the path, and this may still allow correlation
     between messages.

     The application profile may be dependent on the identity of the other
     endpoint, or other information carried in an EDHOC message, but it
     then applies only to the later phases of the protocol when such
     information is known.  (The Initiator does not know the identity of
     the Responder before having verified message_2, and the Responder
     does not know the identity of the Initiator before having verified
     message_3.)

     Other conditions may be part of the application profile, such as what
     is the target application or use (if there is more than one
     application/use) to the extent that EDHOC can distinguish between
     them.  In case multiple application profiles are used, the receiver
     needs to be able to determine which is applicable for a given EDHOC
     session, for example based on URI to which the EDHOC message is sent,
     or external authorization data type.

  4.  Key Derivation




  Selander, et al.          Expires 25 July 2024                 [Page 25]


  Internet-Draft                    EDHOC                     January 2024


  4.1.  Keys for EDHOC Message Processing

     EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm
     in the selected cipher suite to derive keys used in message
     processing.  This section defines EDHOC_Extract (Section 4.1.1) and
     EDHOC_Expand (Section 4.1.2), and how to use them to derive PRK_out
     (Section 4.1.3) which is the shared secret session key resulting from
     a completed EDHOC session.

     EDHOC_Extract is used to derive fixed-length uniformly pseudorandom
     keys (PRK) from ECDH shared secrets.  EDHOC_Expand is used to define
     EDHOC_KDF for generating MACs and for deriving output keying material
     (OKM) from PRKs.

     In EDHOC a specific message is protected with a certain pseudorandom
     key, but how the key is derived depends on the authentication method
     (Section 3.2) as detailed in Section 5.

  4.1.1.  EDHOC_Extract

     The pseudorandom keys (PRKs) used for EDHOC message processing are
     derived using EDHOC_Extract:

        PRK = EDHOC_Extract( salt, IKM )

     where the input keying material (IKM) and salt are defined for each
     PRK below.

     The definition of EDHOC_Extract depends on the EDHOC hash algorithm
     of the selected cipher suite:

     *  if the EDHOC hash algorithm is SHA-2, then EDHOC_Extract( salt,
        IKM ) = HKDF-Extract( salt, IKM ) [RFC5869]

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

     *  if the EDHOC hash algorithm is SHAKE256, then EDHOC_Extract( salt,
        IKM ) = KMAC256( salt, IKM, 512, "" )

     where the Keccak message authentication code (KMAC) is specified in
     [SP800-185].

     The rest of the section defines the pseudorandom keys PRK_2e,
     PRK_3e2m and PRK_4e3m; their use is shown in Figure 8.  The index of
     a PRK indicates its use or in what message protection operation it is
     involved.  For example, PRK_3e2m is involved in the encryption of
     message 3 and in calculating the MAC of message 2.



  Selander, et al.          Expires 25 July 2024                 [Page 26]


  Internet-Draft                    EDHOC                     January 2024


  4.1.1.1.  PRK_2e

     The pseudorandom key PRK_2e is derived with the following input:

     *  The salt SHALL be TH_2.

     *  The IKM SHALL be the ephemeral-ephemeral ECDH shared secret G_XY
        (calculated from G_X and Y or G_Y and X) as defined in
        Section 6.3.1 of [RFC9053].  The use of G_XY gives forward
        secrecy, in the sense that compromise of the private
        authentication keys does not compromise past session keys.

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

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

     Example: Assuming the use of SHA-256 the extract phase of HKDF
     produces PRK_2e as follows:

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

  4.1.1.2.  PRK_3e2m

     The pseudorandom key PRK_3e2m is derived as follows:

     If the Responder authenticates with a static Diffie-Hellman key, then
     PRK_3e2m = EDHOC_Extract( SALT_3e2m, G_RX ), where

     *  SALT_3e2m is derived from PRK_2e, see Section 4.1.2, and

     *  G_RX is the ECDH shared secret calculated from G_R and X, or G_X
        and R (the Responder's private authentication key, see
        Section 3.5.1),

     else PRK_3e2m = PRK_2e.

  4.1.1.3.  PRK_4e3m

     The pseudorandom key PRK_4e3m is derived as follows:

     If the Initiator authenticates with a static Diffie-Hellman key, then
     PRK_4e3m = EDHOC_Extract( SALT_4e3m, G_IY ), where

     *  SALT_4e3m is derived from PRK_3e2m, see Section 4.1.2, and






  Selander, et al.          Expires 25 July 2024                 [Page 27]


  Internet-Draft                    EDHOC                     January 2024


     *  G_IY is the ECDH shared secret calculated from G_I and Y, or G_Y
        and I (the Initiator's private authentication key, see
        Section 3.5.1),

     else PRK_4e3m = PRK_3e2m.

  4.1.2.  EDHOC_Expand and EDHOC_KDF

     The output keying material (OKM) - including keys, IVs, and salts -
     are derived from the PRKs using the EDHOC_KDF, which is defined
     through EDHOC_Expand:

        OKM = EDHOC_KDF( PRK, info_label, context, length )
            = EDHOC_Expand( PRK, info, length )

     where info is encoded as the CBOR sequence

     info = (
       info_label : int,
       context : bstr,
       length : uint,
     )

     where

     *  info_label is an int

     *  context is a bstr

     *  length is the length of OKM in bytes

     When EDHOC_KDF is used to derive OKM for EDHOC message processing,
     then context includes one of the transcript hashes TH_2, TH_3, or
     TH_4 defined in Sections 5.3.2 and 5.4.2.

     The definition of EDHOC_Expand depends on the EDHOC hash algorithm of
     the selected cipher suite:

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

     *  if the EDHOC hash algorithm is SHAKE128, then EDHOC_Expand( PRK,
        info, length ) = KMAC128( PRK, info, L, "" )

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

     where L = 8 ⋅ length, the output length in bits.



  Selander, et al.          Expires 25 July 2024                 [Page 28]


  Internet-Draft                    EDHOC                     January 2024


     Figure 8 lists derivations made with EDHOC_KDF, where

     *  hash_length - length of output size of the EDHOC hash algorithm of
        the selected cipher suite

     *  key_length - length of the encryption key of the EDHOC AEAD
        algorithm of the selected cipher suite

     *  iv_length - length of the initialization vector of the EDHOC AEAD
        algorithm of the selected cipher suite

     Further details of the key derivation and how the output keying
     material is used are specified in Section 5.

     KEYSTREAM_2   = EDHOC_KDF( PRK_2e,   0, TH_2,      plaintext_length )
     SALT_3e2m     = EDHOC_KDF( PRK_2e,   1, TH_2,      hash_length )
     MAC_2         = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 )
     K_3           = EDHOC_KDF( PRK_3e2m, 3, TH_3,      key_length )
     IV_3          = EDHOC_KDF( PRK_3e2m, 4, TH_3,      iv_length )
     SALT_4e3m     = EDHOC_KDF( PRK_3e2m, 5, TH_3,      hash_length )
     MAC_3         = EDHOC_KDF( PRK_4e3m, 6, context_3, mac_length_3 )
     PRK_out       = EDHOC_KDF( PRK_4e3m, 7, TH_4,      hash_length )
     K_4           = EDHOC_KDF( PRK_4e3m, 8, TH_4,      key_length )
     IV_4          = EDHOC_KDF( PRK_4e3m, 9, TH_4,      iv_length )
     PRK_exporter  = EDHOC_KDF( PRK_out, 10, h'',       hash_length )

       Figure 8: Key derivations using EDHOC_KDF. h'' is CBOR diagnostic
                   notation for the empty byte string, 0x40.

  4.1.3.  PRK_out

     The pseudorandom key PRK_out, derived as shown in Figure 8, is the
     output session key of a completed EDHOC session.

     Keys for applications are derived using EDHOC_Exporter (see
     Section 4.2.1) from PRK_exporter, which in turn is derived from
     PRK_out as shown in Figure 8.  For the purpose of generating
     application keys, it is sufficient to store PRK_out or PRK_exporter.
     (Note that the word "store" used here does not imply that the
     application has access to the plaintext PRK_out since that may be
     reserved for code within a Trusted Execution Environment, see
     Section 9.8).

  4.2.  Keys for EDHOC Applications

     This section defines EDHOC_Exporter in terms of EDHOC_KDF and
     PRK_exporter.  A key update function is defined in Appendix H.




  Selander, et al.          Expires 25 July 2024                 [Page 29]


  Internet-Draft                    EDHOC                     January 2024


  4.2.1.  EDHOC_Exporter

     Keying material for the application can be derived using the
     EDHOC_Exporter interface defined as:

        EDHOC_Exporter(exporter_label, context, length)
          = EDHOC_KDF(PRK_exporter, exporter_label, context, length)

     where

     *  exporter_label is a registered uint from the EDHOC_Exporter Label
        registry (Section 10.1)

     *  context is a bstr defined by the application

     *  length is a uint defined by the application

     The (exporter_label, context) pair used in EDHOC_Exporter must be
     unique, i.e., an (exporter_label, context) MUST NOT be used for two
     different purposes.  However, an application can re-derive the same
     key several times as long as it is done securely.  For example, in
     most encryption algorithms the same key can be reused with different
     nonces.  The context can for example be the empty CBOR byte string.

     Examples of use of the EDHOC_Exporter are given in Appendix A.

  5.  Message Formatting and Processing

     This section specifies formatting of the messages and processing
     steps.  Error messages are specified in Section 6.  Annotated traces
     of EDHOC sessions are provided in [I-D.ietf-lake-traces].

     An EDHOC message is encoded as a sequence of CBOR data items (CBOR
     Sequence, [RFC8742]).  Additional optimizations are made to reduce
     message overhead.

     While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
     structures, only a subset of the parameters is included in the EDHOC
     messages, see Appendix C.3.  In order to recreate the COSE object,
     the recipient endpoint may need to add parameters to the COSE headers
     not included in the EDHOC message, for example the parameter 'alg' to
     COSE_Sign1 or COSE_Encrypt0.









  Selander, et al.          Expires 25 July 2024                 [Page 30]


  Internet-Draft                    EDHOC                     January 2024


  5.1.  EDHOC Message Processing Outline

     For each new/ongoing EDHOC session, the endpoints are assumed to keep
     an associated protocol state containing identifiers, keying material,
     etc. used for subsequent processing of protocol related data.  The
     protocol state is assumed to be associated with an application
     profile (Section 3.9) which provides the context for how messages are
     transported, identified, and processed.

     EDHOC messages SHALL be processed according 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, for example by
         means of port number, URI, or media type (Section 3.9).

     2.  Retrieve the protocol state according to the message correlation,
         see Section 3.4.1.  If there is no protocol state, in the case of
         message_1, a new protocol state is created.  The Responder
         endpoint needs to make use of available denial-of-service
         mitigation (Section 9.7).

     3.  If the message received is an error message, then process it
         according to Section 6, else process it as the expected next
         message according to the protocol state.

     The message processing steps SHALL be processed in order, unless
     otherwise stated.  If the processing fails for some reason then,
     typically, an error message is sent, the EDHOC session is aborted,
     and the protocol state erased.  When the composition and sending of
     one message is completed and before the next message is received,
     error messages SHALL NOT be sent.

     After having successfully processed the last message (message_3 or
     message_4 depending on application profile) the EDHOC session is
     completed, after which no error messages are sent and EDHOC session
     output MAY be maintained even if error messages are received.
     Further details are provided in the following subsections and in
     Section 6.

     Different instances of the same message MUST NOT be processed in one
     EDHOC session.  Note that processing will fail if the same message
     appears a second time for EDHOC processing in the same EDHOC session
     because the state of the protocol has moved on and now expects
     something else.  Message deduplication MUST be done by the transport
     protocol (see Section 3.4) or, if not supported by the transport, as
     described in Section 7.




  Selander, et al.          Expires 25 July 2024                 [Page 31]


  Internet-Draft                    EDHOC                     January 2024


  5.2.  EDHOC Message 1

  5.2.1.  Formatting of Message 1

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

     message_1 = (
       METHOD : int,
       SUITES_I : suites,
       G_X : bstr,
       C_I : bstr / -24..23,
       ? EAD_1,
     )

     suites = [ 2* int ] / int
     EAD_1 = 1* ead

     where:

     *  METHOD - authentication method, see Section 3.2.

     *  SUITES_I - array of cipher suites which the Initiator supports
        constructed as specified in Section 5.2.2.

     *  G_X - the ephemeral public key of the Initiator

     *  C_I - variable length connection identifier.  Note that connection
        identifiers are byte strings but certain values are represented as
        integers in the message, see Section 3.3.2.

     *  EAD_1 - external authorization data, see Section 3.8.

  5.2.2.  Initiator Composition of Message 1

     The processing steps are detailed below and in Section 6.3.

     The Initiator SHALL compose message_1 as follows:

     *  Construct SUITES_I as an array of cipher suites supported by I in
        order of preference by I with the first cipher suite in the array
        being the most preferred by I, and the last being the one selected
        by I for this EDHOC session.  If the cipher suite most preferred
        by I is selected then SUITES_I contains only that cipher suite and
        is encoded as an int.  All cipher suites, if any, preferred by I
        over the selected one MUST be included.  (See also Section 6.3.)





  Selander, et al.          Expires 25 July 2024                 [Page 32]


  Internet-Draft                    EDHOC                     January 2024


        -  The selected suite is based on what the Initiator can assume to
           be supported by the Responder; if the Initiator previously
           received from the Responder an error message with error code 2
           containing SUITES_R (see Section 6.3) indicating cipher suites
           supported by the Responder, then the Initiator SHOULD select
           its most preferred supported cipher suite among those (bearing
           in mind that error messages may be forged).

        -  The Initiator MUST NOT change its order of preference for
           cipher suites, and MUST NOT omit a cipher suite preferred to
           the selected one because of previous error messages received
           from the Responder.

     *  Generate an ephemeral ECDH key pair using the curve in the
        selected cipher suite and format it as a COSE_Key.  Let G_X be the
        'x' parameter of the COSE_Key.

     *  Choose a connection identifier C_I and store it during the EDHOC
        session.

     *  Encode message_1 as a sequence of CBOR encoded data items as
        specified in Section 5.2.1

  5.2.3.  Responder Processing of Message 1

     The Responder SHALL process message_1 in the following order:

     *  Decode message_1 (see Appendix C.1).

     *  Process message_1, in particular verify that the selected cipher
        suite is supported and that no prior cipher suite as ordered in
        SUITES_I is supported.

     *  If all processing completed successfully, and if EAD_1 is present,
        then make it available to the application for EAD processing.

     If any processing step fails, then the Responder MUST send an EDHOC
     error message back as defined in Section 6, and the EDHOC session
     MUST be aborted.

  5.3.  EDHOC Message 2

  5.3.1.  Formatting of Message 2

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





  Selander, et al.          Expires 25 July 2024                 [Page 33]


  Internet-Draft                    EDHOC                     January 2024


     message_2 = (
       G_Y_CIPHERTEXT_2 : bstr,
     )

     where:

     *  G_Y_CIPHERTEXT_2 - the concatenation of G_Y (i.e., the ephemeral
        public key of the Responder) and CIPHERTEXT_2.

  5.3.2.  Responder Composition of Message 2

     The Responder SHALL compose message_2 as follows:

     *  Generate an ephemeral ECDH key pair using the curve in the
        selected cipher suite and format it as a COSE_Key.  Let G_Y be the
        'x' parameter of the COSE_Key.

     *  Choose a connection identifier C_R and store it for the length of
        the EDHOC session.

     *  Compute the transcript hash TH_2 = H( G_Y, H(message_1) ) where
        H() is the EDHOC hash algorithm of the selected cipher suite.  The
        input to the hash function is a CBOR Sequence.  Note that
        H(message_1) can be computed and cached already in the processing
        of message_1.

     *  Compute MAC_2 as in Section 4.1.2 with context_2 = << C_R,
        ID_CRED_R, TH_2, CRED_R, ? EAD_2 >> (see Appendix C.1 for
        notation)

        -  If the Responder authenticates with a static Diffie-Hellman key
           (method equals 1 or 3), then mac_length_2 is the EDHOC MAC
           length of the selected cipher suite.  If the Responder
           authenticates with a signature key (method equals 0 or 2), then
           mac_length_2 is equal to hash_length.

        -  C_R - variable length connection identifier.  Note that
           connection identifiers are byte strings but certain values are
           represented as integers in the message, see Section 3.3.2.

        -  ID_CRED_R - identifier to facilitate the retrieval of CRED_R,
           see Section 3.5.3

        -  CRED_R - CBOR item containing the authentication credential of
           the Responder, see Section 3.5.2

        -  EAD_2 - external authorization data, see Section 3.8




  Selander, et al.          Expires 25 July 2024                 [Page 34]


  Internet-Draft                    EDHOC                     January 2024


     *  If the Responder authenticates with a static Diffie-Hellman key
        (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2.  If the
        Responder authenticates with a signature key (method equals 0 or
        2), then Signature_or_MAC_2 is the 'signature' field of a
        COSE_Sign1 object, computed as specified in Section 4.4 of
        [RFC9053] using the signature algorithm of the selected cipher
        suite, the private authentication key of the Responder, and the
        following parameters as input (see Appendix C.3 for an overview of
        COSE and Appendix C.1 for notation):

        -  protected = << ID_CRED_R >>

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

        -  payload = MAC_2

     *  CIPHERTEXT_2 is calculated with a binary additive stream cipher,
        using a keystream generated with EDHOC_Expand, and the following
        plaintext:

        -  PLAINTEXT_2 = ( C_R, ID_CRED_R / bstr / -24..23,
           Signature_or_MAC_2, ? EAD_2 )

           o  If ID_CRED_R contains a single 'kid' parameter, i.e.,
              ID_CRED_R = { 4 : kid_R }, then the compact encoding is
              applied, see Section 3.5.3.2.

           o  C_R - variable length connection identifier.  Note that
              connection identifiers are byte strings but certain values
              are represented as integers in the message, see
              Section 3.3.2.

        -  Compute KEYSTREAM_2 as in Section 4.1.2, where plaintext_length
           is the length of PLAINTEXT_2.  For the case of plaintext_length
           exceeding the EDHOC_KDF output size, see Appendix G.

        -  CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2

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

  5.3.3.  Initiator Processing of Message 2

     The Initiator SHALL process message_2 in the following order:

     *  Decode message_2 (see Appendix C.1).





  Selander, et al.          Expires 25 July 2024                 [Page 35]


  Internet-Draft                    EDHOC                     January 2024


     *  Retrieve the protocol state using available message correlation
        (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see
        Section 3.4.1).

     *  Decrypt CIPHERTEXT_2, see Section 5.3.2.

     *  If all processing completed successfully, then make ID_CRED_R and
        (if present) EAD_2 available to the application for
        authentication- and EAD processing.  When and how to perform
        authentication is up to the application.

     *  Obtain the authentication credential (CRED_R) and the
        authentication key of R from the application (or by other means).

     *  Verify Signature_or_MAC_2 using the algorithm in the selected
        cipher suite.  The verification process depends on the method, see
        Section 5.3.2.  Make the result of the verification available to
        the application.

     If any processing step fails, then the Initiator MUST send an EDHOC
     error message back as defined in Section 6, and the EDHOC session
     MUST be aborted.

  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

     message_3 = (
       CIPHERTEXT_3 : bstr,
     )

  5.4.2.  Initiator Composition of Message 3

     The Initiator SHALL compose message_3 as follows:

     *  Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R)
        where H() is the EDHOC hash algorithm of the selected cipher
        suite.  The input to the hash function is a CBOR Sequence.  Note
        that TH_3 can be computed and cached already in the processing of
        message_2.

     *  Compute MAC_3 as in Section 4.1.2, with context_3 = << ID_CRED_I,
        TH_3, CRED_I, ? EAD_3 >>





  Selander, et al.          Expires 25 July 2024                 [Page 36]


  Internet-Draft                    EDHOC                     January 2024


        -  If the Initiator authenticates with a static Diffie-Hellman key
           (method equals 2 or 3), then mac_length_3 is the EDHOC MAC
           length of the selected cipher suite.  If the Initiator
           authenticates with a signature key (method equals 0 or 1), then
           mac_length_3 is equal to hash_length.

        -  ID_CRED_I - identifier to facilitate the retrieval of CRED_I,
           see Section 3.5.3

        -  CRED_I - CBOR item containing the authentication credential of
           the Initiator, see Section 3.5.2

        -  EAD_3 - external authorization data, see Section 3.8

     *  If the Initiator authenticates with a static Diffie-Hellman key
        (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3.  If the
        Initiator authenticates with a signature key (method equals 0 or
        1), then Signature_or_MAC_3 is the 'signature' field of a
        COSE_Sign1 object, computed as specified in Section 4.4 of
        [RFC9052] using the signature algorithm of the selected cipher
        suite, the private authentication key of the Initiator, and the
        following parameters as input (see Appendix C.3):

        -  protected = << ID_CRED_I >>

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

        -  payload = MAC_3

     *  Compute a COSE_Encrypt0 object as defined in Sections 5.2 and 5.3
        of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
        suite, using the encryption key K_3, the initialization vector
        IV_3 (if used by the AEAD algorithm), the plaintext PLAINTEXT_3,
        and the following parameters as input (see Appendix C.3):

        -  protected = h''

        -  external_aad = TH_3

        -  K_3 and IV_3 are defined in Section 4.1.2

        -  PLAINTEXT_3 = ( ID_CRED_I / bstr / -24..23, Signature_or_MAC_3,
           ? EAD_3 )

           o  If ID_CRED_I contains a single 'kid' parameter, i.e.,
              ID_CRED_I = { 4 : kid_I }, then the compact encoding is
              applied, see Section 3.5.3.2.




  Selander, et al.          Expires 25 July 2024                 [Page 37]


  Internet-Draft                    EDHOC                     January 2024


        CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.

     *  Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I)
        where H() is the EDHOC hash algorithm of the selected cipher
        suite.  The input to the hash function is a CBOR Sequence.

     *  Calculate PRK_out as defined in Figure 8.  The Initiator can now
        derive application keys using the EDHOC_Exporter interface, see
        Section 4.2.1.

     *  Encode message_3 as a CBOR data item as specified in
        Section 5.4.1.

     *  Make the connection identifiers (C_I, C_R) and the application
        algorithms in the selected cipher suite available to the
        application.

     After creating message_3, the Initiator can compute PRK_out, see
     Section 4.1.3, and derive application keys using the EDHOC_Exporter
     interface, see Section 4.2.1.  The Initiator SHOULD NOT persistently
     store PRK_out or application keys until the Initiator has verified
     message_4 or a message protected with a derived application key, such
     as an OSCORE message, from the Responder and the application has
     authenticated the Responder.  This is similar to waiting for an
     acknowledgment (ACK) in a transport protocol.  The Initiator SHOULD
     NOT send protected application data until the application has
     authenticated the Responder.

  5.4.3.  Responder Processing of Message 3

     The Responder SHALL process message_3 in the following order:

     *  Decode message_3 (see Appendix C.1).

     *  Retrieve the protocol state using available message correlation
        (e.g., the CoAP Token, the 5-tuple, or the prepended C_R, see
        Section 3.4.1).

     *  Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
        and 5.3 of [RFC9052], with the EDHOC AEAD algorithm in the
        selected cipher suite, and the parameters defined in
        Section 5.4.2.

     *  If all processing completed successfully, then make ID_CRED_I and
        (if present) EAD_3 available to the application for
        authentication- and EAD processing.  When and how to perform
        authentication is up to the application.




  Selander, et al.          Expires 25 July 2024                 [Page 38]


  Internet-Draft                    EDHOC                     January 2024


     *  Obtain the authentication credential (CRED_I) and the
        authentication key of I from the application (or by other means).

     *  Verify Signature_or_MAC_3 using the algorithm in the selected
        cipher suite.  The verification process depends on the method, see
        Section 5.4.2.  Make the result of the verification available to
        the application.

     *  Make the connection identifiers (C_I, C_R) and the application
        algorithms in the selected cipher suite available to the
        application.

     After processing message_3, the Responder can compute PRK_out, see
     Section 4.1.3, and derive application keys using the EDHOC_Exporter
     interface, see Section 4.2.1.  The Responder SHOULD NOT persistently
     store PRK_out or application keys until the application has
     authenticated the Initiator.  The Responder SHOULD NOT send protected
     application data until the application has authenticated the
     Initiator.

     If any processing step fails, then the Responder MUST send an EDHOC
     error message back as defined in Section 6, and the EDHOC session
     MUST be aborted.

  5.5.  EDHOC Message 4

     This section specifies message_4 which is OPTIONAL to support.  Key
     confirmation is normally provided by sending an application message
     from the Responder to the Initiator protected with a 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, message_4 MUST be supported and MUST be
     used.  Two examples of such deployments are:

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

     2.  When application data is only sent from the Initiator to the
         Responder.

     Further considerations about when to use message_4 are provided in
     Section 3.9 and Section 9.1.

  5.5.1.  Formatting of Message 4

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




  Selander, et al.          Expires 25 July 2024                 [Page 39]


  Internet-Draft                    EDHOC                     January 2024


     message_4 = (
       CIPHERTEXT_4 : bstr,
     )

  5.5.2.  Responder Composition of Message 4

     The Responder SHALL compose message_4 as follows:

     *  Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of
        [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
        suite, using the encryption key K_4, the initialization vector
        IV_4 (if used by the AEAD algorithm), the plaintext PLAINTEXT_4,
        and the following parameters as input (see Appendix C.3):

        -  protected = h''

        -  external_aad = TH_4

        -  K_4 and IV_4 are defined in Section 4.1.2

        -  PLAINTEXT_4 = ( ? EAD_4 )

           o  EAD_4 - external authorization data, see Section 3.8.

        CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.

     *  Encode message_4 as a CBOR data item 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 protocol state using available message correlation
        (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see
        Section 3.4.1).

     *  Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
        and 5.3 of [RFC9052], with the EDHOC AEAD algorithm in the
        selected cipher suite, and the parameters defined in
        Section 5.5.2.

     *  Make (if present) EAD_4 available to the application for EAD
        processing.





  Selander, et al.          Expires 25 July 2024                 [Page 40]


  Internet-Draft                    EDHOC                     January 2024


     If any processing step fails, then the Initiator MUST send an EDHOC
     error message back as defined in Section 6, and the EDHOC session
     MUST be aborted.

     After verifying message_4, the Initiator is assured that the
     Responder has calculated the key PRK_out (key confirmation) and that
     no other party can derive the key.

  6.  Error Handling

     This section defines the format for error messages, and the
     processing associated with the currently defined error codes.
     Additional error codes may be registered, see Section 10.4.

     Many kinds of errors that can occur during EDHOC processing.  As in
     CoAP, an error can be triggered by errors in the received message or
     internal errors in the receiving endpoint.  Except for processing and
     formatting errors, it is up to the application when to send an error
     message.  Sending error messages is essential for debugging but MAY
     be skipped if, for example, an EDHOC session cannot be found or due
     to denial-of-service reasons, see Section 9.7.  Error messages in
     EDHOC are always fatal.  After sending an error message, the sender
     MUST abort the EDHOC session.  The receiver SHOULD treat an error
     message as an indication that the other party likely has aborted the
     EDHOC session.  But since error messages might be forged, the
     receiver MAY try to continue the EDHOC session.

     An EDHOC error message can be sent by either endpoint as 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 be sent and processed as intended.

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

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

                         Figure 9: EDHOC error message.

     where:

     *  ERR_CODE - error code encoded as an integer.  The value 0 is
        reserved for success and can only be used internally, all other
        values (negative or positive) indicate errors.





  Selander, et al.          Expires 25 July 2024                 [Page 41]


  Internet-Draft                    EDHOC                     January 2024


     *  ERR_INFO - error information.  Content and encoding depend on
        error code.

     The remainder of this section specifies the currently defined error
     codes, see Figure 10.  Additional error codes and corresponding error
     information may be specified.

     +----------+---------------+----------------------------------------+
     | ERR_CODE | ERR_INFO Type | Description                            |
     +==========+===============+========================================+
     |        0 |               | This value is reserved                 |
     +----------+---------------+----------------------------------------+
     |        1 | tstr          | Unspecified error                      |
     +----------+---------------+----------------------------------------+
     |        2 | suites        | Wrong selected cipher suite            |
     +----------+---------------+----------------------------------------+
     |        3 | true          | Unknown credential referenced          |
     +----------+---------------+----------------------------------------+

              Figure 10: EDHOC error codes and error information.

  6.1.  Success

     Error code 0 MAY be used internally in an application to indicate
     success, i.e., as a standard value in case of no error, e.g., in
     status reporting or log files.  Error code 0 MUST NOT be used as part
     of the EDHOC message exchange.  If an endpoint receives an error
     message with error code 0, then it MUST abort the EDHOC session and
     MUST NOT send an error message.

  6.2.  Unspecified Error

     Error code 1 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 which SHOULD be written in English, for
     example "Method not supported".  The diagnostic text message is
     mainly intended for software engineers that during debugging need to
     interpret it in the context of the EDHOC specification.  The
     diagnostic message SHOULD be provided to the calling application
     where it SHOULD be logged.











  Selander, et al.          Expires 25 July 2024                 [Page 42]


  Internet-Draft                    EDHOC                     January 2024


  6.3.  Wrong Selected Cipher Suite

     Error code 2 MUST only be used when replying to message_1 in case the
     cipher suite selected by the Initiator is not supported by the
     Responder, or if the Responder supports a cipher suite more preferred
     by the Initiator than the selected cipher suite, see Section 5.2.3.
     In this case, ERR_INFO = SUITES_R and is of type suites, see
     Section 5.2.1.  If the Responder does not support the selected cipher
     suite, then SUITES_R MUST include one or more supported cipher
     suites.  If the Responder supports a cipher suite in SUITES_I other
     than the selected cipher suite (independently of if the selected
     cipher suite is supported or not) then SUITES_R MUST include the
     supported cipher suite in SUITES_I which is most preferred by the
     Initiator.  SUITES_R MAY include a single cipher suite, in which case
     it is encoded as an int.  If the Responder does not support any
     cipher suite in SUITES_I, then it SHOULD include all its supported
     cipher suites in SUITES_R.

     In contrast to SUITES_I, the order of the cipher suites in SUITES_R
     has no significance.

  6.3.1.  Cipher Suite Negotiation

     After receiving SUITES_R, the Initiator can determine which cipher
     suite to select (if any) for the next EDHOC run with the Responder.

     If the Initiator intends to contact the Responder in the future, the
     Initiator SHOULD remember which selected cipher suite to use until
     the next message_1 has been sent, otherwise the Initiator and
     Responder will likely run into an infinite loop where the Initiator
     selects its most preferred cipher suite and the Responder sends an
     error with supported cipher suites.  After a completed EDHOC session,
     the Initiator MAY remember the selected cipher suite to use in future
     EDHOC sessions.  Note that if the Initiator or Responder is updated
     with new cipher suite policies, any cached information may be
     outdated.

     Note that the Initiator's list of supported cipher suites and order
     of preference is fixed (see Section 5.2.1 and Section 5.2.2).
     Furthermore, the Responder SHALL only accept message_1 if the
     selected cipher suite is the first cipher suite in SUITES_I that the
     Responder also supports (see Section 5.2.3).  Following this
     procedure ensures that the selected cipher suite is the most
     preferred (by the Initiator) cipher suite supported by both parties.
     For examples, see Section 6.3.2.






  Selander, et al.          Expires 25 July 2024                 [Page 43]


  Internet-Draft                    EDHOC                     January 2024


     If the selected cipher suite is not the first cipher suite which the
     Responder supports in SUITES_I received in message_1, then the
     Responder MUST abort the EDHOC session, see Section 5.2.3.  If
     SUITES_I in message_1 is manipulated, then the integrity verification
     of message_2 containing the transcript hash TH_2 will fail and the
     Initiator will abort the EDHOC session.

  6.3.2.  Examples

     Assume that the Initiator supports the five cipher suites 5, 6, 7, 8,
     and 9 in decreasing order of preference.  Figures 11 and 12 show two
     examples of how the Initiator can format SUITES_I and how SUITES_R is
     used by Responders to give the Initiator information about the cipher
     suites that the Responder supports.

     In Example 1 (Figure 11), the Responder supports cipher suite 6 but
     not the initially selected cipher suite 5.  The Responder rejects the
     first message_1 with an error indicating support for suite 6 in
     SUITES_R.  The Initiator also supports suite 6, and therefore selects
     suite 6 in the second message_1.  The Initiator prepends in SUITES_I
     the selected suite 6 with the more preferred suites, in this case
     suite 5, to mitigate a potential attack on the cipher suite
     negotiation.

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

                 Figure 11: Cipher suite negotiation example 1.













  Selander, et al.          Expires 25 July 2024                 [Page 44]


  Internet-Draft                    EDHOC                     January 2024


     In Example 2 (Figure 12), the Responder supports cipher suites 8 and
     9 but not the more preferred (by the Initiator) cipher suites 5, 6 or
     7.  To illustrate the negotiation mechanics we let the Initiator
     first make a guess that the Responder supports suite 6 but not suite
     5.  Since the Responder supports neither 5 nor 6, it rejects the
     first message_1 with an error indicating support for suites 8 and 9
     in SUITES_R (in any order).  The Initiator also supports suites 8 and
     9, and prefers suite 8, so selects suite 8 in the second message_1.
     The Initiator prepends in SUITES_I the selected suite 8 with the more
     preferred suites in order of preference, in this case suites 5, 6 and
     7, to mitigate a potential attack on the cipher suite negotiation.

     Note 1.  If the Responder had supported suite 5, then the first
     message_1 would not have been accepted either, since the Responder
     observes that suite 5 is more preferred by the Initiator than the
     selected suite 6.  In that case the Responder would have included
     suite 5 in SUITES_R of the response, and it would then have become
     the selected and only suite in the second message_1.

     Note 2.  For each message_1 the Initiator MUST generate a new
     ephemeral ECDH key pair matching the selected cipher suite.

     Initiator                                                   Responder
     |            METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1             |
     +------------------------------------------------------------------>|
     |                             message_1                             |
     |                                                                   |
     |                  ERR_CODE = 2, SUITES_R = [9, 8]                  |
     |<------------------------------------------------------------------+
     |                               error                               |
     |                                                                   |
     |           METHOD, SUITES_I = [5, 6, 7, 8], G_X, C_I, EAD_1        |
     +------------------------------------------------------------------>|
     |                             message_1                             |

                 Figure 12: Cipher suite negotiation example 2.

  6.4.  Unknown Credential Referenced

     Error code 3 is used for errors due to a received credential
     identifier (ID_CRED_R in message_2 or ID_CRED_I message_3) containing
     a reference to a credential which the receiving endpoint does not
     have access to.  The intent with this error code is that the endpoint
     who sent the credential identifier should for the next EDHOC session
     try another credential identifier supported according to the
     application profile.





  Selander, et al.          Expires 25 July 2024                 [Page 45]


  Internet-Draft                    EDHOC                     January 2024


     For example, an application profile could list x5t and x5chain as
     supported credential identifiers, and state that x5t should be used
     if it can be assumed that the X.509 certificate is available at the
     receiving side.  This error code thus enables the certificate chain
     to be sent only when needed, bearing in mind that error messages are
     not protected so an adversary can try to cause unnecessary large
     credential identifiers.

     For the error code 3, the error information SHALL be the CBOR simple
     value true (0xf5).  Error code 3 MUST NOT be used when the received
     credential identifier type is not supported.

  7.  EDHOC Message Deduplication

     EDHOC by default assumes that message duplication is handled by the
     transport, in this section exemplified with CoAP, see Appendix A.2.

     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 acknowledgment on
     the 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 do 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 the CoAP messaging layer: a received duplicate EDHOC message SHALL
     NOT result in another instance of the next EDHOC message.  The result
     MAY be that a duplicate next EDHOC message is sent, provided it is
     still relevant with respect to 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.

     In principle, if the EDHOC implementation would deterministically
     regenerate the identical EDHOC message previously sent, it would be
     possible to instead store the protocol state to be able to recreate
     and resend the previously sent EDHOC message.  However, even if the
     protocol state is fixed, the message generation may introduce



  Selander, et al.          Expires 25 July 2024                 [Page 46]


  Internet-Draft                    EDHOC                     January 2024


     differences which compromise security.  For example, in the
     generation of message_3, if I is performing a (non-deterministic)
     ECDSA signature (say, method 0 or 1, cipher suite 2 or 3) then
     PLAINTEXT_3 is randomized, but K_3 and IV_3 are the same, leading to
     a key and nonce reuse.

     The EDHOC implementation MUST NOT store previous protocol state and
     regenerate an EDHOC message if there is a risk that the same key and
     IV are used for two (or more) distinct messages.

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

  8.  Compliance Requirements

     In the absence of an application profile specifying otherwise:

     An implementation MAY support only Initiator or only Responder.

     An implementation MAY support only a single method.  None of the
     methods are mandatory-to-implement.

     Implementations MUST support 'kid' parameters.  None of the other
     COSE header parameters are mandatory-to-implement.

     An implementation MAY support only a single credential type (CCS,
     CWT, X.509, C509).  None of the credential types are mandatory-to-
     implement.

     Implementations MUST support the EDHOC_Exporter.

     Implementations MAY support message_4.  Error codes (ERR_CODE) 1 and
     2 MUST be supported.

     Implementations MUST support EAD.

     Implementations MUST support cipher suite 2 and 3.  Cipher suites 2
     (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-
     256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-
     16-64-128, SHA-256) only differ in the size of the MAC length, so
     supporting one or both of these is not significantly different.
     Implementations only need to implement the algorithms needed for
     their supported methods.

  9.  Security Considerations




  Selander, et al.          Expires 25 July 2024                 [Page 47]


  Internet-Draft                    EDHOC                     January 2024


  9.1.  Security Properties

     EDHOC has similar security properties as can be expected from the
     theoretical SIGMA-I protocol [SIGMA] and the Noise XX pattern
     [Noise], which are similar to methods 0 and 3, respectively.  Proven
     security properties are detailed in the security analysis
     publications referenced at the end of this section.

     Using the terminology from [SIGMA], EDHOC provides forward secrecy,
     mutual authentication with aliveness, consistency, and peer
     awareness.  As described in [SIGMA], message_3 provides peer
     awareness to the Responder while message_4 provides peer awareness to
     the Initiator.  By including the authentication credentials in the
     transcript hash, EDHOC protects against Duplicate Signature Key
     Selection (DSKS)-like identity mis-binding attack that the MAC-then-
     Sign variant of SIGMA-I is otherwise vulnerable to.

     As described in [SIGMA], different levels of identity protection are
     provided to the Initiator and the Responder.  EDHOC provides identity
     protection of the Initiator against active attacks and identity
     protection of the Responder against passive attacks.  An active
     attacker can get the credential identifier of the Responder by
     eavesdropping on the destination address used for transporting
     message_1 and then sending its own message_1 to the same address.
     The roles should be assigned to protect the most sensitive identity/
     identifier, typically that which is not possible to infer from
     routing information in the lower layers.

     EDHOC messages might change in transit due to a noisy channel or
     through modification by an attacker.  Changes in message_1 and
     message_2 (except Signature_or_MAC_2 when the signature scheme is not
     strongly unforgeable) are detected when verifying Signature_or_MAC_2.
     Changes to not strongly unforgeable Signature_or_MAC_2, and message_3
     are detected when verifying CIPHERTEXT_3.  Changes to message_4 are
     detected when verifying CIPHERTEXT_4.

     Compared to [SIGMA], EDHOC adds an explicit method type and expands
     the message authentication coverage to additional elements such as
     algorithms, external authorization data, and previous plaintext
     messages.  This protects against an attacker replaying messages or
     injecting messages from another EDHOC session.










  Selander, et al.          Expires 25 July 2024                 [Page 48]


  Internet-Draft                    EDHOC                     January 2024


     EDHOC also adds selection of connection identifiers and downgrade
     protected negotiation of cryptographic parameters, i.e., an attacker
     cannot affect the negotiated parameters.  A single session of EDHOC
     does not include negotiation of cipher suites, but it enables the
     Responder to verify that the selected cipher suite is the most
     preferred cipher suite by the Initiator which is supported by both
     the Initiator and the Responder, and to abort the EDHOC session if
     not.

     As required by [RFC7258], IETF protocols need to mitigate pervasive
     monitoring when possible.  EDHOC therefore only supports methods with
     ephemeral Diffie-Hellman and provides a key update function (see
     Appendix H) for lightweight application protocol rekeying.  Either of
     these provides forward secrecy, in the sense that compromise of the
     private authentication keys does not compromise past session keys
     (PRK_out), and compromise of a session key does not compromise past
     session keys.  Frequently re-running EDHOC with ephemeral Diffie-
     Hellman forces attackers to perform dynamic key exfiltration where
     the attacker must have continuous interactions with the collaborator,
     which is a significant sustained attack.

     To limit the effect of breaches, it is important to limit the use of
     symmetric group keys for bootstrapping.  EDHOC therefore strives to
     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 replacement for a public key infrastructure
     but SHOULD be used instead of symmetric group keys for bootstrapping.

     Compromise of the long-term keys (private signature or static DH
     keys) does not compromise the security of completed EDHOC sessions.
     Compromising the private authentication keys of one party lets an
     active attacker impersonate that compromised party in EDHOC sessions
     with other parties but does not let the attacker impersonate other
     parties in EDHOC sessions with the compromised party.  Compromise of
     the long-term keys does not enable a passive attacker to compromise
     future session keys (PRK_out).  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 session keys.  Compromise of
     PRK_out leads to compromise of all keying material derived with the
     EDHOC_Exporter.

     Based on the cryptographic algorithms requirements Section 9.3, 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.  To break 64-bit security against online brute force an
     attacker would on average have to send 4.3 billion messages per
     second for 68 years, which is infeasible in constrained IoT radio



  Selander, et al.          Expires 25 July 2024                 [Page 49]


  Internet-Draft                    EDHOC                     January 2024


     technologies.  A forgery against a 64-bit MAC in EDHOC breaks the
     security of all future application data, while a forgery against a
     64-bit MAC in the subsequent application protocol (e.g., OSCORE
     [RFC8613]) typically only breaks the security of the data in the
     forged packet.

     As the EDHOC session is aborted when verification fails, the security
     against online attacks is given by the sum of the strength of the
     verified signatures and MACs (including MAC in AEAD).  As an example,
     if EDHOC is used with method 3, cipher suite 2, and message_4, the
     Responder is authenticated with 128-bit security against online
     attacks (the sum of the 64-bit MACs in message_2 and message_4).  The
     same principle applies for MACs in an application protocol keyed by
     EDHOC as long as EDHOC is rerun when verification of the first MACs
     in the application protocol fails.  As an example, if EDHOC with
     method 3 and cipher suite 2 is used as in Figure 2 of
     [I-D.ietf-core-oscore-edhoc], 128-bit mutual authentication against
     online attacks can be achieved after completion of the first OSCORE
     request and response.

     After sending message_3, the Initiator is assured that no other party
     than the Responder can compute the key PRK_out.  While the Initiator
     can securely send protected application data, the Initiator SHOULD
     NOT persistently store the keying material PRK_out until the
     Initiator has verified message_4 or a message protected with a
     derived application key, such as an OSCORE message, from the
     Responder.  After verifying message_3, the Responder is assured that
     an honest Initiator has computed the key PRK_out.  The Responder can
     securely derive and store the keying material PRK_out, and send
     protected application data.

     External authorization data sent in message_1 (EAD_1) or message_2
     (EAD_2) should be considered unprotected by EDHOC, see Section 9.5.
     EAD_2 is encrypted but the Responder has not yet authenticated the
     Initiator and the encryption does not provide confidentiality against
     active attacks.

     External authorization data sent in message_3 (EAD_3) or message_4
     (EAD_4) is protected between Initiator and Responder by the protocol,
     but note that EAD fields may be used by the application before the
     message verification is completed, see Section 3.8.  Designing a
     secure mechanism that uses EAD is not necessarily straightforward.
     This document only provides the EAD transport mechanism, but the
     problem of agreeing on the surrounding context and the meaning of the
     information passed to and from the application remains.  Any new uses
     of EAD should be subject to careful review.





  Selander, et al.          Expires 25 July 2024                 [Page 50]


  Internet-Draft                    EDHOC                     January 2024


     Key compromise impersonation (KCI): In EDHOC authenticated with
     signature keys, EDHOC provides KCI protection against an attacker
     having access to the long-term key or the ephemeral secret key.  With
     static Diffie-Hellman key authentication, KCI protection would be
     provided against an attacker having access to the long-term Diffie-
     Hellman key, but not to an attacker having access to the ephemeral
     secret key.  Note that the term KCI has typically been used for
     compromise of long-term keys, and that an attacker with access to the
     ephemeral secret key can only attack that specific EDHOC session.

     Repudiation: If an endpoint authenticates with a signature, the other
     endpoint can prove that the endpoint performed a run of the protocol
     by presenting the data being signed as well as the signature itself.
     With static Diffie-Hellman key authentication, the authenticating
     endpoint can deny having participated in the protocol.

     Earlier versions of EDHOC have been formally analyzed [Bruni18]
     [Norrman20] [CottierPointcheval22] [Jacomme23] [GuentherIlunga22] and
     the specification has been updated based on the analysis.

  9.2.  Cryptographic Considerations

     The SIGMA protocol requires that the encryption of message_3 provides
     confidentiality against active attackers and EDHOC message_4 relies
     on the use of authenticated encryption.  Hence, the message
     authenticating functionality of the authenticated encryption in EDHOC
     is critical: authenticated encryption MUST NOT be replaced by plain
     encryption only, even if authentication is provided at another level
     or through a different mechanism.

     To reduce message overhead EDHOC does not use explicit nonces and
     instead relies on the ephemeral public keys to provide randomness to
     each EDHOC session.  A good amount of randomness is important for the
     key generation, to provide liveness, and to protect against
     interleaving attacks.  For this reason, the ephemeral keys MUST NOT
     be used in more than one EDHOC message, and both parties SHALL
     generate fresh random ephemeral key pairs.  Note that an ephemeral
     key may be used to calculate several ECDH shared secrets.  When
     static Diffie-Hellman authentication is used the same ephemeral key
     is used in both ephemeral-ephemeral and ephemeral-static ECDH.

     As discussed in [SIGMA], the encryption of message_2 does only need
     to protect against passive attacker as active attackers can always
     get the Responder's identity by sending their own message_1.  EDHOC
     uses the EDHOC_Expand function (typically HKDF-Expand) as a binary
     additive stream cipher which is proven secure as long as the expand
     function is a PRF.  HKDF-Expand is not often used as a stream cipher
     as it is slow on long messages, and most applications require both



  Selander, et al.          Expires 25 July 2024                 [Page 51]


  Internet-Draft                    EDHOC                     January 2024


     confidentiality with indistinguishability under chosen ciphertext
     (IND-CCA) as well as integrity protection.  For the encryption of
     message_2, any speed difference is negligible, IND-CCA does not
     increase security, and integrity is provided by the inner MAC (and
     signature depending on method).

     Requirements for how to securely generate, validate, and process the
     public keys depend on the elliptic curve.  For X25519 and X448, the
     requirements are defined in [RFC7748].  For X25519 and X448, the
     check for all-zero output as specified in Section 6 of [RFC7748] MUST
     be done.  For secp256r1, secp384r1, and secp521r1, the requirements
     are defined in Section 5 of [SP-800-56A].  For secp256r1, secp384r1,
     and secp521r1, at least partial public-key validation MUST be done.

     The same authentication credential MAY be used for both the Initiator
     and Responder roles.  As noted in Section 12 of [RFC9052] the use of
     a single key for multiple algorithms is strongly discouraged unless
     proven secure by a dedicated cryptographic analysis.  In particular
     this recommendation applies to using the same private key for static
     Diffie-Hellman authentication and digital signature authentication.
     A preliminary conjecture is that a minor change to EDHOC may be
     sufficient to fit the analysis of secure shared signature and ECDH
     key usage in [Degabriele11] and [Thormarker21].

     The property that a completed EDHOC session implies that another
     identity has been active is upheld as long as the Initiator does not
     have its own identity in the set of Responder identities it is
     allowed to communicate with.  In Trust on first use (TOFU) use cases,
     see Appendix D.5, the Initiator should verify that the Responder's
     identity is not equal to its own.  Any future EDHOC methods using
     e.g., pre-shared keys might need to mitigate this in other ways.
     However, an active attacker can gain information about the set of
     identities an Initiator is willing to communicate with.  If the
     Initiator is willing to communicate with all identities except its
     own an attacker can determine that a guessed Initiator identity is
     correct.  To not leak any long-term identifiers, using a freshly
     generated authentication key as identity in each initial TOFU session
     is RECOMMENDED.













  Selander, et al.          Expires 25 July 2024                 [Page 52]


  Internet-Draft                    EDHOC                     January 2024


     NIST SP 800-56A [SP-800-56A] forbids deriving secret and non-secret
     randomness from the same KDF instance, but this decision has been
     criticized by Krawczyk [HKDFpaper] and doing so is common practice.
     In addition to IVs, other examples are the challenge in EAP-TTLS, the
     RAND in 3GPP AKAs, and the Session-Id in EAP-TLS 1.3.  Note that part
     of KEYSTREAM_2 is also non-secret randomness as it is known or
     predictable to an attacker.  The more recent NIST SP 800-108
     [SP-800-108] aligns with [HKDFpaper] and states that for a secure
     KDF, the revelation of one portion of the derived keying material
     must not degrade the security of any other portion of that keying
     material.

  9.3.  Cipher Suites and Cryptographic Algorithms

     When using private cipher suite or registering new cipher suites, the
     choice of key length used in the different algorithms needs to be
     harmonized, so that a sufficient security level is maintained for
     authentication credentials, the EDHOC session, and the protection of
     application data.  The Initiator and the Responder should enforce a
     minimum security level.

     The output size of the EDHOC hash algorithm MUST be at least
     256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
     truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
     for certificate identification with x5t and c5t.  For security
     considerations of SHA-1, see [RFC6194].  As EDHOC integrity protects
     the whole authentication credentials, the choice of hash algorithm in
     x5t and c5t does not affect security, and using the same hash
     algorithm as in the cipher suite, but with as much truncation as
     possible, is RECOMMENDED.  That is, when the EDHOC hash algorithm is
     SHA-256, using SHA-256/64 in x5t and c5t is RECOMMENDED.  The EDHOC
     MAC length MUST be at least 8 bytes and the tag length of the EDHOC
     AEAD algorithm MUST be at least 64-bits.  Note that secp256k1 is only
     defined for use with ECDSA and not for ECDH.  Note that some COSE
     algorithms are marked as not recommended in the COSE IANA registry.

  9.4.  Post-Quantum Considerations

     As of the publication of this specification, it is unclear when or
     even if a quantum computer of sufficient size and power to exploit
     public key cryptography will exist.  Deployments that need to
     consider risks decades into the future should transition to Post-
     Quantum Cryptography (PQC) in the not-too-distant future.  Many other
     systems should take a slower wait-and-see approach where PQC is
     phased in when the quantum threat is more imminent.  Current PQC
     algorithms have limitations compared to Elliptic Curve Cryptography
     (ECC) and the data sizes would be problematic in many constrained IoT
     systems.



  Selander, et al.          Expires 25 July 2024                 [Page 53]


  Internet-Draft                    EDHOC                     January 2024


     Symmetric algorithms used in EDHOC such as SHA-256 and AES-CCM-
     16-64-128 are practically secure against even large quantum
     computers.  Two of NIST's security levels for quantum-resistant
     public-key cryptography are based on AES-128 and SHA-256.  Quantum
     computer will likely be expensive, slow due to heavy error
     correction, and Grover’s algorithm, which is proven to be optimal,
     cannot effectively be parallelized.  Grover’s algorithm will provide
     little or no advantage in attacking AES, and AES-128 will remain
     secure for decades to come [NISTPQC].

     EDHOC supports all signature algorithms defined by COSE, including
     PQC signature algorithms such as HSS-LMS.  EDHOC is currently only
     specified for use with key exchange algorithms of type ECDH curves,
     but any Key Encapsulation Method (KEM), including PQC KEMs, can be
     used in method 0.  While the key exchange in method 0 is specified
     with terms of the Diffie-Hellman protocol, the key exchange adheres
     to a KEM interface: G_X is then the public key of the Initiator, G_Y
     is the encapsulation, and G_XY is the shared secret.  Use of PQC KEMs
     to replace static DH authentication would likely require a
     specification updating EDHOC with new methods.

  9.5.  Unprotected Data and Privacy

     The Initiator and 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, it applies to EAD_1, ID_CRED_R, EAD_2, and error
     messages.  Using the same EAD_1 in several EDHOC sessions allows
     passive eavesdroppers to correlate the different sessions.  Note that
     even if ead_value is encrypted outside of EDHOC, the ead_labels in
     EAD_1 is revealed to passive attackers and the ead_labels in EAD_2 is
     revealed to active attackers.  Another consideration is that the list
     of supported cipher suites may potentially be used to identify the
     application.  The Initiator and the Responder must also make sure
     that unauthenticated data does not trigger any harmful actions.  In
     particular, this applies to EAD_1 and error messages.















  Selander, et al.          Expires 25 July 2024                 [Page 54]


  Internet-Draft                    EDHOC                     January 2024


     An attacker observing network traffic may use connection identifiers
     sent in clear in EDHOC or the subsequent application protocol to
     correlate packets sent on different paths or at different times.  The
     attacker may use this information for traffic flow analysis or to
     track an endpoint.  Application protocols using connection
     identifiers from EDHOC SHOULD provide mechanisms to update the
     connection identifiers and MAY provide mechanisms to issue several
     simultaneously active connection identifiers.  See [RFC9000] for a
     non-constrained example of such mechanisms.  Connection identifiers
     can e.g., be chosen randomly among the set of unused 1-byte
     connection identifiers.  Connection identity privacy mechanisms are
     only useful when there are not fixed identifiers such as IP address
     or MAC address in the lower layers.

  9.6.  Updated Internet Threat Model Considerations

     Since the publication of [RFC3552] there has been an increased
     awareness of the need to protect against endpoints that are
     compromised, malicious, or whose interests simply do not align with
     the interests of users
     [I-D.arkko-arch-internet-threat-model-guidance].  [RFC7624] describes
     an updated threat model for Internet confidentiality, see
     Section 9.1.  [I-D.arkko-arch-internet-threat-model-guidance] further
     expands the threat model.  Implementations and users should take
     these threat models into account and consider actions to reduce the
     risk of tracking by other endpoints.  In particular, even data sent
     protected to the other endpoint such as ID_CRED fields and EAD fields
     can be used for tracking, see Section 2.7 of
     [I-D.arkko-arch-internet-threat-model-guidance].

     The fields ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 have
     variable length, and information regarding the length may leak to an
     attacker.  A passive attacker may, e.g., be able to differentiate
     endpoints using identifiers of different length.  To mitigate this
     information leakage an implementation may ensure that the fields have
     fixed length or use padding.  An implementation may, e.g., only use
     fixed length identifiers like 'kid' of length 1.  Alternatively,
     padding may be used (see Section 3.8.1) to hide the true length of,
     e.g., certificates by value in 'x5chain' or 'c5c'.

  9.7.  Denial-of-Service

     EDHOC itself does not provide countermeasures against denial-of-
     service attacks.  In particular, 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 make use of available
     lower layer mechanisms.  For instance, when EDHOC is transferred as



  Selander, et al.          Expires 25 July 2024                 [Page 55]


  Internet-Draft                    EDHOC                     January 2024


     an exchange of CoAP messages, the CoAP server can use the Echo option
     defined in [RFC9175] which forces the CoAP client to demonstrate
     reachability at its apparent network address.  To avoid an additional
     roundtrip the Initiator can reduce the amplification factor by
     padding message_1, i.e., using EAD_1, see Section 3.8.1.  Note that
     while the Echo option mitigates some resource exhaustion aspects of
     spoofing, it does not protect against a distributed denial-of-service
     attack made by real, potentially compromised, clients.  Similarly,
     limiting amplification only reduces the impact, which still may be
     significant because of a large number of clients engaged in the
     attack.

     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 abort the EDHOC session.  EDHOC implementations MAY
     evaluate if a received message is likely to have been forged by an
     attacker and ignore it without sending an error message or aborting
     the EDHOC session.

  9.8.  Implementation Considerations

     The availability of a secure random number generator is essential for
     the security of EDHOC.  If no true random number generator is
     available, a random seed MUST be provided from an external source and
     used with a cryptographically secure pseudorandom number generator.
     As each pseudorandom number must only be used once, an implementation
     needs to get a unique input to the pseudorandom number generator
     after reboot, or continuously store state in nonvolatile memory.
     Appendix B.1.1 in [RFC8613] describes issues and solution approaches
     for writing 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 to augment their (pseudo)random
     number generators using a long-term private key and a deterministic
     signature function.  This improves randomness from broken or
     otherwise subverted random number generators.  The 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
     RECOMMENDED to not trust a single source of randomness and to not put
     unaugmented random numbers on the wire.

     For many constrained IoT devices it is problematic to support several
     crypto primitives.  Existing devices can be expected to support
     either ECDSA or EdDSA.  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 of high-quality randomness.  Recent research has however found



  Selander, et al.          Expires 25 July 2024                 [Page 56]


  Internet-Draft                    EDHOC                     January 2024


     that implementations of these signature algorithms may be vulnerable
     to certain side-channel and fault injection attacks due to their
     determinism.  See e.g., Section 1 of
     [I-D.irtf-cfrg-det-sigs-with-noise] for a list of attack papers.  As
     suggested in Section 2.1.1 of [RFC9053] this can be addressed by
     combining randomness and determinism.

     Appendix D of [I-D.ietf-lwig-curve-representations] describes how
     Montgomery curves such as X25519 and X448 and (twisted) Edwards
     curves as curves such as Ed25519 and Ed448 can be mapped to and from
     short-Weierstrass form for implementation on platforms that
     accelerate elliptic curve group operations in short-Weierstrass form.

     All private keys, symmetric keys, and IVs MUST be secret.  Only the
     Responder SHALL have access to the Responder's private authentication
     key and only the Initiator SHALL have access to the Initiator's
     private authentication key.  Implementations should provide
     countermeasures to side-channel attacks such as timing attacks.
     Intermediate computed values such as ephemeral ECDH keys and ECDH
     shared secrets MUST be deleted after key derivation is completed.

     The Initiator and the Responder are responsible for verifying the
     integrity and validity of certificates.  Verification of validity may
     require the use of a Real-Time Clock (RTC).  The selection of trusted
     CAs should be done very carefully and certificate revocation should
     be supported.  The choice of revocation mechanism is left to the
     application.  For example, in case of X.509 certificates, Certificate
     Revocation Lists [RFC5280] or OCSP [RFC6960] may be used.

     Similar considerations as for certificates are needed for CWT/CCS.
     The endpoints are responsible for verifying the integrity and
     validity of CWT/CCS, and to handle revocation.  The application needs
     to determine what trust anchors are relevant, and have a well-defined
     trust-establishment process.  A self-signed certificate/CWT or CCS
     appearing in the protocol cannot be a trigger to modify the set of
     trust anchors.  One common way for a new trust anchor to be added to
     (or removed from) a device is by means firmware upgrade.  See
     [RFC9360] for a longer discussion on trust and validation in
     constrained devices.












  Selander, et al.          Expires 25 July 2024                 [Page 57]


  Internet-Draft                    EDHOC                     January 2024


     Just like for certificates, the contents of the COSE header
     parameters 'kcwt' and 'kccs' defined in Section 10.6 must be
     processed as untrusted input.  Endpoints that intend to rely on the
     assertions made by a CWT/CCS obtained from any of these methods need
     to validate the contents.  For 'kccs', which enables transport of raw
     public keys, the data structure used does not include any protection
     or verification data. 'kccs' may be used for unauthenticated
     operations, e.g. trust on first use, with the limitations and caveats
     entailed, see Appendix D.5.

     The Initiator and the Responder are allowed to select the connection
     identifier C_I and C_R, respectively, for the other party to use in
     the ongoing EDHOC session as well as in a subsequent application
     protocol (e.g., OSCORE [RFC8613]).  The choice of connection
     identifier is not security critical in EDHOC but intended to simplify
     the retrieval of the right security context in combination with using
     short identifiers.  If the wrong connection identifier of the other
     party is used in a protocol message it will result in the receiving
     party not being able to retrieve a security context (which will abort
     the EDHOC session) or retrieve the wrong security context (which also
     aborts the EDHOC session as the message cannot be verified).

     If two nodes unintentionally initiate two simultaneous EDHOC sessions
     with each other even if they only want to complete a single EDHOC
     session, they MAY abort the EDHOC session with the lexicographically
     smallest G_X.  Note that in cases where several EDHOC sessions with
     different parameter sets (method, COSE headers, etc.) are used, an
     attacker can affect which parameter set will be used by blocking some
     of the parameter sets.

     If supported by the device, it is RECOMMENDED that at least the long-
     term private keys are stored in a Trusted Execution Environment (TEE,
     see for example [RFC9397]) and that sensitive operations using these
     keys are performed inside the TEE.  To achieve even higher security
     it is RECOMMENDED that additional operations such as ephemeral key
     generation, all computations of shared secrets, and storage of the
     PRK keys can be done inside the TEE.  The use of a TEE aims at
     preventing code within that environment to be tampered with, and
     preventing data used by such code to be read or tampered with by code
     outside that environment.











  Selander, et al.          Expires 25 July 2024                 [Page 58]


  Internet-Draft                    EDHOC                     January 2024


     Note that HKDF-Expand has a relatively small maximum output length of
     255 ⋅ hash_length, where hash_length is the output size in bytes of
     the EDHOC hash algorithm of the selected cipher suite.  This means
     that when SHA-256 is used as hash algorithm, PLAINTEXT_2 cannot be
     longer than 8160 bytes.  This is probably not a limitation for most
     intended applications, but to be able to support for example long
     certificate chains or large external authorization data, there is a
     backwards compatible method specified in Appendix G.

     The sequence of transcript hashes in EDHOC (TH_2, TH_3, TH_4) does
     not make use of a so-called running hash.  This is a design choice as
     running hashes are often not supported on constrained platforms.

     When parsing a received EDHOC message, implementations MUST abort the
     EDHOC session if the message does not comply with the CDDL for that
     message.  Implementations are not required to support non-
     deterministic encodings and MAY abort the EDHOC session if the
     received EDHOC message is not encoded using deterministic CBOR.
     Implementations MUST abort the EDHOC session if validation of a
     received public key fails or if any cryptographic field has the wrong
     length.

  10.  IANA Considerations

     This Section gives IANA Considerations and, unless otherwise noted,
     conforms with [RFC8126].

  10.1.  EDHOC Exporter Label Registry

     IANA is requested to create a new registry under the new registry
     group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:

     Registry Name: EDHOC Exporter Label

     Reference: [[this document]]
















  Selander, et al.          Expires 25 July 2024                 [Page 59]


  Internet-Draft                    EDHOC                     January 2024


     +-------------+------------------------------+-------------------+
     | Label       | Description                  | Reference         |
     +=============+==============================+===================+
     | 0           | Derived OSCORE Master Secret | [[this document]] |
     +-------------+------------------------------+-------------------+
     | 1           | Derived OSCORE Master Salt   | [[this document]] |
     +-------------+------------------------------+-------------------+
     | 2-22        | Unassigned                   |                   |
     +-------------+------------------------------+-------------------+
     | 23          | Reserved                     | [[this document]] |
     +-------------+------------------------------+-------------------+
     | 24-32767    | Unassigned                   |                   |
     +-------------+------------------------------+-------------------+
     | 32768-65535 | Private Use                  |                   |
     +-------------+------------------------------+-------------------+

                        Figure 13: EDHOC exporter label.

     +-------------+-------------------------------------+
     | Range       | Registration Procedures             |
     +=============+=====================================+
     | 0 to 23     | Standards Action                    |
     +-------------+-------------------------------------+
     | 24 to 32767 | Expert Review                       |
     +-------------+-------------------------------------+

  10.2.  EDHOC Cipher Suites Registry

     IANA is requested to create a new registry under the new registry
     group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:

     Registry Name: EDHOC Cipher Suites

     Reference: [[this document]]

     The columns of the registry are Value, Array and Description, where
     Value is an integer and the other columns are text strings.  The
     initial contents of the registry are:

     Value: -24
     Array: N/A
     Description: Private Use
     Reference: [[this document]]

     Value: -23
     Array: N/A
     Description: Private Use
     Reference: [[this document]]



  Selander, et al.          Expires 25 July 2024                 [Page 60]


  Internet-Draft                    EDHOC                     January 2024


     Value: -22
     Array: N/A
     Description: Private Use
     Reference: [[this document]]

     Value: -21
     Array: N/A
     Description: Private Use
     Reference: [[this document]]

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

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

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

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

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

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






  Selander, et al.          Expires 25 July 2024                 [Page 61]


  Internet-Draft                    EDHOC                     January 2024


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

     Value: 23
     Reserved
     Reference: [[this document]]

     Value: 24
     Array: 3, -43, 16, 2, -35, 3, -43
     Description: A256GCM, SHA-384, 16, P-384, ES384,
           A256GCM, SHA-384
     Reference: [[this document]]

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

     +----------------+-------------------------------------+
     | Range          | Registration Procedures             |
     +================+=====================================+
     | -65536 to -25  | Specification Required              |
     +----------------+-------------------------------------+
     | -20 to 23      | Standards Action with Expert Review |
     +----------------+-------------------------------------+
     | 24 to 65535    | Specification Required              |
     +----------------+-------------------------------------+

  10.3.  EDHOC Method Type Registry

     IANA is requested to create a new registry under the new registry
     group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:

     Registry Name: EDHOC Method Type

     Reference: [[this document]]

     The columns of the registry are Value, Initiator Authentication Key,
     and Responder Authentication Key, and Reference, where Value is an
     integer and the key columns are text strings describing the
     authentication keys.

     The initial contents of the registry are shown in Figure 4.  Method
     23 is Reserved.



  Selander, et al.          Expires 25 July 2024                 [Page 62]


  Internet-Draft                    EDHOC                     January 2024


     +----------------+-------------------------------------+
     | Range          | Registration Procedures             |
     +================+=====================================+
     | -65536 to -25  | Specification Required              |
     +----------------+-------------------------------------+
     | -24 to 23      | Standards Action with Expert Review |
     +----------------+-------------------------------------+
     | 24 to 65535    | Specification Required              |
     +----------------+-------------------------------------+

  10.4.  EDHOC Error Codes Registry

     IANA is requested to create a new registry under the new registry
     group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:

     Registry Name: EDHOC Error Codes

     Reference: [[this document]]

     The columns of the registry are ERR_CODE, ERR_INFO Type, Description,
     and Reference, 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 are shown in Figure 10.  Error code 23 is Reserved.

     +----------------+-------------------------------------+
     | Range          | Registration Procedures             |
     +================+=====================================+
     | -65536 to -25  | Expert Review                       |
     +----------------+-------------------------------------+
     | -24 to 23      | Standards Action                    |
     +----------------+-------------------------------------+
     | 24 to 65535    | Expert Review                       |
     +----------------+-------------------------------------+

  10.5.  EDHOC External Authorization Data Registry

     IANA is requested to create a new registry under the new registry
     group "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:

     Registry Name: EDHOC External Authorization Data

     Reference: [[this document]]

     The columns of the registry are Name, Label, Description, and
     Reference, where Label is a non-negative integer and the other
     columns are text strings.  The initial contents of the registry is
     shown in Figure 14.  EAD label 23 is Reserved.




  Selander, et al.          Expires 25 July 2024                 [Page 63]


  Internet-Draft                    EDHOC                     January 2024


     +-----------+-------+------------------------+-------------------+
     | Name      | Label | Description            | Reference         |
     +===========+=======+========================+===================+
     | Padding   |   0   | Randomly generated     | [[this document]] |
     |           |       | CBOR byte string       | Section 3.8.1     |
     +-----------+-------+------------------------+-------------------+

                             Figure 14: EAD labels.

     +-------------+-------------------------------------+
     | Range       | Registration Procedures             |
     +=============+=====================================+
     | 0 to 23     | Standards Action with Expert Review |
     +-------------+-------------------------------------+
     | 24 to 65535 | Specification Required              |
     +-------------+-------------------------------------+

  10.6.  COSE Header Parameters Registry

     IANA is requested to register the following entries in the "COSE
     Header Parameters" registry under the registry group "CBOR Object
     Signing and Encryption (COSE)" (see Figure 15): The value of the
     'kcwt' header parameter is a COSE Web Token (CWT) [RFC8392], and the
     value of the 'kccs' header parameter is a CWT Claims Set (CCS), see
     Section 1.4.  The CWT/CCS must contain a COSE_Key in a 'cnf' claim
     [RFC8747].  The Value Registry for this item is empty and omitted
     from the table below.

     +------+-------+---------------+------------------------------------+
     | Name | Label | Value Type    | Description                        |
     +======+=======+===============+====================================+
     | kcwt | TBD1  | COSE_Messages | A CBOR Web Token (CWT) containing  |
     |      |       |               | a COSE_Key in a 'cnf' claim and    |
     |      |       |               | possibly other claims. CWT is      |
     |      |       |               | defined in RFC 8392. COSE_Messages |
     |      |       |               | is defined in RFC 9052.            |
     +------+-------+---------------+------------------------------------+
     | kccs | TBD2  | map           | A CWT Claims Set (CCS) containing  |
     |      |       |               | a COSE_Key in a 'cnf' claim and    |
     |      |       |               | possibly other claims. CCS is      |
     |      |       |               | defined in RFC 8392.               |
     +------+-------+---------------+------------------------------------+

                    Figure 15: COSE header parameter labels.







  Selander, et al.          Expires 25 July 2024                 [Page 64]


  Internet-Draft                    EDHOC                     January 2024


  10.7.  The Well-Known URI Registry

     IANA is requested to add the well-known URI "edhoc" to the "Well-
     Known URIs" registry.

     *  URI suffix: edhoc

     *  Change controller: IETF

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

     *  Related information: None

  10.8.  Media Types Registry

     IANA is requested to add the media types "application/edhoc+cbor-seq"
     and "application/cid-edhoc+cbor-seq" to the "Media Types" registry.

  10.8.1.  application/edhoc+cbor-seq Media Type Registration

     *  Type name: application

     *  Subtype name: edhoc+cbor-seq

     *  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




  Selander, et al.          Expires 25 July 2024                 [Page 65]


  Internet-Draft                    EDHOC                     January 2024


     *  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

  10.8.2.  application/cid-edhoc+cbor-seq Media Type Registration

     *  Type name: application

     *  Subtype name: cid-edhoc+cbor-seq

     *  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




  Selander, et al.          Expires 25 July 2024                 [Page 66]


  Internet-Draft                    EDHOC                     January 2024


     *  Author: See "Authors' Addresses" section.

     *  Change Controller: IESG

  10.9.  CoAP Content-Formats Registry

     IANA is requested to add the media types "application/edhoc+cbor-seq"
     and "application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats"
     registry under the registry group "Constrained RESTful Environments
     (CoRE) Parameters".

  +--------------------------------+----------+------+-------------------+
  | Media Type                     | Encoding | ID   | Reference         |
  +================================+==========+======+===================+
  | application/edhoc+cbor-seq     | -        | TBD5 | [[this document]] |
  | application/cid-edhoc+cbor-seq | -        | TBD6 | [[this document]] |
  +--------------------------------+----------+------+-------------------+

                    Figure 16: CoAP Content-Format IDs

  10.10.  Resource Type (rt=) Link Target Attribute Values Registry

     IANA is requested to add the resource type "core.edhoc" to the
     "Resource Type (rt=) Link Target Attribute Values" registry under the
     registry group "Constrained RESTful Environments (CoRE) Parameters".

     *  Value: "core.edhoc"

     *  Description: EDHOC resource.

     *  Reference: [[this document]]

  10.11.  Expert Review Instructions

     The IANA Registries established in this document are defined as
     "Expert Review", "Specification Required" or "Standards Action with
     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:










  Selander, et al.          Expires 25 July 2024                 [Page 67]


  Internet-Draft                    EDHOC                     January 2024


     *  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 is required.  Experts 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.

     *  Experts should take into account the expected usage of fields when
        approving code 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.

     *  Even for "Expert Review" specifications are recommended.  When
        specifications are not provided for a request where Expert Review
        is the assignment policy, the description provided needs to have
        sufficient information to verify the code points above.

  11.  References

  11.1.  Normative References

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

     [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
                Identifiers for the Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
                2002, <https://www.rfc-editor.org/info/rfc3279>.

     [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
                Text on Security Considerations", BCP 72, RFC 3552,
                DOI 10.17487/RFC3552, July 2003,
                <https://www.rfc-editor.org/info/rfc3552>.

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



  Selander, et al.          Expires 25 July 2024                 [Page 68]


  Internet-Draft                    EDHOC                     January 2024


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

     [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
                Galperin, S., and C. Adams, "X.509 Internet Public Key
                Infrastructure Online Certificate Status Protocol - OCSP",
                RFC 6960, DOI 10.17487/RFC6960, June 2013,
                <https://www.rfc-editor.org/info/rfc6960>.

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

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/info/rfc8126>.

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

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

     [RFC8410]  Josefsson, S. and J. Schaad, "Algorithm Identifiers for
                Ed25519, Ed448, X25519, and X448 for Use in the Internet
                X.509 Public Key Infrastructure", RFC 8410,
                DOI 10.17487/RFC8410, August 2018,
                <https://www.rfc-editor.org/info/rfc8410>.



  Selander, et al.          Expires 25 July 2024                 [Page 69]


  Internet-Draft                    EDHOC                     January 2024


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

     [RFC8747]  Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
                Tschofenig, "Proof-of-Possession Key Semantics for CBOR
                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>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/info/rfc9052>.

     [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
                August 2022, <https://www.rfc-editor.org/info/rfc9053>.

     [RFC9175]  Amsüss, C., Preuß Mattsson, J., and G. Selander,
                "Constrained Application Protocol (CoAP): Echo, Request-
                Tag, and Token Processing", RFC 9175,
                DOI 10.17487/RFC9175, February 2022,
                <https://www.rfc-editor.org/info/rfc9175>.






  Selander, et al.          Expires 25 July 2024                 [Page 70]


  Internet-Draft                    EDHOC                     January 2024


     [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Header Parameters for Carrying and Referencing X.509
                Certificates", RFC 9360, DOI 10.17487/RFC9360, February
                2023, <https://www.rfc-editor.org/info/rfc9360>.

  11.2.  Informative References

     [Bruni18]  Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and
                C. Schürmann, "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,
                <https://cbor.me/>.

     [CNSA]     NSA, "Commercial National Security Algorithm Suite",
                August 2015, <https://en.wikipedia.org/wiki/
                Commercial_National_Security_Algorithm_Suite>.

     [CottierPointcheval22]
                Cottier, B. and D. Pointcheval, "Security Analysis of the
                EDHOC protocol", September 2022,
                <https://arxiv.org/abs/2209.03599>.

     [Degabriele11]
                Degabriele, J. P., Lehmann, A., Paterson, K. G., Smart, N.
                P., and M. Strefler, "On the Joint Security of Encryption
                and Signature in EMV", December 2011,
                <https://eprint.iacr.org/2011/615>.

     [GuentherIlunga22]
                Günther, F. and M. Ilunga, "Careful with MAc-then-SIGn: A
                Computational Analysis of the EDHOC Lightweight
                Authenticated Key Exchange Protocol", December 2022,
                <https://eprint.iacr.org/2022/1705>.

     [HKDFpaper]
                Krawczyk, H., "Cryptographic Extraction and Key
                Derivation: The HKDF Scheme", May 2010,
                <https://eprint.iacr.org/2010/264.pdf>.









  Selander, et al.          Expires 25 July 2024                 [Page 71]


  Internet-Draft                    EDHOC                     January 2024


     [I-D.arkko-arch-internet-threat-model-guidance]
                Arkko, J. and S. Farrell, "Internet Threat Model
                Guidance", Work in Progress, Internet-Draft, draft-arkko-
                arch-internet-threat-model-guidance-00, 12 July 2021,
                <https://datatracker.ietf.org/doc/html/draft-arkko-arch-
                internet-threat-model-guidance-00>.

     [I-D.ietf-core-oscore-edhoc]
                Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
                G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
                (EDHOC) with the Constrained Application Protocol (CoAP)
                and Object Security for Constrained RESTful Environments
                (OSCORE)", Work in Progress, Internet-Draft, draft-ietf-
                core-oscore-edhoc-10, 29 November 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-core-
                oscore-edhoc-10>.

     [I-D.ietf-core-oscore-key-update]
                Höglund, R. and M. Tiloca, "Key Update for OSCORE
                (KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
                core-oscore-key-update-06, 23 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-core-
                oscore-key-update-06>.

     [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-07, 20 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                cbor-encoded-cert-07>.

     [I-D.ietf-iotops-security-protocol-comparison]
                Mattsson, J. P., Palombini, F., and M. Vučinić,
                "Comparison of CoAP Security Protocols", Work in Progress,
                Internet-Draft, draft-ietf-iotops-security-protocol-
                comparison-03, 23 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-iotops-
                security-protocol-comparison-03>.

     [I-D.ietf-lake-reqs]
                Vučinić, M., Selander, G., Mattsson, J. P., and D. Garcia-
                Carillo, "Requirements for a Lightweight AKE for OSCORE",
                Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04,
                8 June 2020, <https://datatracker.ietf.org/doc/html/draft-
                ietf-lake-reqs-04>.





  Selander, et al.          Expires 25 July 2024                 [Page 72]


  Internet-Draft                    EDHOC                     January 2024


     [I-D.ietf-lake-traces]
                Selander, G., Mattsson, J. P., Serafin, M., Tiloca, M.,
                and M. Vučinić, "Traces of EDHOC", Work in Progress,
                Internet-Draft, draft-ietf-lake-traces-08, 22 September
                2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
                lake-traces-08>.

     [I-D.ietf-lwig-curve-representations]
                Struik, R., "Alternative Elliptic Curve Representations",
                Work in Progress, Internet-Draft, draft-ietf-lwig-curve-
                representations-23, 21 January 2022,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-
                curve-representations-23>.

     [I-D.ietf-rats-eat]
                Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", Work in
                Progress, Internet-Draft, draft-ietf-rats-eat-25, 15
                January 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-eat-25>.

     [I-D.irtf-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-irtf-
                cfrg-det-sigs-with-noise-00, 8 August 2022,
                <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
                det-sigs-with-noise-00>.

     [I-D.selander-lake-authz]
                Selander, G., Mattsson, J. P., Vučinić, M., Richardson,
                M., and A. Schellenbaum, "Lightweight Authorization using
                Ephemeral Diffie-Hellman Over COSE", Work in Progress,
                Internet-Draft, draft-selander-lake-authz-03, 7 July 2023,
                <https://datatracker.ietf.org/doc/html/draft-selander-
                lake-authz-03>.

     [Jacomme23]
                Jacomme, C., Klein, E., Kremer, S., and M. Racouchot, "A
                comprehensive, formal and automated analysis of the EDHOC
                protocol", October 2022,
                <https://hal.inria.fr/hal-03810102/>.

     [NISTPQC]  "Post-Quantum Cryptography FAQs", August 2023,
                <https://csrc.nist.gov/Projects/post-quantum-cryptography/
                faqs>.





  Selander, et al.          Expires 25 July 2024                 [Page 73]


  Internet-Draft                    EDHOC                     January 2024


     [Noise]    Perrin, T., "The Noise Protocol Framework, Revision 34",
                July 2018, <https://noiseprotocol.org/noise.html>.

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

     [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                DOI 10.17487/RFC2986, November 2000,
                <https://www.rfc-editor.org/info/rfc2986>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and 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>.

     [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
                Considerations for the SHA-0 and SHA-1 Message-Digest
                Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
                <https://www.rfc-editor.org/info/rfc6194>.

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

     [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
                Trammell, B., Huitema, C., and D. Borkmann,
                "Confidentiality in the 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>.






  Selander, et al.          Expires 25 July 2024                 [Page 74]


  Internet-Draft                    EDHOC                     January 2024


     [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
                "A Voucher Artifact for Bootstrapping Protocols",
                RFC 8366, DOI 10.17487/RFC8366, May 2018,
                <https://www.rfc-editor.org/info/rfc8366>.

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

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

     [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
                Multiplexed and Secure Transport", RFC 9000,
                DOI 10.17487/RFC9000, May 2021,
                <https://www.rfc-editor.org/info/rfc9000>.

     [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
                Datagram Transport Layer Security (DTLS) Protocol Version
                1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
                <https://www.rfc-editor.org/info/rfc9147>.

     [RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
                P. van der Stok, "Constrained RESTful Environments (CoRE)
                Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
                2022, <https://www.rfc-editor.org/info/rfc9176>.

     [RFC9397]  Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
                "Trusted Execution Environment Provisioning (TEEP)
                Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,
                <https://www.rfc-editor.org/info/rfc9397>.

     [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", June 2003,
                <https://www.iacr.org/cryptodb/archive/2003/
                CRYPTO/1495/1495.pdf>.





  Selander, et al.          Expires 25 July 2024                 [Page 75]


  Internet-Draft                    EDHOC                     January 2024


     [SP-800-108]
                Chen, L., "Recommendation for Key Derivation Using
                Pseudorandom Functions", NIST Special Publication 800-108
                Revision 1, August 2022,
                <https://doi.org/10.6028/NIST.SP.800-108r1>.

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

     [SP800-185]
                John Kelsey, Shu-jen Chang, and Ray Perlner, "SHA-3
                Derived Functions cSHAKE, KMAC, TupleHash and
                ParallelHash", NIST Special Publication 800-185, December
                2016, <https://doi.org/10.6028/NIST.SP.800-185>.

     [Thormarker21]
                Thormarker, E., "On using the same key pair for Ed25519
                and an X25519 based KEM", April 2021,
                <https://eprint.iacr.org/2021/509.pdf>.

  Appendix A.  Use with OSCORE and Transfer over CoAP

     This appendix describes how to derive an OSCORE security context when
     EDHOC is used to key OSCORE, and how to transfer EDHOC messages over
     CoAP.  The use of CoAP or OSCORE with EDHOC is optional, but if you
     are using CoAP or OSCORE, then certain normative requirements apply
     as detailed in the subsections.

  A.1.  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]):

     *  The Master Secret and Master Salt SHALL be derived by using the
        EDHOC_Exporter interface, see Section 4.2.1:

        -  The EDHOC Exporter Labels for deriving the OSCORE Master Secret
           and the OSCORE Master Salt, are the uints 0 and 1,
           respectively.




  Selander, et al.          Expires 25 July 2024                 [Page 76]


  Internet-Draft                    EDHOC                     January 2024


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

        -  By default, oscore_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, oscore_salt_length has
           value 8.  The Initiator and Responder MAY agree out-of-band on
           a longer oscore_key_length than the default, and on shorter or
           longer than the default oscore_salt_length.

        Master Secret = EDHOC_Exporter( 0, h'', oscore_key_length )
        Master Salt   = EDHOC_Exporter( 1, h'', oscore_salt_length )

     *  The AEAD Algorithm SHALL be the application AEAD algorithm of the
        selected cipher suite for the EDHOC session.

     *  The HKDF Algorithm SHALL be 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 cipher suite, HKDF SHA-256 is used as HKDF Algorithm in
        the OSCORE Security Context.

     *  The relationship between identifiers in OSCORE and EDHOC is
        specified in Section 3.3.3.  The OSCORE Sender ID and Recipient ID
        SHALL be determined by the EDHOC connection identifiers C_R and
        C_I for the EDHOC session as shown in Figure 17.

         +-----------------+------------------+---------------------+
         |                 | OSCORE Sender ID | OSCORE Recipient ID |
         +=================+==================+=====================+
         | EDHOC Initiator |        C_R       |         C_I         |
         +-----------------+------------------+---------------------+
         | EDHOC Responder |        C_I       |         C_R         |
         +-----------------+------------------+---------------------+

             Figure 17: Usage of connection identifiers in OSCORE.

     Client and Server SHALL 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.








  Selander, et al.          Expires 25 July 2024                 [Page 77]


  Internet-Draft                    EDHOC                     January 2024


  A.2.  Transferring EDHOC over CoAP

     This section specifies how EDHOC can be transferred as an exchange of
     CoAP [RFC7252] messages.  CoAP provides a reliable transport that can
     preserve packet ordering, provides flow and congestion control, and
     handles message duplication.  CoAP can also perform fragmentation and
     mitigate certain denial-of-service attacks.  The underlying CoAP
     transport should be used in reliable mode, in particular when
     fragmentation is used, to avoid, e.g., situations with hanging
     endpoints waiting for each other.

     EDHOC may run with the Initiator either being CoAP client or CoAP
     server.  We denote the former by the "forward message flow" (see
     Appendix A.2.1) and the latter by the "reverse message flow" (see
     Appendix A.2.2).  By default, we assume the forward message flow, but
     the roles SHOULD be chosen to protect the most sensitive identity,
     see Section 9.

     According to this specification, EDHOC is transferred in POST
     requests to the Uri-Path: "/.well-known/edhoc" (see Section 10.7),
     and 2.04 (Changed) responses.  An application may define its own path
     that can be discovered, e.g., using a resource directory [RFC9176].
     Client applications can use the resource type "core.edhoc" to
     discover a server's EDHOC resource, i.e., where to send a request for
     executing the EDHOC protocol, see Section 10.10.  An alternative
     transfer of the forward message flow is specified in
     [I-D.ietf-core-oscore-edhoc].

     In order for the server to correlate a message received from a client
     to a message previously sent in the same EDHOC session over CoAP,
     messages sent by the client SHALL be prepended with the CBOR
     serialization of the connection identifier which the server has
     selected, see Section 3.4.1.  This applies both to the forward and
     the reverse message flows.  To indicate a new EDHOC session in the
     forward message flow, message_1 SHALL be prepended with the CBOR
     simple value true (0xf5).  Even if CoAP is carried over a reliable
     transport protocol such as TCP, the prepending of identifiers
     specified here SHALL be practiced to enable interoperability
     independent of how CoAP is transported.

     The prepended identifiers are encoded in CBOR and thus self-
     delimiting.  The representation of identifiers described in
     Section 3.3.2 SHALL be used.  They are sent in front of the actual
     EDHOC message to keep track of messages in an EDHOC session, and only
     the part of the body following the identifier is used for EDHOC
     processing.  In particular, the connection identifiers within the
     EDHOC messages are not impacted by the prepended identifiers.




  Selander, et al.          Expires 25 July 2024                 [Page 78]


  Internet-Draft                    EDHOC                     January 2024


     An EDHOC message has media type application/edhoc+cbor-seq, whereas
     an EDHOC message prepended by a connection identifier has media type
     application/cid-edhoc+cbor-seq, see Section 10.9.

     To mitigate certain denial-of-service attacks, the CoAP server MAY
     respond to the first POST request with a 4.01 (Unauthorized)
     containing an Echo option [RFC9175].  This forces the Initiator to
     demonstrate 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 error messages need to be transported in response to a message
     that failed (see Section 6).  EDHOC error messages transported with
     CoAP are carried in the payload.

     Note that the transport over CoAP can serve as a blueprint for other
     client-server protocols:

     *  The client prepends the connection identifier selected by the
        server (or, for message_1, the CBOR simple value true) 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.

  A.2.1.  The Forward Message Flow

     In the forward message flow the CoAP client is the Initiator and the
     CoAP server is the Responder.  This flow protects the client identity
     against active attackers and the server identity against passive
     attackers.

     In the forward message flow, the CoAP Token enables correlation on
     the Initiator (client) side, and the prepended C_R enables
     correlation on the Responder (server) side.

     *  EDHOC message_1 is sent in the payload of a POST request from the
        client to the server's resource for EDHOC, prepended with the
        identifier true (0xf5) indicating a new EDHOC session.

     *  EDHOC message_2 or the EDHOC error message is sent from the server
        to the client in the payload of the response, in the former case
        with response code 2.04 (Changed), in the latter with response
        code as specified in Appendix A.2.3.

     *  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,
        prepended with the connection identifier C_R.



  Selander, et al.          Expires 25 July 2024                 [Page 79]


  Internet-Draft                    EDHOC                     January 2024


     *  If EDHOC message_4 is used, or in case of an error message, it is
        sent from the server to the client in the payload of the response,
        with response codes analogously to message_2.  In case of an error
        message sent in response to message_4, it is sent analogously to
        error message sent in response to message_2.

     An example of a completed EDHOC session over CoAP in the forward
     message flow is shown in Figure 18.

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

                Figure 18: Example of the forward message flow.

     The forward message flow of EDHOC can be combined with an OSCORE
     exchange in a total of two round-trips, see
     [I-D.ietf-core-oscore-edhoc].

  A.2.2.  The Reverse Message Flow

     In the reverse message flow the CoAP client is the Responder and the
     CoAP server is the Initiator.  This flow protects the server identity
     against active attackers and the client identity against passive
     attackers.

     In the reverse message flow, the CoAP Token enables correlation on
     the Responder (client) side, and the prepended C_I enables
     correlation on the Initiator (server) side.





  Selander, et al.          Expires 25 July 2024                 [Page 80]


  Internet-Draft                    EDHOC                     January 2024


     *  To trigger a new EDHOC session, the client makes an empty POST
        request to the server's resource for EDHOC.

     *  EDHOC message_1 is sent from the server to the client in the
        payload of the response with response code 2.04 (Changed).

     *  EDHOC message_2 or the EDHOC error message is sent from the client
        to the server's resource in the payload of a POST request,
        prepended with the connection identifier C_I.

     *  EDHOC message_3 or the EDHOC error message is sent from the server
        to the client in the payload of the response, in the former case
        with response code 2.04 (Changed), in the latter with response
        code as specified in Appendix A.2.3.

     *  If EDHOC message_4 is used, or in case of an error message, it is
        sent from the client to the server's resource in the payload of a
        POST request, prepended with the connection identifier C_I.  In
        case of an error message sent in response to message_4, it is sent
        analogously to an error message sent in response to message_2.

     An example of a completed EDHOC session over CoAP in the reverse
     message flow is shown in Figure 19.

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

                Figure 19: Example of the reverse message flow.







  Selander, et al.          Expires 25 July 2024                 [Page 81]


  Internet-Draft                    EDHOC                     January 2024


  A.2.3.  Errors in EDHOC over CoAP

     When using EDHOC over CoAP, 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
     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 keying material).  The
     Content-Format of the error response MUST be set to application/
     edhoc+cbor-seq, see Section 10.9.

  Appendix B.  Compact Representation

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

     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.

     In EDHOC, compact representation is used for the ephemeral public
     keys (G_X and G_Y), see Section 3.7.  Using the notation from [SECG],
     the output is an octet string of length ceil( (log2 q) / 8 ), where
     ceil(x) is the smallest integer not less than x.  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, see Section 9.2.  Using compact representation has 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].





  Selander, et al.          Expires 25 July 2024                 [Page 82]


  Internet-Draft                    EDHOC                     January 2024


     The following may be needed for validation or compatibility with APIs
     that do not support compact representation or do not support the full
     [SECG] format:

     *  If a compressed y-coordinate is required, then the value ~yp set
        to zero can be used.  The compact representation described above
        can in such a case be transformed into the SECG point compressed
        format by prepending it with the single byte 0x02 (i.e., M =
        0x02 || X).

     *  If an uncompressed y-coordinate is required, then a y-coordinate
        has to be calculated following Section 2.3.4 of [SECG] or
        Appendix C of [RFC6090].  Any of the square roots (see [SECG] or
        [RFC6090]) can be used.  The uncompressed SECG format is M =
        0x04 || X || Y.

     For example: The curve P-256 has the parameters (using the notation
     in [RFC6090])

     *  p = 2^256 − 2^224 + 2^192 + 2^96 − 1

     *  a = -3

     *  b = 410583637251521421293261297800472684091144410159937255
        54835256314039467401291

     Given an example x:

     *  x = 115792089183396302095546807154740558443406795108653336
        398970697772788799766525

     we can calculate y as the square root w = (x^3 + a ⋅ x + b)^((p +
     1)/4) (mod p)

     *  y = 834387180070192806820075864918626005281451259964015754
        16632522940595860276856

     Note that this does not guarantee that (x, y) is on the correct
     elliptic curve.  A full validation according to Section 5.6.2.3.3 of
     [SP-800-56A] can be achieved by also checking that 0 ≤ x < p and that
     y^2 ≡ x^3 + a ⋅ x + b (mod p).

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

     This Appendix is intended to help implementors not familiar with CBOR
     [RFC8949], CDDL [RFC8610], COSE [RFC9052], and HKDF [RFC5869].





  Selander, et al.          Expires 25 July 2024                 [Page 83]


  Internet-Draft                    EDHOC                     January 2024


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

     The EDHOC specification sometimes use CDDL names in CBOR diagnostic
     notation as in e.g., << ID_CRED_R, ? EAD_2 >>.  This means that EAD_2
     is optional and that ID_CRED_R and EAD_2 should be substituted with
     their values before evaluation.  I.e., if ID_CRED_R = { 4 : h'' } and
     EAD_2 is omitted then << ID_CRED_R, ? EAD_2 >> = << { 4 : h'' } >>,
     which encodes to 0x43a10440.  We also make use of the occurrence
     symbol "*", like in e.g., 2* int, meaning two or more CBOR integers.

     For a complete specification and more examples, see [RFC8949] and
     [RFC8610].  We recommend implementors get used to CBOR by using the
     CBOR playground [CborMe].



















  Selander, et al.          Expires 25 July 2024                 [Page 84]


  Internet-Draft                    EDHOC                     January 2024


           Diagnostic          Encoded              Type
          -----------------------------------------------------------
           1                   0x01                 unsigned integer
           24                  0x1818               unsigned integer
           -24                 0x37                 negative integer
           -25                 0x3818               negative integer
           true                0xf5                 simple value
           h''                 0x40                 byte string
           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
           ( 1, 2, true )      0x0102f5             sequence
           1, 2, true          0x0102f5             sequence
          -----------------------------------------------------------

                  Figure 20: Examples of use of CBOR and CDDL.

  C.2.  CDDL Definitions

     This section compiles the CDDL definitions for ease of reference.

     suites = [ 2* int ] / int

     ead = (
       ead_label : int,
       ? ead_value : bstr,
     )

     EAD_1 = 1* ead
     EAD_2 = 1* ead
     EAD_3 = 1* ead
     EAD_4 = 1* ead

     message_1 = (
       METHOD : int,
       SUITES_I : suites,
       G_X : bstr,
       C_I : bstr / -24..23,
       ? EAD_1,
     )

     message_2 = (
       G_Y_CIPHERTEXT_2 : bstr,
     )




  Selander, et al.          Expires 25 July 2024                 [Page 85]


  Internet-Draft                    EDHOC                     January 2024


     PLAINTEXT_2 = (
       C_R,
       ID_CRED_R : map / bstr / -24..23,
       Signature_or_MAC_2 : bstr,
       ? EAD_2,
     )

     message_3 = (
       CIPHERTEXT_3 : bstr,
     )

     PLAINTEXT_3 = (
       ID_CRED_I : map / bstr / -24..23,
       Signature_or_MAC_3 : bstr,
       ? EAD_3,
     )

     message_4 = (
       CIPHERTEXT_4 : bstr,
     )

     PLAINTEXT_4 = (
       ? EAD_4,
     )

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

     info = (
       info_label : int,
       context : bstr,
       length : uint,
     )

  C.3.  COSE

     CBOR Object Signing and Encryption (COSE) [RFC9052] 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 [RFC9053]



  Selander, et al.          Expires 25 July 2024                 [Page 86]


  Internet-Draft                    EDHOC                     January 2024


     *  The ciphertexts in message_3 and message_4 consist of a subset of
        the single recipient encrypted data object COSE_Encrypt0, which is
        described in Sections 5.2-5.3 of [RFC9052].  The ciphertext is
        computed over the plaintext and associated data, using an
        encryption key and an initialization vector.  The associated data
        is an Enc_structure consisting of protected headers and externally
        supplied data (external_aad).  COSE constructs the input to the
        AEAD [RFC5116] for message_i (i = 3 or 4, see Section 5.4 and
        Section 5.5, respectively) as follows:

        -  Secret key K = K_i

        -  Nonce N = IV_i

        -  Plaintext P for message_i

        -  Associated Data A = [ "Encrypt0", h'', TH_i ]

     *  Signatures in message_2 of method 0 and 2, and in message_3 of
        method 0 and 1, consist of a subset of the single signer data
        object COSE_Sign1, which is described in Sections 4.2-4.4 of
        [RFC9052].  The signature is computed over a Sig_structure
        containing payload, protected headers and externally supplied data
        (external_aad) using a private signature key and verified using
        the corresponding public signature key.  For COSE_Sign1, the
        message to be signed is:

         [ "Signature1", protected, external_aad, payload ]

        where protected, external_aad and payload are specified in
        Section 5.3 and Section 5.4.

     Different header parameters to identify X.509 or C509 certificates by
     reference are defined in [RFC9360] and
     [I-D.ietf-cose-cbor-encoded-cert]:

     *  by a hash value with the 'x5t' or 'c5t' parameters, respectively:

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

        -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R;

     *  or by a URI with the 'x5u' or 'c5u' parameters, respectively:

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

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




  Selander, et al.          Expires 25 July 2024                 [Page 87]


  Internet-Draft                    EDHOC                     January 2024


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

     *  ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R.  For
        further optimization, see Section 3.5.3.

     Note that ID_CRED_x can contain several header parameters, for
     example { x5u, x5t } or { kid, kid_context }.

     ID_CRED_x MAY also identify the credential by value.  For example, a
     certificate chain can be transported in an ID_CRED field with COSE
     header parameter c5c or x5chain, defined in
     [I-D.ietf-cose-cbor-encoded-cert] and [RFC9360] and credentials of
     type CWT and CCS can be transported with the COSE header parameters
     registered in Section 10.6.

  Appendix D.  Authentication Related Verifications

     EDHOC performs certain authentication related operations, see
     Section 3.5, but in general it is necessary to make additional
     verifications beyond EDHOC message processing.  Which verifications
     that are needed depend on the deployment, in particular the trust
     model and the security policies, but most commonly it can be
     expressed in terms of verifications of credential content.

     EDHOC assumes the existence of mechanisms (certification authority or
     other trusted third party, pre-provisioning, etc.) for generating and
     distributing authentication credentials and other credentials, as
     well as the existence of trust anchors (CA certificates, trusted
     public keys, etc.).  For example, a public key certificate or CWT may
     rely on a trusted third party whose public key is pre-provisioned,
     whereas a CCS or a self-signed certificate/CWT may be used when trust
     in the public key can be achieved by other means, or in the case of
     Trust on first use, see Appendix D.5.

     In this section we provide some examples of such verifications.
     These verifications are the responsibility of the application but may
     be implemented as part of an EDHOC library.

  D.1.  Validating the Authentication Credential

     The authentication credential may contain, in addition to the
     authentication key, other parameters that needs to be verified.  For
     example:






  Selander, et al.          Expires 25 July 2024                 [Page 88]


  Internet-Draft                    EDHOC                     January 2024


     *  In X.509 and C509 certificates, signature keys typically have key
        usage "digitalSignature" and Diffie-Hellman public keys typically
        have key usage "keyAgreement" [RFC3279][RFC8410].

     *  In X.509 and C509 certificates validity is expressed using Not
        After and Not Before.  In CWT and CCS, the “exp” and “nbf” claims
        have similar meanings.

  D.2.  Identities

     The application must decide on allowing a connection or not depending
     on the intended endpoint, and in particular whether it is a specific
     identity or in a set of identities.  To prevent misbinding attacks,
     the identity of the endpoint is included in a MAC verified through
     the protocol.  More details and examples are provided in this
     section.

     Policies for what connections to allow are typically set based on the
     identity of the other endpoint, and endpoints typically only allow
     connections from a specific identity or a small restricted set of
     identities.  For example, in the case of a device connecting to a
     network, the network may only allow connections from devices which
     authenticate with certificates having a particular range of serial
     numbers and signed by a particular CA.  Conversely, a device may only
     be allowed to connect to a network which authenticates with a
     particular public key.

     *  When a Public Key Infrastructure (PKI) is used with certificates,
        the identity is the subject whose unique name, e.g., a domain
        name, a Network Access Identifier (NAI), or an Extended Unique
        Identifier (EUI), is included in the endpoint's certificate.

     *  Similarly, when a PKI is used with CWTs, the identity is the
        subject identified by the relevant claim(s), such as 'sub'
        (subject).

     *  When PKI is not used (e.g., CCS, self-signed certificate/CWT) the
        identity is typically directly associated with the authentication
        key of the other party.  For example, if identities can be
        expressed in the form of unique subject names assigned to public
        keys, then a binding to identity is achieved by including both
        public key and associated subject name in the authentication
        credential: CRED_I or CRED_R may be a self-signed certificate/CWT
        or CCS containing the authentication key and the subject name, see
        Section 3.5.2.  Each endpoint thus needs to know the specific
        authentication key/unique associated subject name, or set of
        public authentication keys/unique associated subject names, which
        it is allowed to communicate with.



  Selander, et al.          Expires 25 July 2024                 [Page 89]


  Internet-Draft                    EDHOC                     January 2024


     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".
     EDHOC follows SIGMA by calculating a MAC over the whole
     authentication credential, which in case of an X.509 or C509
     certificate includes the "subject" and "subjectAltName" fields, and
     in the case of CWT or CCS includes the "sub" claim.

     (While the SIGMA paper only focuses on the identity, the same
     principle is true for other information such as policies associated
     with the public key.)

  D.3.  Certification Path and Trust Anchors

     When a Public Key Infrastructure (PKI) is used with certificates, the
     trust anchor is a Certification Authority (CA) certificate.  Each
     party needs at least one CA public key certificate, or just the CA
     public key.  The certification path contains proof that the subject
     of the certificate owns the public key in the certificate.  Only
     validated public-key certificates are to be accepted.

     Similarly, when a PKI is used with CWTs, each party needs to have at
     least one trusted third party public key as trust anchor to verify
     the end entity CWTs.  The trusted third party public key can, e.g.,
     be stored in a self-signed CWT or in a CCS.

     The signature of the authentication credential needs to be verified
     with the public key of the issuer.  X.509 and C509 certificates
     includes the “Issuer” field.  In CWT and CCS, the “iss” claim has a
     similar meaning.  The public key is either a trust anchor or the
     public key in another valid and trusted credential in a certification
     path from trust anchor to authentication credential.

     Similar verifications as made with the authentication credential (see
     Appendix D.1) are also needed for the other credentials in the
     certification path.

     When PKI is not used (CCS, self-signed certificate/CWT), the trust
     anchor is the authentication key of the other party, in which case
     there is no certification path.











  Selander, et al.          Expires 25 July 2024                 [Page 90]


  Internet-Draft                    EDHOC                     January 2024


  D.4.  Revocation Status

     The application may need to verify that the credentials are not
     revoked, see Section 9.8.  Some use cases may be served by short-
     lived credentials, for example, where the validity of the credential
     is on par with the interval between revocation checks.  But, in
     general, credential lifetime and revocation checking are
     complementary measures to control credential status.  Revocation
     information may be transported as External Authentication Data (EAD),
     see Appendix E.

  D.5.  Unauthenticated Operation

     EDHOC might be used without authentication by allowing the Initiator
     or Responder to communicate with any identity except its own.  Note
     that EDHOC without mutual authentication is vulnerable to active on-
     path attacks and therefore unsafe for general use.  However, it is
     possible to later establish a trust relationship with an unknown or
     not-yet-trusted endpoint.  Some examples:

     *  The EDHOC authentication credential can be verified out-of-band at
        a later stage.

     *  The EDHOC session key can be bound to an identity out-of-band at a
        later stage.

     *  Trust on first use (TOFU) can be used to verify that several EDHOC
        connections are made to the same identity.  TOFU combined with
        proximity is a common IoT deployment model which provides good
        security if done correctly.  Note that secure proximity based on
        short range wireless technology requires very low signal strength
        or very low latency.

  Appendix E.  Use of External Authorization Data

     In order to reduce the number of messages and round trips, or to
     simplify processing, external security applications may be integrated
     into EDHOC by transporting related external authorization data (EAD)
     in the messages.

     The EAD format is specified in Section 3.8, this section contains
     examples and further details of how EAD may be used with an
     appropriate accompanying specification.

     *  One example is third party assisted authorization, requested with
        EAD_1, and an authorization artifact (“voucher”, cf. [RFC8366])
        returned in EAD_2, see [I-D.selander-lake-authz].




  Selander, et al.          Expires 25 July 2024                 [Page 91]


  Internet-Draft                    EDHOC                     January 2024


     *  Another example is remote attestation, requested in EAD_2, and an
        Entity Attestation Token (EAT, [I-D.ietf-rats-eat]) returned in
        EAD_3.

     *  A third example is certificate enrolment, where a Certificate
        Signing Request (CSR, [RFC2986]) is included EAD_3, and the issued
        public key certificate (X.509 [RFC5280], C509
        [I-D.ietf-cose-cbor-encoded-cert]) or a reference thereof is
        returned in EAD_4.

     External authorization data should be considered unprotected by
     EDHOC, and the protection of EAD is the responsibility of the
     security application (third party authorization, remote attestation,
     certificate enrolment, etc.).  The security properties of the EAD
     fields (after EDHOC processing) are discussed in Section 9.1.

     The content of the EAD field may be used in the EDHOC processing of
     the message in which they are contained.  For example, authentication
     related information like assertions and revocation information,
     transported in EAD fields may provide input about trust anchors or
     validity of credentials relevant to the authentication processing.
     The EAD fields (like ID_CRED fields) are therefore made available to
     the application before the message is verified, see details of
     message processing in Section 5.  In the first example above, a
     voucher in EAD_2 made available to the application can enable the
     Initiator to verify the identity or public key of the Responder
     before verifying the signature.  An application allowing EAD fields
     containing authentication information thus may need to handle
     authentication related verifications associated with EAD processing.

     Conversely, the security application may need to wait for EDHOC
     message verification to complete.  In the third example above, the
     validation of a CSR carried in EAD_3 is not started by the Responder
     before EDHOC has successfully verified message_3 and proven the
     possession of the private key of the Initiator.

     The security application may reuse EDHOC protocol fields which
     therefore need to be available to the application.  For example, the
     security application may use the same crypto algorithms as in the
     EDHOC session and therefore needs access to the selected cipher suite
     (or the whole SUITES_I).  The application may use the ephemeral
     public keys G_X and G_Y, as ephemeral keys or as nonces, see
     [I-D.selander-lake-authz].

     The processing of the EAD item (ead_label, ? ead_value) by the
     security application needs to be described in the specification where
     the ead_label is registered, see Section 10.5, including the optional
     ead_value for each message and actions in case of errors.  An



  Selander, et al.          Expires 25 July 2024                 [Page 92]


  Internet-Draft                    EDHOC                     January 2024


     application may support multiple security applications that make use
     of EAD, which may result in multiple EAD items in one EAD field, see
     Section 3.8.  Any dependencies on security applications with
     previously registered EAD items needs to be documented, and the
     processing needs to consider their simultaneous use.

     Since data carried in EAD may not be protected, or be processed by
     the application before the EDHOC message is verified, special
     considerations need to be made such that it does not violate security
     and privacy requirements of the service which uses this data, see
     Section 9.5.  The content in an EAD item may impact the security
     properties provided by EDHOC.  Security applications making use of
     the EAD items must perform the necessary security analysis.

  Appendix F.  Application Profile Example

     This appendix contains a rudimentary example of an application
     profile, see Section 3.9.

     For use of EDHOC with application X the following assumptions are
     made:

     1.  Transfer in CoAP as specified in Appendix A.2 with requests
         expected by the CoAP server (= Responder) at /app1-edh, no
         Content-Format needed.

     2.  METHOD = 1 (I uses signature key, R uses static DH key.)

     3.  CRED_I is an IEEE 802.1AR IDevID encoded as a C509 certificate of
         type 0 [I-D.ietf-cose-cbor-encoded-cert].

         *  R acquires CRED_I out-of-band, indicated in EAD_1.

         *  ID_CRED_I = {4: h''} is a 'kid' with value the empty CBOR byte
            string.

     4.  CRED_R is a CCS of type OKP as specified in Section 3.5.2.

         *  The CBOR map has parameters 1 (kty), -1 (crv), and -2
            (x-coordinate).

         *  ID_CRED_R is {TBD2 : CCS}.  Editor's note: TBD2 is the COSE
            header parameter value of 'kccs', see Section 10.6

     5.  External authorization data is defined and processed as specified
         in [I-D.selander-lake-authz].





  Selander, et al.          Expires 25 July 2024                 [Page 93]


  Internet-Draft                    EDHOC                     January 2024


     6.  EUI-64 is used as the identity of the endpoint (see example in
         Section 3.5.2).

     7.  No use of message_4: the application sends protected messages
         from R to I.

  Appendix G.  Long PLAINTEXT_2

     By the definition of encryption of PLAINTEXT_2 with KEYSTREAM_2, it
     is limited to lengths of PLAINTEXT_2 not exceeding the output of
     EDHOC_KDF, see Section 4.1.2.  If the EDHOC hash algorithm is SHA-2
     then HKDF-Expand is used, which limits the length of the EDHOC_KDF
     output to 255 ⋅ hash_length, where hash_length is the length of the
     output of the EDHOC hash algorithm given by the cipher suite.  For
     example, with SHA-256 as EDHOC hash algorithm, the length of the hash
     output is 32 bytes and the maximum length of PLAINTEXT_2 is 255 ⋅ 32
     = 8160 bytes.

     While PLAINTEXT_2 is expected to be much shorter than 8 kB for the
     intended use cases, it seems nevertheless prudent to specify a
     solution for the event that this should turn out to be a limitation.

     A potential work-around is to use a cipher suite with a different
     hash function.  In particular, the use of KMAC removes all practical
     limitations in this respect.

     This section specifies a solution which works with any hash function,
     by making use of multiple invocations of HKDF-Expand and negative
     values of info_label.

     Consider the PLAINTEXT_2 partitioned in parts P(i) of length equal to
     M = 255 ⋅ hash_length, except possibly the last part P(last) which
     has 0 < length ≤ M.

     PLAINTEXT_2 = P(0) | P(1) | ... | P(last)

     where | indicates concatenation.

     The object is to define a matching KEYSTREAM_2 of the same length and
     perform the encryption in the same way as defined in Section 5.3.2:

     CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2

     Define the keystream as:

     KEYSTREAM_2 = OKM(0) | OKM(1)  | ... | OKM(last)

     where



  Selander, et al.          Expires 25 July 2024                 [Page 94]


  Internet-Draft                    EDHOC                     January 2024


     OKM(i) = EDHOC_KDF( PRK_2e, -i, TH_2, length(P(i)) )

     Note that if length(PLAINTEXT_2) ≤ M then P(0) = PLAINTEXT_2 and the
     definition of KEYSTREAM_2 = OKM(0) coincides with Figure 8.

     This describes the processing of the Responder when sending
     message_2.  The Initiator makes the same calculations when receiving
     message_2, but interchanging PLAINTEXT_2 and CIPHERTEXT_2.

     An application profile may specify if it supports or not the method
     described in this appendix.

  Appendix H.  EDHOC_KeyUpdate

     To provide forward secrecy in an even more efficient way than re-
     running EDHOC, this section specifies the optional function
     EDHOC_KeyUpdate in terms of EDHOC_KDF and PRK_out.

     When EDHOC_KeyUpdate is called, a new PRK_out is calculated as a
     "hash" of the old PRK_out using the EDHOC_Expand function as
     illustrated by the following pseudocode.  The change of PRK_out
     causes a change to PRK_exporter which enables the derivation of new
     application keys superseding the old ones, using EDHOC_Exporter, see
     Section 4.2.1.

      EDHOC_KeyUpdate( context ):
         new PRK_out = EDHOC_KDF( old PRK_out, 11, context, hash_length )
         new PRK_exporter = EDHOC_KDF( new PRK_out, 10, h'', hash_length )

     where hash_length denotes the output size in bytes of the EDHOC hash
     algorithm of the selected cipher suite.

     The EDHOC_KeyUpdate takes a context as input to enable binding of the
     updated PRK_out to some event that triggered the key update.  The
     Initiator and the Responder need to agree on the context, which can,
     e.g., be a counter, a pseudorandom number, or a hash.  To provide
     forward secrecy the old PRK_out and keys derived from it (old
     PRK_exporter and old application keys) must be deleted as soon as
     they are not needed.  When to delete the old keys and how to verify
     that they are not needed is up to the application.

     An application using EDHOC_KeyUpdate needs to store PRK_out.
     Compromise of PRK_out leads to compromise of all keying material
     derived with the EDHOC_Exporter since the last invocation of the
     EDHOC_KeyUpdate function.






  Selander, et al.          Expires 25 July 2024                 [Page 95]


  Internet-Draft                    EDHOC                     January 2024


     While this key update method provides forward secrecy it does not
     give as strong security properties as re-running EDHOC.
     EDHOC_KeyUpdate can be used to meet cryptographic limits and provide
     partial protection against key leakage, but it provides significantly
     weaker security properties than re-running EDHOC with ephemeral
     Diffie-Hellman.  Even with frequent use of EDHOC_KeyUpdate,
     compromise of one session key compromises all future session keys,
     and an attacker therefore only needs to perform static key
     exfiltration [RFC7624], which is less complicated and has a lower
     risk profile than the dynamic case, see Section 9.1.

     A similar method to do key update for OSCORE is KUDOS, see
     [I-D.ietf-core-oscore-key-update].

  Appendix I.  Example Protocol State Machine

     This appendix describes an example protocol state machine for the
     Initiator and for the Responder.  States are denoted in all capitals
     and parentheses denote actions taken only in some circumstances.

     Note that this state machine is just an example, and that details of
     processing are omitted, for example:

     *  When error messages are being sent (with one exception)

     *  How credentials and EAD are processed by EDHOC and the application
        in the RCVD state

     *  What verifications are made, which includes not only MACs and
        signatures

  I.1.  Initiator State Machine

     The Initiator sends message_1, triggering the state machine to
     transition from START to WAIT_M2, and waits for message_2.

     If the incoming message is an error message then the Initiator
     transitions from WAIT_M2 to ABORTED.  In case of error code 2 (Wrong
     Selected Cipher Suite), the Initiator remembers the supported cipher
     suites for this particular Responder and transitions from ABORTED to
     START.  The message_1 that the Initiator subsequently sends takes
     into account the cipher suites supported by the Responder.

     Upon receiving a non-error message, the Initiator transitions from
     WAIT_M2 to RCVD_M2 and processes the message.  If a processing error
     occurs on message_2, then the Initiator transitions from RCVD_M2 to
     ABORTED.  In case of successful processing of message_2, the
     Initiator transitions from RCVD_M2 to VRFD_M2.



  Selander, et al.          Expires 25 July 2024                 [Page 96]


  Internet-Draft                    EDHOC                     January 2024


     The Initiator prepares and processes message_3 for sending.  If any
     processing error is encountered, the Initiator transitions from
     VRFD_M2 to ABORTED.  If message_3 is successfully sent, the Initiator
     transitions from VRFD_M2 to COMPLETED.

     If the application profile includes message_4, then the Initiator
     waits for message_4.  If the incoming message is an error message
     then the Initiator transitions from COMPLETED to ABORTED.  Upon
     receiving a non-error message, the Initiator transitions from
     COMPLETED (="WAIT_M4") to RCVD_M4 and processes the message.  If a
     processing error occurs on message_4, then the Initiator transitions
     from RCVD_M4 to ABORTED.  In case of successful processing of
     message_4, the Initiator transitions from RCVD_M4 to PERSISTED
     (="VRFD_M4").

     If the application profile does not include message_4, then the
     Initiator waits for an incoming application message.  If the
     decryption and verification of the application message is successful,
     then the Initiator transitions from COMPLETED to PERSISTED.
































  Selander, et al.          Expires 25 July 2024                 [Page 97]


  Internet-Draft                    EDHOC                     January 2024


          +- - - - - - - - - -> START
          |                       |
                                  | Send message_1
          |                       |
                Receive error     v
      ABORTED <---------------- WAIT_M2
          ^                       |
          |                       | Receive message_2
          |                       |
          |    Processing error   v
          +-------------------- RCVD_M2
          ^                       |
          |                       | Verify message_2
          |                       |
          |    Processing error   v
          +-------------------- VRFD_M2
          ^                       |
          |                       | Send message_3
          |                       |
          |    (Receive error)    v
          +-------------------- COMPLETED ----------------+
          ^                       |                       |
          |                       | (Receive message_4)   |
          |                       |                       |
          |   (Processing error)  v                       | (Verify
          +------------------- (RCVD_M4)                  |  application
                                  |                       |  message)
                                  | (Verify message_4)    |
                                  |                       |
                                  v                       |
                                PERSISTED <---------------+

  I.2.  Responder State Machine

     Upon receiving message_1, the Responder transitions from START to
     RCVD_M1.

     If a processing error occurs on message_1, the Responder transitions
     from RCVD_M1 to ABORTED.  This includes sending error message with
     error code 2 (Wrong Selected Cipher Suite) if the selected cipher
     suite in message_1 is not supported.  In case of successful
     processing of message_1, the Responder transitions from RCVD_M1 to
     VRFD_M1.

     The Responder prepares and processes message_2 for sending.  If any
     processing error is encountered, the Responder transitions from
     VRFD_M1 to ABORTED.  If message_2 is successfully sent, the Initiator
     transitions from VRFD_M2 to WAIT_M3, and waits for message_3.



  Selander, et al.          Expires 25 July 2024                 [Page 98]


  Internet-Draft                    EDHOC                     January 2024


     If the incoming message is an error message then the Responder
     transitions from WAIT_M3 to ABORTED.

     Upon receiving message_3, the Responder transitions from WAIT_M3 to
     RCVD_M3.  If a processing error occurs on message_3, the Responder
     transitions from RCVD_M3 to ABORTED.  In case of successful
     processing of message_3, the Responder transitions from RCVD_M3 to
     COMPLETED (="VRFD_M3").

     If the application profile includes message_4, the Responder prepares
     and processes message_4 for sending.  If any processing error is
     encountered, the Responder transitions from COMPLETED to ABORTED.

     If message_4 is successfully sent, or if the application profile does
     not include message_4, the Responder transitions from COMPLETED to
     PERSISTED.

                                          START
                                            |
                                            | Receive message_1
                                            |
                         Processing error   v
                ABORTED <---------------- RCVD_M1
                    ^                       |
                    |                       | Verify message_1
                    |                       |
                    |    Processing error   v
                    +-------------------- VRFD_M1
                    ^                       |
                    |                       | Send message_2
                    |                       |
                    |     Receive error     v
                    +-------------------- WAIT_M3
                    ^                       |
                    |                       | Receive message_3
                    |                       |
                    |    Processing error   v
                    +-------------------- RCVD_M3
                    ^                       |
                    |                       | Verify message_3
                    |                       |
                    |   (Processing error)  v
                    +------------------- COMPLETED
                                            |
                                            | (Send message_4)
                                            |
                                            v
                                         PERSISTED



  Selander, et al.          Expires 25 July 2024                 [Page 99]


  Internet-Draft                    EDHOC                     January 2024


  Appendix J.  Change Log

     RFC Editor: Please remove this appendix.

     *  From -21 to -22

        -  Normative text on transport capabilities.

     *  From -20 to -21

        -  Recommendation to use chain instead of bag

        -  Improved text about

           o  denial-of-service

           o  deriving secret and non-secret randomness from the same KDF
              instance

           o  practical security against quantum computers

        -  Clarifications, including

           o  several updates section 3.4.  Transport

           o  descriptions in COSE IANA registration

           o  encoding in Figure 5, reading of Figure 17

        -  Removed term "dummy"

        -  Harmonizing captions

        -  Updated references

        -  Acknowledgments

     *  From -19 to -20

        -  C_R encrypted in message_2

        -  C_R removed from TH_2

        -  Error code for unknown referenced credential

        -  Error code 0 (success) explicitly reserved

        -  Message deduplication section moved from appendix to body



  Selander, et al.          Expires 25 July 2024                [Page 100]


  Internet-Draft                    EDHOC                     January 2024


        -  Terminology

           o  discontinued -> aborted

           o  protocol run / exchange -> session

        -  Clarifications, in particular

           o  when to derive application keys

           o  the role of the application for authentication

        -  Security considerations for kccs and kcwt

        -  Updated references

     *  From -18 to -19

        -  Clarifications:

           o  Relation to SIGMA

           o  Role of Static DH

           o  Initiator and Responder roles

           o  Transport properties

           o  Construction of SUITES_I

           o  Message correlation, new subsection 3.4.1, replacing former
              appendix H

           o  Role of description about long PLAINTEXT_2

           o  ead_label and ead_value

           o  Message processing (Section 5)

           o  Padding

           o  Cipher suite negotiation example

        -  Other updates:

           o  Improved and stricter normative text in Appendix A





  Selander, et al.          Expires 25 July 2024                [Page 101]


  Internet-Draft                    EDHOC                     January 2024


           o  Naming and separate sections for the two message flows in
              Appendix A: Forward/Reverse message flow,

           o  Table index style captions

           o  Aligning with COSE terminology: header map -> header_map

           o  Aligning terminology, use of "_" instead of "-"

           o  Prefixing "EDHOC_" to functions

           o  Updated list of security analysis papers

           o  New appendix with example state machine

           o  Acknowledgements

           o  Language improvements by native English speakers

           o  Updated IANA section with registration procedures

           o  New and updated references

           o  Removed appendix H

     *  From -17 to -18

        -  Padding realised as EAD with ead_label = 0, PAD fields removed

        -  Revised EAD syntax; ead is now EAD item; ead_value is now
           optional

        -  Clarifications of

           o  Identifier representation

           o  Authentication credentials

           o  RPK

           o  Encoding of ID_CRED with kid

           o  Representation of public keys, y-coordinate of ephemeral
              keys and validation

           o  Processing after completed protocol

           o  Making verifications available to the application



  Selander, et al.          Expires 25 July 2024                [Page 102]


  Internet-Draft                    EDHOC                     January 2024


           o  Relation between EDHOC and OSCORE identifiers

        -  Terminology alignment in particular session / protocol;
           discontinue / terminate

        -  Updated CDDL

        -  Additional unicode encodings

        -  Large number of nits from WGLC

     *  From -16 to -17

        -  EDHOC-KeyUpdate moved to appendix

        -  Updated peer awareness properties based on SIGMA

        -  Clarify use of random connection identifiers

        -  Editorials related to appendix about messages with long
           PLAINTEXT_2

        -  Updated acknowledgments (have we forgotten someone else? please
           send email)

     *  From -15 to -16

        -  TH_2 used as salt in the derivation of PRK_2e

        -  CRED_R/CRED_I included in TH_3/TH_4

        -  Distinguish label used in info, exporter or elsewhere

        -  New appendix for optional handling arbitrarily large message_2

           o  info_label type changed to int to support this

        -  Updated security considerations

        -  Implementation note about identifiers which are bstr/int

        -  Clarifications, especifically about compact representation

        -  Type bug fix in CDDL section

     *  From -14 to -15

        -  Connection identifiers and key identifiers are now byte strings



  Selander, et al.          Expires 25 July 2024                [Page 103]


  Internet-Draft                    EDHOC                     January 2024


           o  Represented as CBOR bstr in the EDHOC message

              +  Unless they happen to encode a one-byte CBOR int

           o  More examples

        -  EAD updates and details

           o  Definition of EAD item

           o  Definition of critical / non-critical EAD item

        -  New section in Appendix D: Unauthenticated Operation

        -  Clarifications

           o  Lengths used in EDHOC-KDF

           o  Key derivation from PRK_out

              +  EDHOC-KeyUpdate and EDHOC-Exporter

           o  Padding

        -  Security considerations

           o  When a change in a message is detected

           o  Confidentiality in case of active attacks

           o  Connection identifiers should be unpredictable

           o  Maximum length of message_2

        -  Minor bugs

     *  From -13 to -14

        -  Merge of section 1.1 and 1.2

        -  Connection and key identifiers restricted to be byte strings

        -  Representation of byte strings as one-byte CBOR ints (-24..23)

        -  Simplified mapping between EDHOC and OSCORE identifiers

        -  Rewrite of 3.5




  Selander, et al.          Expires 25 July 2024                [Page 104]


  Internet-Draft                    EDHOC                     January 2024


           o  Clarification of authentication related operations performed
              by EDHOC

           o  Authentication related verifications, including old section
              3.5.1, moved to new appendix D

        -  Rewrite of 3.8

           o  Move content about use of EAD to new appendix E

           o  ead_value changed to bstr

        -  EDHOC-KDF updated

           o  transcript_hash argument removed

           o  TH included in context argument

           o  label argument is now type uint, all labels replaced

        -  Key schedule updated

           o  New salts derived to avoid reuse of same key with expand and
              extract

           o  PRK_4x3m renamed PRK_4e3m

           o  K_4 and IV_4 derived from PRK_4e3m

           o  New PRK: PRK_out derived from PRK_4e3m and TH_4

           o  Clarified main output of EDHOC is the shared secret PRK_out

           o  Exporter defined by EDHOC-KDF and new PRK PRK_exporter
              derived from PRK_out

           o  Key update defined by Expand instead of Extract

        -  All applications of EDHOC-KDF in one place

        -  Update of processing

           o  EAD and ID_CRED passed to application when available

           o  identity verification and credential retrieval omitted in
              protocol description





  Selander, et al.          Expires 25 July 2024                [Page 105]


  Internet-Draft                    EDHOC                     January 2024


           o  Transcript hash defined by plaintext messages instead of
              ciphertext

           o  Changed order of input to TH_2

           o  Removed general G_X checking against selfie-attacks

        -  Support for padding of plaintext

        -  Updated compliance requirements

        -  Updated security considerations

           o  Updated and more clear requirements on MAC length

           o  Clarification of key confirmation

           o  Forbid use of same key for signature and static DH

        -  Updated appendix on message deduplication

        -  Clarifications of

           o  connection identifiers

           o  cipher suites, including negotiation

           o  EAD

           o  Error messages

        -  Updated media types

        -  Applicability template renamed application profile

        -  Editorials

     *  From -12 to -13

        -  no changes

     *  From -12:

        -  Shortened labels to derive OSCORE key and salt

        -  ead_value changed to bstr

        -  Removed general G_X checking against selfie-attacks



  Selander, et al.          Expires 25 July 2024                [Page 106]


  Internet-Draft                    EDHOC                     January 2024


        -  Updated and more clear requirements on MAC length

        -  Clarifications from Kathleen, Stephen, Marco, Sean, Stefan,

        -  Authentication Related Verifications moved to appendix

        -  Updated MTI section and cipher suite

        -  Updated security considerations

     *  From -11 to -12:

        -  Clarified applicability to KEMs

        -  Clarified use of COSE header parameters

        -  Updates on MTI

        -  Updated security considerations

        -  New section on PQC

        -  Removed duplicate definition of cipher suites

        -  Explanations of use of COSE moved to Appendix C.3

        -  Updated internal references

     *  From -10 to -11:

        -  Restructured section on authentication parameters

        -  Changed UCCS to CCS

        -  Changed names and description of COSE header parameters for
           CWT/CCS

        -  Changed several of the KDF and Exporter labels

        -  Removed edhoc_aead_id from info (already in transcript_hash)

        -  Added MTI section

        -  EAD: changed CDDL names and added value type to registry

        -  Updated Figures 1, 2, and 3

        -  Some correction and clarifications



  Selander, et al.          Expires 25 July 2024                [Page 107]


  Internet-Draft                    EDHOC                     January 2024


        -  Added core.edhoc to CoRE Resource Type registry

     *  From -09 to -10:

        -  SUITES_I simplified to only contain the selected and more
           preferred suites

        -  Info is a CBOR sequence and context is a bstr

        -  Added kid to UCCS example

        -  Separate header parameters for CWT and UCCS

        -  CWT Confirmation Method kid extended to bstr / int

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

        -  Replaced “perfect forward secrecy” with “forward secrecy”

        -  Updated security considerations

        -  Replaced prepended 'null' with 'true' in the CoAP transport of
           message_1

        -  Updated CDDL definitions



  Selander, et al.          Expires 25 July 2024                [Page 108]


  Internet-Draft                    EDHOC                     January 2024


        -  Expanded on the 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

     *  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



  Selander, et al.          Expires 25 July 2024                [Page 109]


  Internet-Draft                    EDHOC                     January 2024


        -  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

     *  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

     *  From -04 to -05:

        -  EDHOC-Rekey-FS -> EDHOC-KeyUpdate

        -  Clarification of cipher suite negotiation

        -  Updated security considerations




  Selander, et al.          Expires 25 July 2024                [Page 110]


  Internet-Draft                    EDHOC                     January 2024


        -  Updated test vectors

        -  Updated applicability statement template

     *  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

     *  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

     *  From -01 to -02:

        -  New section 1.2 Use of EDHOC

        -  Clarification of identities




  Selander, et al.          Expires 25 July 2024                [Page 111]


  Internet-Draft                    EDHOC                     January 2024


        -  New section 4.3 clarifying bstr_identifier

        -  Updated security considerations

        -  Updated text on cipher suite negotiation and key confirmation

        -  Test vector for static DH

     *  From -00 to -01:

        -  Removed PSK method

        -  Removed references to certificate by value

  Acknowledgments

     The authors want to thank Christian Amsüss, Alessandro Bruni,
     Karthikeyan Bhargavan, Carsten Bormann, Timothy Claeys, Baptiste
     Cottier, Roman Danyliw, Martin Disch, Martin Duke, Donald Eastlake,
     Lars Eggert, Stephen Farrell, Loïc Ferreira, Theis Grønbech Petersen,
     Felix Günther, Dan Harkins, Klaus Hartke, Russ Housley, Stefan
     Hristozov, Marc Ilunga, Charlie Jacomme, Elise Klein, Erik Kline,
     Steve Kremer, Alexandros Krontiris, Ilari Liusvaara, Rafa Marín-
     López, Kathleen Moriarty, David Navarro, Karl Norrman, Salvador
     Pérez, Radia Perlman, David Pointcheval, Maïwenn Racouchot, Eric
     Rescorla, Michael Richardson, Thorvald Sahl Jørgensen, Zaheduzzaman
     Sarker, Jim Schaad, Michael Scharf, Carsten Schürmann, John Scudder,
     Ludwig Seitz, Brian Sipos, Stanislav Smyshlyaev, Valery Smyslov,
     Peter van der Stok, Rene Struik, Vaishnavi Sundararajan, Erik
     Thormarker, Marco Tiloca, Sean Turner, Michel Veillette, Mališa
     Vučinić, Paul Wouters, and Lei Yan for reviewing and commenting on
     intermediate versions of the draft.  We are especially indebted to
     the late Jim Schaad for his continuous reviewing and implementation
     of early versions of this and other drafts.

     Work on this document has in part been supported by the H2020 project
     SIFIS-Home (grant agreement 952652).

  Authors' Addresses

     Göran Selander
     Ericsson AB
     SE-164 80 Stockholm
     Sweden
     Email: goran.selander@ericsson.com






  Selander, et al.          Expires 25 July 2024                [Page 112]


  Internet-Draft                    EDHOC                     January 2024


     John 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







































  Selander, et al.          Expires 25 July 2024                [Page 113]


