Transcript Document

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
connect • communicate • collaborate
Authentication in eduroam
(selected messages)
NAS
IdP
SP
(umk.pl)
EAP-Request/Identity
EAP-Response/Identity
[email protected]
Access-Request
[email protected]
Access-Request
[email protected]
encapsulated RADIUS Access-Request
[email protected]
[email protected]
encapsulated RADIUS Access-Challenge
EAP-Success
Access-Accept
Access-Accept
EAPOL
RADIUS
RADIUS
Home institution
- IdP
Visited institution - SP
connect • communicate • collaborate
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
connect • communicate • collaborate
Agenda
Case study
Privacy considerations
Proposed solution
Implementation
connect • communicate • collaborate
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
connect • communicate • collaborate
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
connect • communicate • collaborate
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
connect • communicate • collaborate
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
connect • communicate • collaborate
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.
connect • communicate • collaborate
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.
connect • communicate • collaborate
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 AccessAccept 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)
connect • communicate • collaborate
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 NASIdentifier 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
connect • communicate • collaborate
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 NASIdentifier values is also added before the MD5 sum is computed)
connect • communicate • collaborate
Authentication in eduroam
(selected messages - again)
NAS
IdP
SP
(umk.pl)
EAP-Request/Identity
EAP-Response/Identity
[email protected]
Access-Request
[email protected]
Access-Request
[email protected]
encapsulated RADIUS Access-Request
[email protected]
[email protected]
encapsulated RADIUS Access-Challenge
EAP-Success
Access-Accept
Access-Accept
EAPOL
RADIUS
RADIUS
Home institution
- IdP
Visited institution - SP
connect • communicate • collaborate
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
connect • communicate • collaborate
Authentication in eduroam with CUI
(selected messages)
NAS
IdP
SP
(umk.pl)
EAP-Request/Identity
EAP-Response/Identity
[email protected]
Access-Request
[email protected]
Access-Request
[email protected], CUI=NULL,
NAS-Id=12345
encapsulated RADIUS Access-Request
[email protected]
[email protected]
encapsulated RADIUS Access-Challenge
EAP-Success
Access-Accept
Access-Accept
CUI=1930c24643d7fb354aeefe5b4dd0c7ec
EAPOL
RADIUS
RADIUS
Home institution
- IdP
Visited institution - SP
connect • communicate • collaborate
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).
connect • communicate • collaborate
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
connect • communicate • collaborate
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
connect • communicate • collaborate