# drafts

name: draft-lenders-core-dnr
rev: 06
title: Discovery of Network-designated OSCORE-based Resolvers: Problem Statement
time: 2026-01-09T07:09:20Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T13:29:04Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014778+00:00
abstract:
This document states problems when designing DNS SVCB records to
   discover endpoints that communicate over Object Security for
   Constrained RESTful Environments (OSCORE) [RFC8613].  As a
   consequence of learning about OSCORE, this discovery will allow a
   host to learn both CoAP servers and DNS over CoAP resolvers that use
   OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE
   (EDHOC) [RFC9528] for key exchange.  Challenges arise because SVCB
   records are not meant to be used to exchange security contexts, which
   is required in OSCORE scenarios.

full_text:
Constrained RESTful Environments                           M. S. Lenders
Internet-Draft                                                TU Dresden
Intended status: Informational                                 C. Amsüss
Expires: 8 January 2026                                                 
                                                           T. C. Schmidt
                                                             HAW Hamburg
                                                             M. Wählisch
                                        TU Dresden & Barkhausen Institut
                                                             7 July 2025


    Discovery of Network-designated OSCORE-based Resolvers: Problem
                               Statement
                       draft-lenders-core-dnr-06

Abstract

   This document states problems when designing DNS SVCB records to
   discover endpoints that communicate over Object Security for
   Constrained RESTful Environments (OSCORE) [RFC8613].  As a
   consequence of learning about OSCORE, this discovery will allow a
   host to learn both CoAP servers and DNS over CoAP resolvers that use
   OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE
   (EDHOC) [RFC9528] for key exchange.  Challenges arise because SVCB
   records are not meant to be used to exchange security contexts, which
   is required in OSCORE scenarios.

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://netd-
   tud.github.io/draft-lenders-core-oscore-svcb/draft-lenders-core-
   dnr.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-lenders-core-dnr/.

   Discussion of this document takes place on the Constrained RESTful
   Environments Working Group mailing list (mailto:core@ietf.org), which
   is archived at https://mailarchive.ietf.org/arch/browse/core/.
   Subscribe at https://www.ietf.org/mailman/listinfo/core/.

   Source for this draft and an issue tracker can be found at
   https://github.com/netd-tud/draft-lenders-core-oscore-svcb.

Status of This Memo

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



Lenders, et al.          Expires 8 January 2026                 [Page 1]

Internet-Draft                  CoRE DNR                       July 2025


   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 8 January 2026.

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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Problem Space . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.1.  Neighbor discovered server with EDHOC credential  . .   6
       4.1.2.  DHCP discovered server with ACE details . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  10
     A.1.  Since draft-lenders-core-dnr-05 . . . . . . . . . . . . .  10
     A.2.  Since draft-lenders-core-dnr-04 . . . . . . . . . . . . .  10
     A.3.  Since draft-lenders-core-dnr-03 . . . . . . . . . . . . .  10
     A.4.  Since draft-lenders-core-dnr-02 . . . . . . . . . . . . .  11
     A.5.  Since draft-lenders-core-dnr-01 . . . . . . . . . . . . .  11
     A.6.  Since draft-lenders-core-dnr-00 . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11



Lenders, et al.          Expires 8 January 2026                 [Page 2]

Internet-Draft                  CoRE DNR                       July 2025


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The discovery of Internet services can be facilitated by the Domain
   Name System (DNS).  To discover services of the constrained Internet
   of Things (IoT) using the DNS, two challenges must be solved.  First,
   the discovery of a DNS resolver that supports DNS resolution based on
   secure, IoT-friendly protocols—otherwise the subsequent discovery of
   IoT-tailored services would be limited to resolution protocols
   conflicting with constrained resources.  Second, the discovery of an
   IoT-friendly service beyond the DNS resolution.

   [RFC9460] specifies the "SVCB" ("Service Binding") DNS resource
   record to lookup information needed to connect to a network service.
   Service Parameters (SvcParams) carry that information within the SVCB
   record.

   The discovery of recursive DNS resolvers can be enabled by the DNS
   itself [RFC9461], [RFC9462] or, in a local network, by Router
   Advertisements and DHCP [RFC9463].  In all theses cases, the
   SvcParams is used, but supports only DNS transfer based on Transport
   Layer Security (TLS), namely DNS over TLS (DoT) [RFC7858], DNS over
   HTTPS (DoH) [RFC8484], and DNS over Dedicated QUIC (DoQ) [RFC9250].
   The use of DoT, DoH, or DoQ, however, is not recommended in IoT
   scenarios.

   DNS over CoAP [I-D.ietf-core-dns-over-coap] provides a solution for
   encrypted DNS in constrained environments.  The Constrained
   Application Protocol (CoAP) [RFC7252] is mostly agnostic to the
   transport layer CoAP can be transported over UDP, TCP, or WebSockets
   [RFC8323], and even less common transports such as Bluetooth GATT
   [I-D.amsuess-core-coap-over-gatt] or SMS [lwm2m] are discussed.
   [I-D.ietf-core-transport-indication] covers the selection of
   different CoAP transports using SVCB records.

   CoAP offers three ways of secure communication:

   *  *No Security:* This plain CoAP mode does not support any
      encryption (NoSec in Section 9 of [RFC7252]).  It is not
      recommended when using [I-D.ietf-core-dns-over-coap] but inherits
      core CoAP features such as block-wise transfer [RFC7959] for
      datagram-based segmentation.  Such features are beneficial in
      constrained settings even without encryption.

   *  *Transport Security:* CoAP may use DTLS when transferred over UDP
      [RFC7252] and TLS when transferred over TCP [RFC8323].




Lenders, et al.          Expires 8 January 2026                 [Page 3]

Internet-Draft                  CoRE DNR                       July 2025


   *  *Object Security:* Securing content objects can be achieved using
      OSCORE [RFC8613].  OSCORE can be used either as an alternative or
      in addition to transport security.

      OSCORE keys have a limited lifetime and need to be set up.  Keys
      can be established through an EDHOC key exchange [RFC9528],
      received from an ACE Authorization Server (AS, as described in the
      ACE OSCORE profile [RFC9203]), or through a combination of those
      (established with an EDHOC peer whose public key is confirmed by
      an AS, using the ACE EDHOC profile
      [I-D.ietf-ace-edhoc-oscore-profile]).

   The SVCB-based discovery of CoAP services with no security and
   transport security is covered in
   [I-D.ietf-core-transport-indication].  The discovery of CoAP
   services, however, with object security is not specified.  To guide
   future specifications, this document clarifies aspects when using
   SVCB in the context of CoAP and object security.

2.  Terminology

   The terms "DoC server" and "DoC client" are used as defined in
   [I-D.ietf-core-dns-over-coap].

   The terms "constrained node" and "constrained network" are used as
   defined in [RFC7228].

   SvcParams denotes the field in either DNS SVCB/HTTPS records as
   defined in [RFC9460], or DHCP and RA messages as defined in
   [RFC9463].  SvcParamKeys are used as defined in [RFC9460].

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

   The first and most important point of discussion for the
   discoverability of CoAP is if and what new SvcParamKeys need to be
   defined and what is already there.

   [RFC9460] defines the "alpn" key, which is used to identify the
   protocol suite of a service binding using its Application-Layer
   Protocol Negotiation (ALPN) ID [RFC7301].  While this is useful to
   identify classic transport layer security, the question is raised if
   this is needed or even helpful for when there is only object



Lenders, et al.          Expires 8 January 2026                 [Page 4]

Internet-Draft                  CoRE DNR                       July 2025


   security.  There is an ALPN ID for CoAP over TLS that is defined in
   [RFC8323].  As using the same ALPN ID for different transport layers
   is not recommended, another ALPN ID for CoAP over DTLS is introduced
   in [I-D.ietf-core-coap-dtls-alpn].  Object security may be selected
   in addition to transport layer security or without it.  Additionally,
   different CoAP transports can be selected, which may be orthogonal to
   the transport security.  For instance, DTLS can be used over
   transports other than UDP.  The selection of CoAP transport protocols
   will be covered in future versions of
   [I-D.ietf-core-transport-indication].  Defining an ALPN ID for each
   combination of object security, mode of transport layer security, and
   transport protocol might not be viable or scalable.  For some ways of
   setting up object security, additional information is needed, such as
   an establishment options for an encryption context with EDHOC or an
   authentication server (AS) with ACE.

   Beyond the SvcParamKeys, there is the question of what the field
   values of the Encrypted DNS Options defined in [RFC9463] might be
   with EDHOC or ACE EDHOC.  While most fields map, "authentication-
   domain-name" (ADN) and its corresponding ADN length field may not
   matter when authentication is driven by Authorization for Constrained
   Environments (ACE) [RFC9203] [I-D.ietf-ace-edhoc-oscore-profile].

4.  Objectives

   SVCB records are not meant and should not be used to exchange
   security contexts, so this eliminates scenarios that use pre-shared
   keys with OSCORE.  This leaves 2 base scenarios for OSCORE, which may
   occur in combination, with scenarios using transport security, or
   alternative transport protocols:

   *  DoC over OSCORE using EDHOC, and

   *  DoC using any ACE profile that eventually produces an OSCORE
      context.

   We mostly need to answer the question for additional SvcParamKeys.
   [RFC9460] defines the keys "mandatory", "alpn", "no-default-alpn",
   "port", "ipv4hint", and "ipv6hint".  Additionally,
   [I-D.ietf-core-dns-over-coap] defines "docpath" which carries the
   path for the DNS resource at the DoC server as a CBOR sequence.

   Since "alpn" is needed for transport layer security, the type of
   object security (OSCORE using EDHOC, OSCORE using ACE, OSCORE using
   EDHOC using ACE), needs to be conveyed in a different SvcParamKey.
   The semantics and necessacity of the authenticator-domain-name field
   in [RFC9463] needs to be evaluated in each case.




Lenders, et al.          Expires 8 January 2026                 [Page 5]

Internet-Draft                  CoRE DNR                       July 2025


   When using ACE, more SvcParamKeys might be needed, such as the OAuth
   audience, the scope or the authentication server URI.

   Defining these SvcParamKeys, including their value formats and
   spaces, as well as the behavior definition for the authenticator-
   domain-name field, shall be part of future work.

4.1.  Scenarios

   Two example scenarios illustrate possible ways for which a solution
   should work; they are phrased in dialogue form rather than in terms
   of protocol elements to avoid bias on solutions.

4.1.1.  Neighbor discovered server with EDHOC credential

   In which the DoC server restricts access by network address (or not
   at all), and the client trusts its router to advertise a suitable
   Encrypted DNS server.

   1.  Client: Joins a network.

   2.  Local router: Sends out an IPv6 Router Advertisement (RA) with
       Encrypted DNS option (see Section 6 of [RFC9463]).

       Next to the network address, this conveys Service Parameters
       indicating DoC as well as a CWT Claims Set (CCS, [RFC8392]) that
       is to be used as an EDHOC credential.

   3.  Client starts EDHOC with the server at the indicated address.
       The client uses an ephemeral identity (i.e., authenticates with a
       CCS by value) and verifies that the DoC server is in possession
       of the key indicated in the CCS without explicit transmission of
       the CCS.

4.1.2.  DHCP discovered server with ACE details

   In which both the DoC client and server have a preconfigured security
   association with an ACE server, and trust no one else.

   1.  Client: Requests an address using DHCP

   2.  DHCP server: Offers an address along with the DHCPv6 Encrypted
       DNS Option (see Section 5 of [RFC9463]).

       The option contains an address as well as an indication that ACE
       is used, along with sufficient data for the client to obtain an
       ACE token.




Lenders, et al.          Expires 8 January 2026                 [Page 6]

Internet-Draft                  CoRE DNR                       July 2025


       This includes hints like the ACE Request Creation hints: the
       address of the AS and an identifier of the DoC server understood
       by the AS (the "aud"ience).  The address of the AS should be
       provided in some resolved form, given that DNS is being
       bootstrapped.

   3.  Client requests token from AS:

       "I need a token for a host that is authorized to be my DNS server
       with me being authorized to use it; these hints were presented
       for me to obtain it."

   4.  AS verifies that the hint represents a recognized DNS server,
       that the client is authorized to use it, and issues a token for a
       suitable ACE profile (e.g. ACE OSCORE profile or ACE EDHOC
       profile).

   5.  Client establishes a security context with the DoC server as per
       the profile.

5.  Security Considerations

   TODO Security

6.  IANA Considerations

   This document has no IANA considerations.

7.  References

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

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

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.






Lenders, et al.          Expires 8 January 2026                 [Page 7]

Internet-Draft                  CoRE DNR                       July 2025


   [RFC9461]  Schwartz, B., "Service Binding Mapping for DNS Servers",
              RFC 9461, DOI 10.17487/RFC9461, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9461>.

   [RFC9462]  Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
              Jensen, "Discovery of Designated Resolvers", RFC 9462,
              DOI 10.17487/RFC9462, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9462>.

   [RFC9463]  Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
              and T. Jensen, "DHCP and Router Advertisement Options for
              the Discovery of Network-designated Resolvers (DNR)",
              RFC 9463, DOI 10.17487/RFC9463, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9463>.

7.2.  Informative References

   [I-D.amsuess-core-coap-over-gatt]
              Amsüss, C., "CoAP over GATT (Bluetooth Low Energy Generic
              Attributes)", Work in Progress, Internet-Draft, draft-
              amsuess-core-coap-over-gatt-07, 25 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-amsuess-core-
              coap-over-gatt-07>.

   [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-08, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
              edhoc-oscore-profile-08>.

   [I-D.ietf-core-coap-dtls-alpn]
              Lenders, M. S., Amsüss, C., Schmidt, T. C., and M.
              Wählisch, "ALPN ID Specification for CoAP over DTLS", Work
              in Progress, Internet-Draft, draft-ietf-core-coap-dtls-
              alpn-04, 1 April 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              coap-dtls-alpn-04>.

   [I-D.ietf-core-dns-over-coap]
              Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C.,
              and M. Wählisch, "DNS over CoAP (DoC)", Work in Progress,
              Internet-Draft, draft-ietf-core-dns-over-coap-15, 19 June
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              core-dns-over-coap-15>.



Lenders, et al.          Expires 8 January 2026                 [Page 8]

Internet-Draft                  CoRE DNR                       July 2025


   [I-D.ietf-core-transport-indication]
              Amsüss, C. and M. S. Lenders, "CoAP Transport Indication",
              Work in Progress, Internet-Draft, draft-ietf-core-
              transport-indication-08, 3 March 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              transport-indication-08>.

   [lwm2m]    OMA SpecWorks, "White Paper – Lightweight M2M 1.1",
              October 2018, <https://omaspecworks.org/white-paper-
              lightweight-m2m-1-1/>.

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

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

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/rfc/rfc7858>.

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

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

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






Lenders, et al.          Expires 8 January 2026                 [Page 9]

Internet-Draft                  CoRE DNR                       July 2025


   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

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

   [RFC9203]  Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
              "The Object Security for Constrained RESTful Environments
              (OSCORE) Profile of the Authentication and Authorization
              for Constrained Environments (ACE) Framework", RFC 9203,
              DOI 10.17487/RFC9203, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9203>.

   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
              Dedicated QUIC Connections", RFC 9250,
              DOI 10.17487/RFC9250, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9250>.

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

Appendix A.  Change Log

A.1.  Since draft-lenders-core-dnr-05
      (https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-05)

   *  Nits

   *  Moving GitHub repo to netd-tud org

A.2.  Since draft-lenders-core-dnr-04
      (https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-04)

   *  Avoid the term "security mode" as it has a specific definition in
      RFC 7252

A.3.  Since draft-lenders-core-dnr-03
      (https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-03)

   *  Update [I-D.ietf-core-coap-dtls-alpn] reference

   *  intro: overhaul explanation of OSCORE setup




Lenders, et al.          Expires 8 January 2026                [Page 10]

Internet-Draft                  CoRE DNR                       July 2025


   *  objectives: Be open on ACE profiles

   *  Add scenarios

A.4.  Since draft-lenders-core-dnr-02
      (https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-02)

   *  Forward reference to upcoming changes in
      [I-D.ietf-core-transport-indication] updated

A.5.  Since draft-lenders-core-dnr-01
      (https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-01)

   *  Remove parts specified in [I-D.ietf-core-transport-indication]

   *  Remove parts specified in [I-D.ietf-core-coap-dtls-alpn]

   *  Remove solution sketches, set objectives to solve problem space

A.6.  Since draft-lenders-core-dnr-00
      (https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-00)

   *  IANA has processed the "co" ALPN and it is now added to the
      registry

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Martine Sophie Lenders
   TUD Dresden University of Technology
   Helmholtzstr. 10
   D-01069 Dresden
   Germany
   Email: martine.lenders@tu-dresden.de


   Christian Amsüss
   Email: christian@amsuess.com


   Thomas C. Schmidt
   HAW Hamburg
   Email: t.schmidt@haw-hamburg.de





Lenders, et al.          Expires 8 January 2026                [Page 11]

Internet-Draft                  CoRE DNR                       July 2025


   Matthias Wählisch
   TUD Dresden University of Technology & Barkhausen Institut
   Helmholtzstr. 10
   D-01069 Dresden
   Germany
   Email: m.waehlisch@tu-dresden.de













































Lenders, et al.          Expires 8 January 2026                [Page 12]


name: draft-ra-emu-pqc-eapaka
rev: 05
title: Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime
time: 2025-07-10T01:04:15Z
group_uri: /api/v1/group/group/1674/
expires: 2025-11-30T05:23:01Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014783+00:00
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
   making it quantum-safe using Post-Quantum Key Encapsulation
   Mechanisms (PQ-KEMs).

full_text:
EMU                                                             T. Reddy
Internet-Draft                                               A. Banerjee
Intended status: Standards Track                                   Nokia
Expires: 30 November 2025                                    29 May 2025


  Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime
                       draft-ra-emu-pqc-eapaka-05

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
   making it quantum-safe using Post-Quantum Key Encapsulation
   Mechanisms (PQ-KEMs).

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



Reddy & Banerjee        Expires 30 November 2025                [Page 1]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 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 30 November 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
     4.1.  Key Encapsulation Mechanisms  . . . . . . . . . . . . . .   5
   5.  Design Rationales . . . . . . . . . . . . . . . . . . . . . .   5
   6.  PQC KEM Enhancements by Design  . . . . . . . . . . . . . . .   6
   7.  Protocol Construction . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Protocol Call Flow  . . . . . . . . . . . . . . . . . . .   6
     7.2.  Key Steps in protocol construction  . . . . . . . . . . .   8
   8.  Extensions to EAP-AKA' FS . . . . . . . . . . . . . . . . . .   9
     8.1.  AT_PUB_KEM  . . . . . . . . . . . . . . . . . . . . . . .   9
     8.2.  AT_KEM_CT . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  ML-KEM  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
     10.1.  Selecting ML-KEM Variants  . . . . . . . . . . . . . . .  12
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     12.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15






Reddy & Banerjee        Expires 30 November 2025                [Page 2]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 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].

   Researchers have developed Post-Quantum Key Encapsulation Mechanisms
   (PQ-KEMs) to provide secure key establishment resistant against an
   adversary with access to a quantum computer.

   At the time of writing, NIST has standardized three PQC algorithms,
   with more expected to be standardized in the future ([NISTFINAL]).
   As these algorithms are secure against both quantum and classical
   computers, this document proposes a PQ-KEM for achieving perfect
   forward secrecy in EAP-AKA'.

   Although the proposed mechanism is applicable to any post-quantum Key
   Encapsulation Mechanism (PQ-KEM), this document specifies its use
   with Module-Lattice-based Key Encapsulation Mechanisms (ML-KEMs).
   ML-KEM provides a one-pass (store-and-forward) cryptographic method
   for an originator to securely transmit keying material to a recipient
   using the recipient’s ML-KEM public key.  Three parameter sets for
   ML-KEM are defined in [FIPS203], namely ML-KEM-512, ML-KEM-768, and
   ML-KEM-1024, listed in order of increasing security strength and
   decreasing performance.





Reddy & Banerjee        Expires 30 November 2025                [Page 3]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 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].  The following terms are
   repeately used in this specification:

   *  KEM: Key Encapsulation Mechanism

   *  PQ-KEM: Post-Quantum Key Encapsulation Mechanism

   *  CEK: Content Encryption Key

   *  ML-KEM: Module-Lattice-based Key Encapsulation Mechanism

   For the purposes of this document, it is helpful to be able to divide
   cryptographic algorithms into two classes:

   "Asymmetric Traditional Algorithm": An asymmetric cryptographic
   algorithm based on integer factorisation, finite field discrete
   logarithms or elliptic curve discrete logarithms, elliptic curve
   discrete logarithms, or related mathematical problems.

   "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that
   is believed to be secure against attacks using quantum computers as
   well as classical computers.  Post-quantum algorithms can also be
   called quantum-resistant or quantum-safe algorithms.  Examples of
   Post-Quantum Algorithm include ML-KEM.

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.

   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



Reddy & Banerjee        Expires 30 November 2025                [Page 4]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


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

4.1.  Key Encapsulation Mechanisms

   For the purposes of this document, we consider a Key Encapsulation
   Mechanism (KEM) to be any asymmetric cryptographic scheme comprised
   of algorithms satisfying the following interfaces [PQCAPI].

   *  def kemKeyGen() -> (pk, sk)

   *  def kemEncaps(pk) -> (ct, ss)

   *  def kemDecaps(ct, sk) -> ss

   where pk is public key, sk is secret key, ct is the ciphertext
   representing an encapsulated key, and ss is shared secret.

   KEMs are typically used in cases where two parties, hereby refereed
   to as the "encapsulater" and the "decapsulater", wish to establish a
   shared secret via public key cryptography, where the decapsulater has
   an asymmetric key pair and has previously shared the public key with
   the encapsulater.

5.  Design Rationales

   It is essential to note that in the PQ-KEM, one needs to apply
   Fujisaki-Okamoto [FO] transform or its variant [HHK] on the PQC KEM
   part to ensure that the overall scheme is IND-CCA2 secure, as
   mentioned in [I-D.ietf-tls-hybrid-design].  The FO transform is
   performed using the KDF such that the PQC KEM shared secret achieved
   is IND-CCA2 secure.

   Note that during the transition from traditional to post-quantum
   algorithms, there may be a desire or a requirement for protocols that
   incorporate both types of algorithms until the post-quantum



Reddy & Banerjee        Expires 30 November 2025                [Page 5]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


   algorithms are fully trusted.  HPKE is an KEM that can be extended to
   support hybrid post-quantum KEMs and the specifications for the use
   of HPKE with EAP-AKA prime is described in
   [I-D.draft-ar-emu-pqc-eapaka].

6.  PQC KEM Enhancements by Design

   We suggest the following changes and enhancements:

   *  A new attribute, AT_PUB_KEM, is defined to carry the PQC KEM
      public key from the EAP server.

   *  A new attribute, AT_KEM_CT, is defined to carry the ciphertext
      (ct) generated by the PQC KEM Encapsulation function from the EAP
      peer.

   *  The AT_KDF_FS attribute is updated to indicate the PQC KEM for
      generating the Master Key MK_PQ_SHARED_SECRET.

   *  Multiple AT_KDF_FS attributes is included in the EAP-Request to
      handle the EAP peer not supporting PQC KEM.

   *  The PQC KEM can be included first in the AT_KDF_FS attribute in
      the EAP-Request to indicate a higher priority for its use compared
      to the traditional key derivation functions.

7.  Protocol Construction

   This section defines the construction for PQC KEM in EAP-AKA' FS.

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



Reddy & Banerjee        Expires 30 November 2025                [Page 6]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


     |              |                            |                |
     |              |                            | ID, key deriv. |
     |              |                            | function,      |
     |              |                            | network name   |
     |              |                            +--------------->|
     |              |                            |                |
     |              |                            |    RAND, AUTN, |
     |              |                            | XRES, CK', IK' |
     |              |                            |<---------------+
     |      +-------+----------------------------+----------------+--+
     |      | Server now has the needed authentication vector. It    |
     |      | generates an a PQC KEM key pair, sends the public key  |
     |      | of that key pair and the first EAP method message      |
     |      | to the peer. In the message the AT_PUB_KEM attribute   |
     |      | carries the PQC KEM public key and the AT_KDF_FS       |
     |      | attribute carries PQC KEM algorithm. Both of           |
     |      | these are skippable attributes that can be ignored     |
     |      | if the peer does not support this extension.           |
     |      +-------+----------------------------+----------------+--+
     |              |                            |                |
     |              |     EAP-Req/AKA'-Challenge |                |
     |              |  AT_RAND, AT_AUTN, AT_KDF, |                |
     |              |   AT_KDF_FS, AT_KDF_INPUT, |                |
     |              |      AT_PUB_KEM, AT_MAC    |                |
     |              |<---------------------------+                |
   +--+--------------+----------------------------+---------+     |
   | The peer checks if it wants to do the FS extension. If |     |
   | yes, it will eventually respond with AT_KEM_CT and     |     |
   | AT_MAC. If not, it will ignore AT_PUB_KEM 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 calculate a   |     |
   | PQC KEM shared secret key based on the server's PQC    |     |
   | KEM public key. Finally, it proceeds to derive all     |     |
   | EAP-AKA' key values and  constructs a full response.   |     |
   +--+--------------+----------------------------+---------+     |
     |              |                            |                |



Reddy & Banerjee        Expires 30 November 2025                [Page 7]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


     |              | EAP-Resp/AKA'-Challenge    |                |
     |              | AT_RES, AT_KEM_CT,         |                |
     |              | AT_MAC                     |                |
     |              +--------------------------->|                |
     |      +-------+----------------------------+----------------+--+
     |      | The server now has all the necessary values. It        |
     |      | generates the PQC KEM 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 PQC KEM shared secret value. 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.           |
     |      +-------+----------------------------+----------------+--+
     |              |                            |                |
     |              |                EAP-Success |                |
     |              |<---------------------------+                |
     |              |                            |                |

7.2.  Key Steps in protocol construction

   We outline the following key steps in the protocol:

   *  Server generates the PQC KEM public key(pk), private key (sk)
      pair.  The server will generate the Authentication Vector (AV).
      The server PQC KEM key pair is derived as:

      sk, pk = kemKeyGen()

   *  The server will store the expected response XRES, the PQC KEM
      private key sk.  The server will forward the authenticator part
      (AUTH) of the AV to peer along with pk.

   *  The USIM will validate the AUTN received, also verifies the MAC.
      After the verification is successful and if the peer also supports
      the Forward secrecy, peer will invoke kemEncaps using pk:

      ct, ss = kemEncaps(pk)

   "ct" is the ciphertext from kemEncaps whereas "ss" is shared secret
   key.

   *  The peer will send the Authentication result RES and ct to the
      server.



Reddy & Banerjee        Expires 30 November 2025                [Page 8]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


   *  The server will verify the RES with XRES.  The server will use the
      ct and PQC KEM private key sk to generate shared secret:

      ss = kemDecaps(ct, sk)

   The generated ss from kemDecaps is the shared secret key derived from
   kemEncaps.  The peer and the server first generate the
   MK_PQ_SHARED_SECRET and subsequently generate MSK, EMSK as shown
   below:

     MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
     ct, ss = kemEncaps(pKR)
     MK_PQ_SHARED_SECRET = PRF'(IK'|CK'|ss,"EAP-AKA' FS"| Identity | ct)
     K_encr = MK[0..127]
     K_aut = MK[128..383]
     K_re = MK_PQ_SHARED_SECRET [0..255]
     MSK = MK_PQ_SHARED_SECRET [256..767]
     EMSK = MK_PQ_SHARED_SECRET [768..1279]

   where, pkR is PQC KEM public key from the EAP server, ct is the
   ciphertext from the kemEncaps and it is triggered by the EAP peer
   only.  The pseudo-random function (PRF') binds the shared secret to
   the ciphertext (ct), achieving MAL-BIND-K-CT.

   The ML-KEM already achieves MAL-BIND-K-PK as the hash of the PQC KEM
   public key is an input to the computation of the shared secret (ss)
   (line 2 of ML-KEM.Encaps algorithm in [FIPS203]).  These
   computational binding properties for KEMs are defined in [CDM].

8.  Extensions to EAP-AKA' FS

8.1.  AT_PUB_KEM

   The format of the AT_PUB_KEM 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_KEM    |   Reserved    |         Length (in bytes)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Value (variable)                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are as follows:

   AT_PUB_KEM:



Reddy & Banerjee        Expires 30 November 2025                [Page 9]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


   This is set to TBA1 BY IANA.

   Reserved: A 1-byte field reserved for future use.  Including this
   field ensures that the fixed header (Type, Reserved, Length) is 4
   bytes long, maintaining 4-byte alignment for the following Value
   field.  The Reserved field MUST be set to 0 on transmission and
   ignored on receipt.

   Length:

   A 2-byte unsigned integer indicating the total length of the
   attribute in bytes, including the Type, Reserved, Length, and Value
   fields, as well as any padding.  The length is expressed in multiples
   of 4 bytes.

   This differs from the attribute format used in EAP-AKA [RFC4187],
   where the Length field is 1 byte.The modification is necessary
   because PQC KEM public keys, such as those defined in ML-KEM-1024,
   will be 1568 bytes, which would exceed the 1024-byte limit imposed by
   the original EAP-AKA format.

   Value:

  *  EAP-Request: It contains the public key, which is the PQC KEM public key from the EAP server.

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

   The format of the AT_KEM_CT 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_KEM_CT     |   Reserved    |         Length (in bytes)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                   Value (variable)                            |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are as follows:

   AT_KEM_CT:




Reddy & Banerjee        Expires 30 November 2025               [Page 10]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


   This is set to TBA2 BY IANA.

   Reserved: A 1-byte field reserved for future use.  The Reserved field
   MUST be set to 0 on transmission and ignored on receipt.

   Length:

   A 2-byte unsigned integer indicating the total length of the
   attribute in bytes, including the Type, Reserved, Length, and Value
   fields, along with any padding.  The length is expressed in multiples
   of 4 bytes.

   This differs from the format used in EAP-AKA [RFC4187], where the
   Length field is 1 byte.  The change is necessary because ciphertexts
   produced by PQC KEM algorithms,such as 1568 bytes in ML-KEM-1024 will
   exceed the 1024 byte limit imposed by the original EAP-AKA attribute
   format.

   Value:

  *  EAP-Response: It contains the ciphertext (ct) from the PQC KEM Encapsulation function 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.

9.  ML-KEM

   ML-KEM offers several parameter sets with varying levels of security
   and performance trade-offs.  This document specifies the use of the
   ML-KEM algorithm at three security levels: ML-KEM-512, ML-KEM-768,
   and ML-KEM-1024.  The main security property for KEMs standardized in
   the NIST Post-Quantum Cryptography Standardization Project is
   indistinguishability under adaptive chosen ciphertext attacks (IND-
   CCA2) (see Section 10.2 of [I-D.ietf-pquip-pqc-engineers]).  The
   public/private key sizes, ciphertext key size, and PQ security levels
   of ML-KEM are detailed in Section 12 of
   [I-D.ietf-pquip-pqc-engineers].

10.  Security Considerations

   The security of the PQ-KEM algorithm depends on a high-quality
   pseudo-random number generator.  For further discussion on random
   number generation, see [RFC4086].






Reddy & Banerjee        Expires 30 November 2025               [Page 11]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


   In general, good cryptographic practice dictates that a given PQ-KEM
   key pair should be used in only one EAP session.  This practice
   mitigates the risk that compromise of one EAP session will not
   compromise the security of another EAP session and is essential for
   maintaining forward security.

10.1.  Selecting ML-KEM Variants

   ML-KEM is believed to be 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].

11.  IANA Considerations

   Two new values (TBA1, TBA2) in the skippable range need to be
   assigned by IANA for AT_PUB_KEM (Section 8.1) and AT_KEM_CT
   (Section 8.2) 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 PQC KEM algorithm entries:

   +=========+===============================+=========================+
   | Value   | Description                   | Reference               |
   +=========+===============================+=========================+
   | TBA3    | EAP-AKA' with MLKEM512        | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+
   | TBA4    | EAP-AKA' with MLKEM768        | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+
   | TBA5    | EAP-AKA' with MLKEM1024       | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+

12.  References

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




Reddy & Banerjee        Expires 30 November 2025               [Page 12]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 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>.

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

   [RFC9678]  Arkko, J., Norrman, K., and J. Preuß Mattsson, "Forward
              Secrecy Extension to the Improved Extensible
              Authentication Protocol Method for Authentication and Key
              Agreement (EAP-AKA' FS)", RFC 9678, DOI 10.17487/RFC9678,
              March 2025, <https://www.rfc-editor.org/rfc/rfc9678>.

12.2.  Informative References

   [CDM]      "Keeping Up with the KEMs: Stronger Security Notions for
              KEMs and automated analysis of KEM-based protocols",
              <https://eprint.iacr.org/2023/1933.pdf>.

   [FIPS203]  "FIPS-203: Module-Lattice-based Key-Encapsulation
              Mechanism Standard",
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.203.pdf>.

   [FO]       "Secure Integration of Asymmetric and Symmetric Encryption
              Schemes", <https://link.springer.com/article/10.1007/
              s00145-011-9114-1>.

   [HHK]      "A Modular Analysis of the Fujisaki-Okamoto
              Transformation", <https://link.springer.com/
              chapter/10.1007/978-3-319-70500-2_12>.

   [I-D.draft-ar-emu-pqc-eapaka]
              Banerjee, A. and T. Reddy.K, "Enhancing Security in EAP-
              AKA' with Hybrid Post-Quantum Cryptography", Work in
              Progress, Internet-Draft, draft-ar-emu-pqc-eapaka-04, 16
              March 2025, <https://datatracker.ietf.org/doc/html/draft-
              ar-emu-pqc-eapaka-04>.










Reddy & Banerjee        Expires 30 November 2025               [Page 13]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


   [I-D.draft-ietf-emu-aka-pfs-11]
              Arkko, J., Norrman, K., and J. P. Mattsson, "Forward
              Secrecy for the Extensible Authentication Protocol Method
              for Authentication and Key Agreement (EAP-AKA' FS)", Work
              in Progress, Internet-Draft, draft-ietf-emu-aka-pfs-11, 10
              July 2023, <https://datatracker.ietf.org/doc/html/draft-
              ietf-emu-aka-pfs-11>.

   [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-12, 19 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-12>.

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

   [I-D.ietf-tls-hybrid-design]
              Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
              exchange in TLS 1.3", Work in Progress, Internet-Draft,
              draft-ietf-tls-hybrid-design-12, 14 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              hybrid-design-12>.

   [NISTFINAL]
              "NIST Releases First 3 Finalized Post-Quantum Encryption
              Standards", n.d., <https://www.nist.gov/news-
              events/news/2024/08/nist-releases-first-3-finalized-post-
              quantum-encryption-standards>.

   [PQCAPI]   "PQC - API notes",
              <https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-
              Cryptography/documents/example-files/api-notes.pdf>.

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







Reddy & Banerjee        Expires 30 November 2025               [Page 14]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


Appendix A.  Acknowledgements

   This draft leverages text from [I-D.draft-ietf-emu-aka-pfs-11].

Authors' Addresses

   Tirumaleswar Reddy
   Nokia
   Bangalore
   Karnataka
   India
   Email: kondtir@gmail.com


   Aritra Banerjee
   Nokia
   Munich
   Germany
   Email: aritra.banerjee@nokia.com
































Reddy & Banerjee        Expires 30 November 2025               [Page 15]


name: draft-bastian-jose-dvs
rev: 02
title: Public Key Derived HMAC for JOSE
time: 2025-10-12T13:43:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-15T13:43:19Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014793+00:00
abstract:
This specification defines the use of a Diffie-Hellman key agreement
   (DH-KA) protocol combined with a key derivation function (KDF) to
   derive a symmetric Message Authentication Code (MAC) key from public
   information conveyed within a JSON Web Signature (JWS).

full_text:
Javascript Object Signing and Encryption                      P. Bastian
Internet-Draft                                                  M. Kraus
Intended status: Informational                      Bundesdruckerei GmbH
Expires: 15 April 2026                                      S. Santesson
                                                         IDsec Solutions
                                                           P. L. Altmann
                                       The Agency for Digital Government
                                                         12 October 2025


                    Public Key Derived HMAC for JOSE
                       draft-bastian-jose-dvs-02

Abstract

   This specification defines the use of a Diffie-Hellman key agreement
   (DH-KA) protocol combined with a key derivation function (KDF) to
   derive a symmetric Message Authentication Code (MAC) key from public
   information conveyed within a JSON Web Signature (JWS).

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://paulbastian.github.io/draft-bastian-jose-dvs/draft-bastian-
   jose-dvs.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-bastian-jose-dvs/.

   Discussion of this document takes place on the Javascript Object
   Signing and Encryption Working Group mailing list
   (mailto:jose@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/jose/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/jose/.

   Source for this draft and an issue tracker can be found at
   https://github.com/paulbastian/draft-bastian-jose-dvs.

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




Bastian, et al.           Expires 15 April 2026                 [Page 1]

Internet-Draft              PKD-HMAC for JOSE               October 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 15 April 2026.

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 . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Cryptographic Dependencies  . . . . . . . . . . . . . . . . .   4
   5.  Public Key Derived HMAC . . . . . . . . . . . . . . . . . . .   4
     5.1.  Signature Generation  . . . . . . . . . . . . . . . . . .   5
     5.2.  Signature Verification  . . . . . . . . . . . . . . . . .   5
     5.3.  Signature Suites  . . . . . . . . . . . . . . . . . . . .   6
   6.  Public Key Derived HMAC for JOSE  . . . . . . . . . . . . . .   6
     6.1.  The "pkds" Header Parameter . . . . . . . . . . . . . . .   7
       6.1.1.  Syntax and semantics  . . . . . . . . . . . . . . . .   7
     6.2.  Example JWT (*TODO*)  . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     7.1.  Replay Attack Detection . . . . . . . . . . . . . . . . .   9
     7.2.  Limited Repudiability . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Appendix A.  JSON Schema for the "pkds" Header
           Parameter . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11





Bastian, et al.           Expires 15 April 2026                 [Page 2]

Internet-Draft              PKD-HMAC for JOSE               October 2025


1.  Introduction

   JSON Web Signature (JWS) [RFC7515] and JSON Web Algorithms (JWA)
   [RFC7518] specify how to secure content with Hash-based Message
   Authentication Codes (HMAC) [RFC2104] using a shared symmetric key.
   These specifications do not provide means to dynamically derive a MAC
   key for JWS validation using only public information embedded in the
   JWS.

   This specification defines a new protected header parameter, pkds
   (public key derived secret), which contains information required to
   derive an HMAC key using a Diffie-Hellman key agreement (DH-KA) and a
   key derivation function (KDF).  The JWS Producer's DH-KA public key
   appears either in the pkds parameter or in a claims element for use
   in the key agreement computation.  The pkds parameter also includes
   the JWS Recipient's DH-KA public key, used by the JWS Producer during
   key agreement, as well as the KDF parameters necessary for deriving
   the MAC key.

   This specification also defines new alg parameter values, that are
   fully-specified according to Fully Specified Algorithms
   (https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-
   algorithms-00.html).

   The method is useful in settings where pre-shared keys are
   undesirable or infeasible, and where direct key distribution or key
   wrapping introduces operational concerns.  It enables the use of
   HMAC-based signatures that can be validated solely with information
   embedded in a JWS.

   A primary motivation for this work is to enable HMAC signature
   validation from information contained within an SD-JWT, mirroring
   capabilities available in credential formats like [ISO-18013-5].

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

   The draft uses "JSON Web Signature", "JOSE Header", "JWS Signature",
   "JWS Signing Input" as defined by [RFC7515].

   *Producer*:  The party that performs the DH-KA first, derives the MAC



Bastian, et al.           Expires 15 April 2026                 [Page 3]

Internet-Draft              PKD-HMAC for JOSE               October 2025


      key via a KDF, constructs the JOSE Header and JWS Payload, and
      computes the JWS Signature.

   *Recipient*:  The party that performs the DH-KA second, derives the
      MAC key via information in the JWS, and validates the JWS using
      the MAC key according to [RFC7515].

4.  Cryptographic Dependencies

   This specification relies on the following primitives:

   *  A Diffie-Hellman Key Agreement (KA-DH), for example ECKA-DH
      defined in [BSI-TR-03111]:

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

      -  Ndh: The length in bytes of a Diffie-Hellman shared secret
         produced by DH().

      -  Nsk: The length in bytes of a Diffie-Hellman private key.

   *  A key derivation function (KDF), for example HKDF defined in
      [RFC5869]:

      -  Extract(salt, ikm): Extract a pseudorandom key of fixed length
         Nh 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.

      -  Nh: The output size of the Extract() function in bytes.

   *  A Message Authentication Code algorithm (MAC), for example HMAC
      defined in [RFC2104]:

      -  MacSign(k, i): Returns an authenticated tag for the given input
         i and key k.

      -  Nk: The length in bytes of key k.

5.  Public Key Derived HMAC

   A public key derived HMAC requires three components for an algorithm:




Bastian, et al.           Expires 15 April 2026                 [Page 4]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   1.  a Diffie-Hellman Key Agreement (DHKA)

   2.  a Key Derivation Function (KDF)

   3.  a Message Authentication Code algorithm (MAC)

   In general, these parameters are chosen by the Producer.  These
   parameters need to be communicated to the Recipient to be able to
   verify the HMAC.

5.1.  Signature Generation

   The generation of the public key derived HMAC uses the Producer’s
   private key, the Recipient’s public key, and the message as inputs,
   along with optional parameters.  The retrieval and communication of
   the Recipient's public key is out of scope of this specification and
   subject to the implementing protocols.

   Input:

   *  skP: private key of the Producer

   *  pkR: public key of the Recipient

   *  msg: JWS Signing Input

   *  salt : Optional salt for key derivation

   *  info : Optional info for key derivation

   Function:

   def pkdHhmacSign(skP, pkR, msg, salt, info)

       dh =  DH(skP, pkR)
       prk = Extract(salt, dh)
       k = Expand(prk, info, Nk)
       signature = MacSign(k, msg)
       return signature

5.2.  Signature Verification

   The generation of the public key derived HMAC uses the Recipient's
   private key, the Producer's public key, and the message as inputs,
   along with optional parameters.

   Input:




Bastian, et al.           Expires 15 April 2026                 [Page 5]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   *  skR: private key of the Recipient

   *  pkS: public key of the Producer

   *  msg: JWS Signing Input

   *  salt : Optional salt for key derivation

   *  info : Optional info for key derivation

   *  signature : the Message Authentication Code

   Function:

   def pkdHhmacVerify(skR, pkS, msg, signature, salt, info)

       dh =  DH(skR, pkS)
       prk = Extract(salt, dh)
       k = Expand(prk, info, Nk)
       signature' = MacSign(k, msg)
       if signature != signature':
         raise Exception("Public key derived HMAC invalid")
       return

5.3.  Signature Suites

   Algorithms MUST follow the naming **TODO**.

6.  Public Key Derived HMAC for JOSE

   Public Key Derived HMAC behave like a digital signature as described
   in Section 3 of [RFC7518] and are intended for use in JSON Web
   Signatures (JWS) as described in [RFC7515].  The Producer performs
   the Message Signature or MAC Computation as defined by Section 5.1 of
   [RFC7515].  The Recipient performs the Message Signature or MAC
   Validation as defined by Section 5.2 of [RFC7515].

   The following JWS headers are used to convey Public Key Derived HMAC
   for JOSE:

   *  alg : REQUIRED.  The algorithm parameter describes the chosen
      signature suite, for example the ones described in Suites
      (Section 5.3).

   *  pkds : REQUIRED.  The pkds (Public key derived secret) parameter
      specifies the inputs needed to derive a symmetric key for MAC PKDS
      Headermake (Section 6.1).




Bastian, et al.           Expires 15 April 2026                 [Page 6]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   *  nonce : OPTIONAL.  The nonce may be provided by the Recipient
      additional to it's public key and ensure additional freshness of
      the signature.  If provided, the Producer SHOULD add the nonce to
      the header.

6.1.  The "pkds" Header Parameter

   The pkds protected header parameter specifies the inputs needed to
   derive a symmetric key for MAC computation using a key agreement and
   derivation scheme.  Its value is a JSON object that includes
   identifiers, public keys, and algorithm-specific parameters relevant
   to the derivation.

6.1.1.  Syntax and semantics

   The pkds Header Parameter value MUST be a JSON object with the
   following fields:

   *  rpk (object, REQUIRED): The Recipient's public key used in DH-KA.
      The rpk object MUST contain at least one key claim as defined in
      Section 4.1 of [RFC7515].

      Implementations MUST reject a JWS if the rpk key cannot be
      resolved unambiguously at validation time.

   *  ppk (object, OPTIONAL): The JWS Producer’s public key used in DH-
      KA.  The ppk object MUST contain at least one key claim as defined
      in Section 4.1 of [RFC7515].

      Implementations MUST reject a JWS if the ppk key cannot be
      resolved unambiguously at validation time or is incompatible with
      the key information in rpk.

   *  info (string, OPTIONAL): Context- and application-specific
      information used as the info parameter to the KDF.

   For a machine-readable definition of these fields, see the JSON
   Schema in Appendix A (Appendix B).

6.2.  Example JWT (*TODO*)

   The JWT/JWS header:









Bastian, et al.           Expires 15 April 2026                 [Page 7]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   {
     "typ":"JWT",
     "alg":"ECDH-P256+HKDF-SHA256+HS256",
     "pkds":{
       "pkS":{
         "jwk":{
           "kty":"EC",
           "crv":"P-256",
           "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
           "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
         }
       },
       "pkR":{
         "jwk":{
           "kty":"EC",
           "crv":"P-256",
           "x":"vWV4vmRT8HV9QAkbZJAWrvjOV0NfNOzkzq92apq8yjk",
           "y":"XGJRplhubKDv6cFA7e9-yn7F89UUwt57JVLAOS1tpXE"
         }
       },
       "info":"PKDS-v1"
     }
   }

   The JWT/JWS payload (TODO!:

   {
     "sub": "1234567890",
     "iat": 1516239022
   }

   The JWT/JWS signature:

   base64-encoded MAC

   This specification described instantiations of Public Key Derived
   HMAC using specific algorithm combinations:

+-------------------------------+--------------------------+----------------+
| Algorithm Name                | Algorithm Description    | Requirements   |
+-------------------------------+--------------------------+----------------+
| "ECDH-P256+HKDF-SHA256+HS256" | ECDH using NIST P-256,   |   Optional     |
|                               | HKDF using SHA-256, and  |                |
|                               | HMAC using SHA-256       |                |
+-------------------------------+--------------------------+----------------+

7.  Security Considerations




Bastian, et al.           Expires 15 April 2026                 [Page 8]

Internet-Draft              PKD-HMAC for JOSE               October 2025


7.1.  Replay Attack Detection

   Recipient MUST ensure the freshness of signatures by utilizing
   ephemeral keys in rpk or by providing a nonce for nonce.

7.2.  Limited Repudiability

   A malicious Recipient can weaken the repudiability property by
   involving certain third parties in the protocol steps.

   *  One method is to have a third party observe all protocol steps so
      that third party can be sure that the signature originates by the
      Producer.

   *  Another method requires that the Recipient's public key is a
      shared key that has previously been calculated with the keys of
      certain specific third parties so that the proof of authenticity
      can be done with Multi Party Computation involving all parties
      (see [TLS-NOTARY]).

8.  IANA Considerations

   Define:

   *  define new pkds header parameter

   *  alg values for *TODO* and some more

9.  References

9.1.  Normative References

   [BSI-TR-03111]
              "Technical Guideline BSI TR-03111: Elliptic Curve
              Cryptography, Version 2.10", June 2018,
              <https://www.bsi.bund.de/dok/TR-03111-en>.

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





Bastian, et al.           Expires 15 April 2026                 [Page 9]

Internet-Draft              PKD-HMAC for JOSE               October 2025


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

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7518>.

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

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

9.2.  Informative References

   [ISO-18013-5]
              "ISO/IEC 18013-5:2021, Personal identification — ISO-
              compliant driving licence, Part 5: Mobile driving licence
              (mDL) application", September 2021,
              <https://www.iso.org/standard/69084.html>.

   [TLS-NOTARY]
              "TLSNotary project", October 2024,
              <https://tlsnotary.org/>.

Appendix A.  Acknowledgments

   Thanks to:

   *  Brian Campbell

   *  John Bradley







Bastian, et al.           Expires 15 April 2026                [Page 10]

Internet-Draft              PKD-HMAC for JOSE               October 2025


Appendix B.  Appendix A.  JSON Schema for the "pkds" Header Parameter

   JSON { "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "https://example.com/schemas/pkds.schema.json", "title": "JOSE
   Header Parameter: pkds", "type": "object", "properties": { "ppk": {
   "$ref": "#/$defs/keyRef" }, "rpk": { "$ref": "#/$defs/keyRef" },
   "params": { "type": "object" } }, "required": [ "rpk" ],
   "additionalProperties": false, "$defs": { "keyRef": { "type":
   "object", "properties": { "jwk": { "type": "object" }, "kid": {
   "type": "string" }, "jkt": { "type": "string" }, "jku": { "type":
   "string" }, "x5c": { "type": "array", "items": { "type": "string" }
   }, "x5u": { "type": "string" }, "x5t": { "type": "string" } },
   "anyOf": [ { "required": [ "jwk" ] }, { "required": [ "kid" ] }, {
   "required": [ "jkt" ] }, { "required": [ "jku" ] }, { "required": [
   "x5c" ] }, { "required": [ "x5u" ] }, { "required": [ "x5t" ] } ],
   "additionalProperties": false } } }

Authors' Addresses

   Paul Bastian
   Bundesdruckerei GmbH
   Email: bastianpaul@googlemail.com


   Micha Kraus
   Bundesdruckerei GmbH
   Email: kraus.micha@gmail.com


   Stefan Santesson
   IDsec Solutions
   Email: stefan@aaa-sec.com


   Peter Lee Altmann
   The Agency for Digital Government
   Email: altmann@mail.com














Bastian, et al.           Expires 15 April 2026                [Page 11]


name: draft-ietf-ace-coap-est-oscore
rev: 09
title: Protecting EST Payloads with OSCORE
time: 2025-10-20T17:09:08Z
group_uri: /api/v1/group/group/1921/
expires: 2026-04-23T17:09:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014798+00:00
abstract:
Enrollment over Secure Transport (EST) is a certificate provisioning
   protocol over HTTPS [RFC7030] or CoAPs [RFC9148].  This document
   specifies how to carry EST over the Constrained Application Protocol
   (CoAP) protected with Object Security for Constrained RESTful
   Environments (OSCORE).  The specification builds on the EST-coaps
   [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman
   over COSE (EDHOC) instead of DTLS.  The specification also leverages
   the certificate structures defined in
   [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used
   alongside X.509 certificates.

full_text:
ACE Working Group                                            G. Selander
Internet-Draft                                               Ericsson AB
Intended status: Standards Track                                 S. Raza
Expires: 23 April 2026                                              RISE
                                                              M. Furuhed
                                                                   Nexus
                                                              M. Vučinić
                                                                   Inria
                                                               T. Claeys
                                                         20 October 2025


                  Protecting EST Payloads with OSCORE
                   draft-ietf-ace-coap-est-oscore-09

Abstract

   Enrollment over Secure Transport (EST) is a certificate provisioning
   protocol over HTTPS [RFC7030] or CoAPs [RFC9148].  This document
   specifies how to carry EST over the Constrained Application Protocol
   (CoAP) protected with Object Security for Constrained RESTful
   Environments (OSCORE).  The specification builds on the EST-coaps
   [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman
   over COSE (EDHOC) instead of DTLS.  The specification also leverages
   the certificate structures defined in
   [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used
   alongside X.509 certificates.

Discussion Venues

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

   Discussion of this document takes place on the Authentication and
   Authorization for Constrained Environments Working Group mailing list
   (ace@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/ace/.

   Source for this draft and an issue tracker can be found at
   https://github.com/EricssonResearch/EST-OSCORE.

Status of This Memo

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







Selander, et al.          Expires 23 April 2026                 [Page 1]

Internet-Draft                 EST-oscore                   October 2025


   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 23 April 2026.

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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Authentication  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  EDHOC . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Certificate-based Authentication  . . . . . . . . . . . .   6
     3.3.  Channel Binding . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Optimizations . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Protocol Design and Layering  . . . . . . . . . . . . . . . .   7
     4.1.  Discovery and URI . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Mandatory/optional EST Functions  . . . . . . . . . . . .   8
     4.3.  Payload formats . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Message Bindings  . . . . . . . . . . . . . . . . . . . .  13
     4.5.  CoAP response codes . . . . . . . . . . . . . . . . . . .  14
     4.6.  Message Fragmentation . . . . . . . . . . . . . . . . . .  14
     4.7.  Delayed Responses . . . . . . . . . . . . . . . . . . . .  14
     4.8.  Enrollment of Certificates with Static DH Keys  . . . . .  14
     4.9.  Enrollment of Certificates by Reference . . . . . . . . .  15
   5.  HTTP-CoAP Proxy . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     6.1.  Server-generated Private Keys . . . . . . . . . . . . . .  16



Selander, et al.          Expires 23 April 2026                 [Page 2]

Internet-Draft                 EST-oscore                   October 2025


     6.2.  Considerations on Channel Binding . . . . . . . . . . . .  17
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Appendix A.  Example Enrollment With Optimizations  . . . . . . .  21
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   One of the challenges with deploying a Public Key Infrastructure
   (PKI) for the Internet of Things (IoT) is certificate enrollment,
   because existing enrollment protocols are not optimized for
   constrained environments [RFC7228].

   One optimization of certificate enrollment targeting IoT deployments
   is specified in EST-coaps [RFC9148], which defines a version of
   Enrollment over Secure Transport [RFC7030] for transporting EST
   payloads over CoAP [RFC7252] and DTLS [RFC9147], instead of HTTP
   [RFC9110][RFC9112] and TLS [RFC8446].

   This document describes a method for protecting EST payloads over
   CoAP with OSCORE [RFC8613].  OSCORE specifies an extension to CoAP
   that protects messages at the application layer and can be applied
   independently of how CoAP messages are transported.  OSCORE can also
   be applied to CoAP-mappable HTTP, which enables end-to-end security
   for mixed CoAP and HTTP transfer of application layer data (see
   Section 11 of [RFC8613]).  Hence, EST payloads can be protected end-
   to-end independent of the underlying transport and through proxies
   translating between CoAP and HTTP.

   OSCORE is designed for constrained environments, building on IoT
   standards such as CoAP, CBOR [RFC8949], and COSE [RFC9052] [RFC9053],
   and has in particular gained traction in settings where message sizes
   and the number of exchanged messages need to be kept at a minimum,
   such as 6TiSCH [RFC9031], or for securing CoAP group messages
   [I-D.ietf-core-oscore-groupcomm].  Where OSCORE is implemented and
   used for communication security, the reuse of OSCORE for other
   purposes, such as enrollment, reduces the code footprint.

   Prior to running EST-oscore, the protocol defined in this
   specification, there must exist a trust relationship between the EST-
   oscore client and the EST-oscore server.  This trust relationship may
   be based on the pre-shared OSCORE security context, or on the common
   root of trust.  In case there is a pre-shared OSCORE security
   context, the CoAP exchange carrying EST payloads can occur
   immediately.  In case there is a common root of trust, a security



Selander, et al.          Expires 23 April 2026                 [Page 3]

Internet-Draft                 EST-oscore                   October 2025


   handshake based on the Ephemeral Diffie-Hellman over COSE (EDHOC,
   [RFC9528]) protocol needs to occur prior to running EST-oscore.  How
   this trust relationship is established is out of the scope of this
   document.

   How the EST-oscore server verifies the identity of the client prior
   to issuing a certificate is also out of the scope of this
   specification.

   EST-oscore defines a number of optimizations with respect to EST-
   coaps:

   *  The DTLS record layer is replaced by OSCORE.

   *  The DTLS handshake is replaced by the lightweight authenticated
      key exchange protocol EDHOC [RFC9528].

   *  Compact CBOR representations of X.509 certificates and EST
      payloads (see [I-D.ietf-cose-cbor-encoded-cert]) are optionally
      used.

   *  Certificates by reference (see [RFC9360]) are optionally used.

   *  The EST payloads protected by OSCORE can be proxied between
      constrained networks supporting CoAP and non-constrained networks
      supporting HTTP/HTTPs, through a CoAP-HTTP proxy without any
      security processing at the proxy (see Section 5).  The concept
      "Registrar" and its required trust relationship with the EST
      server as described in Section 5 of [RFC9148] is therefore not
      applicable.

2.  Terminology

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

   This document uses terminology from [RFC9148], which in turn is based
   on [RFC7030] and, in turn, on [RFC5272].

   The term "Trust Anchor" follows the terminology of [RFC6024]: "A
   trust anchor represents an authoritative entity via a public key and
   associated data.  The public key is used to verify digital
   signatures, and the associated data is used to constrain the types of
   information for which the trust anchor is authoritative."




Selander, et al.          Expires 23 April 2026                 [Page 4]

Internet-Draft                 EST-oscore                   October 2025


   Apart from enrolling certificates with keys that are used for
   signing, this document also specifies how to enroll certificates with
   keys that are used for Diffie-Hellman (DH) operations (static DH
   keys).  Instead of signing, possession of the private static DH key
   may be proved by generating a MAC given the recipient's public DH
   key.  Therefore, this document extends the definition of the term
   "Trust Anchor": the corresponding public key can also be used for MAC
   generation for static DH proof-of-possession procedures.

3.  Authentication

   This specification replaces the DTLS handshake in EST-coaps with the
   lightweight authenticated key exchange protocol EDHOC [RFC9528].  The
   enrollment using EST-oscore is based on the existence of an OSCORE
   Security Context protecting the messages conveying the EST payloads.
   This Security Context is typically established through an EDHOC
   session preceding the initial enrollment.  Re-enrollment does not
   require a new EDHOC session.

   The EST-oscore client MUST play the role of the EDHOC Initiator.  The
   EST-oscore server MUST play the role of the EDHOC Responder.

   The EST-oscore clients and servers must perform mutual
   authentication.  The EST server and EST client are responsible for
   ensuring that an acceptable cipher suite is negotiated.  The client
   must authenticate the server before accepting any server response.
   The server must authenticate the client.  These requirements are
   fulfilled when using EDHOC [RFC9528].

   The server must also provide relevant information to the CA to
   support its decision about issuing a certificate.

3.1.  EDHOC

   EDHOC supports authentication with certificates or raw public keys
   (referred to as "credentials"), and the credentials may either be
   transported in the protocol, or referenced.  This is determined by
   the identifier of the credential of the endpoint, ID_CRED_x for x=
   Initiator/Responder, which is transported in an EDHOC message.  This
   identifier may be the credential itself (in which case the credential
   is transported), or a pointer such as a URI of the credential (e.g.,
   x5u, see [RFC9360]) or some other identifier which enables the
   receiving endpoint to retrieve the credential.








Selander, et al.          Expires 23 April 2026                 [Page 5]

Internet-Draft                 EST-oscore                   October 2025


3.2.  Certificate-based Authentication

   EST-oscore, like EST-coaps, supports certificate-based authentication
   between the EST client and server.  The client MUST be configured
   with an Implicit or Explicit Trust Anchor (TA) [RFC7030] database,
   enabling the client to authenticate the server.  The requirements on
   managing the Implicit and Explicit TA databases are discussed in
   Section 9.1 of [RFC9148] and Section 9.2 of [RFC9148] and apply to
   EST-oscore.

   The EST client and EST server certificate SHOULD conform to
   [RFC7925].  The EST client and/or EST server certificate MAY be a
   (natively signed) CBOR certificate [I-D.ietf-cose-cbor-encoded-cert].
   The EST client indicates its preference for the type of the
   certificate it supports through the CoAP Accept option included in
   the request to the EST server.

3.3.  Channel Binding

   The [RFC5272] specification describes proof-of-possession as the
   ability of a client to prove its possession of a private key which is
   linked to a certified public key.  In case of a signature key, a
   proof-of-possession is generated by the client when it signs the
   PKCS#10 Request during the enrollment phase.  In case of a static DH
   key, a proof-of-possession is generated by the client when it
   generates a MAC and includes it in the PKCS#10 request, as per
   Section 4.8.

   Connection-based channel binding refers to the security binding
   between the PKCS#10 object and the underlying secure transport layer.
   This is typically achieved by including the challengePassword
   attribute in the PKCS#10 object that is dependent on the underlying
   security session.  Connection-based proof-of-possession using the
   challengePassword attribute of the PKCS#10 object is OPTIONAL, see
   Section 6.

3.4.  Optimizations

   This section contains optional behavior that may be used to reduce
   message sizes or round trips based on the application configuration.

   *  The third message of the EDHOC protocol, message_3, MAY be
      combined with an OSCORE-protected request [RFC9668], enabling
      authenticated Diffie-Hellman key exchange and a protected CoAP
      request/response (which may contain an enrollment request and
      response) in two round trips [RFC9668].





Selander, et al.          Expires 23 April 2026                 [Page 6]

Internet-Draft                 EST-oscore                   October 2025


   *  The enrolled client certificate MAY be the CBOR-encoded
      certificates defined in [I-D.ietf-cose-cbor-encoded-cert].

   *  The enrolled client certificate MAY be referenced instead of
      transported [RFC9360].  The response to the PKCS#10 request MAY
      specify a reference to the enrolled certificate rather than the
      certificate itself (see Section 4.9).

   *  The PKCS#10 object MAY request a certificate for a static DH key
      instead of a signature key.  This may result in a more compact
      request because the use of static DH keys may imply a proof-of-
      possession using a MAC, which is shorter than a signature.
      Additionally, subsequent EDHOC sessions using static DH keys for
      authentication have less overhead than key exchange protocols
      using signature-based authentication credentials.

   *  When the EDHOC handshake precedes the enrollment request, it is
      RECOMMENDED for the EST-client to leverage the information from
      the EDHOC session on the selected cipher suite when making a
      decision on which type of credential to enroll.

4.  Protocol Design and Layering

   EST-oscore uses CoAP [RFC7252] and Block-Wise transfer [RFC7959] to
   transfer EST messages in the same way as [RFC9148].  Instead of the
   DTLS record layer, OSCORE [RFC8613] is used to protect the messages
   conveying the EST payloads.  External Authorization Data (EAD) fields
   of EDHOC messages are intentionally not used to carry EST payloads
   because EDHOC needs not be executed in the case of re-enrollment.
   The DTLS handshake is replaced with EDHOC [RFC9528].  Figure 1 below
   shows the layered EST-oscore architecture.  Protocol design also
   allows that OSCORE and EDHOC messages are carried within the same
   CoAP message, as per [RFC9668].

                                   +----------------+
                                   |  EST messages  |
                      +------------+----------------+
                      |    EDHOC   |    OSCORE      |
                      +------------+----------------+
                      |        CoAP or HTTP         |
                      +-----------------------------+

         Figure 1: The stack diagram of EST protected with OSCORE.

   EST-oscore follows much of the EST-coaps and EST design.  This
   includes the need to authenticate the EST-server before performing
   any request on the different EST endpoints specified in this
   document.



Selander, et al.          Expires 23 April 2026                 [Page 7]

Internet-Draft                 EST-oscore                   October 2025


4.1.  Discovery and URI

   The discovery of EST resources and the definition of the short EST-
   coaps URI paths specified in Section 4.1 of [RFC9148], as well as the
   new Resource Type defined in Section 8.2 of [RFC9148] apply to EST-
   oscore.  In a web link targeting a resource for EST-oscore, it is
   REQUIRED to indicate that the resource is only accessible using
   OSCORE, by means of the "osc" target attribute defined in Section 9
   of [RFC8613].

   Example:

        REQ: GET /.well-known/core?rt="ace.est.sen"

        RES: 2.05 Content
      </est>;rt="ace.est.sen";osc

4.2.  Mandatory/optional EST Functions

   The EST-oscore specification has the same set of required-to-
   implement functions as EST-coaps.  The content of Table 1 is adapted
   from Section 4.2 in [RFC9148] and uses the updated URI paths (see
   Section 4.1).

               +===============+===========================+
               | EST functions | EST-oscore implementation |
               +===============+===========================+
               | /crts         | MUST                      |
               +---------------+---------------------------+
               | /sen          | MUST                      |
               +---------------+---------------------------+
               | /sren         | MUST                      |
               +---------------+---------------------------+
               | /skg          | OPTIONAL                  |
               +---------------+---------------------------+
               | /skc          | OPTIONAL                  |
               +---------------+---------------------------+
               | /att          | OPTIONAL                  |
               +---------------+---------------------------+

                    Table 1: Mandatory and optional EST-
                             oscore functions.









Selander, et al.          Expires 23 April 2026                 [Page 8]

Internet-Draft                 EST-oscore                   October 2025


4.2.1.  /crts

   EST-oscore provides the /crts operation.  A successful request from
   the client to this resource will be answered with a bag of
   certificates which is subsequently installed in the TA database,
   resulting in Explicit TAs.

   A trust anchor is commonly a self-signed certificate of the CA public
   key, of the format indicated by the CoAP Accept option present in the
   request.  In order to reduce transport overhead, the trust anchor
   could be a CBOR encoding of an X.509 certificate
   [I-D.ietf-cose-cbor-encoded-cert], or a CWT Claims Set (CCS)
   [RFC8392], containing the CA public key and associated data without a
   signature.

4.3.  Payload formats

   Similar to EST-coaps, EST-oscore allows transport of DER-encoded
   objects of a given Media-Type.  When transporting DER-encoded
   objects, EST-oscore uses the same CoAP Content-Format identifiers as
   EST-coaps when transferring EST requests and responses.  In addition,
   EST-oscore allows the transport of CBOR-encoded objects, as indicated
   by their corresponding Media-Type.

   EST-oscore servers MUST support both the DER-encoded ASN.1 objects
   and the CBOR-encoded objects, i.e., they MUST support formats
   detailed in Section 4.3.1 and Section 4.3.2.  It is up to the client
   to support only DER-encoded ASN.1, only CBOR encoding, or both.
   Based on the client encoding of the CSR (DER encoding or CBOR
   encoding), the server is able to tell whether the client prefers a
   DER-encoded object (Section 4.3.1) or a CBOR-encoded object
   (Section 4.3.2) in response.  In addition, Content-Format negotiation
   for specific objects happens through the CoAP Accept option present
   in the requests.  The CoAP Accept option may not be present; this is
   a case which carries special semantics, see Section 4.3.1 and
   Section 4.3.2.

4.3.1.  DER-encoded ASN.1 Objects

   Table 2 summarizes the information from Section 4.3 in [RFC9148] for
   what concerns the transport of DER-encoded ASN.1 objects.










Selander, et al.          Expires 23 April 2026                 [Page 9]

Internet-Draft                 EST-oscore                   October 2025


        +=======+==================================+======+=======+
        | URI   | Media Type                       | Type | #IANA |
        +=======+==================================+======+=======+
        | /crts | N/A                              | req  | -     |
        +-------+----------------------------------+------+-------+
        |       | application/pkix-cert            | res  | 287   |
        +-------+----------------------------------+------+-------+
        |       | application/pkcs7-mime;smime-    | res  | 281   |
        |       | type=certs-only                  |      |       |
        +-------+----------------------------------+------+-------+
        | /sen  | application/pkcs10               | req  | 286   |
        +-------+----------------------------------+------+-------+
        |       | application/pkix-cert            | res  | 287   |
        +-------+----------------------------------+------+-------+
        |       | application/pkcs7-mime;smime-    | res  | 281   |
        |       | type=certs-only                  |      |       |
        +-------+----------------------------------+------+-------+
        | /sren | application/pkcs10               | req  | 286   |
        +-------+----------------------------------+------+-------+
        |       | application/pkix-cert            | res  | 287   |
        +-------+----------------------------------+------+-------+
        |       | application/pkcs7-mime;smime-    | res  | 281   |
        |       | type=certs-only                  |      |       |
        +-------+----------------------------------+------+-------+
        | /skg  | application/pkcs10               | req  | 286   |
        +-------+----------------------------------+------+-------+
        |       | application/multipart-core       | res  | 62    |
        +-------+----------------------------------+------+-------+
        | /skc  | application/pkcs10               | req  | 286   |
        +-------+----------------------------------+------+-------+
        |       | application/multipart-core       | res  | 62    |
        +-------+----------------------------------+------+-------+
        | /att  | N/A                              | req  | -     |
        +-------+----------------------------------+------+-------+
        |       | application/csrattrs             | res  | 285   |
        +-------+----------------------------------+------+-------+

            Table 2: EST functions and the associated ASN.1 CoAP
                        Content-Format identifiers.

   Content-Format 281 and Content-Format 287 MUST be supported by EST-
   oscore servers.  It is up to the client to support only Content-
   Format 281, only Content-Format 287, or both.  As indicated in
   Section 4.3 of [RFC9148], the client will use a CoAP Accept Option in
   the request to express the preferred response Content-Format.  If an
   Accept Option is not included in the request, the client is not
   expressing any preference and the server SHOULD choose format 281.
   An exception to this "SHOULD" is in the case when the request



Selander, et al.          Expires 23 April 2026                [Page 10]

Internet-Draft                 EST-oscore                   October 2025


   contains a CBOR-encoded object (e.g. application/cose-c509-pkcs10),
   when the server SHOULD respond with a CBOR-encoded object (see
   Section 4.3.2).

   The generated response for /skg and /skc requests contains two parts:
   certificate and the corresponding private key.  Section 4.8 of
   [RFC9148] specifies that the private key in response to /skc request
   may be either an encrypted (PKCS #7) or unencrypted (PKCS #8) key,
   depending on whether the CSR request included SMIMECapabilities.

   Due to the use of OSCORE, which protects the communication between
   the EST client and the EST server end-to-end, it is possible to
   return the private key to /skc or /skg as an unencrypted PKCS #8
   object (Content-Format identifier 284).  Therefore, when making the
   CSR to /skc or /skg, the EST client MUST NOT include
   SMIMECapabilities.  As a consequence, the private key part of the
   response to /skc or /skg is an unencrypted PKCS #8 object.

   +==========+====================================+===================+
   | Function | DER-encoded ASN.1                  | DER-encoded ASN.1 |
   |          | Response, Part 1                   | Response, Part 2  |
   +==========+====================================+===================+
   | /skg     | 284                                | 281               |
   +----------+------------------------------------+-------------------+
   | /skc     | 284                                | 287               |
   +----------+------------------------------------+-------------------+

     Table 3: Response Content-Format identifiers for /skg and /skc in
                    case of DER- encoded ASN.1 objects.

4.3.2.  CBOR-encoded Objects

   Table 4 presents the equivalent information to Section 4.3.1 when
   CBOR-encoded objects are in use.

















Selander, et al.          Expires 23 April 2026                [Page 11]

Internet-Draft                 EST-oscore                   October 2025


          +=======+==============================+======+=======+
          | URI   | Media Type                   | Type | #IANA |
          +=======+==============================+======+=======+
          | /crts | N/A                          | req  | -     |
          +-------+------------------------------+------+-------+
          |       | application/cose-c509-cert   | res  | TBD6  |
          +-------+------------------------------+------+-------+
          | /sen  | application/cose-c509-pkcs10 | req  | TBD7  |
          +-------+------------------------------+------+-------+
          |       | application/cose-c509-cert   | res  | TBD6  |
          +-------+------------------------------+------+-------+
          |       | application/multipart-core   | res  | 62    |
          +-------+------------------------------+------+-------+
          | /sren | application/cose-c509-pkcs10 | req  | TBD7  |
          +-------+------------------------------+------+-------+
          |       | application/cose-c509-cert   | res  | TBD6  |
          +-------+------------------------------+------+-------+
          |       | application/multipart-core   | res  | 62    |
          +-------+------------------------------+------+-------+
          | /skg  | application/cose-c509-pkcs10 | req  | TBD7  |
          +-------+------------------------------+------+-------+
          |       | application/multipart-core   | res  | 62    |
          +-------+------------------------------+------+-------+
          | /skc  | N/A                          | req  | -     |
          +-------+------------------------------+------+-------+
          |       | N/A                          | res  | -     |
          +-------+------------------------------+------+-------+
          | /att  | N/A                          | req  | -     |
          +-------+------------------------------+------+-------+
          |       | application/csrattrs         | res  | TBD5  |
          +-------+------------------------------+------+-------+

            Table 4: EST functions and the associated CBOR CoAP
                        Content-Format identifiers.

   Please note that Section 4.4 of [I-D.ietf-cose-cbor-encoded-cert]
   defines the format and the semantics of the response to /att.

   In case of CBOR-encoded objects, there is a single Content-Format,
   TBD6, that MUST be supported by both the EST-oscore servers and
   clients.  The EST-client indicates its preference for a CBOR-encoded
   object through the CoAP Accept option.  A preference for any (future)
   Content-Format is to be expressed by the EST-client through the
   Accept option.

   If a CoAP Accept option is not included in the request, the client is
   not expressing preference and the server SHOULD respond with a
   response application/multipart-core that includes the reference(s) to



Selander, et al.          Expires 23 April 2026                [Page 12]

Internet-Draft                 EST-oscore                   October 2025


   the enrolled certificate (e.g., x5t, x5u, c5t, c5u).  The
   application/multipart-core response MUST include the reference(s) to
   the enrolled certificate which allows the client or any other party
   to retrieve it (e.g., through an URI).  The application/multipart-
   core response MAY also include the actual certificate.  The exact
   contents of the application/multipart-core response are dependent on
   the application policy.  An exception to the "SHOULD" is in the case
   when the request contains a DER-encoded ASN.1 object (e.g.,
   application/pkcs10), when the server SHOULD respond with an
   appropriate ASN.1 object (see Section 4.3.1).

   In the case of a request to /skg, the response contains two parts:
   certificate and the corresponding private key.  The certificate part
   is encoded as the application/cose-c509-cert object (Content-Format
   identifier TBD6), while the corresponding private key is encoded as
   application/cose-c509-privkey (Content-Format identifier TBD10).  The
   function /skc is not available when using CBOR-encoded objects, and
   clients MUST use the /skg function for server-side generated keys.

   Table 5 summarizes the Content-Format identifiers used in responses
   to the /skg function.

        +==========+=======================+======================+
        | Function | CBOR Response, Part 1 | CBOR Response Part 2 |
        +==========+=======================+======================+
        | /skg     | TBD10                 | TBD6                 |
        +----------+-----------------------+----------------------+

           Table 5: Response Content-Format identifiers for /skg
                      in case of CBOR-encoded objects.

4.4.  Message Bindings

   Note that the EST-oscore message characteristics are identical to
   those specified in Section 4.4 of [RFC9148].  Therefore, the
   following applies:

   *  EST-oscore endpoints MUST support delayed responses (see
      Section 4.7 of [RFC9148])

   *  EST-oscore endpoints MUST support the following CoAP options:
      OSCORE, Uri-Host, Uri-Path, Uri-Port, Content-Format, Block1,
      Block2, and Accept.  EST-oscore servers MUST implement Block1 and
      Block2.  EST-oscore clients MUST implement Block2 and MAY
      implement Block1.

   *  The EST-coaps URLs based on coaps:// are translated to coap://,
      but with mandatory use of the CoAP OSCORE option.



Selander, et al.          Expires 23 April 2026                [Page 13]

Internet-Draft                 EST-oscore                   October 2025


4.5.  CoAP response codes

   See Section 4.5 in [RFC9148].

4.6.  Message Fragmentation

   The EDHOC key exchange is optimized for low message overhead, in
   particular when using static DH keys instead of signature keys for
   authentication (e.g., method 3 of [RFC9528]).  Together with various
   measures listed in this document such as CBOR-encoded payloads
   [RFC8949], CBOR certificates [I-D.ietf-cose-cbor-encoded-cert],
   certificates by reference (Section 3.4), and trust anchors without
   signature (Section 4.2.1), a significant reduction of message sizes
   can be achieved.

   Nevertheless, depending on the application, the protocol messages may
   become larger than the available frame size thus resulting in
   fragmentation and, in resource-constrained networks such as based on
   IEEE 802.15.4 where throughput is limited, fragment loss can trigger
   costly retransmissions.

   It is recommended to prevent 6LoWPAN fragmentation, since it involves
   an error-prone datagram reassembly.  To limit the size of the CoAP
   payload, this document specifies the requirements on implementing the
   CoAP options Block1 and Block2 (see Section 4.4).

4.7.  Delayed Responses

   See Section 4.7 of [RFC9148].

4.8.  Enrollment of Certificates with Static DH Keys

   This section specifies how the EST client enrolls a static DH key.
   In general, a given key pair should only be used for a single
   purpose, such as key establishment, digital signature, or key
   transport.

   The EST client attempting to enroll a DH key for a key usage
   operation other than digital signature can use an alternative proof-
   of-possession algorithm.  The EST client SHOULD prepare the PKCS#10
   object and compute a MAC, replacing the signature, over the
   certification request information by following the steps in Section 6
   of [RFC6955].  The Key Derivation Function (KDF) and the MAC MUST be
   set to the HDKF and HMAC algorithms used by OSCORE.  The KDF and MAC
   is thus defined by the hash algorithm used by OSCORE in HKDF and
   HMAC, which by default is SHA-256.  When EDHOC is used, then the hash
   algorithm is the application hash algorithm of the selected cipher
   suite.



Selander, et al.          Expires 23 April 2026                [Page 14]

Internet-Draft                 EST-oscore                   October 2025


   In some cases, it may be beneficial to exceptionally use the static
   DH private key associated with the public key used in enrollment for
   a one-time signing operation of the CSR.  While a key pair should
   only be used for a single purpose (e.g., key establishment or
   signing), this exceptional use for one-time signing of the CSR is
   allowed, as discussed in Section 5.6.3.2 of [SP-800-56A] and
   Section 5.2 of [SP-800-57].

   To generate a MAC according to the algorithm outlined in Section 6 of
   [RFC6955], the client needs to know the public DH key of the proof-
   of-possession recipient/verifier, i.e., the EST server.  In the
   general case, the EST client MAY obtain the CA certs including the
   CA's DH certificate using the /crts function using an explicit
   request/response flow.  The obtained certificate indicates the DH
   group parameters which MUST be respected by the EST client when
   generating its own DH key pair.

   As an optimization, when EDHOC precedes the enrollment and the
   optimized workflow based on the EDHOC + OSCORE combined request is
   being used as per Section 3 of [RFC9668], the client MUST use the
   ephemeral public key of the EDHOC Responder, G_Y, as the recipient
   public key in the algorithm outlined in Section 6 of [RFC6955].  When
   generating its DH key pair, the client uses the group parameters as
   indicated by the selected cipher suite used in the EDHOC session.

4.9.  Enrollment of Certificates by Reference

   The EST client may indicate preference for enrolling a certificate by
   reference.  There are two cases to distinguish: 1) any certificate
   reference, or 2) a specific Content-Format.  In the first case, the
   EST client indicates preference for receiving any certificate by
   reference by sending a CBOR-encoded request without the CoAP Accept
   option.  In the second case, the EST client includes a Content-Format
   identifier in the CoAP Accept option indicating preference for
   receiving a specific reference (e.g., application/cose-certhash,
   application/cose-certhash;usage=c509, application/cbor containing a
   URI [I-D.ietf-cose-cbor-encoded-cert]).  It is out of the scope of
   this specification how the certificate by reference gets resolved to
   the actual certificate by other parties participating in the
   communication with the EST client.

5.  HTTP-CoAP Proxy

   As noted in Section 5 of [RFC9148], in real-world deployments, the
   EST server will not always reside within the CoAP boundary.  The EST-
   server can be outside the constrained network in a non-constrained
   network that supports HTTP but not CoAP, thus requiring an
   intermediary CoAP-to-HTTP proxy.



Selander, et al.          Expires 23 April 2026                [Page 15]

Internet-Draft                 EST-oscore                   October 2025


   Since OSCORE is applicable to CoAP-mappable HTTP (see Section 11 of
   [RFC8613]) the messages conveying the EST payloads can be protected
   end-to-end between the EST client and EST server, irrespective of the
   transport protocol or potential transport layer security that may
   need to be terminated at the proxy, see Figure 2.  Therefore, the
   concept "Registrar" and its required trust relationship with EST
   server as described in Section 5 of [RFC9148] is not applicable.

   The mappings between CoAP and HTTP referred to in Section 8.1 of
   [RFC9148] apply, and additional mappings resulting from the use of
   OSCORE are specified in Section 11 of [RFC8613].

   OSCORE provides end-to-end security between the EST Server and EST
   Client.  If a secure association is needed between the EST Client and
   the CoAP-to-HTTP Proxy, this may also rely on OSCORE
   [I-D.ietf-core-oscore-capable-proxies].

                                           Constrained-Node Network
      .---------.                      .-----------------------------.
      |   CA    |                      |                             |
      '---------'                      |                             |
           |                           |                             |
       .------.  HTTP   .-----------------.   CoAP   .-----------.   |
       | EST  |<------->|  CoAP-to-HTTP   |<-------->| EST Client|   |
       |Server|  (TLS)  |      Proxy      |          '-----------'   |
       '------'         '-----------------'                          |
                                       |                             |
           <------------------------------------------------>        |
                            OSCORE     |                             |
                                       |                             |
                                       '-----------------------------'

             Figure 2: CoAP-to-HTTP proxy at the CoAP boundary.

6.  Security Considerations

6.1.  Server-generated Private Keys

   This document enables the EST client to request the generation of
   private keys and the enrollment of the corresponding public key
   through /skg and /skc functions.  As discussed in Section 9 of
   [RFC9148], the transport of private keys generated at the EST-server
   is inherently risky.  The use of server-generated private keys may
   lead to the increased probability of digital identity theft.
   Therefore, implementations SHOULD NOT use server-generated private
   key EST functions.





Selander, et al.          Expires 23 April 2026                [Page 16]

Internet-Draft                 EST-oscore                   October 2025


   A cryptographically-secure pseudo-random number generator is required
   to be available to generate good quality private keys on EST-clients.
   A cryptographically-secure pseudo-random number generator is also a
   dependency of many security protocols.  This includes the EDHOC
   protocol, which EST-oscore uses for the mutual authentication of EST-
   client and EST-server.  If EDHOC is used and a secure pseudo-random
   number generator is available, the EST-client MUST NOT use server-
   generated private key EST functions.  However, EST-oscore also allows
   pre-shared OSCORE security contexts to be used for authentication,
   meaning that EDHOC may not necessarily be present in the protocol
   stack of an EST-client.  If EDHOC is not used for authentication, and
   the EST-client device does not have a cryptographically secure
   pseudo-random number generator, then the EST-client MAY use the
   server-generated private key functions.

   Although hardware random number generators are becoming dominantly
   present in modern IoT devices, it has been shown that many available
   hardware modules contain vulnerabilities and do not produce
   cryptographically secure random numbers.  It is therefore important
   to use multiple randomness sources to seed the cryptographically
   secure pseudo-random number generator.

6.2.  Considerations on Channel Binding

   Section 3 of [RFC9148] specifies that the use of connection-based
   channel binding is optional, and achieves it by including the tls-
   unique value in the CSR.  As a special case, when used with EDHOC for
   the enrollment of static DH keys, this specification achieves
   connection-based channel binding by using the EDHOC ephemeral public
   key of the Responder as the public key in the proof-of-possession
   algorithm that generates a PKCS#10 MAC.  Therefore, connection-based
   channel binding is in this case achieved without any additional
   overhead.

   Other cases include pre-shared OSCORE security contexts and the case
   where the signature key used for signing the CSR is different from
   the key used in the EDHOC session.  In these other cases, this
   specification makes explicit channel binding based on the
   challengePassword attribute in PKCS#10 requests OPTIONAL.  For
   example, the challengePassword attribute could be used for freshness
   in the case of pre-shared OSCORE security contexts and of a re-
   enrollment request.

   EST-servers MUST support the challengePassword attribute in PKCS#10
   requests.  How challengePassword is processed is outside of the scope
   of this specification and can be specified by an application policy.





Selander, et al.          Expires 23 April 2026                [Page 17]

Internet-Draft                 EST-oscore                   October 2025


7.  IANA Considerations

   This document does not require any IANA registrations.

8.  References

8.1.  Normative References

   [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-15, 18 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              cbor-encoded-cert-15>.

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

   [RFC6955]  Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
              of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
              May 2013, <https://www.rfc-editor.org/info/rfc6955>.

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

   [RFC7925]  Tschofenig, H., Ed. and T. Fossati, "Transport Layer
              Security (TLS) / Datagram Transport Layer Security (DTLS)
              Profiles for the Internet of Things", RFC 7925,
              DOI 10.17487/RFC7925, July 2016,
              <https://www.rfc-editor.org/info/rfc7925>.

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

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

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



Selander, et al.          Expires 23 April 2026                [Page 18]

Internet-Draft                 EST-oscore                   October 2025


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

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

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/info/rfc9052>.

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
              August 2022, <https://www.rfc-editor.org/info/rfc9053>.

   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/info/rfc9147>.

   [RFC9148]  van der Stok, P., Kampanakis, P., Richardson, M., and S.
              Raza, "EST-coaps: Enrollment over Secure Transport with
              the Secure Constrained Application Protocol", RFC 9148,
              DOI 10.17487/RFC9148, April 2022,
              <https://www.rfc-editor.org/info/rfc9148>.

   [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Header Parameters for Carrying and Referencing X.509
              Certificates", RFC 9360, DOI 10.17487/RFC9360, February
              2023, <https://www.rfc-editor.org/info/rfc9360>.

   [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/info/rfc9528>.








Selander, et al.          Expires 23 April 2026                [Page 19]

Internet-Draft                 EST-oscore                   October 2025


   [RFC9668]  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)", RFC 9668, DOI 10.17487/RFC9668, November 2024,
              <https://www.rfc-editor.org/info/rfc9668>.

8.2.  Informative References

   [I-D.ietf-core-oscore-capable-proxies]
              Tiloca, M. and R. Höglund, "OSCORE-capable Proxies", Work
              in Progress, Internet-Draft, draft-ietf-core-oscore-
              capable-proxies-05, 3 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              oscore-capable-proxies-05>.

   [I-D.ietf-core-oscore-groupcomm]
              Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
              and R. Höglund, "Group Object Security for Constrained
              RESTful Environments (Group OSCORE)", Work in Progress,
              Internet-Draft, draft-ietf-core-oscore-groupcomm-27, 12
              September 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-core-oscore-groupcomm-27>.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
              <https://www.rfc-editor.org/info/rfc5272>.

   [RFC6024]  Reddy, R. and C. Wallace, "Trust Anchor Management
              Requirements", RFC 6024, DOI 10.17487/RFC6024, October
              2010, <https://www.rfc-editor.org/info/rfc6024>.

   [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/info/rfc7030>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC9031]  Vučinić, M., Ed., Simon, J., Pister, K., and M.
              Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
              RFC 9031, DOI 10.17487/RFC9031, May 2021,
              <https://www.rfc-editor.org/info/rfc9031>.





Selander, et al.          Expires 23 April 2026                [Page 20]

Internet-Draft                 EST-oscore                   October 2025


   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/info/rfc9112>.

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

   [SP-800-57]
              Barker, E., "Recommendation for Key Management",
              NIST Special Publication 800-57 Revision 5, May 2020,
              <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.

Appendix A.  Example Enrollment With Optimizations

   The message flow starts with the EST client sending EDHOC message_1.
   The EDHOC handshake follows and concludes with the EDHOC message_3.
   EDHOC message_3 is carried in the same message as the OSCORE
   enrollment request, as specified in [RFC9668].  The OSCORE enrollment
   request contains a CoAP POST to the /sen endpoint.  This POST request
   includes the Content-Format option set to the value application/cose-
   c509-pkcs10, and the Accept option set to the value application/cose-
   c509-cert, indicating the support for CBOR-encoded objects.  In
   response, the client receives the application/cose-c509-cert object
   that contains the certificate.


















Selander, et al.          Expires 23 April 2026                [Page 21]

Internet-Draft                 EST-oscore                   October 2025


                  EST Client                   EST Server
                  |                                     |
                  |     EDHOC message_1                 |
                  +------------------------------------>|
                  |     EDHOC message_2                 |
                  |<------------------------------------+
                  |     EDHOC message_3                 |
                  |            +                        |
                  |     OSCORE request to /sen          |
                  +------------------------------------>|
                  |           POST /.well-known/est/sen |
                  |           Accept: TBD6              |
                  |           Content-Format: TBD7      |
                  |           Payload: Serialized TBD7  |
                  |                                     |
                  |     OSCORE response                 |
                  |<------------------------------------+
                  |           2.04 Changed              |
                  |           Content-Format: TBD6      |
                  |           Payload: Serialized TBD6  |

          Figure 3: Enrollment EST-oscore flow with optimizations.

Acknowledgments

   The authors would like to thank Esko Dijk, Marco Tiloca, and John
   Mattsson for providing a review of the document.

   Work on this document has in part been supported by the Horizon
   Europe Framework Programme project OpenSwarm (grant agreement No.
   101093046).

Authors' Addresses

   Göran Selander
   Ericsson AB
   Email: goran.selander@ericsson.com


   Shahid Raza
   RISE
   Email: shahid.raza@ri.se


   Martin Furuhed
   Nexus
   Email: martin.furuhed@nexusgroup.com




Selander, et al.          Expires 23 April 2026                [Page 22]

Internet-Draft                 EST-oscore                   October 2025


   Mališa Vučinić
   Inria
   Email: malisa.vucinic@inria.fr


   Timothy Claeys
   Email: timothy.claeys@gmail.com












































Selander, et al.          Expires 23 April 2026                [Page 23]


name: draft-ar-emu-hybrid-pqc-eapaka
rev: 00
title: Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography
time: 2025-07-10T01:03:59Z
group_uri: /api/v1/group/group/1674/
expires: 2025-12-11T13:06:38Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014809+00:00
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: 11 December 2025                                    9 June 2025


  Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography
                   draft-ar-emu-hybrid-pqc-eapaka-00

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-hybrid-pqc/.

   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 11 December 2025                [Page 1]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 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 11 December 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 . . . . . . . . . . . . . . . . . . . . . .   9
   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 11 December 2025                [Page 2]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 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 HPKE [I-D.ietf-hpke-pq]
   [I-D.irtf-cfrg-hybrid-kems] 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.ietf-hpke-pq].





Banerjee & Reddy        Expires 11 December 2025                [Page 3]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 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 11 December 2025                [Page 4]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 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 PQ/T Hybrid KEM
      in HPKE 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 PQ/T Hybrid KEM in HPKE.

   *  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 11 December 2025                [Page 5]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 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 11 December 2025                [Page 6]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 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 11 December 2025                [Page 7]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 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(pq_PK), private key
      (pq_SK) pair and the ECDH public key (trad_PK), private key
      (trad_SK) pair.  The server will generate and send the EAP AKA'
      Authentication Vector (AV).

   *  The server will store the expected response XRES, the ECDH private
      key trad_SK and the PQC KEM private key pq_SK.  The server will
      forward the EAP AKA' AV to peer along with pq_PK and trad_PK.

   *  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(pq_PK, trad_PK) as defined in section 5.4 of
      [I-D.irtf-cfrg-hybrid-kems].

   "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.irtf-cfrg-hybrid-kems]).

   *  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 pq_SK and ECDH private key trad_SK to
      generate shared secret.

   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:











Banerjee & Reddy        Expires 11 December 2025                [Page 8]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 2025


   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

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    |   Reserved    |      Length (in bytes)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Value (variable)                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are as follows:

   AT_PUB_HYBID:

   This is set to TBA1 BY IANA.

   Reserved:

   A 1-byte field reserved for future use.  Including this field ensures
   that the fixed header (Type, Reserved, Length) is 4 bytes long,
   maintaining 4-byte alignment for the following Value field.  The
   Reserved field MUST be set to 0 on transmission and ignored on
   receipt.

   Length:






Banerjee & Reddy        Expires 11 December 2025                [Page 9]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 2025


   A 2-byte unsigned integer indicating the total length of the
   attribute in bytes, including the Type, Reserved, Length, and Value
   fields, as well as any padding.  The length is expressed in multiples
   of 4 bytes.

   This differs from the attribute format used in EAP-AKA [RFC4187],
   where the Length field is 1 byte.  The modification is necessary
   because PQ/T Hybrid KEM public keys, such as X25519 and ML-KEM-768
   (e.g., X-Wing), would exceed the 1024-byte limit imposed by the
   original EAP-AKA format.

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

   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.




Banerjee & Reddy        Expires 11 December 2025               [Page 10]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 2025


9.  IANA Considerations

   Two new values (TBA2) and (TBA3) 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    | QSF-KEM(ML-KEM-768,P-256)-XOF(SHAKE256)-KDF(SHA3-256)              | [TBD BY IANA: THIS RFC] |
   +=========+===============================+========================+=====================================+
   | TBA3    | KitchenSink-KEM(ML-KEM-768,X25519)-XOF(SHAKE256)-KDF(HKDF-SHA-256) | [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>.

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






Banerjee & Reddy        Expires 11 December 2025               [Page 11]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 2025


   [RFC9678]  Arkko, J., Norrman, K., and J. Preuß Mattsson, "Forward
              Secrecy Extension to the Improved Extensible
              Authentication Protocol Method for Authentication and Key
              Agreement (EAP-AKA' FS)", RFC 9678, DOI 10.17487/RFC9678,
              March 2025, <https://www.rfc-editor.org/rfc/rfc9678>.

10.2.  Informative References

   [FIPS203]  "FIPS-203: Module-Lattice-based Key-Encapsulation
              Mechanism Standard",
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.203.pdf>.

   [I-D.ietf-hpke-pq]
              Barnes, R., "Post-Quantum and Post-Quantum/Traditional
              Hybrid Algorithms for HPKE", Work in Progress, Internet-
              Draft, draft-ietf-hpke-pq-00, 1 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-hpke-pq-
              00>.

   [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-12, 19 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-12>.

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

   [I-D.irtf-cfrg-hybrid-kems]
              Connolly, D., "Hybrid PQ/T Key Encapsulation Mechanisms",
              Work in Progress, Internet-Draft, draft-irtf-cfrg-hybrid-
              kems-03, 25 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
              hybrid-kems-03>.

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





Banerjee & Reddy        Expires 11 December 2025               [Page 12]

Internet-Draft         PQC Hybrid in EAP-AKA prime             June 2025


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

   [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 11 December 2025               [Page 13]


name: draft-spm-lake-pqsuites
rev: 01
title: Quantum-Resistant Cipher Suites for EDHOC
time: 2025-10-20T20:35:55Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T20:35:55Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014819+00:00
abstract:
The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral
   Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by
   adding new cipher suites with quantum-resistant algorithms, such as
   ML-DSA for digital signatures and ML-KEM for key exchange.  This
   document specifies how EDHOC operates in a post-quantum setting using
   both signature-based and PSK-based authentication methods, and
   defines corresponding cipher suites.

full_text:
LAKE Working Group                                           G. Selander
Internet-Draft                                         J. Preuß Mattsson
Intended status: Standards Track                                Ericsson
Expires: 23 April 2026                                   20 October 2025


               Quantum-Resistant Cipher Suites for EDHOC
                       draft-spm-lake-pqsuites-01

Abstract

   The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral
   Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by
   adding new cipher suites with quantum-resistant algorithms, such as
   ML-DSA for digital signatures and ML-KEM for key exchange.  This
   document specifies how EDHOC operates in a post-quantum setting using
   both signature-based and PSK-based authentication methods, and
   defines corresponding cipher suites.

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 23 April 2026.

Copyright Notice

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











Selander & Preuß Mattsson Expires 23 April 2026                 [Page 1]

Internet-Draft                  EDHOC PQC                   October 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  EDHOC with Quantum-Resistant Algorithms . . . . . . . . . . .   3
   3.  Using KEMs in EDHOC Key Exchange  . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  EDHOC Method Type Registry  . . . . . . . . . . . . . . .   5
     6.2.  EDHOC Cipher Suites Registry  . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral
   Diffie-Hellman over COSE (EDHOC) [RFC9528], supports the use of
   multiple authentication methods and the negotiation of cipher suites
   based on COSE algorithms.  Currently, four asymmetric authentication
   methods (0, 1, 2, and 3) are defined.  In addition, a symmetric key-
   based authentication method is being developed, see
   [I-D.ietf-lake-edhoc-psk].

   Currently defined cipher suites rely on Elliptic Curve Cryptography
   (ECC) for key exchange and authentication, making them vulnerable in
   the event that a Cryptographically Relevant Quantum Computer (CRQC)
   is constructed.

   This document specifies how EDHOC can operate in a post-quantum
   setting using both signature-based and PSK-based authentication, and
   defines corresponding cipher suites.







Selander & Preuß Mattsson Expires 23 April 2026                 [Page 2]

Internet-Draft                  EDHOC PQC                   October 2025


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.

   Readers are expected to be familiar with EDHOC [RFC9528].

2.  EDHOC with Quantum-Resistant Algorithms

   Method 0 in [RFC9528], which uses digital signatures for
   authentication by both the Initiator and Responder, and also the PSK
   method in [I-D.ietf-lake-edhoc-psk], is straightforward to use with
   standardized post-quantum algorithms.

   A quantum-resistant signature algorithm, such as ML-DSA
   [I-D.ietf-cose-dilithium], is a drop-in replacement for classical
   signature algorithms such as ECDSA.  For post-quantum secure key
   exchange, a quantum-resistant Key Encapsulation Mechanism (KEM), such
   as ML-KEM [I-D.ietf-jose-pqc-kem], can be applied directly to EDHOC,
   as is detailed in Section 3.

   To enable post-quantum security in EDHOC it suffices to register new
   cipher suites using COSE registered algorithms.  Cipher suites using
   ML-KEM-512 [I-D.ietf-jose-pqc-kem] for key exchange and ML-DSA-44
   [I-D.ietf-cose-dilithium] for digital signatures are specified in
   Section 6.2.  As both ML-KEM [FIPS203] and ML-DSA [FIPS204]
   internally use SHAKE256, it is natural to also use SHAKE256 for
   EDHOC's key derivation.  Additional post-quantum cipher suites may be
   specified.

   Methods 1–3 in [RFC9528] use a Diffie-Hellman/Non-Interactive Key
   Exchange (NIKE) based API for authentication.  As of this writing, no
   standardized post-quantum algorithms for these methods exist.  To
   highlight which methods that require DH/NIKE a column is added to the
   EDHOC Method Type registry, see Section 6.1.  To highlight matching
   cipher suites a corresponding column indicating support for DH/NIKE
   is added, see Section 6.2.

   An alternative path to post-quantum EDHOC, not pursued in this
   document, would be to define new authentication methods based on Key
   Encapsulation Mechanisms (KEMs).







Selander & Preuß Mattsson Expires 23 April 2026                 [Page 3]

Internet-Draft                  EDHOC PQC                   October 2025


   Compared to elliptic curve algorithms such as ECDHE, ECDSA, and
   EdDSA, ML-KEM-512 and ML-DSA-44 introduce significantly higher
   overhead [FIPS203][FIPS204].  More efficient post-quantum signature
   schemes are being standardized, such as FN-DSA.

3.  Using KEMs in EDHOC Key Exchange

   Given a quantum-resistant KEM, such as ML-KEM-512, with encapsulation
   key ek, ciphertext c, and shared secret key K (using the notation of
   [FIPS203]).  The Diffie-Hellman procedure in EDHOC is replaced by a
   KEM procedure as follows:

   *  The Initiator generates a new encapsulation / decapsulation key
      pair matching the selected cipher suite.

   *  The encapsulation key ek is transported in the G_X field in
      message_1.

   *  The Responder calculates (K,c) = Encaps(ek).

   *  The ciphertext c is transported in the G_Y field in message_2.

   *  The Initiator calculates the shared secret K = Decaps(c).

   *  G_XY is the shared secret key K.

   The security requirements and security considerations of EDHOC and
   the KEM algorithm used apply.  For example, the Initiator MUST
   generate a new encapsulation / decapsulation key pair for each EDHOC
   session.

   Note that G_Y does not contain a public key when a KEM is used in
   this way.  The definition of EDHOC message_2 in Section 5.3.1 of
   [RFC9528] remains the same:

   message_2 = (
     G_Y_CIPHERTEXT_2 : bstr,
   )

   and G_Y_CIPHERTEXT_2 remains the concatenation of G_Y and
   CIPHERTEXT_2, the latter is defined in Section 5.3.2 of [RFC9528].
   But now G_Y is a KEM ciphertext.

   Just as with the ephemeral key G_Y, the length of KEM ciphertext G_Y
   is known from the corresponding algorithm in the selected cipher
   suite, see Figure 1.  Hence the Initator can separate out the
   concatenated ciphertexts and decapsulate and decrypt, respectively.




Selander & Preuß Mattsson Expires 23 April 2026                 [Page 4]

Internet-Draft                  EDHOC PQC                   October 2025


   +-------------+------------------------------+
   |     KEM     | Length of ciphertext (bytes) |
   +=============+==============================+
   | ML-KEM-512  |                          768 |
   | ML-KEM-768  |                         1088 |
   | ML-KEM-1024 |                         1568 |
   +-------------+------------------------------+

                   Figure 1: Length of ML-KEM Ciphertext.

   Note also that this use of KEM applies both to standalone KEM and
   hybrid KEMs such as, e.g., X-wing [I-D.connolly-cfrg-xwing-kem].

   Conventions for using post-quantum KEMs within COSE are described in
   [I-D.ietf-jose-pqc-kem].  The shared secret key K corresponds to the
   initial shared secret SS' in that document.

4.  Security Considerations

   The cipher suites defined in [RFC9528] rely on Elliptic Curve
   Cryptography (ECC) for key exchange and authentication, which would
   be broken by a Cryptographically Relevant Quantum Computer (CRQC).
   In contrast, the cipher suites specified in this document use the
   quantum-resistant algorithms ML-KEM for key exchange and ML-DSA for
   authentication.  When used with Method 0 from [RFC9528], where both
   the Initiator and Responder authenticate using digital signatures, or
   with the PSK method defined in [I-D.ietf-lake-edhoc-psk], these
   cipher suites preserve the same security properties even in the
   presence of a quantum-capable adversary.

   Security considerations of ML-KEM are discussed in
   [I-D.sfluhrer-cfrg-ml-kem-security-considerations].

5.  Privacy Considerations

   TBD

6.  IANA Considerations

6.1.  EDHOC Method Type Registry

   IANA is requested to update the EDHOC Method Type registry with a
   column with heading "Requires DH/NIKE" indicating that the method
   requires Diffie-Hellman or Non-Interactive Key Exchange.  Valid table
   entries in this column are "Yes" and "No".

   For the existing Method Types, the following entries are inserted in
   the new "Requires DH/NIKE" column:



Selander & Preuß Mattsson Expires 23 April 2026                 [Page 5]

Internet-Draft                  EDHOC PQC                   October 2025


   Value: 0, Requires DH/NIKE: No
   Value: 1, Requires DH/NIKE: Yes
   Value: 2, Requires DH/NIKE: Yes
   Value: 3, Requires DH/NIKE: Yes

6.2.  EDHOC Cipher Suites Registry

   IANA is requested to update the EDHOC Cipher Suites registry with a
   column with heading "Supports DH/NIKE" indicating that the cipher
   suite supports Diffie-Hellman or Non-Interactive Key Exchange.  Valid
   table entries in this column are "Yes" and "No".

   For the existing EDHOC Cipher Suites 0-6, 24, 25, the entry "Yes" is
   inserted in the new "Supports DH/NIKE" column.

   Furthermore, IANA is requested to register the following entries in
   the EDHOC Cipher Suites Registry:

   Value: TBD1
   Array: 30, -45, 16, TBD3, -48, 10, -16
   Description: AES-CCM-16-128-128, SHAKE256, 16, MLKEM512, ML-DSA-44,
                AES-CCM-16-64-128, SHA-256
   Supports DH/NIKE: No
   Reference: [[This document]]

   Value: TBD2
   Array: 3, -45, 16, TBD3, -48, 30, -16
   Description: A256GCM, SHAKE256, 16, MLKEM512, ML-DSA-44,
                A256GCM, SHA-256
   Supports DH/NIKE: No
   Reference: [[This document]]

7.  References

7.1.  Normative References

   [I-D.ietf-cose-dilithium]
              Prorock, M. and O. Steele, "ML-DSA for JOSE and COSE",
              Work in Progress, Internet-Draft, draft-ietf-cose-
              dilithium-10, 14 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              dilithium-10>.









Selander & Preuß Mattsson Expires 23 April 2026                 [Page 6]

Internet-Draft                  EDHOC PQC                   October 2025


   [I-D.ietf-jose-pqc-kem]
              Reddy.K, T., Banerjee, A., and H. Tschofenig, "Post-
              Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE
              and COSE", Work in Progress, Internet-Draft, draft-ietf-
              jose-pqc-kem-04, 3 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-jose-
              pqc-kem-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>.

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

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

7.2.  Informative References

   [FIPS203]  "Module-Lattice-Based Key-Encapsulation Mechanism
              Standard", NIST FIPS 203, August 2024,
              <https://doi.org/10.6028/NIST.FIPS.203>.

   [FIPS204]  "Module-Lattice-Based Digital Signature Standard",
              NIST FIPS 204, August 2024,
              <https://doi.org/10.6028/NIST.FIPS.204>.

   [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-
              09, 1 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-connolly-
              cfrg-xwing-kem-09>.

   [I-D.ietf-lake-edhoc-psk]
              Lopez-Perez, Selander, G., Mattsson, J. P., Marin-Lopez,
              R., and F. Lopez-Gomez, "EDHOC Authenticated with Pre-
              Shared Keys (PSK)", Work in Progress, Internet-Draft,
              draft-ietf-lake-edhoc-psk-06, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lake-
              edhoc-psk-06>.




Selander & Preuß Mattsson Expires 23 April 2026                 [Page 7]

Internet-Draft                  EDHOC PQC                   October 2025


   [I-D.sfluhrer-cfrg-ml-kem-security-considerations]
              Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D.
              Shiu, "ML-KEM Security Considerations", Work in Progress,
              Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security-
              considerations-03, 15 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-sfluhrer-
              cfrg-ml-kem-security-considerations-03>.

Acknowledgments

   This work was supported partially by Vinnova - the Swedish Agency for
   Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS.

Authors' Addresses

   Göran Selander
   Ericsson
   Email: goran.selander@ericsson.com


   John Preuß Mattsson
   Ericsson
   Email: john.mattsson@ericsson.com




























Selander & Preuß Mattsson Expires 23 April 2026                 [Page 8]


name: draft-pocero-authkem-ikr-edhoc
rev: 01
title: KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios
time: 2026-01-20T17:18:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-24T17:18:03Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014824+00:00
abstract:
This document specifies a more efficient variant of a Key
   Encapsulation Mechanism (KEM)-based authentication method for the
   Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol,
   designed for the specific scenario in which the Initiator has prior
   knowledge of the Responder’s credentials, a case commonly found in
   constrained environments.  Improving upon the approach described in
   KEM-based Authentication for EDHOC, this method uses only a mandatory
   three-message handshake to enable signature-free post-quantum
   authentication when PQC KEMs, such as the NIST-standardized ML-KEM,
   are employed, while still providing mutual authentication, forward
   secrecy, and a degree of identity protection.

full_text:
individual                                              L. Pocero Fraile
Internet-Draft                                               C. Koulamas
Intended status: Standards Track                          A.P. Fournaris
Expires: 24 July 2026                                      E. Haleplidis
                                                        ISI, R.C. ATHENA
                                                         20 January 2026


 KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR)
                               Scenarios
                   draft-pocero-authkem-ikr-edhoc-01

Abstract

   This document specifies a more efficient variant of a Key
   Encapsulation Mechanism (KEM)-based authentication method for the
   Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol,
   designed for the specific scenario in which the Initiator has prior
   knowledge of the Responder’s credentials, a case commonly found in
   constrained environments.  Improving upon the approach described in
   KEM-based Authentication for EDHOC, this method uses only a mandatory
   three-message handshake to enable signature-free post-quantum
   authentication when PQC KEMs, such as the NIST-standardized ML-KEM,
   are employed, while still providing mutual authentication, forward
   secrecy, and a degree of identity protection.

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

Copyright Notice

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




Pocero Fraile, et al.     Expires 24 July 2026                  [Page 1]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   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.  Terminology and Requirements Language . . . . . . . . . .   3
       1.2.1.  Key Encapsulation Mechanisms (KEMs) . . . . . . . . .   4
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Protocol Elements . . . . . . . . . . . . . . . . . . . .   6
       2.1.1.  Ephemeral KEM . . . . . . . . . . . . . . . . . . . .   7
       2.1.2.  Authentication Parameters . . . . . . . . . . . . . .   7
         2.1.2.1.  Method  . . . . . . . . . . . . . . . . . . . . .   7
         2.1.2.2.  Authentication Keys . . . . . . . . . . . . . . .   8
         2.1.2.3.  Authentication Credentials  . . . . . . . . . . .   8
         2.1.2.4.  Identification of Credentials . . . . . . . . . .   8
       2.1.3.  Cipher Suites . . . . . . . . . . . . . . . . . . . .   9
   3.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Keys for EDHOC Message Processing . . . . . . . . . . . .  11
       3.1.1.  EDHOC_Extract . . . . . . . . . . . . . . . . . . . .  11
         3.1.1.1.  PRK_1e  . . . . . . . . . . . . . . . . . . . . .  11
         3.1.1.2.  PRK_2m  . . . . . . . . . . . . . . . . . . . . .  12
         3.1.1.3.  PRK_2e3e3m  . . . . . . . . . . . . . . . . . . .  12
       3.1.2.  EDHOC_Expand and EDHOC_KDF  . . . . . . . . . . . . .  13
       3.1.3.  PRK_out . . . . . . . . . . . . . . . . . . . . . . .  14
     3.2.  Keys for EDHOC Applications . . . . . . . . . . . . . . .  14
   4.  Message Formatting and Processing . . . . . . . . . . . . . .  14
     4.1.  KEM-based Authentication EDHOC Message 1  . . . . . . . .  15
       4.1.1.  Formating of Message 1  . . . . . . . . . . . . . . .  15
       4.1.2.  Initiator Composition of Message 1  . . . . . . . . .  15
       4.1.3.  Responder Processing of Message 1 . . . . . . . . . .  16
     4.2.  KEM-based authentication EDHOC Message 2  . . . . . . . .  17
       4.2.1.  Formating of Message 2  . . . . . . . . . . . . . . .  17
       4.2.2.  Responder Composition of Message 2  . . . . . . . . .  17
       4.2.3.  Initiator Processing of Message 2 . . . . . . . . . .  19
     4.3.  KEM-based authentication EDHOC Message 3  . . . . . . . .  20
       4.3.1.  Formating of Message 3  . . . . . . . . . . . . . . .  20
       4.3.2.  Initiator Composition of Message 3  . . . . . . . . .  20
       4.3.3.  Responder Processing of Message 3 . . . . . . . . . .  21
     4.4.  KEM-based authentication EDHOC Message 4  . . . . . . . .  22
       4.4.1.  Formating of Message 4  . . . . . . . . . . . . . . .  22



Pocero Fraile, et al.     Expires 24 July 2026                  [Page 2]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


       4.4.2.  Responder Composition of Message 4  . . . . . . . . .  22
       4.4.3.  Initaitor Processing of Message 4 . . . . . . . . . .  22
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     5.1.  EDHOC Method Types Registry . . . . . . . . . . . . . . .  23
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   The purpose of this document is to address a more efficient quantum-
   resistant transition of the Ephemeral Diffie-Hellman over COSE
   (EDHOC) protocol by extending with a new Key Encapsulation Mechanism
   (KEM)-based authentication method that uses a mandatory three-message
   handshake in Initiator-Known Responder (IKR) Scenarios.

   The specific protocol is part of a more extensive analysis of the PQ
   transition for the EDHOC protocol, which is currently in the process
   of being published.

1.1.  Motivation

   The KEM-based authentication method for EDHOC, specified in
   [I-D.pocero-authkem-edhoc], addresses the general mutually unknown
   peer scenario, similar to the original EDHOC protocol.  In this case,
   the Initiator and Responder, if do not have prior knowledge of each
   other's credentials can exchange them in the form of X.509
   certificate.  To maintain this generality an additional round trip is
   required, resulting in a mandatory five-message handshake.

   This document explores the possibility of reducing this overhead in
   the specific scenario where the Initiator already possesses the
   credentials of the Responder it wishes to connect in advance.  This
   applies to cases where the Initiator is a constrained device equipped
   with credentials for the Responder, obtained through pre-provisioning
   or out-of-band methods.  A typical example is during onboarding,
   where a remote or local server (acting as the Responder) is
   configured on the device in advance.  Such settings are particularly
   relevant for EDHOC, which targets constrained environments where
   transmitting credentials can be costly.

1.2.  Terminology and Requirements Language

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



Pocero Fraile, et al.     Expires 24 July 2026                  [Page 3]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   Readers are expected to be familiar with the terms and concepts
   described in EDHOC [RFC9528], CBOR [RFC8949], CBOR Sequences
   [RFC8742], COSE Structures and Processing [RFC9052] and COSE
   Algorithms [RFC9053], When referring to CBOR, this specification
   always refers to Deterministically Encoded CBOR, as specified in
   Section 4.2.1 and 4.2.2 of [RFC8949].  The single output from
   authenticated encryption (including the authentication tag) is called
   "ciphertext", following [RFC5116].

1.2.1.  Key Encapsulation Mechanisms (KEMs)

   The Key Encapsulation Mechanism consists of 3 algorithms:

   *  *( pk, sk ) <- KEM.KeyGen( )*: The probabilistic key generation
      algorithm generates a KEM key pair consisting of a public
      encapsulation key ( pk ) and secret decapsulation key ( sk ).

   *  *( ss , ct ) <- KEM.Encapsulate( pk )*: The probabilistic
      encapsulation algorithm takes as input a public encapsulation key
      ( pk ) and produces a shared secret ( ss ) and ciphertext ( ct ).

   *  *( ss ) <- KEM.Decapsulate( ct, sk )*: The decapsulation algorithm
      takes as input a secret encacpsulation key ( sk ) and produce a
      shared secret ( ss ).

2.  Protocol Overview

   This document defines a KEM-based authentication method for EDHOC,
   tailored for a specific scenario where the Initiator knows the
   credentials of the Responder it intends to communicate with
   beforehand.  In such cases, the method, specified in this document,
   reduces the standard five-message handshake defined in
   [I-D.pocero-authkem-edhoc] to a three-message exchange.

   This variant, referred to as Initiator Knows Responder (IKR),
   converts the Noise-XX pattern, used in both static-DH and KEM-based
   authentication EDHOC methods, into a Noise-IK pattern.  The Noise-IK
   pattern enables a mutual authentication handshake when the Initiator
   has prior knowledge of the Responder’s static public key, and the
   Initiator’s static keys are sent in the first message.  The mechanism
   provided in [PQNoise-CCS22] for transforming this pattern into the PQ
   Noise-IK version is integrated into this protocol.

   The KEM-based IKR variant provides a more efficient handshake with
   only three mandatory messages while maintaining mutual
   authentication, forward secrecy, and a level of identity protection.
   Notably, the Responder does not require prior knowledge of the
   Initiator’s credentials.  Instead, the Initiator encrypts its



Pocero Fraile, et al.     Expires 24 July 2026                  [Page 4]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   credentials, or an identifier, within message_1 using a key derived
   from a shared secret, computed over the Responder’s static KEM public
   key, which the Initiator already possesses.  Consequently, only the
   legitimate Responder, holding the corresponding static KEM private
   key, can decrypt this information, ensuring that the Initiator’s
   identity remains protected against both passive and active attackers.

   The KEM-based EDHOC protocol consists of three mandatory messages
   (message_1, message_2, message_3), an optional message_4, and an
   error message, between an Initiator (I) and a Responder (R).
   Figure 2 illustrates a KEM-based ikr authentication EDHOC message
   flow as well as the content of each message.  The protocol elements
   in Figure 1 are introduced in this Section and in Section 4.  Message
   formatting and processing are specified in Section 4.

    Initiator                                                Responder
    |  pk_eph, ct_R, AEAD( METHOD, SUITES_I, ID_CRED_I, C_I, EAD_1)  |
    +---------------------------------------------------------------->
    |                       message_1                                |
    |                                                                |
    |       ct_eph, ct_I, AEAD( C_R, ID_CRED_R, MAC_2, EAD_2 )       |
    <----------------------------------------------------------------+
    |                       message_2                                |
    |                                                                |
    |                  AEAD( MAC_3, EAD_3 )                          |
    +---------------------------------------------------------------->
    |                       message_3                                |
    |                                                                |
    |                      AEAD( EAD_4 )                             |
    <----- - - -- - - - - - - - - - - - - - - - - - - - - - - - - - -+
    |                         message_4                              |

            Figure 1: EDHOC Message Flow using the KEM-based IKR
                           Authentication Method

   The Initiator can derive symmetric application keys after receiving
   message_2 and Responder after receiving message_3.

   *  pk_eph is the ephemeral KEM public key generated by the Initiator.

   *  ct_eph is the ephemeral ciphertext computed by the Responder with
      the KEM.encapsulation algorithm over the received ephemeral public
      key (pk_eph).

   *  ct_R is the responder ciphertext computed by the Initiator with
      the KEM.encapsulation algorithm over the static KEM public key of
      the Responder, retrieved from the received ID_CRED_R in message_2.




Pocero Fraile, et al.     Expires 24 July 2026                  [Page 5]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   *  ct_I is the Iniatiator ciphertext computed by the Responder with
      the KEM.encapsulation algorithm over the static KEM public key of
      the Initiator, retrieved from the received ID_CRED_I in message_1.

   *  "CRED_I and CRED_R are the authentication credentials containing
      the public authentication keys of I and R, respectively", as
      defined in Section 2 of [RFC9528] .

   *  "ID_CRED_I and ID_CRED_R are used to identify and optionally
      transport the credentials of I and R, respectively", as defined in
      Section 2 of [RFC9528].

   *  AEAD(), and MAC() denote Authenticated Encryption with Associated
      Data, and Message Authentication Code, crypto algorithms applied
      with keys derived from one or more shared secrets calculated
      during the protocol", as defined in Section 2 of [RFC9528]

   *  "SUITES_I contains cipher suites supported by the Initiator and
      formatted and processed as specified in Section 3.6 and 6.3.2 of
      [RFC9528]"".

   *  "METHOD is an integer specifying the authentication method",as
      defined in Section 3.2 of [RFC9528].  In this case method 5; see
      Section 2.1.2.1.

   *  C_I and C_R are Connection Identifiers chosen by the Initiator and
      Responder, respectively, as specified in Section 3.3 of [RFC9528]

   *  EAD_1, EAD_2, EAD_3, EAD_4 are External Authorization Data
      included in message_1, message_2, message_3 and message_4,
      respectively

   This protocol is designed so that it follows the provisions of
   [RFC9528], that is, to encrypt and integrity protect as much
   information as possible and derive symmetric keys and random material
   using EDHOC_KDF with as much previous information as possible

2.1.  Protocol Elements

   This section describes the principal protocol elements that differ
   from the ones defined in EDHOC.  For the missing elements, the
   definitions in Section 3 of [RFC9528] SHOULD be consulted.









Pocero Fraile, et al.     Expires 24 July 2026                  [Page 6]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


2.1.1.  Ephemeral KEM

   The ephemeral KEM is used to provide forward secrecy.  The Initiator
   generates a new ephemeral KEM key pair in every new session to ensure
   that the compromise of long-term keys does not compromise past
   communications.  The elements of the Ephemeral KEM are:

   *  The ephemeral KEM key pair ( pk_eph, sk_eph ) is generated by the
      Initiator using the following function:

      pk_eph, sk_eph <- KEM.KeyGen()

   *  The ephemeral shared secret ( ss_eph ) and the ephemeral
      ciphertext ( ct_eph ) are generated using the encapsulation and
      decapsulation functions: in the Responder

      ss_eph, ct_eph <-  KEM.Encapsulate( pk_eph )

      in the Initiator

      ss_eph <-  KEM.decapsulation( ct_eph, sk_eph )

2.1.2.  Authentication Parameters

   The protocol performs the same authentication-related operations as
   described in Section 3.5 of [RFC9528]

   The protocol transports information about credentials ID_CRED_I and
   ID_CRED_R encrypted in message_1 and message_2, respectively.

2.1.2.1.  Method

   The protocol extends EDHOC with a new KEM-based authentication method
   for IKR scenarios, where both parties use static KEM key pairs.  The
   authentication is provided by a Message Authentication Code (MAC)
   included in message_2 and message_3 to authenticate the Responder and
   Initiator, respectively.  The Initiator and Responder need to have
   agreed on a method 5.

      +===================+====================+====================+
      | Method Type Value | Initiator          | Responder          |
      |                   | Authentication Key | Authentication Key |
      +===================+====================+====================+
      |                 5 | Static KEM Key     | Static KEM Key     |
      |                   | (IKR scenario)     | (IKR scenario)     |
      +-------------------+--------------------+--------------------+

               Table 2: Authentication Keys for Method Types



Pocero Fraile, et al.     Expires 24 July 2026                  [Page 7]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


2.1.2.2.  Authentication Keys

   The authentication key MUST be a static KEM authentication key pair.

   *  The Initiator static KEM authentication key pair: ( pk_I, sk_I )

   *  The Responder static KEM authentication key pair: ( pk_R, sk_R )

2.1.2.3.  Authentication Credentials

   The authentication credentials, CRED_I and CRED_R, contain the static
   KEM authentication public key of the Initiator and Responder,
   respectively, as described in Section 3.5.2 of [RFC9528].

   *  The authentication credentials can be X.509 certificates seconded
      as bstr, as defined in Section 3.5.2 of [RFC9528], using
      [RFC9360].  [I-D.ietf-lamps-kyber-certificates] describes the
      conventions for using the ML-KEM in X.509 Public Key
      Infrastructure.

   *  Additionally, the authentication credential may include a
      COSE_key, formatted as specified in [RFC8392], to reduce the
      credential size and avoid the PQC signature verification needed
      when X.509 certificates are used.  New IANA value registries
      should be defined to extend COSE Algorithms with the corresponding
      KEMs algorithm values.

2.1.2.4.  Identification of Credentials

   "The ID_CRED fields are used to identify and optionally transport
   credentials", as defined in Section 3.5.3 of [RFC9528].

   *  "ID_CRED_R is intended to facilitate for the Initiator retrieving
      the authentication credential CRED_R and the authentication key of
      R", as defined in Section 3.5.3 of [RFC9528].  For the
      authentication method defined in this document, the authentication
      key is the static KEM public key, and ID_CRED_R SHOULD contain an
      identifier of the credentials, since in the specific IKR scenario,
      the Responder’s credentials have been pre-provisioned or acquired
      out-of-band.











Pocero Fraile, et al.     Expires 24 July 2026                  [Page 8]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   *  "ID_CRED_I is intended to facilitate for the Responder retrieving
      the authentication credential CRED_I and the authentication key of
      I", as defined in Section 3.5.3 of [RFC9528].  For the
      authentication method defined in this document, the authentication
      key is the static KEM public key, and ID_CRED_I may contain the
      authentication credential CRED_R or an identifier of the
      credentials if these have been pre-provisioned or acquired out-of-
      band.

2.1.3.  Cipher Suites

   The authentication method specified in this document uses the EDHOC
   cipher suites element, as defined in Section 3.6 of [RFC9528].  An
   EDHOC cipher suit consists of an ordered set of algorithms from the
   "COSE Algorithms" IANA registry [RFC9053].  The predefined EDHOC
   cipher suites are also listed in the IANA registry, as specified in
   Section 10.2 of [RFC9528].

   A new predefined cipher suite SHOULD be added to the IANA registry,
   specifying each supported KEM in the EDHOC Key Exchange Algorithm
   parameter.  An example of this, when ML-KEM is used, is shown in
   Section 5.  The same KEM algorithm selected for key exchange SHOULD
   also be used for KEM-based authentication when method 4 is selected.
   Furthermore, the KEM algorithms used SHOULD also be added to the COSE
   Algorithms IANA registry to identify them, as is shown in Section 5.

3.  Key Derivation

   This section highlights the differences and similarities in the key
   derivation process of the KEM-based authentication method for IKR
   scenarios compared to the KEM-based authentication method on the
   general case [I-D.pocero-authkem-edhoc] and with the original EDHOC
   authentication methods described in [RFC9528].  An overview of the
   EDHOC key schedule when using the KEM-based authentication in the IKR
   scenarios method is shown in Figure 2, and each key derivation step
   is defined in the following subsections.


                +----+
                |TH_1|
                +--+-+
                   |
      +----+  +--++  +------+  +---+  +---+  +----+  +---+
      |ss_R|->|Ext|->|PRK_1e|--|Exp|->|K_1|->|AEAD|->|C_1|
      +----+  +---+  +--+---+  +--++  +---+  +--^-+  +---+
                        |         |             |
                    +---+         |         PLAINTEXT_1
                    |           +-------+-----------+



Pocero Fraile, et al.     Expires 24 July 2026                  [Page 9]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


                    |           |TH_1=H(pk_eph,ct_R)|
                    |           +---------+---------+
                    |                     |
      +------+  +---+---+  +-------+   +--+---+  +-----+
      |ss_eph|->|Extract|->|PRK_2m |---|Expand|->|MAC_2|
      +------+  +-------+  +--+----+   +------+  +-----+
                              |
                    +---------+
      +----+  +---+  +----------+  +---+   +---+   +----+  +---+
      |ss_I|->|Ext|->|PRK_2e3e3m|+-|Exp|-->|K_2|-->|AEAD|->|C_2|
      +----+  +---+  +----------+ |+--++   +---+   +-^--+  +---+
                                  |   |              |
                                  |   |         PLAINTEXT_2
                                  | +--+---------------------------+
                                  | |TH_2=H(H(Message1),ct_eph,ct_I|
                                  | +--+---------------------------+
                                  | +--+---+   +-----+
                                  +-|Expand|-->|MAC_3|
                                  | +------+   +-----+
                                  | +-------------------------------+
                                  | |TH_3=H(TH_2,PLAINTEXT_2,CRED_R)|
                                  | +--+----------------------------+
                                  |    |
                                  | +--++    +---+   +----+  +---+
                                  +-|Exp|--->|K_3|-->|AEAD|->|C_3|
                                  | +---+    +---+   +-^--+  +---+
                                  |                    |
                                  |             PLAINTEXT_3
                                  |      +---+  +---+   +----+  +---+
                                  +-m_4?-|Exp|->|K_4|-->|AEAD|->|C_4|
                                  |      +--++  +---+   +-^--+  +---+
                                  |         |             |
                                  |         |         PLAINTEXT_4
                                  | +----------+--------------------+
                                  | |TH_4=H(TH_3,PLAINTEXT_3,CRED_I)|
                                  | +----+--------------------------+
                                  |      |
                                  |  +--+--+  +-------+
                                  +--|Expand|->|PRK_out|
                                     +------+  +--+----+
                                                  |
                                               +--v---+
                                               |Expand|
                                               +------+
                                                  |
                                             +----v-------+
                                             |PRK_exporter|
                                             +---+--------+



Pocero Fraile, et al.     Expires 24 July 2026                 [Page 10]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


                                                 |
                                              +--v---+
                                              |Expand|
                                              +--+---+
                                                 |
                                                 v
                                          Aplication Key

         Figure 2: EDHOC Message Key Derivation using the KEM-based
                           Authentication Method

3.1.  Keys for EDHOC Message Processing

3.1.1.  EDHOC_Extract

   The pseudorandom keys (PRKs) used for KEM-based IKR authentication
   are derived using the same EDHOC_Extract function defined in
   [RFC9528], where the input keying material (IKM) and Salt are
   specified for each PRK below.  The usage of PRKs differs from the
   definitions in both [I-D.pocero-authkem-edhoc] and [RFC9528], and
   their names have been updated to reflect their new roles.

3.1.1.1.  PRK_1e

   The pseudorandom key PRK_1e is derived with the following input:

   *  The salt SHALL be TH_1.

   *  The IKM SHALL be the KEM shared secret (ss_R), used to
      authenticate the Responder.

   When SHA-256 is used PRK_1e is produced as follows:

   PRK_1e = HMAC-SHA-256( TH_1, ss_R )

   Where the ss_R shared secret is the output of the following functions
   in the Initiator and the Responder respectively.

   Initiator:

   ss_R, ct_R <-  KEM.Encapsulate( pk_R )

   Responder:

   ss_R <-  KEM.Decapsulate( ct_R, sk_R )






Pocero Fraile, et al.     Expires 24 July 2026                 [Page 11]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


3.1.1.2.  PRK_2m

   The pseudorandom key PRK_2m is derived with the following input:

   *  The salt SHALL be the SALT_2m derived from PRK_1e

   *  The IKM SHALL be the ephemeral KEM shared secret ss_eph

   PRk_2m is derived as follows:

   PRK_2m = EDHOC_Extract( SALT_2m, ss_eph )

   Where the ephemeral KEM shared secret ( ss_eph ) is the output of the
   following functions in the Initiator and Responder, respectively

   Initiator:

   ss_eph <-  KEM.Decapsulate( ct_eph, sk_eph )

   Responder:

   ss_eph, ct_eph <-  KEM.Encapsulate( pk_eph )

3.1.1.3.  PRK_2e3e3m

   The pseudorandom key PRK_2e3e3m is derived with the following input:

   *  The salt SHALL be the SALT_2e3m, derived from PRK_2m

   *  The IKM SHALL be the KEM shared secret ss_I, used to authenticate
      the Initiator

   PRK_2e3e3m is derived as follows:

   PRK_2e3e3m = EDHOC_Extract( SALT_2e3m, ss_I )

   Where the KEM shared secret ss_I used to authenticate the Initiator
   is the output of the following functions in the Initiator and
   Responder, respectively.

   Initiator:

   ss_I <-  KEM.Decapsulate( ct_I, sk_I )

   Responder:

   ss_I, ct_I <-  KEM.Encapsulate( pk_I )




Pocero Fraile, et al.     Expires 24 July 2026                 [Page 12]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


3.1.2.  EDHOC_Expand and EDHOC_KDF

   The output key materials (OKMs) are derived from the PRKs in the same
   way as described in Section 4.1.2 of [RFC9528], with modifications in
   some of the transcription hashes THs input contraction as specified
   in Section 4.

   The OKMs, including keys, initialization vectors (IV), and salts
   derivations using EDHOC_KDF are shown in Figure 3.

   The main difference from the original EDHOC shows in Section 4.1.2 of
   [RFC9528] Figure 6 are:

   *  A new K_1/IV_1 is computed to encrypt the message_1 which includes
      the ID_CRED_I initiator credentials, using a new transcrit hash
      (TH_1) defined as follows:

      TH_1 = H( pk_eph, ct_I )

      The AEAD encrption of message_1 with K_1/IV_1 provide integrity
      protection ensuring that the Initiator’s identity is protected
      against active attacks.  However, this does not provide
      authentication of the Initiator’s identity.

   *  K_2/IV_2 are computed to encrypt and authnticate message_2,
      derived from the PRK computed over the three shared secrets (
      ss_eph, ss_I, and ss_R )

   *  K2/IV_2, K_3/IV_3, and K_4/IV_4 are derived from the same
      PRK_2e3e4m with different THs as Info.

   *  The usage of the pseudorandom keys (PRKs) has changed, and the
      salt names have been selected to reflect their new roles
      accordingly.

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














Pocero Fraile, et al.     Expires 24 July 2026                 [Page 13]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   K_1         = EDHOC_KDF(PRK_1e,      0,  TH_1,      plaintext_length)
   IV_1        = EDHOC_KDF(PRK_1e,      1,  TH_1,      plaintext_length)
   SALT_2m     = EDHOC_KDF(PRK_1e,      2,  TH_1,      hash_length)
   MAC_2       = EDHOC_KDF(PRK_2m,      3,  context_2, mac_length_2)
   SALT_2e3e3m = EDHOC_KDF(PRK_2m,      4,  TH_2,      hash_length)
   K_2         = EDHOC_KDF(PRK_2e3e3m,  5,  TH_2,      key_length)
   IV_2        = EDHOC_KDF(PRK_2e3e3m,  6,  TH_2,      key_length)
   MAC_3       = EDHOC_KDF(PRK_2e3e3m,  7,  context_3, mac_length_3)
   K_3         = EDHOC_KDF(PRK_2e3e3m,  8,  TH_3,      key_length)
   IV_3        = EDHOC_KDF(PRK_2e3e3m,  9,  TH_3,      key_length)
   PRK_out     = EDHOC_KDF(PRK_2e3e3m,  10,  TH_4,      hash_length)
   K_4         = EDHOC_KDF(PRK_2e3e3m,  11,  TH_4,      key_length)
   IV_4        = EDHOC_KDF(PRK_2e3e3m,  12, TH_4,      iv_length)
   PRK_exporter= EDHOC_KDF(PRK_out,     13, h'',       hash_length)

        Figure 3: Key Derivations Using EDHOC_KDF for the KEM-based
                           Authentication Method

3.1.3.  PRK_out

   The pseudorandom key PRK_out is the output session key of a completed
   EDHOC session and is derived as follows:

   PRK_out = EDHOC_KDF( PRK_2e3e3m, TH_4, hash_length )

   The context include the trascription hash TH_4, defined as:

   TH_4 = H( TH_3, PLAINTEXT_3, CRED_I )

   Instead of reusing the last key-exchange internal key, the final key
   derivation depends on both PRK_2e3e3m and a newly computed TH_4,
   which include PLAINTEXT_3.  This approach aims to ensure robust
   session keys that are distinct from the MAC keys and whose
   confirmation implies the authentication of all the handshake data.

3.2.  Keys for EDHOC Applications

   Keying material for the application can be derived using the same
   EDHOC_Exporter interface defined in Section 4.2.1 of [RFC9528].

4.  Message Formatting and Processing

   This section outlines the message format and the procedures for
   composing and processing each message.







Pocero Fraile, et al.     Expires 24 July 2026                 [Page 14]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


4.1.  KEM-based Authentication EDHOC Message 1

4.1.1.  Formating of Message 1

   The message_1 SHALL be a CBOR Sequence as defined below.

   message_1 = (
     pk_eph : bstr,
     ct_R : bstr,
     CIPHERTEXT_1: bstr,
   )

4.1.2.  Initiator Composition of Message 1

   The Initiator SHALL compose message_1 as following:

   *  Construct the following elements of PLAINTEX_1:

      -  Chose KEM-based ikr authentication method 5.

      -  Construct SUITES_I following the Section 5.2.2 of [RFC9528]
         specifications

      -  Chose a connection identifier C_I and store it during the EDHOC
         session, as in Section 5.2.2 of [RFC9528]

   *  Encode PLAINTEXT_1 as a sequence of CBOR-encoded data items, as
      specified below:

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

   *  Generate an ephemeral KEM Key pair (pk_eph) using the KEM
      algorithm from the selected cipher suit.  The ephemeral key pair
      is computed by the Initiator using the following function:


      pk_eph, sk_eph <-  KEM.KeyGen()

   *  Encapsulate the known beforehand static KEM public key of the
      Responder (pk_R) by calculating the corresponding ciphertext
      (ct_R) and shared secret (ss_R) with the following function:




Pocero Fraile, et al.     Expires 24 July 2026                 [Page 15]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


      ss_R, ct_R <-  KEM.Encapsulate(pk_R)

   *  Compute the transcript hash TH_1 = H(pk_eph,ct_R)

   *  Compute the PRK_1e pseudorandom key from the static KEM shared
      secret ( ss_R ) used to authenticate the Responder.

   *  Compute K_1/IV1 as in Section 3.1.2

   *  Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
      of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_1, the initialization vector
      IV_1 (if used by the AEAD algorithm), the plaintext PLAINTEXT_1,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_1

      -  K_1 and IV_1 are defined in Section 3.1.2

      -  PLAINTEXT_1 = ( METHOD, SUITES_I, ID_CRED_I, C_I, ?EAD_2 )

      CIPHERTEXT_1 is the 'ciphertext' of COSE_Encrypt0.

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

4.1.3.  Responder Processing of Message 1

   The Responder SHALL process message_1 in the following order:

   1.  Decode message_1

   2.  Compute the KEM shared_secret ( ss_R ) for the authentication of
       the Responder by decapsulating the KEM ciphertext (ct_R) received
       in message_1 using the Responder static KEM secret key (sk_R).
       The KEM shared secret is computed by the Responder using the
       following function:

       ss_R <-  KEM.Decapsulate( ct_R, sk_R )

   3.  Compute the transcript hash TH_1 = H(pk_eph,ct_R)

   4.  Compute the PRK_1e pseudorandom key from the static KEM shared
       secret ( ss_R ) used to authenticate the Responder.

   5.  Compute K_1/IV1 as in Section 3.1.2



Pocero Fraile, et al.     Expires 24 July 2026                 [Page 16]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   6.  Decrypt the COSE_Encrypt0 (CIPHERTEXT_1) as defined Section 5.2
       and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm in the
       selected cipher suite and the parameters defined in
       Section 4.1.2.

   7.  Process PLAINTEXT_1 as specify in Section 5.2.3 of [RFC9528]

   8.  If all processing is completed successfully, then make ID_CRED_I
       and (if present) EAD_1 available to the application.

   9.  Obtain the authentication credential (CRED_I) from the
       (ID_CRED_I) and the static KEM authentication key (pk_I) of the
       Initiator

4.2.  KEM-based authentication EDHOC Message 2

4.2.1.  Formating of Message 2

   The Initiator SHALL compose message_2 as following:

   message_2 = (
     ct_eph : bstr,
     ct_I : bstr,
     CIPHERTEXT_2: bstr,
   )

4.2.2.  Responder Composition of Message 2

   The Responder SHALL compose message_2 as follows:

   *  Encapsulate the ephemeral KEM key received within message_1 using
      the KEM algorithm in the selected cipher suit.  The ephemeral KEM
      ciphertext and the KEM ephemeral shared secret are computed by the
      Responder using the following function:

       ss_eph, ct_eph <-  KEM.Encapsulate(pk_eph)

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

   *  Compute the PRK_2m pseudorandom key from both the static KEM
      shared secret ( ss_R ) and the latest ephemeral KEM shared secret
      ( ss_eph ).

   *  Choose a connection identifier C_R as specified in Section 5.3.2
      of [RFC9528]





Pocero Fraile, et al.     Expires 24 July 2026                 [Page 17]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   *  Compute the transcript hash TH_2 = H( ct_eph, ct_I, H(message_1)
      ).

   *  Compute MAC_2 as defined in Section 3.1.2, with context_2 =<< C_R,
      ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>

      -  The Responder authenticates with a PRK_2m derived from the KEM
         ephemeral shared secret and with the shared secret computed
         over its static KEM public key.

      -  The mac_lenght_2 is equal to the EDHOC MAC length of the
         selected cipher suit.

      -  The C_R, ID_CRED_R and CRED_R elements corresponds with the
         ones in Section 5.3.2 of [RFC9528]

      -  The latest transcript hash TH_2 and the External Application
         Data included in message_2 (EAD_2) are used.

   *  Encapsulate the retrieved static KEM authentication key of the
      Initiator ( pk_I ) calculating the corresponding ciphertext ( ct_I
      ) and shared secret ( ss_I ) with the following function:

       ss_I, ct_I <-  KEM.Encapsulate(pk_I)

   *  Compute the new PRK_2e3e3m from a chain that includes the KEM
      shared secret for the Authentication of the Responder ( ss_R ),
      the ephemeral KEM shared secret ( ss_eph ), and, the latest KEM
      shared secret for the Authentication of the Initiator ( ss_I ) as
      defined in Section 3.1.1.3

   *  Derive the session key K_2/IV2 as in Section 3.1.2.

   *  Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
      of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_2, the initialization vector
      IV_2 (if used by the AEAD algorithm), the plaintext PLAINTEXT_2,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_2

      -  K_2 and IV_2 are defined in Section 3.1.2

      -  PLAINTEXT_2 = ( C_R, ID_CRED_R, MAC_2, ?EAD_2 )

      CIPHERTEXT_2 is the 'ciphertext' of COSE_Encrypt0.



Pocero Fraile, et al.     Expires 24 July 2026                 [Page 18]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   *  Encode message_2 as a sequence of CBOR-encoded data items as
      specified in Section 4.2.1

4.2.3.  Initiator Processing of Message 2

   The Initiator SHALL process message_2 in the following order:

   1.   Decode message_2

   2.   Retrieve the protocol state as proposed in Section 5.3.3 of
        [RFC9528]

   3.   Compute the ephemeral KEM shared_secret ( ss_eph ) by
        decapsulating the KEM ciphertext (ct_eph) received in message_2
        using the ephemeral secret key (sk_eph).  The ephemeral KEM
        shared secret is computed by the Initiator using the following
        function:

       ss_eph <-  KEM.Decapsulate( ct_eph, sk_eph )

   4.   Compute the PRK_2m pseudorandom key from both the static KEM
        shared secret ( ss_R ) and the latest ephemeral KEM shared
        secret ( ss_eph )

   5.   Compute the transcript hash TH_2 = H(ct_eph,ct_I,H(message_1))

   6.   Compute the KEM shared_secret ( ss_I ) for the authentication of
        the Initiator by decapsulating the KEM ciphertext (ct_I)
        received in message_2 using the Initiator static KEM secret key
        (sk_I).  The KEM shared secret is computed by the Initiator
        using the following function:

       ss_I <-  KEM.Decapsulate( ct_I, sk_I )

   7.   Compute the new PRK_2e3e3m from a chain that includes the KEM
        shared secret for the Authentication of the Responder ( ss_R ),
        the ephemeral KEM shared secret ( ss_eph ), and the latest KEM
        shared secret for the Authentication of the Initiator ( ss_I )
        as defined in Section 3.1.1.3

   8.   Derive the session key K_2/IV2 as in Section 3.1.2.

   9.   Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_2) as defined
        Section 5.2 and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm
        in the selected cipher suite and the parameters defined in
        Section 4.4.2.





Pocero Fraile, et al.     Expires 24 July 2026                 [Page 19]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   10.  Verify MAC_2 as defined in Section 4.4.2, and make the result of
        the verification available to the application.

   11.  If all processing is completed successfully, then make ID_CRED_R
        and (if present) EAD_2 available to the application as in
        Section 5.3.3 of [RFC9528]

4.3.  KEM-based authentication EDHOC Message 3

4.3.1.  Formating of Message 3

   message_3 SHALL be a CBOR Sequence as defined below

   message_3 = (
     CIPHERTEXT_3 : bstr,
   )

4.3.2.  Initiator Composition of Message 3

   The Initiator SHALL process the composition of message_3 as follows:

   *  Compute MAC_3 as defined in Section 3.1.2, with context_3 =<< C_I,
      ID_CRED_I, TH_2, CRED_I, ? EAD_3 >>

      -  The Initaiator authenticate with a PRK_2e3e3m derived from the
         three shared secrets, including the shared secret computed over
         its static KEM key ( ss_I ).

      -  The mac_lenght_3 is equal to the EDHOC MAC lenght of the
         selected cipher suit.

      -  The C_I, ID_CRED_I and CRED_I elements corresponds with the
         ones in Section 5.4.2 of [RFC9528]

      -  The latest trascript hash TH_3 and the External Aplication Data
         include it on Message 3 (EAD_3) are used it.

   *  Compute the transcript hash TH_3=H(TH_2,PLAINTEXT_2,CRED_R) as
      specified in Section 5.4.2 of [RFC9528]

   *  Derive the new session key K_3/IV_3 as defined in Section 3.1.2.

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




Pocero Fraile, et al.     Expires 24 July 2026                 [Page 20]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


      -  protected = h''

      -  external_aad = TH_3

      -  K_3 and IV_3 are defined in Section 3.1.2

      -  PLAINTEXT_3 = ( MAC_3, ?EAD_5 )

      CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.

   *  Calculate PRK_out as defined in Section 3.1.3.  The Initiator can
      now derive application keys using the EDHOC_Exporter interface;
      see Section 3.2

   *  Encode message_3 as a CBOR data item as specified in Section 4.3.1

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

4.3.3.  Responder Processing of Message 3

   The Responder SHALL process message_3 in the following order:

   1.  Decode message_3

   2.  Retrieve the protocol state using available message correlation;
       see Section 3.4.2 of [RFC9528].

   3.  Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_3) as defined in
       Section 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm
       in the selected cipher suite and the parameters defined in
       Section 4.3.2.

   4.  Verify MAC_3 as defined in Section 4.3.2, and make the result of
       the verification available to the application.

   5.  Compute the transcript hash TH_4 = H(TH_3,PLAINTEXT_3,CRED_I)

   6.  Calculate PRK_out as defined in Section 3.1.3.  The Initiator can
       now derive application keys using the EDHOC_Exporter interface;
       see Section 3.2









Pocero Fraile, et al.     Expires 24 July 2026                 [Page 21]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


4.4.  KEM-based authentication EDHOC Message 4

   This section specifies message_4, which is OPTIONAL to support.
   Confirmation of the latest pseudorandom key (PRK2e3e3m) is already
   provided by message_2 and message_3, which are encrypted with K_2/
   IV_2 and K_3/IV_3, respectively.  Either message_4 or the first
   application message from the Responder to the Initiator, protected
   using a key derived from the EDHOC_Exporter, should also ensure the
   authenticity of all prior data.  This is achieved through the use of
   a session key derived from PRK2e3e3m and the latest transcript hash
   TH_4.

4.4.1.  Formating of Message 4

   message_4 SHALL be a CBOR Sequence as defined below

   message_4 = (
     CIPHERTEXT_4 : bstr,
   )

4.4.2.  Responder Composition of Message 4

   The Responder SHALL process the composition of message_4 as follows:

   *  Derive the new session key K_4/IV_4 as defined in Section 3.1.2.

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

      -  protected = h''

      -  external_aad = TH_4

      -  K_4 and IV_4 are defined in Section 3.1.2

      -  PLAINTEXT_4 = ( EAD_4 )

      CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.

   *  Encode message_4 as a CBOR data item as specified in Section 4.4.1

4.4.3.  Initaitor Processing of Message 4

   The Initiator SHALL process message_4 in the following order:




Pocero Fraile, et al.     Expires 24 July 2026                 [Page 22]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   1.  Decode message_4

   2.  Retrieve the protocol state using available message correlation;
       see Section 3.4.2 of [RFC9528].

   3.  Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_4) as defined
       Section 5.2 and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm
       in the selected cipher suite and the parameters defined in
       Section 4.4.2.

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

5.  IANA Considerations

5.1.  EDHOC Method Types Registry

   The "EDHOC Method Types" Registry from group "Ephemeral Diffie-
   Hellman Over COSE (EDHOC)" SHOULD be extended with a new value that
   identifies the KEM-based authentication method.  The extension value
   from the "Standards Action with Expert Review" range, is proposed in
   Table 2

   Registry Name:  EDHOC Method Types

   Reference:  draft-pocertoauthkem-ikr-edhoc-01

   The columns of the registry are Value, Initiator Authentication Key,
   Responder Authentication Key and Reference, where Value is an integer
   and the other columns are text strings.  The new value proposed is:

    +=============+================+================+=================+
    | Value       | Initiator      | Responder      | Reference       |
    |             | Authentication | Authentication |                 |
    |             | Key            | Key            |                 |
    +=============+================+================+=================+
    | 7           | Static KEM Key | Static KEM Key | [draft-         |
    | (suggested) | (IKR)          | (IKR)          | pocertoauthkem- |
    |             |                |                | ikr-edhoc-01]   |
    +-------------+----------------+----------------+-----------------+

                        Table 2: EDHOC Method Types









Pocero Fraile, et al.     Expires 24 July 2026                 [Page 23]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


6.  Security Considerations

   The protocol design aligns with the fundamental PQNoise process
   described in [PQNoise-CCS22].  Specifically, the Initiator transmits
   its ephemeral public key in the first message, along with a key
   encapsulation targeting the Responder’s known static public key.  The
   Initiator also includes its own credentials, unknown to the
   Responder, in the first message using ID_CRED_I.  As defined in the I
   pattern of the Noise framework [Noise], this approach exposes the
   Initiator’s identity to a passive attacker.  To mitigate this, the
   Initiator’s credentials are encrypted using a key derived from the
   Responder’s static public key, ensuring that only the intended
   Responder can decrypt the credentials.

   Full forward secrecy and explicit mutual authentication are achieved
   once the KEM-based ikr EDHOC handshake is completed, as in the
   static-DH EDHOC handshake.  While this mechanism preserves the
   Initiator’s anonymity against active attackers, the identity is
   protected only by the Responder public key, which makes it vulnerable
   if the Responder’s static key is later compromised, and vulnerable to
   be replayed.

   This KEM-based authnetication method does not provide non-
   repudiation, but only implicit proof of participation as EDHOC with
   static DH keys.  It also maintains an equivalent level of downgrade
   protection, as the negotiation base of the protocol is unchanged.

7.  References

7.1.  Normative References

   [I-D.ietf-lamps-kyber-certificates]
              Turner, S., Kampanakis, P., Massimo, J., and B.
              Westerbaan, "Internet X.509 Public Key Infrastructure -
              Algorithm Identifiers for the Module-Lattice-Based Key-
              Encapsulation Mechanism (ML-KEM)", Work in Progress,
              Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22
              July 2025, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lamps-kyber-certificates-11>.

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

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




Pocero Fraile, et al.     Expires 24 July 2026                 [Page 24]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


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

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

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/info/rfc9052>.

   [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Header Parameters for Carrying and Referencing X.509
              Certificates", RFC 9360, DOI 10.17487/RFC9360, February
              2023, <https://www.rfc-editor.org/info/rfc9360>.

   [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/info/rfc9528>.

7.2.  Informative References

   [I-D.pocero-authkem-edhoc]
              Fraile, L. P., Koulamas, C., Fournaris, A. P., and E.
              Haleplidis, "KEM-based Authentication for EDHOC", Work in
              Progress, Internet-Draft, draft-pocero-authkem-edhoc-01,
              24 October 2025, <https://datatracker.ietf.org/doc/html/
              draft-pocero-authkem-edhoc-01>.

   [Noise]    Perrin, T., "The Noise Protocol Framework", Revision 34,
              July 2018, <https://noiseprotocol.org/noise.html>.

   [PQNoise-CCS22]
              Angel, Y., Dowling, B., Hulsing, A., Schwabe, P., and F.
              Weber, "Post Quantum Noise", Proceedings of the 2022 ACM
              SIGSAC Conference on Computer and Communications Security
              (CCS '22), pages 97–109. Association for Computing
              Machinery, New York, NY, USA.  DOI:
              https://doi.org/10.1145/3548606.3560577, 2022,
              <https://doi.org/10.1145/3548606.3560577>.







Pocero Fraile, et al.     Expires 24 July 2026                 [Page 25]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


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

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
              August 2022, <https://www.rfc-editor.org/info/rfc9053>.

Authors' Addresses

   Lidia Pocero Fraile
   ISI, R.C. ATHENA
   Cyber-physical and Networked Embedded Systems
   26504 Patras
   Greece
   Email: pocero@isi.gr


   Christos Koulamas
   ISI, R.C. ATHENA
   Cyber-physical and Networked Embedded Systems
   26504 Patras
   Greece
   Email: koulamas@isi.gr


   Apostolos P. Fournaris
   ISI, R.C. ATHENA
   Security and Protection of Systems, Networks and Infrastructures
   26504 Patras
   Greece
   Email: fournaris@isi.gr


   Evangelos Haleplidis
   ISI, R.C. ATHENA
   Department of Digital Systems
   26504 Patras
   Greece
   Email: haleplidis@isi.gr










Pocero Fraile, et al.     Expires 24 July 2026                 [Page 26]


name: draft-tiloca-lake-exporter-output-length
rev: 00
time: 2026-01-09T07:09:48Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T14:22:10Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014829+00:00
title:
In-band Agreement of Output Lengths for the EDHOC_Exporter Interface of Ephemeral Diffie-Hellman Over COSE (EDHOC)

abstract:
The lightweight authenticated key exchange protocol Ephemeral Diffie-
   Hellman Over COSE (EDHOC) allows two peers to compute a shared secret
   session key.  Once the session key is available, the two peers can
   use the EDHOC_Exporter interface, e.g., to derive keying material for
   an application protocol.  This document defines an in-band approach
   that can be used by the two peers to agree about the lengths of the
   outputs produced with the EDHOC_Exporter interface.  The defined
   approach relies on an EDHOC External Authorization Data (EAD) item
   that can be exchanged in the first two EDHOC messages of an EDHOC
   session.

full_text:
LAKE Working Group                                             M. Tiloca
Internet-Draft                                                R. Höglund
Intended status: Standards Track                                 RISE AB
Expires: 8 January 2026                                   E. Lopez-Perez
                                                                   Inria
                                                             7 July 2025


In-band Agreement of Output Lengths for the EDHOC_Exporter Interface of
               Ephemeral Diffie-Hellman Over COSE (EDHOC)
              draft-tiloca-lake-exporter-output-length-00

Abstract

   The lightweight authenticated key exchange protocol Ephemeral Diffie-
   Hellman Over COSE (EDHOC) allows two peers to compute a shared secret
   session key.  Once the session key is available, the two peers can
   use the EDHOC_Exporter interface, e.g., to derive keying material for
   an application protocol.  This document defines an in-band approach
   that can be used by the two peers to agree about the lengths of the
   outputs produced with the EDHOC_Exporter interface.  The defined
   approach relies on an EDHOC External Authorization Data (EAD) item
   that can be exchanged in the first two EDHOC messages of an EDHOC
   session.

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-exporter-output-
   length.

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, et al.           Expires 8 January 2026                 [Page 1]

Internet-Draft        EDHOC_Exporter Output Lengths            July 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 8 January 2026.

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  EAD Item "EDHOC_Exporter Output Lengths"  . . . . . . . . . .   4
   3.  Processing at the Recipient Side  . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  EDHOC External Authorization Data Registry  . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

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

   Two peers participate in the EDHOC protocol, i.e., a peer acts as
   EDHOC Initiator and starts an EDHOC session with another peer acting
   as EDHOC Responder.  The main output of a successfully completed
   EDHOC session is the shared secret session key PRK_out (see
   Section 4.1.3 of [RFC9528]).




Tiloca, et al.           Expires 8 January 2026                 [Page 2]

Internet-Draft        EDHOC_Exporter Output Lengths            July 2025


   After having established PRK_out, the two peers can use the
   EDHOC_Exporter interface defined in Section 4.2.1 of [RFC9528], e.g.,
   to derive keying material for an application protocol.  Among its
   inputs, the EDHOC_Exporter interface includes "exporter_label" as a
   registered numeric identifier of the intended output and "length" as
   the length in bytes of the intended output.

   At the time of writing, notable uses of the EDHOC_Exporter interface
   include the derivation of:

   *  The Master Secret and Master Salt to use for establishing a
      Security Context for the security protocol Object Security for
      Constrained RESTful Environments (OSCORE) [RFC8613].  These
      derivations are specified in Appendix A.1 of [RFC9528].

   *  A symmetric Pre-Shared Key rPSK to use for session resumption in
      EDHOC and the corresponding credential identifier rID_CRED_PSK
      [I-D.ietf-lake-edhoc-psk].  These derivations are specified in
      Section 6 of [I-D.ietf-lake-edhoc-psk].

   When using the EDHOC_Exporter interface, it is crucial that the two
   peers agree about the length in bytes of each intended output, in
   order to ensure the correctness of their operations.  To this end,
   the two peers can rely on pre-defined default lengths, or agree out-
   of-band on alternative lengths.  However, the two peers might need or
   prefer to explicitly agree about specific output lengths to use on a
   per-session basis.

   This document defines an in-band approach that the two peers can use
   to agree about the lengths of the outputs produced with the
   EDHOC_Exporter interface.  The defined approach relies on an EDHOC
   External Authorization Data (EAD) item (see Section 3.8 of
   [RFC9528]), which the two peers can exchange in the first two EDHOC
   messages of an EDHOC session.

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.

   Readers are expected to be familiar with the terms and concepts
   related to EDHOC [RFC9528], Concise Data Definition Language (CDDL)
   [RFC8610], and Concise Binary Object Representation (CBOR) [RFC8949].





Tiloca, et al.           Expires 8 January 2026                 [Page 3]

Internet-Draft        EDHOC_Exporter Output Lengths            July 2025


   Examples throughout this document are expressed in CBOR diagnostic
   notation as defined in Section 8 of [RFC8949] and Appendix G of
   [RFC8610].  Diagnostic notation comments are often used to provide a
   textual representation of the numeric parameter names and values.

2.  EAD Item "EDHOC_Exporter Output Lengths"

   This section defines the EDHOC EAD item "EDHOC_Exporter Output
   Lengths", which is registered in Section 5.1 of this document.

   The EAD item MAY be included:

   *  In the EAD_1 field of EDHOC message_1, in order to specify the
      output lengths that the Initiator wishes to use with the
      EDHOC_Exporter interface in the present EDHOC session.

   *  In the EAD_2 field of EDHOC message_2, in order to specify the
      output lengths that the Responder wishes to use with the
      EDHOC_Exporter interface in the present EDHOC session.

   Within an EAD_1 field or EAD_2 field, the EAD item MUST NOT occur
   more than once.  The EAD item MUST NOT be included in the EAD fields
   of EDHOC message_3 or message_4.

   When the EAD item is present, its ead_label TBD_EAD_LABEL MUST be
   used only with negative sign, i.e., the use of the EAD item is always
   critical (see Section 3.8 of [RFC9528]).

   The EAD item MUST specify an ead_value, as a CBOR byte string with
   value the binary representation of a CBOR sequence [RFC8742], namely
   EXP_LEN_SEQ.  As specified below, the CBOR sequence is composed of
   pairs of items, with the order of pairs having no meaning.

   Each pair (X, Y) of the CBOR sequence MUST be as follows.

   *  The first element X is a CBOR unsigned integer, specifying the
      value to use as first argument "exporter_label" when invoking the
      EDHOC_Exporter interface (see Section 4.2.1 of [RFC9528]).

      The unsigned integer value is taken from the 'Label' column of the
      "EDHOC Exporter Labels" registry within the "Ephemeral Diffie-
      Hellman Over COSE (EDHOC)" registry group [EDHOC.Exporter.Labels].

   *  The second element Y is a CBOR unsigned integer, specifying the
      value to use as third argument "length" when invoking the
      EDHOC_Exporter interface using the value specified by X as first
      argument "exporter_label" (see Section 4.2.1 of [RFC9528]).




Tiloca, et al.           Expires 8 January 2026                 [Page 4]

Internet-Draft        EDHOC_Exporter Output Lengths            July 2025


      The value specified by Y MUST be a valid value to use as "length"
      when using the value specified by X as "exporter_label".  For
      example, when X specifies 0 as the "exporter_label" to derive an
      OSCORE Master Secret [RFC8613], Y is required to be not less than
      the "length" default value defined in Appendix A.1 of [RFC9528],
      i.e., the key length (in bytes) of the application AEAD Algorithm
      of the selected cipher suite for the EDHOC session.

   In the EAD item, ead_value MUST NOT specify multiple pairs that
   encode the same unsigned integer value in their first element X.

   The CDDL grammar [RFC8610] describing the ead_value for the EAD item
   "EDHOC_Exporter Output Lengths" is provided in Figure 1.

   ead_value = << EXP_LEN_SEQ >>

   ; This defines an array, the elements of which
   ; are to be used in the CBOR Sequence EXP_LEN_SEQ:
   EXP_LEN_SEQ = [* pair]

   pair = (
     exporter_label: uint,
     length: uint
   )

          Figure 1: CDDL Definition of ead_value for the EAD Item
                      "EDHOC_Exporter Output Lengths"

   An example of ead_value in CBOR diagnostic notation is provided in
   Figure 2.  In the example, ead_value indicates the wish to use the
   EDHOC_Exporter interface to derive an OSCORE Master Secret and an
   OSCORE Master Salt [RFC8613] as per Appendix A.1 of [RFC9528], such
   that:

   *  the OSCORE Master Secret (exporter_label: 0) has a length of 32
      bytes; and

   *  the OSCORE Master Salt (exporter_label: 1) has a length of 16
      bytes.

   << 0, 32, 1, 16 >>

      Figure 2: Example of ead_value for the EAD Item "EDHOC_Exporter
                Output Lengths" in CBOR Diagnostic Notation







Tiloca, et al.           Expires 8 January 2026                 [Page 5]

Internet-Draft        EDHOC_Exporter Output Lengths            July 2025


   That is, assuming the second argument "context" of the EDHOC_Exporter
   interface to be the empty CBOR byte string (i.e., h'' in CBOR
   diagnostic notation), the example above is consistent with performing
   the following two invocations of the EDHOC_Exporter interface:

   EDHOC_Exporter(0, h'', 32)
   EDHOC_Exporter(1, h'', 16)

3.  Processing at the Recipient Side

   In case the recipient peer supports the EAD item, the recipient peer
   MUST silently ignore the EAD item "EDHOC_Exporter Output Lengths" if
   this is specified in the EAD_3 field of EDHOC message_3 or in the
   EAD_4 field of EDHOC message_4.

   Upon receiving an EDHOC message_1 or EDHOC message_2 whose EAD field
   includes the EAD item "EDHOC_Exporter Output Lengths", the recipient
   peer MUST abort the EDHOC session and MUST reply with an EDHOC error
   message with error code (ERR_CODE) 1, if any of the following occurs:

   *  the EAD field includes multiple occurrences of the EAD item
      "EDHOC_Exporter Output Lengths";

   *  ead_value is malformed or does not conform with what is defined in
      Section 2;

   *  the recipient peer does not recognize the value encoded by the
      first element X of a pair (X, Y) as a valid "exporter_label" to be
      used when invoking the EDHOC_Exporter interface;

   *  in a pair (X, Y), the value encoded by the second element Y is not
      valid to be used as "length" when invoking the EDHOC_Exporter
      interface using the value encoded by the first element X as
      "exporter_label"; or

   *  for a pair (X, Y), the recipient peer is not going to be able to
      invoke the EDHOC_Exporter interface using the values encoded by X
      and Y as the first argument "exporter_label" and the third
      argument "length", respectively.

   If the Responder has received an EDHOC message_1 including the EAD
   item "EDHOC_Exporter Output Lengths" and the Responder includes the
   EAD item "EDHOC_Exporter Output Lengths" in EDHOC message_2, then the
   following applies.  Within ead_value of the EAD item included in
   EDHOC message_2, the Responder MUST NOT specify any pair (X, Y) such
   that the unsigned integer value encoded by X was encoded by the first
   element of a pair of the EAD item included in the received EDHOC
   message_1.



Tiloca, et al.           Expires 8 January 2026                 [Page 6]

Internet-Draft        EDHOC_Exporter Output Lengths            July 2025


   If the Initiator receives an EDHOC message_2 including the EAD item
   "EDHOC_Exporter Output Lengths" after having sent an EDHOC message_1
   including the EAD item "EDHOC_Exporter Output Lengths", then the
   following applies.  The Initiator MUST abort the EDHOC session and
   MUST reply with an EDHOC error message with error code (ERR_CODE) 1,
   if ead_value of the EAD item included in EDHOC message_2 specifies
   any pair (X, Y) such that the unsigned integer value encoded by X was
   encoded by the first element of a pair of the EAD item included in
   the sent EDHOC message_1.

   In an EDHOC session during which the EAD item "EDHOC_Exporter Output
   Lengths" has been included in EDHOC message_1 and/or message_2, the
   following applies.

   *  The Initiator (Responder) considers the successful verification of
      EDHOC message_2 (message_3) as a confirmed agreement with the
      other peer about how to invoke the EDHOC_Exporter interface, once
      the session key PRK_out for the present EDHOC session is
      available.

      That is, for each pair (X, Y) specified by the exchanged EAD
      items, the two peers MUST use the unsigned integer values encoded
      by X and Y as the first argument "exporter_label" and the third
      argument "length", respectively.

   *  If a particular "exporter_label" value is not specified by the
      exchanged EAD items, then a possible invocation of the
      EDHOC_Exporter interface using that value as its first argument
      takes as value for its third argument "length" a pre-defined
      default value, or an alternative value agreed out-of-band.

4.  Security Considerations

   The same security considerations for EDHOC from [RFC9528] hold for
   this document.  Furthermore, the following considerations apply.

   TBD

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







Tiloca, et al.           Expires 8 January 2026                 [Page 7]

Internet-Draft        EDHOC_Exporter Output Lengths            July 2025


5.1.  EDHOC External Authorization Data Registry

   IANA is asked to register the following entry in the "EDHOC External
   Authorization Data" registry within the "Ephemeral Diffie-Hellman
   Over COSE (EDHOC)" registry group defined in [RFC9528].

   *  Name: EDHOC_Exporter Output Lengths

   *  Label: TBD_EAD_LABEL (range 0-23)

   *  Description: Set of output lengths to use with the EDHOC_Exporter
      interface

   *  Reference: [RFC-XXXX]

6.  References

6.1.  Normative References

   [EDHOC.Exporter.Labels]
              IANA, "EDHOC Exporter Labels",
              <https://www.iana.org/assignments/edhoc/edhoc.xhtml#edhoc-
              exporter-labels>.

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

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

   [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, et al.           Expires 8 January 2026                 [Page 8]

Internet-Draft        EDHOC_Exporter Output Lengths            July 2025


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

6.2.  Informative References

   [I-D.ietf-lake-edhoc-psk]
              Lopez-Perez, Selander, G., Mattsson, J. P., and R. Marin-
              Lopez, "EDHOC Authenticated with Pre-Shared Keys (PSK)",
              Work in Progress, Internet-Draft, draft-ietf-lake-edhoc-
              psk-04, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lake-
              edhoc-psk-04>.

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

Acknowledgments

   The authors sincerely thank Göran Selander for his comments and
   feedback.

   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-164 40 Kista
   Sweden
   Email: marco.tiloca@ri.se


   Rikard Höglund
   RISE AB
   Isafjordsgatan 22
   SE-164 40 Kista
   Sweden
   Email: rikard.hoglund@ri.se


   Elsa Lopez-Perez
   Inria



Tiloca, et al.           Expires 8 January 2026                 [Page 9]

Internet-Draft        EDHOC_Exporter Output Lengths            July 2025


   Email: elsa.lopez-perez@inria.fr


















































Tiloca, et al.           Expires 8 January 2026                [Page 10]


name: draft-lake-pocero-authkem-edhoc
rev: 00
title: KEM-based Authentication for EDHOC
time: 2025-10-16T14:22:40Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-19T14:22:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014836+00:00
abstract:
This document specifies extensions to the Ephemeral Diffie-Hellman
   over COSE (EDHOC) protocol to provide resistance against quantum
   computer adversaries by incorporating Post-Quantum Cryptography (PQC)
   mechanisms for both key exchange and authentication.  It defines a
   Key Encapsulation Mechanism (KEM)-based authentication method to
   enable signature-free post-quantum authentication when PQC KEMs, such
   as NIST-standardized ML-KEM, are used.

full_text:
individual                                              L. Pocero Fraile
Internet-Draft                                               C. Koulamas
Intended status: Standards Track                          A.P. Fournaris
Expires: 19 April 2026                                     E. Haleplidis
                                                        ISI, R.C. ATHENA
                                                         16 October 2025


                   KEM-based Authentication for EDHOC
                   draft-lake-pocero-authkem-edhoc-00

Abstract

   This document specifies extensions to the Ephemeral Diffie-Hellman
   over COSE (EDHOC) protocol to provide resistance against quantum
   computer adversaries by incorporating Post-Quantum Cryptography (PQC)
   mechanisms for both key exchange and authentication.  It defines a
   Key Encapsulation Mechanism (KEM)-based authentication method to
   enable signature-free post-quantum authentication when PQC KEMs, such
   as NIST-standardized ML-KEM, are used.

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 19 April 2026.

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



Pocero Fraile, et al.     Expires 19 April 2026                 [Page 1]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   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.  Terminology and Requirements Language . . . . . . . . . .   5
       1.2.1.  Key Encapsulation Mechanisms (KEMs) . . . . . . . . .   5
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Protocol Elements . . . . . . . . . . . . . . . . . . . .   8
       2.1.1.  Ephemeral KEM . . . . . . . . . . . . . . . . . . . .   9
       2.1.2.  Authentication Parameters . . . . . . . . . . . . . .   9
         2.1.2.1.  Method  . . . . . . . . . . . . . . . . . . . . .   9
         2.1.2.2.  Authentication Keys . . . . . . . . . . . . . . .  10
         2.1.2.3.  Authentication Credentials  . . . . . . . . . . .  10
         2.1.2.4.  Identification of Credentials . . . . . . . . . .  10
       2.1.3.  Cipher Suites . . . . . . . . . . . . . . . . . . . .  11
   3.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Keys for EDHOC Message Processing . . . . . . . . . . . .  13
       3.1.1.  EDHOC_Extract . . . . . . . . . . . . . . . . . . . .  13
         3.1.1.1.  PRK_2e  . . . . . . . . . . . . . . . . . . . . .  13
         3.1.1.2.  PRK_3e2m  . . . . . . . . . . . . . . . . . . . .  13
         3.1.1.3.  PRK_4e3m  . . . . . . . . . . . . . . . . . . . .  14
       3.1.2.  EDHOC_Expand and EDHOC_KDF  . . . . . . . . . . . . .  15
       3.1.3.  PRK_out . . . . . . . . . . . . . . . . . . . . . . .  15
     3.2.  Keys for EDHOC Applications . . . . . . . . . . . . . . .  16
   4.  Message Formatting and Processing . . . . . . . . . . . . . .  16
     4.1.  KEM-based Authentication EDHOC Message 1  . . . . . . . .  16
       4.1.1.  Formating of Message 1  . . . . . . . . . . . . . . .  16
       4.1.2.  Initiator Composition of Message 1  . . . . . . . . .  16
       4.1.3.  Responder Processing of Message 1 . . . . . . . . . .  17
     4.2.  KEM-based authentication EDHOC Message 2  . . . . . . . .  17
       4.2.1.  Formating of Message 2  . . . . . . . . . . . . . . .  17
       4.2.2.  Responder Composition of Message 2  . . . . . . . . .  17
       4.2.3.  Initiator Processing of Message 2 . . . . . . . . . .  18
     4.3.  KEM-based authentication EDHOC Message 3  . . . . . . . .  19
       4.3.1.  Formating of Message 3  . . . . . . . . . . . . . . .  19
       4.3.2.  Initiator Composition of Message 3  . . . . . . . . .  19
       4.3.3.  Responder Processing of Message 3 . . . . . . . . . .  20
     4.4.  KEM-based authentication EDHOC Message 4  . . . . . . . .  21
       4.4.1.  Formating of Message 4  . . . . . . . . . . . . . . .  21
       4.4.2.  Responder Composition of Message 4  . . . . . . . . .  21
       4.4.3.  Initaitor Processing of Message 4 . . . . . . . . . .  22
     4.5.  KEM-based authentication EDHOC Message 5  . . . . . . . .  23
       4.5.1.  Formating of Message 5  . . . . . . . . . . . . . . .  23
       4.5.2.  Initiator Composition of Message 5  . . . . . . . . .  23



Pocero Fraile, et al.     Expires 19 April 2026                 [Page 2]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


       4.5.3.  Responder Processing of Message 5 . . . . . . . . . .  24
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     5.1.  COSE Algorithms Registry  . . . . . . . . . . . . . . . .  25
     5.2.  EDHOC Cipher Suites Registry  . . . . . . . . . . . . . .  26
     5.3.  EDHOC Method Types Registry . . . . . . . . . . . . . . .  27
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  31
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   The purpose of this document is to address the quantum-resistant
   transition of the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol
   by extending with a new Key Encapsulation Mechanism (KEM)-based
   authentication method and Post-Quantum Cryptography cipher suits.

   The specific protocol is part of a more extensive analysis of the PQ
   transition for the EDHOC protocol, which is currently in the process
   of being published.

1.1.  Motivation

   The emerging Quantum Computing technologies bring new potential risks
   to the existing cryptographic infrastructures.  Security mechanisms
   that rely on integer factorization or the discrete logarithm problem
   will be vulnerable to attacks by a Cryptographically Relevant Quantum
   Computer (CRQC).  The European Commission recently issued a roadmap
   for the transition to Post-Quantum Cryptography (PQC), establishing a
   2030 deadline for high-risk use cases and 2035 for medium-risk use
   cases, in alignment with the 2035 deadline set by the U.S. government
   for completing the transition to PQC in federal systems.

   The U.S.  National Institute of Standards and Technology (NIST) has
   concluded its post-quantum cryptography standardization process with
   the release of its first standardized post-quantum algorithms in
   three new Federal Information Processing Standards (FIPS): FIPS 203
   (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on
   CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+).
   Additionally, FALCON has been selected for future standardization,
   and NIST has launched a new initiative to evaluate alternative post-
   quantum signature schemes with compact signatures and efficient
   verification speeds.  Complementing these efforts, the Post-Quantum
   Use in Protocols (PQUIC) IETF Working Group (WG) is developing
   operational and design guidelines to support the transition.  For
   example, [RFC9794] defines terminology for post-quantum/traditional
   Hybrid schemes, while ongoings draft such as



Pocero Fraile, et al.     Expires 19 April 2026                 [Page 3]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   [I-D.ietf-pquip-pqc-engineers] analyze the impact of CRQCs on
   existing systems and the challenges involved in transitioning to
   post-quantum algorithms.

   The growing urgency to transition to PQC highlights the need to adapt
   EDHOC, whose current security relies on traditional Elliptic-Curve
   Cryptography(ECC), based on the discrete logarithm problem that is
   known to be vulnerable to attacks by CRQCs.  The integration of the
   PQC mechanism into EDHOC raises important considerations around
   performance, as the protocol is explicitly designed for constrained
   environments where the number of handshake message rounds, network
   overhead, processing time, and power consumption are critical
   factors.

   PQC algorithms generally have higher computational and memory costs
   compared to the classical cryptography algorithms they aim to replace
   because they often involve complex calculations and require larger
   byte sizes.  Notably, the PQC digital signature schemes standardized
   by NIST, such as ML-KEM and ML-DSA, use significantly large public
   keys and signatures, which can be difficult to transmit over
   constrained networks.  It is important to note that while FALCON,
   also selected for standardization by NIST, provides much shorter
   signatures than the lattice-based schemes, its current
   implementations have been shown to be vulnerable to side-channel
   attacks.  The new compact schemes under NIST evaluation should be
   more suitable for constrained environments.  However, the current
   Cortex-M4 implementations of some of the most compact PQC signature
   schemes, like SNOVA and MAYO, still demand substantial memory
   resources, making them impractical for many constrained devices.
   Additionally, others, such as SQISign, have only recently been
   supported on such platforms, and performance benchmarks for their
   signature operations are still unavailable.

   On the other hand, the standardized ML-KEM offers significantly
   higher computational efficiency compared to all other PQC KEMs (order
   of magnitude faster) and is at least three times more efficient than
   the fastest PQC signature schemes.  Therefore, extending EDHOC with a
   new authentication method that enables a signature-free KEM-based
   EDHOC has the potential to reduce memory and processing requirements
   when ML-KEM is used.  The approach can also result in lower network
   overhead compared to signature-based EDHOC implementations that rely
   on standardized PQC signature-based algorithms.









Pocero Fraile, et al.     Expires 19 April 2026                 [Page 4]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   Some standardization efforts propose adopting the KEM-based
   authentication mechanism to mitigate the overhead introduced by PQC
   digital signatures.  For example, [I-D.celi-wiggers-tls-authkem]
   specifies a KEM-based authentication scheme for TLS 1.3, while
   [I-D.uri-lake-pquake] aims to define a general Post-Quantum
   Authentication Key exchange protocoll, which based on the same
   approach.

   This document describes a KEM-based authentication mechanism
   specifically for the EDHOC protocol, introducing a new authentication
   method intended to provide a PQC signature-free variant as the static
   DH authentication method intends.  The static-DH authentication of
   EDHOC is based on the XX pattern of the Noise framework protocol
   [Noise], where channel security guarantees are increasingly
   established by encrypting transmitted messages with keys derived from
   chains of shared secrets, as soon as those secrets become available.
   To align with this model, the KEM-based authentication Method defined
   in this document follows the approach outlined in [PQNoise-CCS22],
   which provides a recipe for transforming classical Noise patterns
   into PQ variants.  This specification defines the necessary
   modifications to the EDHOC protocol to support the PQ-Noise framework
   while preserving security properties comparable to those of the
   static-DH authentication method.

1.2.  Terminology and Requirements Language

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

   Readers are expected to be familiar with the terms and concepts
   described in EDHOC [RFC9528], CBOR [RFC8949], CBOR Sequences
   [RFC8742], COSE Structures and Processing [RFC9052] and COSE
   Algorithms [RFC9053], When referring to CBOR, this specification
   always refers to Deterministically Encoded CBOR, as specified in
   Section 4.2.1 and 4.2.2 of [RFC8949].  The single output from
   authenticated encryption (including the authentication tag) is called
   "ciphertext", following [RFC5116].

1.2.1.  Key Encapsulation Mechanisms (KEMs)

   The Key Encapsulation Mechanism consists of 3 algorithms:

   *  *( pk, sk ) <- KEM.KeyGen( )*: The probabilistic key generation
      algorithm generates a KEM key pair consisting of a public
      encapsulation key ( pk ) and secret decapsulation key ( sk ).





Pocero Fraile, et al.     Expires 19 April 2026                 [Page 5]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  *( ss , ct ) <- KEM.Encapsulate( pk )*: The probabilistic
      encapsulation algorithm takes as input a public encapsulation key
      ( pk ) and produces a shared secret ( ss ) and ciphertext ( ct ).

   *  *( ss ) <- KEM.Decapsulate( ct, sk )*: The decapsulation algorithm
      takes as input a secret encacpsulation key ( sk ) and produce a
      shared secret ( ss ).

2.  Protocol Overview

   This document defines a KEM-based authentication method for EDHOC in
   a general scenario where both parties may be mutually unknown.  It
   aims to provide a free-signature authentication scheme as the static
   DH authentication EDHOC method 3 does, which relies on the XX pattern
   from the Noise framework [Noise], supporting mutual authentication
   and the transmission of encrypted public credentials.  The proposed
   protocol adopts the approach provided by [PQNoise-CCS22] to transform
   the classical Noise XX pattern in EDHOC into a PQ Noise XX variant.
   This results in a quantum-resistant, KEM-only version of EDHOC when a
   PQC KEM is used.

   The PQ translation of the Noise XX pattern requires introducing up to
   one additional round trip.  With KEMs, the owner of the static key
   cannot combine their static private key with the ephemeral public key
   belonging to the other party to immediately prove their identity in
   the next message, as is possible with DH.  Instead, the party must
   first receive a ciphertext that encapsulates its static public key,
   generated by the peer, before it can authenticate itself.  This
   necessitates an additional key-confirmation message from the key
   owner, using the key derived from the encapsulated value.

   The KEM-based EDHOC protocol consists of five mandatory messages
   (message_1, message_2, message_3, message_4, and message_5), and an
   error message, between an Initiator (I) and a Responder (R).  Error
   handling and cipher suit negotiation mechanisms are the same as
   defined in Section 6 of [RFC9528].  All EDHOC messages are CBOR
   Sequences as specified in [RFC9528].  Figure 1 illustrates a KEM-
   based authentication EDHOC message flow as well as the content of
   each message.  The protocol elements in Figure 1 are introduced in
   this Section and in Section 4.  Message formatting and processing are
   specified in Section 4










Pocero Fraile, et al.     Expires 19 April 2026                 [Page 6]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   Initiator                                                   Responder
   |               METHOD, SUITES_I, pk_eph, C_I, EAD_1                |
   +------------------------------------------------------------------->
   |                             message_1                             |
   |                                                                   |
   |               ct_eph, Enc( C_R, ID_CRED_R, EAD_2 )                |
   <-------------------------------------------------------------------+
   |                             message_2                             |
   |                                                                   |
   |                   ct_R, Enc( ID_CRED_I, EAD_3 )                   |
   +------------------------------------------------------------------->
   |                             message_3                             |
   |                                                                   |
   |                     ct_I, AEAD( EAD_4, MAC_2 )                    |
   <-------------------------------------------------------------------+
   |                             message_4                             |
   |                                                                   |
   |                         AEAD( EAD_5, MAC_3 )                      |
   +------------------------------------------------------------------->
   |                             message_5                             |

      Figure 1: EDHOC Message Flow using the KEM-based Authentication
                                   Method

   The parties exchange ephemeral and static KEM public keys, along with
   ciphertexts that encapsulate these keys, compute shared secrets and
   pseudorandom keys PRK, and derive symmetric session keys to encrypt
   message elements contained in intermediate handshake messages.  All
   handshake messages include encrypted components protected with these
   derived session keys, offering varying levels of confidentiality and
   authenticity, except for the first message, which is sent in
   plaintext.  The parties compute a shared secret session key, PRK_out,
   from which symmetric application keys are derived to protect
   application data.  The Initiator derives these keys after receiving
   message_4, and the Responder after receiving message_5.

   *  pk_eph is the ephemeral KEM public key generated by the Initiator.

   *  ct_eph is the ephemeral ciphertext computed by the Responder with
      the KEM.encapsulation algorithm over the received ephemeral public
      key (pk_eph).

   *  ct_R is the responder ciphertext computed by the Initiator with
      the KEM.encapsulation algorithm over the static KEM public key of
      the Responder, retrieved from the received ID_CRED_R in message_2.






Pocero Fraile, et al.     Expires 19 April 2026                 [Page 7]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  ct_I is the Iniatiator ciphertext computed by the Responder with
      the KEM.encapsulation algorithm over the static KEM public key of
      the Initiator, retrieved from the received ID_CRED_I in message_1.

   *  "CRED_I and CRED_R are the authentication credentials containing
      the public authentication keys of I and R, respectively", as
      defined in Section 2 of [RFC9528] .

   *  "ID_CRED_I and ID_CRED_R are used to identify and optionally
      transport the credentials of I and R, respectively", as defined in
      Section 2 of [RFC9528].

   *  "Enc(), AEAD(), and MAC() denote encryption, Authenticated
      Encryption with Associated Data, and Message Authentication Code,
      crypto algorithms applied with keys derived from one or more
      shared secrets calculated during the protocol", as defined in
      Section 2 of [RFC9528]

   *  "SUITES_I contains cipher suites supported by the Initiator and
      formatted and processed as specified in Section 3.6 and 6.3.2 of
      [RFC9528]"".

   *  "METHOD is an integer specifying the authentication method",as
      defined in Section 3.2 of [RFC9528].  In this case method 4; see
      Section 2.1.2.1.

   *  C_I and C_R are Connection Identifiers chosen by the Initiator and
      Responder, respectively, as specified in Section 3.3 of [RFC9528]

   *  EAD_1, EAD_2, EAD_3, EAD_4, EAD_5 are External Authorization Data
      included in message_1, message_2, message_3, message_4 and
      message_5 respectively

   This protocol is designed so that it follows the provisions of
   [RFC9528], that is, to encrypt and integrity protect as much
   information as possible and derive symmetric keys and random material
   using EDHOC_KDF with as much previous information as possible

2.1.  Protocol Elements

   This section describes the principal protocol elements that differ
   from the definitions of EDHOC and highlights the most important
   similarities.  For the missing elements, the definitions in Section 3
   of [RFC9528] SHOULD be consulted.







Pocero Fraile, et al.     Expires 19 April 2026                 [Page 8]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


2.1.1.  Ephemeral KEM

   The ephemeral KEM is used to provide forward secrecy.  The Initiator
   generates a new ephemeral KEM key pair in every new session to ensure
   that the compromise of long-term keys does not compromise past
   communications.  The elements of the Ephemeral KEM are:

   *  The ephemeral KEM key pair ( pk_eph, sk_eph ) is generated by the
      Initiator using the following function:

      pk_eph, sk_eph <- KEM.KeyGen()

   *  The ephemeral shared secret ( ss_eph ) and the ephemeral
      ciphertext ( ct_eph ) are generated using the encapsulation and
      decapsulation functions: in the Responder

      ss_eph, ct_eph <-  KEM.Encapsulate( pk_eph )

      in the Initiator

      ss_eph <-  KEM.decapsulation( ct_eph, sk_eph )

2.1.2.  Authentication Parameters

   The protocol performs the same authentication-related operations as
   described in Section 3.5 of [RFC9528]

   The protocol transports information about credentials ID_CRED_I and
   ID_CRED_R in message_2 and message_3, respectively.  The
   authentication of these credentials is verified through MAC_2 and
   MAC_3, sent by the Responder and the Initiator in message_4 and
   message_5, respectively.

2.1.2.1.  Method

   The protocol extends EDHOC with a new KEM-based authentication
   method, where both parties use static KEM key pairs.  The
   authentication is provided by a Message Authentication Code (MAC)
   included in message_4 and message_5 to authenticate the Responder and
   Initiator, respectively.  The Initiator and Responder need to have
   agreed on a method 4.










Pocero Fraile, et al.     Expires 19 April 2026                 [Page 9]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


      +===================+====================+====================+
      | Method Type Value | Initiator          | Responder          |
      |                   | Authentication Key | Authentication Key |
      +===================+====================+====================+
      |                 4 | Static KEM Key     | Static KEM Key     |
      +-------------------+--------------------+--------------------+

               Table 1: Authentication Keys for Method Types

2.1.2.2.  Authentication Keys

   The authentication key MUST be a static KEM authentication key pair.

   *  The Initiator static KEM authentication key pair: ( pk_I, sk_I )

   *  The Responder static KEM authentication key pair: ( pk_R, sk_R )

2.1.2.3.  Authentication Credentials

   The authentication credentials, CRED_I and CRED_R, contain the static
   KEM authentication public key of the Initiator and Responder,
   respectively, as described in Section 3.5.2 of [RFC9528].

   *  The authentication credentials can be X.509 certificates seconded
      as bstr, as defined in Section 3.5.2 of [RFC9528], using
      [RFC9360].  [I-D.ietf-lamps-kyber-certificates] describes the
      conventions for using the ML-KEM in X.509 Public Key
      Infrastructure.

   *  Additionally, the authentication credential may include a
      COSE_key, formatted as specified in [RFC8392], to reduce the
      credential size and avoid the PQC signature verification needed
      when X.509 certificates are used.  New IANA value registries
      should be defined to extend COSE Algorithms with the corresponding
      KEMs algorithm values.

2.1.2.4.  Identification of Credentials

   The ID_CRED fields are used to identify and optionally transport
   credentials as defined in Section 3.5.3 of [RFC9528].  The
   authentication method defined in this document operates within the
   general EDHOC framework described in Section 3.5.3 of [RFC9528],
   where ID_CRED_X can either contain the full CRED_X credentials or an
   identifier of those credentials if they have already been provided
   out-of-band.






Pocero Fraile, et al.     Expires 19 April 2026                [Page 10]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  "ID_CRED_R is intended to facilitate for the Initiator retrieving
      the authentication credential CRED_R and the authentication key of
      R", as defined in Section 3.5.3 of [RFC9528].  For the
      authentication method defined in this document, the authentication
      key is the static KEM public key.

   *  "ID_CRED_I is intended to facilitate for the Responder retrieving
      the authentication credential CRED_I and the authentication key of
      I", as defined in Section 3.5.3 of [RFC9528].  For the
      authentication method defined in this document, the authentication
      key is the static KEM public key.

2.1.3.  Cipher Suites

   The authentication method specified in this document uses the EDHOC
   cipher suites element, as defined in Section 3.6 of [RFC9528].  An
   EDHOC cipher suit consists of an ordered set of algorithms from the
   "COSE Algorithms" IANA registry [RFC9053].  The predefined EDHOC
   cipher suites are also listed in the IANA registry, as specified in
   Section 10.2 of [RFC9528].

   A new predefined cipher suite SHOULD be added to the IANA registry,
   specifying each supported KEM in the EDHOC Key Exchange Algorithm
   parameter.  An example of this, when ML-KEM is used, is shown in
   Section 5.  The same KEM algorithm selected for key exchange SHOULD
   also be used for KEM-based authentication when method 4 is selected.
   Furthermore, the KEM algorithms used SHOULD also be added to the COSE
   Algorithms IANA registry to identify them, as is shown in Section 5.

3.  Key Derivation

   This section highlights the differences and similarities in the key
   derivation process of the KEM-based authentication method compared to
   [RFC9528].  An overview of the EDHOC key schedule when using the KEM-
   based authentication method is shown in Figure 2, and each key
   derivation step is explained in the following subsections.


                    +-------+
                    | TH_2  |
                    +-------+
                     |
          +----+  +--v+  +------+  +---+  +-----+  +-+  +---+
          |ss_e|->|Ext|->|PRK_2e|--|Exp|->|KEY_2|->| |->|C_2|
          +----+  +---+  +--+---+  +--++  +-----+  |X|  +---+
                            |         |  PLAIN_2-->| |
                     +------+         |            +-+
                     |           +--+----------------------+



Pocero Fraile, et al.     Expires 19 April 2026                [Page 11]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


                     |           |TH_2=H(H(Message1),ct_eph|
                     |           +-------------------------+
                     |
          +----+  +--++  +--------+  +---+  +-----+  +-+  +---+
          |ss_R|->|Ext|->|PRK_3e2m|+-|Exp|->|KEY_3|->| |->|C_3|
          +----+  +---+  +---+----+ |+-+-+  +-----+  |X|  +---+
                              |     |   |  PLAIN_3-->| |
                              |     |   |            +-+
                     +--------+     | +--+--------------------+
                     |              | |TH_3=                  |
                                    | |  H(TH_2,PLAINTEXT_2,  |
                                    | |  CRED_R,ct_R|         |
                     |              | +-----------------------+
                     |              |
                     |              |  +------+  +-----+
                     |              +--|Expand|->|MAC_2|
                     |                 +-+----+  +-----+
                     |                   |
                     |   +---------------+--------------------+
                     |   |TH_4=H(TH_3,PLAINTEXT_3,CRED_I,ct_I)|
                     |   +------------------+-----------------+
                     |                      |
          +----+  +--+-+  +--------+ +---+  +---+  +----+  +---+
          |ss_I|->|Ext|->|PRK_4e3m|+-|Exp|->|K_4|->|AEAD|->|C_4|
          +----+  +----+  +--------+|+---+ |+---+ |+-^--+  +---+
                                    |       |     |  |
                                    |       |     | PLAINTEXT_4
                                    |       |     |+----+  +---+
                                    |       |     -|AEAD|->|C_5|
          +------------------------+|       |      +-^--+  +---+
          |TH_5=H(TH_4,PLAINTEXT_4)||       |        |
          +--+---------------------+|       |       PLAINTEXT_5
                              |     |       |
                +-----+   +-+----+  |       |
                |MAC_3|<--|Expand|--|       |
                +-----+   +------+          |   +-------+
                                            |-->|PRK_out|
                                                +--+----+
                                                   |
                                                +--v---+
                                                |Expand|
                                                +------+
                                                   |
                                                   v
                                              +------------+
                                              |PRK_exporter|
                                              +---+--------+
                                                  |



Pocero Fraile, et al.     Expires 19 April 2026                [Page 12]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


                                               +--v---+
                                               |Expand|
                                               +--+---+
                                                  |
                                                  v
                                            Aplication Key

         Figure 2: EDHOC Message Key Derivation using the KEM-based
                           Authentication Method

3.1.  Keys for EDHOC Message Processing

3.1.1.  EDHOC_Extract

   The pseudorandom keys (PRKs) used for KEM-based authentication are
   derived using the same EDHOC_Extract function defined in [RFC9528],
   where the input keying material (IKM) and Salt are specified for each
   PRK below.

3.1.1.1.  PRK_2e

   The pseudorandom key PRK_2e is derived with the following input:

   *  The salt SHALL be TH_2.

   *  The IKM SHALL be the ephemeral KEM shared secret (ss_eph)

   When SHA-256 is used PRK_2e is produced as follows:

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

   Where the ephemeral shared secret ss_eph is the output of the
   following functions in the Initiator and Responder respectively

   Initiator:

   ss_eph <-  KEM.Decapsulate( ct_eph, sk_eph )

   Responder:

   ss_eph, ct_eph <-  KEM.Encapsulate( pk_eph )

3.1.1.2.  PRK_3e2m

   The pseudorandom key PRK_3e2m is derived with the following input:

   *  The salt SHALL be the SALT_3e2m derived from PRK_2e




Pocero Fraile, et al.     Expires 19 April 2026                [Page 13]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  The IKM SHALL be the KEM shared secret ss_R, used to authenticate
      the Responder

   PRk_3e2m is derived as follows:

   PRK_3e2m = EDHOC_Extract( SALT_3e2m, ss_R )

   Where the KEM shared secret ss_R used to authenticate the Responder
   is the output of the following functions in the Initiator and
   Responder, respectively

   Initiator:

   ss_R, ct_R <-  KEM.Encapsulate( pk_R )

   Responder:

   ss_R <-  KEM.Decapsulate( ct_R, sk_R )

3.1.1.3.  PRK_4e3m

   The pseudorandom key PRK_4e3m is derived with the following input:

   *  The salt SHALL be the SALT_4e3m, derived from PRK_3e2m

   *  The IKM SHALL be the KEM shared secret ss_I, used to authenticate
      the Initiator

   PRk_4e3m is derived as follows:

   PRK_4e3m = EDHOC_Extract( SALT_4e3m, ss_I )

   Where the KEM shared secret ss_I used to authenticate the Initiator
   is the output of the following functions in the Initiator and
   Responder, respectively

   Initiator:

   ss_I <-  KEM.Decapsulate( ct_I, sk_I )

   Responder:

   ss_I, ct_I <-  KEM.Encapsulate( pk_I )








Pocero Fraile, et al.     Expires 19 April 2026                [Page 14]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


3.1.2.  EDHOC_Expand and EDHOC_KDF

   The output key materials (OKMs) are derived from the PRKs in the same
   way as described in Section 4.1.2 of [RFC9528], with modifications in
   the transcript hashes THs input contraction as specified in
   Section 4.

   The same OKMs, including keys, initialization vectors (IV), and salts
   as those shows in Section 4.1.2 of [RFC9528] Figure 6 are derived,
   with one exception:

   *  KEYSTREAM_3 is computed instead K3/IV3 because the derived key at
      this stage can not yet be used to authenticate the Initiator in
      message_2.

   The final key derivations using EDHOC_KDF is shwon in Figure 3 .
   Further details of the key derivation and how the output keying
   material is used are specified in Section 4

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

        Figure 3: Key Derivations Using EDHOC_KDF for the KEM-based
                           Authentication Method

   Notice that a new key session (K_5/IV_5) can be derived from the same
   PRK_4e3m, using Th_5 as the info parameter, to encrypt message_5, if
   separate keys are shown to enhance security in any way.  The initial
   version of this protocol adopts a simpler approach by deriving a
   single session key to protect both messages, which are different from
   the MAC keys.

3.1.3.  PRK_out

   The pseudorandom key PRK_out is the output session key of a completed
   EDHOC session and is derived as follows:

   PRK_out = EDHOC_KDF( PRK_4e3m, TH_4, hash_length )





Pocero Fraile, et al.     Expires 19 April 2026                [Page 15]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


3.2.  Keys for EDHOC Applications

   Keying material for the application can be derived using the same
   EDHOC_Exporter interface defined in Section 4.2.1 of [RFC9528]

4.  Message Formatting and Processing

   This section outlines the message format and the procedures for
   composing and processing each message.

4.1.  KEM-based Authentication EDHOC Message 1

4.1.1.  Formating of Message 1

   message_1 retains the same format as defined in Section 5.2.1 of
   [RFC9528].  The same fields are used, except that GX is replaced by
   the KEM ephemeral public key ( pk_eph ) computed by the Initiator.

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

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

   The new KEM-based authentication method (method 4) shoould be
   seletect in the METHOD field.

4.1.2.  Initiator Composition of Message 1

   The Initiator SHALL compose message_1 as follows:

   *  Construct SUITES_I following the Section 5.2.2 of [RFC9528]
      specifications

   *  Generate an ephemeral KEM Key pair (pk_eph) using the KEM
      algorithm from the selected cipher suit.  The ephemeral key pair
      is computed by the Initiator using the following function:

      pk_eph, sk_eph <-  KEM.KeyGen()

   *  Choose a conection identifier as in Section 5.2.2 of [RFC9528].





Pocero Fraile, et al.     Expires 19 April 2026                [Page 16]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Encode message_1 as sequence of CBOR-encoded elements, as
      specified in Section 4.1.1

4.1.3.  Responder Processing of Message 1

   The Responder SHALL process message_1 in the following order:

   1.  "Decode message_1", as specified in Section 5.2.3 of [RFC9528]

   2.  "Process message_1", as specify in Section 5.2.3 of [RFC9528]

   3.  "If all processing is completed successfully, and if EAD_1 is
       present, then make it available to the application", as specified
       in Section 5.2.3 of [RFC9528]

4.2.  KEM-based authentication EDHOC Message 2

4.2.1.  Formating of Message 2

   message_2 keeps the same formatting as Section 5.3.1 of [RFC9528].
   The same fields are used instead GY is replaced with the ephemeral
   KEM ciphertext ( ct_eph ) computed on the Responder..

   message_2 = (
     ct_eph_CIPHERTEXT_2 : bstr,
   )

   where cc_eph_CIPHERTEXT_2 is the concatenation of ct_eph and
   CIPHERTEXT_2.

4.2.2.  Responder Composition of Message 2

   The Responder SHALL compose message_2 as follows:

   *  Encapsulate the ephemeral KEM key received within message_1 using
      the KEM algorithm in the selected cipher suit.  The ephemeral KEM
      ciphertext and the KEM ephemeral shared secret are computed by the
      Responder using the following function:

       ss_eph, ct_eph <-  KEM.Encapsulate(pk_eph)

   *  Compute the PRK_2e pseudorandom key from the ephemeral KEM shared
      secret ( ss_eph )

   *  "Choose a connection identifier C_R", as specified in
      Section 5.3.2 of [RFC9528]





Pocero Fraile, et al.     Expires 19 April 2026                [Page 17]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Compute the transcript hash TH_2 = H(pk_eph,H(message_1)) as
      specified in Section 5.3.2 of [RFC9528]

   *  At this point, the Responder is not jet able to authenticate
      itself, so MAC_2 is not computed

   *  CIPHERTEXT_2 is calculated, with a binary additive stream cipher
      as in Section 5.3.2 of [RFC9528], using a keystream (KEYSTREAM_2)
      generated with EDHOC_Expand and the following plaintext:

      -  Compute PLAINTEXT_2 as:

            PLAINTEXT_2 = (C_R,ID_CRED_R,?EAD_2)

         where C_R, ID_CRED_R and EAD_2 elements corresponds with the
         ones in Section 5.3.2 of [RFC9528].

      -  Compute KEYSTREAM_2 as in Section 3.1.2

      -  Compute CIPHERTEXT_2 as in Section 5.3.2 of [RFC9528]

         CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2

   *  Encode message_2 as a sequence of CBOR-encoded data items as
      specified in Section 4.2.1

4.2.3.  Initiator Processing of Message 2

   The Initiator SHALL process message_2 in the following order:

   1.   Decode message_2

   2.   "Retrieve the protocol state" as proposed in Section 5.3.3 of
        [RFC9528]

   3.   Compute the ephemeral KEM shared_secret ( ss_eph ) by
        decapsulating the KEM ciphertext ( ct_eph ) received in
        message_2 using the ephemeral secret key ( sk_eph ).  The
        ephemeral KEM shared secret is computed by the Initiator using
        the following function:

       ss_eph <-  KEM.Decapsulate( ct_eph, sk_eph )

   4.   Compute the PRK_2e pseudorandom key from the ephemeral KEM
        shared secret ( ss_eph )

   5.   Compute the transcript hash TH_2 = H(pk_eph,H(message_1))




Pocero Fraile, et al.     Expires 19 April 2026                [Page 18]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   6.   Derive KEYSTREAM_2 as in Section 3.1.2

   7.   Decrypt CIPHERTEXT_2; see Section 4.2.2

   8.   If all processing is completed successfully, then make ID_CRED_R
        and (if present) EAD_2 available to the application as in
        Section 5.3.3 of [RFC9528]

   9.   Obtain the authentication credential (CRED_R) from the
        (ID_CRED_R) as in Section 5.3.3 of [RFC9528], and the static KEM
        authentication key (pk_R) of the Responder

   10.  Encapsulate the retrieved static KEM authentication key of the
        Responder ( pk_R ) calculating the corresponding ciphertext (
        ct_R ) and shared secret ( ss_R ) with the following function:

       ss_R, ct_R <-  KEM.Encapsulate(pk_R)

   11.  Compute the new PRK_3e2m from a chain that includes both the
        ephemeral KEM shared secret ( ss_eph ) and the latest KEM shared
        secret for the Authentication of the Responder ( ss_R ), as
        defined in Section 3.1.1.2

4.3.  KEM-based authentication EDHOC Message 3

4.3.1.  Formating of Message 3

   message_3 SHALL be a CBOR Sequence as defined below:

   message_3 = (
     ct_R : bstr,
     CIPHERTEXT_3 : bstr,
   )

4.3.2.  Initiator Composition of Message 3

   The Initiator SHALL process the composition of message_3 as follows:

   *  Compute the transcript hash TH_3=H(ct_R,TH_2,PLAINTEXT_2,CRED_R)
      as specified in Section 5.4.2 of [RFC9528].

   *  Derive the new session key KEYSTREAM_3 as defined in
      Section 3.1.2.  The Initiator can use this key to compute
      CIPHERTEXT_3, but it cannot be used to authenticate itself.

   *  At this point, the Responder is not jet able to authenticate
      itself, so MAC_3 is not computed.




Pocero Fraile, et al.     Expires 19 April 2026                [Page 19]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  CIPHERTEXT_3 is calculated with a binary additive stream cipher,
      using a keystream (KEYSTREAM_3) generated with EDHOC_Expand and
      the following plaintext:

      -  Compute PLAINTEXT_3 as:

            PLAINTEXT_3 = (C_I,ID_CRED_I,?EAD_3)

         where C_I, ID_CRED_I and EAD_3 elements corresponds with the
         ones in Section 5.3.3 of [RFC9528].

      -  Compute KEYSTREAM_3 as in Section 3.1.2, where plaintext_length
         is the length of PLAINTEXT_3

      -  Compute CIPHERTEXT_3 as follows:

         CIPHERTEXT_3 = PLAINTEXT_3 XOR KEYSTREAM_3

   *  Encode message_3 as a CBOR data item as specified in Section 4.3.1

4.3.3.  Responder Processing of Message 3

   The Responder SHALL process message_3 in the following order:

   1.  Decode message_3

   2.  "Retrieve the protocol state", as defined in Section 5.4.3 of
       [RFC9528]

   3.  Compute the KEM shared_secret ( ss_R ) for the authentication of
       the Responder by decapsulating the KEM ciphertext ( ct_R )
       received in message_3 using the Responder static KEM secret key (
       sk_R ).  The KEM shared secret is computed by the Responder using
       the following function:

       ss_R <-  KEM.Decapsulate( ct_R, sk_R )

   4.  Compute the new PRK_3e2m from a chain that includes both the
       ephemeral KEM shared secret ( ss_eph ) and the latest KEM shared
       secret for the Authentication of the Responder ( ss_R ), as
       defined in Section 3.1.1.2

   5.  Compute the transcript hash TH_3=H(ct_R,TH_2,PLAINTEXT_2,CRED_R)

   6.  Compute KEYSTREAM_3 as in Section 3.1.2, where plaintext_length
       is the length of PLAINTEXT_3

   7.  Decrypt CIPHERTEXT_3; see Section 4.3.2



Pocero Fraile, et al.     Expires 19 April 2026                [Page 20]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   8.  "If all processing is completed successfully, then make ID_CRED_I
       and (if present) EAD_2 available to the application", as in
       Section 5.3.4 of [RFC9528]

   9.  "Obtain the authentication credential (CRED_I) from the
       (ID_CRED_I)" as in Section 5.3.4 of [RFC9528] and the static KEM
       authentication key (pk_I) of the Initiator.

4.4.  KEM-based authentication EDHOC Message 4

4.4.1.  Formating of Message 4

   message_4 SHALL be a CBOR Sequence as defined below:

   message_3 = (
     ct_I : bstr,
     CIPHERTEXT_4 : bstr,
   )

4.4.2.  Responder Composition of Message 4

   The Responder SHALL process the composition of message_4 as follows:

   *  Compute the transcript hash TH_4 = H(ct_I,TH_3, PLAINTEXT_3,
      CRED_I)

   *  Compute MAC_2 as defined in Section 3.1.2, with context_2 =<< C_R,
      ID_CRED_R, TH_4, CRED_R, ? EAD_4 >>

      -  The Responder authenticates with a PRK_3e2m derived from the
         KEM ephemeral shared secret and with the shared secret computed
         over its static KEM key.

      -  The mac_lenght_2 is equal to the EDHOC MAC length of the
         selected cipher suit.

      -  The C_R, ID_CRED_R and CRED_R elements corresponds with the
         ones in Section 5.3.2 of [RFC9528]

      -  The latest transcript hash TH_4 and the External Application
         Data included in Message 4 (EAD_4) are used.

   *  Encapsulate the retrieved static KEM authentication key of the
      Initiator ( pk_I ) calculating the corresponding ciphertext ( ct_I
      ) and shared secret ( ss_I ) with the following function:

       ss_I, ct_I <-  KEM.Encapsulate(pk_I)




Pocero Fraile, et al.     Expires 19 April 2026                [Page 21]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Compute the new PRK_4e3m from a chain that includes the ephemeral
      KEM shared secret ( ss_eph ), the KEM shared secret for the
      Authentication of the Responder ( ss_R ) , and the latest KEM
      shared secret for the Authentication of the Initiator ( ss_I ) as
      defined in Section 3.1.1.3

   *  Derive the session key K_4/IV4 as in Section 3.1.2.

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

      -  protected = h''

      -  external_aad = TH_4

      -  K_4 and IV_4 are defined in Section 3.1.2

      -  PLAINTEXT_4 = ( MAC_2, ?EAD_4 )

      CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.

   *  Compute the transcript hash TH_5 = H(TH_4, PLAINTEXT_4)

   *  Encode message_4 as a CBOR data item as specified in Section 4.4.1

4.4.3.  Initaitor Processing of Message 4

   The Initiator SHALL process message_4 in the following order:

   1.  Decode message_4

   2.  "Retrieve the protocol state using available message
       correlation", as in Section 3.4.2 of [RFC9528].

   3.  Compute the KEM shared secret ( ss_I ) for the authentication of
       the Initiator by decapsulating the KEM ciphertext ( ct_I )
       received in message_4 using the Responder static KEM secret key (
       sk_I ).  The KEM shared secret is computed by the Initiator using
       the following function:

       ss_I <-  KEM.Decapsulate( ct_I, sk_I )

   4.  Compute the transcript hash TH_4 = H(ct_I,TH_3, PLAINTEXT_3,
       CRED_I)




Pocero Fraile, et al.     Expires 19 April 2026                [Page 22]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   5.  Compute the new PRK_4e3m from a chain that includes the ephemeral
       KEM shared secret ( ss_eph ), the KEM shared secret for the
       Authentication of the Responder ( ss_R ), and the latest KEM
       shared secret for the Authentication of the Initiator ( ss_I ) as
       defined in Section 3.1.1.3

   6.  Derive the session key K_4/IV4 as in Section 3.1.2.

   7.  Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_4) as defined
       Section 5.2 and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm
       in the selected cipher suite and the parameters defined in
       Section 4.4.2.

   8.  Verify MAC_2 as defined in Section 4.4.2, and make the result of
       the verification available to the application.

4.5.  KEM-based authentication EDHOC Message 5

4.5.1.  Formating of Message 5

   message_5 SHALL be a CBOR Sequence as defined below:

   message_3 = (
     CIPHERTEXT_5 : bstr,
   )

4.5.2.  Initiator Composition of Message 5

   The Responder SHALL process the composition of message_5 as follows:

   *  Compute the transcript hash TH_5 = H(TH_4, PLAINTEXT_4)

   *  Compute MAC_3 as defined in Section 3.1.2, with context_3 =<< C_I,
      ID_CRED_I, TH_5, CRED_I, ? EAD_5 >>

      -  The Initiator authenticates with a PRK_4e3m derived from the
         three shared secrets, including the shared secret computed over
         its static KEM key ( ss_I ).

      -  The mac_lenght_3 is equal to the EDHOC MAC length of the
         selected cipher suit.

      -  The C_I, ID_CRED_I and CRED_I elements corresponds with the
         ones in Section 5.4.2 of [RFC9528]

      -  The latest transcript hash TH_5 and the External Application
         Data included on Message 5 (EAD_5) are used.




Pocero Fraile, et al.     Expires 19 April 2026                [Page 23]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Compute a COSE_Encrypt0 object as defined inSection 5.2 and 5.3 of
      [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_4, the initialization vector
      IV_4 (if used by the AEAD algorithm), the plaintext PLAINTEXT_5,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_5

      -  K_5 and IV_5 are defined in Section 3.1.2

      -  PLAINTEXT_5 = ( MAC_3, ?EAD_5 )

      CIPHERTEXT_5 is the 'ciphertext' of COSE_Encrypt0.

   *  Calculate PRK_out as defined in Section 3.1.3.  The Initiator can
      now derive application keys using the EDHOC_Exporter interface;
      see Section 3.2

   *  Encode message_5 as a CBOR data item as specified in Section 4.5.1

   *  "Make the connection identifiers (C_I and C_R) and the application
      algorithms in the selected cipher suite available to the
      application" as in Section 5.4.2 of [RFC9528]

   After creating message_5, the Initiator can compute PRK_out and
   derive application keys using the EDHOC_Exporter interface.  The
   Initiator SHOULD now persistently store PRK_out or application keys
   and send protected application data, since it has already verified
   message_4, which is protected with a derived application key by the
   Responder, and the application has authenticated the Responder.

4.5.3.  Responder Processing of Message 5

   The Initiator SHALL process message_5 in the following order:

   1.  Decode message_5

   2.  "Retrieve the protocol state using available message correlation"
       as in Section 3.4.2 of [RFC9528].

   3.  Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_5) as defined in
       Section 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm
       in the selected cipher suite and the parameters defined in
       Section 4.5.2.





Pocero Fraile, et al.     Expires 19 April 2026                [Page 24]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   4.  Verify MAC_3 as defined in Section 4.5.2, and make the result of
       the verification available to the application.

   5.  Calculate PRK_out as defined in Section 3.1.3.  The Initiator can
       now derive application keys using the EDHOC_Exporter interface;
       see Section 3.2

   After verifying message_5, the Responder can compute PRK_out and
   derive application keys using the EDHOC_Exporter interface.  The
   Responder SHOULD now persistently store PRK_out or application keys
   and send protected application data, since it has already verified
   message_5, which is protected with a derived application key by the
   Initiator, and the application has authenticated the Initiator.

5.  IANA Considerations

5.1.  COSE Algorithms Registry

   The "COSE Algorithms" Registry from "CBOR Object Signing and
   Encryption (COSE)" group SHOULD be extended with new values to
   include PQC KEM algorithms.  The extension of values from the
   "Standards Action with Expert Review" range for ML-KEM algorithms at
   NIST security levels 1 and 3, is proposed in Table 2

   Registry Name:  COSE Algorithms

   Reference:  draft-lake-pocero-authkem-edhoc-00

   The columns of the registry are Name, Value, Description,
   Capabilities, Change Controller, Reference and Recommended, where
   Value is an integer and the other columns are text strings.  The new
   values proposed are:



















Pocero Fraile, et al.     Expires 19 April 2026                [Page 25]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


    +============+=======+================+============+==============+
    | Name       | Value | Description    | Change     | Reference    |
    |            |       |                | Controller |              |
    +============+=======+================+============+==============+
    | Unassigned | -256  |                |            |              |
    |            | to    |                |            |              |
    |            | -56   |                |            |              |
    +------------+-------+----------------+------------+--------------+
    | ML-KEM-512 | -54   | CBOR object    | IETF       | [draft-lake- |
    |            |       | KEM Algorithm  |            | pocero-      |
    |            |       | for ML-KEM-512 |            | authkem-     |
    |            |       |                |            | edhoc-00]    |
    +------------+-------+----------------+------------+--------------+
    | ML-        | -55   | CBOR object    | IETF       | [draft-lake- |
    | KEM-1024   |       | KEM Algorithm  |            | pocero-      |
    |            |       | for ML-        |            | authkem-     |
    |            |       | KEM-1024       |            | edhoc-00]    |
    +------------+-------+----------------+------------+--------------+

                          Table 2: COSE Algorithms

5.2.  EDHOC Cipher Suites Registry

   The "EDHOC Cipher Suites" Registry from group "Ephemeral Diffie-
   Hellman Over COSE (EDHOC)" SHOULD be extended with new values to
   include the cipher suits with the KEM algorithm used.  While the KEM-
   based authentication protocol specified in this document can support
   different KEM algorithms, the NIST-standardized ML-KEM is
   RECOMMENDED.  The extension of values from the "Standards Action with
   Expert Review" range, when the ML-KEM algorithm is used at NIST
   security levels 1 and 3, is proposed in Table 3

   Registry Name:  EDHOC Cipher Suites

   Reference:  draft-lake-pocero-authkem-edhoc-00

   The columns of the registry are Value, Array, Description, and
   Reference, where Value is an integer and the other columns are text
   strings.  The new values proposed are:












Pocero Fraile, et al.     Expires 19 April 2026                [Page 26]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


     +============+===========+========================+=============+
     | Value      | Array     | Description            | Reference   |
     +============+===========+========================+=============+
     | 7          | 30, -16,  | AES-CCM-16-128-128,    | draft-lake- |
     |            | 16, , -48 | SHA-256, 16, ML-KEM-   | pocero-     |
     |            | , 10, -16 | 512, ML-DSA-44, AES-   | authkem-    |
     |            |           | CCM-16-64-128, SHA-256 | edhoc-00    |
     +------------+-----------+------------------------+-------------+
     | 8          | 10, -16,  | A256GCM, SHA-384, 16,  | draft-lake- |
     |            | 8, 1, ,   | ML-KEM-1024, ML-DSA-   | pocero-     |
     |            | -49 , -16 | 65, A256GCM, SHA-384   | authkem-    |
     |            |           |                        | edhoc-00    |
     +------------+-----------+------------------------+-------------+
     | Unassigned | 9 to 22   |                        |             |
     +------------+-----------+------------------------+-------------+

                        Table 3: EDHOC Cipher Suites

   The PQC ML-DSA signature algorithms are selected as the EDHOC
   signature algorithm parameter to verify X.509 certificate signatures
   when the X.509 credential type is used.

5.3.  EDHOC Method Types Registry

   The "EDHOC Method Types" Registry from group "Ephemeral Diffie-
   Hellman Over COSE (EDHOC)" SHOULD be extended with a new value that
   identifies the KEM-based authentication method.  The extension value
   from the "Standards Action with Expert Review" range, is proposed in
   Table 3

   Registry Name:  EDHOC Method Types

   Reference:  draft-lake-pocero-authkem-edhoc-00

   The columns of the registry are Value, Initiator Authentication Key,
   Responder Authentication Key and Reference, where Value is an integer
   and the other columns are text strings.  The new value proposed is:














Pocero Fraile, et al.     Expires 19 April 2026                [Page 27]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   +=======+====================+====================+=================+
   | Value | Initiator          | Responder          | Reference       |
   |       | Authentication Key | Authentication     |                 |
   |       |                    | Key                |                 |
   +=======+====================+====================+=================+
   | 4     | Static KEM Key     | Static KEM Key     | [draft-lake-    |
   |       |                    |                    | pocero-authkem- |
   |       |                    |                    | edhoc-00]       |
   +-------+--------------------+--------------------+-----------------+

                        Table 4: EDHOC Method Types

6.  Security Considerations

   EDHOC protocol with static DH keys enables the Initiator and
   Responder to generate an ephemeral-static shared secret using the
   other party's ephemeral public keys and their own credentials.  This
   shared secret is then used to derive a session key for
   authentication.  Messages 2 and 3 provide explicit authentication
   through MACs, which also bind the exchanged credentials to prevent
   misbinding attacks, as is described in Section 9.1 of [RFC9528]

   In contrast, the KEM-based authentication mechanism requires an
   initial action from the other party.  The Responder must first
   receive the encapsulation of its static public key generated by the
   Initiator to authenticate itself.  To perform this encapsulation, the
   Initiator must retrieve the static KEM public key of the Responder
   from the ID_CRED_R sent in Message 2.  As a result, the Responder
   cannot authenticate itself until Message 3 is processed, which
   contains the ct_R ciphertext necessary to derive the ss_R shared
   secret.  Then it cannot generate MAC_2 or authenticate itself until
   then.  Similarly, the Initiator cannot generate MAC_3 or authenticate
   itself before sending Message 3.  This highlights the main challenge
   in integrating KEM-based authentication method within the EDHOC
   handshake.
















Pocero Fraile, et al.     Expires 19 April 2026                [Page 28]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   To address this issue and maintain a level of identity protection,
   against active attacks on the Initiator and passive attacks on the
   Responder, the credentials continue to be sent encrypted in Messages
   2 and 3.  The credentials of the Initiator ( ID_CRED_I ) are
   encrypted using a key derived from both ephemeral KEM shared secret
   (ss_eph) and the Responder static KEM shared secret ( ss_R ), used to
   authenticate the Responder.  At this stage, the specific encryption
   provided a form of weak forward secrecy, as the static KEM public key
   of the Responder has not yet been verified by the Initiator.
   However, the credentials are still protected against active attacks,
   as only the legitimate Responder, who possesses the corresponding
   private key ( sk_R ) is capable of deriving the session key and
   decrypting message_3.

   Additionally the protocol is extended with two additional messages
   (Messages 4 and 5) to enable both parties to:

   *  Prove possession of the final session key, ensuring key
      confirmation to the other party

   *  Ensure mutual authentication by explicitly authenticating
      themselves using the final session key, which incorporates all
      three shared secrets: the ephemeral KEM shared secret ( ss_eph )
      and the KEM shared secrets ss_I and ss_R used to authenticate the
      Initiator and Responder, respectively.

   *  Provide credential binding by including MAC_2 and MAC_3, ensuring
      the integrity and authenticity of the credentials exchanged in
      messages 2 and 3.

   In [RFC9528], the transcript hashes (THs) are constructed as an
   accumulative hash, combining previous TH values with the current
   plain-text message.  Each new plain-text message in the handshake is
   concatenated with the previous TH value, and the resulting hash forms
   the new TH.  This process links each message in the sequence to all
   prior messages, creating a verifiable and continuous chain.  As a
   result, any changes to the message content are detected during
   subsequent integrity verification using the transcript hashes.  The
   KEM-based authentication method described in this document extends
   this approach.  Both parties only need to verify the integrity and
   authenticity of the latest TH_4 and TH_5, which encompass all
   previous messages in the handshake.  To facilitate this, the MAC-
   protected data in Messages 4 and 5 is modified to include TH_4 and
   TH_5 respectively.  At the end of the handshake, both the Initiator
   and Responder can verify the integrity and authenticity of the entire
   handshake by checking the received MACs.





Pocero Fraile, et al.     Expires 19 April 2026                [Page 29]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   The payload security properties for the static DH authentication
   method and the KEM-based authentication method differ during the
   handshake.  Unlike the static DH authentication method, the KEM-based
   method exhibits no authentication until the final two messages.  It
   provides the same level of destination confidentiality for the first
   two and the last two messages, while message_3 offers weaker forward
   secrecy.  The Initiator’s credentials are encrypted within message_3
   using a key derived from the Responder’s static public key and the
   ephemeral key, ensuring that only the intended Responder can decrypt
   the credential, and protect them against active attacks.

   Full forward secrecy and explicit mutual authentication are achieved
   once the KEM-based method handshake is completed, similar to the
   static-DH method handshake (described in Section 9.1 of [RFC9528]).
   Additionally, a potential misbinding attack will not be detected
   until the handshake concludes, specifically when the Initiator
   verifies Message 4 and the Responder verifies Message 5.  Therefore,
   EAD data should be treated as unprotected, and keying materials
   should not be persistently stored until the protocol is complete, as
   with the static-DH method (described in Section 9.1 of [RFC9528]).
   The final Application Session Key should only be derived at the end
   of the handshake, after ensuring mutual authentication, message
   handshake integrity, credentials authenticity, and proof of key
   possession.

   Regarding non-repudiation, the KEM-based authnetication method
   provides the same implicit proof as EDHOC with static DH keys.  It
   also maintains an equivalent level of downgrade protection, as the
   negotiation base of the protocol is unchanged.

   The proposed KEM-based authentication method with a 5-message
   handshake is designed to meet the same security requirements as
   static-DH method.  However, it can be adapted to reduce the number of
   round trips while remaining suitable for scenarios where neither
   party knows the other beforehand.  This is achieved by transmitting
   the ID_CRED_I credentials of the Initiator in plain-text within the
   message_1, similar to the Noise IX pattern, where the Initiator's
   static key is immediately transmitted to the Responder, despite or
   absent identity protection.  This modification allows the Initiator
   to authenticate itself in Message 2, eliminating the need for Message
   5.  Since the Responder includes its credentials in the first
   message, Message 4 remains necessary to ensure explicit
   authentication of the Responder.  This adaptation reduces the message
   exchange to four but sacrifices identity protection for the
   Initiator's credentials.

7.  References




Pocero Fraile, et al.     Expires 19 April 2026                [Page 30]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


7.1.  Normative References

   [I-D.ietf-lamps-kyber-certificates]
              Turner, S., Kampanakis, P., Massimo, J., and B.
              Westerbaan, "Internet X.509 Public Key Infrastructure -
              Algorithm Identifiers for the Module-Lattice-Based Key-
              Encapsulation Mechanism (ML-KEM)", Work in Progress,
              Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22
              July 2025, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lamps-kyber-certificates-11>.

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

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

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

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

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/info/rfc9052>.

   [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Header Parameters for Carrying and Referencing X.509
              Certificates", RFC 9360, DOI 10.17487/RFC9360, February
              2023, <https://www.rfc-editor.org/info/rfc9360>.

   [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/info/rfc9528>.

7.2.  Informative References

   [I-D.celi-wiggers-tls-authkem]
              Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
              Sullivan, "KEM-based Authentication for TLS 1.3", Work in



Pocero Fraile, et al.     Expires 19 April 2026                [Page 31]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


              Progress, Internet-Draft, draft-celi-wiggers-tls-authkem-
              05, 22 April 2025, <https://datatracker.ietf.org/doc/html/
              draft-celi-wiggers-tls-authkem-05>.

   [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-14, 25 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-14>.

   [I-D.uri-lake-pquake]
              Blumenthal, U., Luo, B., O'Melia, S., Torres, G., and D.
              A. Wilson, "PQuAKE - Post-Quantum Authenticated Key
              Exchange", Work in Progress, Internet-Draft, draft-uri-
              lake-pquake-00, 22 April 2025,
              <https://datatracker.ietf.org/doc/html/draft-uri-lake-
              pquake-00>.

   [Noise]    Perrin, T., "The Noise Protocol Framework", Revision 34,
              July 2018, <https://noiseprotocol.org/noise.html>.

   [PQNoise-CCS22]
              Angel, Y., Dowling, B., Hulsing, A., Schwabe, P., and F.
              Weber, "Post Quantum Noise", Proceedings of the 2022 ACM
              SIGSAC Conference on Computer and Communications Security
              (CCS '22), pages 97–109. Association for Computing
              Machinery, New York, NY, USA.  DOI:
              https://doi.org/10.1145/3548606.3560577, 2022,
              <https://doi.org/10.1145/3548606.3560577>.

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

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
              August 2022, <https://www.rfc-editor.org/info/rfc9053>.

   [RFC9794]  Driscoll, F., Parsons, M., and B. Hale, "Terminology for
              Post-Quantum Traditional Hybrid Schemes", RFC 9794,
              DOI 10.17487/RFC9794, June 2025,
              <https://www.rfc-editor.org/info/rfc9794>.

Authors' Addresses




Pocero Fraile, et al.     Expires 19 April 2026                [Page 32]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   Lidia Pocero Fraile
   ISI, R.C. ATHENA
   Cyber-physical and Networked Embedded Systems
   26504 Patras
   Greece
   Email: pocero@isi.gr


   Christos Koulamas
   ISI, R.C. ATHENA
   Cyber-physical and Networked Embedded Systems
   26504 Patras
   Greece
   Email: koulamas@isi.gr


   Apostolos P. Fournaris
   ISI, R.C. ATHENA
   Security and Protection of Systems, Networks and Infrastructures
   26504 Patras
   Greece
   Email: fournaris@isi.gr


   Evangelos Haleplidis
   ISI, R.C. ATHENA
   Department of Digital Systems
   26504 Patras
   Greece
   Email: haleplidis@isi.gr





















Pocero Fraile, et al.     Expires 19 April 2026                [Page 33]


name: draft-ietf-emu-pqc-eapaka
rev: 01
title: Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime
time: 2026-02-26T10:18:50Z
group_uri: /api/v1/group/group/1674/
expires: 2026-08-30T10:18:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014841+00:00
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
   making it quantum-safe using Post-Quantum Key Encapsulation
   Mechanisms (PQ-KEMs).

full_text:
EMU                                                             T. Reddy
Internet-Draft                                               A. Banerjee
Intended status: Standards Track                                   Nokia
Expires: 30 August 2026                                 26 February 2026


  Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime
                      draft-ietf-emu-pqc-eapaka-01

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
   making it quantum-safe using Post-Quantum Key Encapsulation
   Mechanisms (PQ-KEMs).

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



Reddy & Banerjee         Expires 30 August 2026                 [Page 1]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


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

Copyright Notice

   Copyright (c) 2026 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
     4.1.  Key Encapsulation Mechanisms  . . . . . . . . . . . . . .   5
   5.  Design Rationales . . . . . . . . . . . . . . . . . . . . . .   6
   6.  PQC KEM Enhancements by Design  . . . . . . . . . . . . . . .   6
   7.  Message Fragmentation and Reassembly  . . . . . . . . . . . .   7
     7.1.  Fragmentation Attribute . . . . . . . . . . . . . . . . .   7
     7.2.  Fragmentation Procedure . . . . . . . . . . . . . . . . .   8
     7.3.  Use of the EAP Identifier . . . . . . . . . . . . . . . .   9
     7.4.  Reassembly  . . . . . . . . . . . . . . . . . . . . . . .   9
     7.5.  Applicability . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Protocol Construction . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Protocol Call Flow  . . . . . . . . . . . . . . . . . . .  11
     8.2.  Key Steps in protocol construction  . . . . . . . . . . .  13
   9.  Extensions to EAP-AKA' FS . . . . . . . . . . . . . . . . . .  14
     9.1.  AT_PUB_KEM  . . . . . . . . . . . . . . . . . . . . . . .  14
     9.2.  AT_KEM_CT . . . . . . . . . . . . . . . . . . . . . . . .  15
   10. Capability Negotiation  . . . . . . . . . . . . . . . . . . .  16
   11. ML-KEM  . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  17
     12.1.  Selecting ML-KEM Variants  . . . . . . . . . . . . . . .  17
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17



Reddy & Banerjee         Expires 30 August 2026                 [Page 2]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


     14.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     14.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

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

   Researchers have developed Post-Quantum Key Encapsulation Mechanisms
   (PQ-KEMs) to provide secure key establishment resistant against an
   adversary with access to a quantum computer.

   At the time of writing, NIST has standardized three PQC algorithms,
   with more expected to be standardized in the future ([NISTFINAL]).
   As these algorithms are secure against both quantum and classical
   computers, this document proposes a PQ-KEM for achieving perfect
   forward secrecy in EAP-AKA'.

   Although the proposed mechanism is applicable to any post-quantum Key
   Encapsulation Mechanism (PQ-KEM), this document specifies its use
   with Module-Lattice-based Key Encapsulation Mechanisms (ML-KEMs).
   ML-KEM provides a one-pass (store-and-forward) cryptographic method
   for an originator to securely transmit keying material to a recipient
   using the recipient’s ML-KEM public key.  Three parameter sets for



Reddy & Banerjee         Expires 30 August 2026                 [Page 3]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


   ML-KEM are defined in [FIPS203], namely ML-KEM-512, ML-KEM-768, and
   ML-KEM-1024, listed in order of increasing security strength and
   decreasing performance.

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].  The following terms are
   repeately used in this specification:

   *  KEM: Key Encapsulation Mechanism

   *  PQ-KEM: Post-Quantum Key Encapsulation Mechanism

   *  CEK: Content Encryption Key

   *  ML-KEM: Module-Lattice-based Key Encapsulation Mechanism

   For the purposes of this document, it is helpful to be able to divide
   cryptographic algorithms into two classes:

   "Asymmetric Traditional Algorithm": An asymmetric cryptographic
   algorithm based on integer factorisation, finite field discrete
   logarithms or elliptic curve discrete logarithms, or related
   mathematical problems.

   "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that
   is believed to be secure against attacks using quantum computers as
   well as classical computers.  Post-quantum algorithms can also be
   called quantum-resistant or quantum-safe algorithms.  Examples of
   Post-Quantum Algorithm include ML-KEM.

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.





Reddy & Banerjee         Expires 30 August 2026                 [Page 4]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


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

4.1.  Key Encapsulation Mechanisms

   For the purposes of this document, we consider a Key Encapsulation
   Mechanism (KEM) to be any asymmetric cryptographic scheme comprised
   of algorithms satisfying the following interfaces [PQCAPI].

   *  def kemKeyGen() -> (pk, sk)

   *  def kemEncaps(pk) -> (ct, ss)

   *  def kemDecaps(ct, sk) -> ss

   where pk is public key, sk is secret key, ct is the ciphertext
   representing an encapsulated key, and ss is shared secret.

   KEMs are typically used in cases where two parties, hereby refereed
   to as the "encapsulater" and the "decapsulater", wish to establish a
   shared secret via public key cryptography, where the decapsulater has
   an asymmetric key pair and has previously shared the public key with
   the encapsulater.











Reddy & Banerjee         Expires 30 August 2026                 [Page 5]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


5.  Design Rationales

   It is essential to note that in the PQ-KEM, one needs to apply
   Fujisaki-Okamoto [FO] transform or its variant [HHK] on the PQC KEM
   part to ensure that the overall scheme is IND-CCA2 secure, as
   mentioned in [I-D.ietf-tls-hybrid-design].  The FO transform is
   performed using the KDF such that the PQC KEM shared secret achieved
   is IND-CCA2 secure.

   Note that during the transition from traditional to post-quantum
   algorithms, there may be a desire or a requirement for protocols that
   incorporate both types of algorithms until the post-quantum
   algorithms are fully trusted.  HPKE is an KEM that can be extended to
   support hybrid post-quantum KEMs and the specifications for the use
   of HPKE with EAP-AKA prime is described in
   [I-D.draft-ar-emu-pqc-eapaka].

6.  PQC KEM Enhancements by Design

   We suggest the following changes and enhancements:

   *  A new attribute, AT_PUB_KEM, is defined to carry the PQC KEM
      public key from the EAP server.

   *  A new attribute, AT_KEM_CT, is defined to carry the ciphertext
      (ct) generated by the PQC KEM Encapsulation function from the EAP
      peer.

   *  The AT_KDF_FS attribute is updated to indicate the PQC KEM for
      generating the Master Key MK_PQ_SHARED_SECRET.

   *  Multiple AT_KDF_FS attributes are included in the EAP-Request to
      handle the EAP peer not supporting PQC KEM.

   *  The PQC KEM can be included first in the AT_KDF_FS attribute in
      the EAP-Request to indicate a higher priority for its use compared
      to the traditional key derivation functions.

   *  EAP-AKA and EAP-AKA′ FS do not define a native attribute-level
      fragmentation mechanism.  As PQC public keys and ciphertexts may
      exceed the EAP MTU, this specification defines an explicit
      attribute-level fragmentation mechanism (AT_FRAGMENT) to support
      transport of large attribute values.








Reddy & Banerjee         Expires 30 August 2026                 [Page 6]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


7.  Message Fragmentation and Reassembly

   EAP-AKA and EAP-AKA' FS do not natively define fragmentation.  This
   specification therefore defines attribute-level fragmentation for
   attributes whose total length may exceed the EAP MTU.

   This specification defines an attribute-level fragmentation mechanism
   similar to the lock-step acknowledgment model used by EAP-TLS
   [RFC2716].  Fragmentation applies to the entire attribute, including
   the attribute header and value.

   Only one fragmented attribute exchange (i.e., one fragmented
   attribute transmission in progress in either direction) MUST be
   active at any time.

7.1.  Fragmentation Attribute

   When an attribute is fragmented, each fragment carries a
   Fragmentation attribute.  The Fragment Data field carries a
   contiguous portion of the original attribute, treated as an opaque
   sequence of octets.  The first fragment MUST begin with the attribute
   Type and Length fields.  Subsequent fragments carry the next
   contiguous octets of the attribute.

   The receiver MUST reconstruct the original attribute by concatenating
   the Fragment Data fields, in the order received, excluding any per-
   fragment alignment padding.  The reassembled attribute MUST be
   bitwise identical to the original, unfragmented attribute and MUST
   NOT be processed until reassembly has completed.

   The Fragmentation attribute has the following format:

   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_FRAGMENT | Reserved | Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   Flags | Reserved | Total Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Fragment Data
   (variable) | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:

   A 2-octet unsigned integer indicating the length of this AT_FRAGMENT
   attribute in multiples of 4 octets, including the Type, Reserved,
   Length, Flags, Total Attribute Length, Fragment Data, and any
   alignment padding.  The total length of the attribute in octets is
   obtained by multiplying this field by 4.



Reddy & Banerjee         Expires 30 August 2026                 [Page 7]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


   Each AT_FRAGMENT attribute MUST have a Length that is a multiple of 4
   octets.

   Flags (1 octet):

   The Flags field contains the following bits:

   0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|M| Reserved | +-+-+-+-+-+-+-+-+

   *  S (First Fragment)

      Indicates that this is the first fragment of a fragmented
      attribute.  This bit MUST be set on the first fragment and MUST
      NOT be set on subsequent fragments.

   *  M (More Fragments) Indicates that additional fragments follow.
      This bit MUST be set on all fragments except the last.

   *  Reserved
      MUST be set to zero on transmission and ignored on receipt.

   Total Attribute Length (2 octets)

   The Total Attribute Length field specifies the total length, in
   octets, of the unfragmented attribute, including its Type, Length,
   and Value fields.  It is encoded as an unsigned 16-bit integer in
   network byte order.

   This field MUST be present in all fragments belonging to the same
   fragmented attribute.  In fragments other than the first, the value
   of Total Attribute Length MUST be identical to that of the first
   fragment.  If a mismatch is detected, the receiver MUST treat this as
   a protocol error and abort the authentication exchange.

7.2.  Fragmentation Procedure

   *  When an EAP peer receives an EAP-Request containing an attribute
      fragment with the M bit set, it MUST respond with an EAP-Response
      of the same EAP type containing no attributes.  This response
      serves as a fragment acknowledgment.

   *  When an EAP server receives an EAP-Response containing an
      attribute fragment with the M bit set, it MUST respond with an
      EAP-Request of the same EAP type containing no attributes.  This
      request serves as a fragment acknowledgment.

   *  The sender MUST NOT transmit the next fragment until the
      corresponding acknowledgment has been received.



Reddy & Banerjee         Expires 30 August 2026                 [Page 8]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


7.3.  Use of the EAP Identifier

   The EAP Identifier field is used to correlate fragments and
   acknowledgments:

   *  The Identifier in an EAP-Response MUST match the Identifier of the
      immediately preceding EAP-Request.

   *  Fragment acknowledgments MUST echo the Identifier of the fragment
      being acknowledged.

   *  Retransmitted fragments MUST reuse the same Identifier value as
      the original transmission.

   *  For fragmented exchanges initiated by the EAP server, the
      Identifier in each EAP-Request carrying a fragment MUST be
      incremented relative to the previous EAP-Request.

7.4.  Reassembly

   The receiver MUST reassemble attribute fragments strictly in the
   order received and MUST NOT process the fragmented attribute until
   all fragments have been successfully received and validated.

   The final fragment is identified by the M bit being cleared (M = 0).
   The receiver MUST acknowledge each fragment, including the final
   fragment, using the lock-step procedure defined for fragmentation.
   The sender MUST wait for acknowledgment of the final fragment before
   considering the fragmented attribute exchange complete.

   During the fragmentation phase (i.e., while the M bit is set in
   AT_FRAGMENT), the EAP peer MUST respond to each EAP-Request/AKA'-
   Challenge fragment with an EAP-Response/AKA'-Challenge message
   containing a zero-length attribute payload.  These responses serve
   solely as transport-level acknowledgments and MUST NOT trigger any
   AKA' cryptographic processing.

   The EAP peer MUST NOT initiate USIM processing (e.g., passing RAND
   and AUTN to the USIM) while attribute fragmentation is in progress.
   USIM processing has to occur only after the final fragment (M = 0)
   has been received and the complete attribute set has been
   successfully reassembled and validated.  At that point, the peer will
   invoke the AKA' algorithm using the RAND and AUTN values contained in
   the reassembled message.

   If a fragment is lost or corrupted, normal EAP retransmission
   procedures apply.  Retransmitted fragments MUST use the same EAP
   Identifier value as the original transmission.



Reddy & Banerjee         Expires 30 August 2026                 [Page 9]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


   The receiver MUST verify that:

   *  The first fragment has the S bit set and subsequent fragments do
      not; and

   *  The cumulative length of all received Fragment Data fields equals
      the Total Attribute Length.

   Any inconsistency in fragmentation state (including unexpected S bit
   usage, receipt of a new initial fragment while reassembly is in
   progress, length mismatch, or malformed sequencing) MUST be treated
   as a protocol error, and the authentication exchange MUST be aborted.
   If reassembly cannot be successfully completed after a bounded number
   of retransmissions, the authentication exchange MUST be aborted.

   Fragmentation does not modify the AT_MAC calculation rules defined in
   [RFC9048].  AT_MAC is calculated over the EAP packet exactly as
   transmitted on the wire, including any AT_FRAGMENT attributes.

   Processing of data contained in reassembled fragmented attributes
   MUST occur only after successful AT_MAC verification.  Fragmentation
   therefore does not alter the integrity protection scope of the EAP
   packet.

7.5.  Applicability

   This fragmentation mechanism applies to any attribute within this EAP
   method whose encoded length exceeds the EAP MTU. (e.g., AT_PUB_KEM,
   AT_KEM_CT, or AT_IDENTITY carrying a large SUCI).  Attributes that
   fit within a single EAP packet MUST be sent unfragmented.

   The following diagram details how the fragmentation works for both
   request and response:

   Peer Server | | | <- EAP-Request / Identity (Id=1) | | | | EAP-
   Response / Identity (Id=1) -> | | | | <- EAP-Request / AKA'-Challenge
   (Id=2) | | (unfragmented attributes) | | | | EAP-Response / AKA'-
   Challenge (Id=2) -> | | | |================ Server-Initiated
   Fragmentation ===============| | | | <- EAP-Request / AKA'-Challenge
   (Id=3) | | (Fragment 1: S=1, M=1) | | | | EAP-Response / AKA'-
   Challenge (Id=3) -> | | (ACK, no attributes) | | | | <- EAP-Request /
   AKA'-Challenge (Id=4) | | (Fragment 2: M=1) | | | | EAP-Response /
   AKA'-Challenge (Id=4) -> | | (ACK, no attributes) | | | | <- EAP-
   Request / AKA'-Challenge (Id=5) | | (Fragment 3: M=0, last
   fragment) | | | | EAP-Response / AKA'-Challenge (Id=5) -> | | (ACK,
   no attributes — final fragment) | | | |================ Peer-
   Initiated Fragmentation =================| | | | <- EAP-Request /
   Identity (Id=6) | | | | EAP-Response / AKA'-Challenge (Id=6) -> | |



Reddy & Banerjee         Expires 30 August 2026                [Page 10]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


   (Fragment 1: S=1, M=1) | | | | <- EAP-Request / AKA'-Challenge
   (Id=7) | | (ACK, no attributes) | | | | EAP-Response / AKA'-Challenge
   (Id=7) -> | | (Fragment 2: M=0, last fragment) | | | | <- EAP-Request
   / AKA'-Challenge (Id=8) | | (ACK, no attributes — final
   fragment)| | | | <- EAP-Success (Id=9) | | |

   The term “ACK” in the above figure is used for illustrative purpose
   to describe an EAP-Request or EAP-Response of the same EAP method
   type that contains no attributes and is sent solely to acknowledge
   receipt of a fragment.

8.  Protocol Construction

   The above section outlines how the fragmentation works.  This section
   defines the construction for PQC KEM in EAP-AKA' FS and the other
   params that are sent via EAP Req/Resp AKA'-Challenge.

8.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 an a PQC KEM key pair, sends the public key  |
     |      | of that key pair and the first EAP method message      |



Reddy & Banerjee         Expires 30 August 2026                [Page 11]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


     |      | to the peer. In the message the AT_PUB_KEM attribute   |
     |      | carries the PQC KEM public key and the AT_KDF_FS       |
     |      | attribute carries PQC KEM algorithm. Both of           |
     |      | these are skippable attributes that can be ignored     |
     |      | if the peer does not support this extension.           |
     |      +-------+----------------------------+----------------+--+
     |              |                            |                |
     |              | EAP-Req/AKA'-Challenge,    |                |
     |              |  AT_RAND, AT_AUTN, AT_KDF, |                |
     |              |   AT_KDF_FS, AT_KDF_INPUT, |                |
     |              |      AT_PUB_KEM, AT_MAC    |                |
     |              |<---------------------------+                |
   +--+--------------+----------------------------+---------+     |
   | The peer checks if it wants to do the FS extension. If |     |
   | yes, it will eventually respond with AT_KEM_CT and     |     |
   | AT_MAC. If not, it will ignore AT_PUB_KEM 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 calculate a   |     |
   | PQC KEM shared secret key based on the server's PQC    |     |
   | KEM public key. Finally, it proceeds to derive all     |     |
   | EAP-AKA' key values and  constructs a full response.   |     |
   +--+--------------+----------------------------+---------+     |
     |              |                            |                |
     |              |EAP-Resp/AKA'-Challenge     |                |
     |              | AT_RES, AT_KEM_CT,         |                |
     |              | AT_MAC                     |                |
     |              +--------------------------->|                |
     |      +-------+----------------------------+----------------+--+
     |      | The server now has all the necessary values. It        |
     |      | generates the PQC KEM 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 PQC KEM shared secret value. Even if there was an  |
     |      | attacker who held the long-term key, only an active    |



Reddy & Banerjee         Expires 30 August 2026                [Page 12]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


     |      | 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.           |
     |      +-------+----------------------------+----------------+--+
     |              |                            |                |
     |              |                EAP-Success |                |
     |              |<---------------------------+                |
     |              |                            |                |

8.2.  Key Steps in protocol construction

   We outline the following key steps in the protocol:

   *  Server generates the PQC KEM public key(pk), private key (sk)
      pair.  The server will generate the Authentication Vector (AV).
      The server PQC KEM key pair is derived as:

      sk, pk = kemKeyGen()

   *  The server will store the expected response XRES, the PQC KEM
      private key sk.  The server will forward the authenticator part
      (AUTH) of the AV to peer along with pk.

   *  The USIM will validate the AUTN received, also verifies the MAC.
      After the verification is successful and if the peer also supports
      the Forward secrecy, peer will invoke kemEncaps using pk:

      ct, ss = kemEncaps(pk)

   "ct" is the ciphertext from kemEncaps whereas "ss" is shared secret
   key.

   *  The peer will send the Authentication result RES and ct to the
      server.

   *  The server will verify the RES with XRES.  The server will use the
      ct and PQC KEM private key sk to generate shared secret:

      ss = kemDecaps(ct, sk)

   The generated ss from kemDecaps is the shared secret key derived from
   kemEncaps.  The peer and the server first generate the
   MK_PQ_SHARED_SECRET and subsequently generate MSK, EMSK as shown
   below:






Reddy & Banerjee         Expires 30 August 2026                [Page 13]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


     MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
     ct, ss = kemEncaps(pk)
     MK_PQ_SHARED_SECRET = PRF'(IK'|CK'|ss,"EAP-AKA' FS"| Identity | ct)
     K_encr = MK[0..127]
     K_aut = MK[128..383]
     K_re = MK_PQ_SHARED_SECRET [0..255]
     MSK = MK_PQ_SHARED_SECRET [256..767]
     EMSK = MK_PQ_SHARED_SECRET [768..1279]

   where, pk is PQC KEM public key from the EAP server, ct is the
   ciphertext from the kemEncaps and it is triggered by the EAP peer
   only.  The pseudo-random function (PRF') binds the shared secret to
   the ciphertext (ct), achieving MAL-BIND-K-CT.

   The ML-KEM already achieves MAL-BIND-K-PK as the hash of the PQC KEM
   public key is an input to the computation of the shared secret (ss)
   (line 2 of ML-KEM.Encaps algorithm in [FIPS203]).  These
   computational binding properties for KEMs are defined in [CDM].

9.  Extensions to EAP-AKA' FS

9.1.  AT_PUB_KEM

   The format of the AT_PUB_KEM 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_KEM    |   Reserved    |         Length                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Value (variable)                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are as follows:

   AT_PUB_KEM:

   This is set to TBA1 BY IANA.

   Reserved: A 1-byte field reserved for future use.  Including this
   field ensures that the fixed header (Type, Reserved, Length) is 4
   bytes long, maintaining 4-byte alignment for the following Value
   field.  The Reserved field MUST be set to 0 on transmission and
   ignored on receipt.

   Length:



Reddy & Banerjee         Expires 30 August 2026                [Page 14]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


   A 2-byte unsigned integer indicating the length of this attribute in
   multiples of 4 octets, including the Type, Reserved, Length, and
   Value fields, as well as any padding.

   The total length of the attribute in octets is obtained by
   multiplying this field by 4.

   This differs from the attribute format used in EAP-AKA [RFC4187],
   where the Length field is 1 byte.The modification is necessary
   because PQC KEM public keys, such as those defined in ML-KEM-1024,
   will be 1568 bytes, which would exceed the 1024-byte limit imposed by
   the original EAP-AKA format.

   Value:

  *  EAP-Request: It contains the public key, which is the PQC KEM public key from the EAP server.

   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.

9.2.  AT_KEM_CT

   The format of the AT_KEM_CT 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_KEM_CT     |   Reserved    |         Length                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                   Value (variable)                            |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are as follows:

   AT_KEM_CT:

   This is set to TBA2 BY IANA.

   Reserved: A 1-byte field reserved for future use.  The Reserved field
   MUST be set to 0 on transmission and ignored on receipt.

   Length:





Reddy & Banerjee         Expires 30 August 2026                [Page 15]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


   A 2-byte unsigned integer indicating the length of this attribute in
   multiples of 4 octets, including the Type, Reserved, Length, and
   Value fields, as well as any padding.

   The total length of the attribute in octets is obtained by
   multiplying this field by 4.

   This differs from the format used in EAP-AKA [RFC4187], where the
   Length field is 1 byte.  The change is necessary because ciphertexts
   produced by PQC KEM algorithms,such as 1568 bytes in ML-KEM-1024 will
   exceed the 1024 byte limit imposed by the original EAP-AKA attribute
   format.

   Value:

  *  EAP-Response: It contains the ciphertext (ct) from the PQC KEM Encapsulation function 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.

10.  Capability Negotiation

   Support for PQC KEM is negotiated using the AT_KDF_FS attribute.

   AT_PUB_KEM and AT_KEM_CT use an extended attribute header format that
   is incompatible with legacy EAP-AKA and EAP-AKA' implementations.
   Therefore, these attributes MUST NOT be sent unless a mutually
   supported PQC KEM has been successfully negotiated via AT_KDF_FS.

11.  ML-KEM

   ML-KEM offers several parameter sets with varying levels of security
   and performance trade-offs.  This document specifies the use of the
   ML-KEM algorithm at three security levels: ML-KEM-512, ML-KEM-768,
   and ML-KEM-1024.  The main security property for KEMs standardized in
   the NIST Post-Quantum Cryptography Standardization Project is
   indistinguishability under adaptive chosen ciphertext attacks (IND-
   CCA2) (see Section 10.2 of [I-D.ietf-pquip-pqc-engineers]).  The
   public/private key sizes, ciphertext key size, and PQ security levels
   of ML-KEM are detailed in Section 12 of
   [I-D.ietf-pquip-pqc-engineers].








Reddy & Banerjee         Expires 30 August 2026                [Page 16]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


12.  Security Considerations

   The security of the PQ-KEM algorithm depends on a high-quality
   pseudo-random number generator.  For further discussion on random
   number generation, see [RFC4086].

   In general, good cryptographic practice dictates that a given PQ-KEM
   key pair should be used in only one EAP session.  This practice
   mitigates the risk that compromise of one EAP session will not
   compromise the security of another EAP session and is essential for
   maintaining forward security.

   Implementations MUST enforce a locally configured maximum Total
   Attribute Length for fragmented attributes.  If the Total Attribute
   Length exceeds this limit, the attribute MUST be rejected and the
   authentication exchange aborted.  This limit has to be chosen to
   mitigate DoS attack with support for large PQC key material.

12.1.  Selecting ML-KEM Variants

   ML-KEM is believed to be 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].

13.  IANA Considerations

   Three new Attribute Type values (TBA1, TBA2, and TBA3) from the
   skippable range are requested from IANA for AT_PUB_KEM (Section 9.1),
   AT_KEM_CT (Section 9.2), and AT_FRAGMENT (Section 7.1) in the
   "Attribute Types" registry under the "EAP-SIM/AKA/AKA'" group.

   IANA is requested to update the registry "EAP-AKA' AT_KDF_FS Key
   Derivation Function Values" with the PQC KEM algorithm entries:

   +=========+===============================+=========================+
   | Value   | Description                   | Reference               |
   +=========+===============================+=========================+
   | TBA3    | EAP-AKA' with MLKEM512        | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+
   | TBA4    | EAP-AKA' with MLKEM768        | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+
   | TBA5    | EAP-AKA' with MLKEM1024       | [TBD BY IANA: THIS RFC] |
   +=========+===============================+=========================+

14.  References




Reddy & Banerjee         Expires 30 August 2026                [Page 17]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


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

   [RFC2716]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication
              Protocol", RFC 2716, DOI 10.17487/RFC2716, October 1999,
              <https://www.rfc-editor.org/rfc/rfc2716>.

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

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

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <https://www.rfc-editor.org/rfc/rfc5216>.

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

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

   [RFC9678]  Arkko, J., Norrman, K., and J. Preuß Mattsson, "Forward
              Secrecy Extension to the Improved Extensible
              Authentication Protocol Method for Authentication and Key
              Agreement (EAP-AKA' FS)", RFC 9678, DOI 10.17487/RFC9678,
              March 2025, <https://www.rfc-editor.org/rfc/rfc9678>.

14.2.  Informative References

   [CDM]      "Keeping Up with the KEMs: Stronger Security Notions for
              KEMs and automated analysis of KEM-based protocols",
              <https://eprint.iacr.org/2023/1933.pdf>.





Reddy & Banerjee         Expires 30 August 2026                [Page 18]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


   [FIPS203]  "FIPS-203: Module-Lattice-based Key-Encapsulation
              Mechanism Standard",
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.203.pdf>.

   [FO]       "Secure Integration of Asymmetric and Symmetric Encryption
              Schemes", <https://link.springer.com/article/10.1007/
              s00145-011-9114-1>.

   [HHK]      "A Modular Analysis of the Fujisaki-Okamoto
              Transformation", <https://link.springer.com/
              chapter/10.1007/978-3-319-70500-2_12>.

   [I-D.draft-ar-emu-pqc-eapaka]
              Banerjee, A. and T. Reddy.K, "Enhancing Security in EAP-
              AKA' with Hybrid Post-Quantum Cryptography", Work in
              Progress, Internet-Draft, draft-ar-emu-pqc-eapaka-04, 16
              March 2025, <https://datatracker.ietf.org/doc/html/draft-
              ar-emu-pqc-eapaka-04>.

   [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-14, 25 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-14>.

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

   [I-D.ietf-tls-hybrid-design]
              Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
              exchange in TLS 1.3", Work in Progress, Internet-Draft,
              draft-ietf-tls-hybrid-design-16, 7 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              hybrid-design-16>.

   [NISTFINAL]
              "NIST Releases First 3 Finalized Post-Quantum Encryption
              Standards", n.d., <https://www.nist.gov/news-
              events/news/2024/08/nist-releases-first-3-finalized-post-
              quantum-encryption-standards>.




Reddy & Banerjee         Expires 30 August 2026                [Page 19]

Internet-Draft          PQ KEMs in EAP-AKA prime           February 2026


   [PQCAPI]   "PQC - API notes",
              <https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-
              Cryptography/documents/example-files/api-notes.pdf>.

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

Appendix A.  Acknowledgements

   This draft leverages text from [RFC9678].

Authors' Addresses

   Tirumaleswar Reddy
   Nokia
   Bangalore
   Karnataka
   India
   Email: kondtir@gmail.com


   Aritra Banerjee
   Nokia
   London
   United Kingdom
   Email: aritra.banerjee@nokia.com























Reddy & Banerjee         Expires 30 August 2026                [Page 20]


name: draft-wang-ppm-ecdh-psi
rev: 01
title: PSI based on ECDH
time: 2025-08-20T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2025-08-21T06:43:24Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014847+00:00
abstract:
This document describes Elliptic Curve Diffie-Hellman Private Set
   Intersection (ECDH-PSI) for 2 participants.  It instantiates the
   classical Meadows match-making protocol with standard elliptic curves
   and hash-to-curve methods, enabling the participants to find common
   records in a privacy-respecting way.  In ECDH-PSI, records are
   encoded to points on an elliptic curve, and masked by the private
   keys of both participants.  To compute the intersection, a
   participant only uses the jointly masked datasets and its original
   dataset locally, which prevents its partner from learning the private
   records not in the intersection.

full_text:
Privacy Preserving Measurement                                   Y. Wang
Internet-Draft                                                  W. Chang
Intended status: Informational                                     Y. Lu
Expires: 21 August 2025                                          C. Hong
                                                                 J. Peng
                                                               Ant Group
                                                        17 February 2025


                           PSI based on ECDH
                       draft-wang-ppm-ecdh-psi-01

Abstract

   This document describes Elliptic Curve Diffie-Hellman Private Set
   Intersection (ECDH-PSI) for 2 participants.  It instantiates the
   classical Meadows match-making protocol with standard elliptic curves
   and hash-to-curve methods, enabling the participants to find common
   records in a privacy-respecting way.  In ECDH-PSI, records are
   encoded to points on an elliptic curve, and masked by the private
   keys of both participants.  To compute the intersection, a
   participant only uses the jointly masked datasets and its original
   dataset locally, which prevents its partner from learning the private
   records not in the intersection.

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 21 August 2025.

Copyright Notice

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





Wang, et al.             Expires 21 August 2025                 [Page 1]

Internet-Draft                  ECDH-PSI                   February 2025


   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.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     1.2.  Data Structures and Notations . . . . . . . . . . . . . .   4
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Elliptic Curves . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Hashing to Elliptic Curves  . . . . . . . . . . . . . . .   5
     2.3.  Transport Layer Security  . . . . . . . . . . . . . . . .   6
   3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Handshake . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  HandshakeRequest  . . . . . . . . . . . . . . . . . .   9
       3.2.2.  HandshakeResponse . . . . . . . . . . . . . . . . . .  12
       3.2.3.  Support More hash_to_curve Suites . . . . . . . . . .  14
     3.3.  Data Exchange . . . . . . . . . . . . . . . . . . . . . .  15
       3.3.1.  EcdhPsiBatch  . . . . . . . . . . . . . . . . . . . .  16
   4.  Implementation Considerations . . . . . . . . . . . . . . . .  18
     4.1.  The Representation of EC Point  . . . . . . . . . . . . .  18
     4.2.  The Management of Index . . . . . . . . . . . . . . . . .  18
     4.3.  Large Record Size . . . . . . . . . . . . . . . . . . . .  19
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     5.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  19
     5.2.  Static ECDH Oracle  . . . . . . . . . . . . . . . . . . .  20
     5.3.  Key Reuse . . . . . . . . . . . . . . . . . . . . . . . .  22
     5.4.  Man-In-The-Middle Attack  . . . . . . . . . . . . . . . .  22
     5.5.  Replay Attack . . . . . . . . . . . . . . . . . . . . . .  23
     5.6.  Side Channel  . . . . . . . . . . . . . . . . . . . . . .  25
     5.7.  Data Truncation . . . . . . . . . . . . . . . . . . . . .  25
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  27
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31








Wang, et al.             Expires 21 August 2025                 [Page 2]

Internet-Draft                  ECDH-PSI                   February 2025


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 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.  It
   enables a user to detect whether his/her password is leaked without
   giving away the password to the server [MS21], and allows multiple
   companies to find their common customers without revealing raw data.
   Furthermore, many privacy-respecting systems can leverage PSI schemes
   to collaborate with other data providers for the purpose of enhancing
   the privacy of data-exchange processes.  As an example, a service
   provider who has aggregated attributes from individuals following
   [I-D.ietf-ppm-dap][draft-irtf-cfrg-vdaf-12] can use PSIs to compare
   its results with another entity without disclosing any attribute not
   owned by the partner.

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

   This document describes 2-party ECDH-PSI as a two-phase protocol,
   including a handshake phase which negotiates parameters such as
   cipher suites and a data exchange phase which transfers masked
   datasets.  At the end of data exchange phase, one or both parties
   output the intersection 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.







Wang, et al.             Expires 21 August 2025                 [Page 3]

Internet-Draft                  ECDH-PSI                   February 2025


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

   The following notations are used throughout this document:

   *sqrt(x): The square root of x.

   *log(x,y): The logarithm of y to the base x.

   *x^-1: The inverse of x (over a finite field).

   *x||y: Concatenate string x and y.

   *intersection(set_1,set_2): The intersection of set_1 and set_2

   *|set|: The cardinality of set.

2.  Background

   This section gives brief introductions for elliptic curves, hash-to-
   curve methods and the Transport Layer Security (TLS) protocol.

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

   This document uses term "addition" to refer to the group operation of
   an 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 an integer x<r and a point P as inputs and outputs the
   multiplication result Q, which is written by Q=scalar_mul(P,x) or
   simply Q=P^x.  When set_p is a set of EC points, set_m=set_p^x
   denotes that all elements of set_p are multiplied by x to obtain
   set_m.





Wang, et al.             Expires 21 August 2025                 [Page 4]

Internet-Draft                  ECDH-PSI                   February 2025


   Many cryptographic applications require the participants to generate
   elliptic curve key pairs.  Usually, a key pair refers to a (PK,sk)
   tuple, where sk is an 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 [RFC9380] encodes data of arbitrary length
   to a point on an elliptic curve.  The encoding process first hashes
   the byte string to 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 set_p=hash_to_curve(set_d) to refer to the process of
   encoding every elements in set_d to points on a curve and obtains
   set_p.

   [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.  To meet
   the requirement of DSTs, this document allocates each suite with a
   unique DST, and uses the notation of set_p=hash_to_curve(set_d)
   assuming that the corresponding DST strings have been taken as
   internal inputs.

   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.




Wang, et al.             Expires 21 August 2025                 [Page 5]

Internet-Draft                  ECDH-PSI                   February 2025


2.3.  Transport Layer Security

   The TLS protocol [RFC8446] has been widely used for secure
   communication over the Internet.  It operates over any underlying
   communication channel that provides reliable, in-order data stream,
   ensuring important security properties of authentication,
   confidentiality and integrity.  In particular, TLS provides mutual
   authentication methods so that the peers can authenticate each other.
   It also uses DH key exchange to establish session keys and employs
   authenticated encryption to guarantee that the transferred messages
   are encrypted and not manipulated.

   The notion of "channel binding" is originally proposed by [RFC5056],
   which enables applications to bind authentication to secure sessions
   at lower layers in the network stack so as to prevent the so-called
   Man-In-The-Middle (MITM) attack.  To extend the notion to TLS,
   [RFC9266] presents a method of binding applications to the underlying
   TLS 1.3 sessions, which is denoted by 'tls-exporter'.  It outputs
   exported keying material (EKM) established by the TLS session, which
   can be seen as the output of a pseudorandom function (PRF) based on
   TLS.  The application can bind to the TLS session by taking EKM as an
   input to the application-layer cryptographic session.

3.  Protocol

   We begin with a very brief description on how ECDH-PSI works.
   Firstly, the participants, A and B, agree on a group <G> along with
   the hash_to_curve suites, and generate fresh private keys over <G>.
   Then, both A and B convert their records to points over <G> and
   multiply the points with both parties' private keys for masking.
   Finally, they exchange the sets of masked elements, compute their
   intersection, and match the intersections with original datasets
   locally.

   To prepare the ECDH-PSI protocol, A and B need to:

   *  Establish a TLS channel with mutual authentication.

   *  Negotiate the parameters used for subsequent steps, especially the
      hash_to_curve suite.

   *  Generate EC private keys with sk_A=keygen() and sk_B=keygen().
      These keys are also denoted by "ECDH-PSI keys", and only used in
      current ECDH-PSI session.

   After the preparation, assume that A has set_A, B has set_B, a
   simplified protocol flow of ECDH-PSI is shown by Figure 1, and
   explained step-by-step as follows:



Wang, et al.             Expires 21 August 2025                 [Page 6]

Internet-Draft                  ECDH-PSI                   February 2025


   1.  Each participant maps its records to EC points with
       hash_to_curve, and masks the points locally with its own private
       key by scalar_mul.  In this step, the ECDH-PSI session is bound
       to the underlying TLS session with the channel binding mechanism
       introduced by Section 2.3.  We defer the details of session
       binding to Section 3.3.

   2.  A and B exchange their locally masked sets pset_A and pset_B.

   3.  Upon receiving the masked data from its partner, a participant
       masks the received points with its private key.

   4.  Each participant sends the jointly masked set (i.e., pset_BA and
       pset_AB) back to its partner.

   5.  Each participant calculates intersection of the set calculated in
       Step 3 and the set received in Step 4, matches the original data
       set with the intersection, and finally outputs the matching
       result.

   In order to clarify the statement, this document uses "the first
   round" or "round 1" to refer to Step 2, and "the second round" or
   "round 2" for 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 only one participant (commonly, the participant who
   initiates the session) should output the intersection and the other
   gets nothing.  In such scenarios, Step 4 and Step 5 are executed
   unidirectionally, where only one party sends jointly 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 masked EC points.  In particular,
   the relationship can be established with unique indexes, where an
   original data record and corresponding masked EC point(s) are linked
   to the same index.













Wang, et al.             Expires 21 August 2025                 [Page 7]

Internet-Draft                  ECDH-PSI                   February 2025


              A(set_A,sk_A)                   B(set_B,sk_B)
-----------------------------------------------------------------------
Step 1:             |                               |
                    |                               |
     pset_A=hash_to_curve(set_A)^sk_A   pset_B=hash_to_curve(set_B)^sk_B
                    |                               |
Step 2:             |                               |
                    |                               |
                    |------------pset_A------------>|
                    |<-----------pset_B-------------|
                    |                               |
Step 3:             |                               |
                    |                               |
          pset_BA=pset_B^sk_A             pset_AB=pset_A^sk_B
                    |                               |
                    |                               |
                    |                               |
Step 4:             |                               |
                    |                               |
                    |-----------pset_BA------------>|
                    |<----------pset_AB-------------|
                    |                               |
Step 5:             |                               |
                    |                               |
    rset_A=intersect(pset_BA,pset_AB)   rset_B=intersect(pset_AB,pset_BA)
                    |                               |
                    |                               |
         output match(set_A,rset_A)       output match(set_B,rset_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.  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 21 August 2025                 [Page 8]

Internet-Draft                  ECDH-PSI                   February 2025


   * Next, in the data exchange phase, both parties perform ECDH-PSI
      operations with parameters selected in the handshake phase, where
      EcdhPsiBatch messages carrying masked EC points are exchanged.

   In the second round, the EcdhPsiBatch message sent from the requester
   is optional since the requester may not allow the responder to output
   the intersection, which is determined in the handshake phase.

              A(requester)                          B(responder)
 -----------------------------------------------------------------------
                   |                                     |
 Handshake Phase:  |                                     |
                   |----------HandshakeRequest---------->|
                   |<---------HandshakeResponse----------|
                   |                                     |
 Data Exchange     |
 Phase:            |                                     |
                   |                                     |
                   |-------------EcdhPsiBatch----------->|
                   |<------------EcdhPsiBatch------------|
                   |                                     |
                   |--------EcdhPsiBatch(optional)------>|
                   |<------------EcdhPsiBatch------------|
                   |                                     |

    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;
       uint8 output_mode;
       uint64 record_num;
       ProtocolProposal protocol_param;
     } HandshakeRequest;

   version: The version of ECDH-PSI protocol.  Currently only value 1 is
   allowed.

   record_num: The number of requester's data records.



Wang, et al.             Expires 21 August 2025                 [Page 9]

Internet-Draft                  ECDH-PSI                   February 2025


   output_mode: Whether the responder is allowed to output the result,
   which also decides whether the optional EcdhPsiBatch is sent in the
   second round.  The meaning of OutputMode is explained as follows:

   *  0: Both parties output the intersection result, which means
      EcdhPsiBatch are sent mutually in the second round.

   *  1: Only the requester outputs PSI result, which means only the
      responder sends EcdhPsiBatch in the second round.

   protocol_param: ECDH-PSI protocol configurations supported by the
   requester.

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_SHA256_SSWU_NU_ (1),
     P384_XMD_SHA384_SSWU_NU_ (2),
     P521_XMD_SHA512_SSWU_NU_ (3),
     curve25519_XMD_SHA512_ELL2_NU_ (4),
     (255)
   } HashToCurveSuite;

   enum { compressed (0), uncompressed  (1), (255) } PointOctetFormat;

   enum {
     no_truncation (0),
     128_bit_truncation (1),
     192_bit_truncation (2),
     (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
   requester's preference.





Wang, et al.             Expires 21 August 2025                [Page 10]

Internet-Draft                  ECDH-PSI                   February 2025


   The suites defined here are slightly different from [RFC9380].  To be
   compatible with the representation language of [RFC8446] where
   enumerate types are defined by C identifiers, the colons (":") are
   replaced with underscores ("_"), and hyphens ("-") in hash functions
   are removed (e.g., "SHA-256" is replaced by "SHA256").

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

   * 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 following the description
      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 order of preference, where no_truncation MUST be
   included.  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 truncation options of 128 and 192-bit are
   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 when 128 bits are
   truncated.  See Section 5.7 for a detailed discussion.  The requester
   MUST set this field to a single no_truncation option when its data
   set size has already been equal or larger than 2^40.





Wang, et al.             Expires 21 August 2025                [Page 11]

Internet-Draft                  ECDH-PSI                   February 2025


   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 jointly masked point, a participant SHOULD
   truncate mask_data with:

   truncated_mask_data = kdf(mask_data, nil, "ECDH-PSI", truncation_len)

   In particular, the KDF takes mask_data as the input keying material
   and truncation_len of 128 or 192 depending on the selected truncation
   option.  It does not take a salt value, uses ASCII string "ECDH-PSI"
   as the application specification information, and outputs the derived
   string as truncation result.  When "ECDH-PSI" string is taken as the
   input for kdf, the terminating null byte SHOULD not be included.

3.2.2.  HandshakeResponse

   The responder sends HandshakeResponse to reply to a HandshakeRequest
   message.  It includes selected parameters and the size of responder's
   dataset.

   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;
     uint64 record_num;
     ProtocolResult protocol_param;
   } HandshakeResponse;





Wang, et al.             Expires 21 August 2025                [Page 12]

Internet-Draft                  ECDH-PSI                   February 2025


   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.

   *  out_of_resource: The responder does not have enough resource to
      handle the ECDH-PSI process with the parameters and 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
   and terminate the session.

   item_num: The size of responder's dataset.

   protocol_param: The protocol parameter selected by the responder,
   including the hash_to_curve suite, EC point string format and
   truncation option.

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.





Wang, et al.             Expires 21 August 2025                [Page 13]

Internet-Draft                  ECDH-PSI                   February 2025


   point_octet_format: The format of EC point octet string chosen by the
   responder.

   truncation_option: The truncation option selected by the responder.
   The responder SHOULD consider the sum of both participants' dataset
   sizes.  If the sum is larger than 2^40, truncation MUST not be used,
   which means the responder MUST set this field to no_truncation.

   When deciding the fields of ProtocolResult, the responder SHOULD
   consider the requester's preference.  That is to say, if multiple
   values of a list are acceptable for the responder, it SHOULD choose
   the topmost one.

3.2.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, which have been
   accepted by international standards such as [ISO-SM2], [ISO-SM3] and
   [RFC8998].  However, if the participants decide to use elliptic curve
   parameter with security level less than 128 bit, or a curve over an
   extension field, they MUST evaluate the security of such parameter
   carefully as discussed by Section 5.

   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





Wang, et al.             Expires 21 August 2025                [Page 14]

Internet-Draft                  ECDH-PSI                   February 2025


   *  r:
      0xfffffffeffffffffffffffffffffffff7203df6b21c6052b53bbf40939d54123

   *  m: 1

   *  k: 128

   *  expand_message: expand_message_xmd (Section 5.3.1 of [RFC9380])

   *  H: SM3

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

3.3.  Data Exchange

   In the data exchange phase, masked EC points are exchanged as
   EcdhPsiBatch messages.  The participants MUST generate fresh ECDH-PSI
   keys after the handshake phase, and use the newly generated keys to
   mask the EC points.  The ECDH-PSI keys SHOULD be removed immediately
   after the data exchange phase in order to prevent leakage or being
   reused by other applications by coincidence.









Wang, et al.             Expires 21 August 2025                [Page 15]

Internet-Draft                  ECDH-PSI                   February 2025


   This phase consists of two rounds.  In the first round, both
   participants send EcdhPsiBatch messages carrying locally masked EC
   points, where the requester sends the first one.  In the second
   round, EcdhPsiBatch messages carrying jointly masked EC points are
   sent.  If the requester sets output_mode field by 1, then only the
   responder sends an EcdhPsiBatch message, otherwise both participant
   sends EcdhPsiBatch messages as in the first round.

   If the participants have negotiated a truncation_option of 128 or 192
   bit in the handshake phase, such option MUST NOT be used in the first
   round, since truncated strings cannot be recovered to EC points,
   which makes the second mask operation completely infeasible.

3.3.1.  EcdhPsiBatch

   The structure of EcdhPsiBatch is defined as follows:

   struct {
     uint64 index;
     opaque encoded_point[encoded_point_length];
   } ECPointOctet;

   struct {
     uint32        batch_type;
     uint64        batch_count;
     ECPointOctet  encoded_points<1..2^64-1>;
   } EcdhPsiBatch;

   batch_type: This field indicates the status of current batch.

   *  0: Error occurs, which means that the current ECDH-PSI session
      MUST be terminated immediately.

   *  1: The data included in the current batch are only masked by the
      owner's private key.

   *  2: The data has been jointly masked with both participants'
      private keys.

   The participant SHOULD check this field first before parsing
   encoded_points field.  If batch_type is 0, or the value is not the
   same as expected, the receiver MUST discard all intermediate results,
   remove the ECDH-PSI key, and terminate the session.

   batch_count: Number of EC points included in the current EcdhPsiBatch
   message.  The receiver SHOULD also check that the value of this field
   is the same as expected and matches the data field.  It MUST
   terminate the session if it is not the case, since an attacker may



Wang, et al.             Expires 21 August 2025                [Page 16]

Internet-Draft                  ECDH-PSI                   February 2025


   send more points than expected so as to obtain some privilege of
   breaking the major privacy goal of ECDH-PSI.  See Section 5.2 for
   more detail.

   encoded_points: 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 octet string
   encoded_point encoding an EC point.  The length of encoded_point,
   which is encoded_point_length, is determined by the hash_to_curve
   suite, the compression option and the truncation option.

   The purpose of index is to associate the original data item with the
   (jointly)-masked EC points, such that the participant can match its
   original dataset with the intersection of masked datasets.  The
   values of index are generated by the owner of data so as to identify
   each data record 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.  Furthermore, Section 5.6 discusses the risk of side
   channels raised by indexes and describes a common countermeasure to
   mitigate such threats.

   The content of encoded_point strings are treated differently in round
   1 and 2.

   *  Round 1: The sender of EcdhPsiBatch SHOULD encode EC points to
      octet strings according to point_octet_format negotiated in the
      handshake phase.  The receiver SHOULD decode the octet strings to
      EC points accordingly.  It MUST check that the EC points are on
      the curve in order to prevent the so-called small group attacks.
      After masking the received set of EC points with its private key,
      the participant SHOULD save the jointly masked points if it is
      allowed to output the intersection.

   *  Round 2: The sender SHOULD encode the points with the negotiated
      point_octet_format, and truncate the string if truncation_option
      is set.  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.  Furthermore, if truncation_option
      is set, the receiver SHOULD also truncate the jointly masked
      dataset stored by round 1 with the same truncation method before
      computing the intersection.

   Especially, to convert the original data records to EC points over
   the curve, the participant SHOULD export ekm from the current TLS
   session as stated by [RFC8446][RFC9266], and map record data to EC
   point P with P=hash_to_curve(ekm||data).



Wang, et al.             Expires 21 August 2025                [Page 17]

Internet-Draft                  ECDH-PSI                   February 2025


4.  Implementation Considerations

4.1.  The Representation of EC Point

   When deciding the point encoding format for the elliptic curves
   except for 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 computation resources to "decompress" the point.
   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 compressed format to minimize the cost of data
   transmission.

4.2.  The Management of Index

   A RECOMMENDED method of maintaining indexes is storing the records
   with a database table and using 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 the index can
   be used to identify a record uniquely.

   This document uses explicit indexes to identify data items rather
   than treating the order of records as "implicit" indexes.  Compared
   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 21 August 2025                [Page 18]

Internet-Draft                  ECDH-PSI                   February 2025


   After masking the EC points from its partner, a participant MUST send
   the jointly 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 prime keys.

4.3.  Large Record Size

   The EcdhPsiBatch message can be very large.  For example, if the
   dataset contains 2^30 records, the size of encoded EC points included
   in a single EcdhPsiBatch message can be over 60 GB.  Participants of
   ECDH-PSI SHOULD take great care when implementing the underlying
   communication channel, and guarantee that there are enough buffer or
   storage space for sending or receiving such messages.

   The methods of sending and handling large messages are beyond the
   scope of this document.

5.  Security Considerations

   For PSI protocols, the foremost security goal is ensuring that the
   private data elements (i.e., records not in the intersection) are not
   revealed.  Neither a protocol partner nor an external attacker can
   obtain such private elements with the protocol.

   This section describes the threat model related to ECDH-PSI,
   discusses the threats of key reuse, MITM attack, replay attack and
   side channel, and finally gives probability bounds related to the
   truncation mechanism.

5.1.  Threat Model

   Traditionally, ECDH-PSI protocols are considered secure under the so-
   called semi-honest setting, where both participants will follow the
   protocol specification, but try to guess each others' private inputs
   by observing the received messages.

   This document considers an extended setting of malicious attackers.
   In such setting, ECDH-PSI cannot guarantee that the participants
   always output correct results, as a malicious participant can send
   arbitrary messages that produce wrong results.  However, it is
   excepted that ECDH-PSI can somehow preserve the main security goal of
   data privacy even under such a setting.





Wang, et al.             Expires 21 August 2025                [Page 19]

Internet-Draft                  ECDH-PSI                   February 2025


   In particular, the threat model considers external attackers who have
   the privilege to access the communication channel between the
   participants, and internal attackers who act a participant of the
   protocol.

   In this document, most external attackers are excluded by TLS
   protocol [RFC8446] with mutual authentication, where the participants
   are authentcated mutually, and the messages are encrypted and
   authenticated.  With the protection of TLS, the external attacker
   will not be able to inject, replay, truncate or manipulate messages
   transferred by the channel.  Any malicious behavior will be detected
   immediately by TLS, and the relevant data will be discarded without
   passing to the application layer.  However, TLS alone cannot prevent
   the Man-In-The-Middle (MITM) attack performed by a malicious node who
   concurrently runs two sessions and forwards messages from one session
   to another, which is discussed by Section 5.4.

   Malicious internal attackers may send arbitrary messages during the
   protocol execution.  That is to say, it may sends:

   *  Malformed handshake messages.

   *  Malformed masked points.

   *  Malformed jointly masked points.

   In fact, malformed handshake message or jointly masked points may
   eliminate the protocol execution due to incorrect message syntaxes or
   mislead the victim to output wrong result, which will not harm the
   major security goal of data privacy.  However, the attacker can use
   malformed masked points to construct a static ECDH oracle, as the
   victim will always mask those points with its own private key and
   send the results back.  That is to say, if P1 is a malformed masked
   EC point sent by the attacker and sk is the victim's secret key used
   in ECDH-PSI, the attacker will get P1^sk.  Once the attacker obtains
   some advantages with the querying process and calculates sk, it can
   immediately calculate sk^-1 and use it to "de-mask" any data masked
   by the victim.

5.2.  Static ECDH Oracle

   In this section, we analysis the risk of static ECDH oracle as
   described by Section 5.1, where each ECDH-PSI session can be utilized
   as an oracle for the ECDH-PSI key used in the current session.  The
   attacker can declare that the size of its dataset is very large, and
   query the oracle as many times as it could.  However, once the
   session ends, the victim will delete the ECDH-PSI key and use a
   freshly generated key for new sessions, which means that the attacker



Wang, et al.             Expires 21 August 2025                [Page 20]

Internet-Draft                  ECDH-PSI                   February 2025


   will query different oracle instances in different sessions.

   In general, let v be the maximum time of querying an oracle instance,
   the static ECDH oracle may decrease the security level of elliptic
   curve by about log(2,v)/2 bits.  The problem of static ECDH oracle
   has been studied extensively in a series of literatures including
   [BG04][Gra10][MU10][JV13].

   For the curves employed by this document, the most efficient attack
   strategy is still the one described by [BG04].  In particular, let u
   and v be a pair of integers satisfying u*v=r-1, the [BG04] attack
   requires the attacker to query the oracle v times and uses

   2(sqrt(u)+sqrt(v))=2(sqrt((r-1)/v)+sqrt(v))

   scalar multiplications to calculate the secret key.  Take the
   relationship that the security level of an elliptic curve group can
   be approximately seen as n=log(2,sqrt(r)), the number of scalar
   multiplications can be seen as 2(2^n/sqrt(v)+sqrt(v)).  However, in
   ECDH-PSI, v is limited by the maximum number of elements holding by
   one of the participants, which is 2^64 since the parameter of
   batch_count is carried by an uint64.  That is to say, for all the
   group parameters employed by this document, 2^n/sqrt(v) will be much
   larger than sqrt(v), and the attacker needs to perform
   2^n/(sqrt(v)/2) multiplications, which approximately means the
   security level will be decreased by log(2,sqrt(v)/2)=log(2,v)/2-1
   bits.  For the maximum value of v, which is 2^64, the conclusion
   indicates that the security level will be decreased by 31 bits.

   For the curves employed by this document, the decrease of 31 bits is
   acceptable, as the minimum security level is 128 bit, which will be
   decreased to 128 - 31 = 97 bits.  Currently, there dose not exist any
   evidence that an elliptic curve with security level of 97 bits is
   vulnerable to practical attacks.  Furthermore, this document does not
   use elliptic curves defined over extension fields which may be
   vulnerable to the more efficient attacks proposed by [Gra10] and
   [JV13].

   [MU10] describes another attack by combing static ECDH oracles with
   the notorious small-group attack.  To prevent such attacks, the
   receiver of a set of EC points MUST checks that every point is on the
   curve, as specified by Section 3.3.









Wang, et al.             Expires 21 August 2025                [Page 21]

Internet-Draft                  ECDH-PSI                   February 2025


5.3.  Key Reuse

   This section discusses the risks of reusing ECDH-PSI key across
   different sessions.  In particular, reusing an ECDH-PSI key may
   decrease the security level of the elliptic curve based on the
   discussion presented by Section 5.2, or be utilized by a semi-honest
   attacker to reveal information related with different protocol runs.

   As shown by Section 5.2, the key point of [BG04] attack strategy is
   the maximum query number for a single oracle instance.  Reusing ECDH-
   PSI key will decrease the security level by much more than 31 bits as
   the allowed number of queries changes to the sum of queries allowed
   by all instances using the same key.  In the worst case where the sum
   of queries is 2^(n/2), the security level will be decreased by almost
   a half.

   If an ECDH-PSI key is reused across sessions, an attacker can
   participate these sessions as partners and obtain some extra
   information.  For instance, the victim V may provide two different
   sets (denoted by set_0 and set_1) in two different sessions, where
   the elements are masked by the same secret key sk as set_0^sk and
   set_1^sk.  Then, the attacker who joins both the sessions can
   calculate intersect(set_0^sk,set_1^sk) and learn the size of
   intersect(set_0,set_1).  Despite that the attacker still cannot
   recover the original set set_0 or set_1, it indeed learns extra
   information beyond the original output of PSI even in the semi-honest
   setting.

5.4.  Man-In-The-Middle Attack

   MITM attack in ECDH-PSI refers to the case that the adversary acts as
   an agent who transmits messages between two honest participants.  If
   the attacker transmits messages faithfully, it finally learns the
   cardinality of the intersection as it obtains the jointly masked
   datasets of both participants.  However, as stated above, the
   attacker cannot break the privacy of original data items as it cannot
   obtain the ECDH-PSI keys with such attacks.

   In this document, such attacks are avoided by the TLS binding
   mechanism [RFC9266].  In particular, the particpants use the
   "tls_exporter" channel binding type to export EKM strings from the
   TLS sessions, and concatenate the EKM string with the original data
   item as input to the hash_to_curve function as specified by
   Section 3.3.

   If the malicious adversary M performs MITM attacks against
   participants A and B, it will establish two different TLS sessions
   denoted by s_a and s_b.  Then, A will export EKM ekm_a from TLS



Wang, et al.             Expires 21 August 2025                [Page 22]

Internet-Draft                  ECDH-PSI                   February 2025


   session s_a, and B will export a different ekm_b from s_b, which
   means that the same data element data will be mapped to different
   points on the curve with P_A=hash_to_curve(ekm_a||data) and
   P_B=hash_to_curve(=ekm_b||data).  The PSI protocol will finally fail
   since the same data item cannot be mapped to the same point on the
   curve, but the attacker also cannot learn the size of the
   intersection, which provides more privacy guarantee beyond the
   secrecy of original data items.

5.5.  Replay Attack

   In [CY20], Cui and Yu design a new attack for concurrent runs of
   ECDH-PSI sessions in the malicious setting.  In this attack, the
   attacker establishes two sessions with the same victim who uses two
   different data sets set_1 and set_2 in different sessions, and
   finally learns the size of intersect(set_1,set_2).

   Let sk_1 and sk_2 denote the ECDH-PSI keys that the victim uses in
   different sessions, the attacker M performs the attack to V as
   follows (also refer to Figure 3):

   *  Step 1: M initiates the first session with V, where V maps all
      elements of set_1 to points as set pset_1, masks them with sk_1,
      and sends mset_1=pset_1^sk_1.

   *  Step 2: M initiates another session with V, and obtains
      mset_2=pset_2^sk_2 as in Step 1.

   *  Step 3: The attacker chooses r_1 and r_2, and masks the sets
      received in Step 1 and 2 with rset_1=mset_1^r_1 and
      rset_2=mset_2^r2.

   *  Step 4: M "reflects" the set received in session 1 to V in session
      2 by sending rset_1 to V in the second session.  Then the victim
      masks rset_1 with its ECDH-PSI key for session 2 and sends
      dset_2=rset_1^sk_2 to the attacker.

   *  Step 5: As in Step 4, the attacker sends rset_2 to the victim in
      session 1, and receives dset_1=rset_2^sk_1.

   *  Step 6: Upon receiving dset_1 and dset_2, the attacker de-
      randomizes the sets with r_2^-1 and r_1^-1 respectively, and
      obtains:

   *  Step 7: M calculates the intersection of vset_1 and vset_2, which
      has the same cardinality with the intersection of set_1 and set_2.





Wang, et al.             Expires 21 August 2025                [Page 23]

Internet-Draft                  ECDH-PSI                   February 2025


   vset_1=dset_1^(r_2^-1)=pset_1^sk_1^sk_2
   vset_2=dset_2^(r_1^-1)=pset_2^sk_2^sk_1

                   V                                     M
      -----------------------------------------------------------------
                   |                                     |
s1:       pset_1=hash_to_curve(set_1)                    |
          mset_1=pset_1^sk_1                             |
                   |               mset_1                |
                   | ----------------------------------> |
                   |                                     |
s2:       pset_2=hash_to_curve(set_2)                    |
          mset_2=pset_2^sk_2                             |
                   |               mset_2                |
                   | ----------------------------------> |
                   |                                     |
                   |                             choose r_1 and r_2
                   |                             rset_1=mset_1^r_1
                   |                             rset_2=mset_2^r_2
                   |                                     |
s2:                |               rset_1                |
                   | <---------------------------------- |
          dset_2=rset_1^sk_2                             |
                   |               dset_2                |
                   | ----------------------------------> |
                   |                                     |
s1:                |               rset_2                |
                   | <---------------------------------- |
          dset_1=rset_2^sk_1                             |
                   |               dset_1                |
                   | ----------------------------------> |
                   |                                     |
                   |                           vset_1=dset_2^(r_1^-1)
                   |                           vset_2=dset_1^(r_2^-1)
                   |                                     |
                   |                    calculate |intersect(vset_1,vset_2)|
                   |                                     |

             Figure 3: The replay attack against ECDH-PSI












Wang, et al.             Expires 21 August 2025                [Page 24]

Internet-Draft                  ECDH-PSI                   February 2025


   The replay attack can also be mitgated with TLS channel binding
   mechanism.  In particular, if the participants adopt TLS channel
   binding as specified by Section 3.3, then, in steps 1 and 2 of the
   replay attack, the victim will extract different EKMs and use them to
   calculate pset_1 and pset_2 respectively.  That is to say, even set_1
   and set_2 contain some common elements, they will be mapped to
   different points in pset_1 and pset_2 as the EKMs are different,
   which finally fails the attacker in step 7 as overlapped elements are
   mapped to different points in vset_1 and vset_2.

5.6.  Side Channel

   In some circumstances, the order of elements and data indexes can be
   utilized by a semi-honest attacker as a side-channel which leaks
   information about the original dataset.  When two participants A and
   B execute ECDH-PSI and output the intersection result, one party
   (say, B) also knows where these common elements appear in A's list
   and their indexes, such orders and indexes can be used to infer the
   orders of inserting those elements to a database table.

   A generic method to avoid such side-channels is shuffling the order
   of elements, as well as the indexes, before they are sent to the
   partner.  However, the shuffling operation may be costly or even
   practically infeasible when the size of dataset is very large.  The
   participant SHOULD evaluate the risk of side-channels and use
   suitable mitigation mechanisms when the risk is unacceptable.

5.7.  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 21 August 2025                [Page 25]

Internet-Draft                  ECDH-PSI                   February 2025


   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 two truncation sizes of 128 bit and 192 bit.  For
   128-bit truncation, the probabilities of different n and d=2^128 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

   For 192-bit truncation, the probabilities are listed as follows:

   *  If n=2^50, p(2^50, 2^192) = 2^-93

   *  If n=2^45, p(2^45, 2^192) = 2^-103

   *  If n=2^41, p(2^41, 2^192) = 2^-111

   *  If n=2^40, p(2^40, 2^192) = 2^-113

   *  If n=2^39, p(2^39, 2^192) = 2^-115

   That is, if the number of records is less than 2^40, the probability
   of false-positive will be smaller than 2^-48 for truncation length of
   128 bit, and smaller than 2^-112 for 192 bit.  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 may need IANA to allocate hash_to_curve identifiers
   which may also be used in other applications.

7.  References



Wang, et al.             Expires 21 August 2025                [Page 26]

Internet-Draft                  ECDH-PSI                   February 2025


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

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





Wang, et al.             Expires 21 August 2025                [Page 27]

Internet-Draft                  ECDH-PSI                   February 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/info/rfc8174>.

   [RFC9266]  Whited, S., "Channel Bindings for TLS 1.3", RFC 9266,
              DOI 10.17487/RFC9266, July 2022,
              <https://www.rfc-editor.org/info/rfc9266>.

   [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

   [BG04]     Brown, D. R. L. and R. P. Gallant, "The Static Diffie-
              Hellman Problem", <https://eprint.iacr.org/2024/306>.

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

   [CY20]     Cui, H. and Y. Yu, "A Not-SO-Trival Replay Attack Against
              DH-PSI", <https://eprint.iacr.org/2020/901.pdf>.

   [draft-irtf-cfrg-vdaf-12]
              Barnes, R., Cook, D., Patton, C., and P. Schoppmann,
              "Verifiable Distributed Aggregation Functions", Work in
              Progress, Internet-Draft, draft-irtf-cfrg-vdaf-12, 4
              October 2024, <https://datatracker.ietf.org/doc/html/
              draft-irtf-cfrg-vdaf-12>.

   [Gra10]    Granger, R., "On the Static Diffie-Hellman Problem on
              Elliptic Curves over Extension Fields", Advances in
              Cryptology - ASIACRYPT 2010.,
              DOI https://doi.org/10.1007/978-3-642-17373-8_17,
              <https://doi.org/10.1007/978-3-642-17373-8_17>.

   [I-D.ietf-ppm-dap]
              Geoghegan, T., Patton, C., Pitman, B., Rescorla, E., and
              C. A. Wood, "Distributed Aggregation Protocol for Privacy
              Preserving Measurement", Work in Progress, Internet-Draft,
              draft-ietf-ppm-dap-12, 10 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-
              12>.





Wang, et al.             Expires 21 August 2025                [Page 28]

Internet-Draft                  ECDH-PSI                   February 2025


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

   [JV13]     Joux, A. and V. Vitse, "Elliptic Curve Discrete Logarithm
              Problem over Small Degree Extension Fields - Application
              to the Static Diffie-Hellman Problem on
              $E(\mathbb{F}_{q{5}})$", Journal of Cryptology, Volume 26,
              pages 119–143, (2013),
              DOI https://doi.org/10.1007/s00145-011-9116-z,
              <https://doi.org/10.1007/s00145-011-9116-z>.

   [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 21 August 2025                [Page 29]

Internet-Draft                  ECDH-PSI                   February 2025


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

   [MU10]     Menezes, A. and B. Ustaoglu, "On reusing ephemeral keys in
              Diffie-Hellman key agreement protocols", International
              Journal of Applied Cryptography (IJACT), Vol. 2, No. 2,
              2010, DOI https://doi.org/10.1504/IJACT.2010.038308,
              <https://doi.org/10.1504/IJACT.2010.038308>.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
              <https://www.rfc-editor.org/info/rfc5056>.

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



Wang, et al.             Expires 21 August 2025                [Page 30]

Internet-Draft                  ECDH-PSI                   February 2025


Authors' Addresses

   Yuchen Wang
   Ant Group
   Email: tianwu.wyc@antgroup.com


   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 21 August 2025                [Page 31]


