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

[Alexander Clouter <[e-mail]>]

On Wed, 26 Jul 2023, at 16:16, Alan DeKok wrote:
> The intent of CUI was that if a user was abusive, the visited network
> could report the CUI to the IdP.  The IdP would then block the user.
> While this isn't perfect, it provides for better user privacy.

I disagree, not just because of my views on this, but I can quote straight from the introduction of RFC4372:

"For example, local or intermediate networks may limit the number of simultaneous sessions for specific users; they may require a Chargeable-User-Identity in order to demonstrate willingness to pay or otherwise limit the potential for fraud."

So this can, and I would argue should, not only be the same CUI across multiple sessions but also multiple devices.

If this was purely for the reasons of managing abuse, the visited site could just report the timestamp with the Calling-Station-Id and call it a day; similarly to how IP network abuse is reported with a timestamp with source IP/port (I do not miss the .

That said, CUI *allows* for this, there is no reason for a federation to provide this level of reconciliation.

>From my previous life being an eduroam jockey, I did have an expectation[1] that CUI was a *user* identifier that if I blocked *all* devices for a short (eg. days) duration of that user would be denied.

>   Where there is a trade-off around user privacy, I would lean towards 
> keeping user privacy at the cost of increased effort in the network.

They can always block based on the TLS session resumption materials.

>   I'll see if I can update the wording to suggest that the CUI can be 
> static for one visited / home network relationship, provided they both 
> agree to this.  But generally it's better to have it different for 
> every session.

Maybe lets include some recommended strategies for an IdP/homesite to generate a CUI and along with the benefits and disadvantages of each.

For example did we want to recommend that a CUI is stable for say 24 hours and if so the describe how to go about doing that and more importantly how not to do that; such as "please do not mix in the MAC address or the time with less than day resolution".

>   The issue of CUI changing is made a little less relevant by the fact 
> that the MAC address doesn't change for one visited network (SSID, 
> etc).  So the visited network can always correlate MACs across sessions.

My laptop is setup to be an arse, so it does for me it does...that will learn them for having a high DHCP lease time :)

Cheers

[1] https://community.jisc.ac.uk/library/janet-services-documentation/chargeable-user-identity-eduroam-freeradius-implementation