# drafts

name: draft-yan-anima-brski-cle
rev: 01
title: BRSKI-CLE: A Certificateless Enrollment framework in BRSKI
time: 2024-04-25T07:05:36Z
group_uri: /api/v1/group/group/1027/
expires: 2024-04-25T13:00:15Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Autonomous netops", "Agent discovery/reg"]
tags: []
fetched_at: 2026-03-04T00:00:05.669424+00:00
source: ietf
abstract:
  The Class 1 constrained IoT devices, defined in RFC7228, may be
     unable to use certificates within limited RAM.  Exiting enrollment
     protocols of BRSKI are all using certificates.  This document defines
     a certificateless enrollment framework in BRSKI (BRSKI-CLE) for
     constrained IoT devices.  Considering the evolution towards quantum-
     safe algorithms, the framework is based on Key Encapsulation
     Mechanism (KEM).  Cooperating with the authentication mechanism shown
     in I-D.selander-lake-authz, a constrained IoT device does not need to
     configure a public key to identify itself for the whole bootstrapping
     process.  An authentication centre (AC) is used for issuing
     lightweight credentials, such as CBOR Web Tokens (CWTs), to
     constrained IoT devices.  This document does not specify any
     lightweight credentials.

full_text:
  anima                                                        L. Yan, Ed.
  Internet-Draft                                                    Huawei
  Intended status: Standards Track                         23 October 2023
  Expires: 25 April 2024


         BRSKI-CLE: A Certificateless Enrollment framework in BRSKI
                        draft-yan-anima-brski-cle-01

  Abstract

     The Class 1 constrained IoT devices, defined in RFC7228, may be
     unable to use certificates within limited RAM.  Exiting enrollment
     protocols of BRSKI are all using certificates.  This document defines
     a certificateless enrollment framework in BRSKI (BRSKI-CLE) for
     constrained IoT devices.  Considering the evolution towards quantum-
     safe algorithms, the framework is based on Key Encapsulation
     Mechanism (KEM).  Cooperating with the authentication mechanism shown
     in I-D.selander-lake-authz, a constrained IoT device does not need to
     configure a public key to identify itself for the whole bootstrapping
     process.  An authentication centre (AC) is used for issuing
     lightweight credentials, such as CBOR Web Tokens (CWTs), to
     constrained IoT devices.  This document does not specify any
     lightweight credentials.

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

  Copyright Notice

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





  Yan                       Expires 25 April 2024                 [Page 1]


  Internet-Draft                  BRSKI-CLE                   October 2023


     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 . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Mutual authentication between the pledge and registrar  .   5
     3.  Enrollment framework  . . . . . . . . . . . . . . . . . . . .   6
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     There are various constrained IoT devices in the hospital, such as
     anesthesia syringe pumps, electrocardiogram monitors, smart bed
     cards, etc.  The access gateway is required to authenticate each
     connected IoT device.  Otherwise, adversaries can easily steal
     medical data through illegally accessed devices.  Certificates are
     widely utilized for authentication nowadays.  However, the RAM that
     can be used for authentication is commonly less than 10 KB in
     constrained medical IoT devices.  Moreover, some extremely
     constrained medical IoT devices only have about 8 KB RAM.  These
     constrained IoT devices are also common in scenarios other than in
     the hospital.  The IoT devices with around 10 KB RAM are defined as
     Class 1 constrained devices in [RFC7228].  The limited RAM resources
     make the Class 1 constrained IoT devices hard to use certificates.
     Even using CBOR to encode certificates, the certificate chain is also
     heavy for the Class 1 constrained IoT devices.  The CBOR encoded
     certificate chain in 4 length is around 4 KB, in 2 length is about
     1.5 KB as shown in [I-D.ietf-cose-cbor-encoded-cert].






  Yan                       Expires 25 April 2024                 [Page 2]


  Internet-Draft                  BRSKI-CLE                   October 2023


     The Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
     protocol provides a solution for secure zero-touch (automated)
     bootstrap of new (unconfigured) devices that are called "pledges".
     After being authenticated by the server "registrar", a pledge
     presents its key material to the network and acquires a network-
     specific identity.  This process is called "enrollment".  BRSKI
     typically uses Enrollment over Secure Transport (EST) [RFC7030],
     which is based on certificates, as the enrollment protocol.  Other
     alternative enrollment protocols in BRSKI, such as Constrained
     BRSKI[I-D.ietf-anima-constrained-voucher], BRSKI-AE
     [I-D.ietf-anima-brski-ae] and [I-D.ietf-acme-integrations], are also
     based on certificates.

     This document describes a certificateless enrollment framework in
     BRSKI (BRSKI-CLE) for constrained IoT devices.  Considering the
     evolution towards quantum-safe algorithms, the framework is based on
     the Key Encapsulation Mechanism (KEM).  The framework uses the public
     key of the server end to encapsulate the symmetric key.  The server
     end only needs to configure one public key to handle an enormous
     amount of client ends (the IoT devices).  Compared with encapsulating
     by the public key of the client end, such as EDHOC
     [I-D.ietf-lake-edhoc], a unique public key is required to be
     configured on each IoT device.  When the amount of IoT devices is
     huge, encapsulating by the public key of the client end is less
     efficient in deployment.

     The client end is assumed to have previously known the server end's
     public key in [I-D.wiggers-tls-authkem-psk].  Otherwise, the client
     end cannot encapsulate the symmetric key by the server end's public
     key.  In the BRSKI scenario, a pledge cannot previously know a domain
     server's public key.  Thus, the KEM-based authentication mechanism in
     [I-D.wiggers-tls-authkem-psk] cannot be utilized in the enrollment of
     BRSKI directly.

     The mutual authentication between the pledge and the registrar in
     BRSKI can also make by EDHOC, as shown in [I-D.selander-lake-authz].
     Moreover, the pledge's credential is supported transporting by
     reference rather than by value.  Therefore, cooperating with the
     authentication mechanism shown in [I-D.selander-lake-authz], a
     constrained IoT device has no need to configure a public key to
     identify itself for the whole bootstrapping process.

     An authentication centre (AC) is used for issuing lightweight
     credentials, such as CBOR Web Tokens (CWTs), to the pledges in the
     enrollment phase of BRSKI.  This document does not specify any
     lightweight credentials.





  Yan                       Expires 25 April 2024                 [Page 3]


  Internet-Draft                  BRSKI-CLE                   October 2023


  1.1.  Terminology

     *AC*: The authentication centre provides the credential issuance for
     the pledges.

     *Domain*: The set of entities that share a common local trust anchor.

     *enrollment*: The process where a device presents key material to a
     network and acquires a network-specific identity.

     *imprint*: The process where a device obtains the cryptographic key
     material to identify and trust future interactions with a network.
     This process is the step before enrollment, as defined in BRSKI
     [RFC8995].

     *Pledge*: The prospective (unconfigured) device, which has an
     identity installed at the factory.

  1.2.  Requirements Language

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

  2.  Architecture

     The architecture of the components in BESKI-CLE is shown in Figure 1.
     Compared with the architecture of BRSKI, the CA is replaced by the
     AC.  The AC can be implemented on the registrar or as a backend
     domain component.  After imprinting, the pledge can use BESKI-CLE to
     obtain a lightweight credential from the AC.  It is assumed that the
     communication between the registrar and the AC is protected by a
     security protocol, such as TLS or DTLS, and they can authenticate
     each other using the security protocol.















  Yan                       Expires 25 April 2024                 [Page 4]


  Internet-Draft                  BRSKI-CLE                   October 2023


                                                +------------------------+
        +--------------Drop-Ship----------------| Vendor Service         |
        |                                       +------------------------+
        |                                       | M anufacturer|         |
        |                                       | A uthorized  |Ownership|
        |                                       | S igning     |Tracker  |
        |                                       | A uthority   |         |
        |                                       +--------------+---------+
        |                                                      ^
        |                                                      |  BRSKI-
        V                                                      |   MASA
     +-------+     ............................................|...
     |       |     .                                           |  .
     |       |     .  +------------+       +-----------+       |  .
     |       |     .  |            |       |           |       |  .
     |Pledge |     .  |   Join     |       | Domain    <-------+  .
     |       |     .  |   Proxy    |       | Registrar |          .
     |       <-------->............<------->   (AC)    |          .
     |       | EDHOC  |            | EDHOC |           |          .
     |       |     .  |            |       +-----+-----+          .
     |IDevID |     .  +------------+             | BESKI-CLE      .
     |       |     .           +-----------------+----------+     .
     |       |     .           |                            |     .
     |       |     .           | Authentication Centre(AC)  |     .
     +-------+     .           |                            |     .
                   .           +----------------------------+     .
                   .                                              .
                   ................................................
                                  "Domain" Components

                        Figure 1: Architecture Overview

  2.1.  Mutual authentication between the pledge and registrar

     EDHOC can be a lightweight substitute of TLS for the mutual
     authentication between the pledge and registrar, as described in
     [I-D.selander-lake-authz].  Moreover, the pledge's credential is
     supported transporting by reference rather than by value.  Thus,
     there is no need to configure a credential or a public key on the
     pledge to identify itself for the mutual authentication.











  Yan                       Expires 25 April 2024                 [Page 5]


  Internet-Draft                  BRSKI-CLE                   October 2023


     The message flow of transporting credentials by reference is shown in
     Figure 2, as described at the bottom of Figure 3 in
     [I-D.selander-lake-authz].  ID_CRED_I is used to identify the
     pledge's authentication credential CRED_I.  Pledge sends ID_CRED_I to
     the registrar in the message_3 of EDHOC.  The registrar may use
     ID_CRED_I to obtain the pledge's credential CRED_I from the MASA.
     Credential lookup of CRED_I may involve MASA or other credential
     databases.

                              Credential
     Pledge       Registrar     Database
                                  (MASA)
       |  ID_CRED_I   |              |
       +------------->|  ID_CRED_I   |
       |   message_3  +------------->|
       |              |              |
       |              |   CRED_I     |
       |    EDHOC     |<-------------+
       |              |              |

                 Figure 2: Transporting Credential by reference

  3.  Enrollment framework

     After imprinting, the pledge begins the process of enrollment.  A
     basic protocol flow is shown in Figure 3.

























  Yan                       Expires 25 April 2024                 [Page 6]


  Internet-Draft                  BRSKI-CLE                   October 2023


     +----------+               +-----------+                +--------+
     |          |               |           |                |        |
     |  Pledge  |               | Registrar |                |   AC   |
     |          |               |           |                |        |
     +-----+----+               +-----+-----+                +----+---+
           |                          |                           |
           |    [imprint finished]    | (A) Pledge's ID Register  |
           |                          +-------------------------->|
           |                          |                           |
           |  (B) Public Key Request  |                           |
           +------------------------->|  (B) Public Key Request   |
           |                          +-------------------------->|
           |                          |                           |
           |                          |      (C) Public Key       |
           |     (C) Public Key       |<--------------------------+
           |<-------------------------+                           |
           |                          |                           |
           | (D) [Credential Request] |                           |
           +------------------------->| (D) [Credential Request]  |
           |                          +-------------------------->|
           |                          |                           |
           |                          |    (E) <Credential>       |
           |    (E) <Credential>      |<--------------------------+
           |<-------------------------+                           |
           |                          |                           |

               [] Indicates messages protected using AC's public key.
               <> Indicates messages protected using a symmetric key.

                         Figure 3: Basic Protocol Flow

     Registering Pledge's ID (A):  After authenticating the pledge
        successfully during imprint, the registrar registers the pledge's
        ID on the AC.  The pledge's ID is the unique identity set by the
        pledge's vendor, such as the MAC address.  The AC may record the
        pledge's ID on the allowlist.

     Requesting a public key (B):  The pledge makes a public key request
        to the AC.  The pledge should send its ID in the request.

     Public key response (C):  If the pledge's ID is on the allowlist, the
        AC returns its public key to the pledge.

     Credential request (D):  The pledge interacts with the AC to request
        a local credential.  Firstly, the pledge generates a symmetric key
        and encapsulates the symmetric key by the received public key.
        Secondly, the pledge sends the encapsulated key to the AC for
        credential transporting.



  Yan                       Expires 25 April 2024                 [Page 7]


  Internet-Draft                  BRSKI-CLE                   October 2023


     Credential response (E):  Firstly, the AC decapsulate the symmetric
        key by its private key.  Secondly, the AC generates a credential
        for the pledge and encrypts the credential by the received
        symmetric key.  Lastly, the AC sends the encrypted credential to
        the pledge.

  4.  Security Considerations

     TBD.

  5.  IANA Considerations

     TBD.

  6.  References

  6.1.  Normative References

     [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
                and K. Watsen, "Bootstrapping Remote Secure Key
                Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
                May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

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

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

  6.2.  Informative References

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

     [I-D.ietf-anima-constrained-voucher]
                Richardson, M., Van der Stok, P., Kampanakis, P., and E.
                Dijk, "Constrained Bootstrapping Remote Secure Key
                Infrastructure (BRSKI)", Work in Progress, Internet-Draft,



  Yan                       Expires 25 April 2024                 [Page 8]


  Internet-Draft                  BRSKI-CLE                   October 2023


                draft-ietf-anima-constrained-voucher-21, 7 July 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
                constrained-voucher-21>.

     [I-D.ietf-anima-brski-ae]
                von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE:
                Alternative Enrollment Protocols in BRSKI", Work in
                Progress, Internet-Draft, draft-ietf-anima-brski-ae-06, 20
                October 2023, <https://datatracker.ietf.org/doc/html/
                draft-ietf-anima-brski-ae-06>.

     [I-D.ietf-acme-integrations]
                Friel, O., Barnes, R., Shekh-Yusef, R., and M. Richardson,
                "ACME Integrations for Device Certificate Enrollment",
                Work in Progress, Internet-Draft, draft-ietf-acme-
                integrations-17, 13 July 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-acme-
                integrations-17>.

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

     [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-22, 25
                August 2023, <https://datatracker.ietf.org/doc/html/draft-
                ietf-lake-edhoc-22>.

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










  Yan                       Expires 25 April 2024                 [Page 9]


  Internet-Draft                  BRSKI-CLE                   October 2023


     [I-D.wiggers-tls-authkem-psk]
                Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
                Sullivan, "KEM-based pre-shared-key handshakes for TLS
                1.3", Work in Progress, Internet-Draft, draft-wiggers-tls-
                authkem-psk-00, 18 August 2023,
                <https://datatracker.ietf.org/doc/html/draft-wiggers-tls-
                authkem-psk-00>.

  Acknowledgements

     The authors would like to thank...

  Contributors

  Author's Address

     Lei YAN (editor)
     Huawei
     Ruanjiandadao Road
     Nanjing
     210000
     China
     Email: ray.yanlei@huawei.com




























  Yan                       Expires 25 April 2024                [Page 10]


name: draft-ounsworth-lamps-cms-dhkem
rev: 00
title: Use of the DH-Based KEM (DHKEM) in the Cryptographic Message Syntax (CMS)
time: 2024-02-25T08:14:14Z
group_uri: /api/v1/group/group/1027/
expires: 2024-02-26T04:50:45Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "A2A protocols"]
tags: []
fetched_at: 2026-03-04T00:00:05.678431+00:00
source: ietf
abstract:
  The DHKEM Algorithm is a one-pass (store-and-forward) mechanism for
     establishing keying data to a recipient using the recipient's Diffie-
     Hellman or elliptic curve Diffie-Hellman public key.  This document
     defines a mechanism to wrap Ephemeral-Static (E-S) Diffie-Hellman
     (DH) and Elliptic Curve Diffie-Hellman (ECDH) such that it can be
     used in KEM interfaces within the Cryptographic Message Syntax (CMS).
     This is a sister document to RSA-KEM [RFC5990] and simplifies future
     cryptographic protocol design by only needing to handle KEMs at the
     protocol level.

full_text:
  LAMPS                                                       M. Ounsworth
  Internet-Draft                                                   J. Gray
  Intended status: Standards Track                                 Entrust
  Expires: 26 February 2024                                     R. Housley
                                                            Vigil Security
                                                            25 August 2023


    Use of the DH-Based KEM (DHKEM) in the Cryptographic Message Syntax
                                   (CMS)
                     draft-ounsworth-lamps-cms-dhkem-00

  Abstract

     The DHKEM Algorithm is a one-pass (store-and-forward) mechanism for
     establishing keying data to a recipient using the recipient's Diffie-
     Hellman or elliptic curve Diffie-Hellman public key.  This document
     defines a mechanism to wrap Ephemeral-Static (E-S) Diffie-Hellman
     (DH) and Elliptic Curve Diffie-Hellman (ECDH) such that it can be
     used in KEM interfaces within the Cryptographic Message Syntax (CMS).
     This is a sister document to RSA-KEM [RFC5990] and simplifies future
     cryptographic protocol design by only needing to handle KEMs at the
     protocol level.

  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://EntrustCorporation.github.io/cms-dhkem/draft-ietf-ounsworth-
     cms-dhkem.html.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ounsworth-lamps-cms-dhkem/.

     Discussion of this document takes place on the Limited Additional
     Mechanisms for PKIX and SMIME (lamps) Working Group mailing list
     (mailto:spasm@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/spasm/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/spasm/.

     Source for this draft and an issue tracker can be found at
     https://github.com/EntrustCorporation/cms-dhkem.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.





  Ounsworth, et al.       Expires 26 February 2024                [Page 1]


  Internet-Draft                  CMS DHKEM                    August 2023


     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 26 February 2024.

  Copyright Notice

     Copyright (c) 2023 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.  Cryptographic dependencies  . . . . . . . . . . . . . . . . .   4
       3.1.  Key Derivation Function . . . . . . . . . . . . . . . . .   4
       3.2.  (Elliptic Curve) Diffie Hellman . . . . . . . . . . . . .   4
     4.  DH-Based KEM (DHKEM)  . . . . . . . . . . . . . . . . . . . .   4
     5.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
       7.1.  Object Identifier Allocations . . . . . . . . . . . . . .   6
         7.1.1.  Module Registration - SMI Security for S/MIME Module
                 Identifer . . . . . . . . . . . . . . . . . . . . . .   6
         7.1.2.  Object Identifier Registrations - SMI Security for S/
                 MIME Attributes . . . . . . . . . . . . . . . . . . .   7
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8




  Ounsworth, et al.       Expires 26 February 2024                [Page 2]


  Internet-Draft                  CMS DHKEM                    August 2023


  1.  Introduction

     The Cryptographic Message Syntax (CMS) enveloped-data content type
     [RFC5652] and the CMS authenticated-enveloped-data content type
     [RFC5083] support both key transport and key agreement algorithms to
     establish the key used to encrypt the content.  In recent years,
     cryptographers have be specifying Key Encapsulation Mechanism (KEM)
     algorithms, including quantum-secure KEM algorithms.  This document
     defines conventions for wrapping Diffie-Hellman Ephemeral-Static
     (E-S) Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) to
     fit the KEM interface for the CMS enveloped-data content type and the
     CMS authenticated-enveloped-data content type as defined in
     [I-D.ietf-lamps-cms-kemri].  This is a parallel mechanism to
     [RFC5990] which does the same for RSA.  The benefit is to allow
     forward-compatibility of older DH-based ciphers into new mechanisms
     that only support KEMs.

     A KEM algorithm is a one-pass (store-and-forward) mechanism for
     transporting random keying material to a recipient using the
     recipient's public key.  The recipient's private key is needed to
     recover the random keying material, which is then treated as a
     pairwise shared secret between the originator and recipient.  A KEM
     algorithm provides three functions:

     *  KeyGen() -> (pk, sk):

        Generate the public key (pk) and a private key (sk).

     *  Encapsulate(pk) -> (ct, ss):

        Given the recipient's public key (pk), produce a ciphertext (ct)
        to be passed to the recipient and shared secret (ss) for the
        originator.

     *  Decapsulate(sk, ct) -> ss:

        Given the private key (sk) and the ciphertext (ct), produce the
        shared secret (ss) for the recipient.

     To support a particular KEM algorithm, the CMS originator MUST
     implement Encapsulate().

     To support a particular KEM algorithm, the CMS recipient MUST
     implement KeyGen() and Decapsulate().  The recipient's public key is
     usually carried in a certificate [RFC5280].






  Ounsworth, et al.       Expires 26 February 2024                [Page 3]


  Internet-Draft                  CMS DHKEM                    August 2023


     This draft follows the DH-Based KEM (DHKEM) construction defined in
     [RFC9180] whereby the Encapsulate() operation includes the generation
     of an ephemeral key and the usage of that key against the recipient's
     static public key.

  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.

  3.  Cryptographic dependencies

  3.1.  Key Derivation Function

     A key derivation function (KDF):

     *  Extract(salt, ikm): Extract a pseudorandom key of fixed length
        keyLength bytes from input keying material ikm and an optional
        byte string salt.

     *  Expand(prk, info, L): Expand a pseudorandom key prk using optional
        string info into L bytes of output keying material.

     *  keyLength: The output size of the Extract() function in bytes.

  3.2.  (Elliptic Curve) Diffie Hellman

     An elliptic curve or finite field Diffie-Hellman group providing the
     following operations:

     *  GenerateKeyPair(): create a new DH key.

     *  DH(skX, pkY): Perform a non-interactive Diffie-Hellman exchange
        using the private key skX and public key pkY to produce a Diffie-
        Hellman shared secret of length Ndh. This function can raise a
        ValidationError as described in [RFC9180] Section 7.1.4.

  4.  DH-Based KEM (DHKEM)

     This is a straightforward application of the DHKEM construction from
     [RFC9180] section 4.1 which is to be used unmodified.

     CMS encrypt operations performed by the sender are to use Encap(pkR).
     CMS decrypt operations performed by the received are to use
     Decap(enc, skR).



  Ounsworth, et al.       Expires 26 February 2024                [Page 4]


  Internet-Draft                  CMS DHKEM                    August 2023


     The authenticated modes, AuthEncap(pkR, skS) and AuthDecap(enc, skR,
     pkS) do not apply to CMS.

  5.  ASN.1 Module

     In order to carry a DHKEM inside a CMS KEMRecipientInfo
     [I-D.ietf-lamps-cms-kemri], we define id-kem-dhkem, kema-dhkem, and
     DHKemParameters.

  CMS-DHKEM-2023
      { iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs-9(9) smime(16) modules(0)
        id-mod-cms-dhkem-2023(TBDMOD) }

    DEFINITIONS IMPLICIT TAGS ::=
    BEGIN
    -- EXPORTS ALL;

    IMPORTS

    AlgorithmIdentifier{}, KEY-AGREE, KEY-DERIVATION
      FROM AlgorithmInformation-2009
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-algorithmInformation-02(58) }

     KEM-ALGORITHM
       FROM KEMAlgorithmInformation-2023 -- [I-D.ietf-lamps-cms-kemri]
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-kemAlgorithmInformation-2023(99) }

     pk-dh, pk-ec
       FROM PKIXAlgs-2009
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-pkix1-algorithms2008-02(56) }

    pk-X25519, pk-X448
      FROM Safecurves-pkix-18
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-safecurves-pkix(93) } ;


    id-alg-dhkem OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) TBDALG }




  Ounsworth, et al.       Expires 26 February 2024                [Page 5]


  Internet-Draft                  CMS DHKEM                    August 2023


    kema-dhkem KEM-ALGORITHM ::= {
        IDENTIFIER id-alg-dhkem
        PARAMS TYPE DHKemParameters
        PUBLIC-KEYS { pk-dh | pk-ec | pk-X25519 | pk-X448 }
        UKM ARE optional
        SMIME-CAPS { TYPE DHKemParameters IDENTIFIED BY id-kem-dhkem } }

    DHKemParameters ::= SEQUENCE {
        dh         KeyAgreeAlgorithmIdentifier,
        kdf        KeyDerivationFunction,
        keyLength  KeyLength }

    KeyAgreeAlgorithmIdentifier ::= AlgorithmIdentifier{ KEY-AGREE, {...} }

    KeyDerivationFunction ::= AlgorithmIdentifier { KEY-DERIVATION, {...} }

    KeyLength ::= INTEGER (1..MAX)

  END

     EDNOTE: The other way to define this would be to call out a toplevel
     DHKEM for each one: id-kema-dhkem-dh id-kema-dhkem-ecdh, id-kema-
     dhkem-x25519, id-kema-dhkem-x448.  EDNOTE: This approach adds a layer
     of wrapping for the benefit of agility and future-proofing.  I would
     be happy to write them each out if that's considered better.

  6.  Security Considerations

     This document does not add any security considerations above those
     already present for the Ephemeral-Static mode of the underlying
     (EC)DH primitive and in [RFC9180].

  7.  IANA Considerations

     This document registers the OID id-alg-dhkem

     The IANA is requested to allocate a value from the "SMI Security for
     S/MIME Module Identifier" registry for the included ASN.1 module, and
     allocate values from "SMI Security for S/MIME Algorithms" to identify
     the new algorithm defined within.

  7.1.  Object Identifier Allocations

  7.1.1.  Module Registration - SMI Security for S/MIME Module Identifer

     *  Decimal: IANA Assigned - Replace TBDMOD

     *  Description: CMS-DHKEM-2023 - id-mod-cms-dhkem-2023



  Ounsworth, et al.       Expires 26 February 2024                [Page 6]


  Internet-Draft                  CMS DHKEM                    August 2023


     *  References: This Document

  7.1.2.  Object Identifier Registrations - SMI Security for S/MIME
          Attributes

     *  DHKEM

        -  Decimal: IANA Assigned - Replace TBDALG

        -  Description: id-alg-dhkem

        -  References: This Document

  8.  References

  8.1.  Normative References

     [I-D.ietf-lamps-cms-kemri]
                Housley, R., Gray, J., and T. Okubo, "Using Key
                Encapsulation Mechanism (KEM) Algorithms in the
                Cryptographic Message Syntax (CMS)", Work in Progress,
                Internet-Draft, draft-ietf-lamps-cms-kemri-04, 9 August
                2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
                lamps-cms-kemri-04>.

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

     [RFC5083]  Housley, R., "Cryptographic Message Syntax (CMS)
                Authenticated-Enveloped-Data Content Type", RFC 5083,
                DOI 10.17487/RFC5083, November 2007,
                <https://www.rfc-editor.org/rfc/rfc5083>.

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

     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/rfc/rfc5652>.

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



  Ounsworth, et al.       Expires 26 February 2024                [Page 7]


  Internet-Draft                  CMS DHKEM                    August 2023


  8.2.  Informative References

     [RFC5990]  Randall, J., Kaliski, B., Brainard, J., and S. Turner,
                "Use of the RSA-KEM Key Transport Algorithm in the
                Cryptographic Message Syntax (CMS)", RFC 5990,
                DOI 10.17487/RFC5990, September 2010,
                <https://www.rfc-editor.org/rfc/rfc5990>.

     [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
                Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
                February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Mike Ounsworth
     Entrust Limited
     2500 Solandt Road – Suite 100
     Ottawa, Ontario  K2K 3G5
     Canada
     Email: mike.ounsworth@entrust.com


     John Gray
     Entrust Limited
     2500 Solandt Road – Suite 100
     Ottawa, Ontario  K2K 3G5
     Canada
     Email: john.gray@entrust.com


     Russ Housley
     Vigil Security, LLC
     Herndon, VA,
     United States of America
     Email: housley@vigilsec.com












  Ounsworth, et al.       Expires 26 February 2024                [Page 8]


name: draft-ingles-eap-edhoc
rev: 05
title: Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman over COSE (EDHOC)
time: 2024-06-13T09:30:24Z
group_uri: /api/v1/group/group/1674/
expires: 2024-03-15T08:14:34Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:05.681548+00:00
source: ietf
abstract:
  The Extensible Authentication Protocol (EAP), defined in RFC 3748,
     provides a standard mechanism for support of multiple authentication
     methods.  This document specifies the use of EAP-EDHOC with Ephemeral
     Diffie-Hellman Over COSE (EDHOC).  EDHOC provides a lightweight
     authenticated Diffie-Hellman key exchange with ephemeral keys, using
     COSE (RFC 8152) to provide security services efficiently encoded in
     CBOR (RFC 8949).  This document also provides guidance on
     authentication and authorization for EAP-EDHOC.

full_text:
  EMU Working Group                                      E. Ingles-Sanchez
  Internet-Draft                                      University of Murcia
  Intended status: Standards Track                      D. Garcia-Carrillo
  Expires: 15 March 2024                              University of Oviedo
                                                            R. Marin-Lopez
                                                      University of Murcia
                                                               G. Selander
                                                         J. Preuß Mattsson
                                                                  Ericsson
                                                         12 September 2023


    Using the Extensible Authentication Protocol with Ephemeral Diffie-
                         Hellman over COSE (EDHOC)
                         draft-ingles-eap-edhoc-05

  Abstract

     The Extensible Authentication Protocol (EAP), defined in RFC 3748,
     provides a standard mechanism for support of multiple authentication
     methods.  This document specifies the use of EAP-EDHOC with Ephemeral
     Diffie-Hellman Over COSE (EDHOC).  EDHOC provides a lightweight
     authenticated Diffie-Hellman key exchange with ephemeral keys, using
     COSE (RFC 8152) to provide security services efficiently encoded in
     CBOR (RFC 8949).  This document also provides guidance on
     authentication and authorization for EAP-EDHOC.

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

  Copyright Notice

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



  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 1]


  Internet-Draft                  EAP-EDHOC                 September 2023


     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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Overview of the EAP-EDHOC Conversation  . . . . . . . . .   3
         3.1.1.  Authentication  . . . . . . . . . . . . . . . . . . .   3
         3.1.2.  Transport and Message Correlation . . . . . . . . . .   5
         3.1.3.  Termination . . . . . . . . . . . . . . . . . . . . .   5
         3.1.4.  Identity  . . . . . . . . . . . . . . . . . . . . . .   9
         3.1.5.  Privacy . . . . . . . . . . . . . . . . . . . . . . .  10
         3.1.6.  Fragmentation . . . . . . . . . . . . . . . . . . . .  10
       3.2.  Identity Verification . . . . . . . . . . . . . . . . . .  13
       3.3.  Key Hierarchy . . . . . . . . . . . . . . . . . . . . . .  14
       3.4.  Parameter Negotiation and Compliance Requirements . . . .  15
       3.5.  EAP State Machines  . . . . . . . . . . . . . . . . . . .  15
     4.  Detailed Description of the EAP-EDHOC Protocol  . . . . . . .  15
       4.1.  EAP-EDHOC Request Packet  . . . . . . . . . . . . . . . .  15
       4.2.  EAP-EDHOC Response Packet . . . . . . . . . . . . . . . .  17
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
       5.1.  EAP Type  . . . . . . . . . . . . . . . . . . . . . . . .  18
       5.2.  EDHOC Exporter Label Registry . . . . . . . . . . . . . .  18
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
       6.1.  Security Claims . . . . . . . . . . . . . . . . . . . . .  19
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  20
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  21
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

  1.  Introduction

     The Extensible Authentication Protocol (EAP), defined in [RFC3748],
     provides a standard mechanism for support of multiple authentication
     methods.  This document specifies the EAP authentication method EAP-
     EDHOC which uses COSE defined credential-based mutual authentication,
     utilizing the EDHOC protocol cipher suite negotiation and
     establishment of shared secret keying material.  Ephemeral Diffie-
     Hellman Over COSE (EDHOC, [I-D.ietf-lake-edhoc]) is a very compact



  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 2]


  Internet-Draft                  EAP-EDHOC                 September 2023


     and lightweight authenticated key exchange protocol designed for
     highly constrained settings.  The main objective for EDHOC is to be a
     matching security handshake protocol to OSCORE [RFC8613], 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.  EDHOC reuses the
     same lightweight primitives as OSCORE, CBOR [RFC8949] and COSE
     [RFC8152], and specifies the use of CoAP but is not bound to a
     particular transport.  The EAP-EDHOC method will enable the
     integration of EDHOC in different applications and use cases making
     use of the EAP framework.

  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.

  3.  Protocol Overview

  3.1.  Overview of the EAP-EDHOC Conversation

     The EDHOC protocol running between an Initiator and a Responder
     consists of three mandatory messages (message_1, message_2,
     message_3), an optional message_4, and an error message.  EAP-EDHOC
     uses all messages in the exchange, and message_4 is mandatory, as an
     alternate success indication.

     After receiving an EAP-Request packet with EAP-Type=EAP-EDHOC as
     described in this document, the conversation will continue with the
     EDHOC protocol encapsulated in the data fields of EAP-Response and
     EAP-Request packets.  When EAP-EDHOC is used, the formatting and
     processing of the EDHOC message SHALL be done as specified in
     [I-D.ietf-lake-edhoc].  This document only lists additional and
     different requirements, restrictions, and processing compared to
     [I-D.ietf-lake-edhoc].

  3.1.1.  Authentication

     EAP-EDHOC authentication credentials can be of any type supported by
     COSE and be transported or referenced by EDHOC.

     EAP-EDHOC provides forward secrecy by exchange of ephemeral Diffie-
     Hellman public keys in message_1 and message_2.





  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 3]


  Internet-Draft                  EAP-EDHOC                 September 2023


     The optimization combining the execution of EDHOC with the first
     subsequent OSCORE transaction specified in
     [I-D.ietf-core-oscore-edhoc] is not supported in this EAP method.

     Figure 1 shows an example message flow for a successful EAP-EDHOC.

       EAP-EDHOC Peer                                   EAP-EDHOC Server

           |                           EAP-Request/Identity        |
           | <---------------------------------------------------- |
           |                                                       |
           |   EAP-Response/Identity (Privacy-Friendly)            |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                     (EDHOC Start)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_1)                                   |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                 (EDHOC message_2)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_3)                                   |
           | ----------------------------------------------------> |
           |                                                       |
           |                                         EAP-Request/  |
           |                                   EAP-Type=EAP-EDHOC  |
           |                                    (EDHOC message_4)  |
           | <---------------------------------------------------  |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |  ---------------------------------------------------> |
           |                                        EAP-Success    |
           | <---------------------------------------------------  |
           +                                                       +

                   Figure 1: EAP-EDHOC Mutual Authentication









  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 4]


  Internet-Draft                  EAP-EDHOC                 September 2023


  3.1.2.  Transport and Message Correlation

     EDHOC is not bound to a particular transport layer and can even be
     used in environments without IP.  Nonetheless, EDHOC specification
     has a set of requirements for its transport protocol
     [I-D.ietf-lake-edhoc].  These include handling message loss,
     reordering, duplication, fragmentation, demultiplex EDHOC messages
     from other types of messages, denial-of-service protection, and
     message correlation.  All these requirements are fulfilled either by
     the EAP protocol, EAP method or EAP lower layer, as specified in
     [RFC3748].

     For message loss, this can be either fulfilled by the EAP protocol or
     the EAP lower layer, as retransmissions can occur both in the lower
     layer and the EAP layer when EAP is run over a reliable lower layer.
     In other words, the EAP layer will do the retransmissions if the EAP
     lower layer cannot do it.

     For reordering, EAP is reliant on the EAP lower layer ordering
     guarantees for correct operation.

     For duplication and message correlation, EAP has the Identifier
     field, which provides both the peer and authenticator with the
     ability to detect duplicates and match a request with a response.

     Fragmentation is defined by this EAP method, see Section 3.1.6.  The
     EAP framework [RFC3748] specifies that EAP methods need to provide
     fragmentation and reassembly if EAP packets can exceed the minimum
     MTU of 1020 octets.

     To demultiplex EDHOC messages from other types of messages, EAP
     provides the Code field.

     This method does not provide other mitigation against denial-of-
     service than EAP [RFC3748].

  3.1.3.  Termination

     If the EAP-EDHOC peer authenticates successfully, the EAP-EDHOC
     server MUST send an EAP-Request packet with EAP-Type=EAP-EDHOC
     containing message_4 as a protected success indication.

     If the EAP-EDHOC server authenticates successfully, the EAP-EDHOC
     peer MUST send an EAP-Response message with EAP-Type=EAP-EDHOC
     containing no data.  Finally, the EAP-EDHOC server sends an EAP-
     Success.





  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 5]


  Internet-Draft                  EAP-EDHOC                 September 2023


     Figure 2, Figure 3 and Figure 4 illustrate message flows in several
     cases where the EAP-EDHOC peer or EAP-EDHOC server sends an EDHOC
     error message.

     Figure 2 shows an example message flow where the EAP-EDHOC server
     rejects message_1 with an EDHOC error message.

       EAP-EDHOC Peer                                   EAP-EDHOC Server

           |                           EAP-Request/Identity        |
           | <---------------------------------------------------- |
           |                                                       |
           |   EAP-Response/Identity (Privacy-Friendly)            |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                     (EDHOC Start)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_1)                                   |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                   (EDHOC error)       |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           | ----------------------------------------------------> |
           |                                                       |
           |                                        EAP-Failure    |
           | <---------------------------------------------------- |
           |                                                       |

               Figure 2: EAP-EDHOC Server rejection of message_1

     Figure 3 shows an example message flow where the EAP-EDHOC server
     authentication is unsuccessful and the EAP-EDHOC peer sends an EDHOC
     error message.












  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 6]


  Internet-Draft                  EAP-EDHOC                 September 2023


       EAP-EDHOC Peer                                   EAP-EDHOC Server

           |                           EAP-Request/Identity        |
           | <---------------------------------------------------- |
           |                                                       |
           |   EAP-Response/Identity (Privacy-Friendly)            |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                     (EDHOC Start)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_1)                                   |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                 (EDHOC message_2)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC error)                                       |
           | ----------------------------------------------------> |
           |                                        EAP-Failure    |
           | <---------------------------------------------------- |

                Figure 3: EAP-EDHOC Peer rejection of message_2

     Figure 4 shows an example message flow where the EAP-EDHOC server
     authenticates to the EAP-EDHOC peer successfully, but the EAP-EDHOC
     peer fails to authenticate to the EAP-EDHOC server and the server
     sends an EDHOC error message.



















  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 7]


  Internet-Draft                  EAP-EDHOC                 September 2023


       EAP-EDHOC Peer                                   EAP-EDHOC Server

           |                           EAP-Request/Identity        |
           | <---------------------------------------------------- |
           |                                                       |
           |   EAP-Response/Identity (Privacy-Friendly)            |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                     (EDHOC Start)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_1)                                   |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                 (EDHOC message_2)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_3)                                   |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                     (EDHOC error)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           | ----------------------------------------------------> |
           |                                                       |
           |                                        EAP-Failure    |
           | <---------------------------------------------------- |
           |                                                       |

               Figure 4: EAP-EDHOC Server rejection of message_3

     Figure 4 shows an example message flow where the EAP-EDHOC server
     sends the EDHOC message_4 to the EAP peer, but the success indication
     fails, and the peer sends an EDHOC error message.











  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 8]


  Internet-Draft                  EAP-EDHOC                 September 2023


       EAP-EDHOC Peer                                   EAP-EDHOC Server

           |                           EAP-Request/Identity        |
           | <---------------------------------------------------- |
           |                                                       |
           |   EAP-Response/Identity (Privacy-Friendly)            |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                     (EDHOC Start)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_1)                                   |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                 (EDHOC message_2)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_3)                                   |
           | ----------------------------------------------------> |
           |                                         EAP-Request/  |
           |                                   EAP-Type=EAP-EDHOC  |
           |                                    (EDHOC message_4)  |
           | <---------------------------------------------------  |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC error)                                       |
           | ----------------------------------------------------> |
           |                                        EAP-Failure    |
           | <---------------------------------------------------- |
           |                                                       |

                Figure 5: EAP-EDHOC Peer rejection of message_4

  3.1.4.  Identity

     It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity
     Response as such identities are routable and privacy-friendly.

     While opaque blobs are allowed by [RFC3748], such identities are NOT
     RECOMMENDED as they are not routable and should only be considered in
     local deployments where the EAP-EDHOC peer, EAP authenticator, and
     EAP-EDHOC server all belong to the same network.





  Ingles-Sanchez, et al.    Expires 15 March 2024                 [Page 9]


  Internet-Draft                  EAP-EDHOC                 September 2023


     Many client certificates contain an identity such as an email
     address, which is already in NAI format.  When the client certificate
     contains an NAI as subject name or alternative subject name, an
     anonymous NAI SHOULD be derived from the NAI in the certificate; See
     Section 3.1.5.

  3.1.5.  Privacy

     EAP-EDHOC peer and server implementations supporting EAP-EDHOC MUST
     support anonymous Network Access Identifiers (NAIs) (Section 2.4 of
     [RFC7542]).  A client supporting EAP-EDHOC MUST NOT send its username
     (or any other permanent identifiers) in cleartext in the Identity
     Response (or any message used instead of the Identity Response).
     Following [RFC7542], it is RECOMMENDED to omit the username (i.e.,
     the NAI is @realm), but other constructions such as a fixed username
     (e.g., anonymous@realm) or an encrypted username (e.g.,
     xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed.
     Note that the NAI MUST be a UTF-8 string as defined by the grammar in
     Section 2.2 of [RFC7542].

     EAP-EDHOC is always used with privacy.  This does not add any extra
     round trips and the message flow with privacy is just the normal
     message flow as shown in Figure 1.

  3.1.6.  Fragmentation

     EAP-EDHOC fragmentation support is provided through the addition of a
     flags octet within the EAP-Response and EAP-Request packets, as well
     as a (conditional) EAP-EDHOC Message Length field of four octets.  To
     do so, the EAP request and response messages of EAP-EDHOC have a set
     of information fields that allow for the specification of the
     fragmentation process (See Section 4 for the detailed description).
     Of these fields, we will highlight the one that contains the flag
     octet, which is used to steer the fragmentation process.  If the L
     bit is set, we are specifying that the next message will be
     fragmented and that in such a message we can also find the length of
     the message.

     Implementations MUST NOT set the L bit in unfragmented messages, but
     they MUST accept unfragmented messages with and without the L bit
     set.  Some EAP implementations and access networks may limit the
     number of EAP packet exchanges that can be handled.  To avoid
     fragmentation, it is RECOMMENDED to keep the sizes of EAP-EDHOC peer,
     EAP-EDHOC server, and trust anchor authentication credentials small
     and the length of the certificate chains short.  In addition, it is
     RECOMMENDED to use mechanisms that reduce the sizes of Certificate
     messages.




  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 10]


  Internet-Draft                  EAP-EDHOC                 September 2023


     EDHOC is designed to perform well in constrained networks where
     message sizes are restricted for performance reasons.  In the basic
     message construction, the size of plaintext in message_2 is limited
     to the length of the output of the key derivation function which in
     turn is decided by the EDHOC hash function.  For example, with
     SHA-256 as EDHOC hash algorithm the maximum size of plaintext in
     message_2 is 8160 bytes.  However, EDHOC also defines an optional
     backwards compatible method for handling arbitrarily long message_2
     plaintext sizes, see Appendix G in [I-D.ietf-lake-edhoc].  The other
     three EAP-EDHOC messages do not have an upper bound.

     Furthermore, in the case of sending a certificate in a message
     instead of a reference, a certificate may in principle be as long as
     16 MB.  Hence, the EAP-EDHOC messages sent in a single round may thus
     be larger than the MTU size or the maximum Remote Authentication
     Dial-In User Service (RADIUS) packet size of 4096 octets.  As a
     result, an EAP-EDHOC implementation MUST provide its own support for
     fragmentation and reassembly.

     Since EAP is a simple ACK-NAK protocol, fragmentation support can be
     added in a simple manner.  In EAP, fragments that are lost or damaged
     in transit will be retransmitted, and since sequencing information is
     provided by the Identifier field in EAP, there is no need for a
     fragment offset field as is provided in IPv4 EAP-EDHOC fragmentation
     support is provided through the addition of a flags octet within the
     EAP-Response and EAP-Request packets, as well as a EDHOC Message
     Length field of four octets.  Flags include the Length included (L),
     More fragments (M), and EAP-EDHOC Start (S) bits.  The L flag is set
     to indicate the presence of the four-octet EDHOC Message Length
     field, and MUST be set for the first fragment of a fragmented EDHOC
     message or set of messages.  The M flag is set on all but the last
     fragment.  The S flag is set only within the EAP-EDHOC start message
     sent from the EAP server to the peer.  The EDHOC Message Length field
     is four octets, and provides the total length of the EDHOC message or
     set of messages that is being fragmented; this simplifies buffer
     allocation.

     When an EAP-EDHOC peer receives an EAP-Request packet with the M bit
     set, it MUST respond with an EAP-Response with EAP-Type=EAP-EDHOC and
     no data.  This serves as a fragment ACK.  The EAP server MUST wait
     until it receives the EAP-Response before sending another fragment.
     In order to prevent errors in the processing of fragments, the EAP
     server MUST increment the Identifier field for each fragment
     contained within an EAP-Request, and the peer MUST include this
     Identifier value in the fragment ACK contained within the EAP-
     Response.  Retransmitted fragments will contain the same Identifier
     value.




  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 11]


  Internet-Draft                  EAP-EDHOC                 September 2023


     Similarly, when the EAP server receives an EAP-Response with the M
     bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-EDHOC
     and no data.  This serves as a fragment ACK.  The EAP peer MUST wait
     until it receives the EAP-Request before sending another fragment.
     In order to prevent errors in the processing of fragments, the EAP
     server MUST increment the Identifier value for each fragment ACK
     contained within an EAP-Request, and the peer MUST include this
     Identifier value in the subsequent fragment contained within an EAP-
     Response.

     In the case where the EAP-EDHOC mutual authentication is successful,
     and fragmentation is required, the conversation will appear as
     follows:

       EAP-EDHOC Peer                                   EAP-EDHOC Server

           |                               EAP-Request/Identity    |
           | <---------------------------------------------------- |
           |   EAP-Response/Identity (Privacy-Friendly)            |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                          (EDHOC Start, S bit set)     |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_1)                                   |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                 (EDHOC message_2,     |
           |                          Fragment 1: L,M bits set)    |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                           (Fragment 2: M bits set)    |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           | ----------------------------------------------------> |
           |                                      EAP-Request/     |
           |                                EAP-Type=EAP-EDHOC     |
           |                                       (Fragment 3)    |
           | <---------------------------------------------------- |
           |   EAP-Response/                                       |



  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 12]


  Internet-Draft                  EAP-EDHOC                 September 2023


           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_3,                                   |
           |    Fragment 1: L,M bits set)                          |
           | ----------------------------------------------------> |
           |                                         EAP-Request/  |
           |                                   EAP-Type=EAP-EDHOC  |
           | <---------------------------------------------------  |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_3,                                   |
           |    Fragment 2: M bits set)                            |
           | ----------------------------------------------------> |
           |                                         EAP-Request/  |
           |                                   EAP-Type=EAP-EDHOC  |
           | <---------------------------------------------------  |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |   (EDHOC message_3,                                   |
           |    Fragment 3)                                        |
           | ----------------------------------------------------> |
           |                                         EAP-Request/  |
           |                                   EAP-Type=EAP-EDHOC  |
           |                                    (EDHOC message_4)  |
           | <---------------------------------------------------  |
           |   EAP-Response/                                       |
           |   EAP-Type=EAP-EDHOC                                  |
           |  ---------------------------------------------------> |
           |                                        EAP-Success    |
           | <---------------------------------------------------  |
           +                                                       +

          Figure 6: Fragmentation example of EAP-EDHOC Authentication

  3.2.  Identity Verification

     The EAP peer identity provided in the EAP-Response/Identity is not
     authenticated by EAP-EDHOC.  Unauthenticated information MUST NOT be
     used for accounting purposes or to give authorization.  The
     authenticator and the EAP-EDHOC server MAY examine the identity
     presented in EAP-Response/Identity for purposes such as routing and
     EAP method selection.  EAP-EDHOC servers MAY reject conversations if
     the identity does not match their policy.

     The EAP server identity in the EDHOC server certificate is typically
     a fully qualified domain name (FQDN) in the SubjectAltName (SAN)
     extension.  Since EAP-EDHOC deployments may use more than one EAP
     server, each with a different certificate, EAP peer implementations
     SHOULD allow for the configuration of one or more trusted root



  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 13]


  Internet-Draft                  EAP-EDHOC                 September 2023


     certificates (CA certificate) to authenticate the server certificate
     and one or more server names to match against the SubjectAltName
     (SAN) extension in the server certificate.  If any of the configured
     names match any of the names in the SAN extension, then the name
     check passes.  To simplify name matching, an EAP-EDHOC deployment can
     assign a name to represent an authorized EAP server and EAP Server
     certificates can include this name in the list of SANs for each
     certificate that represents an EAP-EDHOC server.  If server name
     matching is not used, then it degrades the confidence that the EAP
     server with which it is interacting is authoritative for the given
     network.  If name matching is not used with a public root CA, then
     effectively any server can obtain a certificate that will be trusted
     for EAP authentication by the peer.

     The process of configuring a root CA certificate and a server name is
     non-trivial; therefore, automated methods of provisioning are
     RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
     a Configuration Assistant Tool (CAT) to automate the configuration
     process.  In the absence of a trusted root CA certificate (user-
     configured or system-wide), EAP peers MAY implement a trust on first
     use (TOFU) mechanism where the peer trusts and stores the server
     certificate during the first connection attempt.  The EAP peer
     ensures that the server presents the same stored certificate on
     subsequent interactions.  The use of a TOFU mechanism does not allow
     for the server certificate to change without out-of-band validation
     of the certificate and is therefore not suitable for many deployments
     including ones where multiple EAP servers are deployed for high
     availability.  TOFU mechanisms increase the susceptibility to traffic
     interception attacks and should only be used if there are adequate
     controls in place to mitigate this risk.

  3.3.  Key Hierarchy

     The key schedule for EDHOC is described in Section 4 of
     [I-D.ietf-lake-edhoc].  The Key_Material and Method-Id SHALL be
     derived from the PRK_exporter using the EDHOC-Exporter interface, see
     Section 4.2.1 of [I-D.ietf-lake-edhoc].

     Type is the value of the EAP Type field defined in Section 2 of
     [RFC3748].  For EAP-EDHOC, the Type field has the value TBD1.

     Type        =  TBD1
     MSK         =  EDHOC-Exporter(TBD2 ,<< Type >>, 64)
     EMSK        =  EDHOC-Exporter(TBD3 ,<< Type >>, 64)
     Method-Id   =  EDHOC-Exporter(TBD4, << Type >>, 64)
     Session-Id  =  Type || Method-Id





  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 14]


  Internet-Draft                  EAP-EDHOC                 September 2023


     EAP-EDHOC exports the MSK and the EMSK and does not specify how it is
     used by lower layers.

  3.4.  Parameter Negotiation and Compliance Requirements

     The EAP-EDHOC peers and EAP-EDHOC servers MUST comply with the
     compliance requirements (mandatory-to-implement cipher suites,
     signature algorithms, key exchange algorithms, extensions, etc.)
     defined in Section 7 of [I-D.ietf-lake-edhoc].

  3.5.  EAP State Machines

     The EAP-EDHOC server sends message_4 in an EAP-Request as a protected
     success result indication.

     EDHOC error messages SHOULD be considered failure result indication,
     as defined in [RFC3748].  After sending or receiving an EDHOC error
     message, the EAP-EDHOC server may only send an EAP-Failure.  EDHOC
     error messages are unprotected.

     The keying material can be derived after the EDHOC message_2 has been
     sent or received.  Implementations following [RFC4137] can then set
     the eapKeyData and aaaEapKeyData variables.

     The keying material can be made available to lower layers and the
     authenticator after the authenticated success result indication has
     been sent or received (message_4).  Implementations following
     [RFC4137] can set the eapKeyAvailable and aaaEapKeyAvailable
     variables.

  4.  Detailed Description of the EAP-EDHOC Protocol

  4.1.  EAP-EDHOC Request Packet

     A summary of the EAP-EDHOC Request packet format is shown below.  The
     fields are transmitted from left to right.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Code      |   Identifier  |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Flags     |      EDHOC Message Length
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   EDHOC Message Length        |       EDHOC Data...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Code



  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 15]


  Internet-Draft                  EAP-EDHOC                 September 2023


       1

     Identifier

       The Identifier field is one octet and aids in matching responses
       with requests.  The Identifier field MUST be changed on each
       Request packet.

     Length

       The Length field is two octets and indicates the length of the EAP
       packet including the Code, Identifier, Length, Type, and Data
       fields.  Octets outside the range of the Length field should be
       treated as Data Link Layer padding and MUST be ignored on
       reception.

     Type

       TBD1 -- EAP-EDHOC

     Flags

       0 1 2 3 4 5 6 7 8
       +-+-+-+-+-+-+-+-+
       |L M S R R R R R|
       +-+-+-+-+-+-+-+-+

       L = Length included
       M = More fragments
       S = EAP-EDHOC start
       R = Reserved

       The L bit (length included) is set to indicate the presence of the
       four-octet EDHOC Message Length field and MUST be set for the first
       fragment of a fragmented EDHOC message or set of messages.  The M
       bit (more fragments) is set on all but the last fragment.  The S
       bit (EAP-EDHOC start) is set in an EAP-EDHOC Start message.  This
       differentiates the EAP-EDHOC Start message from a fragment
       acknowledgement.  Implementations of this specification MUST set
       the reserved bits to zero and MUST ignore them on reception.

     EDHOC Message Length

       The EDHOC Message Length field is four octets and is present only
       if the L bit is set.  This field provides the total length of the
       EDHOC message or set of messages that is being fragmented.

     EDHOC data



  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 16]


  Internet-Draft                  EAP-EDHOC                 September 2023


       The EDHOC data consists of the encapsulated EDHOC packet in EDHOC
       message format.

  4.2.  EAP-EDHOC Response Packet

     A summary of the EAP-EDHOC Response packet format is shown below.
     The fields are transmitted from left to right.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Code      |   Identifier  |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Flags     |      EDHOC Message Length
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   EDHOC Message Length        |       EDHOC Data...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Code

       2

     Identifier

       The Identifier field is one octet and MUST match the Identifier
       field from the corresponding request.

     Length

       The Length field is two octets and indicates the length of the EAP
       packet including the Code, Identifier, Length, Type, and Data
       fields.  Octets outside the range of the Length field should be
       treated as Data Link Layer padding and MUST be ignored on
       reception.

     Type

       TBD1 -- EAP-EDHOC

     Flags











  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 17]


  Internet-Draft                  EAP-EDHOC                 September 2023


       0 1 2 3 4 5 6 7 8
       +-+-+-+-+-+-+-+-+
       |L M R R R R R R|
       +-+-+-+-+-+-+-+-+

       L = Length included
       M = More fragments
       R = Reserved

       The L bit (length included) is set to indicate the presence of the
       four-octet EDHOC Message Length field,
       and MUST be set for the first
       fragment of a fragmented EDHOC message or set of messages.  The M
       bit (more fragments) is set on all but the last fragment.
       Implementations of this specification MUST set the reserved bits
       to zero and MUST ignore them on reception.

     EDHOC Message Length

       The EDHOC Message Length field is four octets and is present only
       if the L bit is set.  This field provides the total length of the
       EDHOC message or set of messages that is being fragmented.

     EDHOC data

       The EDHOC data consists of the encapsulated EDHOC message.

  5.  IANA Considerations

  5.1.  EAP Type

     IANA has allocated EAP Type TBD1 for method EAP-EDHOC.  The
     allocation has been updated to reference this document.

  5.2.  EDHOC Exporter Label Registry

     IANA has registered the following new labels in the "EDHOC Exporter
     Label" registry under the group name "Ephemeral Diffie-Hellman Over
     COSE (EDHOC)":

     Label: TBD2
     Description: MSK of EAP method EAP-EDHOC

     Label: TBD3
     Description: EMSK of EAP method EAP-EDHOC

     Label: TBD4
     Description: Method-Id of EAP method EAP-EDHOC



  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 18]


  Internet-Draft                  EAP-EDHOC                 September 2023


     The allocations have been updated to reference this document.

  6.  Security Considerations

     TBD.

     [Editor's note: More security considerations to be added.]

  6.1.  Security Claims

     Using EAP-EDHOC provides the security claims of EDHOC, which are
     described next.

     [1] Mutual authentication: The initiator and responder authenticate
     each other through the EDHOC exchange.

     [2] Forward secrecy: Only ephemeral Diffie-Hellman methods are
     supported by EDHOC, which ensures that the compromise of one session
     key does not also compromise earlier sessions' keys.

     [3] Identity protection: EDHOC secures the Responder's credential
     identifier against passive attacks and the Initiator's credential
     identifier against active 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.

     [4] Cipher suite negotiation: The Initiator's list of supported
     cipher suites and order of preference is fixed and the selected
     cipher suite is the first cipher suite that the Responder supports.

     [5] Integrity protection: EDHOC integrity protects all message
     content using transcript hashes for key derivation and as additional
     authenticated data, including, e.g., method type, ciphersuites, and
     external authorization data.

  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-22, 25
                August 2023, <https://datatracker.ietf.org/doc/html/draft-
                ietf-lake-edhoc-22>.





  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 19]


  Internet-Draft                  EAP-EDHOC                 September 2023


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

     [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
                Levkowetz, Ed., "Extensible Authentication Protocol
                (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
                <https://www.rfc-editor.org/info/rfc3748>.

     [RFC4137]  Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
                "State Machines for Extensible Authentication Protocol
                (EAP) Peer and Authenticator", RFC 4137,
                DOI 10.17487/RFC4137, August 2005,
                <https://www.rfc-editor.org/info/rfc4137>.

     [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
                DOI 10.17487/RFC7542, May 2015,
                <https://www.rfc-editor.org/info/rfc7542>.

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

  7.2.  Informative References

     [I-D.ietf-core-oscore-edhoc]
                Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
                G. Selander, "Using EDHOC with CoAP and OSCORE", Work in
                Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-08,
                8 August 2023, <https://datatracker.ietf.org/doc/html/
                draft-ietf-core-oscore-edhoc-08>.

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

     [RFC7593]  Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
                Architecture for Network Roaming", RFC 7593,
                DOI 10.17487/RFC7593, September 2015,
                <https://www.rfc-editor.org/info/rfc7593>.

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





  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 20]


  Internet-Draft                  EAP-EDHOC                 September 2023


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

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

  Acknowledgments

     Work on this document has in part been supported by the H2020
     Projects IoTCrawler (grant agreement no. 779852) and INSPIRE-5Gplus
     (grant agreement no. 871808).

  Authors' Addresses

     Eduardo Ingles-Sanchez
     University of Murcia
     Murcia 30100
     Spain
     Email: eduardo.ingles@um.es


     Dan Garcia-Carrillo
     University of Oviedo
     Gijon, Asturias 33203
     Spain
     Email: garciadan@uniovi.es


     Rafael Marin-Lopez
     University of Murcia
     Murcia 30100
     Spain
     Email: rafa@um.es


     Göran Selander
     Ericsson
     SE-164 80 Stockholm
     Sweden
     Email: goran.selander@ericsson.com







  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 21]


  Internet-Draft                  EAP-EDHOC                 September 2023


     John Preuß Mattsson
     Ericsson
     SE-164 80 Stockholm
     Sweden
     Email: john.mattsson@ericsson.com














































  Ingles-Sanchez, et al.    Expires 15 March 2024                [Page 22]


name: draft-ietf-lake-traces
rev: 09
title: Traces of EDHOC
abstract:
  This document contains some example traces of Ephemeral Diffie-
  Hellman Over COSE (EDHOC).

time: 2024-03-21T01:58:07Z
group_uri: /api/v1/group/group/2249/
expires: 2024-07-30T14:20:56Z
ad: /api/v1/person/person/112723/
shepherd: /api/v1/person/email/stephen.farrell@cs.tcd.ie/
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:05.684325+00:00
source: ietf
states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/110/", "/api/v1/doc/state/113/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  LAKE Working Group                                           G. Selander
  Internet-Draft                                         J. Preuß Mattsson
  Intended status: Informational                                  Ericsson
  Expires: 30 July 2024                                         M. Serafin
                                                                ASSA ABLOY
                                                                 M. Tiloca
                                                                      RISE
                                                                M. Vučinić
                                                                     Inria
                                                           27 January 2024


                              Traces of EDHOC
                         draft-ietf-lake-traces-09

  Abstract

     This document contains some example traces of Ephemeral Diffie-
     Hellman Over COSE (EDHOC).

  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 30 July 2024.

  Copyright Notice

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










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


  Internet-Draft               Traces of EDHOC                January 2024


     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
       1.1.  Setup . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Terminology and Requirements Language . . . . . . . . . .   4
     2.  Authentication with Signatures, X.509 Certificates Identified
             by 'x5t'  . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  message_1 . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.2.  message_2 . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.3.  message_3 . . . . . . . . . . . . . . . . . . . . . . . .  14
       2.4.  message_4 . . . . . . . . . . . . . . . . . . . . . . . .  23
       2.5.  PRK_out and PRK_exporter  . . . . . . . . . . . . . . . .  25
       2.6.  OSCORE Parameters . . . . . . . . . . . . . . . . . . . .  26
       2.7.  Key Update  . . . . . . . . . . . . . . . . . . . . . . .  28
       2.8.  Certificates  . . . . . . . . . . . . . . . . . . . . . .  29
     3.  Authentication with Static DH, CCS Identified by 'kid'  . . .  31
       3.1.  message_1 (first time)  . . . . . . . . . . . . . . . . .  32
       3.2.  error . . . . . . . . . . . . . . . . . . . . . . . . . .  33
       3.3.  message_1 (second time) . . . . . . . . . . . . . . . . .  33
       3.4.  message_2 . . . . . . . . . . . . . . . . . . . . . . . .  35
       3.5.  message_3 . . . . . . . . . . . . . . . . . . . . . . . .  42
       3.6.  message_4 . . . . . . . . . . . . . . . . . . . . . . . .  49
       3.7.  PRK_out and PRK_exporter  . . . . . . . . . . . . . . . .  51
       3.8.  OSCORE Parameters . . . . . . . . . . . . . . . . . . . .  53
       3.9.  Key Update  . . . . . . . . . . . . . . . . . . . . . . .  54
     4.  Invalid Traces  . . . . . . . . . . . . . . . . . . . . . . .  56
       4.1.  Encoding Errors . . . . . . . . . . . . . . . . . . . . .  56
       4.2.  Crypto-related Errors . . . . . . . . . . . . . . . . . .  57
       4.3.  Non-deterministic CBOR  . . . . . . . . . . . . . . . . .  59
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  59
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  59
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  59
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  59
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  60
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  61
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  61






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


  Internet-Draft               Traces of EDHOC                January 2024


  1.  Introduction

     EDHOC [I-D.ietf-lake-edhoc] is a lightweight authenticated key
     exchange protocol designed for highly constrained settings.  This
     document contains annotated traces of EDHOC sessions, with input,
     output, and intermediate processing results to simplify testing of
     implementations.  The traces have been verified by two independent
     implementations.

  1.1.  Setup

     EDHOC is run between an Initiator (I) and a Responder (R).  The
     private/public key pairs and credentials of the Initiator and the
     Responder required to produce the protocol messages are shown in the
     traces when needed for the calculations.

     EDHOC messages and intermediate results are encoded in CBOR [RFC8949]
     and can therefore be displayed in CBOR diagnostic notation using,
     e.g., the CBOR playground [CborMe], which makes them easy to parse
     for humans.  Credentials can also be encoded in CBOR, e.g.  CBOR Web
     Tokens (CWT) [RFC8392].

     The document contains two traces:

     *  Section 2 - Authentication with signature keys identified by the
        hash value of the X.509 certificates (provided in Section 2.8).
        The endpoints use EdDSA [RFC8032] for authentication and X25519
        [RFC7748] for ephemeral-ephemeral Diffie-Hellman key exchange.

     *  Section 3 - Authentication with static Diffie-Hellman keys
        identified by short key identifiers labelling CWT Claim Sets
        (CCSs) [RFC8392].  The endpoints use NIST P-256 [SP-800-186] for
        both ephemeral-ephemeral and static-ephemeral Diffie-Hellman key
        exchange.  This trace also illustrates the cipher suite
        negotiation, and provides an example of low protocol overhead,
        with messages sizes of (39, 45, 19) bytes.

     Examples of invalid EDHOC messages are found in Section 4.

     NOTE 1.  The same name is used for hexadecimal byte strings and their
     CBOR encodings.  The traces contain both the raw byte strings and the
     corresponding CBOR encoded data items.

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






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


  Internet-Draft               Traces of EDHOC                January 2024


     NOTE 3.  When the protocol transporting EDHOC messages does not
     inherently provide correlation across all messages, like CoAP
     [RFC7252], then some messages typically are prepended with connection
     identifiers and potentially a message_1 indicator (see Sections 3.4.1
     and A.2 of [I-D.ietf-lake-edhoc]).  Those bytes are not included in
     the traces in this document.

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

  2.  Authentication with Signatures, X.509 Certificates Identified by
      'x5t'

     In this example the Initiator (I) and Responder (R) are authenticated
     with digital signatures (METHOD = 0).  Both the Initiator and the
     Responder support cipher suite 0, which determines the algorithms:

     *  EDHOC AEAD algorithm = AES-CCM-16-64-128

     *  EDHOC hash algorithm = SHA-256

     *  EDHOC MAC length in bytes (Static DH) = 8

     *  EDHOC key exchange algorithm (ECDH curve) = X25519

     *  EDHOC signature algorithm = EdDSA

     *  Application AEAD algorithm = AES-CCM-16-64-128

     *  Application hash algorithm = SHA-256

     The public keys are represented with X.509 certificates identified by
     the COSE header parameter 'x5t'.

  2.1.  message_1

     Both endpoints are authenticated with signatures, i.e., METHOD = 0:

     METHOD (CBOR Data Item) (1 byte)
     00

     The Initiator selects cipher suite 0.  A single cipher suite is
     encoded as an int:



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


  Internet-Draft               Traces of EDHOC                January 2024


     SUITES_I (CBOR Data Item) (1 byte)
     00

     The Initiator creates an ephemeral key pair for use with the EDHOC
     key exchange algorithm:

     Initiator's ephemeral private key
     X (Raw Value) (32 bytes)
     89 2e c2 8e 5c b6 66 91 08 47 05 39 50 0b 70 5e 60 d0 08 d3 47 c5 81
     7e e9 f3 32 7c 8a 87 bb 03

     Initiator's ephemeral public key
     G_X (Raw Value) (32 bytes)
     31 f8 2c 7b 5b 9c bb f0 f1 94 d9 13 cc 12 ef 15 32 d3 28 ef 32 63 2a
     48 81 a1 c0 70 1e 23 7f 04

     Initiator's ephemeral public key
     G_X (CBOR Data Item) (34 bytes)
     58 20 31 f8 2c 7b 5b 9c bb f0 f1 94 d9 13 cc 12 ef 15 32 d3 28 ef 32
     63 2a 48 81 a1 c0 70 1e 23 7f 04

     The Initiator selects its connection identifier C_I to be the byte
     string 0x2d, which since it is represented by the 1-byte CBOR int -14
     is encoded as 0x2d:

     Connection identifier chosen by Initiator
     C_I (Raw Value) (1 byte)
     2d

     Connection identifier chosen by Initiator
     C_I (CBOR Data Item) (1 byte)
     2d

     No external authorization data:

     EAD_1 (CBOR Sequence) (0 bytes)

     The Initiator constructs message_1:

     message_1 =
     (
      0,
      0,
      h'31f82c7b5b9cbbf0f194d913cc12ef1532d328ef32632a48
        81a1c0701e237f04',
      -14
     )




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


  Internet-Draft               Traces of EDHOC                January 2024


     message_1 (CBOR Sequence) (37 bytes)
     00 00 58 20 31 f8 2c 7b 5b 9c bb f0 f1 94 d9 13 cc 12 ef 15 32 d3 28
     ef 32 63 2a 48 81 a1 c0 70 1e 23 7f 04 2d

  2.2.  message_2

     The Responder supports the most preferred and selected cipher suite
     0, so SUITES_I is acceptable.

     The Responder creates an ephemeral key pair for use with the EDHOC
     key exchange algorithm:

     Responder's ephemeral private key
     Y (Raw Value) (32 bytes)
     e6 9c 23 fb f8 1b c4 35 94 24 46 83 7f e8 27 bf 20 6c 8f a1 0a 39 db
     47 44 9e 5a 81 34 21 e1 e8

     Responder's ephemeral public key
     G_Y (Raw Value) (32 bytes)
     dc 88 d2 d5 1d a5 ed 67 fc 46 16 35 6b c8 ca 74 ef 9e be 8b 38 7e 62
     3a 36 0b a4 80 b9 b2 9d 1c

     Responder's ephemeral public key
     G_Y (CBOR Data Item) (34 bytes)
     58 20 dc 88 d2 d5 1d a5 ed 67 fc 46 16 35 6b c8 ca 74 ef 9e be 8b 38
     7e 62 3a 36 0b a4 80 b9 b2 9d 1c

     The Responder selects its connection identifier C_R to be the byte
     string 0x18, which since it is not represented as a 1-byte CBOR int
     is encoded as h'18' = 0x4118:

     Connection identifier chosen by Responder
     C_R (Raw Value) (1 byte)
     18

     Connection identifier chosen by Responder
     C_R (CBOR Data Item) (2 bytes)
     41 18

     The transcript hash TH_2 is calculated using the EDHOC hash
     algorithm:

     TH_2 = H( G_Y, H(message_1) )

     H(message_1) (Raw Value) (32 bytes)
     c1 65 d6 a9 9d 1b ca fa ac 8d bf 2b 35 2a 6f 7d 71 a3 0b 43 9c 9d 64
     d3 49 a2 38 48 03 8e d1 6b




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


  Internet-Draft               Traces of EDHOC                January 2024


     H(message_1) (CBOR Data Item) (34 bytes)
     58 20 c1 65 d6 a9 9d 1b ca fa ac 8d bf 2b 35 2a 6f 7d 71 a3 0b 43 9c
     9d 64 d3 49 a2 38 48 03 8e d1 6b

     The input to calculate TH_2 is the CBOR sequence:

     G_Y, H(message_1)

     Input to calculate TH_2 (CBOR Sequence) (68 bytes)
     58 20 dc 88 d2 d5 1d a5 ed 67 fc 46 16 35 6b c8 ca 74 ef 9e be 8b 38
     7e 62 3a 36 0b a4 80 b9 b2 9d 1c 58 20 c1 65 d6 a9 9d 1b ca fa ac 8d
     bf 2b 35 2a 6f 7d 71 a3 0b 43 9c 9d 64 d3 49 a2 38 48 03 8e d1 6b

     TH_2 (Raw Value) (32 bytes)
     c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a
     06 52 ca e6 6c 90 61 68 8d

     TH_2 (CBOR Data Item) (34 bytes)
     58 20 c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a
     79 6a 06 52 ca e6 6c 90 61 68 8d

     PRK_2e is specified in Section 4.1.1.1 of [I-D.ietf-lake-edhoc].

     First, the ECDH shared secret G_XY is computed from G_X and Y, or G_Y
     and X:

     G_XY (Raw Value) (ECDH shared secret) (32 bytes)
     e5 cd f3 a9 86 cd ac 5b 7b f0 46 91 e2 b0 7c 08 e7 1f 53 99 8d 8f 84
     2b 7c 3f b4 d8 39 cf 7b 28

     Then, PRK_2e is calculated using EDHOC_Extract() determined by the
     EDHOC hash algorithm:

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

     where salt is TH_2:

     salt (Raw Value) (32 bytes)
     c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a
     06 52 ca e6 6c 90 61 68 8d

     PRK_2e (Raw Value) (32 bytes)
     d5 84 ac 2e 5d ad 5a 77 d1 4b 53 eb e7 2e f1 d5 da a8 86 0d 39 93 73
     bf 2c 24 0a fa 7b a8 04 da






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


  Internet-Draft               Traces of EDHOC                January 2024


     Since METHOD = 0, the Responder authenticates using signatures.
     Since the selected cipher suite is 0, the EDHOC signature algorithm
     is EdDSA.

     The Responder's signature key pair using EdDSA:

     Responder's private authentication key
     SK_R (Raw Value) (32 bytes)
     ef 14 0f f9 00 b0 ab 03 f0 c0 8d 87 9c bb d4 b3 1e a7 1e 6e 7e e7 ff
     cb 7e 79 55 77 7a 33 27 99

     Responder's public authentication key
     PK_R (Raw Value) (32 bytes)
     a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62
     c0 0b 3a c5 5d e9 2f 93 59

     PRK_3e2m is specified in Section 4.1.1.2 of [I-D.ietf-lake-edhoc].

     Since the Responder authenticates with signatures PRK_3e2m = PRK_2e.

     PRK_3e2m (Raw Value) (32 bytes)
     d5 84 ac 2e 5d ad 5a 77 d1 4b 53 eb e7 2e f1 d5 da a8 86 0d 39 93 73
     bf 2c 24 0a fa 7b a8 04 da

     The Responder constructs the remaining input needed to calculate
     MAC_2:

     MAC_2 = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 )

     context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>

     CRED_R is identified by a 64-bit hash:

     ID_CRED_R =
     {
       34 : [-15, h'79f2a41b510c1f9b']
     }

     where the COSE header value 34 ('x5t') indicates a hash of an X.509
     certficate, and the COSE algorithm -15 indicates the hash algorithm
     SHA-256 truncated to 64 bits.

     ID_CRED_R (CBOR Data Item) (14 bytes)
     a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b

     CRED_R is a CBOR byte string of the DER encoding of the X.509
     certificate in Section 2.8.1:




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


  Internet-Draft               Traces of EDHOC                January 2024


     CRED_R (Raw Value) (241 bytes)
     30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 30 05 06 03 2b 65
     70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f 6f
     74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 34
     33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 30
     1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 70 6f 6e 64 65 72
     20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 a1 db 47
     b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62 c0 0b 3a
     c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 23 bc 01 ea b0 92
     8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 47 8f ec fa f1 45
     37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 65 d8 6d
     ce 51 cf ae 52 ab 82 c1 52 cb 02

     CRED_R (CBOR Data Item) (243 bytes)
     58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 30 05 06 03
     2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52
     6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38
     32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31
     20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 70 6f 6e 64
     65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 a1
     db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62 c0
     0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 23 bc 01 ea
     b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 47 8f ec fa
     f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 65
     d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02

     No external authorization data:

     EAD_2 (CBOR Sequence) (0 bytes)

     context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>

     context_2 (CBOR Sequence) (293 bytes)
     41 18 a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b 58 20 c6 40 5c 15 4c
     56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a 06 52 ca e6 6c
     90 61 68 8d 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4
     30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48
     4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33
     31 36 30 38 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30
     5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73
     70 6f 6e 64 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70
     03 21 00 a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0
     f2 c6 62 c0 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7
     23 bc 01 ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32
     47 8f ec fa f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a
     bc 94 95 65 d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02





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


  Internet-Draft               Traces of EDHOC                January 2024


     context_2 (CBOR byte string) (296 bytes)
     59 01 25 41 18 a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b 58 20 c6 40
     5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a 06 52
     ca e6 6c 90 61 68 8d 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62
     31 9e c4 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12
     45 44 48 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32
     32 30 33 31 36 30 38 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30
     30 30 30 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20
     52 65 73 70 6f 6e 64 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03
     2b 65 70 03 21 00 a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac
     e3 3a a0 f2 c6 62 c0 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03
     41 00 b7 23 bc 01 ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69
     87 b0 32 47 8f ec fa f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18
     37 eb 4a bc 94 95 65 d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02

     MAC_2 is computed through EDHOC_Expand() using the EDHOC hash
     algorithm, see Section 4.1.2 of [I-D.ietf-lake-edhoc]:

     MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2), where

     info = ( 2, context_2, mac_length_2 )

     Since METHOD = 0, mac_length_2 is given by the EDHOC hash algorithm.

     info for MAC_2 is:

     info =
     (
      2,
      h'4118a11822822e4879f2a41b510c1f9b5820c6405c154c56
        7466ab1df20369500e540e9f14bd3a796a0652cae66c9061
        688d58f13081ee3081a1a003020102020462319ec4300506
        032b6570301d311b301906035504030c124544484f432052
        6f6f742045643235353139301e170d323230333136303832
        3433365a170d3239313233313233303030305a3022312030
        1e06035504030c174544484f4320526573706f6e64657220
        45643235353139302a300506032b6570032100a1db47b951
        84854ad12a0c1a354e418aace33aa0f2c662c00b3ac55de9
        2f9359300506032b6570034100b723bc01eab0928e8b2b6c
        98de19cc3823d46e7d6987b032478fecfaf14537a1af14cc
        8be829c6b73044101837eb4abc949565d86dce51cfae52ab
        82c152cb02',
      32
     )

     where the last value is the output size of the EDHOC hash algorithm
     in bytes.




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


  Internet-Draft               Traces of EDHOC                January 2024


     info for MAC_2 (CBOR Sequence) (299 bytes)
     02 59 01 25 41 18 a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b 58 20 c6
     40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a 79 6a 06
     52 ca e6 6c 90 61 68 8d 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04
     62 31 9e c4 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c
     12 45 44 48 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d
     32 32 30 33 31 36 30 38 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33
     30 30 30 30 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43
     20 52 65 73 70 6f 6e 64 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06
     03 2b 65 70 03 21 00 a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a
     ac e3 3a a0 f2 c6 62 c0 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70
     03 41 00 b7 23 bc 01 ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d
     69 87 b0 32 47 8f ec fa f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10
     18 37 eb 4a bc 94 95 65 d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02 18 20

     MAC_2 (Raw Value) (32 bytes)
     86 2a 7e 5e f1 47 f9 a5 f4 c5 12 e1 b6 62 3c d6 6c d1 7a 72 72 07 2b
     fe 5b 60 2f fe 30 7e e0 e9

     MAC_2 (CBOR Data Item) (34 bytes)
     58 20 86 2a 7e 5e f1 47 f9 a5 f4 c5 12 e1 b6 62 3c d6 6c d1 7a 72 72
     07 2b fe 5b 60 2f fe 30 7e e0 e9

     Since METHOD = 0, Signature_or_MAC_2 is the 'signature' of the
     COSE_Sign1 object.

     The Responder constructs the message to be signed:
























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


  Internet-Draft               Traces of EDHOC                January 2024


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

     [
      "Signature1",
      h'a11822822e4879f2a41b510c1f9b',
      h'5820c6405c154c567466ab1df20369500e540e9f14bd3a79
        6a0652cae66c9061688d58f13081ee3081a1a00302010202
        0462319ec4300506032b6570301d311b301906035504030c
        124544484f4320526f6f742045643235353139301e170d32
        32303331363038323433365a170d32393132333132333030
        30305a30223120301e06035504030c174544484f43205265
        73706f6e6465722045643235353139302a300506032b6570
        032100a1db47b95184854ad12a0c1a354e418aace33aa0f2
        c662c00b3ac55de92f9359300506032b6570034100b723bc
        01eab0928e8b2b6c98de19cc3823d46e7d6987b032478fec
        faf14537a1af14cc8be829c6b73044101837eb4abc949565
        d86dce51cfae52ab82c152cb02',
      h'862a7e5ef147f9a5f4c512e1b6623cd66cd17a7272072bfe
        5b602ffe307ee0e9'
     ]

     Message to be signed 2 (CBOR Data Item) (341 bytes)
     84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 79 f2 a4 1b
     51 0c 1f 9b 59 01 15 58 20 c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50
     0e 54 0e 9f 14 bd 3a 79 6a 06 52 ca e6 6c 90 61 68 8d 58 f1 30 81 ee
     30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 30 05 06 03 2b 65 70 30 1d
     31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f 6f 74 20 45
     64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 34 33 36 5a
     17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 30 1e 06 03
     55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 70 6f 6e 64 65 72 20 45 64
     32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 a1 db 47 b9 51 84
     85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62 c0 0b 3a c5 5d e9
     2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 23 bc 01 ea b0 92 8e 8b 2b
     6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 47 8f ec fa f1 45 37 a1 af
     14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 65 d8 6d ce 51 cf
     ae 52 ab 82 c1 52 cb 02 58 20 86 2a 7e 5e f1 47 f9 a5 f4 c5 12 e1 b6
     62 3c d6 6c d1 7a 72 72 07 2b fe 5b 60 2f fe 30 7e e0 e9

     The Responder signs using the private authentication key SK_R

     Signature_or_MAC_2 (Raw Value) (64 bytes)
     c3 b5 bd 44 d1 e4 4a 08 5c 03 d3 ae de 4e 1e 6c 11 c5 72 a1 96 8c c3
     62 9b 50 5f 98 c6 81 60 8d 3d 1d e7 93 d1 c4 0e b5 dd 5d 89 ac f1 96
     6a ea 07 02 2b 48 cd c9 98 70 eb c4 03 74 e8 fa 6e 09






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


  Internet-Draft               Traces of EDHOC                January 2024


     Signature_or_MAC_2 (CBOR Data Item) (66 bytes)
     58 40 c3 b5 bd 44 d1 e4 4a 08 5c 03 d3 ae de 4e 1e 6c 11 c5 72 a1 96
     8c c3 62 9b 50 5f 98 c6 81 60 8d 3d 1d e7 93 d1 c4 0e b5 dd 5d 89 ac
     f1 96 6a ea 07 02 2b 48 cd c9 98 70 eb c4 03 74 e8 fa 6e 09

     The Responder constructs PLAINTEXT_2:

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

     PLAINTEXT_2 (CBOR Sequence) (82 bytes)
     41 18 a1 18 22 82 2e 48 79 f2 a4 1b 51 0c 1f 9b 58 40 c3 b5 bd 44 d1
     e4 4a 08 5c 03 d3 ae de 4e 1e 6c 11 c5 72 a1 96 8c c3 62 9b 50 5f 98
     c6 81 60 8d 3d 1d e7 93 d1 c4 0e b5 dd 5d 89 ac f1 96 6a ea 07 02 2b
     48 cd c9 98 70 eb c4 03 74 e8 fa 6e 09

     The input needed to calculate KEYSTREAM_2 is defined in Section 4.1.2
     of [I-D.ietf-lake-edhoc], using EDHOC_Expand() with the EDHOC hash
     algorithm:

     KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length ) =
                 = HKDF-Expand( PRK_2e, info, plaintext_length )

     where plaintext_length is the length in bytes of PLAINTEXT_2 in
     bytes, and info for KEYSTREAM_2 is:

     info =
     (
      0,
      h'c6405c154c567466ab1df20369500e540e9f14bd3a796a06
        52cae66c9061688d',
      82
     )

     where the last value is the length in bytes of PLAINTEXT_2.

     info for KEYSTREAM_2 (CBOR Sequence) (37 bytes)
     00 58 20 c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd
     3a 79 6a 06 52 ca e6 6c 90 61 68 8d 18 52







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


  Internet-Draft               Traces of EDHOC                January 2024


     KEYSTREAM_2 (Raw Value) (82 bytes)
     fd 3e 7c 3f 2d 6b ee 64 3d 3c 9d 2f 28 47 03 5d 73 e2 ec b0 f8 db 5c
     d1 c6 85 4e 24 89 6a f2 11 88 b2 c4 34 4e 68 9e c2 98 42 83 d9 fb c6
     9c e1 c5 db 10 dc ff f2 4d f9 a4 9a 04 a9 40 58 27 7b c7 fa 9a d6 c6
     b1 94 ab 32 8b 44 5e b0 80 49 0c d7 86

     The Responder calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and
     KEYSTREAM_2:

     CIPHERTEXT_2 (Raw Value) (82 bytes)
     bc 26 dd 27 0f e9 c0 2c 44 ce 39 34 79 4b 1c c6 2b a2 2f 05 45 9f 8d
     35 8c 8d 12 27 5a c4 2c 5f 96 de d5 f1 3c c9 08 4e 5b 20 18 89 a4 5e
     5a 60 a5 56 2d c1 18 61 9c 3d aa 2f d9 f4 c9 f4 d6 ed ad 10 9d d4 ed
     f9 59 62 aa fb af 9a b3 f4 a1 f6 b9 8f

     The Responder constructs message_2:

     message_2 =
     (
      G_Y_CIPHERTEXT_2
     )

     where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of
     the raw values of G_Y and CIPHERTEXT_2.

     message_2 (CBOR Sequence) (116 bytes)
     58 72 dc 88 d2 d5 1d a5 ed 67 fc 46 16 35 6b c8 ca 74 ef 9e be 8b 38
     7e 62 3a 36 0b a4 80 b9 b2 9d 1c bc 26 dd 27 0f e9 c0 2c 44 ce 39 34
     79 4b 1c c6 2b a2 2f 05 45 9f 8d 35 8c 8d 12 27 5a c4 2c 5f 96 de d5
     f1 3c c9 08 4e 5b 20 18 89 a4 5e 5a 60 a5 56 2d c1 18 61 9c 3d aa 2f
     d9 f4 c9 f4 d6 ed ad 10 9d d4 ed f9 59 62 aa fb af 9a b3 f4 a1 f6 b9
     8f

  2.3.  message_3

     Since METHOD = 0, the Initiator authenticates using signatures.
     Since the selected cipher suite is 0, the EDHOC signature algorithm
     is EdDSA.

     The Initiator's signature key pair using EdDSA:

     Initiator's private authentication key
     SK_I (Raw Value) (32 bytes)
     4c 5b 25 87 8f 50 7c 6b 9d ae 68 fb d4 fd 3f f9 97 53 3d b0 af 00 b2
     5d 32 4e a2 8e 6c 21 3b c8






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


  Internet-Draft               Traces of EDHOC                January 2024


     Initiator's public authentication key
     PK_I (Raw Value) (32 bytes)
     ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f
     23 d8 cc 20 b7 30 85 14 1e

     PRK_4e3m is specified in Section 4.1.1.3 of [I-D.ietf-lake-edhoc].

     Since the Initiator authenticates with signatures PRK_4e3m =
     PRK_3e2m.

     PRK_4e3m (Raw Value) (32 bytes)
     d5 84 ac 2e 5d ad 5a 77 d1 4b 53 eb e7 2e f1 d5 da a8 86 0d 39 93 73
     bf 2c 24 0a fa 7b a8 04 da

     The transcript hash TH_3 is calculated using the EDHOC hash
     algorithm:

     TH_3 = H(TH_2, PLAINTEXT_2, CRED_R)

     Input to calculate TH_3 (CBOR Sequence) (359 bytes)
     58 20 c6 40 5c 15 4c 56 74 66 ab 1d f2 03 69 50 0e 54 0e 9f 14 bd 3a
     79 6a 06 52 ca e6 6c 90 61 68 8d 41 18 a1 18 22 82 2e 48 79 f2 a4 1b
     51 0c 1f 9b 58 40 c3 b5 bd 44 d1 e4 4a 08 5c 03 d3 ae de 4e 1e 6c 11
     c5 72 a1 96 8c c3 62 9b 50 5f 98 c6 81 60 8d 3d 1d e7 93 d1 c4 0e b5
     dd 5d 89 ac f1 96 6a ea 07 02 2b 48 cd c9 98 70 eb c4 03 74 e8 fa 6e
     09 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e c4 30 05 06
     03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20
     52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30
     38 32 34 33 36 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22
     31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 52 65 73 70 6f 6e
     64 65 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00
     a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41 8a ac e3 3a a0 f2 c6 62
     c0 0b 3a c5 5d e9 2f 93 59 30 05 06 03 2b 65 70 03 41 00 b7 23 bc 01
     ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4 6e 7d 69 87 b0 32 47 8f ec
     fa f1 45 37 a1 af 14 cc 8b e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95
     65 d8 6d ce 51 cf ae 52 ab 82 c1 52 cb 02

     TH_3 (Raw Value) (32 bytes)
     5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69
     b1 67 77 99 65 92 e9 28 bc

     TH_3 (CBOR Data Item) (34 bytes)
     58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57
     f6 69 b1 67 77 99 65 92 e9 28 bc

     The Initiator constructs the remaining input needed to calculate
     MAC_3:




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


  Internet-Draft               Traces of EDHOC                January 2024


     MAC_3 = EDHOC_KDF( PRK_4e3m, 6, context_3, mac_length_3 )

     where

     context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>

     CRED_I is identified by a 64-bit hash:

     ID_CRED_I =
     {
      34 : [-15, h'c24ab2fd7643c79f']
     }

     where the COSE header value 34 ('x5t') indicates a hash of an X.509
     certficate, and the COSE algorithm -15 indicates the hash algorithm
     SHA-256 truncated to 64 bits.

     ID_CRED_I (CBOR Data Item) (14 bytes)
     a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f

     CRED_I is a CBOR byte string of the DER encoding of the X.509
     certificate in Section 2.8.2:

     CRED_I (Raw Value) (241 bytes)
     30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 06 03 2b 65
     70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f 6f
     74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 34
     30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 30
     1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 61 74 6f 72
     20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 ed 06 a8
     ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f 23 d8 cc
     20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 d8 b3 a7 70
     99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 92 75 ae 48
     b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff 27 b9
     e7 a8 13 fa 57 4b 72 a0 0b 43 0b

     CRED_I (CBOR Data Item) (243 bytes)
     58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 06 03
     2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52
     6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38
     32 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31
     20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 61 74
     6f 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 ed
     06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f 23
     d8 cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 d8 b3
     a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 92 75
     ae 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff
     27 b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b



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


  Internet-Draft               Traces of EDHOC                January 2024


     No external authorization data:

     EAD_3 (CBOR Sequence) (0 bytes)

     context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>

     context_3 (CBOR Sequence) (291 bytes)
     a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f 58 20 5b 7d f9 b4 f5 8f 24
     0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 99 65 92 e9
     28 bc 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05
     06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43
     20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36
     30 38 32 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30
     22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69
     61 74 6f 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21
     00 ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e
     0f 23 d8 cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41
     d8 b3 a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3
     92 75 ae 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05
     ee ff 27 b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b

     context_3 (CBOR byte string) (294 bytes)
     59 01 23 a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f 58 20 5b 7d f9 b4
     f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 99
     65 92 e9 28 bc 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e
     a0 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44
     48 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30
     33 31 36 30 38 32 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30
     30 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e
     69 74 69 61 74 6f 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65
     70 03 21 00 ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3
     02 f4 3e 0f 23 d8 cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00
     52 12 41 d8 b3 a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df
     29 10 b3 92 75 ae 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22
     67 dd 05 ee ff 27 b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b

     MAC_3 is computed through EDHOC_Expand() using the EDHOC hash
     algorithm, see Section 4.1.2 of [I-D.ietf-lake-edhoc]:

     MAC_3 = HKDF-Expand(PRK_4e3m, info, mac_length_3), where

     info = ( 6, context_3, mac_length_3 )

     where context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>

     Since METHOD = 0, mac_length_3 is given by the EDHOC hash algorithm.

     info for MAC_3 is:



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


  Internet-Draft               Traces of EDHOC                January 2024


     info =
     (
      6,
      h'a11822822e48c24ab2fd7643c79f58205b7df9b4f58f240c
        e0418e48191b5fff3a22b5ca57f669b16777996592e928bc
        58f13081ee3081a1a003020102020462319ea0300506032b
        6570301d311b301906035504030c124544484f4320526f6f
        742045643235353139301e170d3232303331363038323430
        305a170d3239313233313233303030305a30223120301e06
        035504030c174544484f4320496e69746961746f72204564
        3235353139302a300506032b6570032100ed06a8ae61a829
        ba5fa54525c9d07f48dd44a302f43e0f23d8cc20b7308514
        1e300506032b6570034100521241d8b3a770996bcfc9b9ea
        d4e7e0a1c0db353a3bdf2910b39275ae48b756015981850d
        27db6734e37f67212267dd05eeff27b9e7a813fa574b72a0
        0b430b',
      32
     )

     where the last value is the output size of the EDHOC hash algorithm
     in bytes.

     info for MAC_3 (CBOR Sequence) (297 bytes)
     06 59 01 23 a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f 58 20 5b 7d f9
     b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77
     99 65 92 e9 28 bc 58 f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31
     9e a0 30 05 06 03 2b 65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45
     44 48 4f 43 20 52 6f 6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32
     30 33 31 36 30 38 32 34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30
     30 30 5a 30 22 31 20 30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49
     6e 69 74 69 61 74 6f 72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b
     65 70 03 21 00 ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44
     a3 02 f4 3e 0f 23 d8 cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41
     00 52 12 41 d8 b3 a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b
     df 29 10 b3 92 75 ae 48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21
     22 67 dd 05 ee ff 27 b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b 18 20

     MAC_3 (Raw Value) (32 bytes)
     39 b1 27 c1 30 12 9a fa 30 61 8c 75 13 29 e6 37 cc 37 34 27 0d 4b 01
     25 84 45 a8 ee 02 da a3 bd

   MAC_3 (CBOR Data Item) (34 bytes)
   58 20 39 b1 27 c1 30 12 9a fa 30 61 8c 75 13 29 e6 37 cc 37 34 27 0d 4b
   01 25 84 45 a8 ee 02 da a3 bd

     Since METHOD = 0, Signature_or_MAC_3 is the 'signature' of the
     COSE_Sign1 object.




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


  Internet-Draft               Traces of EDHOC                January 2024


     The Initiator constructs the message to be signed:

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

     [
      "Signature1",
      h'a11822822e48c24ab2fd7643c79f',
      h'58205b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f6
        69b16777996592e928bc58f13081ee3081a1a00302010202
        0462319ea0300506032b6570301d311b301906035504030c
        124544484f4320526f6f742045643235353139301e170d32
        32303331363038323430305a170d32393132333132333030
        30305a30223120301e06035504030c174544484f4320496e
        69746961746f722045643235353139302a300506032b6570
        032100ed06a8ae61a829ba5fa54525c9d07f48dd44a302f4
        3e0f23d8cc20b73085141e300506032b6570034100521241
        d8b3a770996bcfc9b9ead4e7e0a1c0db353a3bdf2910b392
        75ae48b756015981850d27db6734e37f67212267dd05eeff
        27b9e7a813fa574b72a00b430b',
      h'39b127c130129afa30618c751329e637cc3734270d4b0125
        8445a8ee02daa3bd'
     ]

     Message to be signed 3 (CBOR Data Item) (341 bytes)
     84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 c2 4a b2 fd
     76 43 c7 9f 59 01 15 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b
     5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 99 65 92 e9 28 bc 58 f1 30 81 ee
     30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 06 03 2b 65 70 30 1d
     31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f 6f 74 20 45
     64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32 34 30 30 5a
     17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20 30 1e 06 03
     55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 61 74 6f 72 20 45 64
     32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 ed 06 a8 ae 61 a8
     29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f 23 d8 cc 20 b7 30
     85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 d8 b3 a7 70 99 6b cf
     c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 92 75 ae 48 b7 56 01
     59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff 27 b9 e7 a8 13
     fa 57 4b 72 a0 0b 43 0b 58 20 39 b1 27 c1 30 12 9a fa 30 61 8c 75 13
     29 e6 37 cc 37 34 27 0d 4b 01 25 84 45 a8 ee 02 da a3 bd

     The Initiator signs using the private authentication key SK_I:

     Signature_or_MAC_3 (Raw Value) (64 bytes)
     96 e1 cd 5f ce ad fa c1 b5 af 81 94 43 f7 09 24 f5 71 99 55 95 7f d0
     26 55 be b4 77 5e 1a 73 18 6a 0d 1d 3e a6 83 f0 8f 8d 03 dc ec b9 cf
     15 4e 1c 6f 55 5a 1e 12 ca 11 8c e4 2b db a6 87 89 07




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


  Internet-Draft               Traces of EDHOC                January 2024


     Signature_or_MAC_3 (CBOR Data Item) (66 bytes)
     58 40 96 e1 cd 5f ce ad fa c1 b5 af 81 94 43 f7 09 24 f5 71 99 55 95
     7f d0 26 55 be b4 77 5e 1a 73 18 6a 0d 1d 3e a6 83 f0 8f 8d 03 dc ec
     b9 cf 15 4e 1c 6f 55 5a 1e 12 ca 11 8c e4 2b db a6 87 89 07

     The Initiator constructs PLAINTEXT_3:

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

     PLAINTEXT_3 (CBOR Sequence) (80 bytes)
     a1 18 22 82 2e 48 c2 4a b2 fd 76 43 c7 9f 58 40 96 e1 cd 5f ce ad fa
     c1 b5 af 81 94 43 f7 09 24 f5 71 99 55 95 7f d0 26 55 be b4 77 5e 1a
     73 18 6a 0d 1d 3e a6 83 f0 8f 8d 03 dc ec b9 cf 15 4e 1c 6f 55 5a 1e
     12 ca 11 8c e4 2b db a6 87 89 07

     The Initiator constructs the associated data for message_3:

     A_3 =
     [
      "Encrypt0",
      h'',
      h'5b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f669b1
        6777996592e928bc'
     ]

     A_3 (CBOR Data Item) (45 bytes)
     83 68 45 6e 63 72 79 70 74 30 40 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41
     8e 48 19 1b 5f ff 3a 22 b5 ca 57 f6 69 b1 67 77 99 65 92 e9 28 bc

     The Initiator constructs the input needed to derive the key K_3, see
     Section 4.1.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash
     algorithm:

     K_3 = EDHOC_KDF( PRK_3e2m, 3, TH_3, key_length )
         = HKDF-Expand( PRK_3e2m, info, key_length ),

     where key_length is the key length in bytes for the EDHOC AEAD
     algorithm, and info for K_3 is:








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


  Internet-Draft               Traces of EDHOC                January 2024


     info =
     (
      3,
      h'5b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f669b1
        6777996592e928bc',
      16
     )

     where the last value is the key length in bytes for the EDHOC AEAD
     algorithm.

     info for K_3 (CBOR Sequence) (36 bytes)
     03 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca
     57 f6 69 b1 67 77 99 65 92 e9 28 bc 10

     K_3 (Raw Value) (16 bytes)
     da 19 5e 5f 64 8a c6 3b 0e 8f b0 c4 55 20 51 39

     The Initiator constructs the input needed to derive the nonce IV_3,
     see Section 4.1.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash
     algorithm:

     IV_3 = EDHOC_KDF( PRK_3e2m, 4, TH_3, iv_length )
          = HKDF-Expand( PRK_3e2m, info, iv_length ),

     where iv_length is the nonce length in bytes for the EDHOC AEAD
     algorithm, and info for IV_3 is:

     info =
     (
      4,
      h'5b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f669b1
        6777996592e928bc',
      13
     )

     where the last value is the nonce length in bytes for the EDHOC AEAD
     algorithm.

     info for IV_3 (CBOR Sequence) (36 bytes)
     04 58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca
     57 f6 69 b1 67 77 99 65 92 e9 28 bc 0d

     IV_3 (Raw Value) (13 bytes)
     38 d8 c6 4c 56 25 5a ff a4 49 f4 be d7






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


  Internet-Draft               Traces of EDHOC                January 2024


     The Initiator calculates CIPHERTEXT_3 as 'ciphertext' of
     COSE_Encrypt0 applied using the EDHOC AEAD algorithm with plaintext
     PLAINTEXT_3, additional data A_3, key K_3 and nonce IV_3.

     CIPHERTEXT_3 (Raw Value) (88 bytes)
     25 c3 45 88 4a aa eb 22 c5 27 f9 b1 d2 b6 78 72 07 e0 16 3c 69 b6 2a
     0d 43 92 81 50 42 72 03 c3 16 74 e4 51 4e a6 e3 83 b5 66 eb 29 76 3e
     fe b0 af a5 18 77 6a e1 c6 5f 85 6d 84 bf 32 af 3a 78 36 97 04 66 dc
     b7 1f 76 74 5d 39 d3 02 5e 77 03 e0 c0 32 eb ad 51 94 7c

     message_3 is the CBOR bstr encoding of CIPHERTEXT_3:

     message_3 (CBOR Sequence) (90 bytes)
     58 58 25 c3 45 88 4a aa eb 22 c5 27 f9 b1 d2 b6 78 72 07 e0 16 3c 69
     b6 2a 0d 43 92 81 50 42 72 03 c3 16 74 e4 51 4e a6 e3 83 b5 66 eb 29
     76 3e fe b0 af a5 18 77 6a e1 c6 5f 85 6d 84 bf 32 af 3a 78 36 97 04
     66 dc b7 1f 76 74 5d 39 d3 02 5e 77 03 e0 c0 32 eb ad 51 94 7c

     The transcript hash TH_4 is calculated using the EDHOC hash
     algorithm:

     TH_4 = H( TH_3, PLAINTEXT_3, CRED_I )

     Input to calculate TH_4 (CBOR Sequence) (357 bytes)
     58 20 5b 7d f9 b4 f5 8f 24 0c e0 41 8e 48 19 1b 5f ff 3a 22 b5 ca 57
     f6 69 b1 67 77 99 65 92 e9 28 bc a1 18 22 82 2e 48 c2 4a b2 fd 76 43
     c7 9f 58 40 96 e1 cd 5f ce ad fa c1 b5 af 81 94 43 f7 09 24 f5 71 99
     55 95 7f d0 26 55 be b4 77 5e 1a 73 18 6a 0d 1d 3e a6 83 f0 8f 8d 03
     dc ec b9 cf 15 4e 1c 6f 55 5a 1e 12 ca 11 8c e4 2b db a6 87 89 07 58
     f1 30 81 ee 30 81 a1 a0 03 02 01 02 02 04 62 31 9e a0 30 05 06 03 2b
     65 70 30 1d 31 1b 30 19 06 03 55 04 03 0c 12 45 44 48 4f 43 20 52 6f
     6f 74 20 45 64 32 35 35 31 39 30 1e 17 0d 32 32 30 33 31 36 30 38 32
     34 30 30 5a 17 0d 32 39 31 32 33 31 32 33 30 30 30 30 5a 30 22 31 20
     30 1e 06 03 55 04 03 0c 17 45 44 48 4f 43 20 49 6e 69 74 69 61 74 6f
     72 20 45 64 32 35 35 31 39 30 2a 30 05 06 03 2b 65 70 03 21 00 ed 06
     a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f 48 dd 44 a3 02 f4 3e 0f 23 d8
     cc 20 b7 30 85 14 1e 30 05 06 03 2b 65 70 03 41 00 52 12 41 d8 b3 a7
     70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0 db 35 3a 3b df 29 10 b3 92 75 ae
     48 b7 56 01 59 81 85 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff 27
     b9 e7 a8 13 fa 57 4b 72 a0 0b 43 0b

     TH_4 (Raw Value) (32 bytes)
     0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99 be 42 d5
     a4 1a 5a 37 c8 96 f2 94 ac

     TH_4 (CBOR Data Item) (34 bytes)
     58 20 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99 be
     42 d5 a4 1a 5a 37 c8 96 f2 94 ac



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


  Internet-Draft               Traces of EDHOC                January 2024


  2.4.  message_4

     No external authorization data:

     EAD_4 (CBOR Sequence) (0 bytes)

     The Responder constructs PLAINTEXT_4:

     PLAINTEXT_4 =
     (
      ? EAD_4
     )

     PLAINTEXT_4 (CBOR Sequence) (0 bytes)

     The Responder constructs the associated data for message_4:

     A_4 =
     [
      "Encrypt0",
      h'',
      h'0eb868f263cf3555dccd396dd8dec29d3750d599be42d5a4
        1a5a37c896f294ac'
     ]

     A_4 (CBOR Data Item) (45 bytes)
     83 68 45 6e 63 72 79 70 74 30 40 58 20 0e b8 68 f2 63 cf 35 55 dc cd
     39 6d d8 de c2 9d 37 50 d5 99 be 42 d5 a4 1a 5a 37 c8 96 f2 94 ac

     The Responder constructs the input needed to derive the EDHOC
     message_4 key, see Section 4.1.2 of [I-D.ietf-lake-edhoc], using the
     EDHOC hash algorithm:

     K_4   = EDHOC_KDF( PRK_4e3m, 8, TH_4, key_length )
           = HKDF-Expand( PRK_4x3m, info, key_length )

     where key_length is the key length in bytes for the EDHOC AEAD
     algorithm, and info for K_4 is:

     info =
     (
      8,
      h'0eb868f263cf3555dccd396dd8dec29d3750d599be42d5a4
        1a5a37c896f294ac',
      16
     )





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


  Internet-Draft               Traces of EDHOC                January 2024


     where the last value is the key length in bytes for the EDHOC AEAD
     algorithm.

     info for K_4 (CBOR Sequence) (36 bytes)
     08 58 20 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99
     be 42 d5 a4 1a 5a 37 c8 96 f2 94 ac 10

     K_4 (Raw Value) (16 bytes)
     df 8c b5 86 1e 1f df ed d3 b2 30 15 a3 9d 1e 2e

     The Responder constructs the input needed to derive the EDHOC
     message_4 nonce, see Section 4.1.2 of [I-D.ietf-lake-edhoc], using
     the EDHOC hash algorithm:

           IV_4 = EDHOC_KDF( PRK_4e3m, 9, TH_4, iv_length )
                = HKDF-Expand( PRK_4x3m, info, iv_length )

     where length is the nonce length in bytes for the EDHOC AEAD
     algorithm, and info for IV_4 is:

     info =
     (
      9,
      h'0eb868f263cf3555dccd396dd8dec29d3750d599be42d5a4
        1a5a37c896f294ac',
      13
     )

     where the last value is the nonce length in bytes for the EDHOC AEAD
     algorithm.

     info for IV_4 (CBOR Sequence) (36 bytes)
     09 58 20 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99
     be 42 d5 a4 1a 5a 37 c8 96 f2 94 ac 0d

     IV_4 (Raw Value) (13 bytes)
     12 8e c6 58 d9 70 d7 38 0f 74 fc 6c 27

     The Responder calculates CIPHERTEXT_4 as 'ciphertext' of
     COSE_Encrypt0 applied using the EDHOC AEAD algorithm with plaintext
     PLAINTEXT_4, additional data A_4, key K_4 and nonce IV_4.

     CIPHERTEXT_4 (8 bytes)
     4f 0e de e3 66 e5 c8 83

     message_4 is the CBOR bstr encoding of CIPHERTEXT_4:





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


  Internet-Draft               Traces of EDHOC                January 2024


     message_4 (CBOR Sequence) (9 bytes)
     48 4f 0e de e3 66 e5 c8 83

  2.5.  PRK_out and PRK_exporter

     PRK_out is specified in Section 4.1.3 of [I-D.ietf-lake-edhoc].

     PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length ) =
             = HKDF-Expand( PRK_4e3m, info,  hash_length )

     where hash_length is the length in bytes of the output of the EDHOC
     hash algorithm, and info for PRK_out is:

     info =
     (
      7,
      h'0eb868f263cf3555dccd396dd8dec29d3750d599be42d5a4
        1a5a37c896f294ac',
      32
     )

     where the last value is the length in bytes of the output of the
     EDHOC hash algorithm.

     info for PRK_out (CBOR Sequence) (37 bytes)
     07 58 20 0e b8 68 f2 63 cf 35 55 dc cd 39 6d d8 de c2 9d 37 50 d5 99
     be 42 d5 a4 1a 5a 37 c8 96 f2 94 ac 18 20

     PRK_out (Raw Value) (32 bytes)
     b7 44 cb 7d 8a 87 cc 04 47 c3 35 0e 16 5b 25 0d ab 12 ec 45 33 25 ab
     b9 22 b3 03 07 e5 c3 68 f0

     The OSCORE Master Secret and OSCORE Master Salt are derived with the
     EDHOC_Exporter as specified in Section 4.2.1 of
     [I-D.ietf-lake-edhoc].

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

     where PRK_exporter is derived from PRK_out:

      PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) =
                   = HKDF-Expand( PRK_out, info,  hash_length )

     where hash_length is the length in bytes of the output of the EDHOC
     hash algorithm, and info for the PRK_exporter is:





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


  Internet-Draft               Traces of EDHOC                January 2024


     info =
     (
      10,
      h'',
      32
     )

     where the last value is the length in bytes of the output of the
     EDHOC hash algorithm.

     info for PRK_exporter (CBOR Sequence) (4 bytes)
     0a 40 18 20

     PRK_exporter (Raw Value) (32 bytes)
     2a ae c8 fc 4a b3 bc 32 95 de f6 b5 51 05 1a 2f a5 61 42 4d b3 01 fa
     84 f6 42 f5 57 8a 6d f5 1a

  2.6.  OSCORE Parameters

     The derivation of OSCORE parameters is specified in Appendix A.1 of
     [I-D.ietf-lake-edhoc].

     The AEAD and Hash algorithms to use in OSCORE are given by the
     selected cipher suite:

     Application AEAD Algorithm (int)
     10

     Application Hash Algorithm (int)
     -16

     The mapping from EDHOC connection identifiers to OSCORE Sender/
     Recipient IDs is defined in Section 3.3.3 of [I-D.ietf-lake-edhoc].

     C_R is mapped to the Recipient ID of the server, i.e., the Sender ID
     of the client.  The byte string 0x18, which as C_R is encoded as the
     CBOR byte string 0x4118, is converted to the server Recipient ID
     0x18.

     Client's OSCORE Sender ID (Raw Value) (1 byte)
     18

     C_I is mapped to the Recipient ID of the client, i.e., the Sender ID
     of the server.  The byte string 0x2d, which as C_I is encoded as the
     CBOR integer 0x2d is converted to the client Recipient ID 0x2d.

     Server's OSCORE Sender ID (Raw Value) (1 byte)
     2d



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


  Internet-Draft               Traces of EDHOC                January 2024


     The OSCORE Master Secret is computed through EDHOC_Expand() using the
     Application hash algorithm, see Appendix A.1 of
     [I-D.ietf-lake-edhoc]:

     OSCORE Master Secret = EDHOC_Exporter( 0, h'', oscore_key_length )
     = EDHOC_KDF( PRK_exporter, 0, h'',  oscore_key_length )
     = HKDF-Expand( PRK_exporter, info,  oscore_key_length )

     where oscore_key_length is by default the key length in bytes for the
     Application AEAD algorithm, and info for the OSCORE Master Secret is:

     info =
     (
      0,
      h'',
      16
     )

     where the last value is the key length in bytes for the Application
     AEAD algorithm.

     info for OSCORE Master Secret (CBOR Sequence) (3 bytes)
     00 40 10

     OSCORE Master Secret (Raw Value) (16 bytes)
     1e 1c 6b ea c3 a8 a1 ca c4 35 de 7e 2f 9a e7 ff

     The OSCORE Master Salt is computed through EDHOC_Expand() using the
     Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]:

     OSCORE Master Salt = EDHOC_Exporter( 1, h'', oscore_salt_length )
     = EDHOC_KDF( PRK_exporter, 1, h'', oscore_salt_length )
     = HKDF-Expand( PRK_4x3m, info, oscore_salt_length )

     where oscore_salt_length is the length in bytes of the OSCORE Master
     Salt, and info for the OSCORE Master Salt is:

     info =
     (
      1,
      h'',
      8
     )

     where the last value is the length in bytes of the OSCORE Master
     Salt.





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


  Internet-Draft               Traces of EDHOC                January 2024


     info for OSCORE Master Salt (CBOR Sequence) (3 bytes)
     01 40 08

     OSCORE Master Salt (Raw Value) (8 bytes)
     ce 7a b8 44 c0 10 6d 73

  2.7.  Key Update

     Key update is defined in Appendix H of [I-D.ietf-lake-edhoc].

     EDHOC_KeyUpdate( context ):
     PRK_out = EDHOC_KDF( PRK_out, 11, context, hash_length )
             = HKDF-Expand( PRK_out, info, hash_length )

     where hash_length is the length in bytes of the output of the EDHOC
     hash function, and context for KeyUpdate is

     context for KeyUpdate (Raw Value) (16 bytes)
     d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c

     context for KeyUpdate (CBOR Data Item) (17 bytes)
     50 d6 be 16 96 02 b8 bc ea a0 11 58 fd b8 20 89 0c

     and where info for key update is:

     info =
     (
      11,
      h'd6be169602b8bceaa01158fdb820890c',
      32
     )

     PRK_out after KeyUpdate (Raw Value) (32 bytes)
     da 6e ac d9 a9 85 f4 fb a9 ae c2 a9 29 90 22 97 6b 25 b1 4e 89 fa 15
     97 94 f2 8d 82 fa f2 da ad

     After key update, the PRK_exporter needs to be derived anew:

      PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) =
                   = HKDF-Expand( PRK_out, info,  hash_length )

     where info and hash_length are unchanged as in Section 2.5.

     PRK_exporter after KeyUpdate (Raw Value) (32 bytes)
     00 14 d2 52 5e e0 d8 e2 13 ea 59 08 02 8e 9a 1c e9 a0 1c 30 54 6f 09
     30 c0 44 d3 8d b5 36 2c 05

     The OSCORE Master Secret is derived with the updated PRK_exporter:



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


  Internet-Draft               Traces of EDHOC                January 2024


     OSCORE Master Secret =
     = HKDF-Expand(PRK_exporter, info, oscore_key_length)

     where info and key_length are unchanged as in Section 2.6.

     OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes)
     ee 0f f5 42 c4 7e b0 e0 9c 69 30 76 49 bd bb e5

     The OSCORE Master Salt is derived with the updated PRK_exporter:

     OSCORE Master Salt = HKDF-Expand(PRK_exporter, info, salt_length)

     where info and salt_length are unchanged as in Section 2.6.

     OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes)
     80 ce de 2a 1e 5a ab 48

  2.8.  Certificates

  2.8.1.  Responder Certificate

             Version: 3 (0x2)
             Serial Number: 1647419076 (0x62319ec4)
             Signature Algorithm: ED25519
             Issuer: CN = EDHOC Root Ed25519
             Validity
                 Not Before: Mar 16 08:24:36 2022 GMT
                 Not After : Dec 31 23:00:00 2029 GMT
             Subject: CN = EDHOC Responder Ed25519
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
                         a1 db 47 b9 51 84 85 4a d1 2a 0c 1a 35 4e 41
                         8a ac e3 3a a0 f2 c6 62 c0 0b 3a c5 5d e9 2f
                         93 59
             Signature Algorithm: ED25519
             Signature Value:
                 b7 23 bc 01 ea b0 92 8e 8b 2b 6c 98 de 19 cc 38 23 d4
                 6e 7d 69 87 b0 32 47 8f ec fa f1 45 37 a1 af 14 cc 8b
                 e8 29 c6 b7 30 44 10 18 37 eb 4a bc 94 95 65 d8 6d ce
                 51 cf ae 52 ab 82 c1 52 cb 02

  2.8.2.  Initiator Certificate







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


  Internet-Draft               Traces of EDHOC                January 2024


             Version: 3 (0x2)
             Serial Number: 1647419040 (0x62319ea0)
             Signature Algorithm: ED25519
             Issuer: CN = EDHOC Root Ed25519
             Validity
                 Not Before: Mar 16 08:24:00 2022 GMT
                 Not After : Dec 31 23:00:00 2029 GMT
             Subject: CN = EDHOC Initiator Ed25519
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
                         ed 06 a8 ae 61 a8 29 ba 5f a5 45 25 c9 d0 7f
                         48 dd 44 a3 02 f4 3e 0f 23 d8 cc 20 b7 30 85
                         14 1e
             Signature Algorithm: ED25519
             Signature Value:
                 52 12 41 d8 b3 a7 70 99 6b cf c9 b9 ea d4 e7 e0 a1 c0
                 db 35 3a 3b df 29 10 b3 92 75 ae 48 b7 56 01 59 81 85
                 0d 27 db 67 34 e3 7f 67 21 22 67 dd 05 ee ff 27 b9 e7
                 a8 13 fa 57 4b 72 a0 0b 43 0b

  2.8.3.  Common Root Certificate




























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


  Internet-Draft               Traces of EDHOC                January 2024


             Version: 3 (0x2)
             Serial Number: 1647418996 (0x62319e74)
             Signature Algorithm: ED25519
             Issuer: CN = EDHOC Root Ed25519
             Validity
                 Not Before: Mar 16 08:23:16 2022 GMT
                 Not After : Dec 31 23:00:00 2029 GMT
             Subject: CN = EDHOC Root Ed25519
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
                         2b 7b 3e 80 57 c8 64 29 44 d0 6a fe 7a 71 d1
                         c9 bf 96 1b 62 92 ba c4 b0 4f 91 66 9b bb 71
                         3b e4
             X509v3 extensions:
                 X509v3 Key Usage: critical
                     Certificate Sign
                 X509v3 Basic Constraints: critical
                     CA:TRUE
             Signature Algorithm: ED25519
             Signature Value:
                 4b b5 2b bf 15 39 b7 1a 4a af 42 97 78 f2 9e da 7e 81
                 46 80 69 8f 16 c4 8f 2a 6f a4 db e8 25 41 c5 82 07 ba
                 1b c9 cd b0 c2 fa 94 7f fb f0 f0 ec 0e e9 1a 7f f3 7a
                 94 d9 25 1f a5 cd f1 e6 7a 0f

  3.  Authentication with Static DH, CCS Identified by 'kid'

     In this example the Initiator and the Responder are authenticated
     with ephemeral-static Diffie-Hellman (METHOD = 3).  The Initiator
     supports cipher suites 6 and 2 (in order of preference) and the
     Responder only supports cipher suite 2.  After an initial negotiation
     message exchange, cipher suite 2 is used, which determines the
     algorithms:

     *  EDHOC AEAD algorithm = AES-CCM-16-64-128

     *  EDHOC hash algorithm = SHA-256

     *  EDHOC MAC length in bytes (Static DH) = 8

     *  EDHOC key exchange algorithm (ECDH curve) = P-256

     *  EDHOC signature algorithm = ES256

     *  Application AEAD algorithm = AES-CCM-16-64-128




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


  Internet-Draft               Traces of EDHOC                January 2024


     *  Application hash algorithm = SHA-256

     The public keys are represented as raw public keys (RPK), encoded in
     a CWT Claims Set (CCS) and identified by the COSE header parameter
     'kid'.

  3.1.  message_1 (first time)

     Both endpoints are authenticated with static DH, i.e., METHOD = 3:

     METHOD (CBOR Data Item) (1 byte)
     03

     The Initiator selects its preferred cipher suite 6.  A single cipher
     suite is encoded as an int:

     SUITES_I (CBOR Data Item) (1 byte)
     06

     The Initiator creates an ephemeral key pair for use with the EDHOC
     key exchange algorithm:

     Initiator's ephemeral private key
     X (Raw Value) (32 bytes)
     5c 41 72 ac a8 b8 2b 5a 62 e6 6f 72 22 16 f5 a1 0f 72 aa 69 f4 2c 1d
     1c d3 cc d7 bf d2 9c a4 e9

     Initiator's ephemeral public key, 'x'-coordinate
     G_X (Raw Value) (32 bytes)
     74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b 3d 8f 65 f3 26
     20 b7 49 be e8 d2 78 ef a9

     Initiator's ephemeral public key, 'x'-coordinate
     G_X (CBOR Data Item) (34 bytes)
     58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b 3d 8f 65
     f3 26 20 b7 49 be e8 d2 78 ef a9

     The Initiator selects its connection identifier C_I to be the byte
     string 0x0e, which since it is represented by the 1-byte CBOR int 14
     is encoded as 0x0e:

     Connection identifier chosen by Initiator
     C_I (Raw Value) (1 byte)
     0e

     Connection identifier chosen by Initiator
     C_I (CBOR Data Item) (1 byte)
     0e



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


  Internet-Draft               Traces of EDHOC                January 2024


     No external authorization data:

     EAD_1 (CBOR Sequence) (0 bytes)

     The Initiator constructs message_1:

     message_1 =
     (
      3,
      6,
      h'741a13d7ba048fbb615e94386aa3b61bea5b3d8f65f32620
        b749bee8d278efa9',
      14
     )

     message_1 (CBOR Sequence) (37 bytes)
     03 06 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b 3d
     8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e

  3.2.  error

     The Responder does not support cipher suite 6 and sends an error with
     ERR_CODE 2 containing SUITES_R as ERR_INFO.  The Responder proposes
     cipher suite 2, a single cipher suite thus encoded as an int.

     SUITES_R
     02

     error (CBOR Sequence) (2 bytes)
     02 02

  3.3.  message_1 (second time)

     Same steps are performed as for message_1 the first time,
     Section 3.1, but with updated SUITES_I.

     Both endpoints are authenticated with static DH, i.e., METHOD = 3:

     METHOD (CBOR Data Item) (1 byte)
     03

     The Initiator selects cipher suite 2 and indicates the more preferred
     cipher suite(s), in this case 6, all encoded as the array [6, 2]:

     SUITES_I (CBOR Data Item) (3 bytes)
     82 06 02





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


  Internet-Draft               Traces of EDHOC                January 2024


     The Initiator creates an ephemeral key pair for use with the EDHOC
     key exchange algorithm:

     Initiator's ephemeral private key
     X (Raw Value) (32 bytes)
     36 8e c1 f6 9a eb 65 9b a3 7d 5a 8d 45 b2 1b dc 02 99 dc ea a8 ef 23
     5f 3c a4 2c e3 53 0f 95 25

     Initiator's ephemeral public key, 'x'-coordinate
     G_X (Raw Value) (32 bytes)
     8a f6 f4 30 eb e1 8d 34 18 40 17 a9 a1 1b f5 11 c8 df f8 f8 34 73 0b
     96 c1 b7 c8 db ca 2f c3 b6

     Initiator's ephemeral public key, one 'y'-coordinate
     (Raw Value) (32 bytes)
     51 e8 af 6c 6e db 78 16 01 ad 1d 9c 5f a8 bf 7a a1 57 16 c7 c0 6a 5d
     03 85 03 c6 14 ff 80 c9 b3

     Initiator's ephemeral public key, 'x'-coordinate
     G_X (CBOR Data Item) (34 bytes)
     58 20 8a f6 f4 30 eb e1 8d 34 18 40 17 a9 a1 1b f5 11 c8 df f8 f8 34
     73 0b 96 c1 b7 c8 db ca 2f c3 b6

     The Initiator selects its connection identifier C_I to be the byte
     string 0x37, which since it is represented by the 1-byte CBOR int -24
     is encoded as 0x37:

     Connection identifier chosen by Initiator
     C_I (Raw Value) (1 byte)
     37

     Connection identifier chosen by Initiator
     C_I (CBOR Data Item) (1 byte)
     37

     No external authorization data:

     EAD_1 (CBOR Sequence) (0 bytes)

     The Initiator constructs message_1:











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


  Internet-Draft               Traces of EDHOC                January 2024


     message_1 =
     (
      3,
      [6, 2],
      h'8af6f430ebe18d34184017a9a11bf511c8dff8f834730b96
        c1b7c8dbca2fc3b6',
      -24
     )

     message_1 (CBOR Sequence) (39 bytes)
     03 82 06 02 58 20 8a f6 f4 30 eb e1 8d 34 18 40 17 a9 a1 1b f5 11 c8
     df f8 f8 34 73 0b 96 c1 b7 c8 db ca 2f c3 b6 37

  3.4.  message_2

     The Responder supports the selected cipher suite 2 and not the by the
     Initiator more preferred cipher suite(s) 6, so SUITES_I is
     acceptable.

     The Responder creates an ephemeral key pair for use with the EDHOC
     key exchange algorithm:

     Responder's ephemeral private key
     Y (Raw Value) (32 bytes)
     e2 f4 12 67 77 20 5e 85 3b 43 7d 6e ac a1 e1 f7 53 cd cc 3e 2c 69 fa
     88 4b 0a 1a 64 09 77 e4 18

     Responder's ephemeral public key, 'x'-coordinate
     G_Y (Raw Value) (32 bytes)
     41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93 42 2c
     8e a0 f9 55 a1 3a 4f f5 d5

     Responder's ephemeral public key, one 'y'-coordinate
     (Raw Value) (32 bytes)
     5e 4f 0d d8 a3 da 0b aa 16 b9 d3 ad 56 a0 c1 86 0a 94 0a f8 59 14 91
     5e 25 01 9b 40 24 17 e9 9d

     Responder's ephemeral public key, 'x'-coordinate
     G_Y (CBOR Data Item) (34 bytes)
     58 20 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93
     42 2c 8e a0 f9 55 a1 3a 4f f5 d5

     The Responder selects its connection identifier C_R to be the byte
     string 0x27, which since it is represented by the 1-byte CBOR int -8
     is encoded as 0x27:






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


  Internet-Draft               Traces of EDHOC                January 2024


     Connection identifier chosen by Responder
     C_R (raw value) (1 byte)
     27

     Connection identifier chosen by Responder
     C_R (CBOR Data Item) (1 byte)
     27

     The transcript hash TH_2 is calculated using the EDHOC hash
     algorithm:

     TH_2 = H( G_Y, H(message_1) )

     H(message_1) (Raw Value) (32 bytes)
     ca 02 ca bd a5 a8 90 27 49 b4 2f 71 10 50 bb 4d bd 52 15 3e 87 52 75
     94 b3 9f 50 cd f0 19 88 8c

     H(message_1) (CBOR Data Item) (34 bytes)
     58 20 ca 02 ca bd a5 a8 90 27 49 b4 2f 71 10 50 bb 4d bd 52 15 3e 87
     52 75 94 b3 9f 50 cd f0 19 88 8c

     The input to calculate TH_2 is the CBOR sequence:

     G_Y, H(message_1)

     Input to calculate TH_2 (CBOR Sequence) (68 bytes)
     58 20 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93
     42 2c 8e a0 f9 55 a1 3a 4f f5 d5 58 20 ca 02 ca bd a5 a8 90 27 49 b4
     2f 71 10 50 bb 4d bd 52 15 3e 87 52 75 94 b3 9f 50 cd f0 19 88 8c

     TH_2 (Raw Value) (32 bytes)
     35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 02 8f f3
     9d 52 36 c1 82 b2 02 08 4b

     TH_2 (CBOR Data Item) (34 bytes)
     58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 02
     8f f3 9d 52 36 c1 82 b2 02 08 4b

     PRK_2e is specified in Section 4.1.1.1 of [I-D.ietf-lake-edhoc].

     First, the ECDH shared secret G_XY is computed from G_X and Y, or G_Y
     and X:

     G_XY (Raw Value) (ECDH shared secret) (32 bytes)
     2f 0c b7 e8 60 ba 53 8f bf 5c 8b de d0 09 f6 25 9b 4b 62 8f e1 eb 7d
     be 93 78 e5 ec f7 a8 24 ba





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


  Internet-Draft               Traces of EDHOC                January 2024


     Then, PRK_2e is calculated using EDHOC_Extract() determined by the
     EDHOC hash algorithm:

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

     where salt is TH_2:

     salt (Raw Value) (32 bytes)
     35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 02 8f f3
     9d 52 36 c1 82 b2 02 08 4b

     PRK_2e (Raw Value) (32 bytes)
     5a a0 d6 9f 3e 3d 1e 0c 47 9f 0b 8a 48 66 90 c9 80 26 30 c3 46 6b 1d
     c9 23 71 c9 82 56 31 70 b5

     Since METHOD = 3, the Responder authenticates using static DH.  The
     EDHOC key exchange algorithm is based on the same curve as for the
     ephemeral keys, which is P-256, since the selected cipher suite is 2.

     The Responder's static Diffie-Hellman P-256 key pair:

     Responder's private authentication key
     SK_R (Raw Value) (32 bytes)
     72 cc 47 61 db d4 c7 8f 75 89 31 aa 58 9d 34 8d 1e f8 74 a7 e3 03 ed
     e2 f1 40 dc f3 e6 aa 4a ac

     Responder's public authentication key, 'x'-coordinate
     (Raw Value) (32 bytes)
     bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 91 a1 2a fb
     cb ac 93 62 20 46 dd 44 f0

     Responder's public authentication key, 'y'-coordinate
     (Raw Value) (32 bytes)
     45 19 e2 57 23 6b 2a 0c e2 02 3f 09 31 f1 f3 86 ca 7a fd a6 4f cd e0
     10 8c 22 4c 51 ea bf 60 72

     Since the Responder authenticates with static DH (METHOD = 3),
     PRK_3e2m is derived from SALT_3e2m and G_RX.

     The input needed to calculate SALT_3e2m is defined in Section 4.1.2
     of [I-D.ietf-lake-edhoc], using EDHOC_Expand() with the EDHOC hash
     algorithm:

     SALT_3e2m  = EDHOC_KDF( PRK_2e, 1, TH_2, hash_length ) =
                = HKDF-Expand( PRK_2e, info, hash_length )





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


  Internet-Draft               Traces of EDHOC                January 2024


     where hash_length is the length in bytes of the output of the EDHOC
     hash algorithm, and info for SALT_3e2m is:

     info =
     (
      1,
      h'356efd53771425e008f3fe3a86c83ff4c6b16e57028ff39d
        5236c182b202084b',
      32
     )

     info for SALT_3e2m (CBOR Sequence) (37 bytes)
     01 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57
     02 8f f3 9d 52 36 c1 82 b2 02 08 4b 18 20

     SALT_3e2m (Raw Value) (32 bytes)
     af 4e 10 3a 47 cb 3c f3 25 70 d5 c2 5a d2 77 32 bd 8d 81 78 e9 a6 9d
     06 1c 31 a2 7f 8e 3c a9 26

     PRK_3e2m is specified in Section 4.1.1.2 of [I-D.ietf-lake-edhoc].

     PRK_3e2m is derived from G_RX using EDHOC_Extract() with the EDHOC
     hash algorithm:

     PRK_3e2m = EDHOC_Extract( SALT_3e2m, G_RX ) =
              = HMAC-SHA-256( SALT_3e2m, G_RX )

     where G_RX is the ECDH shared secret calculated from G_X and R, or
     G_R and X.

     G_RX (Raw Value) (ECDH shared secret) (32 bytes)
     f2 b6 ee a0 22 20 b9 5e ee 5a 0b c7 01 f0 74 e0 0a 84 3e a0 24 22 f6
     08 25 fb 26 9b 3e 16 14 23

     PRK_3e2m (Raw Value) (32 bytes)
     0c a3 d3 39 82 96 b3 c0 39 00 98 76 20 c1 1f 6f ce 70 78 1c 1d 12 19
     72 0f 9e c0 8c 12 2d 84 34

     The Responder constructs the remaining input needed to calculate
     MAC_2:

     MAC_2 = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 )

     context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>

     CRED_R is identified by a 'kid' with byte string value 0x32:





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


  Internet-Draft               Traces of EDHOC                January 2024


     ID_CRED_R =
     {
      4 : h'32'
     }

     ID_CRED_R (CBOR Data Item) (4 bytes)
     a1 04 41 32

     CRED_R is an RPK encoded as a CCS:

     {                                              /CCS/
       2 : "example.edu",                           /sub/
       8 : {                                        /cnf/
         1 : {                                      /COSE_Key/
           1 : 2,                                   /kty/
           2 : h'32',                               /kid/
          -1 : 1,                                   /crv/
          -2 : h'BBC34960526EA4D32E940CAD2A234148
                 DDC21791A12AFBCBAC93622046DD44F0', /x/
          -3 : h'4519E257236B2A0CE2023F0931F1F386
                 CA7AFDA64FCDE0108C224C51EABF6072'  /y/
         }
       }
     }

     CRED_R (CBOR Data Item) (95 bytes)
     a2 02 6b 65 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32
     20 01 21 58 20 bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2
     17 91 a1 2a fb cb ac 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b
     2a 0c e2 02 3f 09 31 f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea
     bf 60 72

     No external authorization data:

     EAD_2 (CBOR Sequence) (0 bytes)

     context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>

     context_2 (CBOR Sequence) (134 bytes)
     27 a1 04 41 32 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4
     c6 b1 6e 57 02 8f f3 9d 52 36 c1 82 b2 02 08 4b a2 02 6b 65 78 61 6d
     70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 20 01 21 58 20 bb c3
     49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 91 a1 2a fb cb ac
     93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b 2a 0c e2 02 3f 09 31
     f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea bf 60 72






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


  Internet-Draft               Traces of EDHOC                January 2024


     context_2 (CBOR byte string) (136 bytes)
     58 86 27 a1 04 41 32 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8
     3f f4 c6 b1 6e 57 02 8f f3 9d 52 36 c1 82 b2 02 08 4b a2 02 6b 65 78
     61 6d 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 20 01 21 58 20
     bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 91 a1 2a fb
     cb ac 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b 2a 0c e2 02 3f
     09 31 f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea bf 60 72

     MAC_2 is computed through EDHOC_Expand() using the EDHOC hash
     algorithm, see Section 4.1.2 of [I-D.ietf-lake-edhoc]:

     MAC_2 = HKDF-Expand(PRK_3e2m, info, mac_length_2), where

     info = ( 2, context_2, mac_length_2 )

     Since METHOD = 3, mac_length_2 is given by the EDHOC MAC length.

     info for MAC_2 is:

     info =
     (
      2,
      h'27a10441325820356efd53771425e008f3fe3a86c83ff4c6
        b16e57028ff39d5236c182b202084ba2026b6578616d706c
        652e65647508a101a501020241322001215820bbc3496052
        6ea4d32e940cad2a234148ddc21791a12afbcbac93622046
        dd44f02258204519e257236b2a0ce2023f0931f1f386ca7a
        fda64fcde0108c224c51eabf6072',
      8
     )

     where the last value is the EDHOC MAC length in bytes.

     info for MAC_2 (CBOR Sequence) (138 bytes)
     02 58 86 27 a1 04 41 32 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86
     c8 3f f4 c6 b1 6e 57 02 8f f3 9d 52 36 c1 82 b2 02 08 4b a2 02 6b 65
     78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 20 01 21 58
     20 bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17 91 a1 2a
     fb cb ac 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b 2a 0c e2 02
     3f 09 31 f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea bf 60 72 08

     MAC_2 (Raw Value) (8 bytes)
     09 43 30 5c 89 9f 5c 54

     MAC_2 (CBOR Data Item) (9 bytes)
     48 09 43 30 5c 89 9f 5c 54

     Since METHOD = 3, Signature_or_MAC_2 is MAC_2:



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


  Internet-Draft               Traces of EDHOC                January 2024


     Signature_or_MAC_2 (Raw Value) (8 bytes)
     09 43 30 5c 89 9f 5c 54

     Signature_or_MAC_2 (CBOR Data Item) (9 bytes)
     48 09 43 30 5c 89 9f 5c 54

     The Responder constructs PLAINTEXT_2:

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

     Since ID_CRED_R contains a single 'kid' parameter, only the byte
     string value is included in the plaintext, represented as described
     in Section 3.3.2 of [I-D.ietf-lake-edhoc].  The CBOR map { 4 : h'32'
     } is thus replaced, not by the CBOR byte string 0x4132, but by the
     CBOR int 0x32, since that is a one byte encoding of a CBOR integer
     (-19).

     PLAINTEXT_2 (CBOR Sequence) (11 bytes)
     27 32 48 09 43 30 5c 89 9f 5c 54

     The input needed to calculate KEYSTREAM_2 is defined in Section 4.1.2
     of [I-D.ietf-lake-edhoc], using EDHOC_Expand() with the EDHOC hash
     algorithm:

     KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length ) =
                 = HKDF-Expand( PRK_2e, info, plaintext_length )

     where plaintext_length is the length in bytes of PLAINTEXT_2, and
     info for KEYSTREAM_2 is:

     info =
     (
      0,
      h'356efd53771425e008f3fe3a86c83ff4c6b16e57028ff39d
        5236c182b202084b',
      11
     )

     where the last value is the length in bytes of PLAINTEXT_2.






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


  Internet-Draft               Traces of EDHOC                January 2024


     info for KEYSTREAM_2 (CBOR Sequence) (36 bytes)
     00 58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57
     02 8f f3 9d 52 36 c1 82 b2 02 08 4b 0b

     KEYSTREAM_2 (Raw Value) (11 bytes)
     bf 50 e9 e7 ba d0 bb 68 17 33 99

     The Responder calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and
     KEYSTREAM_2:

     CIPHERTEXT_2 (Raw Value) (11 bytes)
     98 62 a1 ee f9 e0 e7 e1 88 6f cd

     The Responder constructs message_2:

     message_2 =
     (
      G_Y_CIPHERTEXT_2,
     )

     where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of
     the raw values of G_Y and CIPHERTEXT_2.

     message_2 (CBOR Sequence) (45 bytes)
     58 2b 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93
     42 2c 8e a0 f9 55 a1 3a 4f f5 d5 98 62 a1 ee f9 e0 e7 e1 88 6f cd

  3.5.  message_3

     The transcript hash TH_3 is calculated using the EDHOC hash
     algorithm:

     TH_3 = H( TH_2, PLAINTEXT_2, CRED_R )

     Input to calculate TH_3 (CBOR Sequence) (140 bytes)
     58 20 35 6e fd 53 77 14 25 e0 08 f3 fe 3a 86 c8 3f f4 c6 b1 6e 57 02
     8f f3 9d 52 36 c1 82 b2 02 08 4b 27 32 48 09 43 30 5c 89 9f 5c 54 a2
     02 6b 65 78 61 6d 70 6c 65 2e 65 64 75 08 a1 01 a5 01 02 02 41 32 20
     01 21 58 20 bb c3 49 60 52 6e a4 d3 2e 94 0c ad 2a 23 41 48 dd c2 17
     91 a1 2a fb cb ac 93 62 20 46 dd 44 f0 22 58 20 45 19 e2 57 23 6b 2a
     0c e2 02 3f 09 31 f1 f3 86 ca 7a fd a6 4f cd e0 10 8c 22 4c 51 ea bf
     60 72

     TH_3 (Raw Value) (32 bytes)
     ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 03 9d f0
     bc 1b bf 0c 16 1b b3 15 5c





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


  Internet-Draft               Traces of EDHOC                January 2024


     TH_3 (CBOR Data Item) (34 bytes)
     58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 03
     9d f0 bc 1b bf 0c 16 1b b3 15 5c

     Since METHOD = 3, the Initiator authenticates using static DH.  The
     EDHOC key exchange algorithm is based on the same curve as for the
     ephemeral keys, which is P-256, since the selected cipher suite is 2.

     The Initiator's static Diffie-Hellman P-256 key pair:

     Initiator's private authentication key
     SK_I (Raw Value) (32 bytes)
     fb 13 ad eb 65 18 ce e5 f8 84 17 66 08 41 14 2e 83 0a 81 fe 33 43 80
     a9 53 40 6a 13 05 e8 70 6b

     Initiator's public authentication key, 'x'-coordinate
     (Raw Value) (32 bytes)
     ac 75 e9 ec e3 e5 0b fc 8e d6 03 99 88 95 22 40 5c 47 bf 16 df 96 66
     0a 41 29 8c b4 30 7f 7e b6

     Initiator's public authentication key, 'y'-coordinate
     (Raw Value) (32 bytes)
     6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 d2 57 e6 db
     3c 2a 93 df 21 ff 3a ff c8

     Since I authenticates with static DH (METHOD = 3), PRK_4e3m is
     derived from SALT_4e3m and G_IY.

     The input needed to calculate SALT_4e3m is defined in Section 4.1.2
     of [I-D.ietf-lake-edhoc], using EDHOC_Expand() with the EDHOC hash
     algorithm:

     SALT_4e3m  = EDHOC_KDF( PRK_3e2m, 5, TH_3, hash_length ) =
                = HKDF-Expand( PRK_3e2m, info, hash_length )

     where hash_length is the length in bytes of the output of the EDHOC
     hash algorithm, and info for SALT_4e3m is:

     info =
     (
      5,
      h'adaf67a78a4bcc91e018f8882762a722000b2507039df0bc
        1bbf0c161bb3155c',
      32
     )






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


  Internet-Draft               Traces of EDHOC                January 2024


     info for SALT_4e3m (CBOR Sequence) (37 bytes)
     05 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07
     03 9d f0 bc 1b bf 0c 16 1b b3 15 5c 18 20

     SALT_4e3m (Raw Value) (32 bytes)
     cf dd f9 51 5a 7e 46 e7 b4 db ff 31 cb d5 6c d0 4b a3 32 25 0d e9 ea
     5d e1 ca f9 f6 d1 39 14 a7

     PRK_4e3m is specified in Section 4.1.1.3 of [I-D.ietf-lake-edhoc].

     Since I authenticates with static DH (METHOD = 3), PRK_4e3m is
     derived from G_IY using EDHOC_Extract() with the EDHOC hash
     algorithm:

     PRK_4e3m = EDHOC_Extract(SALT_4e3m, G_IY) =
              = HMAC-SHA-256(SALT_4e3m, G_IY)

     where G_IY is the ECDH shared secret calculated from G_I and Y, or
     G_Y and I.

     G_IY (Raw Value) (ECDH shared secret) (32 bytes)
     08 0f 42 50 85 bc 62 49 08 9e ac 8f 10 8e a6 23 26 85 7e 12 ab 07 d7
     20 28 ca 1b 5f 36 e0 04 b3

     PRK_4e3m (Raw Value) (32 bytes)
     81 cc 8a 29 8e 35 70 44 e3 c4 66 bb 5c 0a 1e 50 7e 01 d4 92 38 ae ba
     13 8d f9 46 35 40 7c 0f f7

     The Initiator constructs the remaining input needed to calculate
     MAC_3:

     MAC_3 = EDHOC_KDF( PRK_4e3m, 6, context_3, mac_length_3 )

     context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>

     CRED_I is identified by a 'kid' with byte string value 0x2b:

     ID_CRED_I =
     {
      4 : h'2b'
     }

     ID_CRED_I (CBOR Data Item) (4 bytes)
     a1 04 41 2b

     CRED_I is an RPK encoded as a CCS:





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


  Internet-Draft               Traces of EDHOC                January 2024


     {                                              /CCS/
       2 : "42-50-31-FF-EF-37-32-39",               /sub/
       8 : {                                        /cnf/
         1 : {                                      /COSE_Key/
           1 : 2,                                   /kty/
           2 : h'2b',                               /kid/
          -1 : 1,                                   /crv/
          -2 : h'AC75E9ECE3E50BFC8ED6039988952240
                 5C47BF16DF96660A41298CB4307F7EB6'  /x/
          -3 : h'6E5DE611388A4B8A8211334AC7D37ECB
                 52A387D257E6DB3C2A93DF21FF3AFFC8'  /y/
         }
       }
     }

     CRED_I (CBOR Data Item) (107 bytes)
     a2 02 77 34 32 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32
     2d 33 39 08 a1 01 a5 01 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5
     0b fc 8e d6 03 99 88 95 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30
     7f 7e b6 22 58 20 6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52
     a3 87 d2 57 e6 db 3c 2a 93 df 21 ff 3a ff c8

     No external authorization data:

     EAD_3 (CBOR Sequence) (0 bytes)

     context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>

     context_3 (CBOR Sequence) (145 bytes)
     a1 04 41 2b 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00
     0b 25 07 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c a2 02 77 34 32 2d 35 30
     2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 33 39 08 a1 01 a5 01
     02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 0b fc 8e d6 03 99 88 95
     22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 7f 7e b6 22 58 20 6e 5d
     e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 d2 57 e6 db 3c 2a
     93 df 21 ff 3a ff c8

     context_3 (CBOR byte string) (147 bytes)
     58 91 a1 04 41 2b 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7
     22 00 0b 25 07 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c a2 02 77 34 32 2d
     35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 33 39 08 a1 01
     a5 01 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 0b fc 8e d6 03 99
     88 95 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 7f 7e b6 22 58 20
     6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 d2 57 e6 db
     3c 2a 93 df 21 ff 3a ff c8

     MAC_3 is computed through EDHOC_Expand() using the EDHOC hash
     algorithm, see Section 4.1.2 of [I-D.ietf-lake-edhoc]:



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


  Internet-Draft               Traces of EDHOC                January 2024


     MAC_3 = HKDF-Expand(PRK_4e3m, info, mac_length_3), where

     info = ( 6, context_3, mac_length_3 )

     Since METHOD = 3, mac_length_3 is given by the EDHOC MAC length.

     info for MAC_3 is:

     info =
     (
      6,
      h'a104412b5820adaf67a78a4bcc91e018f8882762a722000b
        2507039df0bc1bbf0c161bb3155ca2027734322d35302d33
        312d46462d45462d33372d33322d333908a101a501020241
        2b2001215820ac75e9ece3e50bfc8ed60399889522405c47
        bf16df96660a41298cb4307f7eb62258206e5de611388a4b
        8a8211334ac7d37ecb52a387d257e6db3c2a93df21ff3aff
        c8',
      8
     )

     where the last value is the EDHOC MAC length in bytes.

     info for MAC_3 (CBOR Sequence) (149 bytes)
     06 58 91 a1 04 41 2b 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62
     a7 22 00 0b 25 07 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c a2 02 77 34 32
     2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 33 39 08 a1
     01 a5 01 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 0b fc 8e d6 03
     99 88 95 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 7f 7e b6 22 58
     20 6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87 d2 57 e6
     db 3c 2a 93 df 21 ff 3a ff c8 08

     MAC_3 (Raw Value) (8 bytes)
     62 3c 91 df 41 e3 4c 2f

     MAC_3 (CBOR Data Item) (9 bytes)
     48 62 3c 91 df 41 e3 4c 2f

     Since METHOD = 3, Signature_or_MAC_3 is MAC_3:

     Signature_or_MAC_3 (Raw Value) (8 bytes)
     62 3c 91 df 41 e3 4c 2f

     Signature_or_MAC_3 (CBOR Data Item) (9 bytes)
     48 62 3c 91 df 41 e3 4c 2f

     The Initiator constructs PLAINTEXT_3:




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


  Internet-Draft               Traces of EDHOC                January 2024


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

     Since ID_CRED_I contains a single 'kid' parameter, only the byte
     string value is included in the plaintext, represented as described
     in Section 3.3.2 of [I-D.ietf-lake-edhoc].  The CBOR map { 4 : h'2b'
     } is thus replaced, not by the CBOR byte string 0x412b, but by the
     CBOR int 0x2b, since that is a one byte encoding of a CBOR integer
     (-12).

     PLAINTEXT_3 (CBOR Sequence) (10 bytes)
     2b 48 62 3c 91 df 41 e3 4c 2f

     The Initiator constructs the associated data for message_3:

     A_3 =
     [
      "Encrypt0",
      h'',
      h'adaf67a78a4bcc91e018f8882762a722000b2507039df0bc
        1bbf0c161bb3155c'
     ]

     A_3 (CBOR Data Item) (45 bytes)
     83 68 45 6e 63 72 79 70 74 30 40 58 20 ad af 67 a7 8a 4b cc 91 e0 18
     f8 88 27 62 a7 22 00 0b 25 07 03 9d f0 bc 1b bf 0c 16 1b b3 15 5c

     The Initiator constructs the input needed to derive the key K_3, see
     Section 4.1.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash
     algorithm:

     K_3 = EDHOC_KDF( PRK_3e2m, 3, TH_3, key_length )
         = HKDF-Expand( PRK_3e2m, info, key_length ),

     where key_length is the key length in bytes for the EDHOC AEAD
     algorithm, and info for K_3 is:

     info =
     (
      3,
      h'adaf67a78a4bcc91e018f8882762a722000b2507039df0bc
        1bbf0c161bb3155c',
      16
     )



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


  Internet-Draft               Traces of EDHOC                January 2024


     where the last value is the key length in bytes for the EDHOC AEAD
     algorithm.

     info for K_3 (CBOR Sequence) (36 bytes)
     03 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07
     03 9d f0 bc 1b bf 0c 16 1b b3 15 5c 10

     K_3 (Raw Value) (16 bytes)
     8e 7a 30 04 20 00 f7 90 0e 81 74 13 1f 75 f3 ed

     The Initiator constructs the input needed to derive the nonce IV_3,
     see Section 4.1.2 of [I-D.ietf-lake-edhoc], using the EDHOC hash
     algorithm:

     IV_3 = EDHOC_KDF( PRK_3e2m, 4, TH_3, iv_length )
          = HKDF-Expand( PRK_3e2m, info, iv_length ),

     where iv_length is the nonce length in bytes for the EDHOC AEAD
     algorithm, and info for IV_3 is:

     info =
     (
      4,
      h'adaf67a78a4bcc91e018f8882762a722000b2507039df0bc
        1bbf0c161bb3155c',
      13
     )

     where the last value is the nonce length in bytes for the EDHOC AEAD
     algorithm.

     info for IV_3 (CBOR Sequence) (36 bytes)
     04 58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07
     03 9d f0 bc 1b bf 0c 16 1b b3 15 5c 0d

     IV_3 (Raw Value) (13 bytes)
     6d 83 00 c1 e2 3b 56 15 3a e7 0e e4 57

     The Initiator calculates CIPHERTEXT_3 as 'ciphertext' of
     COSE_Encrypt0 applied using the EDHOC AEAD algorithm with plaintext
     PLAINTEXT_3, additional data A_3, key K_3 and nonce IV_3.

     CIPHERTEXT_3 (Raw Value) (18 bytes)
     e5 62 09 7b c4 17 dd 59 19 48 5a c7 89 1f fd 90 a9 fc

     message_3 is the CBOR bstr encoding of CIPHERTEXT_3:





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


  Internet-Draft               Traces of EDHOC                January 2024


     message_3 (CBOR Sequence) (19 bytes)
     52 e5 62 09 7b c4 17 dd 59 19 48 5a c7 89 1f fd 90 a9 fc

     The transcript hash TH_4 is calculated using the EDHOC hash
     algorithm:

     TH_4 = H( TH_3, PLAINTEXT_3, CRED_I )

     Input to calculate TH_4 (CBOR Sequence) (151 bytes)
     58 20 ad af 67 a7 8a 4b cc 91 e0 18 f8 88 27 62 a7 22 00 0b 25 07 03
     9d f0 bc 1b bf 0c 16 1b b3 15 5c 2b 48 62 3c 91 df 41 e3 4c 2f a2 02
     77 34 32 2d 35 30 2d 33 31 2d 46 46 2d 45 46 2d 33 37 2d 33 32 2d 33
     39 08 a1 01 a5 01 02 02 41 2b 20 01 21 58 20 ac 75 e9 ec e3 e5 0b fc
     8e d6 03 99 88 95 22 40 5c 47 bf 16 df 96 66 0a 41 29 8c b4 30 7f 7e
     b6 22 58 20 6e 5d e6 11 38 8a 4b 8a 82 11 33 4a c7 d3 7e cb 52 a3 87
     d2 57 e6 db 3c 2a 93 df 21 ff 3a ff c8

     TH_4 (Raw Value) (32 bytes)
     c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06 76 56 12
     e5 2b 5d 99 e6 05 9d 6b 6e

     TH_4 (CBOR Data Item) (34 bytes)
     58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06 76
     56 12 e5 2b 5d 99 e6 05 9d 6b 6e

  3.6.  message_4

     No external authorization data:

     EAD_4 (CBOR Sequence) (0 bytes)

     The Responder constructs PLAINTEXT_4:

     PLAINTEXT_4 =
     (
      ? EAD_4
     )

     PLAINTEXT_4 (CBOR Sequence) (0 bytes)

     The Responder constructs the associated data for message_4:










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


  Internet-Draft               Traces of EDHOC                January 2024


     A_4 =
     [
      "Encrypt0",
      h'',
      h'c902b1e3a4326c93c5551f5f3aa6c5ecc0246806765612e5
        2b5d99e6059d6b6e'
     ]

     A_4 (CBOR Data Item) (45 bytes)
     83 68 45 6e 63 72 79 70 74 30 40 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55
     1f 5f 3a a6 c5 ec c0 24 68 06 76 56 12 e5 2b 5d 99 e6 05 9d 6b 6e

     The Responder constructs the input needed to derive the EDHOC
     message_4 key, see Section 4.1.2 of [I-D.ietf-lake-edhoc], using the
     EDHOC hash algorithm:

     K_4   = EDHOC_KDF( PRK_4e3m, 8, TH_4, key_length )
           = HKDF-Expand( PRK_4e3m, info, key_length )

     where key_length is the key length in bytes for the EDHOC AEAD
     algorithm, and info for K_4 is:

     info =
     (
      8,
      h'c902b1e3a4326c93c5551f5f3aa6c5ecc0246806765612e5
        2b5d99e6059d6b6e',
      16
     )

     where the last value is the key length in bytes for the EDHOC AEAD
     algorithm.

     info for K_4 (CBOR Sequence) (36 bytes)
     08 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06
     76 56 12 e5 2b 5d 99 e6 05 9d 6b 6e 10

     K_4 (Raw Value) (16 bytes)
     d3 c7 78 72 b6 ee b5 08 91 1b db d3 08 b2 e6 a0

     The Responder constructs the input needed to derive the EDHOC
     message_4 nonce, see Section 4.1.2 of [I-D.ietf-lake-edhoc], using
     the EDHOC hash algorithm:

           IV_4 = EDHOC_KDF( PRK_4e3m, 9, TH_4, iv_length )
                = HKDF-Expand( PRK_4e3m, info, iv_length )





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


  Internet-Draft               Traces of EDHOC                January 2024


     where iv_length is the nonce length in bytes for the EDHOC AEAD
     algorithm, and info for IV_4 is:

     info =
     (
      9,
      h'c902b1e3a4326c93c5551f5f3aa6c5ecc0246806765612e5
        2b5d99e6059d6b6e',
      13
     )

     where the last value is the nonce length in bytes for the EDHOC AEAD
     algorithm.

     info for IV_4 (CBOR Sequence) (36 bytes)
     09 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06
     76 56 12 e5 2b 5d 99 e6 05 9d 6b 6e 0d

     IV_4 (Raw Value) (13 bytes)
     04 ff 0f 44 45 6e 96 e2 17 85 3c 36 01

     The Responder calculates CIPHERTEXT_4 as 'ciphertext' of
     COSE_Encrypt0 applied using the EDHOC AEAD algorithm with plaintext
     PLAINTEXT_4, additional data A_4, key K_4 and nonce IV_4.

     CIPHERTEXT_4 (8 bytes)
     28 c9 66 b7 ca 30 4f 83

     message_4 is the CBOR bstr encoding of CIPHERTEXT_4:

     message_4 (CBOR Sequence) (9 bytes)
     48 28 c9 66 b7 ca 30 4f 83

  3.7.  PRK_out and PRK_exporter

     PRK_out is specified in Section 4.1.3 of [I-D.ietf-lake-edhoc].

     PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length ) =
             = HKDF-Expand( PRK_4e3m, info,  hash_length )

     where hash_length is the length in bytes of the output of the EDHOC
     hash algorithm, and info for PRK_out is:









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


  Internet-Draft               Traces of EDHOC                January 2024


     info =
     (
      7,
      h'c902b1e3a4326c93c5551f5f3aa6c5ecc0246806765612e5
        2b5d99e6059d6b6e',
      32
     )

     where the last value is the length in bytes of the output of the
     EDHOC hash algorithm.

     info for PRK_out (CBOR Sequence) (37 bytes)
     07 58 20 c9 02 b1 e3 a4 32 6c 93 c5 55 1f 5f 3a a6 c5 ec c0 24 68 06
     76 56 12 e5 2b 5d 99 e6 05 9d 6b 6e 18 20

     PRK_out (Raw Value) (32 bytes)
     2c 71 af c1 a9 33 8a 94 0b b3 52 9c a7 34 b8 86 f3 0d 1a ba 0b 4d c5
     1b ee ae ab df ea 9e cb f8

     The OSCORE Master Secret and OSCORE Master Salt are derived with the
     EDHOC_Exporter as specified in 4.2.1 of [I-D.ietf-lake-edhoc].

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

     where PRK_exporter is derived from PRK_out:

      PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) =
                   = HKDF-Expand( PRK_out, info,  hash_length )

     where hash_length is the length in bytes of the output of the EDHOC
     hash algorithm, and info for the PRK_exporter is:

     info =
     (
      10,
      h'',
      32
     )

     where the last value is the length in bytes of the output of the
     EDHOC hash algorithm.

     info for PRK_exporter (CBOR Sequence) (4 bytes)
     0a 40 18 20






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


  Internet-Draft               Traces of EDHOC                January 2024


     PRK_exporter (Raw Value) (32 bytes)
     e1 4d 06 69 9c ee 24 8c 5a 04 bf 92 27 bb cd 4c e3 94 de 7d cb 56 db
     43 55 54 74 17 1e 64 46 db

  3.8.  OSCORE Parameters

     The derivation of OSCORE parameters is specified in Appendix A.1 of
     [I-D.ietf-lake-edhoc].

     The AEAD and Hash algorithms to use in OSCORE are given by the
     selected cipher suite:

     Application AEAD Algorithm (int)
     10

     Application Hash Algorithm (int)
     -16

     The mapping from EDHOC connection identifiers to OSCORE Sender/
     Recipient IDs is defined in Section 3.3.3 of [I-D.ietf-lake-edhoc].

     C_R is mapped to the Recipient ID of the server, i.e., the Sender ID
     of the client.  The byte string 0x27, which as C_R is encoded as the
     CBOR integer 0x27, is converted to the server Recipient ID 0x27.

     Client's OSCORE Sender ID (Raw Value) (1 byte)
     27

     C_I is mapped to the Recipient ID of the client, i.e., the Sender ID
     of the server.  The byte string 0x37, which as C_I is encoded as the
     CBOR integer 0x0e is converted to the client Recipient ID 0x37.

     Server's OSCORE Sender ID (Raw Value) (1 byte)
     37

     The OSCORE Master Secret is computed through EDHOC_Expand() using the
     Application hash algorithm, see Appendix A.1 of
     [I-D.ietf-lake-edhoc]:

     OSCORE Master Secret = EDHOC_Exporter( 0, h'', oscore_key_length )
     = EDHOC_KDF( PRK_exporter, 0, h'',  oscore_key_length )
     = HKDF-Expand( PRK_exporter, info,  oscore_key_length )

     where oscore_key_length is by default the key length in bytes for the
     Application AEAD algorithm, and info for the OSCORE Master Secret is:






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


  Internet-Draft               Traces of EDHOC                January 2024


     info =
     (
      0,
      h'',
      16
     )

     where the last value is the key length in bytes for the Application
     AEAD algorithm.

     info for OSCORE Master Secret (CBOR Sequence) (3 bytes)
     00 40 10

     OSCORE Master Secret (Raw Value) (16 bytes)
     f9 86 8f 6a 3a ca 78 a0 5d 14 85 b3 50 30 b1 62

     The OSCORE Master Salt is computed through EDHOC_Expand() using the
     Application hash algorithm, see Section 4.2 of [I-D.ietf-lake-edhoc]:

     OSCORE Master Salt = EDHOC_Exporter( 1, h'', oscore_salt_length )
     = EDHOC_KDF( PRK_exporter, 1, h'', oscore_salt_length )
     = HKDF-Expand( PRK_4x3m, info, oscore_salt_length )

     where oscore_salt_length is the length in bytes of the OSCORE Master
     Salt, and info for the OSCORE Master Salt is:

     info =
     (
      1,
      h'',
      8
     )

     where the last value is the length in bytes of the OSCORE Master
     Salt.

     info for OSCORE Master Salt (CBOR Sequence) (3 bytes)
     01 40 08

     OSCORE Master Salt (Raw Value) (8 bytes)
     ad a2 4c 7d bf c8 5e eb

  3.9.  Key Update

     Key update is defined in Appendix H of [I-D.ietf-lake-edhoc].






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


  Internet-Draft               Traces of EDHOC                January 2024


     EDHOC_KeyUpdate( context ):
     PRK_out = EDHOC_KDF( PRK_out, 11, context, hash_length )
             = HKDF-Expand( PRK_out, info, hash_length )

     where hash_length is the length in bytes of the output of the EDHOC
     hash function, context for KeyUpdate is

     context for KeyUpdate (Raw Value) (16 bytes)
     a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea

     context for KeyUpdate (CBOR Data Item) (17 bytes)
     50 a0 11 58 fd b8 20 89 0c d6 be 16 96 02 b8 bc ea

     and where info for key update is:

     info =
     (
      11,
      h'a01158fdb820890cd6be169602b8bcea',
      32
     )

     PRK_out after KeyUpdate (Raw Value) (32 bytes)
     f9 79 53 77 43 fe 0b d6 b9 b1 41 dd bd 79 65 6c 52 e6 dc 7c 50 ad 80
     77 54 d7 4d 07 e8 7d 0d 16

     After key update the PRK_exporter needs to be derived anew:

      PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) =
                   = HKDF-Expand( PRK_out, info,  hash_length )

     where info and hash_length are unchanged as in Section 3.7.

     PRK_exporter after KeyUpdate (Raw Value) (32 bytes)
     00 fc f7 db 9b 2e ad 73 82 4e 7e 83 03 63 c8 05 c2 96 f9 02 83 0f ac
     23 d8 6c 35 9c 75 2f 0f 17

     The OSCORE Master Secret is derived with the updated PRK_exporter:

     OSCORE Master Secret =
     = HKDF-Expand(PRK_exporter, info, oscore_key_length)

     where info and key_length are unchanged as in Section 2.6.

     OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes)
     49 f7 2f ac 02 b4 65 8b da 21 e2 da c6 6f c3 74

     The OSCORE Master Salt is derived with the updated PRK_exporter:



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


  Internet-Draft               Traces of EDHOC                January 2024


     OSCORE Master Salt = HKDF-Expand(PRK_exporter, info, salt_length)

     where info and salt_length are unchanged as in Section 2.6.

     OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes)
     dd 8b 24 f2 aa 9b 01 1a

  4.  Invalid Traces

     This section contains examples of invalid messages, which a compliant
     implementation will not compose and must or may reject according to
     [I-D.ietf-lake-edhoc], [RFC8949], [RFC9053], and [SP-800-56A].  This
     is just a small set of examples of different reasons a message might
     be invalid.  The same types of invalidities applies to other fields
     and messages as well.  Implementations should make sure to check for
     similar types of invalidities in all EHDOC fields and messages.

  4.1.  Encoding Errors

  4.1.1.  Surplus array encoding of message

     Invalid encoding of message_1 as array.  Correct encoding is a CBOR
     sequence according to Section 5.2.1 of [I-D.ietf-lake-edhoc].

     Invalid message_1 (38 bytes)
     84 03 02 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b
     3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e

  4.1.2.  Surplus bstr encoding of connection identifier

     Invalid encoding 41 0e of C_I = 0x0e.  Correct encoding is 0e
     according to Section 3.3.2 of [I-D.ietf-lake-edhoc].

     Invalid message_1 (38 bytes)
     03 02 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b 3d
     8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 41 0e

  4.1.3.  Surplus array encoding of ciphersuite

     Invalid array encoding 81 02 of SUITES_I = 2.  Correct encoding is 02
     according to Section 5.2.2 of [I-D.ietf-lake-edhoc].

     Invalid message_1 (38 bytes)
     03 81 02 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea 5b
     3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e






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


  Internet-Draft               Traces of EDHOC                January 2024


  4.1.4.  Text string encoding of ephemeral key

     Invalid type of the third element (G_X).  Correct encoding is a byte
     string according to Section 5.2.1 of [I-D.ietf-lake-edhoc].

     Invalid message_1 (37 bytes)
     03 02 78 20 20 61 69 72 20 73 70 65 65 64 20 6F 66 20 61 20 75 6E 6C
     61 64 65 6E 20 73 77 61 6C 6C 6F 77 20 0e

  4.1.5.  Wrong number of CBOR sequence elements

     Invalid number of elements in the CBOR sequence.  Correct number of
     elements is 1 according to Section 5.3.1 of [I-D.ietf-lake-edhoc].

     Invalid message_2 (46 bytes)
     58 20 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37 63 c8 93
     42 2c 8e a0 f9 55 a1 3a 4f f5 d5 4B 98 62 a1 1d e4 2a 95 d7 85 38 6a

  4.1.6.  Surplus map encoding of ID_CRED field

     Invalid encoding a1 04 42 32 10 of ID_CRED_R in PLAINTEXT_2.  Correct
     encoding is 42 32 10 according to Section 3.5.3.2 of
     [I-D.ietf-lake-edhoc].

     Invalid PLAINTEXT_2 (15 bytes)
     27 a1 04 42 32 10 48 fa 5e fa 2e bf 92 0b f3

  4.1.7.  Surplus bstr encoding of ID_CRED field

     Invalid encoding 41 32 of ID_CRED_R in PLAINTEXT_2.  Correct encoding
     is 32 according to Section 3.5.3.2 of [I-D.ietf-lake-edhoc].

     Invalid PLAINTEXT_2 (12 bytes)
     27 41 32 48 fa 5e fa 2e bf 92 0b f3

  4.2.  Crypto-related Errors

  4.2.1.  Error in length of ephemeral key

     Invalid length of the third element (G_X).  Selected cipher suite is
     cipher suite 24 with curve P-384 according to Sections 5.2.2, and
     10.2 of [I-D.ietf-lake-edhoc].  Correct length of x-coordinate is 48
     bytes according to Section 3.7 of [I-D.ietf-lake-edhoc] and
     Section 7.1.1 of [RFC9053].

     Invalid message_1 (40 bytes)
     03 82 02 18 18 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b
     ea 5b 3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e



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


  Internet-Draft               Traces of EDHOC                January 2024


  4.2.2.  Error in elliptic curve representation

     Invalid x-coordinate in G_X as x ≥ p.  Requirement that x < p
     according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
     of [SP-800-56A].

     Invalid message_1 (37 bytes)
     03 02 58 20 ff ff ff ff 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
     00 ff ff ff ff ff ff ff ff ff ff ff ff 0e

  4.2.3.  Error in elliptic curve point

     Invalid x-coordinate in (G_X) not corresponding to a point on the
     P-256 curve.  Requirement that y^2 ≡ x^3 + a ⋅ x + b (mod p)
     according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
     of [SP-800-56A].

     Invalid message_1 (37 bytes)
     03 02 58 20 a0 4e 73 60 1d f5 44 a7 0b a7 ea 1e 57 03 0f 7d 4b 4e b7
     f6 73 92 4e 58 d5 4c a7 7a 5e 7d 4d 4a 0e

  4.2.4.  Curve point of low order

     Curve25519 point of low order which fails the check for all-zero
     output according to Section 9.2 of [I-D.ietf-lake-edhoc].

     Invalid message_1 (37 bytes)
     03 00 58 20 ed ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff ff ff ff ff 7f 0e

  4.2.5.  Error in length of MAC

     Invalid length of third element (Signature_or_MAC_2).  The length of
     Signature_or_MAC_2 is given by the cipher suite and the MAC length is
     at least 8 bytes according to Section 9.3 of [I-D.ietf-lake-edhoc].

     Invalid PLAINTEXT_2 (7 bytes)
     27 32 44 fa 5e fa 2e

  4.2.6.  Error in elliptic curve encoding

     Invalid encoding of third element (G_X).  Correct encoding is with
     leading zeros according to Section 3.7 of [I-D.ietf-lake-edhoc] and
     Section 7.1.1 of [RFC9053].

     Invalid message_1 (36 bytes)
     03 02 58 1f d9 69 77 25 d2 3a 68 8b 12 d1 c7 e0 10 8a 08 c9 f7 1a 85
     a0 9c 20 81 49 76 ab 21 12 22 48 fc 0e



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


  Internet-Draft               Traces of EDHOC                January 2024


  4.3.  Non-deterministic CBOR

  4.3.1.  Unnecessary long encoding

     Invalid 16-bit encoding 19 00 03 of METHOD = 3.  Correct is the
     deterministic encoding 03 according to Section 3.1 of
     [I-D.ietf-lake-edhoc] and Section 4.2.1 of [RFC8949], which states
     that the arguments for integers, lengths in major types 2 through 5,
     and tags are required to be as short as possible.

     Invalid message_1 (39 bytes)
     19 00 03 02 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b ea
     5b 3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e

  4.3.2.  Indefinite-length array encoding

     Invalid indefinite-length array encoding 9F 06 02 FF of SUITES_I =
     [6, 2].  Correct encoding is 82 06 02 according to Section 5.2.2 of
     [I-D.ietf-lake-edhoc].

     Invalid message_1 (40 bytes)
     03 9F 06 02 FF 58 20 74 1a 13 d7 ba 04 8f bb 61 5e 94 38 6a a3 b6 1b
     ea 5b 3d 8f 65 f3 26 20 b7 49 be e8 d2 78 ef a9 0e

  5.  Security Considerations

     This document contains examples of EDHOC [I-D.ietf-lake-edhoc] whose
     security considerations apply.  The keys printed in these examples
     cannot be considered secret and MUST NOT be used.

  6.  IANA Considerations

     There are no IANA considerations.

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







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


  Internet-Draft               Traces of EDHOC                January 2024


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

  7.2.  Informative References

     [CborMe]   Bormann, C., "CBOR playground", August 2023,
                <https://cbor.me/>.

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

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8032>.

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

     [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
                August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

     [SP-800-186]
                Chen, L., Moody, D., Randall, K., Regenscheid, A., and A.
                Robinson, "Recommendations for Discrete Logarithm-based
                Cryptography: Elliptic Curve Domain Parameters",
                NIST Special Publication 800-186, February 2023,
                <https://doi.org/10.6028/NIST.SP.800-186>.




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


  Internet-Draft               Traces of EDHOC                January 2024


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

  Acknowledgments

     The authors want to thank all people verifying EDHOC test vectors
     and/or contributing to the interoperability testing including:
     Christian Amsüss, Timothy Claeys, Stefan Hristozov, Rikard Höglund,
     Christos Koulamas, Francesca Palombini, Lidia Pocero, Peter van der
     Stok, and Michel Veillette.

  Authors' Addresses

     Göran Selander
     Ericsson
     Sweden
     Email: goran.selander@ericsson.com


     John Preuß Mattsson
     Ericsson
     Sweden
     Email: john.mattsson@ericsson.com


     Marek Serafin
     ASSA ABLOY
     Poland
     Email: marek.serafin@assaabloy.com


     Marco Tiloca
     RISE
     Sweden
     Email: marco.tiloca@ri.se


     Mališa Vučinić
     Inria
     France
     Email: malisa.vucinic@inria.fr






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


name: draft-lopez-lake-edhoc-psk
rev: 03
title: EDHOC PSK authentication
time: 2025-01-21T12:27:46Z
group_uri: /api/v1/group/group/2249/
expires: 2025-07-25T12:27:46Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/35/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-03-04T00:00:05.696806+00:00
source: ietf
abstract:
  This document specifies the Pre-Shared Key (PSK) authentication
     method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key
     exchange protocol.  It describes the authentication processes,
     message flows, and security considerations of this authentication
     method.

full_text:
  LAKE Working Group                                        E. Lopez-Perez
  Internet-Draft                                                     Inria
  Intended status: Informational                               G. Selander
  Expires: 25 July 2025                                     J. P. Mattsson
                                                                  Ericsson
                                                            R. Marin-Lopez
                                                      University of Murcia
                                                           21 January 2025


                          EDHOC PSK authentication
                       draft-lopez-lake-edhoc-psk-03

  Abstract

     This document specifies the Pre-Shared Key (PSK) authentication
     method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key
     exchange protocol.  It describes the authentication processes,
     message flows, and security considerations of this authentication
     method.

  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://elsalopez133.github.io/draft-lopez-lake-edhoc-psk/#go.draft-
     lopez-lake-edhoc-psk.html.  Status information for this document may
     be found at https://datatracker.ietf.org/doc/draft-lopez-lake-edhoc-
     psk/.

     Discussion of this document takes place on the LAKE Working Group
     mailing list (mailto:lake@ietf.org), which is archived at
     https://example.com/WG.  Subscribe at
     https://www.ietf.org/mailman/listinfo/lake/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ElsaLopez133/draft-lopez-lake-psk.

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



  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 1]


  Internet-Draft             TODO - Abbreviation              January 2025


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

  Copyright Notice

     Copyright (c) 2025 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
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Credentials . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Message flow of PSK . . . . . . . . . . . . . . . . . . .   5
     4.  Key derivation  . . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Message formatting and processing.  Differences with respect to
             RFC9528 . . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Message 1 . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.2.  Message 2 . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.3.  Message 3 . . . . . . . . . . . . . . . . . . . . . . . .   7
       5.4.  Message 4 . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
       6.1.  Identity protection . . . . . . . . . . . . . . . . . . .   8
       6.2.  Number of messages  . . . . . . . . . . . . . . . . . . .   8
       6.3.  External Authorization Data . . . . . . . . . . . . . . .   9
       6.4.  Attacks . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
     8.  Unified Approach and Recommendations  . . . . . . . . . . . .   9
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     10. Normative References  . . . . . . . . . . . . . . . . . . . .   9
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10



  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 2]


  Internet-Draft             TODO - Abbreviation              January 2025


  1.  Introduction

  1.1.  Motivation

     Pre-shared key (PSK) authentication method provides a balance between
     security and computational efficiency.  This authentication method
     was proposed in the first I-Ds of Ephemeral Diffie-Hellman Over COSE
     (EDHOC) [RFC9528], and was ruled out to speed out the development
     process.  However, there is now a renewed effort to reintroduce PSK
     authentication, making this draft an update to the [RFC9528].

     EDHOC with PSK authentication could be beneficial for existing
     systems where two nodes have been provided with a PSK from other
     parties out of band.  This allows the nodes to perform ephemeral
     Diffie-Hellman to achieve Perfect Forward Secrecy (PFS), ensuring
     that past communications remain secure even if the PSK is
     compromised.  The authentication provided by EDHOC prevents
     eavesdropping by on-path attackers, as they would need to be active
     participants in the communication to intercept and potentially tamper
     with the session.  Examples could be Generic Bootstrapping
     Architecture (GBA) and Authenticated Key Management Architecture
     (AKMA) in mobile systems, or Peer and Authenticator in EAP.

     Another prominent use case of PSK authentication in the EDHOC
     protocol is session resumption.  This allows previously connected
     parties to quickly reestablish secure communication using pre-shared
     keys from their earlier session, reducing the overhead of full key
     exchange.  This efficiency is beneficial in scenarios where frequent
     key updates are needed, such in resource-constrained environments or
     applications requiring high-frequency secure communications.  The use
     of PSK authentication in EDHOC ensures that session key can be
     refreshed without heavy computational overhead, typically associated
     with public key operations, thus optimizing both performance and
     security.

  1.2.  Assumptions

  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.







  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 3]


  Internet-Draft             TODO - Abbreviation              January 2025


  3.  Protocol

     In this method, the Pre-Shared Key identifier (ID_CRED_PSK) is sent
     in message_3.  The ID_CRED_PSK allows retrieval of CRED_PSK, a COSE
     object that contains the PSK.  Through this document we will refer to
     the Pre-Shared Key authentication method as EDHOC-PSK.

  3.1.  Credentials

     Initiator and Responder are assumed to have a PSK with good amount of
     randomness and the requirements that:

     *  Only the Initiator and the Responder have access to the PSK.

     *  The Responder is able to retrieve the PSK using ID_CRED_PSK.

     where:

     *  ID_CRED_PSK is a COSE header map containing header parameters that
        can identify a pre-shared key.  For example:

     ID_CRED_PSK = {4 : h'lf' }

     *  CRED_PSK is a COSE_Key compatible credential, encoded as a CCS or
        CWT.  For example:

     {                                               /CCS/
       2 : "mydotbot",                               /sub/
       8 : {                                         /cnf/
         1 : {                                       /COSE_Key/
            1 : 4,                                   /kty/
            2 : h'32',                               /kid/
           -1 : h'50930FF462A77A3540CF546325DEA214'  /k/
         }
       }
     }

     The purpose of ID_CRED_PSK is to facilitate the retrieval of the PSK.
     It is RECOMMENDED that it uniquely identifies the CRED_PSK as the
     recipient might otherwise have to try several keys.  If ID_CRED_PSK
     contains a single 'kid' parameter, then the compact encoding is
     applied; see Section 3.5.3.2 of [RFC9528].  The authentication
     credential CRED_PSK substitutes CRED_I and CRED_R specified in
     [RFC9529], and, when applicable, MUST follow the same guidelines
     described in Sections 3.5.2 and 3.5.3 of [RFC9528].






  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 4]


  Internet-Draft             TODO - Abbreviation              January 2025


  3.2.  Message flow of PSK

     The ID_CRED_PSK is sent in message_3, encrypted using a key derived
     from the ephemeral shared secret, G_XY.  The Responder authenticates
     the Initiator first.  Figure 1 shows the message flow of PSK
     authentication method.

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

                   Figure 1: Overview of message flow of PSK.

     This approach provides protection against passive attackers for both
     Initiator and Responder. message_4 remains optional, but is needed to
     to authenticate the Responder and achieve mutual authentication in
     EDHOC if not relaying on external applications, such as OSCORE.  With
     this fourth message, the protocol achieves both explicit key
     confirmation and mutual authentication.

  4.  Key derivation

     The pseudorandom keys (PRKs) used for PSK authentication method in
     EDHOC are derived using EDHOC_Extract, as done in [RFC9528].

     PRK  = EDHOC_Extract( salt, IKM )

     where the salt and input keying material (IKM) are defined for each
     key.  The definition of EDHOC_Extract depends on the EDHOC hash
     algorithm selected in the cipher suite.

     Figure 2 lists the key derivations that differ from those specified
     in Section 4.1.2 of [RFC9528].





  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 5]


  Internet-Draft             TODO - Abbreviation              January 2025


    PRK_3e2m      = PRK_2e
    PRK_4e3m      = EDHOC_Extract( SALT_4e3m, CRED_PSK )
    KEYSTREAM_3   = EDHOC_KDF( PRK_3e2m,    TBD,  TH_3,       key_length )
    K_3           = EDHOC_KDF( PRK_4e3m,    TBD,  TH_3,  key_length )
    IV_3          = EDHOC_KDF( PRK_4e3m,    TBD,  TH_3,  iv_length  )

         Figure 2: Key derivation of EDHOC PSK authentication method.

     where:

     *  KEYSTREAM_3 is used to encrypt the ID_CRED_PSK in message_3.

     *  TH_3 = H( TH_2, PLAINTEXT_2, CRED_PSK )

     *  TH_4 = H( TH_3, ID_CRED_PSK, ? EAD_3, CRED_PSK )

  5.  Message formatting and processing.  Differences with respect to
      [RFC9528]

     This section specifies the differences on the message formatting
     compared to [RFC9528].

  5.1.  Message 1

     Same as message_1 of EDHOC, described in Section 5.2.1 of [RFC9528].

  5.2.  Message 2

     message_2 SHALL be a CBOR sequence, defined as:

     message_2 = (
       G_Y_CIPHERTEXT_2 : bstr,
     )

     where:

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

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

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

        -  CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2

     Contrary to [RFC9528], MAC_2 is not used.




  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 6]


  Internet-Draft             TODO - Abbreviation              January 2025


  5.3.  Message 3

     message_3 SHALL be a bit string, as defined below:

     message_3 = (
       CIPHERTEXT_3: bstr,
     )

     where:

     *  CIPHERTEXT_3 is a concatenation of two different ciphertexts, each
        of it a CBOR Sequence:

        -  CIPHERTEXT_3A is CBOR Sequence calculated with a binary
           additive stream cipher, using a KESYSTREAM_3 generated with
           EDHOC_Expand and the following plaintext:

           o  PLAINTEXT_3A = ( ID_CRED_PSK )

        -  CIPHERTEXT_3B is 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
           parameters described in Section 5.2 of [RFC9528], plaintext
           PLAINTEXT_3B and the following parameters as input:

           o  protected = h''

           o  external_aad = << Enc(ID_CRED_PSK), TH_3 >>

           o  K_3 and IV_3 as defined in Section 5.2

           o  PLAINTEXT_3B = ( ? EAD_3 )

     The Initiator computes TH_4 = H( TH_3, ID_CRED_PSK, PLAINTEXT_3,
     CRED_PSK ), defined in Section 5.2.

  5.4.  Message 4

     message_4 is mandatory and is a CBOR sequence, defined as:

     message_4 = (
       CIPHERTEXT_4 : bstr,
     )







  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 7]


  Internet-Draft             TODO - Abbreviation              January 2025


     A fourth message is mandatory for Responder's authentication.  The
     Initiator MUST 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.

  6.  Security Considerations

     When evaluating the security considerations, it is important to
     differentiate between the initial handshake and session resumption
     phases.

     1.  *Initial Handshake*: a fresh CRED_PSK is used to establish a
         secure connection.

     2.  *Session Resumption*: the same PSK identifier (ID_CRED_PSK) is
         reused each time EDHOC is executed.  While this enhances
         efficiency and reduces the overhead of key exchanges, it presents
         privacy risks if not managed properly.  Over multiple resumption
         sessions, initiating a full EDHOC session changes the resumption
         PSK, resulting in a new ID_CRED_PSK.  The periodic renewal of the
         CRED_PSK and ID_CRED_PSK helps mitigate long-term privacy risks
         associated with static key identifiers.

  6.1.  Identity protection

     The current EDHOC methods protect the Initiator’s identity against
     active attackers and the Responder’s identity against passive
     attackers (See Section 9.1 of [RFC9528]).  With EDHOC-PSK
     authentication method, both the Initiator's and Responder's
     identities are protected against passive attackers, but not against
     active attackers.

  6.2.  Number of messages

     The current EDHOC protocol consists of three mandatory messages and
     an optional fourth message.  In the case of EDHOC-PSK authentication
     method, message_4 remains optional, but mutual authentication is not
     guaranteed without it, or an OSCORE message or any application data
     that confirms that the Responder owns the PSK.  Additionally, with
     this fourth message the protocol achieves explicit key confirmation
     in addition to mutual authentication.









  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 8]


  Internet-Draft             TODO - Abbreviation              January 2025


  6.3.  External Authorization Data

     The Initiator and Responder can send information in EAD_3 and EAD_4
     or in OSCORE messages in parallel with message_3 and message_4.  This
     is possible because the Initiator knows that only the Responder with
     access to the CRED_PSK can decrypt the information.

  6.4.  Attacks

     EDHOC-PSK authentication method offers privacy and resistance to
     passive attacks but might be vulnerable to certain active attacks due
     to delayed authentication.

  7.  Privacy Considerations

  8.  Unified Approach and Recommendations

     For use cases involving the transmission of application data,
     application data can be sent concurrently with message_3, maintaining
     the protocol's efficiency.  In applications such as EAP-EDHOC, where
     application data is not sent, message_4 is mandatory.  Thus, EDHOC-
     PSK authentication method doe snot include any extra messages.  Other
     implementations may continue using OSCORE in place of EDHOC
     message_4, with a required change in the protocol's language to: The
     Initiator SHALL 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.

     This change ensures that key materials are only stored once their
     integrity and authenticity are confirmed, thereby enhancing privacy
     by preventing early storage of potentially compromised keys.

     Lastly, whether the Initiator or Responder authenticates first is not
     relevant when using symmetric keys.  This consideration was important
     for the privacy properties when using asymmetric authentication but
     is not significant in the context of symmetric key usage.

  9.  IANA Considerations

     This document has no IANA actions.

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




  Lopez-Perez, et al.       Expires 25 July 2025                  [Page 9]


  Internet-Draft             TODO - Abbreviation              January 2025


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

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

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

     [RFC9529]  Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,
                and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over
                COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024,
                <https://www.rfc-editor.org/rfc/rfc9529>.

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Elsa Lopez-Perez
     Inria
     Email: elsa.lopez-perez@inria.fr


     Göran Selander
     Ericsson
     Email: goran.selander@ericsson.com


     John Preuß Mattsson
     Ericsson
     Email: john.mattsson@ericsson.com


     Rafael Marin-Lopez
     University of Murcia
     Email: rafa@um.es








  Lopez-Perez, et al.       Expires 25 July 2025                 [Page 10]


name: draft-tiloca-lake-app-profiles
rev: 03
title: Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)
time: 2024-12-09T09:43:08Z
group_uri: /api/v1/group/group/2249/
expires: 2025-04-24T13:33:03Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-03-04T00:00:05.699700+00:00
source: ietf
abstract:
  The lightweight authenticated key exchange protocol Ephemeral Diffie-
     Hellman Over COSE (EDHOC) requires certain parameters to be agreed
     out-of-band, in order to ensure its successful completion.  To this
     end, application profiles specify the intended use of EDHOC to allow
     for the relevant processing and verifications to be made.  This
     document defines a number of means to coordinate the use and
     discovery of EDHOC application profiles.  Also, it defines a
     canonical, CBOR-based representation that can be used to describe,
     distribute, and store EDHOC application profiles.  Finally, this
     document defines a set of well-known EDHOC application profiles.

full_text:
  LAKE Working Group                                             M. Tiloca
  Internet-Draft                                                R. Höglund
  Intended status: Standards Track                                 RISE AB
  Expires: 24 April 2025                                   21 October 2024


     Coordinating the Use of Application Profiles for Ephemeral Diffie-
                         Hellman Over COSE (EDHOC)
                     draft-tiloca-lake-app-profiles-03

  Abstract

     The lightweight authenticated key exchange protocol Ephemeral Diffie-
     Hellman Over COSE (EDHOC) requires certain parameters to be agreed
     out-of-band, in order to ensure its successful completion.  To this
     end, application profiles specify the intended use of EDHOC to allow
     for the relevant processing and verifications to be made.  This
     document defines a number of means to coordinate the use and
     discovery of EDHOC application profiles.  Also, it defines a
     canonical, CBOR-based representation that can be used to describe,
     distribute, and store EDHOC application profiles.  Finally, this
     document defines a set of well-known EDHOC application profiles.

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

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







  Tiloca & Höglund          Expires 24 April 2025                 [Page 1]


  Internet-Draft         EDHOC Application Profiles           October 2024


     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 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
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Identifying EDHOC Application Profiles by Profile ID  . . . .   5
       2.1.  Web Linking . . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.  EDHOC_Information Object  . . . . . . . . . . . . . . . .   7
         2.2.1.  Use in the EDHOC and OSCORE Profile of the ACE
                 Framework . . . . . . . . . . . . . . . . . . . . . .   8
     3.  Additional Parameters for Web Linking . . . . . . . . . . . .   9
     4.  Additional Parameters of the EDHOC_Information Object . . . .  10
     5.  Representation of an EDHOC Application Profile  . . . . . . .  12
     6.  Well-known EDHOC Application Profiles . . . . . . . . . . . .  14
       6.1.  Well-Known Application Profile WK-MINIMAL_CS_2  . . . . .  14
       6.2.  Well-Known Application Profile WK-MINIMAL_CS_0  . . . . .  15
       6.3.  Well-Known Application Profile WK-BASIC_CS_2_X509 . . . .  15
       6.4.  Well-Known Application Profile WK-BASIC_CS_0_X509 . . . .  15
       6.5.  Well-Known Application Profile WK-BASIC_CS_2_C509 . . . .  15
       6.6.  Well-Known Application Profile WK-BASIC_CS_0_C509 . . . .  16
       6.7.  Well-Known Application Profile WK-INTERMEDIATE_CS_2 . . .  16
       6.8.  Well-Known Application Profile WK-INTERMEDIATE_CS_0 . . .  16
       6.9.  Well-Known Application Profile WK-ADVANCED  . . . . . . .  16
     7.  EDHOC Well-known Application Profiles . . . . . . . . . . . .  17
     8.  EDHOC Endpoint Identity Types . . . . . . . . . . . . . . . .  18
     9.  EDHOC Transports  . . . . . . . . . . . . . . . . . . . . . .  19
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  19
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20



  Tiloca & Höglund          Expires 24 April 2025                 [Page 2]


  Internet-Draft         EDHOC Application Profiles           October 2024


       11.1.  Media Type Registrations . . . . . . . . . . . . . . . .  20
       11.2.  CoAP Content-Formats Registry  . . . . . . . . . . . . .  21
       11.3.  Target Attributes Registry . . . . . . . . . . . . . . .  21
       11.4.  EDHOC Information Registry . . . . . . . . . . . . . . .  22
       11.5.  EDHOC Application Profiles Registry  . . . . . . . . . .  24
       11.6.  EDHOC Endpoint Identity Types Registry . . . . . . . . .  25
       11.7.  EDHOC Transport Registry . . . . . . . . . . . . . . . .  26
       11.8.  Expert Review Instructions . . . . . . . . . . . . . . .  27
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  27
       12.2.  Informative References . . . . . . . . . . . . . . . . .  30
     Appendix A.  CDDL Model . . . . . . . . . . . . . . . . . . . . .  30
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  31
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

  1.  Introduction

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

     In order to successfully run EDHOC, the two peers acting as Initiator
     and Responder have to agree on certain parameters.  Some of those are
     in-band and communicated through the protocol execution, during which
     a few of them may even be negotiated.  However, other parameters have
     to be known out-of-band, before running the EDHOC protocol.

     As discussed in Section 3.9 of [RFC9528], applications can use EDHOC
     application profiles, which specify the intended usage of EDHOC to
     allow for the relevant processing and verifications to be made.  In
     particular, an EDHOC application profile may include both in-band and
     out-of-band parameters.

     This document defines a number of means to coordinate the use and
     discovery of EDHOC application profiles, that is:

     *  The new IANA registry "EDHOC Application Profiles" defined in
        Section 11.5, where to register integer identifiers of EDHOC
        application profiles to use as corresponding Profile IDs.

     *  The new parameter "ed-prof" defined in Section 2.1.  This
        parameter is employed to specify an EDHOC application profile
        identified by its Profile ID, and can be used as target attribute
        in a web link [RFC8288] to an EDHOC resource, or as filter
        criteria in a discovery request to discover EDHOC resources.






  Tiloca & Höglund          Expires 24 April 2025                 [Page 3]


  Internet-Draft         EDHOC Application Profiles           October 2024


        For instance, the target attribute can be used in a link-format
        document [RFC6690] describing EDHOC resources at a server, when
        EDHOC is transferred over CoAP [RFC7252] (see Appendix A.2 of
        [RFC9528] as well as [I-D.ietf-core-oscore-edhoc]).

     *  The new parameter "app_prof" defined in Section 2.2 for the
        EDHOC_Information object specified in
        [I-D.ietf-ace-edhoc-oscore-profile].  This parameter is employed
        to specify a set of EDHOC application profiles, each identified by
        its Profile ID.

        For instance, the parameter can be used in the EDHOC and OSCORE
        profile [I-D.ietf-ace-edhoc-oscore-profile] of the ACE framework
        for authentication and authorization in constrained environments
        (ACE) [RFC9200], in order to indicate the EDHOC application
        profiles supported by an ACE resource server.

     *  Additional parameters that provide information about an EDHOC
        application profile.  A subset of these parameters are to be used
        as target attributes in a web link to an EDHOC resource, or as
        filter criteria in a discovery request to discover EDHOC resources
        (see Section 3).  Another subset of these parameters are to be
        used as elements of the EDHOC_Information object (see Section 4).

     In order to ensure the applicability of such parameters beyond
     transport- or setup-specific scenarios, this document also defines a
     canonical, CBOR-based representation that can be used to describe,
     distribute, and store EDHOC application profiles as CBOR data items
     (see Section 5).  The defined representation is transport- and setup-
     independent, and avoids the need to reinvent an encoding for the
     available options to run the EDHOC protocol or the selection logic to
     apply on those.

     The CBOR-based representation of an EDHOC application profile can be,
     for example: retrieved as a result of a discovery process; or
     retrieved/provided during the retrieval/provisioning of an EDHOC
     peer's public authentication credential; or obtained during the
     execution of a device on-boarding/registration workflow.

     Finally, this document defines a set of well-known EDHOC application
     profiles (see Section 6).  These application profiles are meant to
     reflect what is most common and expected to be supported by EDHOC
     peers, while they are not to be intended as "default" application
     profiles or as a deviation from what is mandatory to support for
     EDHOC peers (see Section 8 of [RFC9528]).






  Tiloca & Höglund          Expires 24 April 2025                 [Page 4]


  Internet-Draft         EDHOC Application Profiles           October 2024


  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 defined
     in EDHOC [RFC9528], and with the use of EDHOC with CoAP [RFC7252] and
     OSCORE [RFC8613] defined in [I-D.ietf-core-oscore-edhoc].

     Concise Binary Object Representation (CBOR) [RFC8949] and Concise
     Data Definition Language (CDDL) [RFC8610] are used in this document.
     CDDL predefined type names, especially bstr for CBOR byte strings and
     tstr for CBOR text strings, are used extensively in this document.

     CBOR data items are represented using the CBOR extended diagnostic
     notation as defined in Section 8 of [RFC8949] and Appendix G of
     [RFC8610] ("diagnostic notation").  Diagnostic notation comments are
     used to provide a textual representation of the parameters' keys and
     values.

     In the CBOR diagnostic notation used in this document, constructs of
     the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME
     in the CDDL model shown in Figure 2 of Appendix A.  For example,
     {e'methods' : [0, 1, 2, 3], e'cipher_suites': 3} stands for {1 : [0,
     1, 2, 3], 2 : 3}.

     Note to RFC Editor: Please delete the paragraph immediately preceding
     this note.  Also, in the CBOR diagnostic notation used in this
     document, please replace the constructs of the form e'SOME_NAME' with
     the value assigned to SOME_NAME in the CDDL model shown in Figure 2
     of Appendix A.  Finally, please delete this note.

  2.  Identifying EDHOC Application Profiles by Profile ID

     This section defines two means to identify EDHOC application profiles
     by their Profile IDs, i.e., the parameter "ed-prof" for web linking
     (see Section 2.1) and the parameter "app_prof" of the
     EDHOC_Information object (see Section 2.2).










  Tiloca & Höglund          Expires 24 April 2025                 [Page 5]


  Internet-Draft         EDHOC Application Profiles           October 2024


  2.1.  Web Linking

     Section 6 of [I-D.ietf-core-oscore-edhoc] defines a number of target
     attributes that can be used in a web link [RFC8288] with resource
     type "core.edhoc" (see Section 10.10 of [RFC9528]).  This is the
     case, e.g., when using a link-format document [RFC6690] describing
     EDHOC resources at a server, when EDHOC is transferred over CoAP
     [RFC7252] as defined in Appendix A.2 of [RFC9528].  This allows a
     client to obtain relevant information about the EDHOC application
     profile(s) to be used with a certain EDHOC resource.

     In the same spirit, this section defines the following additional
     parameter, which can be optionally specified as a target attribute
     with the same name in the link to the respective EDHOC resource, or
     among the filter criteria in a discovery request from a client.

     *  'ed-prof', specifying an EDHOC application profile supported by
        the server.  This parameter MUST specify a single value, which is
        taken from the 'Profile ID' column of the "EDHOC Application
        Profiles" registry defined in Section 11.5 of this document.  This
        parameter MAY occur multiple times, with each occurrence
        specifying an EDHOC application profile.

     When specifying the parameter 'ed-prof' in a link to an EDHOC
     resource, the target attribute rt="core.edhoc" MUST be included.

     If a link to an EDHOC resource includes occurrences of the target
     attribute 'ed-prof', then the following applies.

     *  The link MUST NOT include other target attributes that provide
        information about an EDHOC application profile (see, e.g.,
        Section 6 of [I-D.ietf-core-oscore-edhoc] and Section 3 of this
        document), with the exception of the target attribute 'ed-ead'
        that MAY be included.

        The recipient MUST ignore other target attributes that provide
        information about an EDHOC application profile, with the exception
        of the target attribute 'ed-ead'.

     *  If the link includes occurrences of the target attribute 'ed-ead',
        the link provides the following information: when using the target
        EDHOC resource as per the EDHOC application profile indicated by
        any occurrence of the target attribute 'ed-prof', the server
        supports the EAD items that are specified in the definition of
        that EDHOC application profile, as well as the EAD items indicated
        by the occurrences of the target attribute 'ed-ead'.





  Tiloca & Höglund          Expires 24 April 2025                 [Page 6]


  Internet-Draft         EDHOC Application Profiles           October 2024


     The example in Figure 1 shows how a CoAP client discovers two EDHOC
     resources at a CoAP server, and obtains information about the
     application profile corresponding to each of those resources.  The
     Link Format notation from Section 5 of [RFC6690] is used.

     The example assumes the existence of an EDHOC application profile
     identified by the integer Profile ID 500, which is supported by the
     EDHOC resource at /edhoc-alt and whose definition includes the
     support for the EAD items with EAD label 111 and 222.

     Therefore, the link to the EDHOC resource at /edhoc-alt indicates
     that, when using that EDHOC resource as per the EDHOC application
     profile with Profile ID 500, the server supports the EAD items with
     EAD label 111, 222, and 333.

        REQ: GET /.well-known/core

        RES: 2.05 Content
            </sensors/temp>;osc,
            </sensors/light>;if=sensor,
            </.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;
                ed-method=0;ed-cred-t=1;ed-cred-t=3;ed-idcred-t=4;
                ed-i;ed-r;ed-comb-req,
            </edhoc-alt>;rt=core.edhoc;ed-prof=500;ed-ead=333

                            Figure 1: The Web Link.

  2.2.  EDHOC_Information Object

     Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile] defines the
     EDHOC_Information object, as including information that guides two
     peers towards executing the EDHOC protocol, and defines an initial
     set of its parameters.

     This document defines the new parameter "app_prof" of the
     EDHOC_Information object, as summarized in Table 1 and described
     further below.

     +==========+=======+========+===================+===================+
     | Name     | CBOR  | CBOR   | Registry          | Description       |
     |          | label | type   |                   |                   |
     +==========+=======+========+===================+===================+
     | app_prof | 18    | int    | EDHOC Application | Set of supported  |
     |          |       | or     | Profiles Registry | EDHOC Application |
     |          |       | array  |                   | Profiles          |
     +----------+-------+--------+-------------------+-------------------+

                Table 1: EDHOC_Information Parameter "app_prof"



  Tiloca & Höglund          Expires 24 April 2025                 [Page 7]


  Internet-Draft         EDHOC Application Profiles           October 2024


     *  app_prof: This parameter specifies a set of supported EDHOC
        application profiles, identified by their Profile ID.  If the set
        is composed of a single EDHOC application profile, its Profile ID
        is encoded as an integer.  Otherwise, the set is encoded as an
        array of integers, where each array element encodes one Profile
        ID.  In JSON, the "app_prof" value is an integer or an array of
        integers.  In CBOR, "app_prof" is an integer or an array of
        integers, and has label 18.  The integer values are taken from the
        'Profile ID' column of the "EDHOC Application Profiles" registry
        defined in Section 11.5 of this document.

  2.2.1.  Use in the EDHOC and OSCORE Profile of the ACE Framework

     Section 3 of [I-D.ietf-ace-edhoc-oscore-profile] defines how the
     EDHOC_Information object can be used within the workflow of the EDHOC
     and OSCORE transport profile of the ACE framework for authentication
     and authorization in constrained environments (ACE) [RFC9200].

     In particular, the AS-to-C Access Token Response includes the
     parameter "edhoc_info", with value an EDHOC_Information object.  This
     allows the ACE authorization server (AS) to provide the ACE client
     (C) with information about how to run the EDHOC protocol with the ACE
     resource server (RS) for which the access token is issued.

     Similarly, the access token includes the corresponding claim
     "edhoc_info", with value an EDHOC_Information object.  This allows
     the AS to provide the ACE RS with information about how to run the
     EDHOC protocol with the ACE client, according to the issued access
     token.

     In turn, the EDHOC_Information object can include the parameter
     "app_prof" defined in this document.  This parameter indicates a set
     of EDHOC application profiles associated with the EDHOC resource to
     use at the RS, which is either implied or specified by the parameter
     "uri_path" within the same EDHOC_Information object.

     If the EDHOC_Information object specified as value of "edhoc_info"
     includes the "app_prof" parameter, then the following applies.

     *  The object MUST NOT include other parameters that provide
        information pertaining to an EDHOC application profile, with the
        exception of the parameter "eads" that MAY be included.

        C and RS MUST ignore other parameters present in the
        EDHOC_Information object, with the exception of the parameter
        "eads".





  Tiloca & Höglund          Expires 24 April 2025                 [Page 8]


  Internet-Draft         EDHOC Application Profiles           October 2024


        At the time of writing this document, such parameters are:
        "methods", "cipher_suites", "message_4", "comb_req", "osc_ms_len",
        "osc_salt_len", "osc_version", "cred_types", "id_cred_types",
        "initiator", and "responder" (which are all defined in Section 3.4
        of [I-D.ietf-ace-edhoc-oscore-profile]), as well as those defined
        in Section 4 of this document.

     *  If the EDHOC_Information object specified in the parameter
        "edhoc_info" of the AS-to-C Access Token Response includes the
        parameter "eads", the object provides the following information.

        When using the target EDHOC resource as per any EDHOC application
        profile indicated by the parameter "app_prof", the ACE RS for
        which the access token is issued supports the EAD items that are
        specified in the definition of that EDHOC application profile, as
        well as the EAD items indicated by the parameter "eads".

     *  If the EDHOC_Information object specified in the claim
        "edhoc_info" of the access token includes the parameter "eads",
        the object provides the following information.

        When using the target EDHOC resource as per any EDHOC application
        profile indicated by the parameter "app_prof", the ACE client to
        which the access token is issued supports the EAD items that are
        specified in the definition of that EDHOC application profile, as
        well as the EAD items indicated by the parameter "eads".

  3.  Additional Parameters for Web Linking

     Building on what is defined and prescribed in Section 6 of
     [I-D.ietf-core-oscore-edhoc], this section defines additional
     parameters for web linking [RFC8288], which can be used to obtain
     relevant pieces of information from the EDHOC application profile
     associated with an EDHOC resource.

     These parameters can be optionally specified as target attributes
     with the same name in a link with resource type "core.edhoc" (see
     Section 10.10 of [RFC9528]) targeting an EDHOC resource, or as filter
     criteria in a discovery request from a client.

     When specifying any of the parameters defined below in a link to an
     EDHOC resource, the target attribute rt="core.edhoc" MUST be
     included.

     *  'ed-max-msgsize', specifying the admitted maximum size of EDHOC
        messages in bytes.  This parameter MUST specify a single unsigned
        integer value.




  Tiloca & Höglund          Expires 24 April 2025                 [Page 9]


  Internet-Draft         EDHOC Application Profiles           October 2024


     *  'ed-coap-cf', specifying that CoAP messages have to include the
        CoAP Content-Format Option with value 64 (application/edhoc+cbor-
        seq) or 65 (application/cid-edhoc+cbor-seq) as appropriate, when
        the message payload includes exclusively an EDHOC message possibly
        prepended by an EDHOC connection identifier (see Sections 3.4.1
        and A.2 of [RFC9528]).  A value MUST NOT be given to this
        parameter and any present value MUST be ignored by the recipient.

     *  'ed-idep-t', specifying a type of endpoint identity for EDHOC
        supported by the server.  This parameter MUST specify a single
        value, which is taken from the 'CBOR Label' column of the "EDHOC
        Endpoint Identity Types" Registry defined in Section 8 of this
        document.  This parameter MAY occur multiple times, with each
        occurrence specifying a type of endpoint identity for EDHOC.

     *  'ed-tp', specifying a means for transporting EDHOC messages
        supported by the server.  This parameter MUST specify a single
        value, which is taken from the 'Transport ID' column of the "EDHOC
        Transports" Registry defined in Section 9 of this document.  This
        parameter MAY occur multiple times, with each occurrence
        specifying a means for transporting EDHOC messages.

  4.  Additional Parameters of the EDHOC_Information Object

     This section defines additional parameters of the EDHOC_Information
     object defined in Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].
     These parameters are summarized in Table 2 and described further
     below.

     Editor's note: these parameters can better be defined directly in
     Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].




















  Tiloca & Höglund          Expires 24 April 2025                [Page 10]


  Internet-Draft         EDHOC Application Profiles           October 2024


     +=============+=======+=======+============+=======================+
     | Name        | CBOR  | CBOR  | Registry   | Description           |
     |             | label | type  |            |                       |
     +=============+=======+=======+============+=======================+
     | max_msgsize | 14    | uint  |            | Maximum size of EDHOC |
     |             |       |       |            | messages in bytes     |
     +-------------+-------+-------+------------+-----------------------+
     | coap_cf     | 15    | True  |            | Requested use of the  |
     |             |       | of    |            | CoAP Content-Format   |
     |             |       | False |            | Option in CoAP        |
     |             |       |       |            | messages whose        |
     |             |       |       |            | payload includes      |
     |             |       |       |            | exclusively an EDHOC  |
     |             |       |       |            | message, possibly     |
     |             |       |       |            | prepended by an EDHOC |
     |             |       |       |            | connection identifier |
     +-------------+-------+-------+------------+-----------------------+
     | id_ep_types | 16    | int   | EDHOC      | Set of supported      |
     |             |       | or    | Endpoint   | types of endpoint     |
     |             |       | array | Identity   | identities for EDHOC  |
     |             |       |       | Types      |                       |
     |             |       |       | Registry   |                       |
     +-------------+-------+-------+------------+-----------------------+
     | transports  | 17    | int   | EDHOC      | Set of supported      |
     |             |       | or    | Transports | means for             |
     |             |       | array | Registry   | transporting EDHOC    |
     |             |       |       |            | messages              |
     +-------------+-------+-------+------------+-----------------------+

                    Table 2: EDHOC_Information Parameters

     *  max_msgsize: This parameter specifies the admitted maximum size of
        EDHOC messages in bytes.  In JSON, the "max_msgsize" value is an
        unsigned integer.  In CBOR, "max_msgsize" is an unsigned integer
        and has label 14.

     *  coap_cf: This parameter specifies whether it is required that CoAP
        messages include the CoAP Content-Format Option with value 64
        (application/edhoc+cbor-seq) or 65 (application/cid-edhoc+cbor-
        seq) as appropriate, when the message payload includes exclusively
        an EDHOC message possibly prepended by an EDHOC connection
        identifier (see Sections 3.4.1 and A.2 of [RFC9528]).  In JSON,
        the "coap_cf" value is a boolean.  In CBOR, "coap_cf" is the
        simple value true (0xf5) or false (0xf4), and has label 15.

     *  id_ep_types: This parameter specifies a set of supported types of
        endpoint identities for EDHOC.  If the set is composed of a single
        type of endpoint identity, this is encoded as an integer.



  Tiloca & Höglund          Expires 24 April 2025                [Page 11]


  Internet-Draft         EDHOC Application Profiles           October 2024


        Otherwise, the set is encoded as an array, where each array
        element encodes one type of endpoint identity as an integer.  In
        JSON, the "id_ep_types" value is an integer or an array of
        integers.  In CBOR, "id_ep_types" is an integer or an array of
        integers, and has label 16.  The integer values are taken from the
        'CBOR Label' column of the "EDHOC Endpoint Identity Types"
        registry defined in Section 11.6 of this document.

     *  transports: This parameter specifies a set of supported means for
        transporting EDHOC messages.  If the set is composed of a single
        means for transporting EDHOC messages, this is encoded as an
        integer.  Otherwise, the set is encoded as an array, where each
        array element encodes one means for transporting EDHOC messages as
        an integer.  In JSON, the "transports" value is an integer or an
        array of integers.  In CBOR, "transports" is an integer or an
        array of integers, and has label 17.  The integer values are taken
        from the 'Transport ID' column of the "EDHOC Transports" Registry
        defined in Section 9 of this document.

  5.  Representation of an EDHOC Application Profile

     This section defines the EDHOC_Application_Profile object, which can
     be used as a canonical representation of EDHOC application profiles
     for their description, distribution, and storage.

     An EDHOC_Application_Profile object is encoded as a CBOR map
     [RFC8949].  Each element of the CBOR map is an element of the CBOR-
     encoded EDHOC_Information object defined in Section 3.4 of
     [I-D.ietf-ace-edhoc-oscore-profile], and thus uses the corresponding
     CBOR abbreviations from the 'CBOR label' column of the "EDHOC
     Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].

     The CBOR map encoding an EDHOC_Application_Profile object MUST
     include the element "app_prof" defined in this document.  The value
     of the element "app_prof" is the unique identifier of the EDHOC
     application profile described by the EDHOC_Application_Profile
     object, taken from the 'Profile ID' column of the "EDHOC Application
     Profiles" registry defined in this document, and encoded as a CBOR
     integer.

     The CBOR map MUST include the following elements defined for the
     EDHOC_Information object: "methods" and "cred_types".

     The CBOR map MUST NOT include the following elements defined for the
     EDHOC_Information object: "session_id", "uri_path", "initiator", and
     "responder".





  Tiloca & Höglund          Expires 24 April 2025                [Page 12]


  Internet-Draft         EDHOC Application Profiles           October 2024


     The CBOR map MAY include other elements defined for the
     EDHOC_Information object.  These also comprise the new parameters
     defined in Section 4 of this document.

     Furthermore, consistent with Sections 8 and A.1 of [RFC9528] and with
     Section 5.4 of [RFC8613], the following applies:

     *  If the element "cipher_suites" is not present in the CBOR map,
        this indicates that the EDHOC application profile uses the EDHOC
        cipher suites 2 and 3.

     *  If the element "id_cred_types" is not present in the CBOR map,
        this indicates that the EDHOC application profile uses "kid" as
        type of authentication credential identifiers for EDHOC.

     *  If the element "osc_ms_len" is not present in the CBOR map, this
        indicates that, when using EDHOC to key OSCORE [RFC8613], the size
        of the OSCORE Master Secret in bytes is equal to the size of the
        key length for the application AEAD Algorithm of the selected
        cipher suite for the EDHOC session.

     *  If the element "osc_salt_len" is not present in the CBOR map, this
        indicates that, when using EDHOC to key OSCORE, the size of the
        OSCORE Master Salt in bytes is 8.

     *  If the element "osc_version" is not present in the CBOR map, this
        indicates that, when using EDHOC to key OSCORE, the OSCORE Version
        Number has value 1.

     *  The absence of any other elements in the CBOR map MUST NOT result
        in assuming any value.

     If an element is present in the CBOR map and the information that it
     specifies is intrinsically a set of one or more co-existing
     alternatives, then all the specified alternatives apply for the EDHOC
     application profile in question.

     For example, the element "cipher_suites" with value the CBOR array
     [0, 2] means that, in order to adhere to the EDHOC application
     profile in question, an EDHOC peer has to implement both the EDHOC
     cipher suites 0 and 2, because either of them can be used by another
     EDHOC peer also adhering to the same EDHOC application profile.

     The CDDL grammar describing the EDHOC_Application_Profile object is:







  Tiloca & Höglund          Expires 24 April 2025                [Page 13]


  Internet-Draft         EDHOC Application Profiles           October 2024


     EDHOC_Application_Profile = {
           1 => int / array,    ; methods
           9 => int / array,    ; cred_types
          18 => int,            ; app_prof
        * int / tstr => any
     }

  6.  Well-known EDHOC Application Profiles

     This section defines a set of well-known EDHOC application profiles
     that are meant to reflect what is most common and expected to be
     supported by EDHOC peers.

     The well-known application profiles are _not_ to be intended as
     "default" profiles to use, in case no other indication is provided to
     EDHOC peers.

     In particular, an EDHOC peer MUST NOT assume that, unless otherwise
     indicated, any of such profiles is used when running EDHOC through a
     well-known EDHOC resource, such as the resource at /.well-known/edhoc
     when EDHOC messages are transported as payload of CoAP messages (see
     Appendix A.2 of [RFC9528]).

     Building on the above, the well-known application profiles are _not_
     intended to deviate from what is mandatory to support for EDHOC
     peers, which is defined by the compliance requirements in Section 8
     of [RFC9528].

     The rest of this section defines the well-known application profiles,
     each of which is represented by means of an EDHOC_Application_Profile
     object (see Section 5) using the CBOR extended diagnostic notation.

     An entry for each well-known application profile is also registered
     at the "EDHOC Application Profiles" registry defined in Section 11.5
     of this document.

  6.1.  Well-Known Application Profile WK-MINIMAL_CS_2

     {
             e'methods' : 3, / EDHOC Method Type 3 /
       e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
          e'cred_types' : 1, / CWT Claims Set (CCS) /
       e'id_cred_types' : 4, / kid /
            e'app_prof' : e'APP-PROF-WK-MINIMAL-CS-2'
     }

     This application profile is aligned with the example trace of EDHOC
     compiled in Section 3 of [RFC9529].



  Tiloca & Höglund          Expires 24 April 2025                [Page 14]


  Internet-Draft         EDHOC Application Profiles           October 2024


  6.2.  Well-Known Application Profile WK-MINIMAL_CS_0

     {
             e'methods' : 3, / EDHOC Method Type 3 /
       e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
          e'cred_types' : 1, / CWT Claims Set (CCS) /
       e'id_cred_types' : 4, / kid /
            e'app_prof' : e'APP-PROF-WK-MINIMAL-CS-0'
     }

  6.3.  Well-Known Application Profile WK-BASIC_CS_2_X509

     {
             e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
       e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
          e'cred_types' : [1, 2], / CWT Claims Set (CCS)
                                    and X.509 certificate /
       e'id_cred_types' : [4, 34], / kid and x5t /
            e'app_prof' : e'APP-PROF-WK-BASIC-CS-2-X509'
     }

     This application profile is aligned with the example trace of EDHOC
     compiled in Section 3 of [RFC9529].

  6.4.  Well-Known Application Profile WK-BASIC_CS_0_X509

     {
             e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
       e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
          e'cred_types' : [1, 2], / CWT Claims Set (CCS)
                                    and X.509 certificate /
       e'id_cred_types' : [4, 34], / kid and x5t /
            e'app_prof' : e'APP-PROF-WK-BASIC-CS-0-X509'
     }

     This application profile is aligned with the example trace of EDHOC
     compiled in Section 2 of [RFC9529].

  6.5.  Well-Known Application Profile WK-BASIC_CS_2_C509

     {
             e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
       e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
          e'cred_types' : [1, e'c509_cert'], / CWT Claims Set (CCS)
                                               and C509 certificate /
       e'id_cred_types' : [4, e'c5t'], / kid and c5t /
            e'app_prof' : e'APP-PROF-WK-BASIC-CS-2-C509'
     }



  Tiloca & Höglund          Expires 24 April 2025                [Page 15]


  Internet-Draft         EDHOC Application Profiles           October 2024


  6.6.  Well-Known Application Profile WK-BASIC_CS_0_C509

     {
             e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
       e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
          e'cred_types' : [1, e'c509_cert'], / CWT Claims Set (CCS)
                                               and C509 certificate /
       e'id_cred_types' : [4, e'c5t'], / kid and c5t /
            e'app_prof' : e'APP-PROF-WK-BASIC-CS-0-C509'
     }

  6.7.  Well-Known Application Profile WK-INTERMEDIATE_CS_2

    {
            e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
      e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
         e'cred_types' : [1, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                                 X.509 certificate,
                                                 and C509 certificate /
      e'id_cred_types' : [4, 14, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                            x5t, x5chain,
                                                            c5t, and c5c /
           e'app_prof' : e'APP-PROF-WK-INTERMEDIATE-CS-2'
    }

     This application profile is aligned with the example trace of EDHOC
     compiled in Section 3 of [RFC9529].

  6.8.  Well-Known Application Profile WK-INTERMEDIATE_CS_0

    {
            e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
      e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
         e'cred_types' : [1, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                                 X.509 certificate,
                                                 and C509 certificate /
      e'id_cred_types' : [4, 14, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                            x5t, x5chain,
                                                            c5t, and c5c /
           e'app_prof' : e'APP-PROF-WK-INTERMEDIATE-CS-0'
    }

     This application profile is aligned with the example trace of EDHOC
     compiled in Section 2 of [RFC9529].

  6.9.  Well-Known Application Profile WK-ADVANCED





  Tiloca & Höglund          Expires 24 April 2025                [Page 16]


  Internet-Draft         EDHOC Application Profiles           October 2024


   {
           e'methods' : [0, 1, 2, 3], / EDHOC Method Types
                                        0, 1, 2, and 3 /
     e'cipher_suites' : [0, 1, 2, 3], / EDHOC Cipher Suites
                                        0, 1, 2, and 3 /
        e'cred_types' : [1, 0, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                                   CWT, X.509 certificate,
                                                   and C509 certificate /
     e'id_cred_types' : [4, 14, 13, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                               kcwt, x5t,
                                                               x5chain,
                                                               c5t, and
                                                               c5c /
          e'app_prof' : e'APP-PROF-WK-ADVANCED'
   }

     This application profile is aligned with the example traces of EDHOC
     compiled in Sections 2 and 3 of [RFC9529].

  7.  EDHOC Well-known Application Profiles

     This document defines the following identifiers of well-known EDHOC
     application profiles.

     +=========+======================+=====================+============+
     | Profile | Name                 | Description         | Reference  |
     | ID      |                      |                     |            |
     +=========+======================+=====================+============+
     | 0       | WK-MINIMAL-CS-2      | Method 3; Cipher    | [RFC-XXXX] |
     |         |                      | Suite 2; CCS; kid   |            |
     +---------+----------------------+---------------------+------------+
     | 1       | WK-MINIMAL-CS-0      | Method 3; Cipher    | [RFC-XXXX] |
     |         |                      | Suite 0; CCS; kid   |            |
     +---------+----------------------+---------------------+------------+
     | 2       | WK-BASIC-CS-2-X509   | Methods (0, 3);     | [RFC-XXXX] |
     |         |                      | Cipher Suite 2;     |            |
     |         |                      | (CCS, X.509         |            |
     |         |                      | certificates);      |            |
     |         |                      | (kid, x5t)          |            |
     +---------+----------------------+---------------------+------------+
     | 3       | WK-BASIC-CS-0-X509   | Methods (0, 3);     | [RFC-XXXX] |
     |         |                      | Cipher Suite 0;     |            |
     |         |                      | (CCS, X.509         |            |
     |         |                      | certificates);      |            |
     |         |                      | (kid, x5t)          |            |
     +---------+----------------------+---------------------+------------+
     | 4       | WK-BASIC-CS-2-C509   | Methods (0, 3);     | [RFC-XXXX] |
     |         |                      | Cipher Suite 2;     |            |



  Tiloca & Höglund          Expires 24 April 2025                [Page 17]


  Internet-Draft         EDHOC Application Profiles           October 2024


     |         |                      | (CCS, C509          |            |
     |         |                      | certificates);      |            |
     |         |                      | (kid, c5t)          |            |
     +---------+----------------------+---------------------+------------+
     | 5       | WK-BASIC-CS_0-C509   | Methods (0, 3);     | [RFC-XXXX] |
     |         |                      | Cipher Suite 0;     |            |
     |         |                      | (CCS, C509          |            |
     |         |                      | certificates);      |            |
     |         |                      | (kid, c5t)          |            |
     +---------+----------------------+---------------------+------------+
     | 6       | WK-INTERMEDIATE-CS-2 | Methods (0, 3);     | [RFC-XXXX] |
     |         |                      | Cipher Suite 2;     |            |
     |         |                      | (CCS, X.509/C509    |            |
     |         |                      | certificates);      |            |
     |         |                      | (kid, kccs, x5t,    |            |
     |         |                      | x5chain, c5t,       |            |
     |         |                      | c5c)                |            |
     +---------+----------------------+---------------------+------------+
     | 7       | WK-INTERMEDIATE-CS-0 | Methods (0, 3);     | [RFC-XXXX] |
     |         |                      | Cipher Suite 0;     |            |
     |         |                      | (CCS, X.509/C509    |            |
     |         |                      | certificates);      |            |
     |         |                      | (kid, kccs, x5t,    |            |
     |         |                      | x5chain, c5t,       |            |
     |         |                      | c5c)                |            |
     +---------+----------------------+---------------------+------------+
     | 8       | WK-ADVANCED          | Methods (0, 1, 2,   | [RFC-XXXX] |
     |         |                      | 3); Cipher Suites   |            |
     |         |                      | (0, 1, 2, 3);       |            |
     |         |                      | (CCS, CWT, X.509/   |            |
     |         |                      | C509                |            |
     |         |                      | certificates);      |            |
     |         |                      | (kid, kccs, kcwt,   |            |
     |         |                      | x5t, x5chain,       |            |
     |         |                      | c5t, c5c)           |            |
     +---------+----------------------+---------------------+------------+

                 Table 3: EDHOC Well-known Application Profiles

  8.  EDHOC Endpoint Identity Types

     This document defines the following identifier of type of endpoint
     identity for EDHOC.








  Tiloca & Höglund          Expires 24 April 2025                [Page 18]


  Internet-Draft         EDHOC Application Profiles           October 2024


      +========+============+====================+=====================+
      | Name   | CBOR label | Description        | Reference           |
      +========+============+====================+=====================+
      | EUI-64 | 0          | An EUI-64 identity | [RFC-XXXX][RFC4291] |
      +--------+------------+--------------------+---------------------+

                    Table 4: EDHOC Endpoint Identity Types

  9.  EDHOC Transports

     This document defines the following identifiers of means for
     transporting EDHOC messages.

      +===========+============+===================+====================+
      | Transport | Name       | Description       | Reference          |
      | ID        |            |                   |                    |
      +===========+============+===================+====================+
      | 0         | CoAP over  | EDHOC messages    | [RFC7252],         |
      |           | UDP        | are transported   | Appendix A.2 of    |
      |           |            | as payload of     | [RFC9528]          |
      |           |            | CoAP messages, in |                    |
      |           |            | turn transported  |                    |
      |           |            | over UDP          |                    |
      +-----------+------------+-------------------+--------------------+
      | 1         | CoAP over  | EDHOC messages    | [RFC7252][RFC8323] |
      |           | TCP        | are transported   |                    |
      |           |            | as payload of     |                    |
      |           |            | CoAP messages, in |                    |
      |           |            | turn transported  |                    |
      |           |            | over TCP          |                    |
      +-----------+------------+-------------------+--------------------+
      | 2         | CoAP over  | EDHOC messages    | [RFC7252][RFC8323] |
      |           | WebSockets | are transported   |                    |
      |           |            | as payload of     |                    |
      |           |            | CoAP messages, in |                    |
      |           |            | turn transported  |                    |
      |           |            | over WebSockets   |                    |
      +-----------+------------+-------------------+--------------------+

                           Table 5: EDHOC Transports

  10.  Security Considerations

     TBD







  Tiloca & Höglund          Expires 24 April 2025                [Page 19]


  Internet-Draft         EDHOC Application Profiles           October 2024


  11.  IANA Considerations

     This document has the following actions for IANA.

     Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
     with the RFC number of this specification and delete this paragraph.

  11.1.  Media Type Registrations

     IANA is asked to register the media type "application/edhoc-app-
     profile+cbor-seq".  This registration follows the procedures
     specified in [RFC6838].

     Type name: application

     Subtype name: edhoc-app-profile+cbor-seq

     Required parameters: N/A

     Optional parameters: N/A

     Encoding considerations: Must be encoded as a CBOR sequence [RFC8742]
     of CBOR maps [RFC8949].  Each element of each CBOR map is also
     defined as an element of the CBOR-encoded EDHOC_Information object
     from Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].

     Security considerations: See Section 10 of [RFC-XXXX].

     Interoperability considerations: N/A

     Published specification: [RFC-XXXX]

     Applications that use this media type: Applications that need to
     describe, distribute, and store a representation of an EDHOC
     application profile (see Section 3.9 of [RFC9528]).

     Fragment identifier considerations: N/A

     Additional information: N/A

     Person & email address to contact for further information: LAKE WG
     mailing list (lake@ietf.org) or IETF Applications and Real-Time Area
     (art@ietf.org)

     Intended usage: COMMON

     Restrictions on usage: None




  Tiloca & Höglund          Expires 24 April 2025                [Page 20]


  Internet-Draft         EDHOC Application Profiles           October 2024


     Author/Change controller: IETF

     Provisional registration: No

  11.2.  CoAP Content-Formats Registry

     IANA is asked to add the following entry to the "CoAP Content-
     Formats" registry within the "Constrained RESTful Environments (CoRE)
     Parameters" registry group.

     Content Type: application/edhoc-app-profile+cbor-seq

     Content Coding: -

     ID: TBD

     Reference: [RFC-XXXX]

  11.3.  Target Attributes Registry

     IANA is asked to register the following entries in the "Target
     Attributes" registry within the "Constrained RESTful Environments
     (CoRE) Parameters", as per [RFC9423].

     *  Attribute Name: ed-max-msgsize

     *  Brief Description: The admitted maximum size of EDHOC messages in
        bytes

     *  Change Controller: IETF

     *  Reference: [RFC-XXXX]



     *  Attribute Name: ed-coap-cf

     *  Brief Description: Requested use of the CoAP Content-Format Option
        in CoAP messages whose payload includes exclusively an EDHOC
        message, possibly prepended by an EDHOC connection identifier

     *  Change Controller: IETF

     *  Reference: [RFC-XXXX]



     *  Attribute Name: ed-idep-t



  Tiloca & Höglund          Expires 24 April 2025                [Page 21]


  Internet-Draft         EDHOC Application Profiles           October 2024


     *  Brief Description: A supported type of endpoint identity for EDHOC

     *  Change Controller: IETF

     *  Reference: [RFC-XXXX]



     *  Attribute Name: ed-tp

     *  Brief Description: A supported means for transporting EDHOC
        messages

     *  Change Controller: IETF

     *  Reference: [RFC-XXXX]



     *  Attribute Name: ed-prof

     *  Brief Description: A supported EDHOC application profile

     *  Change Controller: IETF

     *  Reference: [RFC-XXXX]

  11.4.  EDHOC Information Registry

     IANA is asked to register the following entries in the "EDHOC
     Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].

     *  Name: max_msgsize

     *  CBOR label: 14

     *  CBOR type: uint

     *  Registry:

     *  Description: The admitted maximum size of EDHOC messages in bytes

     *  Specification: [RFC-XXXX][RFC9528]



     *  Name: coap_cf




  Tiloca & Höglund          Expires 24 April 2025                [Page 22]


  Internet-Draft         EDHOC Application Profiles           October 2024


     *  CBOR label: 15

     *  CBOR type: True or False

     *  Registry:

     *  Description: Requested use of the CoAP Content-Format Option in
        CoAP messages whose payload includes exclusively an EDHOC message,
        possibly prepended by an EDHOC connection identifier

     *  Specification: [RFC-XXXX][RFC9528]



     *  Name: id_ep_types

     *  CBOR label: 16

     *  CBOR type: int or array

     *  Registry: EDHOC Endpoint Identity Types

     *  Description: Set of supported types of endpoint identities for
        EDHOC

     *  Specification: [RFC-XXXX]



     *  Name: transports

     *  CBOR label: 17

     *  CBOR type: int or array

     *  Registry: EDHOC Transports Registry

     *  Description: Set of supported means for transporting EDHOC
        messages

     *  Specification: [RFC-XXXX]



     *  Name: app_prof

     *  CBOR label: 18




  Tiloca & Höglund          Expires 24 April 2025                [Page 23]


  Internet-Draft         EDHOC Application Profiles           October 2024


     *  CBOR type: int or array

     *  Registry: EDHOC Application Profiles Registry

     *  Description: Set of supported EDHOC Application Profiles

     *  Specification: [RFC-XXXX][RFC9528]

  11.5.  EDHOC Application Profiles Registry

     IANA is requested to create a new "EDHOC Application Profiles"
     registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)"
     registry group defined in [RFC9528].

     The registration policy is either "Private Use", "Standards Action
     with Expert Review", or "Specification Required" per Section 4.6 of
     [RFC8126].  "Expert Review" guidelines are provided in Section 11.8.

     All assignments according to "Standards Action with Expert Review"
     are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
     with Expert Review additionally required per Section 4.5 of
     [RFC8126].  The procedure for early IANA allocation of Standards
     Track code points defined in [RFC7120] also applies.  When such a
     procedure is used, IANA will ask the designated expert(s) to approve
     the early allocation before registration.  In addition, WG chairs are
     encouraged to consult the expert(s) early during the process outlined
     in Section 3.1 of [RFC7120].

     The columns of this registry are:

     *  Profile ID: This field contains the value used to identify the
        EDHOC application profile.  These values MUST be unique.  The
        value can be a positive integer or a negative integer.  Different
        ranges of values use different registration policies [RFC8126].
        Integer values from -24 to 23 are designated as "Standards Action
        With Expert Review".  Integer values from -65536 to -25 and from
        24 to 65535 are designated as "Specification Required".  Integer
        values smaller than -65536 and greater than 65535 are marked as
        "Private Use".

     *  Name: This field contains the name of the EDHOC application
        profile.

     *  Description: This field contains a short description of the EDHOC
        application profile.

     *  Reference: This field contains a pointer to the public
        specification for the EDHOC application profile.



  Tiloca & Höglund          Expires 24 April 2025                [Page 24]


  Internet-Draft         EDHOC Application Profiles           October 2024


     This registry has been initially populated with the values in
     Table 3.

  11.6.  EDHOC Endpoint Identity Types Registry

     IANA is requested to create a new "EDHOC Endpoint Identity Types"
     registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)"
     registry group defined in [RFC9528].

     The registration policy is either "Private Use", "Standards Action
     with Expert Review", or "Specification Required" per Section 4.6 of
     [RFC8126].  "Expert Review" guidelines are provided in Section 11.8.

     All assignments according to "Standards Action with Expert Review"
     are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
     with Expert Review additionally required per Section 4.5 of
     [RFC8126].  The procedure for early IANA allocation of Standards
     Track code points defined in [RFC7120] also applies.  When such a
     procedure is used, IANA will ask the designated expert(s) to approve
     the early allocation before registration.  In addition, WG chairs are
     encouraged to consult the expert(s) early during the process outlined
     in Section 3.1 of [RFC7120].

     The columns of this registry are:

     *  Name: This field contains the name of the EDHOC endpoint identity
        type.

     *  CBOR Label: The value to be used to identify this EDHOC endpoint
        identity type.  These values MUST be unique.  The value can be a
        positive integer or a negative integer.  Different ranges of
        values use different registration policies [RFC8126].  Integer
        values from -24 to 23 are designated as "Standards Action With
        Expert Review".  Integer values from -65536 to -25 and from 24 to
        65535 are designated as "Specification Required".  Integer values
        smaller than -65536 and greater than 65535 are marked as "Private
        Use".

     *  Description: This field contains a short description of the EDHOC
        endpoint identity type.

     *  Reference: This field contains a pointer to the public
        specification for the EDHOC endpoint identity type.

     This registry has been initially populated with the values in
     Table 4.





  Tiloca & Höglund          Expires 24 April 2025                [Page 25]


  Internet-Draft         EDHOC Application Profiles           October 2024


  11.7.  EDHOC Transport Registry

     IANA is requested to create a new "EDHOC Transport" registry within
     the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group
     defined in [RFC9528].

     The registration policy is either "Private Use", "Standards Action
     with Expert Review", or "Specification Required" per Section 4.6 of
     [RFC8126].  "Expert Review" guidelines are provided in Section 11.8.

     All assignments according to "Standards Action with Expert Review"
     are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
     with Expert Review additionally required per Section 4.5 of
     [RFC8126].  The procedure for early IANA allocation of Standards
     Track code points defined in [RFC7120] also applies.  When such a
     procedure is used, IANA will ask the designated expert(s) to approve
     the early allocation before registration.  In addition, WG chairs are
     encouraged to consult the expert(s) early during the process outlined
     in Section 3.1 of [RFC7120].

     The columns of this registry are:

     *  Transport ID: The value to be used to identify this means for
        transporting EDHOC messages.  These values MUST be unique.  The
        value can be a positive integer or a negative integer.  Different
        ranges of values use different registration policies [RFC8126].
        Integer values from -24 to 23 are designated as "Standards Action
        With Expert Review".  Integer values from -65536 to -25 and from
        24 to 65535 are designated as "Specification Required".  Integer
        values smaller than -65536 and greater than 65535 are marked as
        "Private Use".

     *  Name: This field contains the name of the means for transporting
        EDHOC messages.

     *  Description: This field contains a short description of the means
        used for transporting EDHOC messages.

     *  Reference: This field contains a pointer to the public
        specification for the means used for transporting EDHOC messages.

     This registry has been initially populated with the values in
     Table 5.








  Tiloca & Höglund          Expires 24 April 2025                [Page 26]


  Internet-Draft         EDHOC Application Profiles           October 2024


  11.8.  Expert Review Instructions

     "Standards Action with Expert Review" and "Specification Required"
     are two of the registration policies defined for the IANA registries
     established in this document.  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:

     *  Clarity and correctness of registrations.  Experts are expected to
        check the clarity of purpose and use of the requested entries.
        Experts need to make sure that the object of registration (i.e.,
        an EDHOC application profile, an EDHOC endpoint identity type, or
        a means for transporting EDHOC messages) is clearly defined in the
        corresponding specification.  Entries that do not meet these
        objective of clarity and completeness must not be registered.

     *  Point squatting should be discouraged.  Reviewers are encouraged
        to get sufficient information for registration requests to ensure
        that the usage is not going to duplicate one that is already
        registered and that the point is likely to be used in deployments.
        The zones tagged as "Private Use" are intended for testing
        purposes and closed environments.  Code points in other ranges
        should not be assigned for testing.

     *  Specifications are required for the "Standards Action With Expert
        Review" range of point assignment.  Specifications should exist
        for "Specification Required" ranges, but early assignment before a
        specification is available is considered to be permissible.  When
        specifications are not provided, the description provided needs to
        have sufficient information to identify what the point is being
        used for.

     *  Experts should take into account the expected usage of fields when
        approving point assignment.  Documents published via Standards
        Action can also register points outside the Standards Action
        range.  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.

  12.  References

  12.1.  Normative References





  Tiloca & Höglund          Expires 24 April 2025                [Page 27]


  Internet-Draft         EDHOC Application Profiles           October 2024


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

     [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-06, 21 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
                edhoc-oscore-profile-06>.

     [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-11, 9 April 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-core-
                oscore-edhoc-11>.

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

     [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 4291, DOI 10.17487/RFC4291, February
                2006, <https://www.rfc-editor.org/rfc/rfc4291>.

     [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
                Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
                <https://www.rfc-editor.org/rfc/rfc6690>.

     [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
                Specifications and Registration Procedures", BCP 13,
                RFC 6838, DOI 10.17487/RFC6838, January 2013,
                <https://www.rfc-editor.org/rfc/rfc6838>.

     [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
                Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
                2014, <https://www.rfc-editor.org/rfc/rfc7120>.





  Tiloca & Höglund          Expires 24 April 2025                [Page 28]


  Internet-Draft         EDHOC Application Profiles           October 2024


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

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

     [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
                DOI 10.17487/RFC8288, October 2017,
                <https://www.rfc-editor.org/rfc/rfc8288>.

     [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
                Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
                Application Protocol) over TCP, TLS, and WebSockets",
                RFC 8323, DOI 10.17487/RFC8323, February 2018,
                <https://www.rfc-editor.org/rfc/rfc8323>.

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

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

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








  Tiloca & Höglund          Expires 24 April 2025                [Page 29]


  Internet-Draft         EDHOC Application Profiles           October 2024


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

     [RFC9423]  Bormann, C., "Constrained RESTful Environments (CoRE)
                Target Attributes Registry", RFC 9423,
                DOI 10.17487/RFC9423, April 2024,
                <https://www.rfc-editor.org/rfc/rfc9423>.

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

  12.2.  Informative References

     [RFC9529]  Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,
                and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over
                COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024,
                <https://www.rfc-editor.org/rfc/rfc9529>.

  Appendix A.  CDDL Model

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

























  Tiloca & Höglund          Expires 24 April 2025                [Page 30]


  Internet-Draft         EDHOC Application Profiles           October 2024


     ; EDHOC Information
     methods = 1
     cipher_suites = 2
     cred_types = 9
     id_cred_types = 10
     app_prof = 18

     ; EDHOC Application Profiles
     APP-PROF-WK-MINIMAL-CS-2 = 0
     APP-PROF-WK-MINIMAL-CS-0 = 1
     APP-PROF-WK-BASIC-CS-2-X509 = 2
     APP-PROF-WK-BASIC-CS-0-X509 = 3
     APP-PROF-WK-BASIC-CS-2-C509 = 4
     APP-PROF-WK-BASIC-CS-0-C509 = 5
     APP-PROF-WK-INTERMEDIATE-CS-2 = 6
     APP-PROF-WK-INTERMEDIATE-CS-0 = 7
     APP-PROF-WK-ADVANCED = 8

     ; COSE Header Parameters
     c5t = 22
     c5c = 25

     ; EDHOC Authentication Credential Types
     c509_cert = 3

                              Figure 2: CDDL model

  Acknowledgments

     The authors sincerely thank Christian Amsüss, Göran Selander, and
     Brian Sipos for their feedback and comments.

     This work was supported by the Sweden's Innovation Agency VINNOVA
     within the EUREKA CELTIC-NEXT project CYPRESS.

  Authors' Addresses

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








  Tiloca & Höglund          Expires 24 April 2025                [Page 31]


  Internet-Draft         EDHOC Application Profiles           October 2024


     Rikard Höglund
     RISE AB
     Isafjordsgatan 22
     SE-16440 Stockholm Kista
     Sweden
     Email: rikard.hoglund@ri.se













































  Tiloca & Höglund          Expires 24 April 2025                [Page 32]


name: draft-ietf-dnsop-dnssec-bootstrapping
rev: 11
title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator
time: 2024-07-16T23:15:20Z
group_uri: /api/v1/group/group/1452/
expires: 2024-11-29T10:49:56Z
ad: /api/v1/person/person/111656/
shepherd: /api/v1/person/email/tjw.ietf@gmail.com/
categories: ["Autonomous netops", "Policy/governance"]
tags: []
fetched_at: 2026-03-04T00:00:05.724454+00:00
source: ietf
abstract:
  This document introduces an in-band method for DNS operators to
     publish arbitrary information about the zones they are authoritative
     for, in an authenticated fashion and on a per-zone basis.  The
     mechanism allows managed DNS operators to securely announce DNSSEC
     key parameters for zones under their management, including for zones
     that are not currently securely delegated.

     Whenever DS records are absent for a zone's delegation, this signal
     enables the parent's registry or registrar to cryptographically
     validate the CDS/CDNSKEY records found at the child's apex.  The
     parent can then provision DS records for the delegation without
     resorting to out-of-band validation or weaker types of cross-checks
     such as "Accept after Delay".

     This document establishes the DS enrollment method described in
     Section 4 of this document as the preferred method over those from
     Section 3 of RFC 8078.  It also updates RFC 7344.

     [ Ed note: This document is being collaborated on at
     https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
     (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
     The authors gratefully accept pull requests. ]

states:
[cell repeats an earlier one in this file: 151 characters]

full_text:
  DNSOP Working Group                                         P. Thomassen
  Internet-Draft                         deSEC, Secure Systems Engineering
  Updates: 7344, 8078 (if approved)                              N. Wisiol
  Intended status: Standards Track    deSEC, Technische Universität Berlin
  Expires: 29 November 2024                                    28 May 2024


    Automatic DNSSEC Bootstrapping using Authenticated Signals from the
                              Zone's Operator
                  draft-ietf-dnsop-dnssec-bootstrapping-11

  Abstract

     This document introduces an in-band method for DNS operators to
     publish arbitrary information about the zones they are authoritative
     for, in an authenticated fashion and on a per-zone basis.  The
     mechanism allows managed DNS operators to securely announce DNSSEC
     key parameters for zones under their management, including for zones
     that are not currently securely delegated.

     Whenever DS records are absent for a zone's delegation, this signal
     enables the parent's registry or registrar to cryptographically
     validate the CDS/CDNSKEY records found at the child's apex.  The
     parent can then provision DS records for the delegation without
     resorting to out-of-band validation or weaker types of cross-checks
     such as "Accept after Delay".

     This document establishes the DS enrollment method described in
     Section 4 of this document as the preferred method over those from
     Section 3 of RFC 8078.  It also updates RFC 7344.

     [ Ed note: This document is being collaborated on at
     https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
     (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
     The authors gratefully accept pull requests. ]

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






  Thomassen & Wisiol      Expires 29 November 2024                [Page 1]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     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 29 November 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Requirements Notation . . . . . . . . . . . . . . . . . .   5
     2.  Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Signaling . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Chain of Trust  . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Signaling Names . . . . . . . . . . . . . . . . . . . . .   5
     4.  Bootstrapping a DNSSEC Delegation . . . . . . . . . . . . . .   6
       4.1.  Signaling Consent to Act as the Child's Signer  . . . . .   6
         4.1.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Validating CDS/CDNSKEY Records for DNSSEC
             Bootstrapping . . . . . . . . . . . . . . . . . . . . . .   7
         4.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   8
       4.3.  Triggers  . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.4.  Limitations . . . . . . . . . . . . . . . . . . . . . . .  10
     5.  Operational Recommendations . . . . . . . . . . . . . . . . .  10
       5.1.  Child DNS Operator  . . . . . . . . . . . . . . . . . . .  10
       5.2.  Parental Agent  . . . . . . . . . . . . . . . . . . . . .  11
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.  Implementation Status . . . . . . . . . . . . . . . . . . . .  12
       8.1.  Child DNS Operator-side . . . . . . . . . . . . . . . . .  12
       8.2.  Parental Agent-side . . . . . . . . . . . . . . . . . . .  12
     9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13



  Thomassen & Wisiol      Expires 29 November 2024                [Page 2]


  Internet-Draft            dnssec-bootstrapping                  May 2024


       10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
       10.2.  Informative References . . . . . . . . . . . . . . . . .  14
     Appendix A.  Change History (to be removed before publication)  .  15
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

  1.  Introduction

     Securing a DNS delegation for the first time requires that the
     child's DNSSEC parameters be conveyed to the parent through some
     trusted channel.  While the communication conceptually has to occur
     between the parent registry and the DNSSEC key holder, what exactly
     that means and how the communication is coordinated traditionally
     depends on the relationship the child has with the parent.

     A typical situation is that the key is held by the child DNS
     operator; the communication thus often involves this entity.  In
     addition, depending on the circumstances, it may also involve the
     registrar, possibly via the registrant (for details, see [RFC7344],
     Appendix A).

     As observed in [RFC7344], these dependencies often result in a manual
     process that is susceptible to mistakes and/or errors.  In addition,
     due to the annoyance factor of the process, involved parties may
     avoid the process of getting a DS record set (RRset) published in the
     first place.

     To alleviate these problems, automated provisioning of DS records has
     been specified in ([RFC8078]).  It is based on the parental agent
     (registry or registrar) fetching DNSSEC key parameters from the CDS
     and CDNSKEY records ([RFC7344]) located at the child zone's apex, and
     validating them somehow.  This validation can be done using the
     child's existing DNSSEC chain of trust if the objective is to update
     an existing DS RRset (such as during key rollover).  However, when
     bootstrapping a DNSSEC delegation, the child zone has no existing
     DNSSEC validation path, and other means to ensure the CDS/CDNSKEY
     records' legitimacy must be found.

     Due to the lack of a comprehensive DNS-innate solution, either out-
     of-band methods have been used so far to complete the chain of trust,
     or cryptographic validation has been entirely dispensed with, in
     exchange for weaker types of cross-checks such as "Accept after
     Delay" ([RFC8078] Section 3.3).  [RFC8078] does not define an in-band
     validation method for enabling DNSSEC.

     This document aims to close this gap by introducing an in-band method
     for DNS operators to publish arbitrary information about the zones
     they are authoritative for, in an authenticated manner and on a per-
     zone basis.  The mechanism allows managed DNS operators to securely



  Thomassen & Wisiol      Expires 29 November 2024                [Page 3]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     announce DNSSEC key parameters for zones under their management.  The
     parent can then use this signal to cryptographically validate the
     CDS/CDNSKEY RRsets found at an insecure child zone's apex and, upon
     success, secure the delegation.

     While applicable to the vast majority of domains, the protocol does
     not support certain edge cases, such as excessively long child zone
     names, or DNSSEC bootstrapping for domains with in-domain nameservers
     only (see Section 4.4).

     DNSSEC bootstrapping is just one application of the generic signaling
     mechanism specified in this document.  Other applications might arise
     in the future, such as publishing operational metadata or auxiliary
     information which the DNS operator likes to make known (e.g., API
     endpoints for third-party interaction).

     Readers are expected to be familiar with DNSSEC [BCP237].

  1.1.  Terminology

     This section defines the terminology used in this document.

     CDS/CDNSKEY  This notation refers to CDS and/or CDNSKEY, i.e., one or
        both.
     Child  see [RFC9499] Section 7
     Child DNS operator  The entity that maintains and publishes the zone
        information for the child DNS.
     Parent  see [RFC9499] Section 7
     Parental agent  The entity that has the authority to insert DS
        records into the parent zone on behalf of the child.  (It could be
        the registry, registrar, a reseller, or some other authorized
        entity.)
     Signaling domain  A domain name constructed by prepending the label
        _signal to a hostname taken from the child's NS RRSet.  There are
        as many signaling domains as there are distinct NS targets.
     Signaling name  The labels that are prefixed to a signaling domain in
        order to identify a signaling type and a child zone's name (see
        Section 3.2).
     Signaling record  A DNS record located at a signaling name under a
        signaling domain.  Signaling records are used by the child DNS
        operator to publish information about the child.
     Signaling type  A signal type identifier, such as _dsboot for DNSSEC
        bootstrapping.
     Signaling zone  The zone which is authoritative for a given signaling
        record.






  Thomassen & Wisiol      Expires 29 November 2024                [Page 4]


  Internet-Draft            dnssec-bootstrapping                  May 2024


  1.2.  Requirements Notation

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

  2.  Updates to RFCs

     The DS enrollment methods described in Section 3 of [RFC8078] are
     less secure than the method described in Section 4 of this document.
     Child DNS operators and parental agents wishing to use CDS/CDNSKEY
     records for initial DS enrollment SHOULD therefore support the
     authentication protocol described here.

     In order to facilitate publication of signaling records for the
     purpose of DNSSEC bootstrapping (see Section 4.1), the first bullet
     ("Location") of [RFC7344] Section 4.1 is removed.

  3.  Signaling

     This section describes the general mechanism by which a child DNS
     operator can publish an authenticated signal about a child zone.
     Parental agents (or any other party) can then discover and process
     the signal.  Authenticity is ensured through standard DNSSEC
     validation.

  3.1.  Chain of Trust

     If a child DNS operator implements this specification, each signaling
     zone MUST be signed and be validatable by the parental agent (i.e.,
     have a valid publicly resolvable DNSSEC chain of trust).  This is
     typically achieved by securely delegating each signaling zone.

     For example, when publishing a signal that relates to a child zone
     with NS records ns1.example.net and ns2.example.org, the child DNS
     operator needs to ensure that the parental agent has a valid DNSSEC
     chain of trust for the zone(s) that are authoritative for the
     signaling domains _signal.ns1.example.net and
     _signal.ns2.example.org.

  3.2.  Signaling Names

     To publish information about the child zone in an authenticated
     fashion, the child DNS operator MUST publish one or more signaling
     records at a signaling name under each signaling domain.




  Thomassen & Wisiol      Expires 29 November 2024                [Page 5]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     Signaling records MUST be accompanied by RRSIG records created with
     the corresponding signaling zone's key(s).  The type and contents of
     these signaling records depend on the type of signal.

     The signaling name identifies the child and the signaling type.  It
     is identical to the child name (with the final root label removed),
     prefixed with a label containing the signaling type.

  4.  Bootstrapping a DNSSEC Delegation

     When the child zone's CDS/CDNSKEY RRsets are used for setting up
     initial trust, they need to be authenticated.  This is achieved by
     co-publishing the child's CDS/CDNSKEY RRsets as an authenticated
     signal as described in Section 3.  The parent can discover and
     validate it, thus transferring trust from the child DNS operator
     nameservers' chain of trust to the child zone.

     This protocol is not intended for updating an existing DS RRset.  For
     this purpose, the parental agent can validate the child's CDS/CDNSKEY
     RRsets directly, using the chain of trust established by the existing
     DS RRset ([RFC7344] Section 4).

  4.1.  Signaling Consent to Act as the Child's Signer

     To confirm its willingness to act as the child's delegated signer and
     authenticate the child's CDS/CDNSKEY RRsets, the child DNS operator
     MUST co-publish them at the corresponding signaling name under each
     signaling domain, excluding those that would fall within the child
     domain (Section 3.2).  For simplicity, the child DNS operator MAY
     also co-publish the child's CDS/CDNSKEY RRsets under signaling
     domains within the child domain, although those signaling domains are
     not used for validation (Section 4.2).

     Unlike the CDS/CDNSKEY RRsets at the child's apex, a signaling record
     set MUST be signed with the corresponding signaling zone's key(s).
     Its contents MUST be identical to the corresponding RRset published
     at the child's apex.

     Existing use of CDS/CDNSKEY records was specified at the child apex
     only ([RFC7344], Section 4.1).  This protocol extends the use of
     these record types to non-apex owner names for the purpose of DNSSEC
     bootstrapping.  To exclude the possibility of semantic collision,
     there MUST NOT be a zone cut at a signaling name.








  Thomassen & Wisiol      Expires 29 November 2024                [Page 6]


  Internet-Draft            dnssec-bootstrapping                  May 2024


  4.1.1.  Example

     For the purposes of bootstrapping the child zone example.co.uk with
     NS records ns1.example.net, ns2.example.org, and ns3.example.co.uk,
     the required signaling domains are _signal.ns1.example.net and
     _signal.ns2.example.org.

     In the zones containing these domains, the child DNS operator
     authenticates the CDS/CDNSKEY RRsets found at the child's apex by co-
     publishing them as CDS/CDNSKEY RRsets at the names:

     _dsboot.example.co.uk._signal.ns1.example.net
     _dsboot.example.co.uk._signal.ns2.example.org

     These RRsets are signed with DNSSEC just like any other zone data.

     Publication of signaling records under the in-domain name
     _signal.ns3.example.co.uk is not required.

  4.2.  Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping

     To validate a child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, the
     parental agent, knowing both the child zone name and its NS
     hostnames, MUST execute the following steps:

     1.  verify that the child has no DS records published at the parent
         and that at least one of its nameservers is outside the child
         domain;

     2.  query the CDS/CDNSKEY RRset at the child zone apex directly from
         each of the authoritative servers as determined by the
         delegation's (parent-side) NS RRset, without caching;

     3.  query the CDS/CDNSKEY RRset located at the signaling name under
         each signaling domain (except those falling within the child
         domain) using a trusted DNS resolver and enforce DNSSEC
         validation;

     4.  check (separately by record type) that all RRsets retrieved in
         Steps 2 and 3 have equal contents;

     If the above steps succeed without error, the CDS/CDNSKEY RRsets are
     successfully verified, and the parental agent can proceed with the
     publication of the DS RRset under the precautions described in
     [RFC8078], Section 5.

     The parental agent MUST abort the procedure if an error condition
     occurs, in particular:



  Thomassen & Wisiol      Expires 29 November 2024                [Page 7]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     *  in Step 1: the child is already securely delegated or has in-
        domain nameservers only;

     *  in Step 2: any failure during the retrieval of the CDS/CDNSKEY
        RRset located at the child apex from any of the authoritative
        nameservers;

     *  in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets located
        at the signaling name under any signaling domain, including
        failure of DNSSEC validation, or unauthenticated data (AD bit not
        set);

     *  in Step 4: inconsistent responses (for at least one of the types),
        including an RRset that is empty in one of Steps 2 or 3, but non-
        empty in the other.

  4.2.1.  Example

     To verify the CDS/CDNSKEY RRsets for the child example.co.uk, the
     parental agent (assuming that the child delegation's NS records are
     ns1.example.net, ns2.example.org, and ns3.example.co.uk)

     1.  checks that the child domain is not yet securely delegated;

     2.  queries the CDS/CDNSKEY RRsets for example.co.uk directly from
         ns1.example.net, ns2.example.org, and ns3.example.co.uk (without
         caching);

     3.  queries and validates the CDS/CDNSKEY RRsets located at (see
         Section 3.2; ns3.example.co.uk is ignored because it is in-
         domain)

     _dsboot.example.co.uk._signal.ns1.example.net
     _dsboot.example.co.uk._signal.ns2.example.org

     4.  checks that the CDS/CDNSKEY RRsets retrieved in Steps 2 and 3
         agree across responses.

     If all these steps succeed, the parental agent can proceed to publish
     a DS RRset as indicated by the validated CDS/CDNSKEY RRset.

     As in-domain signaling names do not have a chain of trust at
     bootstrapping time, the parental agent does not consider them during
     validation.  Consequently, if all NS hostnames are in-domain,
     validation cannot be completed, and DS records are not published.






  Thomassen & Wisiol      Expires 29 November 2024                [Page 8]


  Internet-Draft            dnssec-bootstrapping                  May 2024


  4.3.  Triggers

     Parental agents SHOULD trigger the procedure described in Section 4.2
     once one of the following conditions is fulfilled:

     *  The parental agent receives a new or updated NS RRset for a child;

     *  The parental agent receives a notification indicating that the
        child wishes to have its CDS/CDNSKEY RRset processed;

     *  The parental agent encounters a signaling record during a
        proactive, opportunistic scan (e.g., daily queries of signaling
        records for some or all of its delegations);

     *  The parental agent encounters a signaling record during an NSEC
        walk or when parsing a signaling zone (e.g., when made available
        via AXFR by the child DNS operator);

     *  Any other condition as deemed appropriate by local policy.

     Timer-based trigger mechanisms (such as scans) exhibit undesirable
     properties with respect to processing delay and scaling; on-demand
     triggers (like notifications) are preferable.  Whenever possible,
     child DNS operators and parental agents are thus encouraged to use
     them, reducing both delays and the amount of scanning traffic.

     Most types of discovery (such as daily scans of delegations) are
     based directly on the delegation's NS RRset.  In this case, these NS
     names can be used as is by the bootstrapping algorithm (Section 4.2)
     for querying signaling records.

     Some discovery methods, however, do not imply reliable knowledge of
     the delegation's NS RRset.  For example, when discovering signaling
     names by performing an NSEC walk or zone transfer of a signaling
     zone, the parental agent MUST NOT assume that a nameserver under
     whose signaling domain a signaling record appears is actually
     authoritative for the corresponding child.

     Instead, whenever a list of "bootstrappable domains" is obtained
     other than directly from the parent, the parental agent MUST
     ascertain that the delegation actually contains the nameserver
     hostname seen during discovery, and ensure that signaling record
     queries are only made against the proper set of nameservers as listed
     in the child's delegation from the parent.







  Thomassen & Wisiol      Expires 29 November 2024                [Page 9]


  Internet-Draft            dnssec-bootstrapping                  May 2024


  4.4.  Limitations

     As a consequence of Step 3 in Section 4.2, DS bootstrapping does not
     work for fully in-domain delegations, as no pre-existing chain of
     trust to the child domain is available during bootstrapping.  (As a
     workaround, one can add an out-of-domain nameserver to the initial NS
     RRset and remove it once bootstrapping is completed.  Automation for
     this is available via CSYNC records, see [RFC7477].)

     Fully qualified signaling names must by valid DNS names.  Label count
     and length requirements for DNS names ([RFC1035] Section 3.1) imply
     that the protocol does not work for unusually long child domain names
     or NS hostnames.

  5.  Operational Recommendations

  5.1.  Child DNS Operator

     It is possible to add CDS/CDNSKEY records and corresponding signaling
     records to a zone without the domain owner's explicit knowledge.  To
     spare domain owners from being caught off guard by the ensuing DS
     changes, child DNS operators following this practice are advised to
     make that transparent, such as by informing the domain owner during
     zone creation (e.g., in a GUI), or by notifying them via email.

     When transferring a zone to another DNS operator, the old and new
     child DNS operators need to cooperate to achieve a smooth transition,
     e.g., by using the multi-signer protocols described in [RFC8901].  If
     all else fails, the domain owner might have to request the removal of
     all DS records and have the transfer performed insecurely (see
     [I-D.hardaker-dnsop-intentionally-temporary-insec]).

     Signaling domains SHOULD be delegated as standalone zones, so that
     the signaling zone's apex coincides with the signaling domain (such
     as _signal.ns1.example.net).  While it is permissible for the
     signaling domain to be contained in a signaling zone of fewer labels
     (such as example.net), a zone cut ensures that bootstrapping
     activities do not require modifications of the zone containing the
     nameserver hostname.

     Once a Child DNS Operator determines that specific signaling record
     sets have been processed (e.g., by seeing the result in the parent
     zone), they are advised to remove them.  This will reduce the size of
     the signaling zone, and facilitate more efficient bulk processing
     (such as via zone transfers).






  Thomassen & Wisiol      Expires 29 November 2024               [Page 10]


  Internet-Draft            dnssec-bootstrapping                  May 2024


  5.2.  Parental Agent

     In order to ensure timely DNSSEC bootstrapping of insecure domains,
     stalemate situations due to mismatch of stale cached records (Step 4
     of Section 4.2) need to be avoided.  It is thus RECOMMENDED to
     perform queries into signaling domains with an (initially) empty
     resolver cache, or using some other method for retrieving fresh data
     from authoritative servers.

     It is also RECOMMENDED to use QNAME minimization [RFC9156] when
     resolving queries for signaling records, to guard against certain
     attacks (see Section 6).

  6.  Security Considerations

     The DNSSEC bootstrapping method introduced in this document is based
     on the approaches described in [RFC8078] Section 3, but adds
     authentication to the CDS/CDNSKEY concept.  Its security level is
     therefore strictly higher than that of existing approaches described
     in that document (e.g., "Accept after Delay").  Apart from this
     general improvement, the same Security Considerations apply as in
     [RFC8078].

     The level of rigor in Section 4.2 is needed to prevent publication of
     a ill-conceived DS RRset (authorized only under a subset of NS
     hostnames).  This ensures, for example, that an operator in a multi-
     homed setup cannot enable DNSSEC unless all other operators agree.

     In any case, as the child DNS operator has authoritative knowledge of
     the child's CDS/CDNSKEY records, it can readily detect fraudulent
     provisioning of DS records.

     In order to prevent the parents of nameserver hostnames from becoming
     a single point of failure for a delegation (both in terms of
     resolution availability and for the trust model of this protocol), it
     is advisable to diversify the path from the root to the child's
     nameserver hostnames, such as by using different and independently
     operated TLDs for each one.

     If QNAME minimization [RFC9156] is not used when querying for
     signaling records, an upstream parent of a signaling domain will see
     those CDS/CDNSKEY queries and could respond with an authoritative
     answer signed with its own key, instead of sending the referral.
     Enabling QNAME minimization reduces the attack surface for such
     forgery.






  Thomassen & Wisiol      Expires 29 November 2024               [Page 11]


  Internet-Draft            dnssec-bootstrapping                  May 2024


  7.  IANA Considerations

     Per [RFC8552], IANA is requested to add the following entries to the
     "Underscored and Globally Scoped DNS Node Names" registry:

     +---------+------------+------------+
     | RR Type | _NODE NAME | Reference  |
     +---------+------------+------------+
     | CDS     | _signal    | [This RFC] |
     | CDNSKEY | _signal    | [This RFC] |
     +---------+------------+------------+

     *Note to the RFC Editor*: please replace "This RFC" in the above
     table with a proper reference.

  8.  Implementation Status

     *Note to the RFC Editor*: please remove this entire section before
     publication.

     In addition to the information in this section, deployment is tracked
     by the community at https://github.com/oskar456/cds-updates
     (https://github.com/oskar456/cds-updates).

  8.1.  Child DNS Operator-side

     *  Operator support:

        -  Cloudflare has implemented bootstrapping record synthesis for
           all signed customer zones.
        -  Glauca HexDNS publishes bootstrapping records for its customer
           zones.
        -  deSEC performs bootstrapping record synthesis for its zones
           using names _signal.ns1.desec.io and _signal.ns2.desec.org.

     *  Authoritative nameserver support:

        -  Knot DNS supports signaling record synthesis since version
           3.3.5.
        -  An implementation of bootstrapping record synthesis in PowerDNS
           is available at https://github.com/desec-io/desec-ns/pull/46
           (https://github.com/desec-io/desec-ns/pull/46).

  8.2.  Parental Agent-side

     *  ccTLD:





  Thomassen & Wisiol      Expires 29 November 2024               [Page 12]


  Internet-Draft            dnssec-bootstrapping                  May 2024


        -  SWITCH (.ch, .li) has implemented authentication of consumed
           CDS records based on this draft.
        -  .cl is working on an implementation.

     *  gTLD:

        -  Knipp has implemented consumption of DNSSEC bootstrapping
           records in its TANGO and CORE registry systems.
        -  A deployment of this is running at .swiss.

     *  Registrars:

        -  Glauca has implemented authenticated CDS processing.
        -  GoDaddy is working on an implementation.

     *  A tool to retrieve and process signaling records for bootstrapping
        purposes, either directly or via zone walking, is available at
        https://github.com/desec-io/dsbootstrap (https://github.com/desec-
        io/dsbootstrap).  The tool outputs the validated DS records which
        then can be added to the parent zone.

  9.  Acknowledgements

     Thanks to Brian Dickson, Ondřej Caletka, John R.  Levine, Christian
     Elmerot, Oli Schacher, Donald Eastlake, Libor Peltan, Warren Kumari,
     Scott Rose, Linda Dunbar, Tim Wicinski, Paul Wouters, Paul Hoffman,
     Peter Yee, Benson Muite, Roman Danyliw, Éric Vyncke, and Joe Abley
     for reviewing draft proposals and offering comments and suggestions.

     Thanks also to Steve Crocker, Hugo Salgado, and Ulrich Wisser for
     early-stage brainstorming.

  10.  References

  10.1.  Normative References

     [RFC1035]  Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
                November 1987, <https://www.rfc-editor.org/info/rfc1035>.

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







  Thomassen & Wisiol      Expires 29 November 2024               [Page 13]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
                DNSSEC Delegation Trust Maintenance", RFC 7344,
                DOI 10.17487/RFC7344, September 2014,
                <https://www.rfc-editor.org/info/rfc7344>.

     [RFC7477]  Hardaker, W., "Child-to-Parent Synchronization in DNS",
                RFC 7477, DOI 10.17487/RFC7477, March 2015,
                <https://www.rfc-editor.org/info/rfc7477>.

     [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from
                the Parent via CDS/CDNSKEY", RFC 8078,
                DOI 10.17487/RFC8078, March 2017,
                <https://www.rfc-editor.org/info/rfc8078>.

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

     [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
                Records through "Underscored" Naming of Attribute Leaves",
                BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
                <https://www.rfc-editor.org/info/rfc8552>.

     [RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
                Name Minimisation to Improve Privacy", RFC 9156,
                DOI 10.17487/RFC9156, November 2021,
                <https://www.rfc-editor.org/info/rfc9156>.

     [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
                RFC 9499, DOI 10.17487/RFC9499, March 2024,
                <https://www.rfc-editor.org/info/rfc9499>.

  10.2.  Informative References

     [BCP237]   Best Current Practice 237,
                <https://www.rfc-editor.org/info/bcp237>.
                At the time of writing, this BCP comprises the following:

                Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
                RFC 9364, DOI 10.17487/RFC9364, February 2023,
                <https://www.rfc-editor.org/info/rfc9364>.

     [I-D.hardaker-dnsop-intentionally-temporary-insec]
                Hardaker, W., "Intentionally Temporarily Degraded or
                Insecure", Work in Progress, Internet-Draft, draft-
                hardaker-dnsop-intentionally-temporary-insec-01, 21
                October 2021, <https://datatracker.ietf.org/doc/html/
                draft-hardaker-dnsop-intentionally-temporary-insec-01>.



  Thomassen & Wisiol      Expires 29 November 2024               [Page 14]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     [RFC8901]  Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
                Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
                DOI 10.17487/RFC8901, September 2020,
                <https://www.rfc-editor.org/info/rfc8901>.

  Appendix A.  Change History (to be removed before publication)

     *  draft-ietf-dnsop-dnssec-bootstrapping-11

     |  Addressed comment by Paul Wouters

     *  draft-ietf-dnsop-dnssec-bootstrapping-10

     |  Editorial nit
     |  
     |  Addressed comments by Paul Wouters
     |  
     |  Make capitalization of registrar/registrant consistent
     |  
     |  Editorial nit by Joe Abley
     |  
     |  Addressed comments by Éric Vyncke

     *  draft-ietf-dnsop-dnssec-bootstrapping-09

     |  Addressed comments by Paul Wouters
     |  
     |  Editorial nits by Roman Danyliw
     |  
     |  Editorial nits by Benson Muite
     |  
     |  Editorial nits by Peter Yee
     |  
     |  Editorial nit by Scott Rose
     |  
     |  Editorial suggestion from John Levine

     *  draft-ietf-dnsop-dnssec-bootstrapping-08

     |  Editorial changes from AD Review
     |  
     |  Updated implementation section
     |  
     |  Change capitalization of terms from terminology section

     *  draft-ietf-dnsop-dnssec-bootstrapping-07

     |  Add Glauca registrar implementation



  Thomassen & Wisiol      Expires 29 November 2024               [Page 15]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     |  
     |  Editorial changes to Security Considerations
     |  
     |  Add/discuss on-demand triggers (notifications)

     *  draft-ietf-dnsop-dnssec-bootstrapping-06

     |  Add section "Updates to RFCs"
     |  
     |  Editorial nits
     |  
     |  Editorial changes from Secdir early review

     *  draft-ietf-dnsop-dnssec-bootstrapping-05

     |  Editorial changes

     *  draft-ietf-dnsop-dnssec-bootstrapping-04

     |  Added consent considerations.
     |  
     |  Editorial changes.

     *  draft-ietf-dnsop-dnssec-bootstrapping-03

     |  Updated Implementation section.
     |  
     |  Typo fix.

     *  draft-ietf-dnsop-dnssec-bootstrapping-02

     |  Clarified that RFC 8078 Section 3 is not replaced, but its methods
     |  are deprecated.
     |  
     |  Added new deployments to Implementation section.
     |  
     |  Included NSEC walk / AXFR as possible triggers for DS
     |  bootstrapping.
     |  
     |  Editorial changes.

     *  draft-ietf-dnsop-dnssec-bootstrapping-01

     |  Allow bootstrapping when some (not all) NS hostnames are in
     |  bailiwick.
     |  
     |  Clarified Operational Recommendations according to operator
     |  feedback.



  Thomassen & Wisiol      Expires 29 November 2024               [Page 16]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     |  
     |  Turn loose Security Considerations points into coherent text.
     |  
     |  Do no longer suggest NSEC-walking Signaling Domains.  (It does not
     |  work well due to the Signaling Type prefix.  What's more, it's
     |  unclear who would do this: Parents know there delegations and can
     |  do a targeted scan; others are not interested.)
     |  
     |  Editorial changes.
     |  
     |  Added IANA request.
     |  
     |  Introduced Signaling Type prefix (_dsboot), renamed Signaling Name
     |  infix from _dsauth to _signal.

     *  draft-ietf-dnsop-dnssec-bootstrapping-00

     |  Editorial changes.

     *  draft-thomassen-dnsop-dnssec-bootstrapping-03

     |  Clarified importance of record cleanup by moving paragraph up.
     |  
     |  Pointed out limitations.
     |  
     |  Replace [RFC8078] Section 3 with our Section 4.2.
     |  
     |  Changed _boot label to _dsauth.
     |  
     |  Removed hashing of Child name components in Signaling Names.
     |  
     |  Editorial changes.

     *  draft-thomassen-dnsop-dnssec-bootstrapping-02

     |  Reframed as an authentication mechanism for RFC 8078.
     |  
     |  Removed multi-signer use case (focus on RFC 8078 authentication).
     |  
     |  Triggers need to fetch NS records (if not implicit from context).
     |  
     |  Improved title.
     |  
     |  Recognized that hash collisions are dealt with by Child apex
     |  check.

     *  draft-thomassen-dnsop-dnssec-bootstrapping-01




  Thomassen & Wisiol      Expires 29 November 2024               [Page 17]


  Internet-Draft            dnssec-bootstrapping                  May 2024


     |  Add section on Triggers.
     |  
     |  Clarified title.
     |  
     |  Improved abstract.
     |  
     |  Require CDS/CDNSKEY records at the Child.
     |  
     |  Reworked Signaling Name scheme.
     |  
     |  Recommend using cold cache for consumption.
     |  
     |  Updated terminology (replace "Bootstrapping" by "Signaling").
     |  
     |  Added NSEC recommendation for Bootstrapping Zones.
     |  
     |  Added multi-signer use case.
     |  
     |  Editorial changes.

     *  draft-thomassen-dnsop-dnssec-bootstrapping-00

     |  Initial public draft.

  Authors' Addresses

     Peter Thomassen
     deSEC, Secure Systems Engineering
     Berlin
     Germany
     Email: peter@desec.io


     Nils Wisiol
     deSEC, Technische Universität Berlin
     Berlin
     Germany
     Email: nils@desec.io













  Thomassen & Wisiol      Expires 29 November 2024               [Page 18]


name: draft-ar-emu-pqc-eapaka
rev: 04
title: Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography
time: 2025-03-17T03:19:14Z
group_uri: /api/v1/group/group/1027/
expires: 2025-09-18T03:19:14Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-04T00:00:05.731095+00:00
source: ietf
abstract:
  Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology]
     algorithms to make it quantum-safe.

full_text:
  EMU                                                          A. Banerjee
  Internet-Draft                                                  T. Reddy
  Intended status: Standards Track                                   Nokia
  Expires: 17 September 2025                                 16 March 2025


    Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography
                         draft-ar-emu-pqc-eapaka-04

  Abstract

     Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology]
     algorithms to make it quantum-safe.

  About This Document

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

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ar-emu-pqc-eapaka/.

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

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



  Banerjee & Reddy        Expires 17 September 2025               [Page 1]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


     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 17 September 2025.

  Copyright Notice

     Copyright (c) 2025 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Background on EAP-AKA' with perfect forward secrecy . . . . .   4
     5.  Hybrid Enhancements by Design . . . . . . . . . . . . . . . .   5
     6.  Protocol Construction . . . . . . . . . . . . . . . . . . . .   6
       6.1.  Protocol Call Flow  . . . . . . . . . . . . . . . . . . .   6
       6.2.  Key Steps in protocol construction  . . . . . . . . . . .   8
     7.  Extensions to EAP-AKA' FS . . . . . . . . . . . . . . . . . .   9
       7.1.  AT_PUB_HYBRID . . . . . . . . . . . . . . . . . . . . . .  10
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
       10.2.  Informative References . . . . . . . . . . . . . . . . .  12
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13











  Banerjee & Reddy        Expires 17 September 2025               [Page 2]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


  1.  Introduction

     Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) defined in [RFC9678]
     updates the improved Extensible Authentication Protocol Method for
     3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
     specified in [RFC9048], with an optional extension providing
     ephemeral key exchange.  This prevents an attacker who has gained
     access to the long term key from obtaining session keys established
     in the past, assuming these have been properly deleted.  EAP-AKA' FS
     mitigates passive attacks (e.g., large scale pervasive monitoring)
     against future sessions.

     Nevertheless, EAP-AKA' FS uses traditional algorithms public-key
     algorithms (e.g., ECDH) which will be broken by a Cryptographically
     Relevant Quantum Computer (CRQC) using Shor's algorithm.  The
     presence of a CRQC would render state-of-the-art, traditional public-
     key algorithms deployed today obsolete and insecure, since the
     assumptions about the intractability of the mathematical problems for
     these algorithms that offer confident levels of security today no
     longer apply in the presence of a CRQC.  A CRQC could recover the
     SHARED_SECRET from the ECDHE public keys (Section 6.3 of [RFC9678]).
     If the adversary has also obtained knowledge of the long-term key, it
     could then compute CK', IK', and the SHARED_SECRET, and any derived
     output keys.  This means that the CRQC would disable the forward
     security capability provided by [RFC9678].

     The migration to PQC is unique in the history of modern digital
     cryptography in that neither the traditional algorithms nor the post-
     quantum algorithms are fully trusted to protect data for the required
     data lifetimes.  The post-quantum algorithms face uncertainty about
     the underlying mathematics, compliance issues, unknown
     vulnerabilities, hardware and software implementations that have not
     had sufficient maturing time to rule out classical cryptanalytic
     attacks and implementation bugs.  During the transition from
     traditional to post-quantum algorithms, there is a desire or a
     requirement for protocols that use both algorithm types.

     This specification defines Hybrid public-key encryption (HPKE)
     [RFC9180] for use with EAP-AKA' FS.  HPKE offers a variant of public-
     key encryption of arbitrary-sized plaintexts for a recipient public
     key.  HPKE works for any combination of an asymmetric key
     encapsulation mechanism (KEM), key derivation function (KDF), and
     authenticated encryption with additional data (AEAD) function.  HPKE
     can be extended to support hybrid post-quantum Key Encapsulation
     Mechanisms (KEMs) as defined in [I-D.connolly-cfrg-xwing-kem].





  Banerjee & Reddy        Expires 17 September 2025               [Page 3]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


  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.

  3.  Terminology

     This document makes use of the terms defined in
     [I-D.ietf-pquip-pqt-hybrid-terminology].  For the purposes of this
     document, it is helpful to be able to divide cryptographic algorithms
     into two classes:

     "Traditional Algorithm": An asymmetric cryptographic algorithm based
     on integer factorisation, finite field discrete logarithms or
     elliptic curve discrete logarithms.  In the context of JOSE, examples
     of traditional key exchange algorithms include Elliptic Curve Diffie-
     Hellman Ephemeral Static [RFC6090] [RFC8037].  In the context of
     COSE, examples of traditional key exchange algorithms include
     Ephemeral-Static (ES) DH and Static-Static (SS) DH [RFC9052].

     "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that
     is believed to be secure against attacks using quantum computers as
     well as classical computers.  Examples of PQC key exchange algorithms
     include Kyber.

     "Hybrid" key exchange, in this context, means the use of two key
     exchange algorithms based on different cryptographic assumptions,
     e.g., one traditional algorithm and one Post-Quantum algorithm, with
     the purpose of the final shared secret key being secure as long as at
     least one of the component key exchange algorithms remains unbroken.
     It is referred to as PQ/T Hybrid Scheme in
     [I-D.ietf-pquip-pqt-hybrid-terminology].

     PQ/T Hybrid Key Encapsulation Mechanism: A Key Encapsulation
     mechanism (KEM) made up of two or more component KEM algorithms where
     at least one is a post-quantum algorithm and at least one is a
     traditional algorithm.

  4.  Background on EAP-AKA' with perfect forward secrecy

     In EAP-AKA', The authentication vector (AV) contains a random part
     RAND, an authenticator part AUTN used for authenticating the network
     to the USIM, an expected result part XRES, a 128-bit session key for
     integrity check IK, and a 128-bit session key for encryption CK.




  Banerjee & Reddy        Expires 17 September 2025               [Page 4]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


     As described in the draft [RFC9678], the server has the EAP identity
     of the peer.  The server asks the AD to run AKA algorithm to generate
     RAND, AUTN, XRES, CK and IK.  Further it also derives CK’ and IK’
     keys which are tied to a particular network name.  The server now
     generates the ephemeral key pair and sends the public key of that key
     pair and the first EAP method message to the peer.  In this EAP
     message, AT_PUB_ECDHE (carries public key) and the AT_KDF_FS(carries
     other FS related parameters).  Both of these might be ignored of USIM
     doesn’t support the Forward Secrecy extension.  The peer checks if it
     wants to have a Forward extension in EAP AKA'.  If yes, then it will
     eventually respond with AT_PUB_ECDHE and MAC.  If not, it will ignore
     AT_PUB_ECDHE.  If the peer wants to participate in FS extension, it
     will then generate its ECDH key pair, calculate a shared key based on
     its private key and server public key.  The server will receive the
     RES from peer and AT_PUB_ECDHE.  The shared key will be generated
     both in the peer and the server with key pairs exchanged, and later
     master key is also generated.

     MK_ECDHE = PRF'(IK'| CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)

  5.  Hybrid Enhancements by Design

     We suggest the following changes and enhancements:

     *  A new attribute, AT_PUB_HYBRID, is defined to carry the public
        key, which is the concatenation of traditional and PQC KEM public
        keys from the EAP server.  The AT_PUB_HYBRID attribute will carry
        the encapsulated key, which is formed by concatenating the
        encapsulated key (enc) from the traditional KEM algorithm and the
        ciphertext (ct) from the PQC KEM Encapsulation function from the
        EAP peer.

     *  The AT_KDF_FS attribute is updated to indicate the HPKE KEM and
        HKDF for generating the Hybrid Master Key MK_HYBRID.

     *  Multiple AT_KDF_FS attributes is included in the EAP-Request to
        handle the EAP peer not supporting HPKE Hybrid KEM.

     *  The Hybrid key derivation function will be included first in the
        EAP-Request to indicate a higher priority than the traditional key
        derivation function.










  Banerjee & Reddy        Expires 17 September 2025               [Page 5]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


  6.  Protocol Construction

     This section defines the construction for hybrid key exchange in EAP-
     AKA' FS.  Hybrid key exchange refers to using multiple key exchange
     algorithms simultaneously and combining the result with the goal of
     providing security even if all but one of the component algorithms is
     broken.  It is motivated by transition to post-quantum cryptography.

  6.1.  Protocol Call Flow

      USIM           Peer                        Server              AD
       |              |                            |                |
       |              |           EAP-Req/Identity |                |
       |              |<---------------------------+                |
       |              |                            |                |
       |              | EAP-Resp/Identity          |                |
       |              | (Privacy-Friendly)         |                |
       |              +--------------------------->|                |
       |      +-------+----------------------------+----------------+--+
       |      | Server now has an identity for the peer. The server    |
       |      | then asks the help of AD to run AKA algorithms,        |
       |      | generating RAND, AUTN, XRES, CK, IK. Typically, the    |
       |      | AD performs the first part of key derivations so that  |
       |      | the authentication server gets the CK' and IK' keys    |
       |      | already tied to a particular network name.             |
       |      +-------+----------------------------+----------------+--+
       |              |                            |                |
       |              |                            | ID, key deriv. |
       |              |                            | function,      |
       |              |                            | network name   |
       |              |                            +--------------->|
       |              |                            |                |
       |              |                            |    RAND, AUTN, |
       |              |                            | XRES, CK', IK' |
       |              |                            |<---------------+
       |      +-------+----------------------------+----------------+--+
       |      | Server now has the needed authentication vector. It    |
       |      | generates a PQC KEM key pair, an ephemeral ECDHE key   |
       |      | pair, sends the hybrid (PQC + ECDHE) public key of that|
       |      | key pair and the first EAP method message to the peer  |
       |      | In the message the AT_PUB_HYBRID attribute             |
       |      | carries the concatenation of PQC KEM and ECDHE public  |
       |      | keys and the AT_KDF_FS attribute carries other         |
       |      | FS-related parameters. Both of these are               |
       |      | skippable attributes that can be ignored if the peer   |
       |      | does not support this extension.                       |
       |      +-------+----------------------------+----------------+--+
       |              |                            |                |



  Banerjee & Reddy        Expires 17 September 2025               [Page 6]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


       |              |     EAP-Req/AKA'-Challenge |                |
       |              |  AT_RAND, AT_AUTN, AT_KDF, |                |
       |              |   AT_KDF_FS, AT_KDF_INPUT, |                |
       |              |       AT_PUB_HYBRID, AT_MAC|                |
       |              |<---------------------------+                |
     +--+--------------+----------------------------+---------+     |
     | The peer checks if it wants to do the FS extension. If |     |
     | yes, it will eventually respond with AT_PUB_HYBRID and |     |
     | AT_MAC. If not, it will ignore AT_PUB_HYBRID and       |     |
     | AT_KDF_FS and base all calculations on basic EAP-AKA'  |     |
     | attributes, continuing just as in EAP-AKA' per RFC     |     |
     | 9048 rules. In any case, the peer needs to query the   |     |
     | auth parameters from the USIM card.                    |     |
     +--+--------------+----------------------------+---------+     |
       |              |                            |                |
       |   RAND, AUTN |                            |                |
       |<-------------+                            |                |
       |              |                            |                |
       | CK, IK, RES  |                            |                |
       +------------->|                            |                |
     +--+--------------+----------------------------+---------+     |
     | The peer now has everything to respond. If it wants to |     |
     | participate in the FS extension, it will then generate |     |
     | its ECDHE key pair, calculate a hybrid shared secret   |     |
     | key based on the server's PQC KEM public key, its ECDHE|     |
     | key pair and the server's ECDHE public key. Finally,   |     |
     | it proceeds to derive all EAP-AKA' key values and      |     |
     | constructs a full response.                            |     |
     +--+--------------+----------------------------+---------+     |
       |              |                            |                |
       |              | EAP-Resp/AKA'-Challenge    |                |
       |              | AT_RES, AT_PUB_HYBRID,     |                |
       |              | AT_MAC                     |                |
       |              +--------------------------->|                |
       |      +-------+----------------------------+----------------+--+
       |      | The server now has all the necessary values. It        |
       |      | generates the Hybrid shared secret and checks the RES  |
       |      | and MAC values received in AT_RES and AT_MAC,          |
       |      | respectively. Success requires both to be found        |
       |      | correct. Note that when this document is used,         |
       |      | the keys generated from EAP-AKA' are based on CK, IK,  |
       |      | and the ECDHE and PQC KEM values. Even if there was an |
       |      | attacker who held the long-term key, only an active    |
       |      | attacker could have determined the generated session   |
       |      | keys; additionally an attacker with a cryptographically|
       |      | relevant quantum computer cannot get access to the     |
       |      | server KEM private key and decrypt the data.           |
       |      +-------+----------------------------+----------------+--+



  Banerjee & Reddy        Expires 17 September 2025               [Page 7]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


       |              |                            |                |
       |              |                EAP-Success |                |
       |              |<---------------------------+                |
       |              |                            |                |

  6.2.  Key Steps in protocol construction

     We outline the following key steps in the protocol:

     *  Server generates the PQC KEM Public key(pk_M), private key (sk_M)
        pair and the ECDH public key (pk_X), private key (sk_X) pair.  The
        server will generate and send the EAP AKA' Authentication Vector
        (AV).  As defined in section 5.2 of [I-D.connolly-cfrg-xwing-kem]
        the server PQC KEM and ECDH key pairs are derived as:

        def GenerateKeyPair():
          (pk_M, sk_M) = ML-KEM-768.KeyGen()
          sk_X = random(32)
          pk_X = X25519(sk_X, X25519_BASE)
          return concat(sk_M, sk_X, pk_X), concat(pk_M, pk_X)

     *  The server will store the expected response XRES, the ECDH private
        key sk_X and the PQC KEM private key sk_M.  The server will
        forward the EAP AKA' AV to peer along with pk_X and pk_M.

     *  The USIM will validate the AUTH received, also verifies the MAC.
        After the verification is successful and if the peer also supports
        the Forward secrecy, peer will invoke Encapsulate using
        concat(pk_M,pk_X) as defined in section 5.4 of
        [I-D.connolly-cfrg-xwing-kem]:

        def Encapsulate(pk):
          pk_M = pk[0:1184]
          pk_X = pk[1184:1216]
          ek_X = random(32)
          ct_X = X25519(ek_X, X25519_BASE)
          ss_X = X25519(ek_X, pk_X)
          (ss_M, ct_M) = ML-KEM-768.Encaps(pk_M)
          ss = Combiner(ss_M, ss_X, ct_X, pk_X)
          ct = concat(ct_M, ct_X)
          return (ss, ct)










  Banerjee & Reddy        Expires 17 September 2025               [Page 8]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


     "ct" is the concatenation of the ciphertext from PQC KEM and
     encapsulated key from ECDH whereas "ss" is hybrid shared secret key.
     Hybrid shared key ss is generated by the peer using the Encapsulate()
     ([I-D.connolly-cfrg-xwing-kem]).  The Combiner() is a "hash and
     concatenation" based approach using SHA3-256 (See section 5.3 of
     [I-D.connolly-cfrg-xwing-kem]) to generate a “hybrid” shared secret
     (ss).

     *  The peer will send the Authentication response RES and ct to the
        server.

     *  The server will verify the RES with XRES.  The server will use the
        ct, PQC KEM private key sk_M and ECDH private key sk_X to generate
        shared secret:

        def Decapsulate(ct, sk):
          ct_M = ct[0:1088]
          ct_X = ct[1088:1120]
          sk_M = sk[0:2400]
          sk_X = sk[2400:2432]
          pk_X = sk[2432:2464]
          ss_M = ML-KEM-768.Decapsulate(ct_M, sk_M)
          ss_X = X25519(sk_X, ct_X)
          return Combiner(ss_M, ss_X, ct_X, pk_X)

     The generated ss from Decapsulate is the hybrid shared secret key
     derived from PQC KEM and traditional ECDH.  The peer and the server
     first generate the MK_HYBRID and subsequently generate MSK, EMSK as
     shown below:

     MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
     HYBRID_SHARED_SECRET, ct = Encapsulate(pKR)
     MK_HYBRID = PRF'(IK'|CK'| HYBRID_SHARED_SECRET,"EAP-AKA' FS"| Identity)
     K_encr = MK[0..127]
     K_aut = MK[128..383]
     K_re = MK_HYBRID [0..255]
     MSK = MK_HYBRID [256..767]
     EMSK = MK_HYBRID [768..1279]

     where, pkR is concatenation of PQC KEM and traditional public keys of
     the receiver, ct is concatenation of the ciphertext from the PQC KEM
     and encapsulated key from ECDH; the Encapsulate() function is
     perfomed by the peer only.

  7.  Extensions to EAP-AKA' FS






  Banerjee & Reddy        Expires 17 September 2025               [Page 9]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


  7.1.  AT_PUB_HYBRID

     The format of the AT_PUB_HYBRID attribute is shown below.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | AT_PUB_HYBRID | Length        | Value                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The fields are as follows:

     AT_PUB_HYBID:

     This is set to TBA1 BY IANA.

     Length:

     The length of the attribute, set as other attributes in EAP-AKA
     [RFC4187].  The length is expressed in multiples of 4 bytes.  The
     length includes the attribute type field, the Length field itself,
     and the Value field (along with any padding).

     Value:

    *  EAP-Request: It contains the public key, which is the concatenation of
       traditional and PQC KEM public keys from the EAP server.
    *  EAP-Response: It contains the encapsulated key, which is formed by
       concatenating the ciphertext (ct) from the PQC KEM Encapsulation function
       and the encapsulated key (enc) from the traditional KEM algorithm and from the
       EAP peer.

     Because the length of the attribute must be a multiple of 4 bytes,the
     sender pads the Value field with zero bytes when necessary.  To
     retain the security of the keys, the sender SHALL generate a fresh
     value for each run of the protocol.

  8.  Security Considerations

     ML-KEM is IND-CCA2 secure based on multiple analyses.  The ML-KEM
     variant and its underlying components should be selected consistently
     with the desired security level.  For further clarity on the sizes
     and security levels of ML-KEM variants, please refer to the tables in
     Sections 12 and 13 of [I-D.ietf-pquip-pqc-engineers].

     The security of the ML-KEM algorithm depends on a high-quality
     pseudo-random number generator.  For further discussion on random
     number generation, see [RFC4086].



  Banerjee & Reddy        Expires 17 September 2025              [Page 10]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


     In general, good cryptographic practice dictates that a given ML-KEM
     key pair should be used in only one EAP session.  This practice
     mitigates the risk that compromising one EAP session will not
     compromise the security of another EAP session and is essential for
     maintaining forward security.

     For security properties of traditional ECDHE for EAP-AKA FS, see
     section 7 of [RFC9678].  The overall Hybrid scheme needs to be IND-
     CCA2 robust; i.e., atleast one of the schemes should be IND-CCA2
     secure.

  9.  IANA Considerations

     One new value (TBA1) in the skippable range need to be assigned by
     IANA for AT_PUB_HYBRID (Section 7.1) in the "Attribute Types"
     registry under the "EAP-AKA and EAP-SIM Parameters" group.

     IANA is requested to update the registry "EAP-AKA' AT_KDF_FS Key
     Derivation Function Values" with the Hybrid key derivation function
     entry:

     +=========+===============================+=========================+
     | Value   | Description                   | Reference               |
     +=========+===============================+=========================+
     | TBA2    | X25519Kyber768Draft00         | [TBD BY IANA: THIS RFC] |
     +=========+===============================+=========================+

  10.  References

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

     [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
                Protocol Method for 3rd Generation Authentication and Key
                Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
                January 2006, <https://www.rfc-editor.org/rfc/rfc4187>.

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







  Banerjee & Reddy        Expires 17 September 2025              [Page 11]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


     [RFC9048]  Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
                "Improved Extensible Authentication Protocol Method for
                3GPP Mobile Network Authentication and Key Agreement (EAP-
                AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
                <https://www.rfc-editor.org/rfc/rfc9048>.

     [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
                Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
                February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

     [RFC9678]  "*** BROKEN REFERENCE ***".

  10.2.  Informative References

     [I-D.connolly-cfrg-xwing-kem]
                Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing:
                general-purpose hybrid post-quantum KEM", Work in
                Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-
                06, 21 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-connolly-
                cfrg-xwing-kem-06>.

     [I-D.ietf-pquip-pqc-engineers]
                Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
                T., and M. Ounsworth, "Post-Quantum Cryptography for
                Engineers", Work in Progress, Internet-Draft, draft-ietf-
                pquip-pqc-engineers-09, 13 February 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
                pqc-engineers-09>.

     [I-D.ietf-pquip-pqt-hybrid-terminology]
                D, F., P, M., and B. Hale, "Terminology for Post-Quantum
                Traditional Hybrid Schemes", Work in Progress, Internet-
                Draft, draft-ietf-pquip-pqt-hybrid-terminology-06, 10
                January 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-pquip-pqt-hybrid-terminology-06>.

     [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
                "Randomness Requirements for Security", BCP 106, RFC 4086,
                DOI 10.17487/RFC4086, June 2005,
                <https://www.rfc-editor.org/rfc/rfc4086>.

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





  Banerjee & Reddy        Expires 17 September 2025              [Page 12]


  Internet-Draft         PQC Hybrid in EAP-AKA prime            March 2025


     [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
                and Signatures in JSON Object Signing and Encryption
                (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8037>.

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

  Appendix A.  Acknowledgements

     This draft leverages text from [RFC9678].

  Authors' Addresses

     Aritra Banerjee
     Nokia
     Munich
     Germany
     Email: aritra.banerjee@nokia.com


     Tirumaleswar Reddy
     Nokia
     Bangalore
     Karnataka
     India
     Email: kondtir@gmail.com






















  Banerjee & Reddy        Expires 17 September 2025              [Page 13]


name: draft-kwiatkowski-tls-ecdhe-mlkem
rev: 03
title: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
time: 2025-02-26T18:27:59Z
group_uri: /api/v1/group/group/1326/
expires: 2025-06-28T06:08:19Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/35/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-04T00:00:05.738237+00:00
source: ietf
abstract:
  This draft defines three hybrid key agreements for TLS 1.3:
     X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which
     combine a post-quantum KEM with an elliptic curve Diffie-Hellman
     (ECDHE).

full_text:
  Transport Layer Security                                  K. Kwiatkowski
  Internet-Draft                                                  PQShield
  Intended status: Informational                             P. Kampanakis
  Expires: 28 June 2025                                                AWS
                                                          B. E. Westerbaan
                                                                Cloudflare
                                                                D. Stebila
                                                    University of Waterloo
                                                          25 December 2024


         Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
                    draft-kwiatkowski-tls-ecdhe-mlkem-03

  Abstract

     This draft defines three hybrid key agreements for TLS 1.3:
     X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which
     combine a post-quantum KEM with an elliptic curve Diffie-Hellman
     (ECDHE).

  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://post-
     quantum-cryptography.github.io/draft-kwiatkowski-tls-ecdhe-mlkem/.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/.

     Discussion of this document takes place on the Transport Layer
     Security Working Group mailing list (mailto:tls@ietf.org), which is
     archived at https://mailarchive.ietf.org/arch/browse/tls/.  Subscribe
     at https://www.ietf.org/mailman/listinfo/tls/.

     Source for this draft and an issue tracker can be found at
     https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-
     ecdhe-mlkem.

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



  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 1]


  Internet-Draft                 ECDHE-MLKEM                 December 2024


     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 28 June 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Negotiated Groups . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Construction  . . . . . . . . . . . . . . . . . . . . . .   4
         3.1.1.  Client share  . . . . . . . . . . . . . . . . . . . .   4
         3.1.2.  Server share  . . . . . . . . . . . . . . . . . . . .   4
         3.1.3.  Shared secret . . . . . . . . . . . . . . . . . . . .   5
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  SecP256r1MLKEM768 . . . . . . . . . . . . . . . . . . . .   6
       5.2.  X25519MLKEM768  . . . . . . . . . . . . . . . . . . . . .   6
       5.3.  SecP384r1MLKEM1024  . . . . . . . . . . . . . . . . . . .   6
       5.4.  Obsoleted Supported Groups  . . . . . . . . . . . . . . .   7
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction







  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 2]


  Internet-Draft                 ECDHE-MLKEM                 December 2024


  1.1.  Motivation

     ML-KEM is a key encapsulation method (KEM) defined in the [FIPS203].
     It is designed to withstand cryptanalytic attacks from quantum
     computers.

     This document introduces three new supported groups for hybrid post-
     quantum key agreements in TLS 1.3: the X25519MLKEM768,
     SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine ML-KEM with
     ECDH in the manner of [hybrid].

     The first one uses X25519 [rfc7748] and is an update to
     X25519Kyber768Draft00 [xyber], the most widely deployed PQ/T hybrid
     combiner for TLS v1.3 deployed in 2024.

     The second one uses secp256r1 (NIST P-256) [ECDSA] [DSS].  The goal
     of this group is to support a use case that requires both shared
     secrets to be generated by FIPS-approved mechanisms.

     The third one uses secp384r1 (NIST P-384) [ECDSA] [DSS].  The goal of
     this group is to provide support for high security environments that
     require use of FIPS-approved mechanisms.

     All constructions aim to provide a FIPS-approved key-establishment
     scheme (as per [SP56C]).

  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.

  3.  Negotiated Groups

     All groups enable the derivation of TLS session keys using FIPS-
     approved schemes.  NIST's special publication 800-56Cr2 [SP56C]
     approves the usage of HKDF [HKDF] with two distinct shared secrets,
     with the condition that the first one is computed by a FIPS-approved
     key-establishment scheme.  FIPS also requires a certified
     implementation of the scheme, which will remain more ubiqutous for
     secp256r1 in the coming years.

     For this reason we put the ML-KEM shared secret first in
     X25519MLKEM768, and the ECDH shared secret first in SecP256r1MLKEM768
     and SecP384r1MLKEM1024.




  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 3]


  Internet-Draft                 ECDHE-MLKEM                 December 2024


     Note: The group name X25519MLKEM768 does not adhere to the naming
     convention outlined in Section 3.2 of [hybrid].  Specifically, the
     order of shares in the concatenation has been reversed.  This is due
     to historical reasons.

  3.1.  Construction

  3.1.1.  Client share

     When the X25519MLKEM768 group is negotiated, the client's
     key_exchange value is the concatenation of the client's ML-KEM-768
     encapsulation key and the client's X25519 ephemeral share.  The size
     of the client share is 1216 bytes (1184 bytes for the ML-KEM part and
     32 bytes for X25519).

     When the SecP256r1MLKEM768 group is negotiated, the client's
     key_exchange value is the concatenation of the secp256r1 ephemeral
     share and ML-KEM-768 encapsulation key.  The ECDHE share is the
     serialized value of the uncompressed ECDH point representation as
     defined in Section 4.2.8.2 of [RFC8446].  The size of the client
     share is 1249 bytes (65 bytes for the secp256r1 part and 1184 bytes
     for ML-KEM).

     When the SecP384r1MLKEM1024 group is negotiated, the client's
     key_exchange value is the concatenation of the secp384r1 ephemeral
     share and the ML-KEM-1024 encapsulation key.  The ECDH share is
     serialised value of the uncompressed ECDH point represenation as
     defined in Section 4.2.8.2 of [RFC8446].  The size of the client
     share is 1665 bytes (97 bytes for the secp384r1 and the 1568 for the
     ML-KEM).

  3.1.2.  Server share

     When the X25519MLKEM768 group is negotiated, the server's key
     exchange value is the concatenation of an ML-KEM ciphertext returned
     from encapsulation to the client's encapsulation key, and the
     server's ephemeral X25519 share.  The size of the server share is
     1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519).

     When the SecP256r1MLKEM768 group is negotiated, the server's key
     exchange value is the concatenation of the server's ephemeral
     secp256r1 share encoded in the same way as the client share and an
     ML-KEM ciphertext returned from encapsulation to the client's
     encapsulation key.  The size of the server share is 1153 bytes (1088
     bytes for the ML-KEM part and 65 bytes for secp256r1).






  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 4]


  Internet-Draft                 ECDHE-MLKEM                 December 2024


     When the SecP384r1MLKEM1024 group is negotiated, the server's key
     exchange value is the concatenation of the server's ephemeral
     secp384r1 share encoded in the same way as the client share and an
     ML-KEM ciphertext returned from encapsulation to the client's
     encapsulation key.  The size of the server share is 1665 bytes (1568
     bytes for the ML-KEM part and 97 bytes for secp384r1)

     For all groups, the server MUST perform the encapsulation key check
     described in Section 7.2 of [FIPS203] on the client's encapsulation
     key, and abort with an illegal_parameter alert if it fails.

     For all groups, the client MUST check if the ciphertext length
     matches the selected group, and abort with an illegal_parameter alert
     if it fails.  If ML-KEM decapsulation fails for any other reason, the
     connection MUST be aborted with an internal_error alert.

     For all groups, both client and server MUST process the ECDH part as
     described in Section 4.2.8.2 of [RFC8446], including all validity
     checks, and abort with an illegal_parameter alert if it fails.

  3.1.3.  Shared secret

     For X25519MLKEM768, the shared secret is the concatenation of the ML-
     KEM shared secret and the X25519 shared secret.  The shared secret is
     64 bytes (32 bytes for each part).

     For SecP256r1MLKEM768, the shared secret is the concatenation of the
     ECDHE and ML-KEM shared secret.  The ECDHE shared secret is the
     x-coordinate of the ECDH shared secret elliptic curve point
     represented as an octet string as defined in Section 7.4.2 of
     [RFC8446].  The size of the shared secret is 64 bytes (32 bytes for
     each part).

     For SecP384r1MLKEM1024, the shared secret is the concatenation of the
     ECDHE and ML-KEM shared secret.  The ECDHE shared secret is the
     x-coordinate of the ECDH shared secret elliptic curve point
     represented as an octet string as defined in Section 7.4.2 of
     [RFC8446].  The size of the shared secret is 80 bytes (48 bytes for
     the ECDH part and 32 bytes for the ML-KEM part).

     For all groups, both client and server MUST calculate the ECDH part
     of the shared secret as described in Section 7.4.2 of [RFC8446],
     including the shared secret check as described in Section 5.7.1.2 of
     [SP56A] or the all-zero shared secret check (depending on the curve),
     and abort the connection with an illegal_parameter alert if it fails.






  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 5]


  Internet-Draft                 ECDHE-MLKEM                 December 2024


  4.  Security Considerations

     The same security considerations as those described in [hybrid] apply
     to the approach used by this document.  The security analysis relies
     crucially on the TLS 1.3 message transcript, and one cannot assume a
     similar hybridisation is secure in other protocols.

     Implementers are encouraged to use implementations resistant to side-
     channel attacks, especially those that can be applied by remote
     attackers.

  5.  IANA Considerations

     This document requests/registers three new entries to the TLS
     Supported Groups registry, according to the procedures in Section 6
     of [tlsiana].  These identifiers are to be used with the final,
     ratified by NIST, version of ML-KEM which is specified in [FIPS203].

  5.1.  SecP256r1MLKEM768

     Value:  4587 (0x11EB)
     Description:  SecP256r1MLKEM768
     DTLS-OK:  Y
     Recommended:  N
     Reference:  This document
     Comment:  Combining secp256r1 ECDH with ML-KEM-768

  5.2.  X25519MLKEM768

     Value:  4588 (0x11EC)
     Description:  X25519MLKEM768
     DTLS-OK:  Y
     Recommended:  N
     Reference:  This document
     Comment:  Combining X25519 ECDH with ML-KEM-768

  5.3.  SecP384r1MLKEM1024

     Value:  4589 (0x11ED)
     Description:  SecP384r1MLKEM1024
     DTLS-OK:  Y
     Recommended:  N
     Reference:  This document
     Comment:  Combining secp384r1 ECDH with ML-KEM-1024







  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 6]


  Internet-Draft                 ECDHE-MLKEM                 December 2024


  5.4.  Obsoleted Supported Groups

     This document obsoletes 25497 and 25498 in the TLS Supported Groups
     registry.

  6.  References

  6.1.  Normative References

     [FIPS203]  "Module-lattice-based key-encapsulation mechanism
                standard", National Institute of Standards and Technology
                (U.S.), DOI 10.6028/nist.fips.203, August 2024,
                <https://doi.org/10.6028/nist.fips.203>.

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

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

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

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

     [SP56A]    Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
                Davis, "Recommendation for pair-wise key-establishment
                schemes using discrete logarithm cryptography", National
                Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-56ar3, April 2018,
                <https://doi.org/10.6028/nist.sp.800-56ar3>.

     [SP56C]    Barker, E., Chen, L., and R. Davis, "Recommendation for
                Key-Derivation Methods in Key-Establishment Schemes",
                National Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-56cr2, August 2020,
                <https://doi.org/10.6028/nist.sp.800-56cr2>.

  6.2.  Informative References






  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 7]


  Internet-Draft                 ECDHE-MLKEM                 December 2024


     [DSS]      Chen, L., Moody, D., Regenscheid, A., Robinson, A., and K.
                Randall, "Recommendations for Discrete Logarithm-based
                Cryptography:: Elliptic Curve Domain Parameters", National
                Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-186, February 2023,
                <https://doi.org/10.6028/nist.sp.800-186>.

     [ECDSA]    American National Standards Institute, "Public Key
                Cryptography for the Financial Services Industry: The
                Elliptic Curve Digital Signature Algorithm (ECDSA)",
                ANSI ANS X9.62-2005, November 2005.

     [HKDF]     Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
                Key Derivation Function (HKDF)", RFC Editor,
                DOI 10.17487/rfc5869, May 2010,
                <https://doi.org/10.17487/rfc5869>.

     [hybrid]   Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
                exchange in TLS 1.3", Work in Progress, Internet-Draft,
                draft-ietf-tls-hybrid-design-11, 7 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                hybrid-design-11>.

     [tlsiana]  Salowey, J. A. and S. Turner, "IANA Registry Updates for
                TLS and DTLS", Work in Progress, Internet-Draft, draft-
                ietf-tls-rfc8447bis-10, 3 November 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                rfc8447bis-10>.

     [xyber]    Westerbaan, B. and D. Stebila, "X25519Kyber768Draft00
                hybrid post-quantum key agreement", Work in Progress,
                Internet-Draft, draft-tls-westerbaan-xyber768d00-03, 24
                September 2023, <https://datatracker.ietf.org/doc/html/
                draft-tls-westerbaan-xyber768d00-03>.

  Appendix A.  Change log

     *  draft-kwiatkowski-tls-ecdhe-mlkem-03:

        -  Adds P-384 combined with ML-KEM-1024

        -  Adds text that describes error-handling and outlines how the
           client and server must ensure the integrity of the key exchange
           process.

        -  Adds note on the incompatibility of the codepoint name
           X25519MLKEM768 with [hybrid].




  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 8]


  Internet-Draft                 ECDHE-MLKEM                 December 2024


        -  Various cosmetic changes.

     *  draft-kwiatkowski-tls-ecdhe-mlkem-02:

        -  Adds section that mentions supported groups that this document
           obsoletes.

        -  Fix a reference to encapsulation in the FIPS 203.

     *  draft-kwiatkowski-tls-ecdhe-mlkem-01:

        -  Add X25519MLKEM768

     *  draft-kwiatkowski-tls-ecdhe-mlkem-00:

        -  Change Kyber name to ML-KEM

        -  Swap reference to I-D.cfrg-schwabe-kyber with FIPS-203

        -  Change codepoint.  New value is equal to old value + 1.

     *  draft-kwiatkowski-tls-ecdhe-kyber-01: Fix size of key shares
        generated by the client and the server

     *  draft-kwiatkowski-tls-ecdhe-kyber-00: updates following IANA
        review

  Authors' Addresses

     Kris Kwiatkowski
     PQShield
     Email: kris@amongbytes.com


     Panos Kampanakis
     AWS
     Email: kpanos@amazon.com


     Bas Westerbaan
     Cloudflare
     Email: bas@cloudflare.com


     Douglas Stebila
     University of Waterloo
     Email: dstebila@waterloo.ca




  Kwiatkowski, et al.       Expires 28 June 2025                  [Page 9]


name: draft-ecdh-psi
rev: 00
title: PSI based on ECDH
time: 2024-10-21T10:26:11Z
group_uri: /api/v1/group/group/1027/
expires: 2025-04-24T10:26:11Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:05.741424+00:00
source: ietf
abstract:
  This document describes Elliptic Curve Diffie-Hellman Private Set
     Intersection (ECDH-PSI).  It instantiates the classical Meadows
     match-making protocol with standard elliptic curves and hash-to-curve
     methods.  In ECDH-PSI, data items are encoded to points on an
     elliptic curve, and masked by the private keys of both parties.
     After collecting the mutually masked datasets from both parties, a
     participant computes their intersection and outputs the corresponding
     original data items as result.

full_text:
  Security Dispatch                                                Y. Wang
  Internet-Draft                                                  W. Chang
  Intended status: Informational                                     Y. Lu
  Expires: 24 April 2025                                           C. Hong
                                                                   J. Peng
                                                                 Ant Group
                                                           21 October 2024


                             PSI based on ECDH
                             draft-ecdh-psi-00

  Abstract

     This document describes Elliptic Curve Diffie-Hellman Private Set
     Intersection (ECDH-PSI).  It instantiates the classical Meadows
     match-making protocol with standard elliptic curves and hash-to-curve
     methods.  In ECDH-PSI, data items are encoded to points on an
     elliptic curve, and masked by the private keys of both parties.
     After collecting the mutually masked datasets from both parties, a
     participant computes their intersection and outputs the corresponding
     original data items as result.

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



  Wang, et al.              Expires 24 April 2025                 [Page 1]


  Internet-Draft                  ECDH-PSI                    October 2024


     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.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
       1.2.  Data Structures and Notations . . . . . . . . . . . . . .   3
     2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Elliptic Curves . . . . . . . . . . . . . . . . . . . . .   3
       2.2.  Hashing to Elliptic Curves  . . . . . . . . . . . . . . .   4
     3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Handshake . . . . . . . . . . . . . . . . . . . . . . . .   9
         3.2.1.  HandshakeRequest  . . . . . . . . . . . . . . . . . .   9
         3.2.2.  HandshakeResponse . . . . . . . . . . . . . . . . . .  13
       3.3.  Data Exchange . . . . . . . . . . . . . . . . . . . . . .  15
         3.3.1.  EcdhPsiBatch  . . . . . . . . . . . . . . . . . . . .  15
         3.3.2.  EcdhPsiBatchResponse  . . . . . . . . . . . . . . . .  17
     4.  Implementation Considerations . . . . . . . . . . . . . . . .  18
       4.1.  The Representation of EC Point  . . . . . . . . . . . . .  18
       4.2.  The Management of Index . . . . . . . . . . . . . . . . .  18
       4.3.  Support More hash_to_curve Suites . . . . . . . . . . . .  19
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
       5.1.  Data Truncation . . . . . . . . . . . . . . . . . . . . .  20
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  22
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     Private Set Intersection (PSI) schemes enable the discovery of shared
     elements among different parties' datasets without revealing
     individual data.  They are widely used when there's a need to
     identify overlapping data elements between two or more parties while
     preserving the confidentiality of each party's original data.  PSI is
     one of the most frequently used privacy preserving techniques in
     business, e.g. it enables a user to detect whether his/her password
     is leaked without giving away the password to the server [MS21], or
     multiple companies to find their common customers without giving each
     other their raw data.





  Wang, et al.              Expires 24 April 2025                 [Page 2]


  Internet-Draft                  ECDH-PSI                    October 2024


     The classical Diffie-Hellman PSI [Meadows86] has been published for
     more than thirty years.  The academic has also proposed numerous PSI
     schemes with new functionalities and secure guarantees, such as
     [KKRT16][CHLR18][RR22], but DH-PSI is still preferable due to its
     simplicity and communication efficiency.  This document describes a
     widely deployed instance of DH-PSI denoted by Elliptic Curve Diffie-
     Hellman PSI (ECDH-PSI).  Compared with the finite field parameters
     used in the original version, elliptic curves are commonly considered
     to be more efficient and secure [IMC][LOGJAM], and are extensively
     adopted by recent standards including [RFC8031][RFC8446][RFC9497].

     In document describes 2-party ECDH-PSI as a two stage protocol,
     including a handshake phase and a data exchange phase.  In the
     handshake phase, the parties agree on the cipher suite and message
     flow to be used in data exchange phase.  Then, during the data
     exchange phase, original data elements are masked and transmitted in
     batches, allowing one or both parties to output the result.

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

  1.2.  Data Structures and Notations

     In this document, data structures are defined and encoded according
     to the conventions laid out in Section 3 of [RFC8446].

  2.  Background

     This section gives brief introductions for elliptic curves and hash-
     to-curve methods.

  2.1.  Elliptic Curves

     An elliptic curve E is defined by a two-variable equation over a
     finite field F with prime characteristic p larger than three.  Except
     for a special point called point at infinity, a point on E is a
     (x,y)-coordinate pair that satisfies the curve equation, where x and
     y are elements of F.  All distinct points of curve E consists an
     algebraic group of order n, where the point at infinity is the
     identity element.  Applications and standards generally use a prime
     order (sub)group <G> generated by a point G on E.  The order of <G>
     is denoted by r.




  Wang, et al.              Expires 24 April 2025                 [Page 3]


  Internet-Draft                  ECDH-PSI                    October 2024


     This document uses term "addition" to refer to the group operation of
     a elliptic curve group, meaning two points P and Q can be added
     together to get a third point R.  Scalar multiplication refers to the
     operation of adding a point P with itself repeatedly.  This document
     uses scalar_mul to denote the scalar multiplication process.  It
     takes a integer x<r and a point P as inputs and outputs the
     multiplication result Q, which is written by Q=scalar_mul(P,x).

     Many cryptographic applications require the participants to generate
     elliptic curve key pairs.  Usually, a key pair on refers to a (PK,sk)
     tuple, where sk is a integer generated uniformly between 1 and r-1,
     and PK=scalar_mul(G,sk).  In the context of ECDH-PSI, only sk, namely
     the private key, is used.  Thus, this document uses the notation
     sk=keygen() to refer to the process of generating a private key on
     the elliptic curve and omits PK.

  2.2.  Hashing to Elliptic Curves

     A hash_to_curve function encodes data of arbitrary length to a point
     on a elliptic curve.  The encoding process first hashes the byte
     string to one or more elements of fixed length, and then calculates a
     point on the curve with the elements using so-called map_to_curve and
     clear_cofactor functions.

     [RFC9380] describes a series of hash_to_curve methods (which are also
     called "suites") for standard curves such as NIST P-256 and
     curve25519.  It specifies two encoding types denoted by
     "encode_to_curve" and "hash_to_curve".  Both encodings can be proven
     indifferentiable from random oracles (ROs)[MRH04], but have different
     output distributions.  This document only uses "hash_to_curve"
     encodings which output uniformly random points.  It also uses the
     notation P=hash_to_curve(data) to refer to the process of encoding
     data of arbitrary length to a point P on the curve given in the
     context.

















  Wang, et al.              Expires 24 April 2025                 [Page 4]


  Internet-Draft                  ECDH-PSI                    October 2024


     [RFC9380] requires all uses of the hash_to_curve suites must enforce
     domain separation with domain separation tags (DSTs).  In particular,
     DSTs are distinct strings that enable different applications to
     simulate distinct RO instances with the same hash function.  That is,
     each application concatenates the DST with its message as the input
     to hash function.  This document allocates each suit with a unique
     DST.  For simplicity, DST strings are omitted when writing the
     process of calculating the hash value of a string.  The notation
     tag=hash(str) means that the hash function actually takes "dst||str"
     as its input rather than str alone, where dst is the DST string
     defined for the corresponding hash_to_curve suite.  Similarly, this
     document also omits DST strings when describing hash_to_curve
     functions, assuming that the corresponding DST has been taken as a
     part of the input.

     A suite defined by [RFC9380] includes a series of parameters such as
     the curve, hash function, and encoding type.  In applications, these
     suites are very efficient to be referred to, as the included
     parameters can also be used beyond the scenario of mapping data to
     curves.  For example, the participants can negotiate a hash_to_curve
     suite, and then use the curve deduced from the suite for other
     cryptographic functions such as encryption and key establishment.

     To extend the usage of hash_to_curve suites, [RFC9380] also describes
     methods and naming conventions for defining new suites, which enables
     developers to define suites with new curves and hash functions.

  3.  Protocol

     We begin with a very brief description on how ECDH-PSI works.
     Firstly, the participants, A and B, agree on a EC group <G> along
     with the hash_to_curve suites, and generate private keys over <G>.
     Then, both A and B convert their data to points over <G> and multiply
     the points with both parties' private keys.  Next, they exchange the
     sets of masked elements as sets of EC points, and compute the
     intersection over these sets.  Finally, they output the original data
     items corresponding to the intersection of masked sets.

     Assume that the parties have agreed on the suite, and generated
     private keys of sk_A and sk_B, an simplified protocol flow of ECDH-
     PSI is shown by Figure 1, and explained step-by-step as follows:

     1.  A participant maps its data items to EC points with
         hash_to_curve, and masks the points locally with its own private
         key by scalar_mul.

     2.  A and B exchange their locally masked elements.




  Wang, et al.              Expires 24 April 2025                 [Page 5]


  Internet-Draft                  ECDH-PSI                    October 2024


     3.  Upon receiving the masked data from its partner, a participant
         doubly masks the received points with its private key.

     4.  A participant sends the doubly-masked elements back to its
         partner.

     5.  The participant calculates intersection of the set calculated in
         Step 3 and the set received in Step 4, and finally outputs the
         corresponding original elements.

     In order to clarify the statement, this document uses "the first
     round" to refer to the data exchange process of Step 2, and "the
     second round" for the process of Step 4.

     The classical description of ECDH-PSI enables both parties to output
     PSI results and thus requires two complete rounds (i.e.  Step 2 and
     Step 4) to exchange masked data.  However, many application scenarios
     require that should only one participant output the intersection and
     the other one get nothing.  In such scenarios, Step 4 and Step 5 are
     executed unidirectionally, where only one party sends doubly-masked
     data in Step 4 and only the receiver of that message can output the
     result.

     To output PSI result, the participants should also match the original
     data items with their corresponding EC points.  In particular, the
     relationship can be established with unique indexes, where the
     original data item and the masked EC point(s) are linked to the same
     index.























  Wang, et al.              Expires 24 April 2025                 [Page 6]


  Internet-Draft                  ECDH-PSI                    October 2024


                 A(data_A,sk_A)                  B(data_B,sk_B)
   -----------------------------------------------------------------------
   Step 1:             |                               |
                       |                               |
               p_A=scalar_mul(sk_A,            p_B=scalar_mul(sk_B,
               hash_to_curve(data_A))          hash_to_curve(data_B))
                       |                               |
   Step 2:             |                               |
                       |                               |
                       |-------------p_A-------------->|
                       |<------------p_B---------------|
                       |                               |
   Step 3:             |                               |
                       |                               |
          p_AB=scalar_mul(sk_A,p_B)     p_BA = scalar_mul(sk_B,p_A)
                       |                               |
                       |                               |
                       |                               |
   Step 4:             |                               |
                       |                               |
                       |-------------p_AB------------->|
                       |<------------p_BA--------------|
                       |                               |
   Step 5:             |                               |
                       |                               |
            set_A=intersect(p_AB,p_BA)      set_B=intersect(p_BA,p_AB)
                       |                               |
                       |                               |
            output match(set_A,data_A)      output match(set_B,data_B)

              Figure 1: A Simplified Protocol Flow of ECDH-PSI

  3.1.  Overview

     The specification of ECDH-PSI consists of two phases as shown in
     Figure 2, including a handshake phase which negotiates the protocol
     parameters and a data exchange phase that performs the operations
     described by Figure 1.

     * In the handshake phase, a participant, which is denoted by
        requester, sends a HandshakeRequest message to initiate the ECDH-
        PSI protocol flow.  This message carries lists of parameters
        supported by the requester and information about the requester's
        data.  Then, the other participant, denoted by responder, selects
        parameters from the requester's lists, and sends the parameters
        with its data information in a HandshakeResponse message.





  Wang, et al.              Expires 24 April 2025                 [Page 7]


  Internet-Draft                  ECDH-PSI                    October 2024


     * Next, in the data exchange phase, both parties perform ECDH-PSI
        operations with parameters selected in the handshake phase, where
        EcdhPsiBatch messages are exchanged.  The receiver of an
        EcdhPsiBatch replies with a EcdhPsiBatchResponse message, which
        tells sender the handling status of last EcdhPsiBatch message.

     This specification enables masked data to be transferred by many
     batches, as the entire data set may be extremely large and requires
     numerous resources to be handled with properly.  For example, the
     size of a data set may exceed the limit of a single package of the
     underlying network protocol.  The participants can divide the data
     set to multiple batches and use multiple EcdhPsiBatch messages to
     send them so as to meet the limits of network, storage or computation
     resources.

     Besides hash_to_curve suites and data formats, the handshake phase
     also determines the interaction pattern for data exchange phase.  The
     pattern is decided by the following options:

     * The participant that outputs the result.  If only one participant
        (for example, A) has the privilege of obtaining the result, then,
        in the second round, EcdhPsiBatch messages will be only sent from
        B to A.

     * The maximum size of a single EcdhPsiBatch message.  Upon the
        determination of maximum batch size, the participants can deduce
        the number of batch messages sent or received in each round by
        dividing the size of entire data set with the maximum size.

     * The order of sending EcdhPsiBatch messages.  When both participants
        need to send batch messages in the same round, the requester will
        always send the first one.  Then, they can send EcdhPsiBatch
        messages in turn, or let the requester send all batches in
        sequence before the responder sending its data.

















  Wang, et al.              Expires 24 April 2025                 [Page 8]


  Internet-Draft                  ECDH-PSI                    October 2024


                     A                                     B
   -----------------------------------------------------------------------
                     |                                     |
   Handshake Phase:  |                                     |
                     |----------HandshakeRequest---------->|
                     |<---------HandshakeResponse----------|
                     |                                     |
   Data Exchange     |
   Phase:            |                                     |
                     |                                     |
                     |-------------EcdhPsiBatch----------->|
                     |<--------EcdhPsiBatchResponse--------|
                     |                   .                 |
                     |                   .                 |
                     |                   .                 |
                     |-------------EcdhPsiBatch----------->|
                     |<--------EcdhPsiBatchResponse--------|
                     |                   .                 |
                     |                   .                 |
                     |                   .                 |

      Figure 2: An Overview of the Two-Phase Specification of ECDH-PSI

  3.2.  Handshake

     The handshake phase includes a HandshakeRequest and a
     HandshakeResponse message.  The structures of these messages are
     documented as follows.

  3.2.1.  HandshakeRequest

     Structure of HandshakeRequest:

       struct {
         uint8 version = 1;
         ProtocolProposal protocol_param;
         DataProposal data_param;
       } HandshakeRequest;

     version: The version of ECDH-PSI protocol.

     protocol_param: ECDH-PSI protocol configurations supported by the
     requester.

     data_param: The requester's data information, including its data set
     size and proposals for data exchange pattern.





  Wang, et al.              Expires 24 April 2025                 [Page 9]


  Internet-Draft                  ECDH-PSI                    October 2024


  3.2.1.1.  Protocol Proposal

     The ProtocolProposal message describes ECDH-PSI protocol parameters
     supported by the requester.

     Structure of this message:

     enum {
       null (0),
       P256_XMD:SHA-256_SSWU_NU_ (1),
       P384_XMD:SHA-384_SSWU_NU_ (2),
       P521_XMD:SHA-512_SSWU_NU_ (3),
       curve25519_XMD:SHA-512_ELL2_NU_ (4),
       (255)
     } HashToCurveSuite

     enum { compressed (0), uncompressed  (1), (255) } PointOctetFormat

     enum {
       no_truncation (0),
       128_bit_truncation (1),
       (255)
       } TruncationOption

     struct {
       HashToCurveSuite    suites<1..255>;
       PointOctetFormat    point_octet_formats<1..255>;
       TruncationOption    truncation_options<1..255>;
     } ProtocolProposal

     suites: The list of supported HashToCurveSuite in order of the
     requester's preference.  .

     Different suites use different DST strings as required by [RFC9380].
     In particular, ECDH-PSI uses "ECDH-PSI-V<xx>-<suites>" as its DST,
     where <xx> is a two-digit number indicating the current protocol
     version as specified by the version field of HandshakeRequest, and
     <suites> is the ASCII string representation of the currently adopted
     suite as defined by [RFC9380].  As an example, when both participants
     agree to use the suite for P256 curve, the corresponding DST is
     "ECDH-PSI-V01-P256_XMD:SHA-256_SSWU_NU_".

     point_octet_formats: The list of octet string formats representing EC
     points, in the order of requester's preference.  This field enables
     the participants to weigh the tradeoffs between the costs of
     communication and computation as discussed by Section 4.1.





  Wang, et al.              Expires 24 April 2025                [Page 10]


  Internet-Draft                  ECDH-PSI                    October 2024


     * For the curves defined in [FIPS186-4], the PointOctetFormat values
        refer to the corresponding compressed/uncompressed formats
        documented by [ECDSA].

     * Points on Curve25519 are always encoded as the input and output of
        X25519 function defined by Section 5 of [RFC7748] as 32 byte
        strings.  Unlike the other curves, the scalar multiplication of
        curve25519 only relies on one 32-byte coordinate without the cost
        of decompressing to the (x,y)-coordinate representation, which
        eliminates the need of making a tradeoff.

     truncation_options: Whether the requester supports truncation for
     data transferred in the second round.  The options are listed in the
     requester's preference.  The truncation could decrease the costs of
     data transmission and storage, and even accelerate the computation
     process of intersection, at the expense of a (negligible) false-
     positive rate.

     In this document, only 128-bit truncation is allowed, with a
     restriction that the total number of data items owned by both
     participants SHOULD be no more than 2^40, ensuring that the
     probability of collision is smaller than 2^-48.  See Section 5.1 for
     a detailed discussion.  The requester MUST set this field by a single
     no_truncation option when its data set size has already been equal or
     larger than 2^40.

     The truncation process utilizes Key Derivation Functions (KDFs) as
     many key-exchange protocols that use shared secrets to derive shorter
     strings which can be seen as uniformly distributed cryptographic keys
     (e.g., [RFC8446][RFC9382]).  In this document, the KDFs are
     instantiated by Hashed Message Authentication Code (HMAC) [RFC2104],
     along with HMAC-based KDF (HKDF)[RFC5869], and the hash function
     included in hash_to_curve suite.

     Following [RFC5869], a KDF function kdf() takes a input keying
     material ikm, a salt value salt, an application specific information
     info and output length len as its inputs.  Let mask_data be the
     string representation of a doubly-masked element, a participant
     SHOULD truncate mask_data with:

     truncated_mask_data = kdf(mask_data, nil, "ECDH-PSI", 128)

     In particular, the KDF takes mask_data as the input keying material.
     It does not take a salt value, uses ASCII string "ECDH-PSI" as the
     application specification information, and outputs a 128-bit string
     as the truncation result.





  Wang, et al.              Expires 24 April 2025                [Page 11]


  Internet-Draft                  ECDH-PSI                    October 2024


  3.2.1.2.  Data Proposal

     The data_param field describes requester's data size and provides
     supported options on how to exchange EcdhPsiBatch messages.

     Structure of this message:

     enum { continuous (0), interactive (1), (255) } BatchMode

     enum { both (0), requester (1), responder (2), (255) } OutputMode

     struct{
       BatchMode  supported_batch_modes<1..255>;
       OutputMode supported_output_modes<1..255>;
       uint64     max_batch_size;
       uint64     item_num;
     } DataProposal

     supported_batch_modes: The list of interaction patterns supported by
     the requester in the order of preference.  BatchMode describes the
     message interaction pattern when both parties need to send their data
     sets with multiple EcdhPsiBatch messages in the same round.

     *  continuous: A participant sends its entire data set with
        continuous EcdhPsiBatch messages.

     *  interactive: The participants send EcdhPsiBatch messages in turn.
        If one party has sent all its batch messages before its partner,
        the partner SHOULD send its messages continuously.

     When both parties need to send data batches in the same round, the
     requester SHOULD always send the first EcdhPsiBatch message.

     supported_output_modes: The list of output modes supported by the
     requester in the order of its preference, where OutputMode describes
     which party has the privilege of obtaining the result.

     The meaning of OutputMode is explained as follows:

     *  both: Both parties output the intersection result, which means
        EcdhPsiBatch are sent mutually in the second round.

     *  requester: Only the requester outputs PSI result, which means only
        the responder sends message batches in the second round.

     *  responder: Only the responder outputs PSI result, which means only
        the requester sends message batches in the second round.




  Wang, et al.              Expires 24 April 2025                [Page 12]


  Internet-Draft                  ECDH-PSI                    October 2024


     max_batch_size: The maximum byte size of a single EcdhPsiBatch
     message allowed by the requester.  That is, the requester will not
     send a batch message beyond this limit, and it cannot receive a batch
     message having larger size.  The requester SHOULD decide the value of
     this field comprehensively according to its hardware/software
     configuration and environment.

     item_num: The total number of requester's data items.

  3.2.2.  HandshakeResponse

     The responder sends HandshakeResponse to reply to a HandshakeRequest
     message.  It includes selected parameters and the responder's data
     information.

     Structure of this message:

     enum {
       success(0),
       generic_error         (0x01),
       unsupported_version   (0x02)
       invalid_request       (0x03),
       out_of_resource       (0x04),
       unsupported_parameter (0x05),
       (0xFF)
     } HandshakeStatus

     struct {
       HandshakeStatus status;
       ProtocolResult protocol_param;
       DataResult data_param;
     } HandshakeResponse;

     status: Indicating the status of handshake.  The meanings of error
     statuses are listed as follows:

     *  generic_error: The error cannot be categorized to the rest error
        statuses defined by HandshakeStatus.

     *  unsupported_version: The responder does not support the ECDH-PSI
        protocol version given by version.

     *  invalid_request: The responder cannot parse the request correctly.
        The message may be in wrong format and cannot be parsed as a
        normal HandshakeRequest message.






  Wang, et al.              Expires 24 April 2025                [Page 13]


  Internet-Draft                  ECDH-PSI                    October 2024


     *  out_of_resource: The responder does not have enough resource to
        handle the ECDH-PSI process following to the options provided by
        the requester.

     *  unsupported_parameter: The responder rejects all options proposed
        by one of the suggested option lists included in HandshakeRequest.

     The responder MUST ignore all options or parameters that it cannot
     recognize when parsing the HandshakeRequest message.  If one of the
     suggested option lists is filled with unrecognized parameters, it
     SHOULD reply with a HandshakeResponse carrying unsupported_parameter.

     Upon receiving a HandshakeResponse message without success status,
     the requester MUST ignore the other fields included in this message.

     protocol_param: The protocol parameter selected by the responder,
     including the hash_to_curve suite, EC point string format and
     truncation option.

     data_param: This message includes the data exchange pattern selected
     by the responder and the size of responder's dataset.

  3.2.2.1.  Protocol Result

     The structure of ProtocolResult is defined as follows:

     struct {
       HashToCurveSuite    suite;
       PointOctetFormat    point_octet_format;
       TruncationOption    truncation_option;
     } ProtocolResult;

     suite: The hash_to_curve suite selected by the responder.

     point_octet_format: The format of EC point octet string chosen by the
     responder.

     truncation_option: The truncation option selected by the responder.
     When deciding the field, the responder SHOULD consider the sum of
     both participants' dataset sizes.  If the sum is larger than 2^40,
     truncation MUST no be used, which means the responder MUST set this
     field by no_truncation.

  3.2.2.2.  Data Result

     The structure of DataInfoResult is defined as follows:





  Wang, et al.              Expires 24 April 2025                [Page 14]


  Internet-Draft                  ECDH-PSI                    October 2024


     struct  {
       BatchMode   batch_mode;
       OutputMode  output_mode;
       uint64      max_batch_size;
       uint64      item_num;
     } DataInfoResult;

     batch_mode: The BatchMode selected by responder.

     output_mode: The OutputMode selected by responder.

     max_batch_size: The maximum size of a EcdhPsiBatch message, which
     SHOULD NOT be larger than the max_batch_size given by the requester.

     item_num: The size of responder's dataset.

  3.3.  Data Exchange

     The data exchange phase consists of two rounds.  In each round, a
     participant may send or receive multiple EcdhPsiBatch messages.  Upon
     receiving a EcdhPsiBatch and handling the data properly, the
     participant SHOULD respond with a EcdhPsiBatchResponse message,
     indicating its partner that it is ready to receive the next
     EcdhPsiBatch message.

  3.3.1.  EcdhPsiBatch

     The structure of EcdhPsiBatch is defined as follows:

     enum { transmit(0), retransmit(1), fatal_error(2), (255)} BatchStatus

     struct {
       uint64 index;
       opaque octet;
     } ECPointOctet;

     struct {
       BatchStatus   status;
       uint32        batch_type;
       uint64        batch_index;
       uint64        batch_count;
       uint32        is_last_batch;
       ECPointOctet  data<1..2^64-1>;
     } EcdhPsiBatch;

     status: Status of current batch message.  Values of this field are
     explained as follows:




  Wang, et al.              Expires 24 April 2025                [Page 15]


  Internet-Draft                  ECDH-PSI                    October 2024


     *  transmit: It is a normal batch message which has not been
        transmitted before.

     *  retransmit: This message has been transmitted, but it is re-
        transmitted due to the receiver's request.  A batch message may be
        retransmitted several times before it is properly handled by the
        receiver.  For example, the receiver may need a relative long time
        to prepare the storage resource, and require the sender to re-send
        the batch until it has enough space.

     *  fatal_error: The sender of this batch message cannot continue the
        ECDH-PSI protocol procedure due to some fatal errors.  The
        receiver MUST ignore the other fields included in the current
        EcdhPsiBatch message and terminate the PSI process.

        Such fatal error may occur in the handshake phase or data exchange
        phase.  For example, if the responder sends a HandshakeRespond
        message with parameters unsupported by the requester, the
        requester should construct and send a EcdhPsiBatch message
        carrying fatal_error status so as to terminate the process.

     batch_type: This field indicates the mask status of current batch.
     That is, value "1" stands for that the data included in the current
     batch are only masked by the owner's private key, and "2" means the
     data has been doubly-masked with both participants' private keys.

     batch_index: The index of current EcdhPsiBatch message, which is an
     incremental counter starting with "1".  The participant SHOULD use
     independent counters for different rounds and protocol runs.  For
     example, if participant A needs to send dataset p_A in the first
     round by 10 batches, and sends p_AB in the second round by 5 batches,
     it should use batch_index from 1 to 10 for the first round, and 1 to
     5 for the second.

     batch_count: Number of EC points included in the current EcdhPsiBatch
     message.

     is_last_batch: Indicating whether this batch is the last one, where
     "1" means the batch is the last one from the sender in current round,
     and "0" for there exists subsequent batches.

     data: This field carries multiple EC points with ECPointOctet, which
     number is specified by the batch_count field.  Each ECPointOctet
     structure includes an unique index allocated by the owner of the
     corresponding original data, and the encoded octet string.






  Wang, et al.              Expires 24 April 2025                [Page 16]


  Internet-Draft                  ECDH-PSI                    October 2024


     The purpose of index is to associate the original data item with the
     (doubly)-masked EC points, such that the participant can match its
     dataset with the intersection of masked datasets.  The values of
     index are generated by the owner of data so as to identify each data
     item uniquely.  When masking the data from its partner, a participant
     MUST reserve the index for every record.  Section 4.2 gives more
     discussions on the implementation and maintenance of such indexes.

     The content of each octet string is determined by the selected
     hash_to_curve suite, octet format and truncation option.  In the
     first round, the receiver SHOULD decode the octet strings with the
     configurations negotiated in the handshake phase in order to mask the
     data provided by the sender.  However, in the second round where
     masking is not required, the receiver SHOULD treat the contents as
     octet strings rather than decode them to EC points, as such strings
     are enough for computing the intersection.

  3.3.2.  EcdhPsiBatchResponse

     The structure of EcdhPsiBatchResponse is defined as follows:

     enum {
       success (0),
       retransmit (1),
       fatal_error (2),
       (255)
     } BatchResponseStatus;

     struct {
       BatchResponseStatus status;
       uint64 batch_index;
     } EcdhPsiBatchResponse;

     status: Indicating whether the EcdhPsiBatch message identified by
     batch_index has been handled properly.  Values of this field are
     explained as follows:

     *  success: The EcdhPsiBatch message has been handled in a proper
        way.  Upon receiving a response with this status, the sender of
        EcdhPsiBatch can send the subsequence batch or prepare to receive
        the EcdhPsiBatch message from its partner.

     *  retransmit: Upon receiving retransmit, the participant MUST re-
        send the EcdhPsiBatch message identified by batch_index.

     *  fatal_error: The ECDH-PSI process meets some fatal error such that
        both the participants MUST terminate the current session, and
        discard all data received.



  Wang, et al.              Expires 24 April 2025                [Page 17]


  Internet-Draft                  ECDH-PSI                    October 2024


  4.  Implementation Considerations

  4.1.  The Representation of EC Point

     When deciding the point encoding format for the elliptic curves
     expect curve25519, the participants should consider the aspects of
     bandwidth, storage and computation comprehensively.  Compressed point
     format could decrease the costs of transmission and storage, but it
     also needs more computation resources to "decompress" the point.  The
     "decompress" process may be as costly as scalar multiplication
     [CZZDL24].  Uncompressed format requires more storage spaces and
     needs more time to transmit, but the participant can perform scalar
     multiplications without extra effort to recover the points.

     For example, when both parties are deployed in the same data center
     and linked with a high-bandwidth local area network (LAN), they can
     choose to use the uncompressed format to achieve better performance.

     As another example, the parties may be deployed in geographically
     separated data centers connected with low bandwidth wide area network
     (WAN), and equipped with high-end computation acceleration devices
     such as Graphics Processing Units (GPUs).  In this case, the
     computation resource may not be the bottleneck, and the participants
     can choose the compress format to minimize the costs of data
     transmission.

  4.2.  The Management of Index

     A RECOMMENDED method of maintaining indexes is storing the records
     with a database table and use the row numbers or prime keys as
     indexes.  The intersection result can be matched with original data
     items by a simple join operation.  The participant could also design
     a different indexing mechanism on its own, as long as guaranteeing
     its uniqueness.

     This document uses explicit indexes to identify data items rather
     than treats the order of records as "implicit" indexes.  Compare with
     the implicit counterpart, explicit indexes can be efficiently created
     and maintained by modern databases, and do not require the
     participants to implement extra logic to preserve the order of
     records.










  Wang, et al.              Expires 24 April 2025                [Page 18]


  Internet-Draft                  ECDH-PSI                    October 2024


     When masking the EC points from its partner, a participant MUST send
     the doubly-masked data with correct indexes.  To achieve this, it
     keeps the indexes of each data items received in the first round,
     masks the records with its private key, and associates the masked
     records with the same indexes.  These operations can also be
     implemented easily with database operations by viewing the received
     records and masked records as columns in the same table, which
     enables them to be linked naturally via the primary key.

  4.3.  Support More hash_to_curve Suites

     Participants can negotiate hash_to_curve suites besides the ones
     listed by Section 3.2.1.1.  They can use other suites defined by
     [RFC9380], or use a self-defined suite following the syntax and
     convention given by Section 8.9 and 8.10 of [RFC9380].

     As an example, this document next defines a hash_to_curve suite for
     the ShangMi(SM) curve and cryptography algorithms.  The SM algorithms
     are becoming mandatory in China, and have been accepted by
     international standards such as [ISO-SM2], [ISO-SM3] and [RFC8998].

     The new suite, denoted by curveSM2_XMD:SM3_SSWU_RO, encodes data to
     points on the so-called curveSM2[GBT.32918.5-2017] with SM3 hash
     algorithm[GBT.32905-2016], and reuses the expand_message_xmd and
     Simplified Shallue-van de Woestijne-Ulas (SSWU) methods for message
     expansion and mapping.

     In particular, curveSM2_XMD:SM3_SSWU_RO_ is defined as follows:

     *  encoding type: hash_to_curve

     *  E: y^2 = x^3 + A * x + B, where

        -  A = -3

        -  B = 0x28e9fa9e9d9f5e344d5a9e4bcf6509a7f39789f515ab8f92ddbcbd414
           d940e93

     *  p: 2^256-2^224-2^96+2^64-1

     *  m: 1

     *  k: 128

     *  expand_message: expand_message_xmd (Section 5.3.1 of [RFC9380])

     *  H: SM3




  Wang, et al.              Expires 24 April 2025                [Page 19]


  Internet-Draft                  ECDH-PSI                    October 2024


     *  L: 48

     *  f: SSWU method (Section 6.6.2 of of [RFC9380])

     *  Z: -9

     *  h_eff: 1

     The value Z is calculated by the sage script given by Appendix H.2 of
     [RFC9380] with the p, A and B parameters of curveSM2.

     The participants SHOULD agree on the meaning of HashToCurveSuite
     values.  In this document, suite curveSM2_XMD:SM3_SSWU_RO_ is
     identified as follows:

     enum {
       null                              (0),
       ... // (1) to (4) follow section 3.2.1.1
       curveSM2_XMD:SM3_SSWU_RO_         (5),
       ... // other hash_to_curve suites
       (255)
     } HashToCurveSuite;

  5.  Security Considerations

  5.1.  Data Truncation

     This section provides a detailed discussion on the truncation
     mechanism presented in this document.

     The truncation, undoubtedly, will raise the probability of message
     collision.  That is, two different data item may be mapped to the
     same string after the procedures of masking and truncation by
     coincidence.  The collision may happen across the datasets owned by
     different participants, which causes a false-positive case that two
     different records are matched by PSI, or happen in the same dataset.
     The later situation may also lead to a false-positive case.  To be
     more specific, consider a participant A has two different data items
     data_X and data_Y which are mapped to the same record mask_data_XY.
     Its partner, say B, also has record data_X which is mapped to
     mask_data_XY.  Finally, A outputs both data_X and data_Y as the
     result of PSI, as it cannot distinguish which one matches the record
     of mask_data_XY.








  Wang, et al.              Expires 24 April 2025                [Page 20]


  Internet-Draft                  ECDH-PSI                    October 2024


     To avoid such false-positive case, we have to consider the collision
     probability with respect to the sum number of data items owned by A
     and B.  Such probability can be computed with the well-known birthday
     paradox bound.  Let n be the number of sampling and d be the output
     space, the probability of collision can be approximately computed
     with:

     p(n,d)=1-e^(-n(n-1)/2d)

     This document uses a truncated length of 128 bit, which means
     d=2^128.  For different n, which is the sum size of records, the
     probability are calculated as follows:

     *  If n=2^50, p(2^50, 2^128) = 2^-29

     *  If n=2^45, p(2^45, 2^128) = 2^-33

     *  If n=2^41, p(2^41, 2^128) = 2^-47

     *  If n=2^40, p(2^40, 2^128) = 2^-49

     *  If n=2^39, p(2^39, 2^128) = 2^-51

     That is, if the number of records is less than 2^40, the probability
     of false-positive will be smaller than 2^-48.  The participant can
     also decide the truncation option by calculating the collision
     probability, and only use truncation when they both agree that the
     probability is acceptable.

  6.  IANA Considerations

     This document has no IANA actions.

  7.  References

  7.1.  Normative References

     [ECDSA]    American National Standards Institute, "Public Key
                Cryptography for the Financial Services Industry: The
                Elliptic Curve Digital Signature Algorithm (ECDSA)",
                ANSI ANS X9.62-2005, November 2005.

     [FIPS186-4]
                National Institute of Standards and Technology (NIST),
                "Digital Signature Standard (DSS)", FIPS 186-4,
                DOI 10.6028/NIST.FIPS.186-4, July 2013,
                <https://nvlpubs.nist.gov/nistpubs/FIPS/
                NIST.FIPS.186-4.pdf>.



  Wang, et al.              Expires 24 April 2025                [Page 21]


  Internet-Draft                  ECDH-PSI                    October 2024


     [GBT.32905-2016]
                Standardization Administration of China, "Information
                security technology --- SM3 cryptographic hash algorithm",
                GB/T 32905-2016, March 2017, <http://www.gmbz.org.cn/
                upload/2018-07-24/1532401392982079739.pdf>.

     [GBT.32918.5-2017]
                Standardization Administration of the People's Republic of
                China, "Information security technology --- Public key
                cryptographic algorithm SM2 based on elliptic curves ---
                Part 5: Parameter definition", GB/T 32918.5-2017, December
                2017, <http://www.gmbz.org.cn/
                upload/2018-07-24/1532401863206085511.pdf>.

     [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
                Hashing for Message Authentication", RFC 2104,
                DOI 10.17487/RFC2104, February 1997,
                <https://www.rfc-editor.org/info/rfc2104>.

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

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

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

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

     [RFC9380]  Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,
                and C. A. Wood, "Hashing to Elliptic Curves", August 2023.

  7.2.  Informative References

     [CHLR18]   Chen, H., Huang, Z., Laine, K., and P. Rindal, "Labeled
                PSI from Fully Homomorphic Encryption with Malicious
                Security", Proceedings of the 2018 {ACM} {SIGSAC}
                Conference on Computer and Communications Security, {CCS}
                2018, Toronto, ON, Canada, October 15-19, 2018, October
                2018, <https://doi.org/10.1145/3243734.3243836>.



  Wang, et al.              Expires 24 April 2025                [Page 22]


  Internet-Draft                  ECDH-PSI                    October 2024


     [CZZDL24]  Chen, Y., Zhang, M., Zhang, C., Dong, M., and W. Liu,
                "Private Set Operations from Multi-query Reverse Private
                Membership Test", Public-Key Cryptography - {PKC} 2024 -
                27th {IACR} International Conference on Practice and
                Theory of Public-Key Cryptography, 2024, Proceedings, Part
                {III}, April 2024,
                <https://doi.org/10.1007/978-3-031-57725-3_13>.

     [IMC]      Katz, J. and Y. Lindell, "Introduction to Modern
                Cryptography, Third Edition".

     [ISO-SM2]  International Organization for Standardization, "IT
                Security techniques -- Digital signatures with appendix --
                Part 3: Discrete logarithm based mechanisms", ISO/
                IEC 14888-3:2018, November 2018,
                <https://www.iso.org/standard/76382.html>.

     [ISO-SM3]  International Organization for Standardization, "IT
                Security techniques -- Hash-functions -- Part 3: Dedicated
                hash-functions", ISO/IEC 10118-3:2018, October 2018,
                <https://www.iso.org/standard/67116.html>.

     [KKRT16]   Kolesnikov, V., Kumaresan, R., Rosulek, M., and N. Trieu,
                "Efficient Batched Oblivious {PRF} with Applications to
                Private Set Intersection", Proceedings of the 2016 {ACM}
                {SIGSAC} Conference on Computer and Communications
                Security, Vienna, Austria, October 24-28, 2016, October
                2016, <https://doi.org/10.1145/2976749.2978381>.

     [LOGJAM]   Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
                Green, M., Halderman, J. A., Heninger, N., Springall, D.,
                Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E.,
                Zanella-Béguelin, S., and P. Zimmermann, "Imperfect
                Forward Secrecy: How Diffie-Hellman Fails in Practice",
                Proceedings of the 22nd {ACM} {SIGSAC} Conference on
                Computer and Communications Security, Denver, CO, USA,
                October 12-16, 2015, October 2015,
                <https://doi.org/10.1145/2810103.2813707>.

     [Meadows86]
                Meadows, C., "A More Efficient Cryptographic Matchmaking
                Protocol for Use in the Absence of a Continuously
                Available Third Party", 1986 IEEE Symposium on Security
                and Privacy, <https://doi.org/10.1109/SP.1986.10022>.

     [MRH04]    Maurer, U., Renner, R., and C. Holenstein,
                "Indifferentiability, Impossibility Results on Reductions,
                and Applications to the Random Oracle Methodology", In TCC



  Wang, et al.              Expires 24 April 2025                [Page 23]


  Internet-Draft                  ECDH-PSI                    October 2024


                2004: Theory of Cryptography, pages 21-39,
                DOI 10.1007/978-3-540-24638-1_2, February 2004,
                <https://doi.org/10.1007/978-3-540-24638-1_2>.

     [MS21]     Lauter, K., Kannepalli, S., Laine, K., and R. C. Moreno,
                "Password Monitor: Safeguarding passwords in Microsoft
                Edge", <https://www.microsoft.com/en-us/research/blog/
                password-monitor-safeguarding-passwords-in-microsoft-
                edge/>.

     [RFC8031]  Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
                Internet Key Exchange Protocol Version 2 (IKEv2) Key
                Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
                <https://www.rfc-editor.org/info/rfc8031>.

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

     [RFC8998]  Yang, P., "ShangMi (SM) Cipher Suites for TLS 1.3",
                RFC 8998, DOI 10.17487/RFC8998, March 2021,
                <https://www.rfc-editor.org/info/rfc8998>.

     [RFC9382]  Ladd, W., "SPAKE2, a Password-Authenticated Key Exchange",
                RFC 9382, DOI 10.17487/RFC9382, September 2023,
                <https://www.rfc-editor.org/info/rfc9382>.

     [RFC9497]  Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
                Wood, "Oblivious Pseudorandom Functions (OPRFs) Using
                Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497,
                December 2023, <https://www.rfc-editor.org/info/rfc9497>.

     [RR22]     Raghuraman, S. and P. Rindal, "Blazing Fast PSI from
                Improved OKVS and Subfield VOLE", Proceedings of the 2022
                {ACM} {SIGSAC} Conference on Computer and Communications
                Security, {CCS} 2022, Los Angeles, CA, USA, November 7-11,
                2022, November 2022,
                <https://doi.org/10.1145/3548606.3560658>.

  Authors' Addresses

     Yuchen Wang
     Ant Group
     Email: tianwu.wyc@antgroup.com







  Wang, et al.              Expires 24 April 2025                [Page 24]


  Internet-Draft                  ECDH-PSI                    October 2024


     Wenting Chang
     Ant Group
     Postfach 330440
     Beijing
     Phone: +49-421-218-63921
     Email: bainuan.cwt@antgroup.com


     Yufei Lu
     Ant Group
     Email: yuwen.lyf@antgroup.com


     Cheng Hong
     Ant Group
     Email: vince.hc@alibaba-inc.com


     Jin Peng
     Ant Group
     Email: jim.pj@antgroup.com






























  Wang, et al.              Expires 24 April 2025                [Page 25]


