Re: [radext] CUI comments in "deprecating insecure transports"

[Arran Cudbard-Bell <[e-mail]>]

> On Jul 26, 2023, at 11:29, Alexander Clouter <[e-mail]> wrote:
> 
> On Wed, 26 Jul 2023, at 17:20, Alan DeKok wrote:
>>> They can always block based on the TLS session resumption materials.
>> 
>> Is the session ticket sent in the clear?  I'm not sure how a visited
>> network would block based on the ticket.
> 
> SessionTicket is there in the clear of the ClientHello, right? You cannot read the opaque part, but it is a stable identifier for about 24 hours.

Largely true for TLS < 1.3, but with TLS 1.3 all bets are off.

A new session ticket can be sent during session resumption (I think FreeRADIUS does this by default, at least in v4), and multiple session tickets can be issued per authentication attempt.  RFC8446 also describes single use tickets as an anti-replay defence.  In order to use this as a reliable cross-session identifier you'd need to be able to observe the session tickets being sent by the server, which you can't do with TLS 1.3.

RFC8446 is silent on what TLS clients should do when receiving new session tickets, but you'd hope any reasonable implementation would discard tickets from previous authentication attempts.

EAP-SIM/EAP-AKA/EAP-AKA' can all mutate or regenerate their Pseudonym and Fast-Reauth identities on every authentication attempt whether it's resumed or not, but the new values are always sent within AT_ENCR_DATA which is opaque to eavesdroppers, and so defeats tracking.

Anyway, just to make the point that privacy won't automatically be compromised by TLS or AKA based EAP methods when performing session-resumption.

-Arran