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

[Heikki Vatiainen <[e-mail]>]

On Wed, 26 Jul 2023 at 22:15, Arran Cudbard-Bell <a.cudbardb=
[e-mail]> wrote:


> > On Jul 26, 2023, at 11:29, Alexander Clouter <[e-mail]>
> wrote:
>
> > 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.
>

New ticket with each resumption appears to be what OpenSSL does by default.
Based on what I've seen with TLSv1.3: initialise the SSL context with
number of tickets set to 1 (as suggested by EAP-TLSv1.3 RFC 9190, section
2.1.2) and when a client authenticates with a full TLS handshake, they get
one new ticket. When they resume, they get another new ticket. The
subsequent resumptions then all hand out one new ticket. The new ticket
server sends is encrypted.

I think session tickets with EAP in TLSv1.2 are not supported, but tracking
the server based resumption ClientHello SessionID would work with TLSv1.2
and earlier.


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

With the SIM based EAP method, there's also this specification from the
Wireless Broadband Alliance:
https://wballiance.com/resource/imsi-privacy-protection-for-wi-fi/

This allows the EAP client to encrypt its IMSI (basis of its EAP Identity)
even with the first authentication. This uses a client configuration which
can also be set so that the client never sends out its IMSI without
encryption, no matter what the EAP server requests.

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

Agreed.

-- 
Heikki Vatiainen
[e-mail]