Post-Quantum Enhancements to EAP-TLS and EAP-TTLS
draft-reddy-emu-pqc-eap-tls-02

EAP Method Update                                               T. Reddy
Internet-Draft                                                     Nokia
Intended status: Standards Track                         24 January 2026
Expires: 28 July 2026

           Post-Quantum Enhancements to EAP-TLS and EAP-TTLS
                     draft-reddy-emu-pqc-eap-tls-02

Abstract

   This document proposes enhancements to the Extensible Authentication
   Protocol with Transport Layer Security (EAP-TLS) and EAP Tunneled TLS
   (EAP-TTLS) to incorporate post-quantum cryptographic mechanisms.  It
   also addresses challenges related to large certificate sizes and long
   certificate chains, as identified in [RFC9191], and provides
   recommendations for integrating PQC algorithms into EAP-TLS and EAP-
   TTLS deployments.

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-reddy-emu-pqc-eap-tls/.

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 28 July 2026.

Reddy                     Expires 28 July 2026                  [Page 1]
Internet-Draft      PQC Enhancements to EAP-TLS/TTLS        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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Data Confidentiality in EAP-TLS . . . . . . . . . . . . . . .   4
   4.  Post-Quantum Authentication in EAP-TLS  . . . . . . . . . . .   5
   5.  EST Integration . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     Normative References  . . . . . . . . . . . . . . . . . . . . .   8
     Informative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The emergence of a Cryptographically Relevant Quantum Computer (CRQC)
   would break the mathematical assumptions that underpins widely
   deployed public-key algorithms, rendering them insecure and obsolete.
   As a result, there is an urgent need to update protocols and
   infrastructure with post-quantum cryptographic (PQC) algorithms
   designed to resist attacks from both quantum and classical
   adversaries.  The cryptographic primitives requiring replacement are
   discussed in [I-D.ietf-pquip-pqc-engineers], and the NIST PQC
   Standardization process has initially selected algorithms such as ML-
   KEM, SLH-DSA, and ML-DSA for usage in security protocols.

   To mitigate the risks posed by a CRQC, such as the potential
   compromise of encrypted data and the forging of digital signatures,
   existing security protocols must be upgraded to support PQC.  These
   risks include "Harvest Now, Decrypt Later" (HNDL) attack, where
   adversaries capture encrypted traffic today with the intent to
   decrypt it once CRQCs become available.  Protocols such as EAP-TLS

Reddy                     Expires 28 July 2026                  [Page 2]
Internet-Draft      PQC Enhancements to EAP-TLS/TTLS        January 2026

   and EAP-TTLS are widely used for network access authentication in
   Enterprise and Wireless environments.  To continue providing long-
   term confidentiality and authentication guarantees, EAP-TLS and EAP-
   TTLS must evolve to incorporate post-quantum algorithms.

   However, transitioning these protocols to support PQC introduces
   practical challenges.  [RFC9191] highlights issues related to large
   certificates and certificate chains in EAP-TLS, which can lead to
   session failures due to round-trip limitations.  PQC certificates and
   certificate chains tend to be significantly larger than their
   traditional counterparts, further exacerbating these issues by
   increasing TLS handshake sizes and the likelihood of session
   failures.  To address these challenges, this draft proposes
   mitigation strategies that enable the use of PQC within EAP-TLS and
   EAP-TTLS, ensuring secure and efficient authentication even in
   constrained network environments.

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.

   This document adopts terminology defined in
   [I-D.ietf-pquip-pqt-hybrid-terminology].  For the purposes of this
   document, it is useful to categorize cryptographic algorithms into
   three distinct classes:

   *  Traditional Algorithm: An asymmetric cryptographic algorithm based
      on integer factorization, finite field discrete logarithms, or
      elliptic curve discrete logarithms.  In the context of TLS, an
      example of a traditional key exchange algorithm is Elliptic Curve
      Diffie-Hellman (ECDH), which is almost exclusively used in its
      ephemeral mode, referred to as Elliptic Curve Diffie-Hellman
      Ephemeral (ECDHE).

   *  Post-Quantum Algorithm: An asymmetric cryptographic algorithm
      designed to be secure against attacks from both quantum and
      classical computers.  An example of a post-quantum key exchange
      algorithm is the Module-Lattice Key Encapsulation Mechanism (ML-
      KEM).

   *  Hybrid Algorithm: We distinguish between key exchanges and
      signature algorithms:

Reddy                     Expires 28 July 2026                  [Page 3]
Internet-Draft      PQC Enhancements to EAP-TLS/TTLS        January 2026

      -  Hybrid Key Exchange: A key exchange mechanism that combines two
         component algorithms - one traditional algorithm and one post-
         quantum algorithm.  The resulting shared secret remains secure
         as long as at least one of the component key exchange
         algorithms remains unbroken.

      -  PQ/T Hybrid Digital Signature: A multi-algorithm digital
         signature scheme composed of two or more component signature
         algorithms, where at least one is a post-quantum algorithm and
         at least one is a traditional algorithm.

   Digital signature algorithms play a critical role in X.509
   certificates, Certificate Transparency Signed Certificate Timestamps,
   Online Certificate Status Protocol (OCSP) statements, and any other
   mechanism that contributes signatures during a TLS handshake or in
   context of a secure communication establishment.

3.  Data Confidentiality in EAP-TLS

   One of the primary threats to EAP-TLS and EAP-TTLS is the HNDL
   attack.  In this scenario, adversaries can passively capture EAP-TLS
   handshakes such as those transmitted over the air in Wi-Fi networks
   and store them for future decryption once CRQCs become available.

   While EAP-TLS 1.3 [RFC9190] provides forward secrecy through
   ephemeral key exchange and improves privacy by encrypting client
   identity and reducing exposure of session metadata, these protections
   rely on the security of the underlying key exchange algorithm.  In
   the presence of a CRQC, traditional key exchange mechanisms (e.g.,
   ECDHE) would no longer provide long-term confidentiality.  In such
   cases, an adversary could mount a HDNL attack by passively recording
   EAP-TLS handshakes and decrypting the captured traffic once quantum-
   capable cryptanalysis becomes feasible.  This could retroactively
   expose information that TLS 1.3 is otherwise designed to protect,
   including:

   *  The identity of the authenticated client.

   *  Client credentials used in certificate-based authentication (e.g.,
      usernames, device or organization identifiers).

   To preserve the intended privacy guarantees of TLS 1.3 and to protect
   against HDNL attacks, EAP-TLS and EAP-TTLS deployments that require
   long-term confidentiality will need to adopt post-quantum key
   exchange mechanisms, as outlined in Section 4 of
   [I-D.ietf-uta-pqc-app].

Reddy                     Expires 28 July 2026                  [Page 4]
Internet-Draft      PQC Enhancements to EAP-TLS/TTLS        January 2026

   These mechanisms ensure that even if handshake data is recorded
   today, it cannot be decrypted in the future, maintaining the
   confidentiality and privacy of the TLS session.

   Furthermore, to support hybrid or PQC-only key exchange in bandwidth
   or latency-constrained EAP deployments, EAP clients and servers
   should apply the optimizations described in Section 4.1 of
   [I-D.ietf-uta-pqc-app] to minimize performance overhead.

4.  Post-Quantum Authentication in EAP-TLS

   Although a CRQC would primarily impact the confidentiality of
   recorded TLS sessions, it could also pose risks to authentication
   mechanisms that rely on traditional public-key algorithms with long-
   lived credentials.  In particular, if quantum-capable cryptanalysis
   were to become practical within the validity period of a certificate,
   an adversary could recover the private key corresponding to a
   traditionally signed certificate and subsequently impersonate the
   certificate holder in real time.  The feasibility and impact of such
   attacks depend on several factors, including certificate lifetimes
   and key management practices.

   EAP-TLS and EAP-TTLS deployments rely on X.509 certificates issued by
   CAs, and the transition to PQ certificate authentication is
   constrained by the long lifecycle associated with distributing,
   deploying, and validating new trust anchors.  If CRQCs arrive sooner
   than anticipated, deployed authentication systems may lack the
   agility to transition credentials and trust anchors in a timely
   manner.

   As a result, deployments that rely on long-lived certificates or that
   require resistance to future quantum-capable adversaries face an
   increased risk of authentication compromise.  In such scenarios, an
   on-path attacker that is able to recover a server’s private key
   within the certificate validity period could impersonate access
   points (APs) in real time, potentially deceiving users into revealing
   credentials or connecting to rogue networks.

   To mitigate these risks, EAP-TLS and EAP-TTLS deployments will need
   to adopt, over time, either PQ or PQ/T hybrid certificate-based
   authentication, as described in Section 5 of [I-D.ietf-uta-pqc-app].

   The use of PQ or PQ/T hybrid certificates increases the size of
   individual certificates, certificate chains, and signatures,
   resulting in significantly larger handshake messages.  These larger
   payloads can lead to packet fragmentation, retransmissions, and
   handshake delays, issues that are particularly disruptive in
   constrained or lossy network environments.

Reddy                     Expires 28 July 2026                  [Page 5]
Internet-Draft      PQC Enhancements to EAP-TLS/TTLS        January 2026

   To address these impacts, EAP-TLS and EAP-TTLS deployments can apply
   certificate chain optimization techniques outlined in Section 6.1 of
   [I-D.ietf-uta-pqc-app] to reduce transmission overhead and improve
   handshake reliability.

5.  EST Integration

   The EAP-client is expected to validate the certificate presented by
   the EAP-server using a trust anchor that is provisioned out-of-band
   prior to authentication (e.g., using EST).  The Intermediate
   certificates are provided by the EAP server during the EAP-TLS
   handshake.  The EAP client relies solely on the pre-provisioned trust
   anchor to build and validate the certificate chain.  This model
   assumes a managed deployment environment with explicitly configured
   trust relationships between the EAP-client and EAP-server.

   To further reduce handshake overhead, particularly in deployments
   using large certificate chains due to post-quantum (PQ) or composite
   certificates, this draft proposes an optimization that leverages the
   Enrollment over Secure Transport (EST) protocol [RFC7030], extended
   by [RFC8295].  Specifically, it allows intermediate certificates to
   be retrieved in advance by using EST, thereby avoiding the need to
   transmit them during each EAP-TLS exchange.

   This section defines extensions to EST to support retrieval of the
   certificate chain used by a EAP server and EAP clients.  The first
   extension enables clients to obtain access to the complete set of
   published intermediate certificates of the EAP server.

   A new path component is defined under the EST well-known URI:

   GET /.well-known/est/eapservercertchain

   The '/eapservercertchain' is intended for informational retrieval
   only and does not require client authentication.  It allows clients
   to retrieve the intermediate certificate chain that the EAP server
   presents during TLS handshakes.  This request is performed using the
   HTTPS protocol.  The EST server MUST support requests without
   requiring client authentication.  The certificate chain provided by
   the EST server MUST be the same certificate chain EAP server uses in
   a EAP-TLS or EAP-TTLS session.

   The second extension enables EAP servers to obtain access to the
   complete set of published intermediate certificates of the EAP
   clients.  Rather than relying on static configuration, the EAP server
   can dynamically fetch the client's intermediate certificate chain
   from a trusted EST server within the same administrative domain.

Reddy                     Expires 28 July 2026                  [Page 6]
Internet-Draft      PQC Enhancements to EAP-TLS/TTLS        January 2026

   A new path component is defined under the EST well-known URI:

   GET /.well-known/est/eapclientcertchain

   The '/eapclientcertchain' is intended for informational retrieval
   only and does not require client authentication.  It allows EAP
   server to retrieve the intermediate certificate chain that the EAP
   clients present during TLS handshakes.  This request is performed
   using the HTTPS protocol.  The EST server MUST support requests
   without requiring client authentication.  The certificate chain
   provided by the EST server MUST be the same certificate chain EAP
   clients use in the EAP-TLS or EAP-TTLS session.

   EAP servers and clients are RECOMMENDED to cache retrieved
   certificate chains to reduce latency and network overhead.  However,
   they SHOULD implement mechanisms to detect changes or expiration.
   These include periodic re-fetching, honoring HTTP cache control
   headers (e.g., Cache-Control, ETag), and verifying the validity
   period of intermediate certificates.

   As an alternative, a device MAY attempt to retrieve the certificate
   chain from the EST server (e.g., /eapservercertchain or
   /eapclientcertchain) only when certificate validation fails during an
   EAP-TLS or EAP-TTLS handshake.  While this on-demand retrieval can
   serve as a fallback to recover from outdated intermediate
   certificate, it has the drawback of delaying authentication.

   After retrieving intermediate certificates via EST, a EAP client that
   believes it has a complete set of intermediate certificates to
   authenticate the EAP server sends the tls_flags extension as defined
   in [I-D.kampanakis-tls-scas-latest] with the 0xTBD1 flag set to 1 in
   its ClientHello message.  Similarly, a EAP server that believes it
   has a complete set of intermediate certificates to authenticate the
   EAP client sends the same tls_flags extension with 0xTBD1 set to 1 in
   its CertificateRequest message.  In both cases, only the end-entity
   certificates will be provided by the EAP client and server during the
   TLS handshake, relying on the recipient to possess or retrieve the
   necessary intermediate certificates for certificate chain validation.

6.  Security Considerations

   The security considerations outlined in [I-D.ietf-uta-pqc-app] and
   [I-D.ietf-pquip-pqc-engineers] must be carefully evaluated and taken
   into account for both EAP-TLS and EAP-TTLS deployments.

Reddy                     Expires 28 July 2026                  [Page 7]
Internet-Draft      PQC Enhancements to EAP-TLS/TTLS        January 2026

7.  IANA Considerations

   This document does not request the creation of a new IANA registry
   nor the registration of the two URI path components defined in
   Section 5.

Acknowledgements

   TBA.

References

Normative References

   [I-D.ietf-uta-pqc-app]
              Reddy.K, T. and H. Tschofenig, "Post-Quantum Cryptography
              Recommendations for TLS-based Applications", Work in
              Progress, Internet-Draft, draft-ietf-uta-pqc-app-00, 18
              September 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-uta-pqc-app-00>.

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

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/rfc/rfc7030>.

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

   [RFC8295]  Turner, S., "EST (Enrollment over Secure Transport)
              Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018,
              <https://www.rfc-editor.org/rfc/rfc8295>.

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

Informative References

Reddy                     Expires 28 July 2026                  [Page 8]
Internet-Draft      PQC Enhancements to EAP-TLS/TTLS        January 2026

   [I-D.ietf-pquip-pqc-engineers]
              Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
              T., and M. Ounsworth, "Post-Quantum Cryptography for
              Engineers", Work in Progress, Internet-Draft, draft-ietf-
              pquip-pqc-engineers-14, 25 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-14>.

   [I-D.ietf-pquip-pqt-hybrid-terminology]
              D, F., P, M., and B. Hale, "Terminology for Post-Quantum
              Traditional Hybrid Schemes", Work in Progress, Internet-
              Draft, draft-ietf-pquip-pqt-hybrid-terminology-06, 10
              January 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-pquip-pqt-hybrid-terminology-06>.

   [I-D.kampanakis-tls-scas-latest]
              Kampanakis, P., Bytheway, C., Westerbaan, B., and M.
              Thomson, "Suppressing CA Certificates in TLS 1.3", Work in
              Progress, Internet-Draft, draft-kampanakis-tls-scas-
              latest-03, 5 January 2023,
              <https://datatracker.ietf.org/doc/html/draft-kampanakis-
              tls-scas-latest-03>.

   [RFC9191]  Sethi, M., Preuß Mattsson, J., and S. Turner, "Handling
              Large Certificates and Long Certificate Chains in TLS-
              Based EAP Methods", RFC 9191, DOI 10.17487/RFC9191,
              February 2022, <https://www.rfc-editor.org/rfc/rfc9191>.

Author's Address

   Tirumaleswar Reddy
   Nokia
   Bangalore
   Karnataka
   India
   Email: k.tirumaleswar_reddy@nokia.com

Reddy                     Expires 28 July 2026                  [Page 9]