IDENTITY MANAGEMENT OF USERS IN eduroam Maja Górecka-Wolniewicz, Nicolaus Copernicus University Toruń & PIONIER Network, Poland Tomasz Wolniewicz, Nicolaus Copernicus University Toruń & PIONIER Network, Poland TERENA Networking Conference 2009, Malaga, 8-11.06.2009
Authentication in eduroam (selected messages) EAP-Request/Identity NAS SP IdP (umk.pl) EAP-Response/Identity UserName=@umk.pl Access-Request UserName=@umk.pl Access-Request UserName=@umk.pl encapsulated RADIUS Access-Request twoln@umk.pl encapsulated RADIUS Access-Challenge user123@umk.pl EAP-Success Access-Accept Access-Accept EAPOL RADIUS RADIUS Home institution -IdP Visited institution - SP
Problem statement eduroam authentication is designed to support users privacy (the user is able to hide the real identifier from the visited institution) current eduroam policy allows for identification of the users through the correlation of log files a process which requires participation of at least two parties, and which has been designed mainly to deal with serious incidents the short-term anonymity of the user takes away most control mechanism form the visited institution the proposed solution an opaque, persistent user handle is, in principle, very similar to the edupersontargetedid as defined by the eduperson Object Class Specification
Agenda Case study Privacy considerations Proposed solution Implementation
Case study - the need of an identifier Timely reaction to network incidents incident observed user blocked on the basis of Calling-Station-Id (MAC) user changes MAC and reauthenticates successfully report incident to up-stream eduroam structure report reaches the IdP IdP considers the case and blocks the user in the meantime the SP blocks the entire IdP realm a unique user handle allows the SP to put an immediate, unavoidable local blocking rule Reaction to minor incidents Identifying and reacting to the overuse of guest access Collecting guest usage statistics at the SP
Case study - the need of an identifier Timely reaction to network incidents Reaction to minor incidents IdP can only block the user from the entire eduroam the decision to block the user may be difficult a unique user handle allows the SP to act at its own discretion Identifying and reacting to the overuse of guest access Collecting guest usage statistics at the SP
Case study - the need of an identifier Timely reaction to network incidents Reaction to minor incidents Identifying and reacting to the overuse of guest access it is frequently observed that users living within the range of an institutional wireless network set up permanent links from residencies in eduroam the guest access can be used for the same purpose such use (if seen as undesirable by an institution) is difficult to detect and even more difficult to stop (anonymous outer identity, MAC address change) a unique user handle solves the problem Collecting guest usage statistics at the SP
Case study - the need of an identifier Timely reaction to network incidents Reaction to minor incidents Identifying and reacting to the overuse of guest access Collecting guest usage statistics at the SP the number of eduroam guests is difficult to measure using information from the Calling-Station-Id RADIUS attribute, the SP is able to count the number of devices but not the actual users users may be changing the MAC address of their devices, which puts even more confusion to the statistics Correlation of RADIUS Accounting with user authentications is difficult even for local users and impossible for guest users a unique user handle makes it possible to count each user once
Privacy considerations user handle should be supplied only on demand the true user identifier should be impossible to recover, also by application of a dictionary attack, when the algorithm of generating the handle is known user handles for one user, supplied to different SPs should be different, in order to make it impossible to correlate data from several SPs and create a user profile edupersontargetedid: A persistent, non-reassigned, privacy-preserving identifier for a principal shared between a pair of coordinating entities, denoted by the SAML 2 architectural overview as identity provider and service provider (or a group of service providers). An identity provider uses the appropriate value of this attribute when communicating with a particular service provider or group of service providers, and does not reveal that value to any other service provider except in limited circumstances.
Proposed solution MAC address why not? The MAC address of the user s device is sent within the Calling-Station-Id RADIUS attribute, hence it could be considered as a candidate for the user handle Cons: The MAC address can be controlled by the user. Even if this is rarely done, those users who intend to overuse the network, are likely to take steps to avoid detection. A user may, by chance or on purpose, change the MAC address to a value that has also been used by another user. This could lead to putting the blame for another user's behaviour on the wrong person. (In a full scale eduroam investigation this could not happen, but such investigations are not likely to be started in minor cases.) eduroam administrators cannot insist that their users keep the MAC addresses constant, as this could clearly lead to the violation of privacy. The MAC address can only be an identifier of a device and not the user.
Proposed solution Chargeable-User-Identity (CUI) Definition RFC-4372 Response to the anonymous outer identity problem provides a persistent identifier returned on request in Access-Accept CUI request an Access-Request packet containing the CUI attribute is considered to be the request for the user s CUI value CUI response a CUI attribute value in the Access-Accept packet A NAS supporting CUI must add the CUI value received in Access- Accept to all appropriate accounting packets Expected usage mainly accounting purposes Implementation support expected to be implemented in NAS and RADIUS server currently no known implementation in NASes currently only the most basic support in RADIUS servers (usually limited to proper proxying)
Chargeable-User-Indentifier in eduroam Implementation in the server (disregarding the NAS) Safeguarding users privacy the CUI value should change when the user visits another institution the real user identifier must not be recoverable with dictionary attack eduroam approach to CUI handling the Access-Request packet containing CUI request must also contain the NAS-Identifier attribute, which is treated as a persistent, identifier of the visited institution the algorithm used to construct the CUI value must use the NAS- Identifier as one of the inputs the NAS-Identifier value must be opaque the algorithm used to construct the CUI value should make it impossible to use the dictionary attack to recover real user information even when the NAS-Identifier value is known
Implementation FreeRADIUS server Pure RFC-4372 implementation eduroam extensions as an additional configuration No code modification needed all implementation done in FreeRADIUS configuration SP and IdP parts implemented independently and can be separately configured How it works on the SP side, the server adds the CUI attribute with the NULL value to each Access-Request packet (in the eduroam extension the NAS-Identifier is also added) on the IdP side the server prepares the CUI value creating the MD5 checksum of the concatenation of: the inner User-Name value and an additional, preconfigured string (in eduroam extension the NAS- Identifier values is also added before the MD5 sum is computed)
Authentication in eduroam (selected messages - again) EAP-Request/Identity NAS SP IdP (umk.pl) EAP-Response/Identity UserName=@umk.pl Access-Request UserName=@umk.pl Access-Request UserName=@umk.pl encapsulated RADIUS Access-Request twoln@umk.pl encapsulated RADIUS Access-Challenge user123@umk.pl EAP-Success Access-Accept Access-Accept EAPOL RADIUS RADIUS Home institution -IdP Visited institution - SP
CUI accounting support in FreeRADIUS On reception of an Access-Accept packet, the SP server uses a new FreeRADIUS sql module (cui) and an auxiliary database and writes down a record containing: the NAS IP address the MAC address of the user's machine outer username CUI value When the server receives an accounting packet it gets the database record corresponding to the NAS IP address, the MAC address and the username, reads the stored CUI value and adds it to the packet. When an accounting Stop packet is received, the corresponding record is deleted from the auxiliary database. The database is periodically cleaned of stale records
Authentication in eduroam with CUI (selected messages) EAP-Request/Identity NAS SP IdP (umk.pl) EAP-Response/Identity Access-Request Access-Request UserName=@umk.pl UserName=@umk.pl UserName=@umk.pl, CUI=NULL, NAS-Id=12345 encapsulated RADIUS Access-Request twoln@umk.pl user123@umk.pl encapsulated RADIUS Access-Challenge EAP-Success Access-Accept Access-Accept CUI=1930c24643d7fb354aeefe5b4dd0c7ec EAPOL RADIUS RADIUS Home institution -IdP Visited institution - SP
Implementation eapol_test eapol_test a popular testing tool distributed with wpa_supplicant in order to support CUI testing eapol_test has been extended: displays CUI attributes in RADIUS packets supports adding arbitrary attributes to Access-Request packets CUI support present in wpa_supplicant distributions starting from 0.6.7 calling syntax eapol_test -N 32:s:identifier -N 89 -a radius_server_ip -s secret -c config_file The number following the -N flag is the identifier assigned to the given RADIUS attribute, the next letter denotes the syntax of the attribute and the last part is the attribute value. Hence -N 32:s:identifier specifies the NAS-Identifier attribute of syntax string and value "identifier" and -N 89 is the Chargeable-User-Identity attribute (no syntax or value specification means the NULL value).
Conclusions and future work CUI support adds significant value to the eduroam service The support for CUI can be added gradually without any disruption to the service CUI, as designed in eduroam, does not pose any data protection threats The FreeRADIUS implementation is fully functional and is used in production service at the Nicolas Copernicus University When direct server-server RadSec connections become standard, this will introduce a new factor, which can be taken into account also in the CUI design Some (optional) elements of the CUI RFC have not been implemented, the major one being the control of CUI during reauthentication
Acknowledgments The authors would like to thank Jochem van Dieten, for pointing out the CUI RFC the participants of TERENA Task Force Mobility and GEANT2 JRA5, in particular Stefan Winter, Andrew Cormack, Josh Howlett for their important input Alan DeKok for sketching how CUI could be included in accounting packets in FreeRADIUS and for help in structuring of the implementation