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

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.

Josh

> -----Original Message-----
> From: radext <radext-bounces@ietf.org> On Behalf Of Alan DeKok
> Sent: Tuesday, July 25, 2023 1:32 AM
> To: radext@ietf.org
> Subject: [radext] CUI comments in "deprecating insecure transports"
> 
>   I've been adding text to the "deprecating insecure transports" document
> based on feedback from Margaret.  In addition to deprecating UDP/TCP in
> certain situations, the document should also discuss best practices for
securing
> RADIUS, and minimizing personally identifying information.
> 
>   To that end, in Madinas today Warren Kumari gave a presentation on
testing
> OpenRoaming  One of the outcomes was that the identity provider returned a
> CUI. However, that CUI was unchanged over multiple sessions, and over long
> periods of time.
> 
>   The CUI RFC (4372) implies that the CUI should change regularly:
> 
>    When the home network assigns a value to the CUI, it asserts that
>    this value represents a user in the home network.  The assertion
>    should be temporary -- long enough to be useful for the external
>    applications and not too long such that it can be used to identify
>    the user.
> 
>   And
> 
>       The
>       binding lifetime of the reference to the user is determined based
>       on business agreements.  For example, the lifetime can be set to
>       one billing period.
> 
>   However, this text allows the CUI to remain unchanged based on "business
> agreements".
> 
>   It is perhaps useful to update this document to suggest more strongly
that
> the CUI change on every session.  This could be done as part of a "best
> practices" section for increasing RADIUS security.
> 
>   Alan DeKok.
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext