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

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

> On Jul 26, 2023, at 10:09, Alan DeKok <[e-mail]> wrote:
> 
>  Some suggested text on CUI:
> 
> Where the Chargeable-User-Identifer (CUI) {{?RFC4372}} is used, it Chargeable-User-Identifer SHOULD be unique per session.  This pracrice will help to maximize user privacy, as it will be more difficult to track users across multiple sessions.  Due to additional constraints which we will discuss below, we cannot require that the CUI change for ecery session.
> 
> What we can do is require that the home server MUST provide a unique CUI for each combination of user and visited network.  That is, if the same user visits multiple networks, the home server MUST provide different CUIs to each visited network for that user.  The CUI MAY be the same across multiple sessions for that user on one particular network.  The CUI MAY be the same for multiple devices used by that user on one particular network.
> 
> We note that the MAC address is likely the same across multiple user sessions on one network.  Therefore changing the CUI offers little additional benefit, as the user can still be tracked by the unchanging MAC address.  Never the less, we believe that having a unique CUI per session can be useful, because there is ongoing work on increasing user privacy by allowing more MAC address randomization.  If we were to recommend that the CUI remain constant across multiple sessions, that would in turn negate much of the effort being put into MAC address randomization.
> 
> One reason to have a constant CUI value for a user (or user devices) on one network is that network access providers may need to enforce limits on simultaneous logins.  Network providers may also need to correlate user behavior across mutliple sessions in order to track and prevent abuse.  Both of these requirements are impossible if the CUI changes for every user session.
> 
> The result is that there is a trade-off between user privacy and the needs of the local network.  While perfect user privacy is an admirable goal, perfect user privacy may also allow anonymous users to abuse the visited network.  The network would then likely simply refuse to provide network access.  Users may therefore have to accept some limitations on privacy, in order to obtain network access.

That text seems reasonable to me.

The frustrating thing here is you can't tell what the Home Server is doing.  Is it assigning new CUIs on every auth, or are they stable?  I know it's out of scope for this doc, but it seems like assigning tags for both the requested CUI type and the provided CUI type would be useful, then Access Providers that care more about privacy than blocking and tracking users can advertise that fact.

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.

-Arran