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

[Alexander Clouter <[e-mail]>]

On Wed, 26 Jul 2023, at 19:01, Arran Cudbard-Bell wrote:
> Regarding session tickets for TLS 1.3 there's a ticket_nonce (and the 
> blob itself), but I'm fairly sure it's not sent in the clear by the 
> server?
>
>    - All handshake messages after the ServerHello are now encrypted.
> The newly introduced EncryptedExtensions message allows various
> extensions previously sent in the clear in the ServerHello to also
> enjoy confidentiality protection.
>
> SessionTickets and SessionIDs were sent in the clear with TLS <= 1.2.

As a visited site I am not looking to block the home sites RADIUS server (I can do that on the realm) I am looking to block the client.

The contents of the 'pre_shared_key' extension in TLSv1.3 of the ClientHello is what I would block on. Any 'opaque' bit is there, sure I cannot decode but I do not care as I would be treating it as a stable 

Once I see abuse I would grab the value seen when that user last authenticated and block on that.

Of course the server could punt a new ticket each time to the client effectively making them single use; as long as it has the smarts to know to burn previous used tokens but that can be an exotic deployment for some sites.

The workaround for the workaround is to then forcible disconnect the user and capture the currently in use ticket and continue blocking based on that.

That said, there is likely to be a stable mapping of Calling-Station-Id to this ticket, making it questionable if this effort would even be worth it when a ticket is valid for a short period and the MAC address is likely stable for a given network across sessions.

Cheers