# drafts

name: draft-gont-dhcwg-dhcpv6-iids
rev: 00
time: 2025-08-14T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2025-08-14T20:40:52Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081760+00:00
source: ietf
title:
  A Method for Generating Semantically Opaque IPv6 Interface Identifiers (IIDs) with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

abstract:
  This document describes a method for selecting IPv6 Interface
     Identifiers that can be employed by Dynamic Host Configuration
     Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6
     addresses to DHCPv6 clients.  This method is a DHCPv6 server-side
     algorithm that does not require any updates to the existing DHCPv6
     specifications.  The aforementioned method results in stable
     addresses within each subnet, even in the presence of multiple DHCPv6
     servers or DHCPv6 server reinstallments.  It is a DHCPv6 variant of
     the method specified in RFC 7217 for IPv6 Stateless Address
     Autoconfiguration (SLAAC).

full_text:
  Dynamic Host Configuration (dhc)                                 F. Gont
  Internet-Draft                                              SI6 Networks
  Obsoletes: 7943 (if approved)                           10 February 2025
  Intended status: Standards Track                                        
  Expires: 14 August 2025


   A Method for Generating Semantically Opaque IPv6 Interface Identifiers
     (IIDs) with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
                      draft-gont-dhcwg-dhcpv6-iids-00

  Abstract

     This document describes a method for selecting IPv6 Interface
     Identifiers that can be employed by Dynamic Host Configuration
     Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6
     addresses to DHCPv6 clients.  This method is a DHCPv6 server-side
     algorithm that does not require any updates to the existing DHCPv6
     specifications.  The aforementioned method results in stable
     addresses within each subnet, even in the presence of multiple DHCPv6
     servers or DHCPv6 server reinstallments.  It is a DHCPv6 variant of
     the method specified in RFC 7217 for IPv6 Stateless Address
     Autoconfiguration (SLAAC).

  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 14 August 2025.

  Copyright Notice

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






  Gont                     Expires 14 August 2025                 [Page 1]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Applicability and Design Goals  . . . . . . . . . . . . . . .   3
     4.  Method Specification  . . . . . . . . . . . . . . . . . . . .   4
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     A number of DHCPv6 implementations are known generate predictable
     IPv6 addressess, such as those resulting from generating addresses as
     a result of global counter.  Additionally, many implementations are
     known to select IPv6 addresses from a small address pool as opposed
     to using the entire IPv6 prefix assigned to the local subnet.

     The security and privacy implications resulting from predictable IPv6
     addresses have been discussed in great detail in [RFC7721], and
     [RFC9416] contains specific advice for protocol specifications
     regarding the generation of transient numeric identifiers such as
     IPv6 addresses.

     While a DHCPv6 server implementation could mitigate the issues
     discussed in [RFC7721] by using a simple randomization scheme for the
     selection of IPv6 addresses, such a scheme would usually result in
     non-stable IPv6 addresses.

     The benefits of stable IPv6 addresses are discussed in [RFC7721].
     Providing address stability across server reinstallations or when a
     database of previous DHCPv6 address leases is unavailable is of use
     not only when a DHCPv6 server must be reinstalled or the address-
     lease database becomes corrupted, but is also of use when
     implementation constraints (e.g., a DHCPv6 server implementation on
     an embedded device) make it impossible for a DHCPv6 server



  Gont                     Expires 14 August 2025                 [Page 2]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


     implementation to maintain a database of previous DHCPv6 address
     leases.  Additionally, [RFC7031] describes scenarios where multiple
     DHCPv6 servers are required to run in such a way as to provide
     increased availability in case of server failures.

     This document describes a method for selecting IPv6 Interface
     Identifiers that can be employed by DHCPv6 servers when leasing non-
     temporary IPv6 addresses to DHCPv6 clients (i.e., to be employed with
     IA_NA options).  This method is a DHCPv6 server-side algorithm that
     does not require any updates to the existing DHCPv6 specifications.
     The aforementioned method has the following properties:

     *  The resulting IPv6 addresses remain stable within each subnet for
        the same network interface of the same client, even when different
        DHCPv6 servers (implementing this specification) are employed, or
        a database of previous DHCPv6 address leases is not available.

     *  Predicting the IPv6 addresses that will be generated by the method
        specified in this document, even with knowledge of the IPv6
        addresses generated for other nodes within the same network,
        becomes very difficult.

     The method specified in this document achieves the aforementioned
     properties by means of a calculated technique as opposed to, e.g.,
     state sharing among DHCPv6 servers.  This approach has already been
     suggested in [RFC7031].  We note that the method described in this
     document is essentially a DHCPv6 version of the "Method for
     Generating Semantically Opaque Interface Identifiers with IPv6
     Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217].
     This document aims to produce a Standards Track specification of the
     algorithm originally specified in [RFC7943].

  2.  Terminology

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

  3.  Applicability and Design Goals

     This document specifies one possible approach for selecting IPv6
     Interface Identifiers to be employed by DHCPv6 servers when leasing
     non-temporary IPv6 addresses to DHCPv6 clients, with the following
     properties:





  Gont                     Expires 14 August 2025                 [Page 3]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


     *  The resulting IPv6 addresses remain stable within each subnet for
        the same network interface of the same client.

     *  The resulting IPv6 addresses cannot be predicted by an attacker
        without knowledge of a secret key.

     *  The resulting IPv6 addresses remain stable across DHCPv6 server
        reinstallations, or even if a database of previous DHCPv6 address
        leases is not available.

     *  The resulting IPv6 addresses remain stable when different DHCPv6
        servers (implementing this specification) are employed on the same
        network.

     NOTE:
        The interoperability properties required for stable IPv6
        addressess generated by DHCPv6 servers are those specified as
        "Category #3: Uniqueness, stable within context (soft failure)" in
        Section 6 of [RFC9415].

     We note that the algorithm specified in this document employs a
     (lightweight) calculated technique (as opposed to, e.g., state
     sharing among DHCPv6 servers) to achieve address stability in
     scenarios where multiple DHCPv6 servers are required to run in such a
     way as to provide increased availability, without the need of an
     additional protocol to synchronize the lease databases of DHCPv6
     servers.

     NOTE:
        The algorithm specified in this document is essentially the
        algorithm specified in Section "7.3.  Category #3: Uniqueness,
        Stable within Context (Soft Failure)" of [RFC9415] where each of
        the algorithm parameters have been selected according to our use
        case.

     Finally, we note that the algorithm in this document is only meant to
     mitigate IPv6 address-based location tracking, device-specific
     vulnerability exploitation, and host scanning (please see [RFC7721]).
     There are a number of ways in which DHCPv6 affects user privacy,
     which the algorithm specified in this document does not mitigate (and
     does not intend to).  Please see [RFC7844] for a comprehensive
     discussion of how DHCPv6 may affect user privacy.

  4.  Method Specification

     Implementations SHOULD provide the means for a system administrator
     to enable or disable the use of this algorithm for generating IPv6
     addresses.



  Gont                     Expires 14 August 2025                 [Page 4]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


     A DHCPv6 server implementing this specification MUST select the IPv6
     addresses to be leased with the following algorithm:

     1.  Compute a random (but stable) identifier with the expression:

         RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)

         Where:

         RID:
            Random (but stable) Identifier

         F():
            A Pseudorandom Function (PRF) that MUST NOT be computable from
            the outside (without knowledge of the secret key).  F() MUST
            also be difficult to reverse, such that it resists attempts to
            obtain the secret key, even when given samples of the output
            of F() and knowledge or control of the other input parameters.
            F() MUST produce an output of at least 64 bits.  F() could be
            implemented as a cryptographic hash of the concatenation of
            each of the function parameters.  The default algorithm to be
            employed for F() SHOULD be SHA-256 [FIPS-SHS].  An
            implementation MAY provide the means for selecting other
            algorithms.  Note: Message Digest 5 (MD5) [RFC1321] is
            considered unacceptable for F() [RFC6151].

         Prefix:
            The prefix employed for the local subnet, as a 128-bit
            unsigned integer in network byte order (with the unused bits
            set to 0).  If multiple servers operate on the same network to
            provide increased availability, all such DHCPv6 servers must
            be configured with the same Prefix.  It is the administrator's
            responsibility that the aforementioned requirement is met.

         |:
            An operator representing "concatenation".

         Client_DUID:
            The DHCPv6 Unique Identifier (DUID) value contained in the
            Client Identifier option received in the DHCPv6 client
            message.  The DUID can be treated as an array of 8-bit
            unsigned integers.

         IAID:
            The Identity Association Identifier (IAID) value contained in
            the IA_NA option received in the client message.  It must be
            interpreted as a 32-bit unsigned integer in network byte
            order.



  Gont                     Expires 14 August 2025                 [Page 5]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


         secret_key:
            A secret key that is not known by the attacker.  The secret
            key SHOULD be of at least 128 bits, and MUST be encoded as an
            array of 8-bit unsigned integers.  Unless explicitly
            configured by the system administrator, it MUST be initialized
            to a pseudo-random number (see [RFC4086] for randomness
            requirements for security) when the DHCPv6 server is installed
            or "bootstrapped" for the first time.  An implementation of
            this specification MUST provide an interface for viewing and
            changing the secret key.  All DHCPv6 servers leasing addresses
            from the same address range MUST employ the same secret key.

         Counter:
            A 32-bit unsigned integer in network byte order that is
            employed to resolve address conflicts.  It must be initialized
            to 0.

     2.  A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by
         concatenating as many bits as necessary from the RID value
         computed in the previous step (starting from the least
         significant bit) to the Prefix employed in the equation above, as
         follows:

             IPV6_ADDR = IPV6_ADDR_LOW +
                         RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1)

         where:

         IPV6_ADDR:
            The candidate IPv6 address to be leased.

         IPV6_ADDR_HI:
            An IPv6 address specifying the upper boundary of the IPv6
            address pool from which the DHCPv6 server leases IPv6
            addresses.  If an address range is not explicitly selected,
            IPV6_ADDR_HI must be set to the IPv6 address from the Prefix
            (see the expression above) that has all of the bits of the
            Interface Identifier set to 1.

         IPV6_ADDR_LOW:
            An IPv6 address specifying the lower boundary of the IPv6
            address pool from which the DHCPv6 server leases IPv6
            addresses.  If an address range is not explicitly selected,
            IPV6_ADDR_LOW must be set to the IPv6 address from the Prefix
            (see the expression above) that has all of the bits of the
            Interface Identifier set to 0.





  Gont                     Expires 14 August 2025                 [Page 6]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


     3.  The Interface Identifier of the selected IPv6 address MUST be
         compared against the reserved IPv6 Interface Identifiers
         [RFC5453] [IANA-RESERVED-IID].  In the event that an unacceptable
         identifier has been generated, the Counter variable SHOULD be
         incremented by 1, and a new IPv6 address SHOULD be computed with
         the updated Counter value.

     4.  If the resulting address is not available (e.g., there is a
         conflicting binding or the address has been marked as
         "decliend"), the DHCPv6 server SHOULD increment the Counter
         variable, and a new Interface Identifier and IPv6 address SHOULD
         be computed with the updated Counter value.

     This document requires that SHA-256 be the default function to be
     used for F(), such that (all other configuration parameters being the
     same) different implementations of this specification result in the
     same IPv6 addresses.

     Including the Prefix in the PRF computation causes the Interface
     Identifier to be different for each address from a different prefix
     leased to the same client.  This mitigates the correlation of
     activities of multihomed nodes (since each of the corresponding
     addresses will employ a different Interface Identifier), host
     tracking (since the network prefix, and therefore the resulting
     Interface Identifier, will change as the node moves from one network
     to another), and any other attacks that benefit from predictable
     Interface Identifiers [RFC7721].

     As required by [RFC8415], an IAID is associated with each of the
     client's network interfaces and is consistent across restarts of the
     DHCPv6 client.

     The Counter parameter provides the means to intentionally cause this
     algorithm to produce different IPv6 addresses (all other parameters
     being the same).  This can be of use to resolve address conflicts
     (e.g., the resulting address having a conflicting binding).

     Note that the result of F() in the algorithm above is no more secure
     than the secret key.  If an attacker is aware of the PRF that is
     being used by the DHCPv6 server (which we should expect), and the
     attacker can obtain enough material (i.e., addresses generated by the
     DHCPv6 server), the attacker may simply search the entire secret-key
     space to find matches.  To protect against this, the secret key
     should be of at least 128 bits.  Key lengths of at least 128 bits
     should be adequate.






  Gont                     Expires 14 August 2025                 [Page 7]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


     Providing a mechanism to display and change the secret_key is crucial
     for having different DHCPv6 servers produce the same IPv6 addresses
     and for causing a replacement system to generate the same IPv6
     addresses as the system being replaced.  We note that since the
     privacy of the scheme specified in this document relies on the
     secrecy of the secret_key parameter, implementations should constrain
     access to the secret_key parameter to the extent practicable (e.g.,
     require superuser privileges to access it).  Furthermore, in order to
     prevent leakages of the secret_key parameter, it should not be used
     for any other purposes than being a parameter to the scheme specified
     in this document.

     We note that all of the bits in the resulting Interface Identifiers
     are treated as "opaque" bits [RFC7136].  For example, the universal/
     local bit of Modified EUI-64 format identifiers is treated as any
     other bit of such identifier.

  5.  Security Considerations

     This document follows the guidance in [RFC9416] for specifying an
     algorithm for the selection of IPv6 addresses by DHCPv6 servers.  The
     method specified in this document results in IPv6 Interface
     Identifiers (and hence IPv6 addresses) that do not follow any
     specific pattern.  Thus, attacks that rely on predictable Interface
     Identifiers (such as [RFC7707]) are mitigated.

     The method specified in this document neither mitigates nor
     exacerbates the security considerations for DHCPv6 discussed in
     [RFC8415] and does not mitigate a range of other privacy implications
     associated with DHCPv6.  Please read [RFC7844] for a comprehensive
     assessment of the privacy implications of DHCPv6.

     Finally, we note that an attacker that is able to attach to each of
     the links to which the victim attaches may still be able to correlate
     the activities of the victim across networks.

     In scenarios where attacks based on DHCPv6-server packets are a
     concern, usage of operational mitigations such as [RFC7610] should be
     considered.

  6.  References

  6.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.



  Gont                     Expires 14 August 2025                 [Page 8]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


     [RFC5453]  Krishnan, S., "Reserved IPv6 Interface Identifiers",
                RFC 5453, DOI 10.17487/RFC5453, February 2009,
                <https://www.rfc-editor.org/info/rfc5453>.

     [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
                Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
                February 2014, <https://www.rfc-editor.org/info/rfc7136>.

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

     [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
                Richardson, M., Jiang, S., Lemon, T., and T. Winters,
                "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
                RFC 8415, DOI 10.17487/RFC8415, November 2018,
                <https://www.rfc-editor.org/info/rfc8415>.

     [RFC9416]  Gont, F. and I. Arce, "Security Considerations for
                Transient Numeric Identifiers Employed in Network
                Protocols", BCP 72, RFC 9416, DOI 10.17487/RFC9416, July
                2023, <https://www.rfc-editor.org/info/rfc9416>.

  6.2.  Informative References

     [FIPS-SHS] Federal Information Processing Standards (FIPS), "Secure
                Hash Standard (SHS)", FIPS 180-4, August 2015,
                <http://csrc.nist.gov/publications/fips/fips180-4/fips-
                180-4.pdf>.

     [IANA-RESERVED-IID]
                IANA, "Reserved IPv6 Interface Identifiers",
                <http://www.iana.org/assignments/ipv6-interface-ids>.

     [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
                DOI 10.17487/RFC1321, April 1992,
                <https://www.rfc-editor.org/info/rfc1321>.

     [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
                for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
                RFC 6151, DOI 10.17487/RFC6151, March 2011,
                <https://www.rfc-editor.org/info/rfc6151>.

     [RFC7031]  Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
                Requirements", RFC 7031, DOI 10.17487/RFC7031, September
                2013, <https://www.rfc-editor.org/info/rfc7031>.





  Gont                     Expires 14 August 2025                 [Page 9]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


     [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
                Interface Identifiers with IPv6 Stateless Address
                Autoconfiguration (SLAAC)", RFC 7217,
                DOI 10.17487/RFC7217, April 2014,
                <https://www.rfc-editor.org/info/rfc7217>.

     [RFC7610]  Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
                Protecting against Rogue DHCPv6 Servers", BCP 199,
                RFC 7610, DOI 10.17487/RFC7610, August 2015,
                <https://www.rfc-editor.org/info/rfc7610>.

     [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance in IPv6
                Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
                <https://www.rfc-editor.org/info/rfc7707>.

     [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
                Considerations for IPv6 Address Generation Mechanisms",
                RFC 7721, DOI 10.17487/RFC7721, March 2016,
                <https://www.rfc-editor.org/info/rfc7721>.

     [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
                Profiles for DHCP Clients", RFC 7844,
                DOI 10.17487/RFC7844, May 2016,
                <https://www.rfc-editor.org/info/rfc7844>.

     [RFC7943]  Gont, F. and W. Liu, "A Method for Generating Semantically
                Opaque Interface Identifiers (IIDs) with the Dynamic Host
                Configuration Protocol for IPv6 (DHCPv6)", RFC 7943,
                DOI 10.17487/RFC7943, September 2016,
                <https://www.rfc-editor.org/info/rfc7943>.

     [RFC9415]  Gont, F. and I. Arce, "On the Generation of Transient
                Numeric Identifiers", RFC 9415, DOI 10.17487/RFC9415, July
                2023, <https://www.rfc-editor.org/info/rfc9415>.

  Acknowledgements

     This document is based on [RFC7943], authored by Fernando Gont and
     Will Liu. The authors would like to thank Marc Blanchet, Stephane
     Bortzmeyer, Tatuya Jinmei, Andre Kostur, Ted Lemon, Tomek Mrugalski,
     Hosnieh Rafiee, Jim Schaad, Jean-Francois Tremblay, Tina Tsou, and
     Bernie Volz for providing valuable comments on that document.

     Fernando Gont would like to thank Nelida Garcia and Jorge Gont for
     their love and support, and Diego Armando Maradona for his magic and
     inspiration.





  Gont                     Expires 14 August 2025                [Page 10]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


  Author's Address

     Fernando Gont
     SI6 Networks
     Segurola y Habana 4310, 7mo Piso
     Villa Devoto
     Ciudad Autonoma de Buenos Aires
     Argentina
     Email: fgont@si6networks.com
     URI:   https://www.si6networks.com









































  Gont                     Expires 14 August 2025                [Page 11]


name: draft-melnikov-sasl2
rev: 02
title: Extensible Simple Authentication and Security Layer (SASL)
time: 2025-06-05T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2025-06-05T12:36:05Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081813+00:00
source: ietf
abstract:
  The Simple Authentication and Security Layer (SASL) is a framework
     for providing authentication and data security services in
     connection-oriented protocols via replaceable mechanisms.  It
     provides a structured interface between protocols and mechanisms.
     The resulting framework allows new protocols to reuse existing
     mechanisms and allows old protocols to make use of new mechanisms.
     The framework also provides a protocol for securing subsequent
     protocol exchanges within a data security layer.

     This document describes how a SASL mechanism is structured, describes
     how protocols include support for SASL, and defines the protocol for
     carrying a data security layer over a connection.  This document also
     defines how servers can request fulfillment of extra authentication
     related tasks, such as two factor authentication and/or password
     change.

full_text:
  Network Working Group                                        D. Cridland
  Internet-Draft                                                          
  Intended status: Standards Track                              T. Molitor
  Expires: 5 June 2025                                                    
                                                                   M. Wild
                                                                          
                                                               A. Melnikov
                                                                 Isode Ltd
                                                           2 December 2024


         Extensible Simple Authentication and Security Layer (SASL)
                          draft-melnikov-sasl2-02

  Abstract

     The Simple Authentication and Security Layer (SASL) is a framework
     for providing authentication and data security services in
     connection-oriented protocols via replaceable mechanisms.  It
     provides a structured interface between protocols and mechanisms.
     The resulting framework allows new protocols to reuse existing
     mechanisms and allows old protocols to make use of new mechanisms.
     The framework also provides a protocol for securing subsequent
     protocol exchanges within a data security layer.

     This document describes how a SASL mechanism is structured, describes
     how protocols include support for SASL, and defines the protocol for
     carrying a data security layer over a connection.  This document also
     defines how servers can request fulfillment of extra authentication
     related tasks, such as two factor authentication and/or password
     change.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 5 June 2025.



  Cridland, et al.           Expires 5 June 2025                  [Page 1]


  Internet-Draft                Extended SASL                December 2024


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
     3.  Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Channel Binding advertisement . . . . . . . . . . . . . . . .   6
     5.  Extra Protocol Requirements . . . . . . . . . . . . . . . . .   7
     6.  Extra Mechanism Requirements  . . . . . . . . . . . . . . . .   8
     7.  Example of a Protocol fulfilling extra requirements . . . . .   8
     8.  Open Issues . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       12.1.  Normative References . . . . . . . . . . . . . . . . . .   9
       12.2.  Informative References . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     The Simple Authentication and Security Layer (SASL) is a framework
     for providing authentication and data security services in
     connection-oriented protocols via replaceable mechanisms.  SASL
     provides a structured interface between protocols and mechanisms.
     SASL also provides a protocol for securing subsequent protocol
     exchanges within a data security layer.  The data security layer can
     provide data integrity, data confidentiality, and other services.

     SASL's design is intended to allow new protocols to reuse existing
     mechanisms without requiring redesign of the mechanisms and allows
     existing protocols to make use of new mechanisms without redesign of
     protocols.





  Cridland, et al.           Expires 5 June 2025                  [Page 2]


  Internet-Draft                Extended SASL                December 2024


     SASL is conceptually a framework that provides an abstraction layer
     between protocols and mechanisms as illustrated in the following
     diagram.

                       SMTP    LDAP    XMPP   Other protocols ...
                          \       |    |      /
                           \      |    |     /
                          SASL abstraction layer
                           /      |    |     \
                          /       |    |      \
                   EXTERNAL   GSSAPI  PLAIN   Other mechanisms ...

     It is through the interfaces of this abstraction layer that the
     framework allows any protocol to utilize any mechanism.  While this
     layer does generally hide the particulars of protocols from
     mechanisms and the particulars of mechanisms from protocols, this
     layer does not generally hide the particulars of mechanisms from
     protocol implementations.  For example, different mechanisms require
     different information to operate, some of them use password-based
     authentication, some of then require realm information, others make
     use of Kerberos tickets, certificates, etc.  Also, in order to
     perform authorization, server implementations generally have to
     implement identity mapping between authentication identities, whose
     form is mechanism specific, and authorization identities, whose form
     is application protocol specific.  Section 2 discusses identity
     concepts.

     It is possible to design and implement this framework in ways that do
     abstract away particulars of similar mechanisms.  Such a framework
     implementation, as well as mechanisms implementations, could be
     designed not only to be shared by multiple implementations of a
     particular protocol but to be shared by implementations of multiple
     protocols.

     Since the publication of [RFC4422] a number of shortcomings in the
     SASL framework were identified that are addressed in this document.
     [[Note that the current draft only shows changes from RFC 4422.]]


     This specification addresses a number of shortfalls in [RFC4422]:

     *  Support for Two-factor authentication (2FA) or Multi-factor
        authentication (MFA) tasks.

     *  Support for mandatory password change tasks.

     *  Channel Binding advertisement.




  Cridland, et al.           Expires 5 June 2025                  [Page 3]


  Internet-Draft                Extended SASL                December 2024


     *  Shared key derivation after successful authentication.

     Extensions to SASL documented herein are primarily to allow for
     better capability discovery, and additional results beyond total
     success or abject failure.

  2.  Conventions Used in This Document

     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.

     Character names in this document use the notation for code points and
     names from the Unicode Standard [Unicode].  For example, the letter
     "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.

     Note: a glossary of terms used in Unicode can be found in [Glossary].
     Information on the Unicode character encoding model can be found in
     [CharModel].

     Example lines prefaced by "C:" are sent by the client and ones
     prefaced by "S:" by the server.  If a single "C:" or "S:" label
     applies to multiple lines, then the line breaks between those lines
     are for editorial clarity only, and are not part of the actual
     protocol exchange.

  3.  Tasks

     A protocol profile might have a way to indicate that while the SASL
     exchange was successful, it is insufficient to allow authentication
     at this time.  We call this indicator a "continue outcome message".
     This can be used to indicate a need to execute extra task(s), for
     example, that the Client needs to perform a Second Factor
     Authentication ("2FA")and/or is required to change password (this
     list is not meant to be exhaustive in any way).

     These tasks are analogous to a SASL mechanism, but have a number of
     differences - they may never attempt to negotiate a new authorization
     identifier, nor a new security layer.

     Each task has a name ([[need to define syntax and maximum length]])
     that SHOULD be registered with IANA.







  Cridland, et al.           Expires 5 June 2025                  [Page 4]


  Internet-Draft                Extended SASL                December 2024


     A client MAY choose any one of the offered tasks; if multiple are
     required, once a task is successfully completed, the server will
     indicate that another one is required, and so on, until all mandatory
     tasks are complete.

     The continue outcome message MAY include SASL mechanism specific
     additional data, as the successful outcome message does.

     Finally, the continue outcome message MAY contain a textual data,
     which contains human-readable data explaining the nature of the step
     required.

     Example 1. Continue Required (using XMPP protocol)

     S: <continue xmlns='urn:xmpp:sasl:2'>
       <additional-data>
         SSdtIGJvcmVkIG5vdy4=
       </additional-data>
       <tasks>
         <task>HOTP-EXAMPLE</task>
         <task>TOTP-EXAMPLE</task>
       </tasks>
       <text>This account requires 2FA</text>
     </continue>


     If any SASL security layer was negotiated, it takes effect after the
     final octet of the first continue outcome message.

     Clients respond with a task initiation message, which has a single
     mandatory parameter containing the selected task name, and MAY
     contain any task specific data.

     Each task MUST end either by the server sending a task failure
     indicator message, if the task failed, a continue outcome message, if
     the task was completed successfully and the server requests the
     client to perform a new task, or a successful outcome message,
     indicating that the task was completed successfully and no further
     tasks are needed.












  Cridland, et al.           Expires 5 June 2025                  [Page 5]


  Internet-Draft                Extended SASL                December 2024


  Example 2. Fictional TOTP task
  <!-- Client starts TOTP-EXAMPLE task -->

  <next xmlns='urn:xmpp:sasl:2' task='TOTP-EXAMPLE'>
    <totp xmlns="urn:totp:example">
      SSd2ZSBydW4gb3V0IG9mIGlkZWFzIGhlcmUu
    </totp>
  </next>

  <!-- Server provides needed data to Client -->
  <task-data xmlns='urn:xmpp:sasl:2'>
    <totp xmlns="urn:totp:example">
      94d27acffa2e99a42ba7786162a9e73e7ab17b9d
    </totp>
  </task-data>

  <!-- Client responds with requested TOP data -->
  <task-data xmlns='urn:xmpp:sasl:2'>
    <totp xmlns="urn:totp:example">
      OTRkMjdhY2ZmYTJlOTlhNDJiYTc3ODYxNjJhOWU3M2U3YWIxN2I5ZAo=
    </totp>
  </task-data>

  <!-- Server indicates successful completion of TOTP-EXAMPLE task -->
  <success xmlns='urn:xmpp:sasl:2'>
    <totp xmlns="urn:totp:example">
      SGFkIHlvdSBnb2luZywgdGhlcmUsIGRpZG4ndCBJPw==
    </totp>
    <authorization-identifier>juliet@montague.example</authorization-identifier>
  </success>

  4.  Channel Binding advertisement

     Most modern SASL mechanism are expected to support channel bindings
     [RFC5056].

     Explicit advertisement of server supported channel binding types
     improves interoperability and is also necessary to prevent certain
     MITM attacks.












  Cridland, et al.           Expires 5 June 2025                  [Page 6]


  Internet-Draft                Extended SASL                December 2024


     Example 3. Channel Binding Type advertisement in XMPP (XEP-0440).
     Note that the <sasl-channel-binding> element is the new channel
     binding advertisement.

     <stream:features>
       <sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'>
         <channel-binding type='tls-server-end-point'/>
         <channel-binding type='tls-exporter'/>
       </sasl-channel-binding>
       <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
         <mechanism>EXTERNAL</mechanism>
         <mechanism>SCRAM-SHA-1-PLUS</mechanism>
         <mechanism>PLAIN</mechanism>
       </mechanisms>
     </stream:features>

  5.  Extra Protocol Requirements

     [[Note that the item number continues the numbering of requirements
     from Section 4 of RFC 4422.]]

     [[Alexey: All of the features below are optional (in order to remain
     backward compatible with RFC 4422).  However if any is implemented,
     all of them MUST be implemented in a protocol.  This makes client
     implementations easier.]]


        9) Facility to advertise the list of Channel Bindings that the
        server supports.  See Section 4.

        10) Facility to issue reuthentication tokens for SASL mechanisms
        that support them.

        11) Detail any task negotiation facility that the protocol
        provides.  [[Alexey: does this need to be done before
        authentication starts, or is it sufficient to discover these at
        the end of SASL mechanism exchange, when specific extra tasks are
        requested?]] A protocol MUST specify a facility through which the
        client may discover, the names of the SASL tasks that the server
        makes available to the client.  This facility is typically
        provided through the protocol's extensions or capabilities
        discovery facility (so that the client can be made aware of which
        tasks might be required to complete authentication before starting
        any authentication), as well as provided at the end of a SASL
        authentication exchange.

        12) Definition of the messages necessary for executing tasks,
        including the following:



  Cridland, et al.           Expires 5 June 2025                  [Page 7]


  Internet-Draft                Extended SASL                December 2024


        a.  A message to initiate execution of a task (see Section 3).
            This message MUST contain a field for carrying the name of the
            task selected by the client.  This message MUST allow for an
            optional field for carrying an initial task related data.  The
            specification MUST describe how messages with an empty initial
            task related data are distinguished from messages with no
            initial task related data.  This field MUST be capable of
            carrying arbitrary sequences of octets (including zero-length
            sequences and sequences containing zero-valued octets).

        b.  Messages to transfer task related data from server and from
            client (see Section 3).  Each of these messages MUST be
            capable of carrying arbitrary sequences of octets (including
            zero-length sequences and sequences containing zero-valued
            octets).

        c.  A message to indicate the outcome of the task execution and
            whether or not execution of further tasks is required by the
            server (see Section 3).  This message MUST allow for an
            optional field for carrying additional data with a successful
            outcome.  The specification MUST describe how messages with an
            empty additional data are distinguished from messages with no
            additional data.  This field MUST be capable of carrying
            arbitrary sequences of octets (including zero- length
            sequences and sequences containing zero-valued octets).

  6.  Extra Mechanism Requirements

     [[Note that the number continues the numbering of requirements from
     Section 5 of RFC 4422.]]


        6) Optional facility for SASL mechanism shared key derivation
        after a successful authentication.

        7) Optional facility for SASL mechanism to generate
        reauthentication token after a successful authentication.

  7.  Example of a Protocol fulfilling extra requirements

     [[Ideally need 2 protocols.  For example XMPP and IMAP.  IMAP can
     have a new command for tasks.]]









  Cridland, et al.           Expires 5 June 2025                  [Page 8]


  Internet-Draft                Extended SASL                December 2024


  8.  Open Issues


  9.  Security Considerations

     TBD

  10.  IANA Considerations

     IANA is requested to create a new subregistry of "SASL tasks" for
     registering SASL tasks as specified in this document.

     The registration template is as follows:


  Task Name: <need to define syntax!>
  Task Type: <define the list of types and whether or not it will be extensible>
  Pointer to specification text:
  Notes (optional):


     The registration procedure for the above registry is Expert Review.

  11.  Acknowledgements

     TBD.  Thank you XSF for XEP-0388, XEP-0440 and XEP-scram-upgrade.

  12.  References

  12.1.  Normative References

     [CharModel]
                Whistler, K. and A. Freytag, "Unicode character encoding
                model", Unicode tr17, 11 November 2022,
                <https://www.unicode.org/reports/tr17/>.

     [Glossary] Consortium, U., "Glossary of Unicode Terms",
                Unicode glossary, 2023,
                <https://www.unicode.org/glossary/>.

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







  Cridland, et al.           Expires 5 June 2025                  [Page 9]


  Internet-Draft                Extended SASL                December 2024


     [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
                Authentication and Security Layer (SASL)", RFC 4422,
                DOI 10.17487/RFC4422, June 2006,
                <https://www.rfc-editor.org/info/rfc4422>.

     [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
                FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
                <https://www.rfc-editor.org/info/rfc4949>.

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

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

     [Unicode]  Consortium, U., "Unicode 15.0.0", Unicode 15.0.0, 13
                September 2022,
                <https://www.unicode.org/versions/Unicode15.0.0/>.

  12.2.  Informative References

     [RFC6238]  M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
                Time-Based One-Time Password Algorithm", RFC 6238,
                DOI 10.17487/RFC6238, May 2011,
                <https://www.rfc-editor.org/info/rfc6238>.

  Authors' Addresses

     Dave Cridland
     Email: dave@cridland.net


     Thilo Molitor
     Email: thilo+xmpp@eightysoft.de


     Matthew Wild
     Email: mwild1@gmail.com


     Alexey Melnikov
     Isode Ltd
     Email: Alexey.Melnikov@isode.com






  Cridland, et al.           Expires 5 June 2025                 [Page 10]


name: draft-ietf-tls-ecdhe-mlkem
rev: 04
title: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
time: 2026-02-17T16:53:57Z
group_uri: /api/v1/group/group/1326/
expires: 2026-08-12T21:50:15Z
ad: /api/v1/person/person/112723/
shepherd: /api/v1/person/email/joe@salowey.net/
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081833+00:00
source: ietf
abstract:
  This draft defines three hybrid key agreement mechanisms for TLS 1.3
     - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that
     combine the post-quantum ML-KEM (Module-Lattice-Based Key
     Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie-
     Hellman) exchange.

states:
  ["/api/v1/doc/state/1/", "/api/v1/doc/state/108/", "/api/v1/doc/state/154/", "/api/v1/doc/state/115/", "/api/v1/doc/state/17/", "/api/v1/doc/state/117/", "/api/v1/doc/state/44/"]

full_text:
  Transport Layer Security                                  K. Kwiatkowski
  Internet-Draft                                                  PQShield
  Intended status: Standards Track                           P. Kampanakis
  Expires: 12 August 2026                                              AWS
                                                          B. E. Westerbaan
                                                                Cloudflare
                                                                D. Stebila
                                                    University of Waterloo
                                                           8 February 2026


         Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
                       draft-ietf-tls-ecdhe-mlkem-04

  Abstract

     This draft defines three hybrid key agreement mechanisms for TLS 1.3
     - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that
     combine the post-quantum ML-KEM (Module-Lattice-Based Key
     Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie-
     Hellman) exchange.

  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://tlswg.github.io/draft-ietf-tls-ecdhe-mlkem/draft-ietf-tls-
     ecdhe-mlkem.html.  Status information for this document may be found
     at https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/tlswg/draft-ietf-tls-ecdhe-mlkem.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.



  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 1]


  Internet-Draft                 ECDHE-MLKEM                 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 12 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.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     4.  Negotiated Groups . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Client share  . . . . . . . . . . . . . . . . . . . . . .   4
       4.2.  Server share  . . . . . . . . . . . . . . . . . . . . . .   5
       4.3.  Shared secret . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Regulatory Context  . . . . . . . . . . . . . . . . . . . . .   6
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
       7.1.  X25519MLKEM768  . . . . . . . . . . . . . . . . . . . . .   7
       7.2.  SecP256r1MLKEM768 . . . . . . . . . . . . . . . . . . . .   7
       7.3.  SecP384r1MLKEM1024  . . . . . . . . . . . . . . . . . . .   7
       7.4.  Obsoleted Supported Groups  . . . . . . . . . . . . . . .   8
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11








  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 2]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


  1.  Introduction

     ML-KEM is a key encapsulation mechanism (KEM) defined in the
     [NIST-FIPS-203].  It is designed to withstand cryptanalytic attacks
     from quantum computers.

     The [hybrid] document defines a framework for combining traditional
     key exchanges with next-generation key exchange in TLS 1.3.  The goal
     of this approach is to provide security against both classical and
     quantum adversaries while maintaining compatibility with existing
     infrastructure and protocols.

     This document applies the framework to ML-KEM and specifies code
     points for the hybrid groups.

  2.  Motivation

     This document introduces three new supported groups for hybrid post-
     quantum key agreements in TLS 1.3: the X25519MLKEM768,
     SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine ML-KEM with
     ECDH in the manner of [hybrid].  Any of the hybrid groups specified
     in this document may be implemented in a FIPS-approved way as
     discussed in Section 5.

     *  The first one uses X25519 [RFC7748], is widely deployed, and often
        serves as the most practical choice for a single post-quantum/
        traditional (PQ/T) hybrid combiner [RFC9794] in TLS 1.3.

     *  The second group uses secp256r1 (NIST P-256) [NIST-FIPS-186].
        This group supports use cases that require both shared secrets to
        be generated by FIPS-approved mechanisms.

     *  The third group uses secp384r1 (NIST P-384) [NIST-FIPS-186].  This
        group is intended for high-security environments that require
        FIPS-approved mechanisms with an increased security margin.

     Key establishment using NIST curves is outlined in Section 6.1.1.2 of
     [NIST-SP-800-56A].

  2.1.  Terminology

     The [hybrid] document defines "traditional" algorithms as those that
     are already widely adopted and "next-generation" algorithms as those
     that are not yet widely adopted, such as post-quantum algorithms.  In
     this document, ECDH using Curve25519, P-256, or P-384 is considered
     traditional, while ML-KEM is considered next-generation.





  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 3]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


     The [hybrid] document also defines a "hybrid" key exchange as the
     simultaneous use of multiple key exchange algorithms, with their
     outputs combined to provide security as long as at least one of the
     component algorithms remains secure, even if the others are
     compromised.  This document uses the term "hybrid" with the same
     meaning.

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

  4.  Negotiated Groups

  4.1.  Client share

     When the X25519MLKEM768 group is negotiated, the client's
     key_exchange value is the concatenation of the client's ML-KEM-768
     encapsulation key and the client's X25519 ephemeral share.  The size
     of the client share is 1216 bytes (1184 bytes for the ML-KEM part and
     32 bytes for X25519).

     Note: The group name X25519MLKEM768 does not adhere to the naming
     convention outlined in Section 3.2 of [hybrid].  Specifically, the
     order of shares in the concatenation has been reversed.  This is due
     to historical reasons.

     When the SecP256r1MLKEM768 group is negotiated, the client's
     key_exchange value is the concatenation of the secp256r1 ephemeral
     share and ML-KEM-768 encapsulation key.  The ECDHE share is the
     serialized value of the uncompressed ECDH point representation as
     defined in Section 4.2.8.2 of [RFC8446].  The size of the client
     share is 1249 bytes (65 bytes for the secp256r1 part and 1184 bytes
     for ML-KEM).

     When the SecP384r1MLKEM1024 group is negotiated, the client's
     key_exchange value is the concatenation of the secp384r1 ephemeral
     share and the ML-KEM-1024 encapsulation key.  The ECDH share is
     serialized value of the uncompressed ECDH point represenation as
     defined in Section 4.2.8.2 of [RFC8446].  The size of the client
     share is 1665 bytes (97 bytes for the secp384r1 part and 1568 for ML-
     KEM).






  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 4]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


  4.2.  Server share

     When the X25519MLKEM768 group is negotiated, the server's key
     exchange value is the concatenation of an ML-KEM ciphertext returned
     from encapsulation to the client's encapsulation key, and the
     server's ephemeral X25519 share.  The size of the server share is
     1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519).

     When the SecP256r1MLKEM768 group is negotiated, the server's key
     exchange value is the concatenation of the server's ephemeral
     secp256r1 share encoded in the same way as the client share and an
     ML-KEM ciphertext returned from encapsulation to the client's
     encapsulation key.  The size of the server share is 1153 bytes (1088
     bytes for the ML-KEM part and 65 bytes for secp256r1).

     When the SecP384r1MLKEM1024 group is negotiated, the server's key
     exchange value is the concatenation of the server's ephemeral
     secp384r1 share encoded in the same way as the client share and an
     ML-KEM ciphertext returned from encapsulation to the client's
     encapsulation key.  The size of the server share is 1665 bytes (1568
     bytes for the ML-KEM part and 97 bytes for secp384r1)

     For all groups, the server MUST perform the encapsulation key check
     described in Section 7.2 of [NIST-FIPS-203] on the client's
     encapsulation key, and abort with an illegal_parameter alert if it
     fails.

     For all groups, the client MUST check if the ciphertext length
     matches the selected group, and abort with an illegal_parameter alert
     if it fails.  If ML-KEM decapsulation fails for any other reason, the
     connection MUST be aborted with an internal_error alert.

     For all groups, both client and server MUST process the ECDH part as
     described in Section 4.2.8.2 of [RFC8446], including all validity
     checks, and abort with an illegal_parameter alert if it fails.

  4.3.  Shared secret

     For X25519MLKEM768, the shared secret is the concatenation of the ML-
     KEM shared secret and the X25519 shared secret.  The shared secret is
     64 bytes (32 bytes for each part).

     For SecP256r1MLKEM768, the shared secret is the concatenation of the
     ECDHE and ML-KEM shared secret.  The ECDHE shared secret is the
     x-coordinate of the ECDH shared secret elliptic curve point
     represented as an octet string as defined in Section 7.4.2 of
     [RFC8446].  The size of the shared secret is 64 bytes (32 bytes for
     each part).



  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 5]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


     For SecP384r1MLKEM1024, the shared secret is the concatenation of the
     ECDHE and ML-KEM shared secret.  The ECDHE shared secret is the
     x-coordinate of the ECDH shared secret elliptic curve point
     represented as an octet string as defined in Section 7.4.2 of
     [RFC8446].  The size of the shared secret is 80 bytes (48 bytes for
     the ECDH part and 32 bytes for the ML-KEM part).

     For all groups, both client and server MUST calculate the ECDH part
     of the shared secret as described in Section 7.4.2 of [RFC8446],
     including the all-zero shared secret check for X25519, and abort the
     connection with an illegal_parameter alert if it fails.

  5.  Regulatory Context

     This section provides informal notes on how the hybrid key agreement
     mechanisms defined in this document relate to existing NIST guidance
     on key derivation and hybrid key establishment.

     *  *FIPS-compliance*. All groups defined in this document permit
        FIPS-approved key derivation as per [NIST-SP-800-56C] and
        [NIST-SP-800-135].  NIST's special publication 800-56Cr2
        [NIST-SP-800-56C] approves the usage of HKDF [RFC5869] with two
        distinct shared secrets, with the condition that the first one is
        computed by a FIPS-approved key-establishment scheme.  FIPS also
        requires a certified implementation of the scheme, which will
        remain more ubiquitous for secp256r1 in the coming years.  For
        this reason, the ML-KEM shared secret is placed first in
        X25519MLKEM768, while the ECDH shared secret is placed first in
        SecP256r1MLKEM768 and SecP384r1MLKEM1024.  This means that for
        SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDH implementation
        must be certified whereas the ML-KEM implementation does not
        require certification.  In contrast, for X25519MLKEM768, the ML-
        KEM implementation must be certified.

     *  *SP800-227 compliance*. The NIST Special Publication 800-227
        [NIST-SP-800-227] provides general guidance on the design and use
        of key-encapsulation mechanisms, including hybrid constructions.
        The key agreements defined in this document follow the principles
        described in Section 4.6 of [NIST-SP-800-227], which discusses the
        combination of post-quantum and classical key-establishment
        schemes and the use of approved key combiners.  In particular, the
        shared-secret concatenation and HKDF-based derivation used by the
        TLS 1.3 are consistent with the composite-KEM constructions and
        key-combiner recommendations outlined in Sections 4.6.1 and 4.6.2
        of [NIST-SP-800-227].  Section 4.6.3 of [NIST-SP-800-227] further
        provides relevant security considerations for hybrid KEM designs
        underlying the approach used in this document.




  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 6]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


  6.  Security Considerations

     The same security considerations as those described in [hybrid] apply
     to the approach used by this document.  The security analysis relies
     crucially on the TLS 1.3 message transcript, and one cannot assume a
     similar hybridisation is secure in other protocols.

     [NIST-SP-800-227] includes guidelines and requirements for
     implementations on using KEMs securely.  Implementers are encouraged
     to use implementations resistant to side-channel attacks, especially
     those that can be applied by remote attackers.

     All groups defined in this document use and generate fixed-length
     public keys, ciphertexts, and shared secrets, which complies with the
     requirements described in Section 6 of [hybrid].

  7.  IANA Considerations

     This document requests/registers three new entries to the TLS
     Supported Groups registry (https://www.iana.org/assignments/tls-
     parameters/tls-parameters.xhtml#tls-parameters-8), according to the
     procedures in Section 6 of [RFC9847].  These identifiers are to be
     used with the final, ratified by NIST, version of ML-KEM which is
     specified in [NIST-FIPS-203].

  7.1.  X25519MLKEM768

     Value:  4588 (0x11EC)
     Description:  X25519MLKEM768
     DTLS-OK:  Y
     Recommended:  N
     Reference:  This document
     Comment:  Combining X25519 ECDH with ML-KEM-768

  7.2.  SecP256r1MLKEM768

     Value:  4587 (0x11EB)
     Description:  SecP256r1MLKEM768
     DTLS-OK:  Y
     Recommended:  N
     Reference:  This document
     Comment:  Combining secp256r1 ECDH with ML-KEM-768

  7.3.  SecP384r1MLKEM1024

     Value:  4589 (0x11ED)
     Description:  SecP384r1MLKEM1024
     DTLS-OK:  Y



  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 7]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


     Recommended:  N
     Reference:  This document
     Comment:  Combining secp384r1 ECDH with ML-KEM-1024

  7.4.  Obsoleted Supported Groups

     Experimental code points for pre-standard versions of Kyber768 were
     added to the TLS registry as X25519Kyber768Draft00 (25497) and
     SecP256r1Kyber768Draft00 (25498).  This document obsoletes these
     entries.  IANA is instructed to modify the recommended field to 'D'
     and update the reference to add [ this RFC ].  The comment fields for
     25497 and 25498 are updated to "Pre-standards version of Kyber768.
     Obsoleted by [this RFC]"

  8.  References

  8.1.  Normative References

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

     [NIST-FIPS-186]
                "Digital Signature Standard (DSS)", National Institute of
                Standards and Technology (U.S.),
                DOI 10.6028/nist.fips.186-5, February 2023,
                <https://doi.org/10.6028/nist.fips.186-5>.

     [NIST-FIPS-203]
                "Module-lattice-based key-encapsulation mechanism
                standard", National Institute of Standards and Technology
                (U.S.), DOI 10.6028/nist.fips.203, August 2024,
                <https://doi.org/10.6028/nist.fips.203>.

     [NIST-SP-800-135]
                Dang, Q., "Recommendation for existing application-
                specific key derivation functions", National Institute of
                Standards and Technology, DOI 10.6028/nist.sp.800-135r1,
                2011, <https://doi.org/10.6028/nist.sp.800-135r1>.

     [NIST-SP-800-227]
                Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A.,
                Silberg, H., and N. Waller, "Recommendations for key-
                encapsulation mechanisms", National Institute of Standards
                and Technology (U.S.), DOI 10.6028/nist.sp.800-227,
                September 2025, <https://doi.org/10.6028/nist.sp.800-227>.



  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 8]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


     [NIST-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", National
                Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-56ar3, April 2018,
                <https://doi.org/10.6028/nist.sp.800-56ar3>.

     [NIST-SP-800-56C]
                Barker, E., Chen, L., and R. Davis, "Recommendation for
                Key-Derivation Methods in Key-Establishment Schemes",
                National Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-56cr2, August 2020,
                <https://doi.org/10.6028/nist.sp.800-56cr2>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

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

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

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

  8.2.  Informative References

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

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

     [RFC9847]  Salowey, J. and S. Turner, "IANA Registry Updates for TLS
                and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
                <https://www.rfc-editor.org/rfc/rfc9847>.




  Kwiatkowski, et al.      Expires 12 August 2026                 [Page 9]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


  Appendix A.  Change log

     *  draft-ietf-tls-ecdhe-mlkem-04:

        -  Status: Sets document category to Standards Track

        -  References: Make [hybrid] normative; add/clarify HKDF reference
           via RFC 5869; update to RFC 9847 (replacing draft-ietf-tls-
           rfc8447bis).

        -  Text: Rename “Discussion” to “Regulatory context” and expand it
           (incl.  NIST SP 800-227 notes).

        -  IANA/TLS registry: Obsoletes the experimental pre-standard
           Kyber768 groups X25519Kyber768Draft00 (25497) and
           SecP256r1Kyber768Draft00 (25498); instruct IANA to set
           Recommended = “D”, update Reference to this RFC, and update
           Comments accordingly.

        -  Editorial: Addressed nits, including normalizing reference
           labels to a consistent format (e.g., RFC7748 instead of rfc7748
           or ad-hoc labels like HKDF) and renaming NIST references to the
           NIST-... form.

     *  draft-ietf-tls-ecdhe-mlkem-01:

        -  Alignment with the final version of [hybrid]

        -  Added new section called Discussion and moved FIPS-compliance
           and Failures text there.

        -  The Construction section has been removed.

     *  draft-ietf-tls-ecdhe-mlkem-00:

        -  Change a name of the draft, following adoption by TLS WG

        -  Fixes references to the to NIST ECC CDH

     *  draft-kwiatkowski-tls-ecdhe-mlkem-03:

        -  Adds P-384 combined with ML-KEM-1024

        -  Adds text that describes error-handling and outlines how the
           client and server must ensure the integrity of the key exchange
           process.





  Kwiatkowski, et al.      Expires 12 August 2026                [Page 10]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


        -  Adds note on the incompatibility of the codepoint name
           X25519MLKEM768 with [hybrid].

        -  Various cosmetic changes.

     *  draft-kwiatkowski-tls-ecdhe-mlkem-02:

        -  Adds section that mentions supported groups that this document
           obsoletes.

        -  Fix a reference to encapsulation in the FIPS 203.

     *  draft-kwiatkowski-tls-ecdhe-mlkem-01:

        -  Add X25519MLKEM768

     *  draft-kwiatkowski-tls-ecdhe-mlkem-00:

        -  Change Kyber name to ML-KEM

        -  Swap reference to I-D.cfrg-schwabe-kyber with FIPS-203

        -  Change codepoint.  New value is equal to old value + 1.

     *  draft-kwiatkowski-tls-ecdhe-kyber-01: Fix size of key shares
        generated by the client and the server

     *  draft-kwiatkowski-tls-ecdhe-kyber-00: updates following IANA
        review

  Authors' Addresses

     Kris Kwiatkowski
     PQShield
     Email: kris@amongbytes.com


     Panos Kampanakis
     AWS
     Email: kpanos@amazon.com


     Bas Westerbaan
     Cloudflare
     Email: bas@cloudflare.com






  Kwiatkowski, et al.      Expires 12 August 2026                [Page 11]


  Internet-Draft                 ECDHE-MLKEM                 February 2026


     Douglas Stebila
     University of Waterloo
     Email: dstebila@waterloo.ca
















































  Kwiatkowski, et al.      Expires 12 August 2026                [Page 12]


name: draft-ietf-lake-edhoc-impl-cons
rev: 06
title: Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC)
time: 2026-03-02T14:46:54Z
group_uri: /api/v1/group/group/2249/
expires: 2026-09-03T14:46:54Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/145/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081851+00:00
source: ietf
abstract:
  This document provides considerations for guiding the implementation
     of the authenticated key exchange protocol Ephemeral Diffie-Hellman
     Over COSE (EDHOC).

full_text:
  LAKE Working Group                                             M. Tiloca
  Internet-Draft                                                   RISE AB
  Intended status: Informational                            7 January 2026
  Expires: 11 July 2026


    Implementation Considerations for Ephemeral Diffie-Hellman Over COSE
                                  (EDHOC)
                     draft-ietf-lake-edhoc-impl-cons-05

  Abstract

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

  Discussion Venues

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

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

     Source for this draft and an issue tracker can be found at
     https://github.com/lake-wg/edhoc-impl-cons.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 11 July 2026.







  Tiloca                    Expires 11 July 2026                  [Page 1]


  Internet-Draft   Implementation Considerations for EDHOC    January 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
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Handling of Invalid EDHOC Sessions and Application Keys . . .   4
       2.1.  EDHOC Sessions Become Invalid . . . . . . . . . . . . . .   5
       2.2.  Application Keys Become Invalid . . . . . . . . . . . . .   5
       2.3.  Application Keys or Bound Access Rights Become Invalid  .   8
     3.  Trust Policies for Learning New Authentication Credentials  .  11
       3.1.  Trust Policy LEARNING . . . . . . . . . . . . . . . . . .  13
       3.2.  Trust Policy NO-LEARNING  . . . . . . . . . . . . . . . .  13
       3.3.  Enforcement of Trust Policies in Specific Scenarios . . .  14
         3.3.1.  In the EDHOC and OSCORE Profile of ACE  . . . . . . .  14
         3.3.2.  In the Lightweight Authorization using EDHOC (ELA)
                 Procedure . . . . . . . . . . . . . . . . . . . . . .  15
     4.  Side Processing of Incoming EDHOC Messages  . . . . . . . . .  16
       4.1.  EDHOC message_1 . . . . . . . . . . . . . . . . . . . . .  19
       4.2.  EDHOC message_4 . . . . . . . . . . . . . . . . . . . . .  20
       4.3.  EDHOC message_2 and message_3 . . . . . . . . . . . . . .  20
         4.3.1.  Pre-Verification Side Processing  . . . . . . . . . .  20
         4.3.2.  Post-Verification Side Processing . . . . . . . . . .  23
         4.3.3.  Flowcharts  . . . . . . . . . . . . . . . . . . . . .  23
       4.4.  Consistency Checks of Authentication Credentials from
             ID_CRED and EAD Items . . . . . . . . . . . . . . . . . .  28
     5.  Using EDHOC over CoAP with Block-Wise . . . . . . . . . . . .  29
       5.1.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .  30
       5.2.  Pre-requirements for the EDHOC + OSCORE Request . . . . .  31
       5.3.  Effectively Using Block-Wise  . . . . . . . . . . . . . .  31
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  33
       6.1.  Assessing the Correctness of Implementations  . . . . . .  33
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  34
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  34
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  35



  Tiloca                    Expires 11 July 2026                  [Page 2]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     Appendix A.  Foreseen Advanced Processing of Incoming EDHOC
             message_1 . . . . . . . . . . . . . . . . . . . . . . . .  37
     Appendix B.  Document Updates . . . . . . . . . . . . . . . . . .  41
       B.1.  Version -04 to -05  . . . . . . . . . . . . . . . . . . .  41
       B.2.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  41
       B.3.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  41
       B.4.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  42
       B.5.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  42
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  42
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  43

  1.  Introduction

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

     During the development of EDHOC, a number of side topics were raised
     and discussed, as emerging from reviews of the protocol latest design
     and from implementation activities.  These topics were identified as
     strongly pertaining to the implementation of EDHOC rather than to the
     protocol in itself.  Hence, they are not discussed in [RFC9528],
     which rightly focuses on specifying the actual protocol.

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

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

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

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









  Tiloca                    Expires 11 July 2026                  [Page 3]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

     *  Effectively using EDHOC over the Constrained Application Protocol
        (CoAP) [RFC7252] in combination with Block-wise transfers for CoAP
        [RFC7959], possibly together with the optimized EDHOC execution
        workflow defined in [RFC9668].  This topic is discussed in
        Section 5.

  1.1.  Terminology

     The reader is expected to be familiar with terms and concepts related
     to the EDHOC protocol [RFC9528], (CoAP) [RFC7252], and Block-wise
     transfers for CoAP [RFC7959].

  2.  Handling of Invalid EDHOC Sessions and Application Keys

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

     *  The EDHOC sessions at that peer; and

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

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

     To provide more concrete guidance, the following considers the case
     where "applications keys" stands for the keying material and
     parameters that compose a Security Context for the security protocol
     Object Security for Constrained RESTful Environments (OSCORE)
     [RFC8613], i.e., when specifically those application keys are derived
     from an EDHOC session (see Appendix A.1 of [RFC9528]).

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



  Tiloca                    Expires 11 July 2026                  [Page 4]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


  2.1.  EDHOC Sessions Become Invalid

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

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

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

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

       Figure 1: Handling of an EDHOC Session that Has Become Invalid.

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

  2.2.  Application Keys Become Invalid

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

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

     *  SET has reached a pre-determined expiration time;

     *  SET has been established to use for an amount of time that is now
        elapsed, according to enforced application policies; or





  Tiloca                    Expires 11 July 2026                  [Page 5]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

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

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

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

         *  The peer P supports a key update protocol, as an alternative
            to performing a new execution of EDHOC with the other peer.
            When SET is an OSCORE Security Context, the key update
            protocol supported by the peer P can be KUDOS
            [I-D.ietf-core-oscore-key-update].

     2.  The application at P runs the key update protocol mentioned at
         Step 1 with the other peer, in order to update SET.  When SET is
         an OSCORE Security Context, the application at P can run the key
         update protocol KUDOS with the other peer.

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

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

         *  It deletes SET.

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

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



  Tiloca                    Expires 11 July 2026                  [Page 6]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     The flowchart in Figure 2 shows the handling of a set of application
     keys that has become invalid.  In particular, it assumes such a set
     to be an OSCORE Security Context and the key update protocol to be
     KUDOS.

    Invalid application keys

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

      |
      | YES
      v

    Install the updated
    application keys

       Figure 2: Handling of a Set of Application Keys that Has Become
                                   Invalid.







  Tiloca                    Expires 11 July 2026                  [Page 7]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


  2.3.  Application Keys or Bound Access Rights Become Invalid

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

     When doing so, one of the two peers acts as ACE resource server (RS)
     hosting protected resources.  The other peer acts as ACE client and
     requests an access token from an ACE authorization server (AS) that
     is in a trust relationship with the RS.  The access token specifies
     access rights for accessing protected resources at the RS as well as
     the public authentication credential of the client, namely
     AUTH_CRED_C.

     After that, C uploads the access token to the RS, by means of an EAD
     item included in an EDHOC message during the EDHOC execution (see
     below).  Alternatively, the AS can upload the access token to the RS
     on behalf of the client, as per the alternative Short Distribution
     Chain (SDC) workflow defined in [I-D.ietf-ace-workflow-and-params].

     Consistent with the EDHOC and OSCORE profile of ACE, the two peers
     run EDHOC in order to specifically derive an OSCORE Security Context
     as their shared set of application keys (see Appendix A.1 of
     [RFC9528]).  At the RS, the access token is bound to the successfully
     completed EDHOC session and to the established OSCORE Security
     Context.

     After that, the peer acting as ACE client can access the protected
     resources hosted at the other peer acting as RS, according to the
     access rights specified in the access token.  The communications
     between the two peers are protected by means of the established
     OSCORE Security Context.

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

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

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




  Tiloca                    Expires 11 July 2026                  [Page 8]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


         *  The access token is still believed to be valid.  That is, it
            has not expired yet and the peer P is not aware that it has
            been revoked.

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

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

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

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

         *  If the access token is not believed to be valid anymore, the
            peer P deletes all the EDHOC sessions associated with the
            access token as well as the OSCORE Security Context derived
            from each of those sessions.

            Note that, when specifically considering the EDHOC and OSCORE
            profile of ACE, an access token is associated with at most one
            EDHOC session (see Section 4.2 of
            [I-D.ietf-ace-edhoc-oscore-profile]).

            If the peer P acted as ACE client, then P obtains from the ACE
            AS a new access token, which is uploaded to the other peer
            acting as ACE RS.

            Finally, the application at P moves to Step 4.

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

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



  Tiloca                    Expires 11 July 2026                  [Page 9]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


            Finally, the application at P moves to Step 4.

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

         At the RS, the access token is bound to this latest EDHOC session
         and the newly established OSCORE Security Context.

     The flowchart in Figure 3 shows the handling of an access token or of
     a set of application keys that have become invalid, when using the
     EDHOC and OSCORE profile of the ACE framework.

   Invalid access token
   specifying AUTH_CRED_C,
   or invalid application keys

     |
     |
     v
                 NO
   Is the       ----> Delete the associated --> Obtain and --> Rerun ---+
   access token       EDHOC sessions and        upload a       EDHOC    |
   still believed     the application keys      new access              |
   to be valid?       derived from those        token            ^      |
     |                                                           |      |
     |                                                           |      |
     |                                                           |      |
     | YES                                                       |      |
     v                                                           |      |
                                                                 |      |
   The application keys                                          |      |
   are not valid anymore                                         |      |
                                                                 |      |
     |                                                           |      |
     |                                                           |      |
     v                                                           |      |
                                                                 |      |
   Are the           NO                                          |      |
   application keys -----> Delete the application keys and ------+      |
   persisted?              the associated EDHOC session                 |
                                                                        |
     |                             ^        ^                           |
     | YES                         |        |                           |
     v                             |        |                           |
                                   |        |                           |
   Is KUDOS      NO                |        |                           |



  Tiloca                    Expires 11 July 2026                 [Page 10]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


   supported? ---------------------+        |                           v
                                            |
     |                                      |           Derive and install
     | YES                                  |         new application keys
     v                                      |
                                            |
   Run KUDOS                                |
                                            |
     |                                      |
     |                                      |
     v                                      |
                                            |
   Has KUDOS     NO                         |
   succeeded? ------------------------------+

     |
     | YES
     v

   Install the updated
   application keys

      Figure 3: Handling of an Access Token or of a Set of Application
                       Keys that Have Become Invalid.

  3.  Trust Policies for Learning New Authentication Credentials

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

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

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











  Tiloca                    Expires 11 July 2026                 [Page 11]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     Also during the EDHOC execution, an External Authorization Data (EAD)
     field might include an EAD item that specifies CRED by value or
     reference.  This is the case, e.g., for the EAD items defined by the
     EDHOC and OSCORE profile of the ACE framework
     [I-D.ietf-ace-edhoc-oscore-profile].  In particular, they can be used
     for transporting (a reference to) an access token, which in turn
     specifies by value or by reference the public authentication
     credential associated with the EDHOC peer acting as ACE client.

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

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

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

     When processing a received EDHOC message M that specifies an
     authentication credential CRED, the peer P can enforce one of the
     trust policies LEARNING and NO-LEARNING specified in Section 3.1 and
     Section 3.2, in order to determine whether to trust CRED.

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

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










  Tiloca                    Expires 11 July 2026                 [Page 12]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

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

  3.1.  Trust Policy LEARNING

     When enforcing the LEARNING policy, the peer P trusts CRED even if P
     is not already storing CRED at message reception time.

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

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

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

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

  3.2.  Trust Policy NO-LEARNING

     When enforcing the NO-LEARNING policy, the peer P trusts CRED only if
     P is already storing CRED at message reception time, unless in cases
     where situation-specific exceptions apply and are deliberately
     enforced (see below).

     That is, upon receiving M, the peer P continues the execution of
     EDHOC only if both the following conditions hold:

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



  Tiloca                    Expires 11 July 2026                 [Page 13]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

     Exceptions may apply and be actually enforced in cases where, during
     an EDHOC execution, P obtains additional information that allows it
     to trust and successfully validate CRED, even though CRED is not
     already stored upon receiving M.

     Such exceptions typically rely on a trusted party that vouches for
     CRED, e.g., in the cases discussed in Section 3.3.  From the point of
     view of the peer P, the trusted party might have been involved in the
     background, so that the vouching information about CRED is conveyed
     within an EDHOC message received during the EDHOC session (e.g.,
     transported by an EAD item).  Alternatively, P might directly
     interact with the trusted party for retrieving the vouching
     information about CRED, e.g., after having received M and before
     continuing the EDHOC execution.

     If the peer P admits such an exception and actually enforces it on an
     authentication credential CRED, then P effectively handles CRED
     according to the trust policy "LEARNING" specified in Section 3.1.
     When doing so, P still attempts to validate CRED, and it aborts the
     EDHOC session if the validation process is not successful.

  3.3.  Enforcement of Trust Policies in Specific Scenarios

     The following subsections discuss how an EDHOC peer enforces the
     trust policies LEARNING and NO-LEARNING in specific scenarios.

  3.3.1.  In the EDHOC and OSCORE Profile of ACE

     As discussed in Section 2.3, two EDHOC peers can be using the ACE
     framework [RFC9200] and specifically the EDHOC and OSCORE profile of
     ACE defined in [I-D.ietf-ace-edhoc-oscore-profile].

     In this case, one of the two EDHOC peers, namely PEER_RS, acts as ACE
     resource server (RS).  Instead, the other EDHOC peer, namely PEER_C,
     acts as ACE client and obtains from an ACE authorization server (AS)
     an access token for accessing protected resources at PEER_RS.  The AS
     and PEER_RS are in a trust relationship.











  Tiloca                    Expires 11 July 2026                 [Page 14]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     Together with other information, the access token specifies (by value
     or by reference) the public authentication credential AUTH_CRED_C
     associated with PEER_C that PEER_C is going to use when running EDHOC
     with PEER_RS.  Note that AUTH_CRED_C will be used as either CRED_I or
     CRED_R in EDHOC, depending on whether the two peers use the EDHOC
     forward message flow (i.e., PEER_C is the EDHOC Initiator) or the
     EDHOC reverse message flow (i.e., PEER_C is the EDHOC Responder),
     respectively (see Appendix A.2 of [RFC9528]).

     When the AS issues the first access token that specifies AUTH_CRED_C
     and is intended to be uploaded to PEER_RS, it is expected that the
     access token specifies AUTH_CRED_C by value and that PEER_RS is not
     currently storing AUTH_CRED_C, but instead will obtain it and learn
     it upon receiving the access token.

     Although the AS can upload the access token to PEER_RS on behalf of
     PEER_C as per the alternative SDC workflow defined in
     [I-D.ietf-ace-workflow-and-params], the access token is typically
     uploaded to PEER_RS by PEER_C through a dedicated EAD item, when
     running EDHOC with PEER_RS.  Consequently, PEER_RS has to learn
     AUTH_CRED_C as a new authentication credential during an EDHOC
     session with PEER_C.

     At least for its EDHOC resource used for exchanging the EDHOC
     messages of the EDHOC session in question, this requires PEER_RS to:

     *  Enforce the trust policy "LEARNING"; or

     *  If enforcing the trust policy "NO-LEARNING", additionally enforce
        an overriding exception when an incoming EDHOC message includes an
        EAD item conveying (a reference to) a valid access token issued by
        a trusted AS.

        That is, through a successful verification of the access token,
        PEER_RS is able to trust AUTH_CRED_C (if found valid), even though
        it did not already store AUTH_CRED_C upon receiving the EDHOC
        message with the EAD item.

  3.3.2.  In the Lightweight Authorization using EDHOC (ELA) Procedure

     When the execution of EDHOC embeds the ELA procedure defined in
     [I-D.ietf-lake-authz], the EDHOC peer U receives an EDHOC message_2
     (message_3) where ID_CRED_R (ID_CRED_I) specifies by value the
     authentication credential CRED associated with the other peer V.

     In the same EDHOC message, an EAD item specifies a voucher issued by
     a trusted enrollment server W.  The voucher is an assertion to U that
     W has authorized V and has endorsed CRED.



  Tiloca                    Expires 11 July 2026                 [Page 15]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     Through a successful verification of the voucher, U is able to trust
     CRED (if found valid), even though it did not already store CRED upon
     receiving the EDHOC message.

     Therefore, if U enforces the trust policy "NO-LEARNING", it can
     additionally enforce an overriding exception when an incoming EDHOC
     message includes an EAD item conveying a valid voucher issued by a
     trusted enrollment server.

  4.  Side Processing of Incoming EDHOC Messages

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

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

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

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

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

     *  It is possible that some EAD items can be processed only after
        having successfully verified the EDHOC message, i.e., after a
        successful verification of the Signature_or_MAC field in EDHOC
        message_2 or message_3.







  Tiloca                    Expires 11 July 2026                 [Page 16]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

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

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

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

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

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

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

     *  The authentication credentials that the peer P stores as
        associated with other peers.

     *  All the decrypted information elements retrieved from M.

     *  The EAD items included in M.

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




  Tiloca                    Expires 11 July 2026                 [Page 17]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

           If no such EAD items are found, EDHOC can remove any padding
           EAD item (see Section 3.8.1 of [RFC9528]), as well as any EAD
           item which is neither critical nor recognized (since the SPO is
           going to ignore it anyway).  This results in EDHOC providing
           the SPO only with EAD items that will be recognized and that
           require actual processing.

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

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

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

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

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

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

        -  The consumption of EAD items included in M.

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

     In the following, Section 4.1 to Section 4.3 describe more in detail
     the actions performed by the SPO on the different incoming EDHOC
     messages.  Then, Section 4.4 describes further special handling of
     incoming EDHOC messages, as to consistency checks concerning
     authentication credentials in particular situations.






  Tiloca                    Expires 11 July 2026                 [Page 18]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     After completing the EDHOC execution, control is transferred back to
     the application.  In particular, the application is provided with the
     overall outcome of the EDHOC execution (i.e., successful completion
     or failure), together with possible specific results produced by the
     SPO throughout the EDHOC execution (e.g., due to the processing of
     EAD items).

     After that, the application might need to perform follow-up actions,
     depending on the outcome of the EDHOC execution.  For example, the
     SPO might have preliminarily filled application-level data
     structures, as a result of processing EAD items.  In case of
     successful EDHOC execution, the application might need to finalize
     such data structures.  Instead, in case of unsuccessful EDHOC
     execution, the application might need to clean-up or amend such data
     structures, or even roll back what the SPO did, unless the SPO
     already performed such actions before control was transferred back to
     the application.

  4.1.  EDHOC message_1

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

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

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

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

     Future extensions of EDHOC or external security applications
     integrated into EDHOC might require a processing of EDHOC message_1
     that is more advanced than the currently expected one.  In
     particular, an EAD item conveyed in EDHOC message_1 might specify the
     authentication credential CRED associated with the Initiator (by
     value or by reference), as wrapped in a cryptographically protected
     "envelope".  In such a case, the processing of an incoming EDHOC
     message_1 shares similarities with that of an incoming EDHOC
     message_2 or message_3 (see Section 4.3), as it is further elaborated
     in Appendix A.







  Tiloca                    Expires 11 July 2026                 [Page 19]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


  4.2.  EDHOC message_4

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

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

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

  4.3.  EDHOC message_2 and message_3

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

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

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

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

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

  4.3.1.  Pre-Verification Side Processing

     The pre-verification side processing occurs in two sequential phases,
     namely PHASE_1 (see Section 4.3.1.1) and PHASE_2 (see
     Section 4.3.1.2).

  4.3.1.1.  PHASE_1

     During PHASE_1, the SPO at the recipient peer P determines CRED,
     i.e., the authentication credential associated with the other peer to
     be used in the ongoing EDHOC session.  In particular, the SPO
     performs the following steps.





  Tiloca                    Expires 11 July 2026                 [Page 20]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

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

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

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

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

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

     3.   The SPO attempts to retrieve CRED via ID_CRED_X or an EAD item
          considered at Step 1.  Then, the SPO moves to Step 4.

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

     5.   If the enforced trust policy for new authentication credentials
          is "NO-LEARNING" and P does not admit any exceptions that are
          acceptable to enforce for message_X (see Section 3.2), the SPO
          moves to Step 11.  Otherwise, the SPO moves to Step 6.

     6.   If this step has been reached, the peer P is not already storing
          the retrieved CRED and, at the same time, it enforces either the
          trust policy "LEARNING" or the trust policy "NO-LEARNING" while
          also enforcing an exception acceptable for message_X (see
          Section 3.2).

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










  Tiloca                    Expires 11 July 2026                 [Page 21]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

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

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

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

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

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

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

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

  4.3.1.2.  PHASE_2

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

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

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

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



  Tiloca                    Expires 11 July 2026                 [Page 22]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


  4.3.2.  Post-Verification Side Processing

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

     The late processing of such EAD items is typically due to the fact
     that a pre-requirement has to be fulfilled first.

     For example, the recipient peer P has to have first verified that the
     other peer does possess the private key corresponding to the public
     key specified by CRED, i.e., the authentication credential associated
     with the other peer that was determined during the pre-verification
     side processing (see Section 4.3.1).  This requirement is fulfilled
     after a successful verification of message_X.

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

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

  4.3.3.  Flowcharts

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

   Incoming
   EDHOC message_X
   (X = 2 or 3)

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



  Tiloca                    Expires 11 July 2026                 [Page 23]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

          Figure 4: High-Level Interaction Between the Core EDHOC
         Processing and the Side-Processor Object (SPO), for EDHOC
                          message_2 and message_3.

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

      Incoming
      EDHOC message_X
      (X = 2 or 3)

              |
              |
              v
     +-------------------+  ---+
     | Decode message_X  |     |



  Tiloca                    Expires 11 July 2026                 [Page 24]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     +-------------------+     |
              |                |
              |                |
              v                |
     +-------------------+     |
     | Retrieve the      |     +--- (Core EDHOC Processing)
     | protocol state    |     |
     +-------------------+     |
              |                |
              |                |
              v                |
     +-------------------+     |
     | Decrypt message_X |     |
     +-------------------+  ---+
              |
              |

     Control transferred to
     the side-processor object

              |
    +---------|----------------------------------------------------------+
    |         |            Pre-verification side processing (PHASE_1)    |
    |         v                                                          |
    | +---------------------+     +--------------+     +-------------+   |
    | | 1. Does ID_CRED_X   | NO  | 3. Retrieve  |     | 4. Is the   |   |
    | | or an EAD item      |---->| CRED via     |---->| retrieval   |   |
    | | point to an already |     | ID_CRED_X or |     | of CRED     |   |
    | | stored CRED?        |     | an EAD item  |     | successful? |   |
    | +---------------------+     +--------------+     +-------------+   |
    |         |                                          |         |     |
    |         |                                          | NO      | YES |
    |         |                         +----------------+         |     |
    |         |                         |                          |     |
    |         | YES                     |                          |     |
    |         v                         v                          v     |
    | +-----------------+ NO      +-----------+   YES +----------------+ |
    | | 2. Is this CRED |-------->| 11. Abort |<------| 5. Is the used | |
    | | still valid?    |         | the EDHOC |       | trust policy   | |
    | +-----------------+         | session   |       | "NO-LEARNING", | |
    |         |                   |           |       | without any    | |
    |         |                   |           |       | acceptable     | |
    |         |                   |           |       | exceptions?    | |
    |         |                   |           |       +----------------+ |
    |         | YES               |           |                    |     |
    |         v                   |           |    Here the used   | NO  |
    | +--------------------+ NO   |           |    trust policy is |     |
    | | 9. Is this CRED    |----->|           |    "LEARNING", or  |     |



  Tiloca                    Expires 11 July 2026                 [Page 25]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


    | | good to use in the |      +-----------+    "NO-LEARNING"   |     |
    | | context of this    |               ^       together with   |     |
    | | EDHOC session?     |<-----+        |       an overriding   |     |
    | +--------------------+      |        |       exception       |     |
    |         |                   |        |                       |     |
    |         |                   |        |                       v     |
    |         |                   |        |             +-------------+ |
    |         |                   |        |             | 6. Validate | |
    |         |                   |        |             | CRED        | |
    |         |                   |        |             +-------------+ |
    |         |                   |        |                       |     |
    |         | YES               |        | NO                    |     |
    |         |                   |        |                       v     |
    |         |                   |     +------------------------------+ |
    |         |                   |     | 7. Is CRED valid?            | |
    |         |                   |     +------------------------------+ |
    |         |                   |        |                             |
    |         |                   |        | YES                         |
    |         v                   |        v                             |
    | +------------------+        |     +------------------------------+ |
    | | 10. Continue by  |        |     | 8. Store CRED as valid and   | |
    | | considering this |        +-----| trusted.                     | |
    | | CRED as the      |              |                              | |
    | | authentication   |              | Pair CRED with consistent    | |
    | | credential       |              | credential identifiers, for  | |
    | | associated with  |              | each supported type of       | |
    | | the other peer   |              | credential identifier.       | |
    | +------------------+              +------------------------------+ |
    |         |                                                          |
    +---------|----------------------------------------------------------+
              |
              |
    +---------|----------------------------------------------------------+
    |         |            Pre-verification side processing (PHASE_2)    |
    |         v                                                          |
    | +--------------------------------------------------------+         |
    | | Process the EAD items that have not been processed yet |         |
    | | and that can be processed before message verification  |         |
    | +--------------------------------------------------------+         |
    |         |                                                          |
    +---------|----------------------------------------------------------+
              |
              |
              v

     Control transferred back
     to the core EDHOC processing




  Tiloca                    Expires 11 July 2026                 [Page 26]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

     Control transferred to
     the side-processor object

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

     Control transferred back
     to the core EDHOC processing

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

        Figure 5: Processing Steps for EDHOC message_2 and message_3.





  Tiloca                    Expires 11 July 2026                 [Page 27]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


  4.4.  Consistency Checks of Authentication Credentials from ID_CRED and
        EAD Items

     Typically, an EDHOC peer specifies its associated authentication
     credential (by value or by reference) only in the ID_CRED field of
     EDHOC message_2 (if acting as Responder) or EDHOC message_3 (if
     acting as Initiator).

     In addition to that, there may be cases where an EDHOC peer provides
     the authentication credential also in an EAD item.  In particular,
     such an EAD item can specify a cryptographically protected "envelope"
     (by value or by reference), which in turn specifies the
     authentication credential (by value or by reference).

     A case in point is the EDHOC and OSCORE profile of the ACE framework
     [I-D.ietf-ace-edhoc-oscore-profile], where the envelope in question
     is an access token issued to the ACE client.  In such a case, the ACE
     client can rely on an EAD item specifying the access token by value,
     or instead on a different EAD item specifying a session identifier as
     a reference to such access token.  In either case, the access token
     specifies the authentication credential (by value or by reference)
     associated with the client.

     During an EDHOC session, an EDHOC peer P1 might therefore receive the
     authentication credential CRED associated with the other EDHOC peer
     P2 as specified by two items:

     *  ITEM_A: the ID_CRED field specifying CRED.  If P2 acts as
        Initiator (Responder), then ITEM_A is the ID_CRED_I (ID_CRED_R)
        field.

     *  ITEM_B: the envelope specified in an EAD item within an EDHOC
        message sent by P2.

     As part of the process where P1 validates CRED during the EDHOC
     session, P1 must check that both ITEM_A and ITEM_B specify the same
     authentication credential, and it must abort the EDHOC session if
     such a consistency check fails.

     The consistency check is successful only if one of the following
     conditions holds and it fails otherwise:

     *  If both ITEM_A and ITEM_B specify an authentication credential by
        value, then both ITEM_A and ITEM_B specify the same value.







  Tiloca                    Expires 11 July 2026                 [Page 28]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     *  If one among ITEM_A and ITEM_B specifies an authentication
        credential by value VALUE while the other one specifies an
        authentication credential by reference REF, then REF is a valid
        reference for VALUE.

     *  If ITEM_A specifies an authentication credential by reference
        REF_A and ITEM_B specifies an authentication credential by
        reference REF_B, then REF_A or REF_B allows to retrieving the
        value VALUE of an authentication credential from a local or remote
        storage, such that both REF_A and REF_B are a valid reference for
        VALUE.

     The peer P1 performs the consistency check above as soon as it has
     both ITEM_A and ITEM_B available.  If P1 acts as Responder, that is
     the case when processing the incoming EDHOC message_3.  If P1 acts as
     Initiator, that is the case when processing the incoming EDHOC
     message_2 or message_4, i.e., whichever of the two messages includes
     ITEM_B in an EAD item of its EAD field.

  5.  Using EDHOC over CoAP with Block-Wise

     Appendix A.2 of [RFC9528] specifies how to transfer EDHOC over CoAP
     [RFC7252].  In such a case, the EDHOC messages (possibly prepended by
     an EDHOC connection identifier) are transported in the payload of
     CoAP requests and responses, according to the EDHOC forward message
     flow or the EDHOC reverse message flow.  Furthermore, Appendix A.1 of
     [RFC9528] specifies how to derive an OSCORE Security Context
     [RFC8613] from an EDHOC session.

     Building on that, [RFC9668] further details the use of EDHOC with
     CoAP and OSCORE.  In particular, it specifies an optimization
     approach for the EDHOC forward message flow that combines the EDHOC
     execution with the first subsequent OSCORE transaction.  This is
     achieved by means of an "EDHOC + OSCORE request", i.e., a single CoAP
     request message that conveys both EDHOC message_3 of the ongoing
     EDHOC session and the OSCORE-protected application data, where the
     latter is protected with the OSCORE Security Context derived from
     that EDHOC session.

     This section provides guidelines and recommendations for CoAP
     endpoints supporting Block-wise transfers for CoAP [RFC7959] and
     specifically for CoAP clients supporting the EDHOC + OSCORE request
     defined in [RFC9668].  The use of Block-wise transfers can be
     desirable, e.g., for EDHOC messages that include a large ID_CRED_I or
     ID_CRED_R, or that include a large EAD field.






  Tiloca                    Expires 11 July 2026                 [Page 29]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     The following especially considers a CoAP endpoint that may perform
     only "inner" Block-wise, but not "outer" Block-wise operations (see
     Section 4.1.3.4 of [RFC8613]).  That is, the considered CoAP endpoint
     does not (further) split an OSCORE-protected message like an
     intermediary (e.g., a proxy) might do.  This is the typical case for
     CoAP endpoints using OSCORE (see Section 4.1.3.4 of [RFC8613]).

  5.1.  Notation

     The rest of this section refers to the following notation:

     *  SIZE_BODY: the size in bytes of the data to be transmitted with
        CoAP.  When Block-wise is used, such data is referred to as the
        "body" to be fragmented into blocks, each of which to be
        transmitted in one CoAP message.

        With the exception of EDHOC message_3, the considered body can
        also be an EDHOC message, possibly prepended by an EDHOC
        connection identifier encoded as per Section 3.3 of [RFC9528].

        When specifically using the EDHOC + OSCORE request, the considered
        body is the application data to be protected with OSCORE, (whose
        first block is) to be sent together with EDHOC message_3 as part
        of the EDHOC + OSCORE request.

     *  SIZE_EDHOC_M3: the size in bytes of EDHOC message_3, if this is
        sent as part of the EDHOC + OSCORE request.  Otherwise, the size
        in bytes of EDHOC message_3, plus, if included, the size in bytes
        of a prepended EDHOC connection identifier encoded as per
        Section 3.3 of [RFC9528].

     *  SIZE_MTU: the maximum amount of transmittable bytes before having
        to use Block-wise.  This is, for example, 64 KiB as maximum
        datagram size when using UDP, or 1280 bytes as the maximum size
        for an IPv6 MTU.

     *  SIZE_OH: the size in bytes of the overall overhead due to all the
        communication layers underlying the application.  This takes into
        account also the overhead introduced by the OSCORE processing.

     *  LIMIT = (SIZE_MTU - SIZE_OH): the practical maximum size in bytes
        to be considered by the application before using Block-wise.

     *  SIZE_BLOCK: the size in bytes of inner blocks.

     *  ceil(): the ceiling function.





  Tiloca                    Expires 11 July 2026                 [Page 30]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


  5.2.  Pre-requirements for the EDHOC + OSCORE Request

     Before sending an EDHOC + OSCORE request, a CoAP client has to
     perform the following checks.  Note that, while the CoAP client is
     able to fragment the plain application data before any OSCORE
     processing, it cannot fragment the EDHOC + OSCORE request or the
     EDHOC message_3 added therein.

     *  If inner Block-wise is not used, hence SIZE_BODY <= LIMIT, the
        CoAP client must verify whether all the following conditions hold:

        -  COND1: SIZE_EDHOC_M3 <= LIMIT

        -  COND2: (SIZE_BODY + SIZE_EDHOC_M3) <= LIMIT

     *  If inner Block-wise is used, the CoAP client must verify whether
        all the following conditions hold:

        -  COND3: SIZE_EDHOC_M3 <= LIMIT

        -  COND4: (SIZE_BLOCK + SIZE_EDHOC_M3) <= LIMIT

     In either case, if not all the corresponding conditions hold, the
     CoAP client should not send the EDHOC + OSCORE request.  Instead, the
     CoAP client can continue by switching to the purely sequential,
     original EDHOC workflow (see Appendix A.2.1 of [RFC9528]).  That is,
     the CoAP client first sends EDHOC message_3 prepended by the EDHOC
     Connection Identifier C_R encoded as per Section 3.3 of [RFC9528] and
     then sends the OSCORE-protected CoAP request once the EDHOC execution
     is completed.

  5.3.  Effectively Using Block-Wise

     In order to avoid further fragmentation at lower layers when sending
     an EDHOC + OSCORE request, the CoAP client has to use inner Block-
     wise if _any_ of the following conditions holds:

     *  COND5: SIZE_BODY > LIMIT

     *  COND6: (SIZE_BODY + SIZE_EDHOC_M3) > LIMIT

     In particular, consistently with Section 5.2, the SIZE_BLOCK used has
     to be such that the following condition also holds:

     *  COND7: (SIZE_BLOCK + SIZE_EDHOC_M3) <= LIMIT

     Note that the CoAP client might still use Block-wise due to reasons
     different from exceeding the size indicated by LIMIT.



  Tiloca                    Expires 11 July 2026                 [Page 31]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     The following shows the number of round trips for completing both the
     EDHOC execution and the first OSCORE-protected exchange, under the
     assumption that the exchange of EDHOC message_1 and EDHOC message_2
     does not result in using Block-wise.

     If _both_ the conditions COND5 and COND6 hold, the use of Block-wise
     results in the following number of round trips experienced by the
     CoAP client.

     *  If the original EDHOC execution workflow is used (see
        Appendix A.2.1 of [RFC9528]), the number of round trips RT_ORIG is
        equal to 1 + ceil(SIZE_EDHOC_M3 / SIZE_BLOCK) + ceil(SIZE_BODY /
        SIZE_BLOCK).

     *  If the optimized EDHOC execution workflow is used (see Section 3
        of [RFC9668]), the number of round trips RT_COMB is equal to 1 +
        ceil(SIZE_BODY / SIZE_BLOCK).

     It follows that RT_COMB < RT_ORIG, i.e., the optimized EDHOC
     execution workflow always yields a lower number of round trips.

     Instead, the convenience of using the optimized EDHOC execution
     workflow becomes questionable if _both_ the following conditions
     hold:

     *  COND8: SIZE_BODY <= LIMIT

     *  COND9: (SIZE_BODY + SIZE_EDHOC_M3) > LIMIT

     That is, since SIZE_BODY <= LIMIT, using Block-wise would not be
     required when using the original EDHOC execution workflow, provided
     that SIZE_EDHOC_M3 <= LIMIT still holds.

     At the same time, using the combined workflow is in itself what
     actually triggers the use of Block-wise, since (SIZE_BODY +
     SIZE_EDHOC_M3) > LIMIT.

     Therefore, the following round trips are experienced by the CoAP
     client.

     *  The original EDHOC execution workflow run without using Block-wise
        results in a number of round trips RT_ORIG equal to 3.

     *  The optimized EDHOC execution workflow run using Block-wise
        results in a number of round trips RT_COMB equal to 1 +
        ceil(SIZE_BODY / SIZE_BLOCK).





  Tiloca                    Expires 11 July 2026                 [Page 32]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     It follows that RT_COMB >= RT_ORIG, i.e., the optimized EDHOC
     execution workflow might still be not worse than the original EDHOC
     execution workflow in terms of round trips.  This is the case only if
     the SIZE_BLOCK used is such that ceil(SIZE_BODY / SIZE_BLOCK) is
     equal to 2, i.e., the plain application data is fragmented into only
     2 inner blocks, and thus the EDHOC + OSCORE request is followed by
     only one more request message transporting the last block of the
     body.

     However, even in such a case, there would be no advantage in terms or
     round trips compared to the original workflow, while still requiring
     the CoAP client and the CoAP server to perform the processing due to
     using the EDHOC + OSCORE request and Block-wise transferring.

     Therefore, if both the conditions COND8 and COND9 hold, the CoAP
     client should not send the EDHOC + OSCORE request.  Instead, the CoAP
     client should continue by switching to the original EDHOC execution
     workflow.  That is, the CoAP client first sends EDHOC message_3
     prepended by the EDHOC Connection Identifier C_R encoded as per
     Section 3.3 of [RFC9528] and then sends the OSCORE-protected CoAP
     request once the EDHOC execution is completed.

  6.  Security Considerations

     This document provides considerations for implementations of the
     EDHOC protocol.  The security considerations compiled in Section 9 of
     [RFC9528] and in Section 7 of [RFC9668] apply.  The compliance
     requirements for implementations that are listed in Section 8 of
     [RFC9528] also apply.

     It is foreseeable that the EDHOC protocol will be extended (e.g., as
     to new cipher suites, new methods, and new types of authentication
     credentials) and that external security applications will be
     integrated into EDHOC by embedding the transport of their data in
     EDHOC EAD items.  For implementations that support such extensions
     and external applications, the related security considerations and
     compliance requirements also apply.

  6.1.  Assessing the Correctness of Implementations

     Tools relying on fuzz testing such as EDHOC-Fuzzer [EDHOC-Fuzzer] can
     help assess the correctness of implementations of the EDHOC protocol
     and of external security applications integrated into EDHOC.

     Such tools help finding and amending implementation errors especially
     related to the following points:





  Tiloca                    Expires 11 July 2026                 [Page 33]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     *  Non-conformance with the protocol specification (e.g., unintended
        deviations in performing the protocol steps), which can be a
        potential source of security vulnerabilities in addition to
        performance deficiencies.

     *  Presence of inappropriate states and state transitions in the
        modeling of the EDHOC execution, e.g., states that are impossible
        to reach and traverse or that are not part of the protocol
        specification (which is a particular case of non-conformance).

        These states and transitions should be amended or removed, in
        order to reduce the memory footprint and code complexity and to
        simplify the implementation, thus reducing the risks of bugs and
        related security vulnerabilities.

  7.  IANA Considerations

     This document has no actions for IANA.

  8.  References

  8.1.  Normative References

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

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

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

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









  Tiloca                    Expires 11 July 2026                 [Page 34]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

  8.2.  Informative References

     [EDHOC-Fuzzer]
                Sagonas, K. and T. Typaldos, "EDHOC-Fuzzer: An EDHOC
                Protocol State Fuzzer", ISSTA 2023: Proceedings of the
                32nd ACM SIGSOFT International Symposium on Software
                Testing and Analysis , 13 July 2023,
                <https://dl.acm.org/doi/10.1145/3597926.3604922>.

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

     [I-D.ietf-ace-workflow-and-params]
                Tiloca, M. and G. Selander, "Short Distribution Chain
                (SDC) Workflow and New OAuth Parameters for the
                Authentication and Authorization for Constrained
                Environments (ACE) Framework", Work in Progress, Internet-
                Draft, draft-ietf-ace-workflow-and-params-06, 20 October
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                ace-workflow-and-params-06>.

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

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



  Tiloca                    Expires 11 July 2026                 [Page 35]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

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

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

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

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

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

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









  Tiloca                    Expires 11 July 2026                 [Page 36]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


  Appendix A.  Foreseen Advanced Processing of Incoming EDHOC message_1

     As mentioned in Section 4.1, future developments in EDHOC and in
     related external security applications might rely on an EAD item in
     EDHOC message_1 that specifies the authentication credential CRED
     associated with the Initiator (by value or by reference), as wrapped
     in a cryptographically protected "envelope".

     In order to handle such a case, the processing of an incoming EDHOC
     message_1 as described in Section 4.1 is extended with additional
     steps performed by the SPO.

     Such an extended side processing shares similarities with that of an
     incoming EDHOC message_2 or message_3 (see Section 4.3).  In
     particular, similarly to what is compiled in Section 4.3.1.1 and
     Section 4.3.1.2, it consists of the following steps.

     *  (0) The SPO checks the presence of an EAD item that specifies the
        authentication credential CRED associated with the Initiator (by
        value or by reference).

        If no such EAD item is found, the SPO moves to Step 12.
        Otherwise, the SPO moves to Step 1.

     *  (1) The SPO determines CRED based on an EAD item retrieved at Step
        0.

        The EAD item can specify CRED by value or by reference, including
        a URI or other external reference where CRED can be retrieved
        from.

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

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

        Performing such a validation might require the SPO to first
        process an EAD item included in message_1.

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

     *  (3) The SPO attempts to retrieve CRED via an EAD item considered
        at Step 1.  Then, the SPO moves to Step 4.





  Tiloca                    Expires 11 July 2026                 [Page 37]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     *  (4) If the retrieval of CRED has succeeded, the SPO moves to Step
        5.  Otherwise, the SPO moves to Step 11.

     *  (5) If the enforced trust policy for new authentication
        credentials is "NO-LEARNING" and P does not admit any exceptions
        that are acceptable to enforce for message_1 (see Section 3.2),
        the SPO moves to Step 11.  Otherwise, the SPO moves to Step 6.

     *  (6) If this step has been reached, the peer P is not already
        storing the retrieved CRED and, at the same time, it enforces
        either the trust policy "LEARNING" or the trust policy "NO-
        LEARNING" while also enforcing an exception acceptable for
        message_1 (see Section 3.2).

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

        Validating CRED might require the SPO to first process an EAD item
        included in message_1.

     *  (7) If CRED has been determined valid, the SPO moves to Step 8.
        Otherwise, the SPO moves to Step 11.

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

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

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

     *  (10) P uses CRED as authentication credential associated with the
        other peer in the ongoing EDHOC session.  Then, the SPO moves to
        Step 12.

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

     *  (12) The SPO processes any EAD item included in message_1 that has
        not already been processed.




  Tiloca                    Expires 11 July 2026                 [Page 38]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


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

     The flowchart in Figure 6 shows the different steps taken for the
     advanced processing of an incoming EDHOC message_1 defined above.

      Incoming
      EDHOC message_1

               |
               |
               v
     +-------------------+  ---+
     | Decode message_1  |     |
     +-------------------+     |
               |               |
               |               +--- (Core EDHOC Processing)
               v               |
     +-------------------+     |
     | Accepted selected |     |
     | cipher suite      |     |
     +-------------------+  ---+
               |
               |

     Control transferred to
     the side-processor object

               |
    +----------|---------------------------------------------------------+
    |          |                                     Side processing     |
    |          v                                                         |
    | +--------------------+                                             |
    | | 0. Does an EAD     |                                             |
    | | item specify CRED? |                                             |
    | +--------------------+                                             |
    |  |       |                                                         |
    |  | NO    | YES                                                     |
    |  |       v                                                         |
    |  |   +----------------+     +-------------+     +-------------+    |
    |  |   | 1. Does an EAD | NO  | 3. Retrieve |     | 4. Is the   |    |
    |  |   | item point to  |---->| CRED via    |---->| retrieval   |    |
    |  |   | an already     |     | an EAD item |     | of CRED     |    |
    |  |   | stored CRED?   |     +-------------+     | successful? |    |
    |  |   +----------------+                         +-------------+    |
    |  |       |                                         |         |     |



  Tiloca                    Expires 11 July 2026                 [Page 39]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


    |  |       |                                         | NO      | YES |
    |  |       |                        +----------------+         |     |
    |  |       |                        |                          |     |
    |  |       | YES                    |                          |     |
    |  |       v                        v                          v     |
    |  |  +-----------------+ NO  +-----------+   YES +----------------+ |
    |  |  | 2. Is this CRED |---->| 11. Abort |<------| 5. Is the used | |
    |  |  | still valid?    |     | the EDHOC |       | trust policy   | |
    |  |  +-----------------+     | session   |       | "NO-LEARNING", | |
    |  |       |                  |           |       | without any    | |
    |  |       |                  |           |       | acceptable     | |
    |  |       |                  |           |       | exceptions?    | |
    |  |       |                  |           |       +----------------+ |
    |  |       | YES              |           |                    |     |
    |  |       v                  |           |    Here the used   | NO  |
    |  |  +-----------------+ NO  |           |    trust policy is |     |
    |  |  | 9. Is this CRED |---->|           |    "LEARNING", or  |     |
    |  |  | good to use in  |     +-----------+    "NO-LEARNING"   |     |
    |  |  | the context of  |              ^       together with   |     |
    |  |  | this EDHOC      |<----+        |       an overriding   |     |
    |  |  | session?        |     |        |       exception       |     |
    |  |  +-----------------+     |        |                       |     |
    |  |      |                   |        |                       v     |
    |  |      |                   |        |             +-------------+ |
    |  |      |                   |        |             | 6. Validate | |
    |  |      |                   |        |             | CRED        | |
    |  |      |                   |        |             +-------------+ |
    |  |      |                   |        |                       |     |
    |  |      | YES               |        | NO                    |     |
    |  |      |                   |        |                       v     |
    |  |      |                   |     +------------------------------+ |
    |  |      |                   |     | 7. Is CRED valid?            | |
    |  |      |                   |     +------------------------------+ |
    |  |      |                   |        |                             |
    |  |      |                   |        | YES                         |
    |  |      v                   |        v                             |
    |  |  +------------------+    |     +------------------------------+ |
    |  |  | 10. Continue by  |    |     | 8. Store CRED as valid and   | |
    |  |  | considering this |    +-----| trusted.                     | |
    |  |  | CRED as the      |          |                              | |
    |  |  | authentication   |          | Pair CRED with consistent    | |
    |  |  | credential       |          | credential identifiers, for  | |
    |  |  | associated with  |          | each supported type of       | |
    |  |  | the other peer   |          | credential identifier.       | |
    |  |  +------------------+          +------------------------------+ |
    |  |      |                                                          |
    |  |      |                                                          |
    |  v      v                                                          |



  Tiloca                    Expires 11 July 2026                 [Page 40]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


    | +------------------------------------------------------------+     |
    | | 12. Process the EAD items that have not been processed yet |     |
    | +------------------------------------------------------------+     |
    |         |                                                          |
    +---------|----------------------------------------------------------+
              |
              |
              v

     Control transferred back
     to the core EDHOC processing

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

               Figure 6: Processing Steps for EDHOC message_1.

  Appendix B.  Document Updates

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

  B.1.  Version -04 to -05

     *  Minor clarifications.

     *  Editorial fixes and improvements.

  B.2.  Version -03 to -04

     *  Clarified and re-positioned exceptions to NO-LEARNING policy.

     *  Added security considerations.

     *  Appendix on foreseen advanced processing of incoming EDHOC
        message_1.

     *  Clarifications and editorial improvements.

  B.3.  Version -02 to -03

     *  Consistent use of "trust policy" instead of "trust model".

     *  More modular presentation of trust policies and their enforcement.



  Tiloca                    Expires 11 July 2026                 [Page 41]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     *  Alignment with use of EDHOC in the EDHOC and OSCORE profile of
        ACE.

     *  Note on follow-up actions for the application after EDHOC
        completion.

     *  Removed moot section on special handling when using the EDHOC and
        OSCORE profile of ACE.

     *  Consistency checks of authentication credentials from ID_CRED and
        EAD items.

     *  Updated reference.

     *  Clarifications and editorial improvements.

  B.4.  Version -01 to -02

     *  Improved content on the EDHOC and OSCORE profile of ACE.

     *  Admit situation-specific exceptions to the "NO-LEARNING" policy.

     *  Using the EDHOC and OSCORE profile of ACE with the "NO-LEARNING"
        policy.

     *  Revised guidelines on using EDHOC with CoAP and Block-wise.

     *  Editorial improvements.

  B.5.  Version -00 to -01

     *  Added considerations on trust policies when using the EDHOC and
        OSCORE profile of the ACE framework.

     *  Placeholder section on special processing when using the EDHOC and
        OSCORE profile of the ACE framework.

     *  Added considerations on using EDHOC with CoAP and Block-wise.

     *  Editorial improvements.

  Acknowledgments

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





  Tiloca                    Expires 11 July 2026                 [Page 42]


  Internet-Draft   Implementation Considerations for EDHOC    January 2026


     The work on this document has been partly supported by the Sweden's
     Innovation Agency VINNOVA and the Celtic-Next project CYPRESS.

  Author's Address

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








































  Tiloca                    Expires 11 July 2026                 [Page 43]


name: draft-ietf-lake-authz
rev: 07
title: Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA)
time: 2026-03-02T16:44:44Z
group_uri: /api/v1/group/group/2249/
expires: 2026-09-03T16:44:44Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081870+00:00
source: ietf
abstract:
  Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight
     authenticated key exchange protocol intended for use in constrained
     scenarios.  This document specifies Lightweight Authorization using
     EDHOC (ELA).  The procedure allows authorizing enrollment of new
     devices using the extension point defined in EDHOC.  ELA is
     applicable to zero-touch onboarding of new devices to a constrained
     network leveraging trust anchors installed at manufacture time.

full_text:
  LAKE Working Group                                           G. Selander
  Internet-Draft                                         J. Preuß Mattsson
  Intended status: Standards Track                             Ericsson AB
  Expires: 23 April 2026                                        M. Vučinić
                                                            G. Fedrecheski
                                                                     INRIA
                                                             M. Richardson
                                                  Sandelman Software Works
                                                           20 October 2025


  Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA)
                          draft-ietf-lake-authz-06

  Abstract

     Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight
     authenticated key exchange protocol intended for use in constrained
     scenarios.  This document specifies Lightweight Authorization using
     EDHOC (ELA).  The procedure allows authorizing enrollment of new
     devices using the extension point defined in EDHOC.  ELA is
     applicable to zero-touch onboarding of new devices to a constrained
     network leveraging trust anchors installed at manufacture time.

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

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

     Source for this draft and an issue tracker can be found at
     https://github.com/lake-wg/authz.

  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                     ELA                      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
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Protocol Outline  . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Device (U)  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Domain Authenticator (V)  . . . . . . . . . . . . . . . .   7
       3.3.  Enrollment Server (W) . . . . . . . . . . . . . . . . . .   8
     4.  The Protocol  . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Reuse of EDHOC  . . . . . . . . . . . . . . . . . . . . .  10
       4.3.  Stateless Operation of V  . . . . . . . . . . . . . . . .  12
       4.4.  Device <-> Enrollment Server (U <-> W)  . . . . . . . . .  13
       4.5.  Device <-> Authenticator (U <-> V)  . . . . . . . . . . .  16
       4.6.  Authenticator <-> Enrollment Server (V <-> W) . . . . . .  18
       4.7.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  21
       4.8.  Reverse flow with U as Responder  . . . . . . . . . . . .  22
     5.  REST Interface at W . . . . . . . . . . . . . . . . . . . . .  26
       5.1.  Scheme "https"  . . . . . . . . . . . . . . . . . . . . .  27
       5.2.  Scheme "coaps"  . . . . . . . . . . . . . . . . . . . . .  27
       5.3.  Scheme "coap" . . . . . . . . . . . . . . . . . . . . . .  27



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


  Internet-Draft                     ELA                      October 2025


       5.4.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  27
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
       7.1.  EDHOC External Authorization Data Registry  . . . . . . .  30
       7.2.  The Well-Known URI Registry . . . . . . . . . . . . . . .  31
       7.3.  Well-Known Name Under ".arpa" Name Space  . . . . . . . .  31
       7.4.  Media Types Registry  . . . . . . . . . . . . . . . . . .  33
       7.5.  CoAP Content-Formats Registry . . . . . . . . . . . . . .  34
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  34
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  34
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  35
     Appendix A.  Optimization Strategies  . . . . . . . . . . . . . .  37
       A.1.  U broadcasts message_1  . . . . . . . . . . . . . . . . .  37
       A.2.  V advertises support for ELA  . . . . . . . . . . . . . .  38
     Appendix B.  Use with Constrained Join Protocol (CoJP)  . . . . .  41
       B.1.  Network Discovery . . . . . . . . . . . . . . . . . . . .  42
       B.2.  The Enrollment Protocol with Parameter Provisioning . . .  43
     Appendix C.  Example of opaque_state  . . . . . . . . . . . . . .  45
     Appendix D.  Examples of protocol execution . . . . . . . . . . .  45
       D.1.  Minimal . . . . . . . . . . . . . . . . . . . . . . . . .  45
       D.2.  Wrong gateway . . . . . . . . . . . . . . . . . . . . . .  46
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  47
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  47

  1.  Introduction

     For constrained IoT deployments [RFC7228] the overhead and processing
     contributed by security protocols may be significant, which motivates
     the specification of lightweight protocols that are optimizing, in
     particular, message overhead (see [I-D.ietf-lake-reqs]).  This
     document describes Lightweight Authorization using EDHOC (ELA), a
     procedure for augmenting the lightweight authenticated Diffie-Hellman
     key exchange EDHOC [RFC9528] with third party-assisted authorization.

     ELA involves a device, a domain authenticator, and an enrollment
     server.  The device and domain authenticator perform mutual
     authentication and authorization, assisted by the enrollment server
     that provides relevant authorization information to the device (a
     "voucher") and to the authenticator.  The high-level model is similar
     to BRSKI [RFC8995].

     In this document, we consider the target interaction for which
     authorization is needed to be "enrollment", for example joining a
     network for the first time (e.g., [RFC9031]), but it can be applied
     to authorize other target interactions.






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


  Internet-Draft                     ELA                      October 2025


     The enrollment server may represent the manufacturer of the device,
     or some other party with information about the device from which a
     trust anchor has been pre-provisioned into the device.  The (domain)
     authenticator may represent the service provider or some other party
     controlling access to the network in which the device is enrolling.

     ELA assumes that authentication between device and authenticator is
     performed with EDHOC [RFC9528], and defines the integration of a
     lightweight authorization procedure using the External Authorization
     Data (EAD) fields defined in EDHOC.

     ELA enables a low message count by performing authorization and
     enrollment in parallel with authentication, instead of in sequence,
     which is common for network access.  It further reuses protocol
     elements from EDHOC, leading to reduced message sizes on constrained
     links.

     This protocol is applicable to a wide variety of settings, and can be
     mapped to different authorization architectures.

  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 have an understanding of CBOR [RFC8949], CDDL
     [RFC8610], and EDHOC [RFC9528].  Appendix C.1 of [RFC9528] contains
     some basic info about CBOR.

  2.  Protocol Outline

     The goal of ELA is to enable a (potentially constrained) device (U)
     to enroll into a domain over a constrained link.  The device
     authenticates and enforces authorization of the (non-constrained)
     domain authenticator (V) with the help of a voucher conveying
     authorization information.  The voucher has a similar role as in
     [RFC8366] but should be considerably more compact.  The domain
     authenticator, in turn, authenticates the device and authorizes its
     enrollment into the domain.  ELA also enables scenarios where only V
     needs to authorize U, by allowing the voucher to be optional.








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


  Internet-Draft                     ELA                      October 2025


     The procedure is assisted by a (non-constrained) enrollment server
     (W) located in a non-constrained network behind the domain
     authenticator, e.g., on the Internet, providing information to the
     device (conveyed in the voucher) and to the domain authenticator as
     part of the protocol.

     The objective of this document is to specify such a protocol that is
     lightweight over the constrained link, by reusing elements of EDHOC
     [RFC9528] and by shifting message overhead to the non-constrained
     side of the network.  See illustration in Figure 1.

     Note the cardinality of the involved parties.  It is expected that
     the domain authenticator needs to handle a large unspecified number
     of devices, but for a given device type or manufacturer it is
     expected that one or a few nodes host enrollment servers.

                     Voucher
                     Info
     +----------+      |     +---------------+  Voucher  +---------------+
     |          |      |     |               |  Request  |               |
     |  Device  +------o---->|    Domain     +---------->|   Enrollment  |
     |          |<---o-------+ Authenticator |<----------+     Server    |
     |   (U)    +----+------>|      (V)      |  Voucher  |      (W)      |
     |          |    |       |               |  Response |               |
     +----------+    |       +---------------+           +---------------+
                   Voucher

         Figure 1: Overview of the message flow.  EDHOC is used on the
        constrained link between U and V.  Voucher Info and Voucher are
           sent in EDHOC External Authorization Data (EAD).  The link
                      between V and W is not constrained.

  3.  Assumptions

     The protocol is based on the following pre-existing relations between
     the device (U), the domain authenticator (V) and the enrollment
     server (W), see Figure 2.

     *  U and W have an explicit relation: U is configured with a public
        key of W, see Section 3.1.

     *  V and W have an implicit relation, e.g., based on web PKI with
        trusted CA certificates, see Section 3.2.

     *  U and V need not have any previous relation.  This protocol
        establishes a relation between U and V.





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


  Internet-Draft                     ELA                      October 2025


     Each of the three parties can gain protected communication with the
     other two during the protocol.

     V may be able to access credentials over non-constrained networks,
     but U may be limited to constrained networks.  Implementations
     wishing to leverage the zero-touch capabilities of this protocol are
     expected to support transmission of credentials from V to U by value
     during the EDHOC exchange, which will impact the message size
     depending on the type of credential used.

             Explicit relation (e.g., from device manufacture)
         | <---------------------------------------------------> |
         |                                                       |
    +----+-----+            +---------------+            +-------+-------+
    |          |            |               |            |               |
    |  Device  |    con-    |    Domain     |  not con-  |   Enrollment  |
    |          |  strained  | Authenticator |  strained  |     Server    |
    |   (U)    |  network   |      (V)      |  network   |      (W)      |
    |          |            |               |            |               |
    +----+-----+            +-------+-------+            +-------+-------+
         |                          |                            |
         | <----------------------> | <------------------------> |
              No previous relation        Implicit relation
                                        (e.g., web PKI based)

                Figure 2: Overview of pre-existing relations.

  3.1.  Device (U)

     To authenticate to V, the device (U) runs EDHOC in the role of
     Initiator with authentication credential CRED_U, for example, an
     X.509 certificate [RFC5280] or a CBOR Web Token (CWT, [RFC8392]).
     CRED_U may, for example, be carried by value in ID_CRED_I of EDHOC
     message_3 or be provisioned to V over a non-constrained network,
     leveraging a credential identifier in ID_CRED_I (see bottom of
     Figure 3).

     U also needs to identify itself to W.  The device identifier used for
     this is ID_U.  The purpose of ID_U is for W to be able to determine
     if the device with this identifier is authorized to enroll with V.
     ID_U may be a reference to CRED_U, like ID_CRED_I in EDHOC (see
     Section 3.5.2 of [RFC9528]), or a device identifier from a different
     name space, such as EUI-64 identifiers.

     U is also provisioned with information about W:

     *  A static public DH key of W (G_W) used to establish secure
        communication with the enrollment server (see Section 4.4).



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


  Internet-Draft                     ELA                      October 2025


     *  Location information about the enrollment server (LOC_W) that can
        be used by V to reach W.  This is typically a URI but may
        alternatively be only the domain name.

  3.2.  Domain Authenticator (V)

     To authenticate to U, the domain authenticator (V) runs EDHOC in the
     role of Responder with an authentication credential CRED_V containing
     a public key of V, see Section 4.5.2.1.  This proves to U the
     possession of the private key corresponding to the public key of
     CRED_V.  CRED_V typically needs to be transported to U in EDHOC
     (using ID_CRED_R = CRED_V, see Section 3.5.2 of [RFC9528]) since
     there is no previous relation between U and V.

     V and W need to establish a secure (confidentiality and integrity
     protected) connection for the Voucher Request/Response protocol.
     Furthermore, W needs to access the same credential CRED_V that V uses
     with U (to compute the Voucher), and V needs to prove to W the
     possession of the private key corresponding to the public key of
     CRED_V.  It is RECOMMENDED that V authenticates to W using the same
     credential CRED_V as with U.

     Note that the choice of protocols may affect which type of credential
     and methods should be used by V.  For example, in case V and W select
     TLS for the secure channel and PoP, then CRED_V is a X.509
     certificate, and the EDHOC method used by V is signature-based.  Some
     of the possible combinations of protocols to secure the connection
     between V and W are listed in Table 1 below.























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


  Internet-Draft                     ELA                      October 2025


     +=================+=====================+==============+============+
     | Secure channel  | Proof-of-Possession |Type of       |EDHOC method|
     | between V and W | from V to W         |CRED_V        |used by V   |
     +=================+=====================+==============+============+
     | [D]TLS 1.3 with | Provided by [D]TLS. |Restricted to |V MUST      |
     | mutual          |                     |types that    |authenticate|
     | authentication, |                     |are supported |using a     |
     | where V is the  |                     |by both       |signature.  |
     | client and W is |                     |[D]TLS and    |            |
     | the server.     |                     |EDHOC, e.g.,  |            |
     |                 |                     |X.509         |            |
     |                 |                     |certificates. |            |
     +-----------------+---------------------+--------------+------------+
     | [D]TLS 1.3,     | Run an EDHOC        |Any type      |Any method  |
     | where V is the  | session on top of   |supported by  |may be used.|
     | client and W is | the TLS-protected   |EDHOC, e.g.,  |            |
     | the server.     | channel.            |X.509, C509,  |            |
     |                 |                     |CWT, or CCS.  |            |
     +-----------------+---------------------+--------------+------------+
     | EDHOC and       | Already provided by |Any type      |Any method  |
     | OSCORE, where V | EDHOC during the    |supported by  |may be used.|
     | is the          | setup of the secure |EDHOC.        |            |
     | initiator and W | channel.            |              |            |
     | is the          |                     |              |            |
     | responder.      |                     |              |            |
     +-----------------+---------------------+--------------+------------+

       Table 1: Examples of how to secure the connection between V and W.

     Note also that the secure connection between V and W may be long-
     lived and reused for multiple voucher requests/responses.

     Other details of proof-of-possession related to CRED_V and transport
     of CRED_V are out of scope of this document.

  3.3.  Enrollment Server (W)

     The enrollment server (W) is assumed to have the private DH key
     corresponding to G_W, which is used to establish secure communication
     with the device (see Section 4.4).  W provides to U the authorization
     decision for enrollment with V in the form of a voucher (see
     Section 4.4.2).  Authorization policies are out of scope for this
     document.

     Authentication credentials and communication security with V is
     described in Section 3.2.  To calculate the voucher, W needs access
     to message_1 and CRED_V as used in the EDHOC session between U and V,
     see Section 4.4.2.



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


  Internet-Draft                     ELA                      October 2025


     *  W MUST verify that CRED_V is bound to the secure connection
        between W and V

     *  W MUST verify that V is in possession of the private key
        corresponding to the public key of CRED_V

     W needs to be available during the execution of the protocol between
     U and V.

  4.  The Protocol

  4.1.  Overview

     The ELA protocol consist of three security sessions going on in
     parallel:

     1.  The EDHOC session between device (U) and (domain) authenticator
         (V)

     2.  Voucher Request/Response between authenticator (V) and enrollment
         server (W)

     3.  An exchange of voucher-related information, including the voucher
         itself, between device (U) and enrollment server (W), mediated by
         the authenticator (V).

     Figure 3 provides an overview of the message flow detailed in this
     section.  An outline of EDHOC is given in Section 2 of [RFC9528].

  U                              V                                       W
  |                              |                                       |
  |                              |                                       |
  |                              |        Establish secure channel       |
  |                              +<---  ---  ---  ---  ---  ---  ---  -->|
  |                              |      (e.g., TLS with server cert.)    |
  |                              |                                       |
  |                              |   Proof-of-possession w.r.t. CRED_V   |
  |                              +<---  ---  ---  ---  ---  ---  ---  -->|
  |                              |            (e.g., EDHOC)              |
  |                              |                                       |
  |                              |                                       |
  |                              |                                       |

  ------------------------------------------------------------------------
                            CORE PROTOCOL

  |                              |                                       |
  |         EDHOC message_1      |                                       |



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


  Internet-Draft                     ELA                      October 2025


  +----------------------------->|                                       |
  |  (EAD_1 = LOC_W, ENC_U_INFO) |                                       |
  |                              |                                       |
  |                              |        Voucher Request (VREQ)         |
  |                              +-------------------------------------->|
  |                              |       (message_1, ?opaque_state)      |
  |                              |                                       |
  |                              |        Voucher Response (VRES)        |
  |                              |<--------------------------------------+
  |                              | (message_1, ?Voucher, ?opaque_state)  |
  |                              |                                       |
  |         EDHOC message_2      |                                       |
  |<-----------------------------+                                       |
  |        (EAD_2 = Voucher)     |                                       |
  |                              |                                       |
  |                              |                                       |
  |         EDHOC message_3      |                                       |
  +----------------------------->|                                       |
  |                              |                                       |

  ------------------------------------------------------------------------

  |                              |
  |                              |                              Credential
  |                              |                                Database
  |                              |                                       |
  |                              |       ID_CRED_I from message_3        |
  |                              +---  ---  ---  ---   ---  ---  ---  -->|
  |                              |                                       |
  |                              |                 CRED_U                |
  |                              |<--  ---  ---  ---  ---   ---  ---  ---+
  |                              |                                       |
  |                              |                                       |

    Figure 3: Overview of ELA: W-assisted authorization of U and V to
     each other: EDHOC between U and V, and Voucher Request/Response
      between V and W.  Before the protocol, V and W are assumed to
        have established a secure channel and performed proof-of-
      possession of relevant keys.  Credential lookup of CRED_U may
                 involve W or other credential database.

  4.2.  Reuse of EDHOC

     The ELA protocol illustrated in Figure 3 reuses several components of
     EDHOC:






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


  Internet-Draft                     ELA                      October 2025


     *  G_X, the ephemeral public Diffie-Hellman key of U, is also used in
        the protocol between U and W.  In case U acts as Responder (see
        Section 4.8), G_Y is used instead.

     *  SUITES_I includes the cipher suite for EDHOC selected by U, and
        also defines the algorithms used between U and W (see Section 3.6
        of [RFC9528]):

        -  EDHOC AEAD algorithm: used to encrypt ID_U and to generate
           voucher

        -  EDHOC hash algorithm: used for key derivation

        -  EDHOC key exchange algorithm: used to calculate the shared
           secret between U and W

     *  EAD_1, EAD_2 are the External Authorization Data message fields of
        message_1 and message_2, respectively, see Section 3.8 of
        [RFC9528].  In case U acts as Responder (see Section 4.8), EAD_2
        and EAD_3 are used in message_2 and message_3, respectively.  This
        document specifies two new EAD items, with ead_label = TBD1 and
        TBD2, see Section 7.1.

     *  ID_CRED_I and ID_CRED_R are used to identify the authentication
        credentials CRED_U and CRED_V, respectively.  As shown at the
        bottom of Figure 3, V may use W to obtain CRED_U.  By default,
        CRED_V is transported in ID_CRED_R in message_2, see
        Section 4.5.2.1.  In case U is Responder, CRED_V is transported in
        ID_CRED_I in message_3.

     The protocol also reuses the EDHOC_Extract and EDHOC_Expand key
     derivation from EDHOC (see Section 4 of [RFC9528]).

     *  The intermediate pseudo-random key PRK is derived using
        EDHOC_Extract():

        -  PRK = EDHOC_Extract(salt, IKM)

           o  where salt = 0x (the zero-length byte string)

           o  IKM is computed as an ECDH cofactor Diffie-Hellman shared
              secret from the public key of W, G_W, and the private key
              corresponding to G_X (or v.v.), see Section 5.7.1.2 of
              [NIST-800-56A].

     The output keying material OKM is derived from PRK using
     EDHOC_Expand(), which is defined in terms of the EDHOC hash algorithm
     of the selected cipher suite SS, see Section 4.1.2 of [RFC9528]:



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


  Internet-Draft                     ELA                      October 2025


     *  OKM = EDHOC_Expand(PRK, info, length)

        where

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

  4.3.  Stateless Operation of V

     V may act statelessly with respect to U: the state of the EDHOC
     session started by U may be dropped at V until authorization from W
     is received.  Once V has received EDHOC message_1 from U and
     extracted LOC_W from EAD_1, message_1 is forwarded unmodified to W in
     the form of a Voucher Request (see Section 4.6.1).  V encapsulates
     the internal state that it needs to later respond to U, and sends
     that to W together with EDHOC message_1.  This state typically
     contains addressing information of U (e.g., U's IP address and port
     number), together with any other implementation-specific parameter
     needed by V to respond to U.  At this point, V can drop the EDHOC
     session that was initiated by U.

     The encapsulated state MUST be protected using a uniformly-
     distributed (pseudo-)random key, known only to itself and specific
     for the current EDHOC session to prevent replay attacks of old
     encapsulated state.

     How V serializes and encrypts its internal state is out of scope in
     this specification.  For example, V may use CBOR and COSE.

     W sends to V the voucher together with the echoed message_1, as
     received from U, and V's internal state, see Section 4.6.2.  This
     allows V to act as a simple message relay until it has obtained the
     authorization from W to enroll U.  The reception of a successful
     Voucher Response at V from W implies the authorization for V to
     enroll U.  At this point, V can initialize a new EDHOC session with
     U, based on the message and the state retrieved from the Voucher
     Response from W.

     Noet that while stateless operation is supported in the default flow,
     it is not supported in the reverse flow (see Section 4.8).








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


  Internet-Draft                     ELA                      October 2025


  4.4.  Device <-> Enrollment Server (U <-> W)

     The protocol between U and W is carried between U and V in message_1
     and message_2 (Section 4.5), and between V and W in the Voucher
     Request/Response (Section 4.6).  The data is protected between the
     endpoints using secret keys derived from a Diffie-Hellman shared
     secret (see Section 4.2) as further detailed in this section.

  4.4.1.  Voucher Info

     The external authorization data EAD_1 contains a critical EAD item
     with ead_label = -TBD1 and ead_value = Voucher_Info, which is a CBOR
     byte string:

     Voucher_Info = bstr .cborseq Voucher_Info_Seq

     Voucher_Info_Seq = [ ; used as a CBOR sequence, not array
         LOC_W:      tstr,
         ENC_U_INFO:     bstr
     ]

     where

     *  LOC_W is a text string used by V to locate W, e.g., a URI or a
        domain name.

     *  ENC_U_INFO is a byte string containing an encrypted identifier of
        U and, optionally, opaque application data prepared by U.  It is
        calculated as follows:

     ENC_U_INFO is encrypted using the EDHOC AEAD algorithm of the
     selected cipher suite SS specified in SUITE_I of EDHOC message_1.  It
     consists of 'ciphertext' of COSE_Encrypt0 (Section 5.2 of [RFC9052])
     computed from the following:

     *  The encryption key K_1 and nonce IV_1 are derived as specified
        below.

     *  'protected' is a byte string of size 0

     *  'plaintext' and 'external_aad' as below:

     plaintext = (
         ID_U:            bstr,
     )






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


  Internet-Draft                     ELA                      October 2025


     external_aad = [ ; used as a CBOR sequence, not array
         "ELA-voucher-info": tstr, ; fixed label
         METHOD:             int,
         SS:                 int,
         C_I:                bstr
     ]

     where

     *  "ELA-voucher-info" is a string literal for the Voucher_Info
        struct.

     *  ID_U is an identifier of the device, see Section 3.1.

     *  METHOD is the authentication method of EDHOC message_1.

     *  SS is the selected cipher suite in SUITES_I of EDHOC message_1,
        see Section 4.5.

     *  C_I is the connection identifier of EDHOC message_1.

     The external_aad is wrapped in an enc_structure as defined in
     Section 5.3 of [RFC9052].

     The derivation of K_1 = EDHOC_Expand(PRK, info, length) uses the
     following input to the info struct (see OKM in Section 4.2):

     *  info_label = 0

     *  context = h'' (the empty CBOR string)

     *  length is length of the key of the EDHOC AEAD algorithm in bytes
        (which is the length of K_1)

     The derivation of IV_1 = EDHOC_Expand(PRK, info, length) uses the
     following input to the info struct (see OKM in Section 4.2):

     *  info_label = 1

     *  context = h'' (the empty CBOR string)

     *  length is length of the nonce of the EDHOC AEAD algorithm in bytes
        (which is the length of IV_1)








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


  Internet-Draft                     ELA                      October 2025


  4.4.2.  Voucher

     The external authorization data EAD_2 contains a critical EAD item
     with ead_label = -TBD2.  If W generates a Voucher, the EAD item also
     contains ead_value = Voucher, otherwise ead_value is absent.

     The voucher is an assertion to U that W has authorized V.  It is
     encrypted using the EDHOC AEAD algorithm of the selected cipher suite
     SS specified in SUITE_I of EDHOC message_1.  It consists of the
     'ciphertext' field of a COSE_Encrypt0 object, which is a byte string,
     as defined below.

     Voucher = bstr

     Its corresponding plaintext value consists of an opaque field that
     can be used by W to convey information to U, such as a voucher scope.
     The authentication tag present in the ciphertext is also bound to
     message_1 and the credential of V as described below.

     *  The encryption key K_2 and nonce IV_2 are derived as specified
        below.

     *  'protected' is a byte string of size 0

     *  'plaintext' and 'external_aad' as below:

     plaintext = (
         ?OPAQUE_INFO: bstr
     )

     external_aad = (
         H_handshake:  bstr,
         CRED_V:        bstr,
     )

     where

     *  OPAQUE_INFO is an opaque field provided by the application.  If
        present, it will contain application data that W may want to
        convey to U, e.g., a voucher scope.  Note that OPAQUE_INFO is
        opaque when viewed as an information element in EDHOC.  It is
        opaque to V, while the application in U and W can read its
        contents.

     *  H_handshake is the hash of EDHOC message_1, sent by V as part of
        the voucher request, see Section 4.6.1.





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


  Internet-Draft                     ELA                      October 2025


     *  CRED_V is the credential used by V to authenticate to U and W, see
        Section 4.5.2.1 and Table 1.

     The derivation of K_2 = EDHOC_Expand(PRK, info, length) uses the
     following input to the info struct (see Section 4.2):

     *  info_label = 2

     *  context = h'' (the empty CBOR string)

     *  length is length of the key of the EDHOC AEAD algorithm in bytes

     The derivation of IV_2 = EDHOC_Expand(PRK, info, length) uses the
     following input to the info struct (see Section 4.2):

     *  info_label = 3

     *  context = h'' (the empty CBOR string)

     *  length is length of the nonce of the EDHOC AEAD algorithm in bytes

  4.5.  Device <-> Authenticator (U <-> V)

     This section describes the processing in U and V, which includes the
     EDHOC protocol, see Figure 3.  Normal EDHOC processing is omitted
     here.

  4.5.1.  Message 1

  4.5.1.1.  Processing in U

     U composes EDHOC message_1 using authentication method, identifiers,
     etc. according to an agreed application profile, see Section 3.9 of
     [RFC9528].  The selected cipher suite, in this document denoted SS,
     applies also to the interaction with W as detailed in Section 4.2, in
     particular, with respect to the Diffie-Hellman key agreement
     algorithm used between U and W.  As part of the normal EDHOC
     processing, U generates the ephemeral public key G_X that is reused
     in the interaction with W, see Section 4.4.

     The device sends EDHOC message_1 with EAD item (-TBD1, Voucher_Info)
     included in EAD_1, where Voucher_Info is specified in Section 4.4.
     The negative sign indicates that the EAD item is critical, see
     Section 3.8 of [RFC9528].







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


  Internet-Draft                     ELA                      October 2025


  4.5.1.2.  Processing in V

     V receives EDHOC message_1 from U and processes it as specified in
     Section 5.2.3 of [RFC9528], with the additional step of processing
     the EAD item in EAD_1.  Since the EAD item is critical, if V does not
     recognize it or it contains information that V cannot process, then V
     MUST abort the EDHOC session, see Section 3.8 of [RFC9528].
     Otherwise, the ead_label = -TBD1 triggers the voucher request to W as
     described in Section 4.6.  The exchange between V and W needs to be
     completed successfully for the EDHOC session to be continued.

     Note that the selected cipher suite SS is used both in the U <-> W
     and U <-> V interactions, therefore V must be ready to use the cipher
     suite SS set by U in message_1.  That is, ELA restricts the cipher
     suite negotiation in order to provide a streamlined authorization
     flow from the perspective of U.  Since V has a pre-established
     trusted channel with W, it has the opportunity to learn which cipher
     suites should be supported before any authorization attempt begins to
     take place.

  4.5.2.  Message 2

  4.5.2.1.  Processing in V

     V receives the voucher response from W as described in Section 4.6.

     V sends EDHOC message_2 to U with the critical EAD item (-TBD2,
     ?Voucher) included in EAD_2, i.e., ead_label = -TBD2 and, if the
     Voucher is present, ead_value = Voucher, as specified in
     Section 4.4.2.

     The type of CRED_V may depend on the selected mechanism for the
     establishment of a secure channel between V and W, See Table 1.

     In case the network between U and V is constrained, it is recommended
     that CRED_V be a CWT Claims Set (CCS) [RFC8392].  The CCS contains
     the public authentication key of V encoded as a COSE_Key in the 'cnf'
     claim, see Section 3.5.2 of [RFC9528].  ID_CRED_R contains the CWT
     Claims Set with 'kccs' as COSE header_map, see Section 10.6 of
     [RFC9528].

  4.5.2.2.  Processing in U

     U receives EDHOC message_2 from V and processes it as specified in
     Section 5.3.3 of [RFC9528], with the additional step of processing
     the EAD item in EAD_2.





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


  Internet-Draft                     ELA                      October 2025


     U first verifies that the EAD item contains the expected ead_label,
     see Section 7.1.

     If U does not recognize the EAD item or the EAD item contains
     information that U cannot process, then U MUST abort the EDHOC
     session, see Section 3.8 of [RFC9528].

     When the Voucher is present, U MUST verify the Voucher using
     H_message_1, CRED_V, and the keys derived as in Section 4.4.2.  If
     the Voucher verification fails then U MUST abort the EDHOC session.

     If OPAQUE_INFO is present, it is made available to the application.

  4.5.3.  Message 3

  4.5.3.1.  Processing in U

     If all verifications are passed, then U sends EDHOC message_3.

     EDHOC message_3 may be combined with an OSCORE-protected application
     request, see [I-D.ietf-core-oscore-edhoc].

  4.5.3.2.  Processing in V

     V performs the normal EDHOC verifications of message_3.  V may
     retrieve CRED_U from a Credential Database, after having learned
     ID_CRED_I from U.

  4.6.  Authenticator <-> Enrollment Server (V <-> W)

     It is assumed that V and W have set up a secure connection, W has
     accessed the authentication credential CRED_V to be used in the EDHOC
     session between V and U, and that W has verified that V is in
     possession of the private key corresponding to CRED_V, see
     Section 3.2 and Section 3.3.  V and W run the Voucher Request/
     Response protocol over the secure connection.

  4.6.1.  Voucher Request

  4.6.1.1.  Processing in V

     V sends the voucher request to W.  The Voucher Request SHALL be a
     CBOR array as defined below:








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


  Internet-Draft                     ELA                      October 2025


     Voucher_Request = [
         SS:             int,
         G_U:            bstr,
         Voucher_Info:   bstr,
         H_handshake:    bstr,
         ? opaque_state: bstr
     ]

     where

     *  SS is the selected cipher suite used in the EDHOC session between
        U and V

     *  G_U is the ephemeral public key (G_X) of U

     *  Voucher_Info is as extracted from the EAD_1 field of message_1

     *  H_handshake is the hash of message_1.  It is computed using the
        EDHOC hash algorithm of the selected cipher suite SS specified in
        SUITE_I of EDHOC message_1.

     *  opaque_state is OPTIONAL and represents the serialized and
        encrypted opaque state needed by V to statelessly respond to U
        after the reception of Voucher_Response.

  4.6.1.2.  Processing in W

     W receives and parses the voucher request received over the secure
     connection with V.  W extracts from Voucher_Request:

     *  SS - the selected cipher suite, which is the (last) integer of
        SUITES_I.

     *  G_U - the ephemeral public key of U.

     *  ENC_U_INFO - the encryption of the device identifier ID_U,
        contained in the Voucher_Info field of Voucher_Request.

     *  H_handshake - the hash of message_1.

     W verifies and decrypts ENC_U_INFO using the relevant algorithms of
     the selected cipher suite SS (see Section 4.2), and obtains ID_U.

     W uses H_handshake as a session identifier, and associates it to the
     device identifier ID_U.  Note that message_1 contains a unique
     ephemeral key, therefore H_handshake is expected to be unique.





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


  Internet-Draft                     ELA                      October 2025


     If processing fails up until this point, the protocol SHALL be
     aborted with an error code signaling a generic issue with the
     request, see Section 5.4.1.

     W uses ID_U to look up the associated authorization policies for U
     and enforces them.  This is out of scope for the specification.

     If ID_U is known by W, but authorization fails, the protocol SHALL be
     aborted with an error code signaling an access control issue, see
     Section 4.7 and Section 5.4.1.

  4.6.2.  Voucher Response

  4.6.2.1.  Processing in W

     In case a Voucher is needed (as determined by the application), W
     retrieves CRED_V associated with the secure connection with V, and
     constructs the Voucher for the device with identifier ID_U (see
     Section 4.4.2).

     W generates the voucher response and sends it to V over the secure
     connection.  The Voucher_Response SHALL be a CBOR array as defined
     below:

     Voucher_Response = [
         ? Voucher:        bstr,
         ? opaque_state: bstr
     ]

     where

     *  The Voucher is defined in Section 4.4.2, if present.

     *  opaque_state is the echoed byte string opaque_state from
        Voucher_Request, if present.

     W signals the successful processing of Voucher_Request via a status
     code in the REST interface, as defined in Section 5.4.1.

  4.6.2.2.  Processing in V

     V receives the voucher response from W over the secure connection.
     If present, V decrypts and verifies opaque_state as received from W.
     If that verification fails, then the EDHOC session with U is aborted.
     If the voucher response is successfully received from W, then V
     responds to U with EDHOC message_2 as described in Section 4.5.2.1.





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


  Internet-Draft                     ELA                      October 2025


  4.7.  Error Handling

     This section specifies a new EDHOC error code and how it is used in
     ELA.

  4.7.1.  EDHOC Error "Access denied"

     This section specifies the new EDHOC error "Access denied", see
     Figure 4.

    +----------+----------------+----------------------------------------+
    | ERR_CODE | ERR_INFO Type  | Description                            |
    +==========+================+========================================+
    |     TBD3 | error_content  | Access denied                          |
    +----------+----------------+----------------------------------------+

    Figure 4: EDHOC error code and error information for ‘Access denied’.

     Error code TBD3 is used to indicate to the receiver that access
     control has been applied and the sender has aborted the EDHOC
     session.  The ERR_INFO field contains error_content which is a CBOR
     Sequence consisting of an integer and an optional byte string.

     error_content = (
       REJECT_TYPE : int,
       ? REJECT_INFO : bstr,
     )

     The purpose of REJECT_INFO is for the sender to provide verifiable
     and actionable information to the receiver about the error, so that
     an automated action may be taken to enable access.

    +-------------+---------------+--------------------------------------+
    | REJECT_TYPE | REJECT_INFO   | Description                          |
    +=============+===============+======================================+
    |           0 | -             | No REJECT_INFO                       |
    +-------------+---------------+--------------------------------------+
    |           1 | bstr          | REJECT_INFO from trusted third party |
    +-------------+---------------+--------------------------------------+

          Figure 5: REJECT_TYPE and REJECT_INFO for ‘Access denied’.

  4.7.2.  Error handling in W, V, and U

     ELA uses the EDHOC Error "Access denied" in the following way:






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


  Internet-Draft                     ELA                      October 2025


     *  W generates error_content and transfers it to V via the secure
        connection.  If REJECT_TYPE is 1, then REJECT_INFO is encrypted
        from W to U using the EDHOC AEAD algorithm.  W signals the error
        via an appropriate status code in the REST interface, as defined
        in Section 5.4.1.

     *  V receives error_content, prepares an EDHOC "Access denied" error,
        and sends it to U.

     *  U receives the error message and extracts the error_content.  If
        REJECT_TYPE is 1, then U decrypts REJECT_INFO, based on which it
        may retry to gain access.

     The encryption of REJECT_INFO follows a procedure analogous to the
     one defined in Section 4.4.2, with the following differences:

     plaintext = (
         OPAQUE_INFO:     bstr,
      )

     external_aad = (
         H_handshake:    bstr,
      )

     where

     *  OPAQUE_INFO is an opaque field that contains actionable
        information about the error.  It may contain, for example, a list
        of suggested Vs through which U should join instead.

     *  H_handshake is the hash of EDHOC message_1, calculated from the
        associated voucher request, see Section 4.6.1.

  4.8.  Reverse flow with U as Responder

     This section presents a protocol variant in which U is the EDHOC
     Responder.  This may allow optimizations in certain constrained
     network technologies.  For example, one use case is having V
     broadcast message_1, to which U responds with a message_2 whose EAD_2
     field contains Voucher_Info.

     Note that this is different from the EDHOC reverse message flow
     defined in Appendix A.2.2 of [RFC9528], since we make no assumption
     about whether U or V is a CoAP server.







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


  Internet-Draft                     ELA                      October 2025


  4.8.1.  U is the Initiator

     For clarity, we first present the "default flow" with U as Initiator,
     as described in Section 4.1 and Section 4.5.  Note that Voucher_Info
     and Voucher are carried in EDHOC message_1 and message_2,
     respectively.

    +-----+-----+                   +-----------+
    |     U     |                   |     V     |
    | Initiator |                   | Responder |
    +-----+-----+                   +-----+-----+
          |                               |
          |                               |
          |       EDHOC message_1         |                              W
          +------------------------------>|                              |
          | EAD_1 = (-TBD1, Voucher_info) |                              |
          |                               |             VREQ             |
          |                               +----------------------------->|
          |                               | (SS, G_X, Voucher_Info,      |
          |                               |  H_message_1, ?opaque_state) |
          |                               |                              |
          |                               |             VRES             |
          |                               +<---------------------------->|
          |                               |    (?Voucher, ?opaque_state) |
          |       EDHOC message_2         |
          +<------------------------------|
          |   EAD_2 = (-TBD2, ?Voucher)   |
          |                               |
          |       EDHOC message_3         |
          +------------------------------>|
          |                               |
          |                               |

           Figure 6: In ELA default flow, U is the EDHOC Initiator.

     In the ELA default flow, once message_2 processing is finalized
     (including processing of EAD_2), U considers V authenticated through
     W.

  4.8.2.  U is the Responder

     ELA also works with U as the EDHOC Responder, a setup we refer to as
     the "ELA reverse flow", as shown in Figure 7.

     We present this variant as a set of changes to the regular protocol
     flow.  That is, here we only describe the differences in processing,
     when compared to the ELA default flow.




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


  Internet-Draft                     ELA                      October 2025


     Here is a summary of the changes needed in the ELA reverse flow:

     *  Voucher_Info and Voucher are transported in EDHOC message_2 and
        message_3, respectively (instead of message_1 and message_2).

     *  The EAD_2 and EAD_3 fields carry critical EAD items identified
        with labels -TBD1 and -TBD2, respectively.

     *  The VREQ / VRES protocol takes place between message_2 and
        message_3.

     *  The Voucher_Request carries G_Y instead of G_X, and the transcript
        hash TH_2 instead of the hash H_message_1.

     *  Stateless operation of V (see Section 4.3) is not supported

    +-----+-----+                   +-----------+
    |     U     |                   |     V     |
    | Initiator |                   | Responder |
    +-----+-----+                   +-----+-----+
          |                               |
          |       Trigger Message         |
          +- - - - - - - - - - - - - - - >|
          |                               |
          |       EDHOC message_1         |
          +<------------------------------|
          |                               |
          |                               |
          |       EDHOC message_2         |                              W
          +------------------------------>|                              |
          | EAD_2 = (-TBD1, Voucher_info) |                              |
          |                               |             VREQ             |
          |                               +----------------------------->|
          |                               | (SS, G_Y, Voucher_Info,      |
          |                               |  TH_2, ?opaque_state)        |
          |                               |                              |
          |                               |             VRES             |
          |                               +<---------------------------->|
          |                               |    (Voucher, ?opaque_state)  |
          |     EDHOC message_3           |
          +<------------------------------|
          |   EAD_3 = (-TBD2, ?Voucher)   |
          |                               |
          |                               |

                 Figure 7: ELA when U is the EDHOC Responder.





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


  Internet-Draft                     ELA                      October 2025


     The following detail how the processing changes in each of the three
     security sessions.

     The way to interpret the subsections below is as follows.  The ELA
     reverse flow described in this section uses most of the ELA default
     flow processing (Section 4.1 to Section 4.7), except by the changes
     detailed in Section 4.8.2.1, Section 4.8.2.2, and Section 4.8.2.3.

  4.8.2.1.  Reverse U <-> W

     The protocol between U and W is carried between U and V in message_2
     and message_3, and between V and W in the Voucher Request/Response
     (Section 4.6).

     Voucher Info:

     *  The EAD_2 item has ead_label = -TBD1 and ead_value = Voucher_Info.

     Voucher:

     *  H_handshake is the transcript hash TH_2, sent by V as part of the
        voucher request, see Section 4.8.2.3.

  4.8.2.2.  Reverse U <-> V

     Message 1:

     *  V composes message_1 and sends it to U.

     *  U processes message_1 and extracts SS.

     Message 2:

     *  U composes message_2 and generates G_Y, which is reused in the
        interaction with W.

     *  U sends message_2 with critical EAD item (-TBD1, Voucher_Info)
        included in EAD_2.

     *  V processes message_2 and the EAD item in EAD_2, extracting the
        Voucher_Info struct.

     *  V sends the voucher request to W.

     Message 3:

     *  V receives the voucher response from W.




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


  Internet-Draft                     ELA                      October 2025


     *  V sends message_3 with critical EAD item (-TBD2, ?Voucher)
        included in EAD_3.

     *  Y processes message_3 and the EAD item in EAD_3.

  4.8.2.3.  Reverse V <-> W

     Processing in V:

     *  The Voucher_Request fields are prepared as defined in
        Section 4.6.1, with the following changes:

        -  G_U is set to G_Y, which is the ephemeral public key of U as
           extracted from message_2.

        -  Voucher_Info is as extracted from the EAD_2 field of message_2.

        -  H_handshake is the transcript hash TH_2, computed by V as
           specified in Section 5.3.2 of [RFC9528].

     Processing in W happens as specified in Section 4.6.1.

  4.8.3.  Interoperability considerations

     A Device (U) MUST implement one of the ELA flows, and it MAY choose
     to implement both.

     V MUST support the regular flow and MAY support the reverse flow.

     From the point of view of W, there is no difference whether U and V
     run as EDHOC Initiator or Responder.

  4.8.4.  Security implications

     When using the reverse flow, U shares its identity before it can
     learn (1) V's identity and (2) whether or not the Voucher is valid.

     In the reverse flow, Voucher_Info is confidentiality and integrity
     protected, while Voucher is also authenticated.  These properties are
     inherited from EDHOC message_2 and message_3.  This is a higher level
     of protection than with the regular flow.

  5.  REST Interface at W

     The interaction between V and W is enabled through a RESTful
     interface exposed by W.  This RESTful interface MAY be implemented
     using either HTTP or CoAP.  V SHOULD access the resources exposed by
     W through the protocol indicated by the scheme in the LOC_W URI.



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


  Internet-Draft                     ELA                      October 2025


  5.1.  Scheme "https"

     In case the scheme indicates "https", V MUST perform a TLS handshake
     with W and access the resources defined in Section 5.4 using HTTP.
     If the authentication credential CRED_V can be used in a TLS
     handshake, e.g., an X.509 certificate of a signature public key, then
     V SHOULD use it to authenticate to W as a client.  If the
     authentication credential CRED_V cannot be used in a TLS handshake,
     e.g., if the public key is a static Diffie-Hellman key, then V SHOULD
     first perform a TLS handshake with W using available compatible keys.
     V MUST then perform an EDHOC session over the TLS connection proving
     to W the possession of the private key corresponding to CRED_V.
     Performing the EDHOC session is only necessary if V did not
     authenticate with CRED_V in the TLS handshake with W.

     The relationship between V and W is long-lived.  HTTP/1.1 and higher
     support persistent connections, and SHOULD be used in order to reduce
     overhead if a flood of new devices need to be onboarded.  Support for
     TLS session resumptions tickets [RFC8446], Section 2.2 is appropriate
     for longer term associations.  While a policy for renewal of the TLS
     connection should be applied, it is out of scope of this document.

  5.2.  Scheme "coaps"

     In case the scheme indicates "coaps", V SHOULD perform a DTLS
     handshake with W and access the resources defined in Section 5.4
     using CoAP.  The normative requirements in Section 5.1 on performing
     the DTLS handshake and EDHOC session remain the same, except that TLS
     is replaced with DTLS.  As in Section 5.1, it is RECOMMENDED to allow
     reuse of the DTLS session.

  5.3.  Scheme "coap"

     In case the scheme indicates "coap", V SHOULD perform an EDHOC
     session with W, as specified in Appendix A of [RFC9528] and access
     the resources defined in Section 5.4 using OSCORE and CoAP.  The
     authentication credential in this EDHOC session MUST be CRED_V.  As
     in Section 5.1, it is RECOMMENDED to allow reuse of the EDHOC
     session.

  5.4.  URIs

     The URIs defined below are valid for both HTTP and CoAP.  W MUST
     support the use of the path-prefix "/.well-known/", as defined in
     [RFC8615], and the registered name "lake-authz".  A valid URI in case
     of HTTP thus begins with

     *  "https://www.example.com/.well-known/lake-authz"



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


  Internet-Draft                     ELA                      October 2025


     In case of CoAP with DTLS:

     *  "coaps://example.com/.well-known/lake-authz"

     In case of EDHOC and OSCORE:

     *  "coap://example.com/.well-known/lake-authz"

     Each operation specified in the following is indicated by a path-
     suffix.

  5.4.1.  Voucher Request (/voucherrequest)

     To request a voucher, V MUST issue a request such that:

     *  Method is POST

     *  Payload is the serialization of the Voucher Request object, as
        specified in Section 4.6.1.

     *  Content-Format (Content-Type) is set to "application/lake-authz-
        voucherrequest+cbor"

     In case of successful processing at W, W MUST issue a response such
     that:

     *  Status code is 200 OK if using HTTP, or 2.04 Changed if using CoAP

     *  Payload is the serialized Voucher Response object, as specified in
        Section 4.6.2

     *  Content-Format (Content-Type) is set to "application/lake-authz-
        voucherresponse+cbor"

     In case of error, two cases should be considered:

     *  U cannot be identified: this happens either if W fails to process
        the Voucher Request, or if it succeeds but ID_U is considered
        unknown to W.  In this case, W MUST reply with 400 Bad Request if
        using HTTP, or 4.00 if using CoAP.

     *  U is identified but unauthorized: this happens if W is able to
        process the Voucher Request, and W recognizes ID_U as a known
        device, but the access policies forbid enrollment.  For example,
        the policy could enforce enrollment within a delimited time
        window, via a specific V, etc.  In this case, W MUST reply with a
        403 Forbidden code if using HTTP, or 4.03 if using CoAP; the
        payload is the serialized error_content object, with Content-



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


  Internet-Draft                     ELA                      October 2025


        Format (Content-Type) set to "application/lake-authz-
        vouchererror+cbor".  The payload MAY be used by V to prepare an
        EDHOC error "Access Denied", see Section 4.7.

  5.4.2.  Certificate Request (/certrequest)

     V requests the public key certificate of U from W through the
     "/certrequest" path-suffix.  To request U's authentication
     credential, V MUST issue a request such that:

     *  Method is POST

     *  Payload is the serialization of the ID_CRED_I object, as received
        in EDHOC message_3.

     *  Content-Format (Content-Type) is set to "application/lake-authz-
        certrequest+cbor"

     In case of a successful lookup of the authentication credential at W,
     W MUST issue a response such that:

     *  Status code is 200 OK if using HTTP, or 2.04 Changed if using CoAP

     *  Payload is the serialized CRED_U

     *  Content-Format (Content-Type) is set to "application/lake-authz-
        certresponse+cbor"

  6.  Security Considerations

     This specification builds on and reuses many of the security
     constructions of EDHOC, e.g., shared secret calculation and key
     derivation.  The security considerations of EDHOC [RFC9528] apply
     with modifications discussed here.

     EDHOC provides identity protection of the Initiator, here the device.
     The encryption of the device identifier ID_U in the first message
     should consider potential information leaking from the length of
     ID_U, either by making all identifiers having the same length or the
     use of a padding scheme.











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


  Internet-Draft                     ELA                      October 2025


     Although W learns about the identity of U after receiving VREQ, this
     information must not be disclosed to V, until U has revealed its
     identity to V with ID_CRED_I in message_3.  W may be used for lookup
     of CRED_U from ID_CRED_I, or this credential lookup function may be
     separate from the authorization function of W, see Figure 3.  The
     trust model used here is that U decides to which V it reveals its
     identity.  In an alternative trust model where U trusts W to decide
     to which V it reveals U's identity, CRED_U could be sent in Voucher
     Response.

     As noted in Section 9.2 of [RFC9528] an ephemeral key may be used to
     calculate several ECDH shared secrets.  In this specification, the
     ephemeral key G_X is also used to calculate G_XW, the shared secret
     with the enrollment server.

     The private ephemeral key is thus used in the device for calculations
     of key material relating to both the authenticator and the enrollment
     server.  There are different options for where to implement these
     calculations.  One option is as an addition to EDHOC, i.e., to extend
     the EDHOC API in the device, so that EDHOC can import the public key
     of W (G_W) and the device identifier of U (ID_U), and then produce
     the encryption of ID_U which is included in Voucher_Info in EAD_1.

  7.  IANA Considerations

  7.1.  EDHOC External Authorization Data Registry

     IANA has registered the following entries in the "EDHOC External
     Authorization Data" registry under the group name "Ephemeral Diffie-
     Hellman Over COSE (EDHOC)".

            +=======+============+===============================+
            | Label | Value Type | Description                   |
            +=======+============+===============================+
            |  TBD1 | bstr       | Voucher_Info structure,       |
            |       |            | prepared by the Device (U).   |
            +-------+------------+-------------------------------+
            |  TBD2 | bstr       | Voucher structure, prepared   |
            |       |            | by the Enrollment Server (W). |
            +-------+------------+-------------------------------+

                 Table 2: Addition to the EDHOC EAD registry

     The ead_label = TBD1 corresponds to the ead_value = Voucher_Info,
     which can be carried in either EAD_1 or EAD_2, depending on whether U
     acts as EDHOC Initiator or Responder, see Section 4.8.





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


  Internet-Draft                     ELA                      October 2025


     The ead_label = TBD2 corresponds to ead_value = Voucher, and can be
     carried in either EAD_2 or EAD_3, see Section 4.8.

     Note for IANA reviewers: the preferred value range is 0-23 (Standards
     Action with Expert Review).

  7.2.  The Well-Known URI Registry

     IANA has registered the following entry in "The Well-Known URI
     Registry", using the template from [RFC8615]:

     *  URI suffix: lake-authz

     *  Change controller: IETF

     *  Specification document: [[this document]]

     *  Status: permanent

     *  Related information: None

  7.3.  Well-Known Name Under ".arpa" Name Space

     This document allocates a well-known name under the .arpa name space
     according to the rules given in [RFC3172] and [RFC6761].  The name
     "lake-authz.arpa" is requested.  No subdomains are expected, and
     addition of any such subdomains requires the publication of an IETF
     Standards Track RFC.  No A, AAAA, or PTR record is requested.

  7.3.1.  Domain Name Reservation Considerations

     As required by [RFC6761], the following considerations apply to the
     reservation of "lake-authz.arpa":

     1.  Users: Are human users expected to recognize these names as
         special and use them differently?  In what way?

     No.  This name is not intended for direct use or recognition by human
     users.

     1.  Application Software: Are writers of application software
         expected to make their software recognize these names as special
         and treat them differently?  In what way?  (For example, if a
         human user enters such a name, should the application software
         reject it with an error message?)






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


  Internet-Draft                     ELA                      October 2025


     Yes. Applications that implement ELA and use CoAP may include "lake-
     authz.arpa" in the URI-Host option when the Device (U) does not yet
     know the address or identity of the Authenticator (V), such as during
     zero-touch enrollment.

     1.  Name Resolution APIs and Libraries: Are writers of name
         resolution APIs and libraries expected to make their software
         recognize these names as special and treat them differently?  If
         so, how?

     No.

     1.  Caching DNS Servers: Are developers of caching domain name
         servers expected to make their implementations recognize these
         names as special and treat them differently?  If so, how?

     No.

     1.  Authoritative DNS Servers: Are developers of authoritative domain
         name servers expected to make their implementations recognize
         these names as special and treat them differently?  If so, how?

     No.

     1.  DNS Server Operators: Does this reserved Special-Use Domain Name
         have any potential impact on DNS server operators?  If they try
         to configure their authoritative DNS server as authoritative for
         this reserved name, will compliant name server software reject it
         as invalid?  Do DNS server operators need to know about that and
         understand why?  Even if the name server software doesn't prevent
         them from using this reserved name, are there other ways that it
         may not work as expected, of which the DNS server operator should
         be aware?

     No.

     1.  DNS Registries/Registrars: How should DNS Registries/Registrars
         treat requests to register this reserved domain name?  Should
         such requests be denied?  Should such requests be allowed, but
         only to a specially designated entity?  (For example, the name
         "www.example.org" is reserved for documentation examples and is
         not available for registration; however, the name is in fact
         registered; and there is even a website at that name, which
         states circularly that the name is reserved for use in
         documentation and cannot be registered!)

     Any requests to register this domain name should be denied.




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


  Internet-Draft                     ELA                      October 2025


  7.4.  Media Types Registry

     IANA has added the media types "application/lake-authz-
     voucherrequest+cbor" to the "Media Types" registry.

  7.4.1.  application/lake-authz-voucherrequest+cbor Media Type
          Registration

     *  Type name: application

     *  Subtype name: lake-authz-voucherrequest+cbor

     *  Required parameters: N/A

     *  Optional parameters: N/A

     *  Encoding considerations: binary (CBOR)

     *  Security considerations: See Section 6 of this document.

     *  Interoperability considerations: N/A

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

     *  Application that use this media type: To be identified

     *  Fragment identifier considerations: N/A

     *  Additional information:

        -  Magic number(s): N/A

        -  File extension(s): N/A

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

     *  Person & email address to contact for further information: IETF
        LAKE Working Group (lake@ietf.org)

     *  Intended usage: COMMON

     *  Restrictions on usage: N/A

     *  Author: LAKE WG

     *  Change Controller: IETF





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


  Internet-Draft                     ELA                      October 2025


  7.5.  CoAP Content-Formats Registry

     IANA has added the following Content-Format number in the "CoAP
     Content-Formats" registry under the registry group "Constrained
     RESTful Environments (CoRE) Parameters".

       +================================+==========+======+============+
       | Content Type                   | Content  | ID   | Reference  |
       |                                | Encoding |      |            |
       +================================+==========+======+============+
       | application/lake-authz-        | -        | TBD3 | [[this     |
       | voucherrequest+cbor            |          |      | document]] |
       +--------------------------------+----------+------+------------+

             Table 3: Addition to the CoAP Content-Formats registry

     Note for IANA reviewers: the preferred value range is 0-255 (Expert
     Review).

  8.  References

  8.1.  Normative References

     [NIST-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://nvlpubs.nist.gov/nistpubs/SpecialPublications/
                NIST.SP.800-56Ar3.pdf>.

     [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
                "A Voucher Artifact for Bootstrapping Protocols",
                RFC 8366, DOI 10.17487/RFC8366, May 2018,
                <https://www.rfc-editor.org/info/rfc8366>.

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

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







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


  Internet-Draft                     ELA                      October 2025


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

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

  8.2.  Informative References

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

     [I-D.ietf-core-oscore-edhoc]
                Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
                G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
                (EDHOC) with the Constrained Application Protocol (CoAP)
                and Object Security for Constrained RESTful Environments
                (OSCORE)", Work in Progress, Internet-Draft, draft-ietf-
                core-oscore-edhoc-11, 9 April 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-core-
                oscore-edhoc-11>.

     [I-D.ietf-lake-reqs]
                Vučinić, M., Selander, G., Mattsson, J. P., and D. Garcia-
                Carillo, "Requirements for a Lightweight AKE for OSCORE",
                Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04,
                8 June 2020, <https://datatracker.ietf.org/doc/html/draft-
                ietf-lake-reqs-04>.

     [IEEE802.15.4]
                IEEE standard for Information Technology, "IEEE Std
                802.15.4 Standard for Low-Rate Wireless Networks", n.d..







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


  Internet-Draft                     ELA                      October 2025


     [IEEE802.1X]
                IEEE standard for Information Technology, "IEEE Standard
                for Local and metropolitan area networks - Port-Based
                Network Access Control", February 2010.

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

     [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
                Requirements for the Address and Routing Parameter Area
                Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
                September 2001, <https://www.rfc-editor.org/info/rfc3172>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/info/rfc5280>.

     [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
                RFC 6761, DOI 10.17487/RFC6761, February 2013,
                <https://www.rfc-editor.org/info/rfc6761>.

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

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

     [RFC8137]  Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information
                Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May
                2017, <https://www.rfc-editor.org/info/rfc8137>.

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

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





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


  Internet-Draft                     ELA                      October 2025


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

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/info/rfc8615>.

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

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

  Appendix A.  Optimization Strategies

     When ELA is used for zero-touch enrollment of IoT devices, U may have
     little to no knowledge about V's available in its vicinity.  This may
     lead to situations where U retries several times at different V's
     until it finds one that works.  This section presents two
     optimization strategies for such cases.  They were developed to
     address scenarios where V's are radio gateways to which U wants to
     enroll, but may also be applicable to other use cases.

  A.1.  U broadcasts message_1

     This strategy consists in U broadcasting EDHOC message_1.  When each
     of the V's in radio range of U receive message_1, one of the
     following can happen:

     *  V does not implement EDHOC, and drops the message

     *  V does not implement ELA, and drops the message (even though the
        EAD_1 option is critical, broadcast messages should not have error
        replies)

     *  V forwards message_1 to W as VREQ, but W does not authorize it,
        and error handling is applied

     *  V forwards message_1 to W as VREQ, W authorizes it, and the
        protocol continues normally




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


  Internet-Draft                     ELA                      October 2025


     U is expected to receive and process at most one message_2 as
     response, which contains the Voucher.  In case U receives additional
     message_2's, they MUST be silently dropped.

     This strategy may increase the number of messages that need to be
     processed by V and W, in exchange for reducing resource usage in U.

     Security concerns related to this strategy, including potential reuse
     of G_X and double processing of message_2, are discussed in
     Section 6.

  A.2.  V advertises support for ELA

     In this strategy, V shares some information (V_INFO) with a potential
     U, that can help it decide whether to try to enroll with that V.

     The exact contents of the V_INFO structure, as well as the mechanism
     used to transport it, will depend on the underlying communication
     technology and also on application needs.  For example, V_INFO may
     state that:

     *  V implements ELA -- similarly to how EAPOL [IEEE802.1X] frames
        state support for IEEE 802.1X.

     *  V is part of a certain domain -- similarly to how Eduroam
        [RFC7593] is used in the SSID field of IEEE 802.11 packets

     V_INFO can be sent over a network beacon (see Appendix A.2.1), which
     may require technology specific profiling, e.g., the IEEE 802.15.4
     enhanced beacon may be extended according to [RFC8137].
     Alternatively, V_INFO can be sent as part of an EAD field, as shown
     in Appendix A.2.2.

     As a guideline for implementers, we define the following field that
     can be included in a V_INFO structure:

     DOMAIN_ID: bstr

     The DOMAIN_ID field identifies the domain to which V belongs to, for
     example an URL or UUID.

     Below are three examples of how the advertisement strategy may be
     applied according to different application needs.  The examples
     include sending V_INFO in network beacons, as part of EAD_1 in
     reverse message flow, or as part of a periodic CoAP multicast packet.
     The advantages, costs, and security impacts of each approach are also
     discussed.




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


  Internet-Draft                     ELA                      October 2025


  A.2.1.  V_INFO in network beacons

     This approach allows carrying V_INFO in beacons sent over the network
     layer, as shown in Figure 8.  It requires that the network layer
     offers a mechanism to configure its beacon packets.  Depending on the
     network type, a solicitation packet may also be needed, as is the
     case of non-beaconed IEEE 802.15.4 and BLE with GATT.

          +-------+--------+                       +-------+--------+
          | Init  | Client |                       | Resp  | Server |
          +-------+--------+                       +----------------+
          |       U        |                       |       V        |
          +----------------+                       +----------------+
                  |                                        |
                  + - - - - - - - - - - - - - - - - - - -->|
                  |     Optional network solicitation      |
                  |                                        |
                  |<---------------------------------------+
                  |   Network discovery (contains V_INFO)  |
                  |                                        |
                  |            EDHOC message_1             |
                  +--------------------------------------->|
                  |        (?EAD_1 = Voucher_Info)         |
                  |                                        |

                   ( ... protocol continues normally ... )

        Figure 8: Advertising ELA using V_INFO in network-layer beacons.

     This strategy can be used, for example, in IEEE 802.15.4, where an
     Enhanced Beacon [IEEE802.15.4] can be used to transmit V_INFO.
     Specifically, a new information element for carrying V_INFO can be
     defined according to [RFC8137].

     This approach has the advantage of requiring minimal changes to the
     default protocol as presented in Section 4.1, i.e., no reverse flow.
     It requires, however, some profiling of the lower layer beacons.

  A.2.2.  V_INFO in EAD_1

     The ELA reverse flow (see Section 4.8) allows implementing
     advertising where U first sends a trigger packet, in the format of a
     CoAP request that is broadcasted to the newtork.  When a suitable V
     receives the solicitation, if it implements ELA, it should respond
     with an EDHOC message_1 whose EAD_1 has label -TBD1 and value V_INFO
     (see Section Appendix A).





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


  Internet-Draft                     ELA                      October 2025


             +-------+--------+                +-------+--------+
             | Resp  | Client |                | Init  | Server |
             +-------+--------+                +----------------+
             |       U        |                |       V        |
             +----------------+                +----------------+
                     |                                 |
                     +-------------------------------->|
                     |   CoAP discovery/solicitation   |
                     |                                 |
                     |        EDHOC message_1          |
                     +<--------------------------------|
                     |       (?EAD_1 = V_INFO)         |
                     |                                 |

                  ( ... reverse flow continues normally ... )

         Figure 9: Advertising ELA using V_INFO in EAD_1, eploying the
                    EDHOC reverse flow with U as responder.

     Note that V will only reply if it supports ELA.  V_INFO can be
     structured to contain only an optional domain identifier:

     V_INFO = (
       ?DOMAIN_ID: bstr,
     )

     This approach enables a simple filtering mechanism, where only V's
     that support ELA will reply.  It also encrypts Voucher_Info (as part
     of EAD_2), whereas it is sent in the clear in the original flow.  In
     addition, it may not require layer-two profiling (in case the network
     allows transporting data before authorization).  Finally, note that
     the reverse flow with U as Responder protects the identity of V
     (instead of U's as in the forward flow).

  A.2.3.  V_INFO in a CoAP Multicast Packet

     In this approach, V periodically multicasts a CoAP packet containing
     V_INFO, see Figure 10.  Upon receiving one or more CoAP messages and
     processing V_INFO, U can decide whether or not to initiate the ELA
     protocol with a given V.  Next, the application can either keep U
     acting as a server, and thus employ the EDHOC reverse flow, or
     implement a CoAP client and use the forward flow.









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


  Internet-Draft                     ELA                      October 2025


        +--------+---------+                       +--------+---------+
        |  Init  | Cli/Ser |                       |  Resp  | Cli/Ser |
        +--------+---------+                       +------------------+
        |        U         |                       |        V         |
        +------------------+                       +------------------+
                 |                                          |
                 |          POST /ela-advertisement         |
                 |<-----------------------------------------+
                 |     CoAP multicast (contains V_INFO)     |
                 |                                          |
                 |              EDHOC message_1             |
                 +----------------------------------------->|
                 |          (?EAD_1 = Voucher_Info)         |
                 |                                          |

                  ( ... protocol continues normally ... )

              Figure 10: Advertising ELA using the network layer.

     The V_INFO structure is sent as part of the CoAP payload.  It is
     encoded as a CBOR sequence:

     V_INFO = (
       ?DOMAIN_ID: bstr,
     )

     One advantage of this approach is that, since U is the initiator, its
     identity is protected in the context of the EDHOC handshake.  On the
     other hand, the periodic multicast may have resource usage impacts in
     the network.

  Appendix B.  Use with Constrained Join Protocol (CoJP)

     This section outlines how ELA is used for network enrollment and
     parameter provisioning.  An IEEE 802.15.4 network is used as an
     example of how a new device (U) can be enrolled into the domain
     managed by the domain authenticator (V).














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


  Internet-Draft                     ELA                      October 2025


     U                                    V                              W
     |                                    |                              |
     |                                    |                              |
     + - - - - - - - - - - - - - - - - -->|                              |
     |    Optional network solicitation   |                              |
     |<-----------------------------------+                              |
     |          Network discovery         |                              |
     |                                    |                              |
     +----------------------------------->|                              |
     |          EDHOC message_1           |                              |
     |                                    +----------------------------->|
     |                                    |    Voucher Request (VREQ)    |
     |                                    |<-----------------------------+
     |                                    |    Voucher Response (VRES)   |
     |<-----------------------------------+                              |
     |          EDHOC message_2           |                              |
     |                                    |                              |
     |                                    |                              |
     +----------------------------------->|                              |
     |   EDHOC message_3 + CoJP request   |                              |
     |                                    |                              |
     +<-----------------------------------|                              |
     |            CoJP response           |                              |
     |

               Figure 11: Use of draft-ietf-lake-authz with CoJP.

  B.1.  Network Discovery

     When a device first boots, it needs to discover the network it
     attempts to join.  The network discovery procedure is defined by the
     link-layer technology in use.  In case of Time-slotted Channel
     Hopping (TSCH) networks, a mode of [IEEE802.15.4], the device scans
     the radio channels for Enhanced Beacon (EB) frames, a procedure known
     as passive scan.  EBs carry the information about the network, and
     particularly the network identifier.  Based on the EB, the network
     identifier, the information pre-configured into the device, the
     device makes the decision on whether it should join the network
     advertised by the received EB frame.  This process is described in
     Section 4.1 of [RFC9031].  In case of other, non-TSCH modes of IEEE
     802.15.4, it is possible to use the active scan procedure and send
     solicitation frames.  These solicitation frames trigger the nearest
     network coordinator to respond by emitting a beacon frame.  The
     network coordinator emitting beacons may be multiple link-layer hops
     away from the domain authenticator (V), in which case it plays the
     role of a Join Proxy (see [RFC9031]).  The Join Proxy does not
     participate in the protocol and acts as a transparent router between
     the device and the domain authenticator.  For simplicity, Figure 11



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


  Internet-Draft                     ELA                      October 2025


     illustrates the case when the device and the domain authenticator are
     a single hop away and can communicate directly.

  B.2.  The Enrollment Protocol with Parameter Provisioning

  B.2.1.  Flight 1

     Once the device has discovered the network it wants to join, it
     constructs EDHOC message_1, as described in Section 4.5.  The device
     SHALL map the message to a CoAP request:

     *  The request method is POST.

     *  The type is Confirmable (CON).

     *  The Proxy-Scheme option is set to "coap".

     *  The Uri-Host option is set to "lake-authz.arpa".  This is an
        anycast type of identifier of the domain authenticator (V) that is
        resolved to its IPv6 address by the Join Proxy.

     *  By means of Uri-Path options, the Uri-Path is set to ".well-known/
        edhoc".

     *  The payload is the (true, EDHOC message_1) CBOR sequence, where
        EDHOC message_1 is constructed as defined in Section 4.5.

  B.2.2.  Flight 2

     The domain authenticator receives message_1 and processes it as
     described in Section 4.5.  The message triggers the exchange with the
     enrollment server, as described in Section 4.6.  If the exchange
     between V and W completes successfully, the domain authenticator
     prepares EDHOC message_2, as described in Section 4.5.  The
     authenticator SHALL map the message to a CoAP response:

     *  The response code is 2.04 Changed.

     *  The payload is the EDHOC message_2, as defined in Section 4.5.

  B.2.3.  Flight 3

     The device receives EDHOC message_2 and processes it as described in
     Section 4.5.  Upon successful processing of message_2, the device
     prepares flight 3, which is an OSCORE-protected CoJP request
     containing an EDHOC message_3, as described in
     [I-D.ietf-core-oscore-edhoc].  EDHOC message_3 is prepared as
     described in Section 4.5.  The OSCORE-protected payload is the CoJP



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


  Internet-Draft                     ELA                      October 2025


     Join Request object specified in Section 8.4.1 of [RFC9031].  OSCORE
     protection leverages the OSCORE Security Context derived from the
     EDHOC session, as specified in Appendix A of [RFC9528].  To that end,
     [I-D.ietf-core-oscore-edhoc] specifies that the Sender ID of the
     client (device) must be set to the connection identifier selected by
     the domain authenticator, C_R.  OSCORE includes the Sender ID as the
     kid in the OSCORE option.  The network identifier in the CoJP Join
     Request object is set to the network identifier obtained from the
     network discovery phase.  In case of IEEE 802.15.4 networks, this is
     the PAN ID.

     The device SHALL map the message to a CoAP request:

     *  The request method is POST.

     *  The type is Confirmable (CON).

     *  The Proxy-Scheme option is set to "coap".

     *  The Uri-Host option is set to "lake-authz.arpa".

     *  The Uri-Path option is set to ".well-known/edhoc".

     *  The EDHOC option [I-D.ietf-core-oscore-edhoc] is set and is empty.

     *  The payload is prepared as described in Section 3.2 of
        [I-D.ietf-core-oscore-edhoc], with EDHOC message_3 and the CoJP
        Join Request object as the OSCORE-protected payload.

     Note that the OSCORE Sender IDs are derived from the connection
     identifiers of the EDHOC session.  This is in contrast with [RFC9031]
     where ID Context of the OSCORE Security Context is set to the device
     identifier (pledge identifier).  Since the device identity is
     exchanged during the EDHOC session, and the certificate of the device
     is communicated to the authenticator as part of the Voucher Response
     message, there is no need to transport the device identity in OSCORE
     messages.  The authenticator playing the role of the [RFC9031] JRC
     obtains the device identity from the execution of the authorization
     protocol.

  B.2.4.  Flight 4

     Flight 4 is the OSCORE response carrying CoJP response message.  The
     message is processed as specified in Section 8.4.2 of [RFC9031].







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


  Internet-Draft                     ELA                      October 2025


  Appendix C.  Example of opaque_state

     As per Section 4.3, V may act statelessly and transmit a opaque_state
     to W during the VREQ call.  The example below contains an IPv4
     address, a port number, and a timestamp, serialized as CBOR:

     83             # array(3)
        84          # array(4)
           18 C0    # unsigned(192)
           18 A8    # unsigned(168)
           00       # unsigned(0)
           05       # unsigned(5)
        19 5A18     # unsigned(23064)
        1A 6867EEE4 # unsigned(1751641828)

     The above plaintext state can be encrypted using COSE.  Speficially,
     it is useful that the plaintext is not only encrypted but also
     authenticated.  That can be achieved using COSE_Encrypt0 using an
     AEAD algorithm.

  Appendix D.  Examples of protocol execution

     This section presents high level examples of the protocol execution.

     Note: the examples below include samples of access policies used by
     W.  These are provided for the sake of completeness only, since the
     authorization mechanism used by W is out of scope in this document.

  D.1.  Minimal

     This is a simple example that demonstrates a successful execution of
     ELA.

     Premises:

     *  device u1 has ID_U = key id = 14

     *  the access policy in W specifies, via a list of ID_U, that device
        u1 can enroll via any domain authenticator, i.e., the list
        contains ID_U = 14.  In this case, the policy only specifies a
        restriction in terms of U, effectively allowing enrollment via any
        V.

     Execution:

     1.  device u1 discovers a gateway (v1) and tries to enroll





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


  Internet-Draft                     ELA                      October 2025


     2.  gateway v1 identifies the zero-touch join attempt by checking
         that the label of EAD_1 = -TBD1, and prepares a Voucher Request
         using the information contained in the value of EAD_1

     3.  upon receiving the request, W obtains ID_U = 14, authorizes the
         access, and replies with Voucher Response

  D.2.  Wrong gateway

     In this example, a device u1 tries to enroll a domain via gateway v1,
     but W denies the request because the pairing (u1, v1) is not
     configured in its access policies.

     This example also illustrates how the REJECT_INFO field of the EDHOC
     error Access Denied could be used, in this case to suggest that the
     device should select another gateway for the join procedure.

     Premises:

     *  devices and gateways communicate via Bluetooth Low Energy (BLE),
        therefore their network identifiers are MAC addresses (EUI-48)

     *  device u1 has ID_U = key id = 14

     *  there are 3 gateways in the radio range of u1:

        -  v1 with MAC address = A2-A1-88-EE-97-75

        -  v2 with MAC address = 28-0F-70-84-51-E4

        -  v3 with MAC address = 39-63-C9-D0-5C-62

     *  the access policy in W specifies, via a mapping of shape (ID_U;
        MAC1, MAC2, ...) that device u1 can only join via gateway v3,
        i.e., the mapping is: (14; 39-63-C9-D0-5C-62)

     *  W is able to map the PoP key of the gateways to their respective
        MAC addresses

     Execution:

     1.  device u1 tries to join via gateway v1, which forwards the
         request to W








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


  Internet-Draft                     ELA                      October 2025


     2.  W determines that MAC address A2-A1-88-EE-97-75 is not in the
         access policy mapping, and replies with an error.  The
         error_content has REJECT_TYPE = 1, and the plaintext OPAQUE_INFO
         (used to compute the encrypted REJECT_INFO) specifies a list of
         suggested gateways = [h'3963C9D05C62'].  The single element in
         the list is the 6-byte MAC address of v3, serialized as a bstr.

     3.  gateway v1 assembles an EDHOC error "Access Denied" with
         error_content, and sends it to u1

     4.  device u1 processes the error, decrypts REJECT_INFO, and retries
         the protocol via gateway v3

  Acknowledgments

     The authors sincerely thank Aurelio Schellenbaum for his contribution
     in the initial phase of this work, and Marco Tiloca for extensively
     reviewing the document.  We also thank Christian Amsüss for his
     active participation in discussions that led to improvements in 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
     Sweden
     Email: goran.selander@ericsson.com


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


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


     Geovane Fedrecheski
     INRIA
     France



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


  Internet-Draft                     ELA                      October 2025


     Email: geovane.fedrecheski@inria.fr


     Michael Richardson
     Sandelman Software Works
     Canada
     Email: mcr+ietf@sandelman.ca












































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


name: draft-ietf-emu-eap-edhoc
rev: 07
title: Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC)
time: 2026-03-04T14:22:48Z
group_uri: /api/v1/group/group/1674/
expires: 2026-08-03T06:08:00Z
ad: /api/v1/person/person/112723/
shepherd: /api/v1/person/email/renzoefra@gmail.com/
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081875+00:00
source: ietf
abstract:
  The Extensible Authentication Protocol (EAP), defined in RFC 3748,
     provides a standard mechanism for support of multiple authentication
     methods.  This document specifies the EAP authentication method EAP-
     EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC).  EDHOC is
     a lightweight security handshake protocol, enabling authentication
     and establishment of shared secret keys suitable in constrained
     settings.  This document also provides guidance on authentication and
     authorization for EAP-EDHOC.

states:
  ["/api/v1/doc/state/1/", "/api/v1/doc/state/114/", "/api/v1/doc/state/12/", "/api/v1/doc/state/44/"]

full_text:
  EAP Method Update                                     D. Garcia-Carrillo
  Internet-Draft                                      University of Oviedo
  Intended status: Standards Track                          R. Marin-Lopez
  Expires: 3 August 2026                              University of Murcia
                                                               G. Selander
                                                         J. Preuß Mattsson
                                                                  Ericsson
                                                            F. Lopez-Gomez
                                                      University of Murcia
                                                           30 January 2026


     Using the Extensible Authentication Protocol (EAP) with Ephemeral
                      Diffie-Hellman over COSE (EDHOC)
                        draft-ietf-emu-eap-edhoc-07

  Abstract

     The Extensible Authentication Protocol (EAP), defined in RFC 3748,
     provides a standard mechanism for support of multiple authentication
     methods.  This document specifies the EAP authentication method EAP-
     EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC).  EDHOC is
     a lightweight security handshake protocol, enabling authentication
     and establishment of shared secret keys suitable in constrained
     settings.  This document also provides guidance on authentication and
     authorization for EAP-EDHOC.

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

     Discussion of this document takes place on the EAP Method Update
     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/.

     Source for this draft and an issue tracker can be found at
     https://github.com/dangarciacarrillo/i-d-eap-edhoc.

  Status of This Memo

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





  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 1]


  Internet-Draft                  EAP-EDHOC                   January 2026


     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 3 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
       1.1.  EDHOC Overview  . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Overview of the EAP-EDHOC Conversation  . . . . . . . . .   5
         3.1.1.  Successful EAP-EDHOC Message Flow without
                 Fragmentation . . . . . . . . . . . . . . . . . . . .   6
         3.1.2.  Transport and Message Correlation . . . . . . . . . .   8
         3.1.3.  Termination . . . . . . . . . . . . . . . . . . . . .   8
         3.1.4.  Identity  . . . . . . . . . . . . . . . . . . . . . .  12
         3.1.5.  Privacy . . . . . . . . . . . . . . . . . . . . . . .  13
         3.1.6.  Fragmentation . . . . . . . . . . . . . . . . . . . .  13
       3.2.  Identity Verification . . . . . . . . . . . . . . . . . .  16
       3.3.  Key Hierarchy . . . . . . . . . . . . . . . . . . . . . .  17
       3.4.  Parameter Negotiation and Compliance Requirements . . . .  18
       3.5.  EAP State Machines  . . . . . . . . . . . . . . . . . . .  18
       3.6.  EAP Channel Binding . . . . . . . . . . . . . . . . . . .  18
     4.  Detailed Description of the EAP-EDHOC Request and Response
             Protocol  . . . . . . . . . . . . . . . . . . . . . . . .  19
       4.1.  EAP-EDHOC Request Packet  . . . . . . . . . . . . . . . .  20



  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 2]


  Internet-Draft                  EAP-EDHOC                   January 2026


       4.2.  EAP-EDHOC Response Packet . . . . . . . . . . . . . . . .  21
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
       5.1.  EAP Type  . . . . . . . . . . . . . . . . . . . . . . . .  22
       5.2.  EDHOC Exporter Label Registry . . . . . . . . . . . . . .  22
       5.3.  EDHOC External Authorization Data Registry  . . . . . . .  22
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
       6.1.  Security Claims . . . . . . . . . . . . . . . . . . . . .  23
         6.1.1.  EAP Security Claims . . . . . . . . . . . . . . . . .  23
         6.1.2.  Additional Security Claims  . . . . . . . . . . . . .  26
       6.2.  Peer and Server Identities  . . . . . . . . . . . . . . .  26
       6.3.  Certificate Validation  . . . . . . . . . . . . . . . . .  26
       6.4.  Certificate Revocation  . . . . . . . . . . . . . . . . .  26
       6.5.  Packet Modification Attacks . . . . . . . . . . . . . . .  27
       6.6.  Authorization . . . . . . . . . . . . . . . . . . . . . .  27
       6.7.  Privacy Considerations  . . . . . . . . . . . . . . . . .  27
       6.8.  Pervasive Monitoring  . . . . . . . . . . . . . . . . . .  27
       6.9.  Cross-Protocol Attacks  . . . . . . . . . . . . . . . . .  27
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  27
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  28
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  31
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

  1.  Introduction

     The Extensible Authentication Protocol (EAP), defined in [RFC3748],
     provides a standard mechanism for support of multiple authentication
     methods.  This document specifies the EAP authentication method EAP-
     EDHOC, which is based on the lightweight security handshake protocol
     Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528].

     EAP-EDHOC is similar to EAP-TLS 1.3 [RFC9190], since EDHOC is based
     on a similar security protocol design as the TLS 1.3 handshake
     [RFC8446].  However, EDHOC has been optimized for highly constrained
     settings, for example involving wirelessly connected battery powered
     'things' with embedded microcontrollers, sensors, and actuators.  An
     overview of EDHOC is given in Section 1.1.

     The EAP-EDHOC method enables the integration of EDHOC into different
     applications and use cases using the EAP framework.

  1.1.  EDHOC Overview

     Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight
     authenticated ephemeral key exchange, including mutual authentication
     and establishment of shared secret keying material, see [RFC9528].





  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 3]


  Internet-Draft                  EAP-EDHOC                   January 2026


     EDHOC provides state-of-the-art security design at very low message
     overhead, targeting low complexity implementations and allowing
     extensibility.  The security of EDHOC has been thoroughly analyzed,
     some references are provided in Section 9.1 of [RFC9528].

     The main features of EDHOC are:

     *  Support for different authentication methods and credentials.  The
        authentication methods include (mixed) signatures and static
        Diffie-Hellman keys [RFC9528], and pre-shared keys
        [I-D.ietf-lake-edhoc-psk].  A wide and extensible range of
        authentication credentials is supported, including public key
        certificates such as X.509 and C509
        [I-D.ietf-cose-cbor-encoded-cert], as well as CBOR Web Tokens
        (CWTs) and CWT Claims Sets (CCSs) [RFC8392].

     *  A standardized and extensible format for identification of
        credentials, using COSE header parameters [RFC9052], supporting
        credential transport by value or by reference, enabling very
        compact representations.

     *  Crypto agility and secure cipher suite negotiation, with
        predefined compactly represented cipher suites and support for
        extensibility using the COSE algorithms registry [RFC9053].

     *  Selection of connection identifiers identifying a session for
        which keys are agreed.

     *  Support for integration of external security applications into
        EDHOC by transporting External Authorization Data (EAD) included
        in and protected as EDHOC messages.

     A necessary condition for a successful completion of an EDHOC session
     is that both peers support a common application profile including
     method, cipher suite, etc.  More details are provided in
     [I-D.ietf-lake-app-profiles].

     EDHOC messages make use of lightweight primitives, specifically CBOR
     [RFC8949] and COSE [RFC9052] [RFC9053] for efficient encoding and
     security services in constrained devices.  EDHOC is optimized for use
     with CoAP [RFC7252] and OSCORE [RFC8613] to secure resource access in
     constrained IoT use cases, but it is not bound to a particular
     transport or communication security protocol.








  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 4]


  Internet-Draft                  EAP-EDHOC                   January 2026


  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.

     Readers are expected to be familiar with the terms and concepts
     described in EAP [RFC3748] and EDHOC [RFC9528].

  3.  Protocol Overview

  3.1.  Overview of the EAP-EDHOC Conversation

     The EAP exchange involves three key entities: the EAP peer, the EAP
     authenticator, and the EAP server.  The EAP authenticator is a
     network device that enforces access control and initiates the EAP
     authentication process.  The EAP peer is the device seeking network
     access and communicates directly with the EAP authenticator.  The EAP
     server is responsible for selecting and implementing the
     authentication methods and for authenticating the EAP peer.  When the
     EAP server is not located on a separate backend authentication
     server, it is integrated into the EAP authenticator.  For simplicity,
     the operational flow diagrams in this document depict only the EAP
     peer and the EAP server.

     The EDHOC protocol running between an Initiator and a Responder
     consists of three mandatory messages (message_1, message_2,
     message_3), an optional message_4, and an error message.  In an EDHOC
     session, EAP-EDHOC uses all messages including message_4, which is
     mandatory and acts as a protected success indication.

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

     The message processing in Section 5 of [RFC9528] states that certain
     data (EAD items, connection identifiers, application algorithms,
     etc.) is made available to the application.  Since EAP-EDHOC is now
     acting as the application of EDHOC, it may need to handle this data
     to complete the protocol execution.  See also
     [I-D.ietf-lake-edhoc-impl-cons].




  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 5]


  Internet-Draft                  EAP-EDHOC                   January 2026


     Resumption of EAP-EDHOC may be defined using the EDHOC-PSK
     authentication method [I-D.ietf-lake-edhoc-psk].

  3.1.1.  Successful EAP-EDHOC Message Flow without Fragmentation

     EDHOC allows EAP-EDHOC to support authentication credentials of any
     type defined by COSE, which can be either transported or referenced
     during the protocol.

     The optimization combining the execution of EDHOC with the first
     subsequent OSCORE transaction specified in [RFC9668] is not
     applicable to this EAP method.

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




































  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 6]


  Internet-Draft                  EAP-EDHOC                   January 2026


       EAP-EDHOC Peer                                   EAP-EDHOC Server

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

                        Figure 1: EAP-EDHOC Message Flow

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

     If the EAP-EDHOC server authenticates successfully, and the EAP-EDHOC
     peer achieves key confirmation by successfully verifying EDHOC
     message_4, then the EAP-EDHOC peer MUST send an EAP-Response message
     with EAP-Type=EAP-EDHOC containing no data.  Finally, the EAP-EDHOC
     server sends an EAP-Success.



  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 7]


  Internet-Draft                  EAP-EDHOC                   January 2026


     Note that the Identity request is optional [RFC3748] and might not be
     used in systems like 3GPP 5G [Sec5G] where the identity is
     transferred encrypted by other means before the EAP exchange.  While
     the EAP-Response/EAP-Type=EAP-EDHOC and EAP-Success are mandatory
     [RFC3748] they do not contain any information and might be encoded
     into other system specific messages [Sec5G].

  3.1.2.  Transport and Message Correlation

     EDHOC is not bound to a particular transport layer and can even be
     used in environments without IP.  Nonetheless, [RFC9528] provides a
     set of requirements for a transport protocol to use with EDHOC.
     These include: handling the loss, reordering, duplication,
     correlation, and fragmentation of messages; demultiplexing EDHOC
     messages from other types of messages; and denial-of-service
     protection.  All these requirements are fulfilled by the EAP
     protocol, EAP method, or EAP lower layer, as specified in [RFC3748].

     For message loss, this can be either fulfilled by the EAP layer, or
     the EAP lower layer, or both.

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

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

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

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

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

  3.1.3.  Termination

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

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




  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 8]


  Internet-Draft                  EAP-EDHOC                   January 2026


       EAP-EDHOC Peer                                   EAP-EDHOC Server

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

               Figure 2: EAP-EDHOC Server Rejection of message_1

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

















  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 9]


  Internet-Draft                  EAP-EDHOC                   January 2026


       EAP-EDHOC Peer                                   EAP-EDHOC Server

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

                Figure 3: EAP-EDHOC Peer Rejection of message_2

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

     Note that the EDHOC error message cannot be omitted.  For example,
     with EDHOC ERR_CODE 3 "Unknown credential referenced", it is
     indicated that the EDHOC peer should, for the next EDHOC session, try
     another credential identifier supported according to the application
     profile.









  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 10]


  Internet-Draft                  EAP-EDHOC                   January 2026


       EAP-EDHOC Peer                                   EAP-EDHOC Server

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

               Figure 4: EAP-EDHOC Server Rejection of message_3

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









  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 11]


  Internet-Draft                  EAP-EDHOC                   January 2026


       EAP-EDHOC Peer                                   EAP-EDHOC Server

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

                Figure 5: EAP-EDHOC Peer Rejection of message_4

  3.1.4.  Identity

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






  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 12]


  Internet-Draft                  EAP-EDHOC                   January 2026


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

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

  3.1.5.  Privacy

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

  3.1.6.  Fragmentation

     EDHOC is designed to perform well in constrained networks where
     message sizes are restricted for performance reasons.  When
     credentials are transferred by reference, EAP-EDHOC messages are
     typically so small that fragmentation is not needed.  However, as
     EAP-EDHOC also supports large X.509 certificate chains, EAP-EDHOC
     implementations MUST provide support for fragmentation and
     reassembly.  Some EAP implementations and access networks impose
     limits on the number of EAP packet exchanges that can be processed.
     To minimize fragmentation, it is RECOMMENDED to use compact EAP-EDHOC
     peer, EAP-EDHOC server, and trust anchor authentication credentials,
     as well as to limit the length of certificate chains.  Additionally,
     mechanisms that reduce the size of Certificate messages are
     RECOMMENDED.











  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 13]


  Internet-Draft                  EAP-EDHOC                   January 2026


     Since EAP is a lock-step protocol, fragmentation support can be
     easily added.  To do so, the EAP-Response and EAP-Request packets of
     EAP-EDHOC have a set of information fields that allow for the
     specification of the fragmentation process (see Section 4 for the
     detailed description).  As a summary, EAP-EDHOC fragmentation support
     is provided through the addition of flag bits (M and L) within the
     EAP-Response and EAP-Request packets, as well as a (conditional) EAP-
     EDHOC Message Length field that can be zero to four octets.

     The EDHOC Message Length field conveys the total length of the EDHOC
     message being fragmented, which facilitates buffer allocation.  The L
     flag consists of three bits that determine the length of the EDHOC
     Message Length field.  This L flag MUST be present in the first
     fragment of a fragmented EDHOC message, indicating the size of the
     EAP-EDHOC Message Length field and thereby signaling that the EDHOC
     message is fragmented.  Implementations MUST NOT set any of the L
     flag bits to 1 in unfragmented messages.  However, implementations
     MUST accept unfragmented messages regardless of the value of the L
     flag bits.

     The S flag bit SHALL be set only in the EAP-EDHOC Start message sent
     by the EAP server to the peer (and is also used in unfragmented
     exchanges).  The M flag bit SHALL be set in all fragments except the
     last one.

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

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

     Figure 6 illustrates the conversation beetween the endpoints in the
     case where the EAP-EDHOC mutual authentication is successful and
     fragmentation is required:



  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 14]


  Internet-Draft                  EAP-EDHOC                   January 2026


       EAP-EDHOC Peer                                   EAP-EDHOC Server

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



  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 15]


  Internet-Draft                  EAP-EDHOC                   January 2026


           | <---------------------------------------------------- |
           |                                                       |
           |   EAP-Response/EAP-Type=EAP-EDHOC                     |
           |   (EDHOC message_3, Fragment 3)                       |
           | ----------------------------------------------------> |
           |                                                       |
           |                      EAP-Request/EAP-Type=EAP-EDHOC   |
           |                                   (EDHOC message_4)   |
           | <---------------------------------------------------- |
           |                                                       |
           |   EAP-Response/EAP-Type=EAP-EDHOC                     |
           | ----------------------------------------------------> |
           |                                                       |
           |                                         EAP-Success   |
           | <---------------------------------------------------- |
           |                                                       |

                   Figure 6: EAP-EDHOC Fragmentation Example

  3.2.  Identity Verification

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

     The EAP server identity in the EDHOC server certificate is typically
     a fully qualified domain name (FQDN) in the SubjectAltName (SAN)
     extension.  Since EAP-EDHOC deployments may use more than one EAP
     server, each with a different certificate, EAP peer implementations
     SHOULD allow for the configuration of one or more trusted root
     certificates (CA certificate) to authenticate the server certificate
     and one or more server names to match against the SubjectAltName
     (SAN) extension in the server certificate.  If any of the configured
     names match any of the names in the SAN extension, then the name
     check passes.  To simplify name matching, an EAP-EDHOC deployment can
     assign a designated name to represent an authorized EAP server.  This
     name can then be included in the SANs list of each certificate used
     by this EAP-EDHOC server.  If server name matching is not used, the
     EAP peer has reduced assurance that the EAP server it is interacting
     with is authoritative for the given network.  If name matching is not
     used with a public root CA, then effectively any server can obtain a
     certificate that will be trusted for EAP authentication by the peer.





  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 16]


  Internet-Draft                  EAP-EDHOC                   January 2026


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

     As an alternative to standard certificate validation, EDHOC
     extensions such as the Lightweight Authorization mechanism defined in
     [I-D.ietf-lake-authz] can provide additional means of verifying
     server credentials.  Such mechanisms may be suitable in deployments
     where no prior trust relationship exists or where managing trusted
     root CAs is impractical.

  3.3.  Key Hierarchy

     The key derivation for EDHOC is described in Section 4 of [RFC9528].
     The key material and Method-Id SHALL be derived from the PRK_exporter
     using the EDHOC_Exporter interface, see Section 4.2.1 of [RFC9528].

     Type is the value of the EAP Type field defined in Section 2 of
     [RFC3748].  For EAP-EDHOC, Type has the value TBD1.  The << >>
     notation defined in Section G.3 of [RFC8610] means that the CBOR-
     encoded integer Type value is embedded in a CBOR byte string.  The
     use of Type as context enables the reuse of exporter labels across
     other future EAP methods based on EDHOC.

     Type        =  TBD1
     MSK         =  EDHOC_Exporter(TBD2, << Type >>, 64)
     EMSK        =  EDHOC_Exporter(TBD3, << Type >>, 64)
     Method-Id   =  EDHOC_Exporter(TBD4, << Type >>, 64)
     Session-Id  =  Type || Method-Id
     Peer-Id     =  ID_CRED_I
     Server-Id   =  ID_CRED_R

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




  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 17]


  Internet-Draft                  EAP-EDHOC                   January 2026


  3.4.  Parameter Negotiation and Compliance Requirements

     The EAP-EDHOC peers and EAP-EDHOC servers MUST comply with the
     requirements defined in Section 8 of [RFC9528], including mandatory-
     to-implement cipher suites, signature algorithms, key exchange
     algorithms, and extensions.

  3.5.  EAP State Machines

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

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

     The keying material can be derived by the Initiator upon receiving
     EDHOC message_2, and by the Responder upon receiving EDHOC message_3.
     Implementations following [RFC4137] can then set the eapKeyData and
     aaaEapKeyData variables.

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

  3.6.  EAP Channel Binding

     EAP-EDHOC allows the secure exchange of information between the
     endpoints of the authentication process (i.e., the EAP peer and the
     EAP server) using protected data fields.  These fields can be used to
     exchange EAP channel binding information, as defined in [RFC6677].

     Section 6 in [RFC6677] outlines requirements for components
     implementing channel binding information, all of which are satisfied
     by EAP-EDHOC, including confidentiality and integrity protection.
     Additionally, EAP-EDHOC supports fragmentation, allowing the
     inclusion of additional information at the method level without
     issues.











  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 18]


  Internet-Draft                  EAP-EDHOC                   January 2026


     While the EAD_1 and EAD_2 fields (carried in EDHOC message_1 and
     EDHOC message_2, respectively) are integrity protected through the
     transcript hash, the channel binding protocol defined in [RFC6677]
     must be transported after keying material has been derived between
     the endpoints in the EAP communication and before the peer is exposed
     to potential adverse effects from joining an adversarial network.
     Therefore, compliance with [RFC6677] requires use of the EAD_3 and
     EAD_4 fields, transmitted in EDHOC message_3 and EDHOC message_4,
     respectively.

     It is important to note that EAD fields in EDHOC are optional;
     consequently, the inclusion of EAP Channel Binding information in an
     authentication exchange is also optional.

     Accordingly, this document specifies a new EAD item, with ead_label =
     TBD5, to incorporate EAP channel binding information into the EAD
     fields of the EAP-EDHOC messages.  See the definition in Section 5.3.

        *Implementation Note:* This document defines only the container
        for carrying EAP Channel Binding information within EAP-EDHOC
        messages, using the EAD_3 and EAD_4 fields.  The format and
        semantics of the channel binding content are application-specific
        and are determined by the authentication domain in which the
        protocol is deployed.

     If the server detects a consistency error in the channel binding
     information contained in EAD_3, it MUST send an EDHOC error message,
     as specified in [RFC9528], since the new EAD item defined to carry
     EAP Channel Binding information is critical.  In this case, the
     exchange proceeds according to Figure 4.

     Similarly, if the Initiator detects an error in the channel binding
     information contained in EAD_4, it MUST send an EDHOC error message,
     and the exchange proceeds according to Figure 5.

  4.  Detailed Description of the EAP-EDHOC Request and Response Protocol

     The EAP-EDHOC packet format for Requests and Responses is summarized
     in Figure 7.  Fields are transmitted from left to right. following a
     structure inspired by the EAP-TLS packet format [RFC5216].  As
     specified in Section 4.1 of [RFC3748], EAP Request and Response
     packets consist of Code, Identifier, Length, Type, and Type-Data
     fields.  The functions of the Code, Identifier, Length, and Type
     fields are reiterated here for convenience.  The EAP Type-Data field
     consists of the R, S, M, L, EDHOC Message Length, and EDHOC Data
     fields.





  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 19]


  Internet-Draft                  EAP-EDHOC                   January 2026


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Code      |   Identifier  |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |  R  |S|M|  L  |      EDHOC Message Length     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          EDHOC Data                           ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 7: EAP-EDHOC Request and Response Packet Format

  4.1.  EAP-EDHOC Request Packet

     Code:  1 (Request)

     Identifier:  The Identifier field is one octet and aids in matching
        responses with requests.  The Identifier field MUST be changed on
        each new (non-retransmission) Request packet, and MUST be the same
        if a Request packet is retransmitted due to a timeout while
        waiting for a Response.  In the case of fragmented messages, the
        Identifier will follow the indications of Section 3.1.6.

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

     Type:  TBD1 (EAP-EDHOC)

     R:  Implementations of this specification MUST set the R bits
        (reserved) to zero and MUST ignore them on reception.

     S:  The S bit (EAP-EDHOC start) is set in an EAP-EDHOC Start message.
        This differentiates the EAP-EDHOC Start message from a fragment
        acknowledgement.

     M:  The M bit (more fragments) is set on all but the last fragment.
        I.e., when there is no fragmentation, it is set to zero.

     L:  The L flag bits represent the binary encoding of the size of the
        EDHOC Message Length, which can range from 0 to 4 bytes.  When all
        three bits are set to 0, the EDHOC Message Length field is not
        present.  If the first two bits of the L field are set to 0 and
        the last bit is set to 1, then the size of the EDHOC Message
        Length field is 1 byte, and so on.  Values from 5 to 7 are not
        used in this specification.



  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 20]


  Internet-Draft                  EAP-EDHOC                   January 2026


     EDHOC Message Length:  The EDHOC Message Length field, when present,
        has a size of one to four octets, as determined by the L flag
        bits.  It is included only if the L flag bits indicate a value
        greater than zero and specifies the total length of the EDHOC
        message being fragmented.  When fragmentation is not used, this
        field is omitted.

     EDHOC Data:  The EDHOC data consists of the whole or a fragment of
        the transported EDHOC message.

  4.2.  EAP-EDHOC Response Packet

     Code:  2 (Response)

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

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

     Type:  TBD1 (EAP-EDHOC)

     R:  Implementations of this specification MUST set the R bits
        (reserved) to zero and MUST ignore them on reception.

     S:  The S bit (EAP-EDHOC start) is set to zero.

     M:  The M bit (more fragments) is set on all but the last fragment.
        I.e., when there is no fragmentation, it is set to zero.

     L:  The L flag bits represent the binary encoding of the size of the
        EDHOC Message Length, which can range from 0 to 4 bytes.  When all
        three bits are set to 0, the EDHOC Message Length field is not
        present.  If the first two bits of the L field are set to 0 and
        the last bit is set to 1, then the size of the EDHOC Message
        Length field is 1 byte, and so on.  Values from 5 to 7 are not
        used in this specification.

     EDHOC Message Length:  The EDHOC Message Length field, when present,
        has a size of one to four octets, as determined by the L flag
        bits.  It is included only if the L flag bits indicate a value
        greater than zero and specifies the total length of the EDHOC
        message being fragmented.  When fragmentation is not used, this
        field is omitted.




  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 21]


  Internet-Draft                  EAP-EDHOC                   January 2026


     EDHOC Data:  The EDHOC data consists of the whole or a fragment of
        the transported EDHOC message.

  5.  IANA Considerations

  5.1.  EAP Type

     IANA has registered the following new type in the "Method Types"
     registry under the group name "Extensible Authentication Protocol
     (EAP) Registry":

     Value: TBD1
     Description: EAP-EDHOC

  5.2.  EDHOC Exporter Label Registry

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

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

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

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

     The allocations have been updated to reference this document.

  5.3.  EDHOC External Authorization Data Registry

     IANA has registered the following new label in the "EDHOC External
     Authorization Data" registry under the group name "Ephemeral Diffie-
     Hellman Over COSE (EDHOC)":

     Label: TBD5
     Description: EAP channel binding information

     This new EAD item is intended only for EAD_3 and EAD_4.  Then, it
     MUST be ignored if included in other EAD fields.  This new EAD item
     is considered as critical.  Multiple occurrences of this new EAD item
     in one EAD field are NOT allowed.







  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 22]


  Internet-Draft                  EAP-EDHOC                   January 2026


  6.  Security Considerations

     The security considerations of EAP [RFC3748] and EDHOC [RFC9528]
     apply to this document.  Since the design of EAP-EDHOC closely
     follows EAP-TLS 1.3 [RFC9190], many of its security considerations
     are also relevant.

  6.1.  Security Claims

  6.1.1.  EAP Security Claims

     EAP security claims are defined in Section 7.2.1 of [RFC3748].  EAP-
     EDHOC security claims are described next and summarized in Table 1.






































  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 23]


  Internet-Draft                  EAP-EDHOC                   January 2026


         +==================+=======================================+
         | Claim            |                                       |
         +==================+=======================================+
         | Auth. principle: | Certificates, CWTs, and all           |
         |                  | credential types for which COSE       |
         |                  | header parameters are defined (1)     |
         +------------------+---------------------------------------+
         | Cipher suite     | Yes (2)                               |
         | negotiation:     |                                       |
         +------------------+---------------------------------------+
         | Mutual           | Yes (3)                               |
         | authentication:  |                                       |
         +------------------+---------------------------------------+
         | Integrity        | Yes (4)                               |
         | protection:      |                                       |
         +------------------+---------------------------------------+
         | Replay           | Yes (5)                               |
         | protection:      |                                       |
         +------------------+---------------------------------------+
         | Confidentiality: | Yes (6)                               |
         +------------------+---------------------------------------+
         | Key derivation:  | Yes (7)                               |
         +------------------+---------------------------------------+
         | Key strength:    | The specified cipher suites provide   |
         |                  | key strength of at least 128 bits.    |
         +------------------+---------------------------------------+
         | Dictionary       | Yes (8)                               |
         | attack           |                                       |
         | protection:      |                                       |
         +------------------+---------------------------------------+
         | Fast reconnect:  | No                                    |
         +------------------+---------------------------------------+
         | Crypt. binding:  | N/A                                   |
         +------------------+---------------------------------------+
         | Session          | Yes (9)                               |
         | independence:    |                                       |
         +------------------+---------------------------------------+
         | Fragmentation:   | Yes (Section 3.1.6)                   |
         +------------------+---------------------------------------+
         | Channel binding: | Yes (Section 3.6: EAD_3 and EAD_4 can |
         |                  | be used to convey integrity-protected |
         |                  | channel properties, such as network   |
         |                  | SSID or peer MAC address.)            |
         +------------------+---------------------------------------+

                      Table 1: EAP-EDHOC security claims





  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 24]


  Internet-Draft                  EAP-EDHOC                   January 2026


     *  (1) Authentication principle: EAP-EDHOC establishes a shared
        secret based on an authenticated ECDH key exchange.  The key
        exchange is authenticated using different kinds of credentials.
        EAP-EDHOC supports EDHOC credential types.  EDHOC supports all
        credential types for which COSE header parameters are defined.
        These include X.509 certificates [RFC9360], C509 certificates,
        CWTs ([RFC9528] Section 3.5.3.1), and CCSs ([RFC8392]
        Section 7.1).

     *  (2) Cipher suite negotiation: The Initiator's list of supported
        cipher suites and order of preference is fixed, and the selected
        cipher suite is the cipher suite that is most preferred by the
        Initiator and that is supported by both the Initiator and the
        Responder.  EDHOC supports all signature algorithms defined by
        COSE.

     *  (3) Mutual authentication: The initiator and responder
        authenticate each other through the EDHOC exchange.

     *  (4) Integrity protection: EDHOC integrity protects all message
        content using transcript hashes for key derivation and as
        additional authenticated data, including, e.g., method type,
        cipher suites, and external authorization data.

     *  (5) Replay protection.  EDHOC broadens the message authentication
        coverage to include algorithms, external authorization data, and
        prior plaintext messages, as well as adding an explicit method
        type.  By doing this, an attacker cannot replay or inject messages
        from a different EDHOC session.

     *  (6) Confidentiality.  EDHOC message_2 provides confidentiality
        against passive attackers, while message_3 and message_4 provide
        confidentiality against active attackers.

     *  (7) Key derivation.  Except for MSK and EMSK, derived keys are not
        exported.  Key derivation is discussed in Section 3.3.

     *  (8) Dictionary attack protection.  EAP-EDHOC provides Dictionary
        attack protection.

     *  (9) Session independence.  EDHOC generates computationally
        independent keys derived from the ECDH shared secret.









  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 25]


  Internet-Draft                  EAP-EDHOC                   January 2026


  6.1.2.  Additional Security Claims

     *  (10) Cryptographic strength and Forward secrecy: Only ephemeral
        key exchange methods are supported by EDHOC, which ensures that
        the compromise of a session key does not also compromise earlier
        sessions' keys.

     *  (11) Identity protection: EDHOC secures the Responder's credential
        identifier against passive attacks and the Initiator's credential
        identifier against active attacks.  An active attacker can get the
        credential identifier of the Responder by eavesdropping on the
        destination address used for transporting message_1 and then
        sending their own message_1.

  6.2.  Peer and Server Identities

     The Peer-Id represents the identity to be used for access control and
     accounting purposes.  The Server-Id represents the identity of the
     EAP server.  The Peer-Id and Server-Id are determined from the
     information provided in the credentials used.

     ID_CRED_I and ID_CRED_R are used to identify the credentials of the
     Initiator (EAP peer) and Responder (EAP server).  Therefore, for
     Server-Id the ID_CRED_R is used, and for Peer-Id the ID_CRED_I is
     used.

  6.3.  Certificate Validation

     Same considerations as in EAP-TLS 1.3 Section 5.3 [RFC9190] apply
     here in relation to the use of certificates.

     When other types of credentials are used such as CWT/CCS, the
     application needs to have a clear trust-establishment mechanism and
     identify the pertinent trust anchors [RFC9528].

  6.4.  Certificate Revocation

     Same considerations as in EAP-TLS 1.3 Section 5.4 [RFC9190] apply
     here in relation to certificates.

     When other types of credentials are used such as CWT/CCS, the
     endpoints are in charge of handling revocation and confirming the
     validity and integrity of CWT/CCS [RFC9528].








  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 26]


  Internet-Draft                  EAP-EDHOC                   January 2026


  6.5.  Packet Modification Attacks

     EAP-EDHOC relies on EDHOC, which is designed to encrypt and integrity
     protect as much information as possible.  Any change in any message
     is detected by means of the transcript hashes integrity verification.

  6.6.  Authorization

     Following the considerations of EDHOC in appendix D.5 Unauthenticated
     Operation [RFC9528], EDHOC can be used without authentication by
     allowing the Initiator or Responder to communicate with any identity
     except its own.

     When peer authentication is not used, EAP-EDHOC server
     implementations MUST take care to limit network access appropriately
     for authenticated peers.  Authorization and accounting MUST be based
     on authenticated information such as information in the certificate.
     The requirements for Network Access Identifiers (NAIs) specified in
     Section 4 of [RFC7542] apply and MUST be followed.

  6.7.  Privacy Considerations

     Considerations in Section 9.6 of [RFC9528] against tracking of users
     and eavesdropping on Identity Responses or certificates apply here.
     Also, the considerations of Section 5.8 of [RFC9190] regarding
     anonymous NAIs also applies.

  6.8.  Pervasive Monitoring

     Considerations in Section 9.1 of [RFC9528] about pervasive monitoring
     apply here.

  6.9.  Cross-Protocol Attacks

     This applies in the context of TLS 1.3 resumption, while it does not
     apply here.

  7.  References

  7.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.






  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 27]


  Internet-Draft                  EAP-EDHOC                   January 2026


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

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

     [RFC6677]  Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-
                Binding Support for Extensible Authentication Protocol
                (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,
                <https://www.rfc-editor.org/rfc/rfc6677>.

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

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

     [RFC9190]  Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
                Extensible Authentication Protocol with TLS 1.3",
                RFC 9190, DOI 10.17487/RFC9190, February 2022,
                <https://www.rfc-editor.org/rfc/rfc9190>.

     [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










  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 28]


  Internet-Draft                  EAP-EDHOC                   January 2026


     [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-16, 25 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                cbor-encoded-cert-16>.

     [I-D.ietf-lake-app-profiles]
                Tiloca, M. and R. Höglund, "Coordinating the Use of
                Application Profiles for Ephemeral Diffie-Hellman Over
                COSE (EDHOC)", Work in Progress, Internet-Draft, draft-
                ietf-lake-app-profiles-03, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lake-
                app-profiles-03>.

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

     [I-D.ietf-lake-edhoc-impl-cons]
                Tiloca, M., "Implementation Considerations for Ephemeral
                Diffie-Hellman Over COSE (EDHOC)", Work in Progress,
                Internet-Draft, draft-ietf-lake-edhoc-impl-cons-05, 7
                January 2026, <https://datatracker.ietf.org/doc/html/
                draft-ietf-lake-edhoc-impl-cons-05>.

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

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

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.




  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 29]


  Internet-Draft                  EAP-EDHOC                   January 2026


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

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

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

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

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

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

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

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

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

     [Sec5G]    3GPP TS 33 501, "Security architecture and procedures for
                5G System", March 2025,
                <https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3169>.



  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 30]


  Internet-Draft                  EAP-EDHOC                   January 2026


  Acknowledgments

     The authors sincerely thank Eduardo Ingles-Sanchez for his
     contribution in the initial phase of this work.  We also want to
     thank Marco Tiloca, Christian Amsüss, Gabriel Lopez-Millan and Renzo
     Navas for their reviews.

     This work was supported partially by grant PID2020-112675RB-C44
     funded by MCIN/AEI/10.13039/5011000011033 (ONOFRE3-UMU).

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

  Authors' Addresses

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


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


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


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


     Francisco Lopez-Gomez
     University of Murcia
     Murcia 30100
     Spain
     Email: francisco.lopezg@um.es



  Garcia-Carrillo, et al.   Expires 3 August 2026                [Page 31]


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

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


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

  Abstract

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

  About This Document

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

     The latest revision of this draft can be found at https://netd-
     tud.github.io/draft-lenders-core-oscore-svcb/draft-lenders-core-
     dnr.html.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-lenders-core-dnr/.

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

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

  Status of This Memo

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



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


  Internet-Draft                  CoRE DNR                       July 2025


     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 8 January 2026.

  Copyright Notice

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

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

  Table of Contents

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



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


  Internet-Draft                  CoRE DNR                       July 2025


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

  1.  Introduction

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

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

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

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

     CoAP offers three ways of secure communication:

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

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




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


  Internet-Draft                  CoRE DNR                       July 2025


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

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

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

  2.  Terminology

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

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

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

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

  3.  Problem Space

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

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



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


  Internet-Draft                  CoRE DNR                       July 2025


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

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

  4.  Objectives

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

     *  DoC over OSCORE using EDHOC, and

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

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

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




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


  Internet-Draft                  CoRE DNR                       July 2025


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

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

  4.1.  Scenarios

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

  4.1.1.  Neighbor discovered server with EDHOC credential

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

     1.  Client: Joins a network.

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

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

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

  4.1.2.  DHCP discovered server with ACE details

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

     1.  Client: Requests an address using DHCP

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

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




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


  Internet-Draft                  CoRE DNR                       July 2025


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

     3.  Client requests token from AS:

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

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

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

  5.  Security Considerations

     TODO Security

  6.  IANA Considerations

     This document has no IANA considerations.

  7.  References

  7.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

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

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






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


  Internet-Draft                  CoRE DNR                       July 2025


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

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

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

  7.2.  Informative References

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

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

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

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



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


  Internet-Draft                  CoRE DNR                       July 2025


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

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

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

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

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

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

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

     [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
                Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
                Application Protocol) over TCP, TLS, and WebSockets",
                RFC 8323, DOI 10.17487/RFC8323, February 2018,
                <https://www.rfc-editor.org/rfc/rfc8323>.

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






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


  Internet-Draft                  CoRE DNR                       July 2025


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

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

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

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

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

  Appendix A.  Change Log

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

     *  Nits

     *  Moving GitHub repo to netd-tud org

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

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

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

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

     *  intro: overhaul explanation of OSCORE setup




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


  Internet-Draft                  CoRE DNR                       July 2025


     *  objectives: Be open on ACE profiles

     *  Add scenarios

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

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

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

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

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

     *  Remove solution sketches, set objectives to solve problem space

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

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

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

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


     Christian Amsüss
     Email: christian@amsuess.com


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





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


  Internet-Draft                  CoRE DNR                       July 2025


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













































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


name: draft-ra-emu-pqc-eapaka
rev: 05
title: Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime
time: 2025-07-10T01:04:15Z
group_uri: /api/v1/group/group/1674/
expires: 2025-11-30T05:23:01Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081905+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 November 2025                                    29 May 2025


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

  Abstract

     Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     making it quantum-safe using Post-Quantum Key Encapsulation
     Mechanisms (PQ-KEMs).

  About This Document

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

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ra-emu-pqc-eapaka/.

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

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.



  Reddy & Banerjee        Expires 30 November 2025                [Page 1]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 30 November 2025.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Background on EAP-AKA' with perfect forward secrecy . . . . .   4
       4.1.  Key Encapsulation Mechanisms  . . . . . . . . . . . . . .   5
     5.  Design Rationales . . . . . . . . . . . . . . . . . . . . . .   5
     6.  PQC KEM Enhancements by Design  . . . . . . . . . . . . . . .   6
     7.  Protocol Construction . . . . . . . . . . . . . . . . . . . .   6
       7.1.  Protocol Call Flow  . . . . . . . . . . . . . . . . . . .   6
       7.2.  Key Steps in protocol construction  . . . . . . . . . . .   8
     8.  Extensions to EAP-AKA' FS . . . . . . . . . . . . . . . . . .   9
       8.1.  AT_PUB_KEM  . . . . . . . . . . . . . . . . . . . . . . .   9
       8.2.  AT_KEM_CT . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.  ML-KEM  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
       10.1.  Selecting ML-KEM Variants  . . . . . . . . . . . . . . .  12
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
       12.2.  Informative References . . . . . . . . . . . . . . . . .  13
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  15
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15






  Reddy & Banerjee        Expires 30 November 2025                [Page 2]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


  1.  Introduction

     Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) defined in [RFC9678]
     updates the improved Extensible Authentication Protocol Method for
     3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
     specified in [RFC9048], with an optional extension providing
     ephemeral key exchange.  This prevents an attacker who has gained
     access to the long term key from obtaining session keys established
     in the past, assuming these have been properly deleted.  EAP-AKA' FS
     mitigates passive attacks (e.g., large scale pervasive monitoring)
     against future sessions.

     Nevertheless, EAP-AKA' FS uses traditional algorithms public-key
     algorithms (e.g., ECDH) which will be broken by a Cryptographically
     Relevant Quantum Computer (CRQC) using Shor's algorithm.  The
     presence of a CRQC would render state-of-the-art, traditional public-
     key algorithms deployed today obsolete and insecure, since the
     assumptions about the intractability of the mathematical problems for
     these algorithms that offer confident levels of security today no
     longer apply in the presence of a CRQC.  A CRQC could recover the
     SHARED_SECRET from the ECDHE public keys (Section 6.3 of [RFC9678]).
     If the adversary has also obtained knowledge of the long-term key, it
     could then compute CK', IK', and the SHARED_SECRET, and any derived
     output keys.  This means that the CRQC would disable the forward
     security capability provided by [RFC9678].

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

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

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





  Reddy & Banerjee        Expires 30 November 2025                [Page 3]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


  2.  Conventions and Definitions

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

  3.  Terminology

     This document makes use of the terms defined in
     [I-D.ietf-pquip-pqt-hybrid-terminology].  The following terms are
     repeately used in this specification:

     *  KEM: Key Encapsulation Mechanism

     *  PQ-KEM: Post-Quantum Key Encapsulation Mechanism

     *  CEK: Content Encryption Key

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

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

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

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

  4.  Background on EAP-AKA' with perfect forward secrecy

     In EAP-AKA', The authentication vector (AV) contains a random part
     RAND, an authenticator part AUTN used for authenticating the network
     to the USIM, an expected result part XRES, a 128-bit session key for
     integrity check IK, and a 128-bit session key for encryption CK.

     As described in the draft [RFC9678], the server has the EAP identity
     of the peer.  The server asks the AD to run AKA algorithm to generate
     RAND, AUTN, XRES, CK and IK.  Further it also derives CK’ and IK’
     keys which are tied to a particular network name.  The server now
     generates the ephemeral key pair and sends the public key of that key



  Reddy & Banerjee        Expires 30 November 2025                [Page 4]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


     pair and the first EAP method message to the peer.  In this EAP
     message, AT_PUB_ECDHE (carries public key) and the AT_KDF_FS(carries
     other FS related parameters).  Both of these might be ignored if USIM
     doesn’t support the Forward Secrecy extension.  The peer checks if it
     wants to have a Forward extension in EAP AKA'.  If yes, then it will
     eventually respond with AT_PUB_ECDHE and MAC.  If not, it will ignore
     AT_PUB_ECDHE.  If the peer wants to participate in FS extension, it
     will then generate its ECDH key pair, calculate a shared key based on
     its private key and server public key.  The server will receive the
     RES from peer and AT_PUB_ECDHE.  The shared key will be generated
     both in the peer and the server with key pairs exchanged, and later
     master key is also generated.

     MK_ECDHE = PRF'(IK'| CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)

  4.1.  Key Encapsulation Mechanisms

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

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

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

     *  def kemDecaps(ct, sk) -> ss

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

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

  5.  Design Rationales

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

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



  Reddy & Banerjee        Expires 30 November 2025                [Page 5]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


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

  6.  PQC KEM Enhancements by Design

     We suggest the following changes and enhancements:

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

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

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

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

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

  7.  Protocol Construction

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

  7.1.  Protocol Call Flow

      USIM           Peer                        Server              AD
       |              |                            |                |
       |              |           EAP-Req/Identity |                |
       |              |<---------------------------+                |
       |              |                            |                |
       |              | EAP-Resp/Identity          |                |
       |              | (Privacy-Friendly)         |                |
       |              +--------------------------->|                |
       |      +-------+----------------------------+----------------+--+
       |      | Server now has an identity for the peer. The server    |
       |      | then asks the help of AD to run AKA algorithms,        |
       |      | generating RAND, AUTN, XRES, CK, IK. Typically, the    |
       |      | AD performs the first part of key derivations so that  |
       |      | the authentication server gets the CK' and IK' keys    |
       |      | already tied to a particular network name.             |
       |      +-------+----------------------------+----------------+--+



  Reddy & Banerjee        Expires 30 November 2025                [Page 6]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


       |              |                            |                |
       |              |                            | ID, key deriv. |
       |              |                            | function,      |
       |              |                            | network name   |
       |              |                            +--------------->|
       |              |                            |                |
       |              |                            |    RAND, AUTN, |
       |              |                            | XRES, CK', IK' |
       |              |                            |<---------------+
       |      +-------+----------------------------+----------------+--+
       |      | Server now has the needed authentication vector. It    |
       |      | generates an a PQC KEM key pair, sends the public key  |
       |      | of that key pair and the first EAP method message      |
       |      | to the peer. In the message the AT_PUB_KEM attribute   |
       |      | carries the PQC KEM public key and the AT_KDF_FS       |
       |      | attribute carries PQC KEM algorithm. Both of           |
       |      | these are skippable attributes that can be ignored     |
       |      | if the peer does not support this extension.           |
       |      +-------+----------------------------+----------------+--+
       |              |                            |                |
       |              |     EAP-Req/AKA'-Challenge |                |
       |              |  AT_RAND, AT_AUTN, AT_KDF, |                |
       |              |   AT_KDF_FS, AT_KDF_INPUT, |                |
       |              |      AT_PUB_KEM, AT_MAC    |                |
       |              |<---------------------------+                |
     +--+--------------+----------------------------+---------+     |
     | The peer checks if it wants to do the FS extension. If |     |
     | yes, it will eventually respond with AT_KEM_CT and     |     |
     | AT_MAC. If not, it will ignore AT_PUB_KEM and          |     |
     | AT_KDF_FS and base all calculations on basic EAP-AKA'  |     |
     | attributes, continuing just as in EAP-AKA' per RFC     |     |
     | 9048 rules. In any case, the peer needs to query the   |     |
     | auth parameters from the USIM card.                    |     |
     +--+--------------+----------------------------+---------+     |
       |              |                            |                |
       |   RAND, AUTN |                            |                |
       |<-------------+                            |                |
       |              |                            |                |
       | CK, IK, RES  |                            |                |
       +------------->|                            |                |
     +--+--------------+----------------------------+---------+     |
     | The peer now has everything to respond. If it wants to |     |
     | participate in the FS extension, it will calculate a   |     |
     | PQC KEM shared secret key based on the server's PQC    |     |
     | KEM public key. Finally, it proceeds to derive all     |     |
     | EAP-AKA' key values and  constructs a full response.   |     |
     +--+--------------+----------------------------+---------+     |
       |              |                            |                |



  Reddy & Banerjee        Expires 30 November 2025                [Page 7]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


       |              | EAP-Resp/AKA'-Challenge    |                |
       |              | AT_RES, AT_KEM_CT,         |                |
       |              | AT_MAC                     |                |
       |              +--------------------------->|                |
       |      +-------+----------------------------+----------------+--+
       |      | The server now has all the necessary values. It        |
       |      | generates the PQC KEM shared secret and checks the RES |
       |      | and MAC values received in AT_RES and AT_MAC,          |
       |      | respectively. Success requires both to be found        |
       |      | correct. Note that when this document is used,         |
       |      | the keys generated from EAP-AKA' are based on CK, IK,  |
       |      | and PQC KEM shared secret value. Even if there was an  |
       |      | attacker who held the long-term key, only an active    |
       |      | attacker could have determined the generated session   |
       |      | keys; additionally an attacker with a cryptographically|
       |      | relevant quantum computer cannot get access to the     |
       |      | server KEM private key and decrypt the data.           |
       |      +-------+----------------------------+----------------+--+
       |              |                            |                |
       |              |                EAP-Success |                |
       |              |<---------------------------+                |
       |              |                            |                |

  7.2.  Key Steps in protocol construction

     We outline the following key steps in the protocol:

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

        sk, pk = kemKeyGen()

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

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

        ct, ss = kemEncaps(pk)

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

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



  Reddy & Banerjee        Expires 30 November 2025                [Page 8]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


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

        ss = kemDecaps(ct, sk)

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

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

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

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

  8.  Extensions to EAP-AKA' FS

  8.1.  AT_PUB_KEM

     The format of the AT_PUB_KEM attribute is shown below.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | AT_PUB_KEM    |   Reserved    |         Length (in bytes)     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         |                       Value (variable)                        |
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The fields are as follows:

     AT_PUB_KEM:



  Reddy & Banerjee        Expires 30 November 2025                [Page 9]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


     This is set to TBA1 BY IANA.

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

     Length:

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

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

     Value:

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

     Because the length of the attribute must be a multiple of 4 bytes,the
     sender pads the Value field with zero bytes when necessary.  To
     retain the security of the keys, the sender SHALL generate a fresh
     value for each run of the protocol.

  8.2.  AT_KEM_CT

     The format of the AT_KEM_CT attribute is shown below.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | AT_KEM_CT     |   Reserved    |         Length (in bytes)     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         |                   Value (variable)                            |
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The fields are as follows:

     AT_KEM_CT:




  Reddy & Banerjee        Expires 30 November 2025               [Page 10]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


     This is set to TBA2 BY IANA.

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

     Length:

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

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

     Value:

    *  EAP-Response: It contains the ciphertext (ct) from the PQC KEM Encapsulation function from the EAP peer.

     Because the length of the attribute must be a multiple of 4 bytes,
     the sender pads the Value field with zero bytes when necessary.  To
     retain the security of the keys, the sender SHALL generate a fresh
     value for each run of the protocol.

  9.  ML-KEM

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

  10.  Security Considerations

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






  Reddy & Banerjee        Expires 30 November 2025               [Page 11]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


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

  10.1.  Selecting ML-KEM Variants

     ML-KEM is believed to be IND-CCA2 secure based on multiple analyses.
     The ML-KEM variant and its underlying components should be selected
     consistently with the desired security level.  For further clarity on
     the sizes and security levels of ML-KEM variants, please refer to the
     tables in Sections 12 and 13 of [I-D.ietf-pquip-pqc-engineers].

  11.  IANA Considerations

     Two new values (TBA1, TBA2) in the skippable range need to be
     assigned by IANA for AT_PUB_KEM (Section 8.1) and AT_KEM_CT
     (Section 8.2) in the "Attribute Types" registry under the "EAP-AKA
     and EAP-SIM Parameters" group.

     IANA is requested to update the registry "EAP-AKA' AT_KDF_FS Key
     Derivation Function Values" with the PQC KEM algorithm entries:

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

  12.  References

  12.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
                Protocol Method for 3rd Generation Authentication and Key
                Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
                January 2006, <https://www.rfc-editor.org/rfc/rfc4187>.




  Reddy & Banerjee        Expires 30 November 2025               [Page 12]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


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

     [RFC9048]  Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
                "Improved Extensible Authentication Protocol Method for
                3GPP Mobile Network Authentication and Key Agreement (EAP-
                AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
                <https://www.rfc-editor.org/rfc/rfc9048>.

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

  12.2.  Informative References

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

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

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

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

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










  Reddy & Banerjee        Expires 30 November 2025               [Page 13]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


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

     [I-D.ietf-pquip-pqc-engineers]
                Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
                T., and M. Ounsworth, "Post-Quantum Cryptography for
                Engineers", Work in Progress, Internet-Draft, draft-ietf-
                pquip-pqc-engineers-12, 19 May 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
                pqc-engineers-12>.

     [I-D.ietf-pquip-pqt-hybrid-terminology]
                D, F., P, M., and B. Hale, "Terminology for Post-Quantum
                Traditional Hybrid Schemes", Work in Progress, Internet-
                Draft, draft-ietf-pquip-pqt-hybrid-terminology-06, 10
                January 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-pquip-pqt-hybrid-terminology-06>.

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

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

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

     [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
                "Randomness Requirements for Security", BCP 106, RFC 4086,
                DOI 10.17487/RFC4086, June 2005,
                <https://www.rfc-editor.org/rfc/rfc4086>.







  Reddy & Banerjee        Expires 30 November 2025               [Page 14]


  Internet-Draft          PQ KEMs in EAP-AKA prime                May 2025


  Appendix A.  Acknowledgements

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

  Authors' Addresses

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


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
































  Reddy & Banerjee        Expires 30 November 2025               [Page 15]


