# drafts

name: draft-willman-rtgwg-conduit-tunnels
rev: 01
title: Underlay for IPsec Transport
time: 2026-02-20T04:16:31Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-24T04:16:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:07.990783+00:00
abstract:
This document specifies CONDUIT, a tunnel fabric management protocol
   for tactical and enterprise networks operating over heterogeneous
   Wide Area Network (WAN) links.  CONDUIT automates the lifecycle
   management of IPsec tunnels, monitors tunnel health through active
   probing, and publishes quality metrics to enable Segment Routing over
   IPv6 (SRv6) based traffic engineering.

   CONDUIT follows a strict separation of concerns: it manages the
   underlay tunnel fabric while delegating all traffic engineering
   decisions to SRv6.  This architecture simplifies network operations,
   enables rapid adaptation to changing WAN conditions, and leverages
   standard SRv6 capabilities including Flexible Algorithm (Flex-Algo)
   and Topology-Independent Loop-Free Alternate (TI-LFA).

   The protocol is fully programmable via gRPC and mandates compliance
   with Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)
   cryptographic requirements.

full_text:
Routing Area Working Group                                    J. E. W. V
Internet-Draft                               Department of the Air Force
Updates: draft-conduit-tunnel-fabric (if                19 February 2026
         approved)                                                      
Intended status: Standards Track                                        
Expires: 23 August 2026


                      Underlay for IPsec Transport
                 draft-willman-rtgwg-conduit-tunnels-01

Abstract

   This document specifies CONDUIT, a tunnel fabric management protocol
   for tactical and enterprise networks operating over heterogeneous
   Wide Area Network (WAN) links.  CONDUIT automates the lifecycle
   management of IPsec tunnels, monitors tunnel health through active
   probing, and publishes quality metrics to enable Segment Routing over
   IPv6 (SRv6) based traffic engineering.

   CONDUIT follows a strict separation of concerns: it manages the
   underlay tunnel fabric while delegating all traffic engineering
   decisions to SRv6.  This architecture simplifies network operations,
   enables rapid adaptation to changing WAN conditions, and leverages
   standard SRv6 capabilities including Flexible Algorithm (Flex-Algo)
   and Topology-Independent Loop-Free Alternate (TI-LFA).

   The protocol is fully programmable via gRPC and mandates compliance
   with Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)
   cryptographic requirements.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 23 August 2026.




V                        Expires 23 August 2026                 [Page 1]

Internet-Draft        Underlay for IPsec Transport         February 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.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Design Philosophy . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   5
     1.4.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   6
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  System Overview . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Tunnel Fabric Concept . . . . . . . . . . . . . . . . . .   8
     3.3.  Separation of Concerns  . . . . . . . . . . . . . . . . .   9
   4.  Cryptographic Requirements  . . . . . . . . . . . . . . . . .  10
     4.1.  CNSA 2.0 Compliance . . . . . . . . . . . . . . . . . . .  10
     4.2.  Mandatory Algorithms  . . . . . . . . . . . . . . . . . .  10
     4.3.  Prohibited Algorithms . . . . . . . . . . . . . . . . . .  11
     4.4.  IPsec Profile . . . . . . . . . . . . . . . . . . . . . .  12
     4.5.  Certificate Requirements  . . . . . . . . . . . . . . . .  12
     4.6.  TLS Requirements  . . . . . . . . . . . . . . . . . . . .  13
   5.  Tunnel Fabric Management  . . . . . . . . . . . . . . . . . .  13
     5.1.  Tunnel Lifecycle States . . . . . . . . . . . . . . . . .  13
     5.2.  Tunnel Establishment Policy . . . . . . . . . . . . . . .  14
     5.3.  Tunnel Naming Convention  . . . . . . . . . . . . . . . .  15
     5.4.  Full Mesh Fabric  . . . . . . . . . . . . . . . . . . . .  15
   6.  Health Monitoring . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Probe Mechanism . . . . . . . . . . . . . . . . . . . . .  16
     6.2.  Probe Packet Format . . . . . . . . . . . . . . . . . . .  16
     6.3.  Metrics Calculation . . . . . . . . . . . . . . . . . . .  18
       6.3.1.  Round-Trip Time . . . . . . . . . . . . . . . . . . .  18
       6.3.2.  Jitter  . . . . . . . . . . . . . . . . . . . . . . .  19
       6.3.3.  Packet Loss . . . . . . . . . . . . . . . . . . . . .  19



V                        Expires 23 August 2026                 [Page 2]

Internet-Draft        Underlay for IPsec Transport         February 2026


     6.4.  Probe Scheduling  . . . . . . . . . . . . . . . . . . . .  19
     6.5.  Tunnel State Determination  . . . . . . . . . . . . . . .  20
   7.  Metric Publishing . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Publishing Methods  . . . . . . . . . . . . . . . . . . .  20
     7.2.  Interface Metric Calculation  . . . . . . . . . . . . . .  21
     7.3.  IGP TE Extensions . . . . . . . . . . . . . . . . . . . .  21
     7.4.  Flex-Algo Integration . . . . . . . . . . . . . . . . . .  22
     7.5.  SRLG Assignment . . . . . . . . . . . . . . . . . . . . .  23
   8.  Control Protocol  . . . . . . . . . . . . . . . . . . . . . .  23
     8.1.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  23
     8.2.  Message Header  . . . . . . . . . . . . . . . . . . . . .  24
     8.3.  Message Types . . . . . . . . . . . . . . . . . . . . . .  25
     8.4.  HELLO Message . . . . . . . . . . . . . . . . . . . . . .  25
     8.5.  WAN Descriptor  . . . . . . . . . . . . . . . . . . . . .  26
     8.6.  Message Authentication  . . . . . . . . . . . . . . . . .  28
     8.7.  Anti-Replay Protection  . . . . . . . . . . . . . . . . .  29
   9.  SRv6 Integration  . . . . . . . . . . . . . . . . . . . . . .  29
     9.1.  Tunnel Interfaces as SRv6 Adjacencies . . . . . . . . . .  29
     9.2.  Flex-Algo Tunnel Assignment . . . . . . . . . . . . . . .  30
     9.3.  Traffic Steering  . . . . . . . . . . . . . . . . . . . .  31
   10. High Availability . . . . . . . . . . . . . . . . . . . . . .  31
     10.1.  HA Architecture  . . . . . . . . . . . . . . . . . . . .  31
     10.2.  Synchronized State . . . . . . . . . . . . . . . . . . .  32
     10.3.  Failover Behavior  . . . . . . . . . . . . . . . . . . .  32
   11. gRPC API  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
     11.1.  Service Overview . . . . . . . . . . . . . . . . . . . .  33
     11.2.  Authentication and Authorization . . . . . . . . . . . .  33
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  33
     12.1.  Cryptographic Security . . . . . . . . . . . . . . . . .  33
     12.2.  Threat Mitigations . . . . . . . . . . . . . . . . . . .  34
     12.3.  Operational Security . . . . . . . . . . . . . . . . . .  34
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
     13.1.  UDP Port Allocation  . . . . . . . . . . . . . . . . . .  35
     13.2.  WAN Type Registry  . . . . . . . . . . . . . . . . . . .  35
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     14.2.  Informative References . . . . . . . . . . . . . . . . .  36
   Appendix A.  WAN Type Characteristics . . . . . . . . . . . . . .  37
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  37
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

1.1.  Problem Statement

   Modern tactical and enterprise networks increasingly operate over
   diverse Wide Area Network (WAN) links with varying characteristics:




V                        Expires 23 August 2026                 [Page 3]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Satellite Communications (SATCOM): Both Geostationary (GEO) with
      approximately 600ms round-trip latency and Low Earth Orbit (LEO)
      with 20-40ms latency, limited bandwidth, and weather sensitivity.

   *  Line-of-Sight (LOS) Radio: Low latency, high mobility, but
      terrain-dependent coverage.

   *  Cellular Networks (LTE/5G): Variable quality, broad coverage, but
      may traverse untrusted infrastructure.

   *  High Frequency (HF) Radio: Very low bandwidth but extended range
      with atmospheric effects.

   *  Wired Connections: When available at fixed installations.

   Managing IPsec tunnels across these heterogeneous links presents
   significant operational challenges:

   1.  Links appear and disappear as network elements move or
       environmental conditions change.

   2.  Link quality varies dramatically and unpredictably.

   3.  Multiple paths to each destination may exist simultaneously.

   4.  Failover must complete within sub-second timeframes to maintain
       voice and command-and-control (C2) applications.

   5.  All traffic must be encrypted using approved cryptographic
       algorithms.

   Existing approaches typically couple tunnel management with traffic
   engineering decisions, creating unnecessary complexity and limiting
   interoperability with standard routing protocols.

1.2.  Design Philosophy

   CONDUIT adheres to a strict separation of concerns:

   *  SRv6 Traffic Engineering Layer: Responsible for all path selection
      decisions, including Flexible Algorithm computation, fast reroute
      via TI-LFA, traffic class steering, and load balancing across
      equal-cost paths.

   *  CONDUIT Tunnel Fabric Layer: Responsible for tunnel lifecycle
      management (creation, maintenance, deletion), health monitoring
      through active probing, metric publication to enable SRv6-based
      decisions, and IPsec security association management.



V                        Expires 23 August 2026                 [Page 4]

Internet-Draft        Underlay for IPsec Transport         February 2026


   This separation ensures that CONDUIT does not duplicate functionality
   available in standard SRv6 implementations while providing essential
   tunnel management capabilities that SRv6 requires but does not
   natively provide.

1.3.  Design Goals

   The following quantitative goals guide CONDUIT's design:

    +=====================+===========================================+
    | Parameter           | Requirement                               |
    +=====================+===========================================+
    | Tunnel Scale        | Support for 1000+ tunnels per node        |
    +---------------------+-------------------------------------------+
    | Failover Detection  | Less than 500ms to detect tunnel failure  |
    +---------------------+-------------------------------------------+
    | Metric Publish Rate | 1 Hz default, 10 Hz burst capability      |
    +---------------------+-------------------------------------------+
    | Cryptographic Suite | Full CNSA 2.0 compliance                  |
    +---------------------+-------------------------------------------+
    | API Coverage        | 100% of functionality accessible via gRPC |
    +---------------------+-------------------------------------------+
    | Probe Overhead      | Less than 1% of available bandwidth       |
    +---------------------+-------------------------------------------+

                                  Table 1

1.4.  Scope

   This document specifies:

   *  Tunnel lifecycle management procedures

   *  Health monitoring through active probing

   *  Metric calculation and publishing mechanisms

   *  Control protocol message formats

   *  Integration requirements for SRv6-based traffic engineering

   *  Cryptographic requirements for CNSA 2.0 compliance

   This document does not specify:

   *  SRv6 data plane operations (covered by [RFC8986])





V                        Expires 23 August 2026                 [Page 5]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Flexible Algorithm computation (covered by draft-ietf-lsr-flex-
      algo)

   *  IPsec key exchange procedures (covered by [RFC7296])

   *  IGP extensions for traffic engineering (covered by [RFC8570])

2.  Conventions and Terminology

2.1.  Requirements Language

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

2.2.  Definitions

   Node:  A device implementing the CONDUIT protocol.


   Peer:  A remote node with which tunnels are established.


   WAN:  A Wide Area Network interface, either physical or virtual,

    capable of carrying IP traffic to remote peers.

   Tunnel:  An IPsec-protected communication path between two WAN

    interfaces on different nodes.

   Fabric:  The complete set of tunnels managed by a CONDUIT node.


   Probe:  A measurement packet transmitted through a tunnel to assess

    its quality characteristics.

   Metric:  A quantitative measure of tunnel quality, such as latency,

    jitter, or packet loss.

   Locator:  The SRv6 locator block assigned to a node, typically a /48

    IPv6 prefix.




V                        Expires 23 August 2026                 [Page 6]

Internet-Draft        Underlay for IPsec Transport         February 2026


2.3.  Abbreviations

   CNSA:  Commercial National Security Algorithm Suite


   ECMP:  Equal-Cost Multi-Path


   ESP:  Encapsulating Security Payload


   Flex-Algo:  Flexible Algorithm


   GEO:  Geostationary Earth Orbit


   gRPC:  gRPC Remote Procedure Call


   HMAC:  Hash-based Message Authentication Code


   IGP:  Interior Gateway Protocol


   IKE:  Internet Key Exchange


   LEO:  Low Earth Orbit


   LOS:  Line-of-Sight


   mTLS:  Mutual Transport Layer Security


   RTT:  Round-Trip Time


   SA:  Security Association


   SPI:  Security Parameter Index


   SRLG:  Shared Risk Link Group



V                        Expires 23 August 2026                 [Page 7]

Internet-Draft        Underlay for IPsec Transport         February 2026


   SRv6:  Segment Routing over IPv6


   TE:  Traffic Engineering


   TI-LFA: Topology-Independent Loop-Free Alternate

3.  Architecture

3.1.  System Overview

   A CONDUIT deployment consists of the following components:

   *  SDN Controller (Optional): Provides centralized policy management,
      SRv6 policy configuration, and network-wide optimization.
      Communicates with CONDUIT nodes via gRPC.

   *  SRv6 Data Plane: Executes traffic engineering decisions using
      standard SRv6 mechanisms including IS-IS or OSPFv3 with SRv6
      extensions, Flexible Algorithm for constraint-based path
      computation, and TI-LFA for sub-50ms fast reroute.

   *  CONDUIT Daemon: Manages the tunnel fabric, comprising the Tunnel
      Lifecycle Manager for creating and deleting tunnels, Health
      Monitor for probing tunnel quality, Metric Publisher for feeding
      metrics to SRv6/IGP, and the gRPC API Server for external control.

   *  IKEv2/IPsec Subsystem: Handles cryptographic operations and
      security association management.  CONDUIT interfaces with this
      subsystem but does not implement cryptographic operations
      directly.

   *  WAN Interfaces: Physical or virtual interfaces connecting to
      various transport networks.

3.2.  Tunnel Fabric Concept

   CONDUIT creates tunnels between WAN interfaces according to the
   configured tunnel policy.  In a full mesh configuration with N local
   WANs and M remote WANs to a given peer, CONDUIT establishes up to N x
   M tunnels.

   For example, consider a node with three WAN interfaces (SATCOM, LOS
   Radio, and LTE) connecting to a peer also having three WAN
   interfaces.  A full mesh fabric would comprise nine tunnels:

   *  SATCOM to SATCOM



V                        Expires 23 August 2026                 [Page 8]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  SATCOM to LOS

   *  SATCOM to LTE

   *  LOS to SATCOM

   *  LOS to LOS

   *  LOS to LTE

   *  LTE to SATCOM

   *  LTE to LOS

   *  LTE to LTE

   Each tunnel becomes a distinct interface visible to the SRv6 data
   plane and IGP.  The IGP sees multiple adjacencies to the same peer,
   each with potentially different metrics based on tunnel quality.

3.3.  Separation of Concerns

   CONDUIT explicitly delegates the following functions to SRv6:

     +========================+======================================+
     | Function               | Mechanism                            |
     +========================+======================================+
     | Path Selection         | SRv6 Flex-Algo, IGP SPF computation  |
     +------------------------+--------------------------------------+
     | Traffic Classification | SRv6 Policy color matching           |
     +------------------------+--------------------------------------+
     | Load Balancing         | IGP ECMP across equal-metric tunnels |
     +------------------------+--------------------------------------+
     | Fast Reroute           | TI-LFA pre-computed backup paths     |
     +------------------------+--------------------------------------+
     | QoS Marking            | SRv6 Traffic Class field             |
     +------------------------+--------------------------------------+

                                  Table 2

   CONDUIT is responsible for:










V                        Expires 23 August 2026                 [Page 9]

Internet-Draft        Underlay for IPsec Transport         February 2026


     +=====================+========================================+
     | Function            | Mechanism                              |
     +=====================+========================================+
     | Tunnel Creation     | Automatic based on WAN availability    |
     +---------------------+----------------------------------------+
     | Tunnel Deletion     | Automatic when WAN becomes unavailable |
     +---------------------+----------------------------------------+
     | Health Monitoring   | Active probing with configurable rates |
     +---------------------+----------------------------------------+
     | Metric Calculation  | RTT, jitter, loss measurement          |
     +---------------------+----------------------------------------+
     | Metric Publishing   | Interface metrics, IGP TE extensions   |
     +---------------------+----------------------------------------+
     | IPsec SA Management | Via IKEv2 with CNSA 2.0 parameters     |
     +---------------------+----------------------------------------+

                                 Table 3

4.  Cryptographic Requirements

4.1.  CNSA 2.0 Compliance

   CONDUIT implementations MUST comply with the Commercial National
   Security Algorithm Suite 2.0 (CNSA 2.0) as specified by the National
   Security Agency for protection of classified information.

   Implementations intended for use in environments not requiring CNSA
   2.0 compliance MAY support additional algorithms but MUST default to
   CNSA 2.0 algorithms and MUST provide configuration options to enforce
   CNSA 2.0-only operation.

4.2.  Mandatory Algorithms

   The following algorithms are REQUIRED:

















V                        Expires 23 August 2026                [Page 10]

Internet-Draft        Underlay for IPsec Transport         February 2026


   +======================+==============+============================+
   | Function             | Algorithm    | Parameters                 |
   +======================+==============+============================+
   | Symmetric Encryption | AES-256-GCM  | 256-bit key, 96-bit IV,    |
   |                      |              | 128-bit authentication tag |
   +----------------------+--------------+----------------------------+
   | Key Exchange         | ECDH         | P-384 curve (secp384r1)    |
   +----------------------+--------------+----------------------------+
   | Digital Signature    | ECDSA        | P-384 curve (secp384r1)    |
   +----------------------+--------------+----------------------------+
   | Hash Function        | SHA-384      | 384-bit output             |
   +----------------------+--------------+----------------------------+
   | Message              | HMAC-SHA-384 | 384-bit output             |
   | Authentication       | [RFC4868]    |                            |
   +----------------------+--------------+----------------------------+
   | Pseudo-Random        | HMAC-SHA-384 | Per [RFC4868]              |
   | Function (IKEv2)     |              |                            |
   +----------------------+--------------+----------------------------+
   | Key Derivation       | HKDF-SHA-384 | Per [RFC5869]              |
   +----------------------+--------------+----------------------------+

                                 Table 4

4.3.  Prohibited Algorithms

   CONDUIT implementations MUST reject configuration of the following
   algorithms and MUST NOT negotiate their use:

   *  AES with key sizes less than 256 bits (AES-128, AES-192)

   *  Triple DES (3DES) and DES

   *  SHA-1 and SHA-256 for authentication or integrity

   *  MD5

   *  RSA with key sizes less than 3072 bits

   *  Diffie-Hellman groups with less than 3072-bit modulus

   *  ECDH or ECDSA with curves smaller than P-384

   *  ChaCha20-Poly1305 (not approved for CNSA)

   Implementations MUST generate a configuration error and refuse to
   operate if prohibited algorithms are specified.





V                        Expires 23 August 2026                [Page 11]

Internet-Draft        Underlay for IPsec Transport         February 2026


4.4.  IPsec Profile

   CONDUIT implementations MUST configure IPsec with the following
   parameters:

   IKEv2 Parameters:

   *  Version: IKEv2 only (version 1 MUST NOT be used)

   *  Encryption: AES-256-GCM with 16-octet ICV (aes256gcm16)

   *  PRF: HMAC-SHA-384 (prf-hmac-sha384)

   *  Diffie-Hellman Group: 20 (384-bit random ECP, P-384)

   *  Authentication: ECDSA with SHA-384 using P-384 certificates

   ESP (Child SA) Parameters:

   *  Encryption: AES-256-GCM with 16-octet ICV

   *  Extended Sequence Numbers: Enabled

   *  Traffic Selectors: As required for overlay traffic

   Lifetime Parameters:

   *  IKE SA Lifetime: 86400 seconds (24 hours) maximum

   *  Child SA Lifetime: 28800 seconds (8 hours) maximum

   *  Child SA Volume Limit: 1 TiB maximum

4.5.  Certificate Requirements

   Node certificates MUST meet the following requirements:

   *  Format: X.509 version 3

   *  Key Algorithm: ECDSA with P-384 curve

   *  Signature Algorithm: ecdsa-with-SHA384

   *  Key Usage: digitalSignature, keyAgreement

   *  Extended Key Usage: serverAuth, clientAuth, IPsecIKE





V                        Expires 23 August 2026                [Page 12]

Internet-Draft        Underlay for IPsec Transport         February 2026


   Certificate Authority certificates MUST use ECDSA with P-384 and
   SHA-384 signatures.

   Certificate validation MUST include revocation checking via CRL or
   OCSP when network connectivity permits.

4.6.  TLS Requirements

   The gRPC API MUST be protected using TLS with the following
   configuration:

   *  Minimum Version: TLS 1.3 (TLS 1.2 and earlier MUST NOT be used)

   *  Cipher Suite: TLS_AES_256_GCM_SHA384 only

   *  Certificate Type: ECDSA with P-384 curve

   *  Client Authentication: Required (mutual TLS)

   Implementations MUST reject TLS connections that do not meet these
   requirements.

5.  Tunnel Fabric Management

5.1.  Tunnel Lifecycle States

   Each tunnel exists in one of the following states:

   DISCOVERED:  A peer has been discovered but tunnel establishment has

      not begun.  Entry: peer discovery.  Exit: initiate IKEv2.

   INITIATING:  IKEv2 negotiation is in progress.  Entry: IKEv2

      initiation.  Exit: IKE_SA and CHILD_SA established, or timeout/
      failure.

   ESTABLISHED:  The tunnel is operational and probes are succeeding

      within acceptable thresholds.  Entry: successful IKEv2 completion
      or recovery from DEGRADED.  Exit: metrics degrade, probe failures
      accumulate, or rekey initiated.

   DEGRADED:  The tunnel is operational but metrics exceed preferred

      thresholds.  Entry: metrics exceed degradation thresholds.  Exit:
      metrics recover or probe failures accumulate.




V                        Expires 23 August 2026                [Page 13]

Internet-Draft        Underlay for IPsec Transport         February 2026


   REKEYING:  Security association rekeying is in progress.  Entry:

      rekey initiated (time or volume based).  Exit: rekey success or
      failure.

   DOWN:  The tunnel has failed and is not currently usable.  Entry:

      consecutive probe failures exceed threshold or IKE failure.  Exit:
      probes succeed or WAN becomes unavailable.

   DELETED:  The tunnel is marked for removal.  Entry: WAN unavailable

      or administrative deletion.  Exit: cleanup complete.

   State transitions MUST be reported via the gRPC API event stream and
   SHOULD be logged for operational visibility.

5.2.  Tunnel Establishment Policy

   CONDUIT supports three fabric modes:

   Full Mesh:  Create tunnels for all combinations of local and remote

      WAN interfaces.  This mode maximizes path diversity but increases
      resource consumption.

   Primary Only:  Create tunnels only between designated primary WAN

      interfaces on each node.  This mode minimizes resource consumption
      but limits path diversity.

   Custom:  Apply a rule-based policy to determine which tunnel

      combinations to establish.  Rules may specify:

      *  Local WAN type (e.g., SATCOM, LOS, cellular)

      *  Remote WAN type

      *  Action (create or skip)

      *  Priority (affects establishment order)

   The tunnel policy SHOULD be configurable via the gRPC API and SHOULD
   support runtime modification without service interruption.






V                        Expires 23 August 2026                [Page 14]

Internet-Draft        Underlay for IPsec Transport         February 2026


5.3.  Tunnel Naming Convention

   Tunnel interfaces SHOULD be named according to the following
   convention to facilitate operational identification:

      tun-<peer>-<local_wan>-<remote_wan>

   Where:

   *  <peer> is a short identifier for the remote node

   *  <local_wan> is a short identifier for the local WAN interface

   *  <remote_wan> is a short identifier for the remote WAN interface

   Example names:

   *  tun-hq-sat-sat (to headquarters, SATCOM to SATCOM)

   *  tun-hq-los-lte (to headquarters, LOS radio to LTE)

   *  tun-fwd1-hf-hf (to forward unit 1, HF to HF)

5.4.  Full Mesh Fabric

   When operating in full mesh mode, the number of tunnels T to a single
   peer is:

      T = L x R

   Where L is the number of local WAN interfaces and R is the number of
   remote WAN interfaces on the peer.

   The total tunnels across all peers is:

      Total = sum(L x R_i) for each peer i

   Implementations MUST support configurable limits on:

   *  Maximum tunnels per peer

   *  Maximum total tunnels

   When limits would be exceeded, implementations SHOULD prioritize
   tunnel creation based on configured policy and WAN type preferences.

6.  Health Monitoring




V                        Expires 23 August 2026                [Page 15]

Internet-Draft        Underlay for IPsec Transport         February 2026


6.1.  Probe Mechanism

   CONDUIT monitors tunnel health through active probing.  Each tunnel
   is independently probed to measure:

         +=================+==============+=====================+
         | Metric          | Unit         | Collection Method   |
         +=================+==============+=====================+
         | Round-Trip Time | Microseconds | Timestamp echo      |
         +-----------------+--------------+---------------------+
         | Jitter          | Microseconds | [RFC3550] algorithm |
         +-----------------+--------------+---------------------+
         | Packet Loss     | Percentage   | Sequence tracking   |
         +-----------------+--------------+---------------------+
         | Availability    | Percentage   | Probe success rate  |
         +-----------------+--------------+---------------------+

                                 Table 5

6.2.  Probe Packet Format

   CONDUIT probe packets use the following format:





























V                        Expires 23 August 2026                [Page 16]

Internet-Draft        Underlay for IPsec Transport         February 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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Magic (0x434E4454)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Type      |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    TX Timestamp (64-bit)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    RX Timestamp (64-bit)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      HMAC-SHA-384                             +
   |                        (384 bits)                             |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     Padding (variable)                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Field descriptions:

   Magic (32 bits):  Fixed value 0x434E4454 ("CNDT" in ASCII).  Used to

      identify CONDUIT probe packets.

   Version (8 bits):  Protocol version.  This specification defines

      version 1.

   Type (8 bits):  Probe type:

      *  0x01: Echo Request




V                        Expires 23 August 2026                [Page 17]

Internet-Draft        Underlay for IPsec Transport         February 2026


      *  0x02: Echo Reply

      *  0x03: Timestamp Request

      *  0x04: Timestamp Reply

   Flags (16 bits):  Reserved for future use.  MUST be set to zero on

      transmission and ignored on receipt.

   Sequence Number (32 bits):  Monotonically increasing sequence number

      used for loss detection and RTT matching.

   TX Timestamp (64 bits):  Transmission timestamp in microseconds since

      the Unix epoch.  Set by the sender.

   RX Timestamp (64 bits):  Reception timestamp in microseconds since

      the Unix epoch.  Set by the responder in reply packets; zero in
      request packets.

   HMAC-SHA-384 (384 bits):  Message authentication code computed over

      all preceding fields.  Provides probe authenticity and integrity.

   Padding (variable):  Optional padding to achieve desired probe size

      for bandwidth estimation or MTU testing.

6.3.  Metrics Calculation

6.3.1.  Round-Trip Time

   RTT is calculated as:

      RTT = T_local_rx - T_local_tx

   Where T_local_rx is the local time when the reply was received and
   T_local_tx is the local time when the request was sent.

   For more accurate one-way delay measurement when nodes have
   synchronized clocks:

      OWD_forward = T_remote_rx - T_local_tx
      OWD_reverse = T_local_rx - T_remote_tx




V                        Expires 23 August 2026                [Page 18]

Internet-Draft        Underlay for IPsec Transport         February 2026


6.3.2.  Jitter

   Jitter is calculated using the algorithm specified in [RFC3550]:

      D(i) = (R(i) - R(i-1)) - (S(i) - S(i-1))
      J(i) = J(i-1) + (|D(i)| - J(i-1)) / 16

   Where:

   *  R(i) is the receive timestamp of probe i

   *  S(i) is the send timestamp of probe i

   *  J(i) is the jitter estimate after probe i

6.3.3.  Packet Loss

   Packet loss is calculated over a sliding window:
      Loss% = ((Probes_sent - Probes_received) / Probes_sent) x 100

   The default window size is 100 probes.  Implementations SHOULD make
   this configurable.

6.4.  Probe Scheduling

   The base probe interval is configurable, with a default of 100ms.

   The effective probe interval SHOULD be adjusted based on tunnel
   state:

            +=============+============+======================+
            | State       | Multiplier | Rationale            |
            +=============+============+======================+
            | Established | 1.0        | Normal monitoring    |
            +-------------+------------+----------------------+
            | Degraded    | 0.5        | Increased monitoring |
            |             |            | of troubled tunnel   |
            +-------------+------------+----------------------+
            | Recovering  | 0.25       | Rapid assessment     |
            |             |            | during recovery      |
            +-------------+------------+----------------------+
            | Down        | 2.0        | Reduced load on      |
            |             |            | failed path          |
            +-------------+------------+----------------------+

                                  Table 6





V                        Expires 23 August 2026                [Page 19]

Internet-Draft        Underlay for IPsec Transport         February 2026


   To prevent probe synchronization across tunnels, implementations
   SHOULD add random jitter of +/- 10% to each probe interval.

6.5.  Tunnel State Determination

   Tunnel state transitions are triggered by threshold crossings:

   Degraded Thresholds:

   *  RTT increases by more than 50% above baseline

   *  Packet loss exceeds 1%

   *  Jitter increases by more than 100% above baseline

   Down Thresholds:

   *  Five or more consecutive probe failures

   *  Packet loss exceeds 25%

   Thresholds SHOULD be configurable via the gRPC API.

7.  Metric Publishing

7.1.  Publishing Methods

   CONDUIT publishes tunnel metrics through multiple mechanisms to
   enable SRv6-based traffic engineering:

      +====================+==================+=====================+
      | Method             | Target           | Use Case            |
      +====================+==================+=====================+
      | Interface Metrics  | Operating system | Simple deployments  |
      +--------------------+------------------+---------------------+
      | IGP TE Extensions  | IS-IS / OSPF     | Distributed TE      |
      +--------------------+------------------+---------------------+
      | gRPC Streaming     | SDN Controller   | Centralized TE      |
      +--------------------+------------------+---------------------+
      | Flex-Algo Affinity | IGP Flex-Algo    | Constraint-based TE |
      +--------------------+------------------+---------------------+

                                  Table 7

   Implementations MUST support interface metric publishing.
   Implementations SHOULD support IGP TE extensions and gRPC streaming.





V                        Expires 23 August 2026                [Page 20]

Internet-Draft        Underlay for IPsec Transport         February 2026


7.2.  Interface Metric Calculation

   CONDUIT calculates an interface metric from tunnel quality
   measurements using the following formula:

      Metric = Latency_component + Loss_component + Jitter_component

   Where:

   *  Latency_component = RTT_ms (1 ms = 1 metric unit)

   *  Loss_component = Loss% x 100 (1% loss = 100 metric units)

   *  Jitter_component = Jitter_ms x 10 (1 ms jitter = 10 metric units)

   The resulting metric MUST be clamped to the range 1-65535.

   Example calculations:

            +==============+========+======+========+========+
            | Tunnel Type  | RTT    | Loss | Jitter | Metric |
            +==============+========+======+========+========+
            | GEO SATCOM   | 600 ms | 0.1% | 10 ms  | 710    |
            +--------------+--------+------+--------+--------+
            | LOS Radio    | 5 ms   | 0%   | 0.5 ms | 10     |
            +--------------+--------+------+--------+--------+
            | LTE Cellular | 50 ms  | 0.5% | 5 ms   | 150    |
            +--------------+--------+------+--------+--------+

                                 Table 8

   The SRv6 data plane, seeing these metrics, will naturally prefer the
   LOS tunnel (metric 10) over LTE (metric 150) over SATCOM (metric 710)
   when computing shortest paths.

7.3.  IGP TE Extensions

   When IGP TE metric publishing is enabled, CONDUIT advertises the
   following per-tunnel attributes:

   *  TE Metric: Calculated as described in Section 7.2

   *  Maximum Link Bandwidth: Configured WAN bandwidth

   *  Available Bandwidth: Estimated available capacity

   *  Unidirectional Link Delay: Measured one-way delay per [RFC8570]




V                        Expires 23 August 2026                [Page 21]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Unidirectional Delay Variation: Measured jitter per [RFC8570]

   *  Unidirectional Packet Loss: Measured loss per [RFC8570]

   *  Shared Risk Link Groups: Assigned SRLG values

   *  Administrative Group: For Flex-Algo affinity matching

   For IS-IS, these attributes are advertised using the extensions
   defined in [RFC8570].  For OSPF, the equivalent extensions from
   [RFC7471] apply.

7.4.  Flex-Algo Integration

   CONDUIT assigns tunnels to Flexible Algorithm groups based on
   measured characteristics and configured constraints.

   A Flex-Algo definition specifies:

   *  Algorithm ID: An integer in the range 128-255

   *  Metric Type: IGP metric, minimum delay, or TE metric

   *  Constraints: Maximum delay, minimum bandwidth, SRLG exclusions

   CONDUIT evaluates each tunnel against each Flex-Algo definition and
   sets the appropriate affinity bits in IGP advertisements.

   Example Flex-Algo definitions for tactical networks:

   Flex-Algo 128 (Low Latency):

   *  Metric Type: Minimum Delay

   *  Constraint: Maximum delay 100 ms

   *  Use: Voice, real-time C2

   Flex-Algo 129 (High Bandwidth):

   *  Metric Type: IGP

   *  Constraint: Minimum bandwidth 1 Mbps

   *  Use: Video, bulk transfer

   Flex-Algo 130 (Resilient):




V                        Expires 23 August 2026                [Page 22]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Metric Type: IGP

   *  Constraint: Exclude SRLG "satcom"

   *  Use: Critical C2 requiring terrestrial diversity

   With these definitions, the SRv6 data plane automatically steers
   voice traffic over low-latency tunnels (LOS radio), video over high-
   bandwidth tunnels (possibly ECMP across multiple), and critical C2
   over tunnels not sharing SATCOM failure modes.

7.5.  SRLG Assignment

   Shared Risk Link Groups identify tunnels that share common failure
   modes.  CONDUIT assigns SRLG values based on:

   *  WAN Type: All tunnels using SATCOM share a "satcom" SRLG

   *  Physical Path: Tunnels using the same physical link share an SRLG

   *  Provider: Tunnels using the same carrier share an SRLG

   *  Geographic: Tunnels transiting the same geographic area may share
      an SRLG

   SRLG assignment enables SRv6 TI-LFA to compute backup paths that
   avoid shared failure modes and Flex-Algo to exclude entire failure
   domains.

8.  Control Protocol

8.1.  Transport

   CONDUIT control messages are transported via UDP.  Two ports are
   used:

   *  Port 4794: Control messages (HELLO, WAN_UPDATE, etc.)

   *  Port 4795: Probe packets

   Control messages are transmitted through established IPsec tunnels
   when available.  For initial peer discovery before tunnel
   establishment, messages may be sent via the underlying WAN with HMAC
   authentication.







V                        Expires 23 August 2026                [Page 23]

Internet-Draft        Underlay for IPsec Transport         February 2026


8.2.  Message Header

   All CONDUIT control messages share a common header:

   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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Type      |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Node ID                               +
   |                         (64 bits)                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                      Timestamp (64 bits)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      HMAC-SHA-384                             +
   |                        (384 bits)                             |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Field descriptions:

   Version (8 bits):  Protocol version.  This specification defines

      version 1.

   Type (8 bits):  Message type as defined in Section 8.3.


   Flags (16 bits):  Message-specific flags.


   Length (16 bits):  Total message length in octets, including header.




V                        Expires 23 August 2026                [Page 24]

Internet-Draft        Underlay for IPsec Transport         February 2026


   Reserved (16 bits): Reserved for future use.  MUST be zero.

   Node ID (64 bits):  Unique identifier of the sending node.


   Sequence Number (32 bits):  Per-peer monotonically increasing

    counter for anti-replay protection.

   Timestamp (64 bits):  Message creation time in microseconds since

    Unix epoch.

   HMAC-SHA-384 (384 bits):  Message authentication code computed over

    the entire message with the HMAC field set to zero.

   Total header size: 72 octets.

8.3.  Message Types

     +=======+===============+======================================+
     | Value | Name          | Description                          |
     +=======+===============+======================================+
     | 0x01  | HELLO         | Peer discovery and WAN advertisement |
     +-------+---------------+--------------------------------------+
     | 0x02  | HELLO_ACK     | Response to HELLO                    |
     +-------+---------------+--------------------------------------+
     | 0x03  | WAN_UPDATE    | WAN availability change notification |
     +-------+---------------+--------------------------------------+
     | 0x04  | TUNNEL_STATE  | Tunnel state change notification     |
     +-------+---------------+--------------------------------------+
     | 0x05  | KEEPALIVE     | Peer liveness check                  |
     +-------+---------------+--------------------------------------+
     | 0x06  | KEEPALIVE_ACK | Response to KEEPALIVE                |
     +-------+---------------+--------------------------------------+
     | 0x0F  | ERROR         | Error notification                   |
     +-------+---------------+--------------------------------------+

                                 Table 9

8.4.  HELLO Message

   The HELLO message is used for peer discovery and WAN capability
   advertisement:






V                        Expires 23 August 2026                [Page 25]

Internet-Draft        Underlay for IPsec Transport         February 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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Num WANs    |   Reserved    |         Capabilities          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Hold Time (sec)        |        Max Tunnels            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    SRv6 Locator (48 bits)                     +
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      WAN Descriptors                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Field descriptions:

   Num WANs (8 bits):  Number of WAN Descriptors following.


   Capabilities (16 bits):  Bitmask of supported capabilities.


   Hold Time (16 bits):  Time in seconds the receiver should consider

    the sender reachable without further messages.

   Max Tunnels (16 bits):  Maximum tunnels this node can establish to

    a single peer.

   SRv6 Locator (48 bits):  The node's SRv6 locator prefix.


8.5.  WAN Descriptor

   Each WAN interface is described by a WAN Descriptor:












V                        Expires 23 August 2026                [Page 26]

Internet-Draft        Underlay for IPsec Transport         February 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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    WAN ID     |   WAN Type    |     State     | Addr Flags    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Bandwidth (Kbps)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              MTU              |     Typical Latency (ms)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  IPv6 Address (if flag set)                   +
   |                        (128 bits)                             |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  IPv4 Address (if flag set)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            SRLG ID            |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   WAN Type values:






























V                        Expires 23 August 2026                [Page 27]

Internet-Draft        Underlay for IPsec Transport         February 2026


            +=======+===============+=========================+
            | Value | Name          | Typical Characteristics |
            +=======+===============+=========================+
            | 0x01  | SATCOM_GEO    | 600ms RTT, 2-10 Mbps    |
            +-------+---------------+-------------------------+
            | 0x02  | SATCOM_LEO    | 30ms RTT, 50-200 Mbps   |
            +-------+---------------+-------------------------+
            | 0x03  | LOS_RADIO     | 5ms RTT, 10-100 Mbps    |
            +-------+---------------+-------------------------+
            | 0x04  | TROPOSCATTER  | 10ms RTT, 5-20 Mbps     |
            +-------+---------------+-------------------------+
            | 0x05  | HF_RADIO      | 50ms RTT, 9.6-64 Kbps   |
            +-------+---------------+-------------------------+
            | 0x06  | CELLULAR_LTE  | 30ms RTT, 10-100 Mbps   |
            +-------+---------------+-------------------------+
            | 0x07  | CELLULAR_5G   | 10ms RTT, 100-1000 Mbps |
            +-------+---------------+-------------------------+
            | 0x08  | WIRE_ETHERNET | 1ms RTT, 1-100 Gbps     |
            +-------+---------------+-------------------------+
            | 0x09  | WIRE_FIBER    | 1ms RTT, 1-100 Gbps     |
            +-------+---------------+-------------------------+
            | 0x0A  | WIFI          | 5ms RTT, 50-500 Mbps    |
            +-------+---------------+-------------------------+

                                  Table 10

   Address Flags:

   *  Bit 0: IPv4 address present

   *  Bit 1: IPv6 address present

   *  Bit 2: Behind NAT (IPv4)

   *  Bit 3: Behind NAT (IPv6)

8.6.  Message Authentication

   All CONDUIT control messages MUST be authenticated using HMAC- SHA-
   384.

   The authentication key is derived from the IKEv2 SA when
   available:








V                        Expires 23 August 2026                [Page 28]

Internet-Draft        Underlay for IPsec Transport         February 2026


      AUTH_KEY = HKDF-SHA-384(
         IKM = SK_d,
         salt = "CONDUIT-v1-auth",
         info = Node_ID_local || Node_ID_remote,
         length = 48
      )

   For initial HELLO messages before IKEv2 SA establishment, a pre-
   shared key MAY be used.  Unauthenticated HELLO messages MUST NOT be
   accepted in production deployments.

8.7.  Anti-Replay Protection

   Each peer maintains anti-replay state consisting of:

   *  Expected sequence number (next expected value)

   *  Window bitmap (received sequences within window)

   *  Window size (default 64)

   *  Maximum timestamp skew (default 60 seconds)

   Message acceptance rules:

   1.  If sequence >= expected: Accept and update expected

   2.  If sequence < expected - window_size: Reject (too old)

   3.  If sequence in window and bit set: Reject (replay)

   4.  If sequence in window and bit clear: Accept and set bit

   5.  If timestamp differs from local time by more than maximum skew:
       Reject

9.  SRv6 Integration

9.1.  Tunnel Interfaces as SRv6 Adjacencies

   Each CONDUIT tunnel is presented to the SRv6 data plane as a distinct
   interface.  From the perspective of IS-IS or OSPFv3, each tunnel
   represents a separate adjacency to the peer node.

   This design enables:

   *  Independent metrics per tunnel based on measured quality




V                        Expires 23 August 2026                [Page 29]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  ECMP load balancing across multiple tunnels to the same peer

   *  Flex-Algo differentiation based on tunnel characteristics

   *  TI-LFA backup path computation considering tunnel diversity

   For example, a node with three tunnels to a peer (via SATCOM, LOS,
   and LTE) would advertise three adjacencies in IS-IS, each with its
   own metric.  The IGP SPF computation naturally prefers lower-metric
   paths.

9.2.  Flex-Algo Tunnel Assignment

   CONDUIT evaluates each tunnel against configured Flex-Algo
   definitions and assigns appropriate affinities.

   A tunnel qualifies for a Flex-Algo if:

   *  Measured delay is less than the maximum delay constraint (if
      specified)

   *  Configured bandwidth meets the minimum bandwidth constraint (if
      specified)

   *  Tunnel SRLG membership does not intersect with excluded SRLGs (if
      specified)

   Assignment is dynamic: as tunnel metrics change, Flex-Algo membership
   is re-evaluated and IGP advertisements are updated accordingly.

   Example assignment for a deployment with three Flex-Algos:

   +===========+====================+====================+=============+
   | Tunnel    | Algo 128 (Low Lat) | Algo 129           | Algo 130    |
   |           |                    | (High BW)          | (Resilient) |
   +===========+====================+====================+=============+
   | SATCOM    | Excluded           | Included           | Excluded    |
   | (600ms)   |                    |                    |             |
   +-----------+--------------------+--------------------+-------------+
   | LOS Radio | Included           | Included           | Included    |
   | (5ms)     |                    |                    |             |
   +-----------+--------------------+--------------------+-------------+
   | LTE       | Included           | Included           | Included    |
   | (50ms)    |                    |                    |             |
   +-----------+--------------------+--------------------+-------------+

                                  Table 11




V                        Expires 23 August 2026                [Page 30]

Internet-Draft        Underlay for IPsec Transport         February 2026


   The SATCOM tunnel is excluded from Flex-Algo 128 (delay exceeds 100ms
   threshold) and Flex-Algo 130 (SRLG "satcom" is excluded).

9.3.  Traffic Steering

   With CONDUIT providing tunnel metrics and Flex-Algo assignments,
   traffic steering is accomplished through standard SRv6 mechanisms:

   *  SRv6 Policy Color: Traffic matching a policy with a specific color
      is steered to paths computed using the associated Flex-Algo

   *  DSCP Mapping: DSCP values can be mapped to SRv6 policy colors

   *  BGP Communities: BGP communities can signal desired Flex-Algo

   Example mapping for tactical traffic:

        +==============+===========+==========+===================+
        | Traffic Type | DSCP      | SR Color | Flex-Algo         |
        +==============+===========+==========+===================+
        | Voice        | EF (46)   | 100      | 128 (Low Latency) |
        +--------------+-----------+----------+-------------------+
        | Video        | AF41 (34) | 200      | 129 (High BW)     |
        +--------------+-----------+----------+-------------------+
        | Critical C2  | CS6 (48)  | 300      | 130 (Resilient)   |
        +--------------+-----------+----------+-------------------+
        | Best Effort  | BE (0)    | 0        | Default (SPF)     |
        +--------------+-----------+----------+-------------------+

                                  Table 12

10.  High Availability

10.1.  HA Architecture

   CONDUIT supports high availability through active-standby or active-
   active node pairs sharing a virtual IP address.

   In active-standby mode:

   *  Primary node handles all tunnel management and peer communication

   *  Standby node maintains synchronized state and pre-established
      tunnels

   *  Failover occurs when primary failure is detected

   In active-active mode:



V                        Expires 23 August 2026                [Page 31]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Both nodes actively manage tunnels

   *  Anycast addressing distributes peer connections

   *  State synchronization ensures consistency

10.2.  Synchronized State

   The following state is synchronized between HA peers:

     +===============+==================+===========================+
     | Data          | Sync Method      | Purpose                   |
     +===============+==================+===========================+
     | Peer List     | Periodic + Event | Both nodes know all peers |
     +---------------+------------------+---------------------------+
     | Tunnel State  | Event-driven     | Enable fast failover      |
     +---------------+------------------+---------------------------+
     | Metrics       | Periodic (1 Hz)  | Consistent path costs     |
     +---------------+------------------+---------------------------+
     | Configuration | Event-driven     | Policy consistency        |
     +---------------+------------------+---------------------------+

                                 Table 13

   IKEv2 Security Associations are NOT synchronized.  Each node
   maintains independent SAs with peers.  This simplifies implementation
   and avoids complexities of SA state transfer.

10.3.  Failover Behavior

   Upon detecting primary node failure:

   1.  Standby assumes the virtual IP address

   2.  Standby's pre-established tunnels become active

   3.  SRv6 reconverges via TI-LFA (sub-50ms for pre-computed backups)

   4.  Traffic flows through standby's tunnels

   Target failover time is less than 3 seconds for complete recovery,
   with TI-LFA providing sub-50ms forwarding continuity for traffic with
   pre-computed backup paths.

11.  gRPC API






V                        Expires 23 August 2026                [Page 32]

Internet-Draft        Underlay for IPsec Transport         February 2026


11.1.  Service Overview

   CONDUIT exposes all functionality through a gRPC API comprising three
   services:

   TunnelFabric Service:  Primary interface for tunnel management,

      including node configuration, WAN interface management, peer
      discovery and management, tunnel lifecycle operations, tunnel
      policy configuration, and metric publishing configuration.

   Telemetry Service:  Provides access to operational metrics, including

      current tunnel metrics, real-time metric streaming, historical
      metric queries, and fabric statistics.

   HighAvailability Service:  Manages HA operations, including HA status

      and configuration, synchronization status, and manual failover
      triggers.

   The complete Protocol Buffer definitions for these services are
   available in a companion document.

11.2.  Authentication and Authorization

   All gRPC connections MUST use mutual TLS (mTLS) with certificates
   meeting the requirements of Section 4.5.

   Implementations SHOULD support role-based access control (RBAC) for
   API authorization.  Recommended roles include:

   *  Administrator: Full access to all operations

   *  Operator: Read access plus tunnel state changes

   *  Monitor: Read-only access to status and metrics

12.  Security Considerations

12.1.  Cryptographic Security

   CONDUIT's security relies on the strength of its cryptographic
   foundations.  The mandatory use of CNSA 2.0 algorithms provides
   protection appropriate for classified information.

   Key security properties:




V                        Expires 23 August 2026                [Page 33]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  All tunnel traffic is protected by AES-256-GCM, providing
      confidentiality and integrity

   *  All control messages are authenticated using HMAC-SHA-384

   *  Key exchange uses ECDH with P-384, providing forward secrecy

   *  Node authentication uses ECDSA with P-384 certificates

12.2.  Threat Mitigations

   CONDUIT addresses the following threats:

    +=====================+===========================================+
    | Threat              | Mitigation                                |
    +=====================+===========================================+
    | Probe Spoofing      | HMAC-SHA-384 authentication on all probes |
    +---------------------+-------------------------------------------+
    | Replay Attacks      | Sequence numbers and timestamp validation |
    +---------------------+-------------------------------------------+
    | Man-in-the-Middle   | IPsec with certificate-based auth         |
    +---------------------+-------------------------------------------+
    | Unauthorized API    | Mutual TLS with certificate validation    |
    +---------------------+-------------------------------------------+
    | Tunnel Manipulation | Authenticated control protocol messages   |
    +---------------------+-------------------------------------------+
    | Denial of Service   | Rate limiting on control plane            |
    +---------------------+-------------------------------------------+

                                  Table 14

12.3.  Operational Security

   Deployments SHOULD implement the following operational security
   measures:

   *  Certificates should be rotated at least annually

   *  Private keys should be stored in hardware security modules (HSM)
      where available

   *  All tunnel state changes should be logged for audit purposes

   *  Rate limiting should be applied to control plane message
      processing

   *  Network segmentation should isolate CONDUIT management traffic




V                        Expires 23 August 2026                [Page 34]

Internet-Draft        Underlay for IPsec Transport         February 2026


13.  IANA Considerations

13.1.  UDP Port Allocation

   This document requests allocation of two UDP ports:

           +======+=================+==========================+
           | Port | Name            | Description              |
           +======+=================+==========================+
           | 4794 | conduit-control | CONDUIT control messages |
           +------+-----------------+--------------------------+
           | 4795 | conduit-probe   | CONDUIT probe packets    |
           +------+-----------------+--------------------------+

                                  Table 15

13.2.  WAN Type Registry

   This document requests creation of a "CONDUIT WAN Types" registry
   with the following initial values:

   +-------+----------------+-------------------------+
   | Value | Name           | Reference               |
   +-------+----------------+-------------------------+
   |  0x00 | Reserved       | This document           |
   |  0x01 | SATCOM_GEO     | This document           |
   |  0x02 | SATCOM_LEO     | This document           |
   |  0x03 | LOS_RADIO      | This document           |
   |  0x04 | TROPOSCATTER   | This document           |
   |  0x05 | HF_RADIO       | This document           |
   |  0x06 | CELLULAR_LTE   | This document           |
   |  0x07 | CELLULAR_5G    | This document           |
   |  0x08 | WIRE_ETHERNET  | This document           |
   |  0x09 | WIRE_FIBER     | This document           |
   |  0x0A | WIFI           | This document           |
   | 0x0B-0xEF | Unassigned |                         |
   | 0xF0-0xFF | Private Use | This document          |
   +-------+----------------+-------------------------+

   New values in the range 0x0B-0xEF require Standards Action.

14.  References

14.1.  Normative References







V                        Expires 23 August 2026                [Page 35]

Internet-Draft        Underlay for IPsec Transport         February 2026


   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

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

   [RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
              D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
              2019, <https://www.rfc-editor.org/info/rfc8570>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

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

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868,
              DOI 10.17487/RFC4868, May 2007,
              <https://www.rfc-editor.org/info/rfc4868>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <https://www.rfc-editor.org/info/rfc7471>.





V                        Expires 23 August 2026                [Page 36]

Internet-Draft        Underlay for IPsec Transport         February 2026


Appendix A.  WAN Type Characteristics

   The following table provides typical characteristics for each WAN
   type.  Actual values vary based on specific equipment, configuration,
   and environmental conditions.

   +===============+=========+===============+=========================+
   | WAN Type      | Latency | Bandwidth     | Notes                   |
   +===============+=========+===============+=========================+
   | SATCOM_GEO    | 600ms   | 2-10 Mbps     | Weather sensitive       |
   +---------------+---------+---------------+-------------------------+
   | SATCOM_LEO    | 20-40ms | 50-200 Mbps   | Handover during orbit   |
   +---------------+---------+---------------+-------------------------+
   | LOS_RADIO     | 5ms     | 10-100 Mbps   | Terrain dependent       |
   +---------------+---------+---------------+-------------------------+
   | TROPOSCATTER  | 10ms    | 5-20 Mbps     | Over-horizon capability |
   +---------------+---------+---------------+-------------------------+
   | HF_RADIO      | 50ms    | 9.6-64 Kbps   | Atmospheric effects     |
   +---------------+---------+---------------+-------------------------+
   | CELLULAR_LTE  | 30ms    | 10-100 Mbps   | Coverage dependent      |
   +---------------+---------+---------------+-------------------------+
   | CELLULAR_5G   | 10ms    | 100-1000      | Limited coverage        |
   |               |         | Mbps          |                         |
   +---------------+---------+---------------+-------------------------+
   | WIRE_ETHERNET | <1ms    | 1-100 Gbps    | Fixed installations     |
   +---------------+---------+---------------+-------------------------+
   | WIRE_FIBER    | <1ms    | 1-100 Gbps    | Fixed installations     |
   +---------------+---------+---------------+-------------------------+
   | WIFI          | 5ms     | 50-500 Mbps   | Short range             |
   +---------------+---------+---------------+-------------------------+

                                  Table 16

Acknowledgements

   The authors thank the members of the tactical networking community
   for their input on operational requirements and deployment
   considerations.

Author's Address

   John Edward Willman V
   Department of the Air Force
   1800 Air Force Pentagon
   Washington, DC 20330
   United States of America
   Phone: +1 786 994 3023
   Email: john.willman.1@us.af.mil



V                        Expires 23 August 2026                [Page 37]

Internet-Draft        Underlay for IPsec Transport         February 2026


   URI:   https://www.linkedin.com/in/johnewillmanv


















































V                        Expires 23 August 2026                [Page 38]


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: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014717+00:00
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: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:09.014742+00:00
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: ["Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:09.014757+00:00
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: 05
title: Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC)
time: 2026-01-07T08:43:54Z
group_uri: /api/v1/group/group/2249/
expires: 2026-07-11T08:43:54Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/145/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014762+00:00
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: 06
title: Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA)
time: 2025-11-21T17:11:33Z
group_uri: /api/v1/group/group/2249/
expires: 2026-04-23T23:22:43Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Agent identity/auth", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:09.014768+00:00
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-02-14T07:13:01Z
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: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014773+00:00
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/20/", "/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]


