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

[[e-mail]]

I agree with Alex.

In particular, I don't think we need to prescribe what value the CUI should
take. That is configuration, and the value of that attribute should be
controlled by business agreement.

I do think it would be valuable to describe the privacy implications of CUI
and the algorithms that can be used to generate privacy-preserving CUI
values.

Josh

> -----Original Message-----
> From: Alexander Clouter <[e-mail]>
> Sent: Wednesday, July 26, 2023 4:54 PM
> To: Alan DeKok <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: [radext] CUI comments in "deprecating insecure transports"
> 
> 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