Hi,

In regards to the CUI & eduroam:

From what I can tell, CUI can transit eduroam. Transiting and being
offered are two different things though.
The eduroam policy service definition document[1] describes it, but not
all eduroam sites follow the EU service definition document.
It is worth noting though that on on page 31, section 6.3.2 and quite a
ways down, the generation of CUI is only recommended and not required.

When it is generated it must be opaque to anyone but the IdP populating it:
 
Excerpt from page 31:

The value of Chargeable-User-Identity attribute MUST be generated in a way
which ensures that the matching of this value to the actual user identity
is possible only at the Identity Provider.



So, does the intended use of CUI in Moonshot match how CUI is implemented?
For those eduroam RADIUS servers that configure it to be offered of course.

I am also concerned about the use of CUI and impersonation risks. RFC 4372
comments that the client returns the attribute back on accounting requests
and to me there is no certainty that the CUI is not altered or can be
detected as altered.



Chris.



[1] 
https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-de
finition_ver28_26072012.pdf

On 14-03-13 9:00 AM, "Sam Hartman" <[log in to unmask]> wrote:

>I agree that guidance is what we want here.
>People are going to have different requirements and explore things.
>
>I for example had not considered the risks of CUI before.
>
>As I understand it from RADIUS:
>
>CUI is intended to provide a way of corrilating usage for accounting and
>billing while obscuring identity.
>
>Authorization was not considered.  Also, I suspect to a large extent IDP
>impersonation was not considered because for accounting most of the
>accounting info will be directed back towards the IDP anyway.
>
>This means that when we consider authorization in scope, we need to
>defend against one IDP impersonating another.
>
>--Sam