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

[Alan DeKok <[e-mail]>]

On Jul 26, 2023, at 8:54 AM, Alexander Clouter <[e-mail]> wrote:
> 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.

  I think that's implied, yes.  But not stated explicitly.  :(

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

  Is the session ticket sent in the clear?  I'm not sure how a visited network would block based on the ticket.

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

  Yes.  I'll add that.

> 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".

  Sure.

  Over all, I think user privacy conflicts directly with the desire of the visited network to enforce local policies.  Off of the top of my head, the only way I can think to address this is for the visited network to inform the home server of it's policies,  The home server can then apply and enforce those policies.

  That being said, none of this is possible in RADIUS today.  There is no attribute which says "please limit simultaneous logins to N", or anything similar.  This kind of extension would be necessary in order to get full user privacy at the visited network.

  I'll update the doc with issues and trade-offs.  There isn't much else we can do at this point.

  Alan DeKok.