1 / 5

Chargeable-User-Identity in eduroam

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

vonda
Download Presentation

Chargeable-User-Identity in eduroam

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chargeable-User-Identity in eduroam

  2. The problem • Current eduroam setup provides per-realm granularity • The consequences • if a guest misbehaves the SP can only black-listthe entire realm • if someone uses theguest 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

  3. 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)

  4. Tests and implementation • CUI request implemented in FreeRadius v. 2 • CUI response implemented in FreeRadius v. 1 and 2 (runs in production service in Toruń) – currently a fixed value per user is returned • CUI proxying tested for FreeRadius v. 1 and 2, Radiator, RadSec 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

  5. 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 SA5 participants? • Add a subchapter to Roaming CookBook?

More Related