EAP Method Update T. Reddy Internet-Draft Nokia Intended status: Standards Track 21 September 2026 Expires: 25 March 2027 Post-Quantum Enhancements to TLS-Based EAP Methods draft-ietf-emu-pqc-eap-tls-01 Abstract This document specifies the use of post-quantum cryptography in TLS- based EAP methods, including the Extensible Authentication Protocol with Transport Layer Security (EAP-TLS), EAP Tunneled TLS (EAP-TTLS), Protected EAP (PEAP), and EAP Tunnel Method (TEAP). It also addresses challenges related to large certificate sizes and long certificate chains, as identified in [RFC9191], and specifies a mechanism to reduce TLS handshake size. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-emu-pqc-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 25 March 2027. Reddy Expires 25 March 2027 [Page 1] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 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 TLS-Based EAP Methods . . . . . . . . 4 4. Post-Quantum Authentication in TLS-Based EAP Methods . . . . 5 5. EST Integration . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The emergence of a Cryptographically Relevant Quantum Computer (CRQC) would break the mathematical assumptions that underpin 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 [RFC9958], and the NIST PQC Standardization process has initially selected algorithms such as ML-KEM [FIPS203], ML-DSA [FIPS204], and SLH-DSA [FIPS205] 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) attacks, where adversaries capture encrypted traffic today with the intent to decrypt it once CRQCs become available. TLS-based EAP methods are Reddy Expires 25 March 2027 [Page 2] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 widely used for network access authentication in enterprise and wireless environments. This document applies to all EAP methods that use TLS as their underlying transport, including EAP-TLS [RFC9190], EAP-TTLS [RFC5281], PEAP, and TEAP [RFC7170]. To continue providing long-term confidentiality and authentication guarantees, these methods 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 document specifies post- quantum key agreement and authentication requirements for TLS-based EAP methods, together with a mechanism that reduces TLS handshake size for use 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 [RFC9794]. 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 25 March 2027 [Page 3] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 - Hybrid Key Exchange: A key exchange mechanism that combines two component algorithms o 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 the context of a secure communication establishment. 3. Data Confidentiality in TLS-Based EAP Methods One of the primary threats to TLS-based EAP methods 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 an HNDL 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). Reddy Expires 25 March 2027 [Page 4] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 In the case of EAP-TTLS, PEAP, and TEAP, HNDL attacks present an additional threat. These methods typically carry legacy inner authentication protocols within the outer TLS tunnel, such as MS- CHAPv2. If a CRQC is used to break the outer TLS tunnel, the exposed inner authentication exchange could enable offline password attacks, potentially allowing an adversary to recover user credentials. To protect against HNDL attacks, TLS-based EAP deployments that require long-term confidentiality MUST use TLS 1.3 [RFC9846] and MUST negotiate a post-quantum or PQ/T hybrid key agreement group. Traditional key agreement groups alone do not provide long-term confidentiality against an adversary equipped with a CRQC. EAP peers and EAP servers MUST support at least one post-quantum or PQ/T hybrid key agreement group registered in the "TLS Supported Groups" registry. PQ/T hybrid groups combining ML-KEM with ECDHE are constructed as described in [RFC9954] and registered in [RFC10024]. This document does not mandate a specific group. The Recommended column of the "TLS Supported Groups" registry, defined in [RFC9847], records current IETF guidance on the use of registered groups. At the time of writing, X25519MLKEM768 (code point 4588) is the only PQ/ T hybrid group marked Recommended. PQ/T hybrid key agreement is generally preferred, because the shared secret remains secure as long as either component algorithm remains unbroken [RFC9794]. Standalone ML-KEM key agreement may be required for deployments subject to regulatory or compliance mandates that require exclusive use of post-quantum cryptography. The choice is a deployment decision and is out of scope for this document. 4. Post-Quantum Authentication in TLS-Based EAP Methods 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. Reddy Expires 25 March 2027 [Page 5] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 TLS-based EAP 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, TLS-based EAP deployments that require resistance to future CRQCs MUST support at least one post-quantum or PQ/T hybrid signature scheme registered in the "TLS SignatureScheme" registry for authentication. ML-DSA [FIPS204] is specified for use in X.509 certificates in [RFC9881] and for authentication in TLS 1.3 in [I-D.ietf-tls-mldsa]. This document does not mandate a specific signature scheme or parameter set. The Recommended column of the "TLS SignatureScheme" registry, defined in [RFC9847], records current IETF guidance on the use of registered schemes. PQ/T hybrid authentication using composite signatures may be preferred by deployments seeking defense in depth during the transition, so that authentication remains secure as long as either component algorithm remains unbroken. Composite ML-DSA is specified for X.509 in [I-D.ietf-lamps-pq-composite-sigs] and for TLS 1.3 in [I-D.reddy-tls-composite-mldsa]. The choice between pure post- quantum and PQ/T hybrid authentication is a deployment decision and is out of scope for this document. The relatively large SLH-DSA [FIPS205] signatures may make SLH-DSA less suitable for TLS-based EAP deployments, particularly where handshake size and fragmentation are significant constraints. Signature sizes are given in [RFC9958]. The end-entity certificate and the CertificateVerify each carry a signature in every handshake, and neither can be avoided by the mechanism in Section 5, which removes only intermediate certificates. Reddy Expires 25 March 2027 [Page 6] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 A post-quantum or PQ/T hybrid end-entity certificate does not by itself provide post-quantum authentication. Every signature in the path up to the trust anchor has to use a post-quantum or PQ/T hybrid scheme, and since the trust anchor is provisioned out of band, it has to be in place before the certificates that chain to it are issued. 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. Section 5 describes mitigations. 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 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. Certificate compression [RFC8879] provides limited benefit for certificates containing large high-entropy post-quantum public keys and signatures, and session resumption requires a prior full handshake. Out-of-band provisioning of the intermediate chain can avoid transmitting it during the first TLS authentication of a newly provisioned device. To further reduce handshake overhead, particularly in deployments using large certificate chains due to post-quantum (PQ) or composite certificates, this document specifies 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 TLS handshake. For EAP methods that use TLS as an outer tunnel (e.g., PEAP and TEAP), the EST optimization described in this section applies to the certificates used in the outer TLS tunnel. The EST pre-fetching of client intermediate certificates is relevant only when mutual TLS authentication is used. This is always the case for EAP-TLS, and optionally the case for EAP-TTLS and TEAP when client certificate authentication is used in the outer tunnel. Reddy Expires 25 March 2027 [Page 7] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 This section defines extensions to EST to support retrieval of the certificate chain used by an EAP server and EAP clients. The first extension enables EAP clients to retrieve the intermediate certificates required to build a certification path to the EAP server's end-entity certificate. 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 EST server MUST provide the intermediate certificates of the CAs that issue EAP server certificates. The second extension enables EAP servers to retrieve the intermediate certificates required to build a certification path to the EAP clients' end-entity certificates. 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. 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 the 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 EST server MUST provide the intermediate certificates of the CAs that issue EAP client certificates. Retrieved intermediate certificates are used for certification path construction together with any certificates received in the TLS handshake. Where an EAP server has certificates issued by more than one CA, the retrieved intermediate certificates cover all of them, and the EAP client selects those needed to construct a path for the certificate presented in the handshake. If no valid path can be constructed, authentication fails as for any other certificate validation failure. Reddy Expires 25 March 2027 [Page 8] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 EAP clients and servers MUST authenticate the EST server using a trust anchor obtained via a suitable bootstrapping mechanism before retrieving intermediate certificate chains via HTTPS. Various bootstrapping mechanisms exist for establishing this trust, such as BRSKI [RFC8995], EST [RFC7030], or out-of-band provisioning. The choice of bootstrapping mechanism is a deployment decision and is out of scope for this document. Certificate chains retrieved from an unauthenticated or untrusted EST server MUST NOT be used for TLS chain validation. 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. EAP clients MAY omit intermediate certificates from the TLS handshake only if they have been explicitly configured by the administrator to do so. Such configuration is recommended only in deployments where both the EAP client and EAP server support this specification and have completed EST pre-fetching as part of provisioning. If no such configuration is present, the EAP client MUST include the full certificate chain in the TLS handshake. Similarly, an EAP server MAY omit intermediate certificates from the TLS handshake only if it has been explicitly configured by the administrator to do so. Administrators are advised to ensure that clients in the deployment have retrieved the server's intermediate certificates via EST as part of their provisioning process before enabling this configuration. EST is one transport for retrieving intermediate certificates out of band. Device management systems can deliver the same chains, and TEAP [RFC7170] could be extended to provision them within the tunnel it establishes. Note: A TLS extension could be used to explicitly signal support for intermediate certificate omission between peers, avoiding the need for administrator configuration. Such a mechanism is considered a possible future solution but is out of scope for this document. 6. Security Considerations The security considerations outlined in [I-D.ietf-uta-pqc-app] and [RFC9958] must be carefully evaluated and taken into account for all TLS-based EAP deployments. Reddy Expires 25 March 2027 [Page 9] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 7. IANA Considerations This document defines two new path components under the EST well- known URI '/.well-known/est/', following the extension mechanism established by [RFC8295]: '/eapservercertchain' and '/eapclientcertchain'. As these are sub-paths under the already- registered '/.well-known/est/' prefix defined in [RFC7030], no new IANA registry entries are required. Acknowledgements Thanks to John Mattsson, Hannes Tschofenig, Alan DeKok and Michael Richardson for the discussion and comments. References Normative References [I-D.ietf-tls-mldsa] Hollebeek, T., Schmieg, S., and B. Westerbaan, "Use of ML- DSA in TLS 1.3", Work in Progress, Internet-Draft, draft- ietf-tls-mldsa-06, 11 September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8295] Turner, S., "EST (Enrollment over Secure Transport) Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, . [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, . Reddy Expires 25 March 2027 [Page 10] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . [RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025, . [RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, October 2025, . [RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July 2026, . [RFC10024] Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., and D. Stebila, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3", RFC 10024, DOI 10.17487/RFC10024, August 2026, . Informative References [FIPS203] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, 2024. [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS 204, 2024. [FIPS205] National Institute of Standards and Technology (NIST), "Stateless Hash-Based Digital Signature Standard", FIPS 205, 2024. [I-D.ietf-lamps-pq-composite-sigs] Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S. Fluhrer, "Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure", Work in Progress, Internet-Draft, draft- ietf-lamps-pq-composite-sigs-19, 21 April 2026, . Reddy Expires 25 March 2027 [Page 11] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 [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-03, 4 July 2026, . [I-D.reddy-tls-composite-mldsa] Reddy.K, T., Hollebeek, T., Gray, J., Fluhrer, S., and D. Van Geest, "Use of Composite ML-DSA in TLS 1.3", Work in Progress, Internet-Draft, draft-reddy-tls-composite-mldsa- 12, 31 August 2026, . [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, DOI 10.17487/RFC5281, August 2008, . [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, . [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate Compression", RFC 8879, DOI 10.17487/RFC8879, December 2020, . [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, . [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, . [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, . Reddy Expires 25 March 2027 [Page 12] Internet-Draft PQC Enhancements to TLS-Based EAP Method September 2026 [RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek, T., and M. Ounsworth, "Post-Quantum Cryptography for Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026, . Author's Address Tirumaleswar Reddy Nokia Bangalore Karnataka India Email: k.tirumaleswar_reddy@nokia.com Reddy Expires 25 March 2027 [Page 13]