# drafts

name: draft-bastian-jose-dvs
rev: 02
title: Public Key Derived HMAC for JOSE
time: 2025-10-12T13:43:19Z
group: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.744710+00:00
source: ietf
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: 10
title: Protecting EST Payloads with OSCORE
time: 2026-03-02T21:36:48Z
group: ace
group_uri: /api/v1/group/group/1921/
expires: 2026-09-03T21:36:48Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.760837+00:00
source: ietf
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: emu
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.773758+00:00
source: ietf
abstract:
  Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology]
     algorithms to make it quantum-safe.

full_text:
  EMU                                                          A. Banerjee
  Internet-Draft                                                  T. Reddy
  Intended status: Standards Track                                   Nokia
  Expires: 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: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.777321+00:00
source: ietf
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: 02
title: KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios
time: 2026-03-02T16:00:56Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T16:00:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.781389+00:00
source: ietf
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: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.785322+00:00
source: ietf
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: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.789097+00:00
source: ietf
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: emu
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.793328+00:00
source: ietf
abstract:
  Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     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: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.797308+00:00
source: ietf
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]


