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

["Mark Grayson (mgrayson)" <[e-mail]>]

Whereas there is text on binding-lifetime for CUI, does there need to be equivalent discussion around the use of user-name re-write and class attribute?

Cheers,
Mark

From: radext <[e-mail]> on behalf of Alan DeKok <[e-mail]>
Date: Wednesday, 26 July 2023 at 16:17
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [radext] CUI comments in "deprecating insecure transports"
On Jul 26, 2023, at 5:58 AM, <[e-mail]> <[e-mail]> wrote:
>
> There are good reasons for the CUI value to be persistent, provided that it
> is targeted to each network access provider. In this way, different
> providers cannot collude to track users. However, they still maintain the
> ability to *recognise* (but not identify) the same user that they saw
> previously.
>
> There are legitimate reasons to track and, if necessary, identify users,
> including troubleshooting and prevention of service abuse.

  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.

  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.

  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.

  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.

  But for me, this is about nibbling away at the privacy bits one problem at a time.  At some point, MADINAS will perhaps allow MACs to be changed per session, and then that problem will go away.  And the CUI will already be different per session (usually).  So we won't have to go back and fix it again.

  Alan DeKok.

_______________________________________________
radext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/radext