eduroam and CUI

What is CUI?

CUI is a Chargeable User Identity and is specified in RFC 4372.  A CUI is a unique identifier for a user which remains static for a given user visiting a given site.  What do I mean by that? When a user visits a site their CUI will always be the same regardless of their outer identity or which device they use to login.  In effect the CUI is an obscured version of the users real username.

How is the CUI useful?

In the world of eduroam (and 802.1X in general) when a user visits another site, the only information a site has to identify the user is their outer identity and their calling station id (mac address).  This can often make it difficult to know how many visitors a site has.  For example you could have 10 users all using eduroam with the outer identity anonymous@eduroam.ac.uk.  However, is that really 10 different users or is it a single user on 10 different devices, or 5 users with 2 devices each etc.  CUI solves this as each unique user has a different CUI (but the CUI is the same across different devices).

A CUI can also help with accountability.  If you have a visitor who breaks your AUP and you decide to ban them, how do you enforce this ban.  You can't ban the outer identity because the user can change that to whatever they like, and you are likely to end up blocking other innocent users.  If you ban the CSI the user could just login on another device or spoof their CSI.  By having a CUI you can definitively identify the user and block them based on CUI.  Additionally, if you do have an AUP issue when contacting the home site a CUI provides a more reliable link to the user than a CSI which could be spoofed.

How do I request a CUI for a user?

If you require a CUI for a user, you simply attach RADIUS attribute 89 (Chargeable-User-Identity) with a NULL value to the Access-Request.

However, here is the problem.  The site authenticating the request should, upon receipt of a NUL Chargeable-User-Identity, generate the CUI value and return it in the subsequent replies.  Therefore if the IdP hasn’t configured their RADIUS server to respond to CUI requests, you won’t get back a CUI.

If you do get back a CUI for a user, you must then include this in your accounting packets and not modify the value.

How do I generate a CUI for a user?

If you receive a CUI request RFC 4372 says you should respond with the CUI for the user being authenticated.  Whilst the RFC doesn’t specify the method, a CUI must be a transformation of the username.  Therefore the recommended method for eduroam is to MD5 hash the username together with a salt and the visited site Operator Name.  This therefore requires the visited site to send their Operator Name (Attribute 126) together with the CUI Request.

What does eduroam say about CUI?

If you look at the latest version of the eduroam service definition (http://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf) it says:

“Adherence to the following specifications is RECOMMENDED:

• AAA Servers:

Generation of a Chargeable-User-Identity (RFC 4372) response if solicited by a Service Provider and on the condition that the Service Provider's Access-Request contains a nonempty Operator-Name attribute. The value of Chargeable-User-Identity attribute returned in the response MUST have a constant value for one user and one Operator-Name attribute value.  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.”