ChargeableUserIdentity in eduroam The problem Current eduroam setup

Chargeable-User-Identity in eduroam

The problem • Current eduroam setup provides per-realm granularity • The consequences – if a guest misbehaves the SP can only black-list the entire realm – if someone uses the guest access to set up a full-time Internet link the SP may become suspicious about the eduroam idea and may want to turn on some quota system to defend against that kind of overuse (this may be a local-level problem but we might provide a universal solution) – in case of incidents locating the correct entries in the logs may be complicated by the fact that the SP logs will just show anonymous user

Possible solution: Chargeable-User-Identity (CUI) attribute • defined in RFC 4372 (pointed out by Jochem van Dieten) • meant to carry a value which is unique to a user (perhaps only for some period of time) • CUI in action – request – send the CUI attribute with a NUL value – reply – send the user identifier in the CUI – the NAS accounting should be based on CUI rather the User-Name (probably currently not implemented by anybody)

Tests and implementation • CUI request implemented in Free. Radius v. 2 • CUI response implemented in Free. Radius v. 1 and 2 (runs in production service in Toruń) – currently a fixed value per user is returned • CUI proxying tested for Free. Radius v. 1 and 2, Radiator, Rad. Sec proxy • testing tool – a patch to eapol_test from wpa_supplicant 0. 6. 2 capable of sending goth NUL and non-NUL CUI and displaying the response

So now what. . • We are happy to provide all information on server setup, eapol_test patch etc. • Questions, issues – – Test pilot (volunteers)? How permanent should the CUI be? Recommendation for SA 5 participants? Add a subchapter to Roaming Cook. Book?