| Internet-Draft | Protocol-Error | October 2026 |
| DeKok | Expires 25 April 2027 | [Page] |
This specification documents implementation issues with TLS 1.3 session tickets, and provides guidance to correct the problems. Problems related to PQC is also discussed in relation to TLS-based EAP methods. A partial solution to those issues is also proposed.¶
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-dekok-emu-tls-tickets/.¶
Discussion of this document takes place on the EMU Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/.¶
Source for this draft and an issue tracker can be found at https://github.com/InkbridgeNetworks/eap-tls-tickets.git.¶
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 April 2027.¶
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.¶
EAP-TLS was extended to use TLS 1.3 ([RFC9846]) in [RFC9190]. Other TLS-based EAP methods were updated to support TLS 1.3 in [RFC9427]. These specifications resulted in interoperable implementations, but the specifications appear to have missed corner cases related to session tickets, which are allowed by TLS 1.3.¶
This document explains what those issues are, and gives guidance for addressing them.¶
This document then discusses issues with PQC certificates, and extends the above guidance to show how careful use of session tickets can address many practical problems that are seen with PQC certificates.¶
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.¶
TLS 1.2 sends session tickets in the TLS header. TLS 1.3 does not. It appears that implementers (supplicants and servers) all assumed that TLS 1.3 session tickets would then be sent and received immediately after the TLS header negotiation was finished.¶
However, this assumption has a few problems. The first problem is that TLS 1.3 allows for session tickets to be sent at any time after the TLS negotiation has completed. It appears that no EAP implementation supports this behavior.¶
The second problem is that TLS 1.3 allows for stateless session tickets. i.e. session tickets where the server does not maintain any local state. To be clear, there is no issue with stateless session tickets themselves, but stateless session tickets interact badly with the first problem noted above.¶
If a server sends session tickets before the phase 2 (inner tunnel) authentication has completed, then an attack is possible. This issue is noted in [RFC9427], Section 3, which says:¶
Therefore, the EAP server MUST NOT permit any session ticket to successfully resume authentication unless the inner tunnel authentication has completed successfully. The alternative would allow an attacker to bypass authentication by obtaining a session ticket, immediately closing the current session, and "resuming" using the session ticket.¶
The text in [RFC9427], Section 3 further suggests:¶
implementations SHOULD NOT send NewSessionTicket messages until the "inner tunnel" authentication has completed.¶
Recent interoperability checks indicate that few (if any) EAP peers or servers implemented this suggestion. In fact, some peer implementations may misbehave if they receive a session ticket after "inner tunnel" authentication succeeds.¶
This specification does not change the requirements of [RFC9427]. Instead, it serves to highlight the fact that this issue is a problem.¶
EAP peer implementations MUST be updated to behave properly when they receive session tickets after "inner tunnel" authentication has succeed.¶
In order to avoid problems with shipping EAP peer implementations, EAP server implementations SHOULD send session tickets immediately after the TLS handshake has completed.¶
However, this behavior highlights another problem¶
If an EAP server sends a stateless session ticket before inner-tunnel authentication succeeds, it still must satisfy the requirements noted above in [RFC9427].¶
The only practical way to do this is to maintain state, even for stateless session tickets.¶
Further discussion is necessary here.¶
There is ongoing discussion in multiple standards bodies about the problem seen with PQC certificates. These certificates can be large.¶
Rough numbers show that PQC certs may require 80+ round trips between the EAP peer and server. This behavior has a number of negative implications:¶
many APs and servers have hard-coded limits on the number of EAP round trips (e.g. hostap is 50-100, FreeRADIUS is similar). This limitation is there to prevent attackers from using EAP methods to exchange large amounts of data in EAP. This limit is likely to negatively affect PQC certs.¶
Real-world research [DELAY] measured trans-continent RTT in eduroam. Rough numbers show that each round trip adds latency in a linear fashion:¶
The total wall-clock time follows a linear function T=n RTT + b quite well, where n is an integer (7 and 8 in the example above) and b is 70-90 ms in our lab setup.¶
For PQC certs which take 80 round trips, this delay can be six (6) seconds or more. This delay is unacceptable.¶
There are proposals which partially address this issue. One is to allow the AP to fragment / reassemble the EAP data, which reduces the number of round trips over RADIUS. However, this reassembly results in large RADIUS packets (8K or more), which is likely impossible to require in a roaming environment with multiple proxies.¶
The previous TLS-based EAP specifications (and implementations) assumed that possession of a session ticket allowed the EAP peer to skip phase 2 authentication. This assumption does not appear to have been explicit in any specification.¶
The attacks noted above in [RFC9427] are a direct result of that assumption.¶
Both the above attack and the PQC issues can be avoided simply by separating the relationship between session tickets and phase 2 authentication. That is, implementations can instead use session tickets do skip the certificate exchange, and then still do the full phase 2 authentication.¶
Since the phase 2 authentication is still done, it is possible to issue new session resumption tickets essentially forever. The limitations are only:¶
policy on the server can require a full certificate exchange. This should be done only when the EAP peer is known to be in the "home" network.¶
the session tickets should be issued only during the lifetime of any client certificate. After a client certificate expires, it should be re-provisioned.¶
authentication (and thus resumption) can be refused if the phase 2 authentication fails, such as when the users account is removed, or when their password has been changed.¶
In practice, the above approach means that the full PQC certificate exchange can be done in the "home" network. Since it is the home network, there will be no issues related to proxying, or proxy delay. The home network is also free to set large MTU for RADIUS packets.¶
Once the EAP peer performs the full certificate checks and is authenticate, the above process can be used for future authentications.¶
The "session tickets skip certificate checks" process really has nothing to do with TLS 1.3. It can be done for TLS 1.2, also.¶
Plus, this process solves a long-standing issue with TLS-based EAP methods: the full certificate chain must be exchanged on every authentication.¶
There are some implementation caveats. Ideally, both EAP peer and serer implementations should be able to automatically detect this new behavior, and proceed with either possibility, without requiring configuration changes.¶
This detection appears to be possible, at least with TLS 1.3. The process then goes as follows:¶
The EAP peer and server agree to perform session resumption. This packet flow is shown in [RFC9190], Section 2.1.5 Figure 7,¶
If the server is willing to bypass Phase 2, it sends a one octet protected success indicator.¶
2.1 If the EAP peer chooses to skip Phase 2, it follows [RFC9190], Section 2.1.4 Figure 7, and sends an EAP-Response/ EAP-Type=EAP-TLS. The server replies with EAP-Success.¶
2.2 If the EAP peer chooses to do Phase 2 authentication, it instead sends Phase 2 data. The server then follows the normal Phase 2 process to authenticate the peer.¶
If the server instead requires full Phase 2 authentication, then it does not send the one octet protected success indicator.¶
3.2 The EAP peer sees that there is no protected success indicator, and initiates Phase 2.¶
3.3 If the EAP peer instead sends an EAP-Response/ EAP-Type=EAP-TLS (as in 2.1 above), that message contains no Phase 2 data. The server then knows that the peer is unwilling to do Phase 2, which forces the server to respond with EAP Failure.¶
This document has no IANA considerations.¶
None.¶
Lots.¶
This document came out of discussions with Jouni Malinen, Karri Huhtanen, and others.¶