Session Tickets in TLS-Based Extensible Authentication Protocol (EAP)

Introduction EAP-TLS was extended to use TLS 1.3 () in . Other TLS-based EAP methods were updated to support TLS 1.3 in . 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.

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 when, and only when, they appear in all capitals, as shown here.

TLS 1.3 and Session Tickets 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.

Session Tickets and Authentication 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 , 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 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 . 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

Stateless Session Tickets and State If an EAP server sends a stateless session ticket before inner-tunnel authentication succeeds, it still must satisfy the requirements noted above in . The only practical way to do this is to maintain state, even for stateless session tickets. Further discussion is necessary here.

PQC and TLS-based EAP methods 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 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.

Session Tickets can help avoid PQC issues. 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 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.

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

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

IANA Considerations This document has no IANA considerations.

Privacy Considerations None.

Security Considerations Lots.

Acknowledgements This document came out of discussions with Jouni Malinen, Karri Huhtanen, and others.