All, With eduroam (or any 802.1x proxying), the outer identifier is the only thing that a Service Provider will see. "@institution" is necessary as an outer identifier to be able to route the request to the proper destination. So, it's not so much that eduroam doesn't allow the Service Provider to know the identifier, it's the user that decides what to reveal in the outer identifier. As of today, there is no enforcement of consistency between the outer identifier (carried with the negotiation of the TLS tunnel) and the credentials protected inside the TLS tunnel (credentials used for the authentication at the destination institution). The outer identifier just needs to contain the REALM (@institution) to be able to reach its destination. This said, many operating systems put by default the inner identifier as the outer identifier. In other words, as a user, you have to specifically configure your EAP supplicant in the operating systems with a specific outer identifier if you want to mask you identity (most common one is anonymous@institution, but @institution works as well).
Every federation that participates in eduroam is required to sign a compliance statement: https://www.eduroam.org/downloads/docs/eduroam_Compliance_Statement_v1_0.pdf (Internet2 signed it on behalf of the US). This greatly enhances the responsiveness of the eduroam service as a whole. So we really have two schools of thoughts: 1-The privacy concerned (that only want anonymous@institution) 2-The Security concerned (that would prefer real-user@institution) For 1, I would say that you can always anonymize yourself or your users if you are concerned. For 2, if law enforcement is involved, as Peter Jacobs mentioned earlier "Don’t worry about other countries and cooperation agreements between law enforcement. It works faster than you think – in both directions" Also, all participants in eduroam are required to hold RADIUS logs for 6 months! (part of the GeGC Compliance Statement) For CALEA: eduroam is not a public network. Only authenticated users can join it! For DMCA: When you have a complaint, we help you send the complaint to the proper destination For blocking an abuser immediately: classic MAC address filtering, Chargeable User Identity (http://tools.ietf.org/html/rfc4372), or in desperate cases: block the entire REALM! The driver license analogy is great, but eduroam works better ... As a visitor to the US you have to first get an International Driver License, good for only a few months. http://www.usa.gov/Topics/Foreign-Visitors-Driving.shtml eduroam allows you to use your school credentials, as is ;-) Best, Philippe Philippe Hanset www.eduroamus.org<http://www.eduroamus.org> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Green, William C Sent: February-26-13 2:50 PM To: [email protected]<mailto:[email protected]> Subject: Re: [WIRELESS-LAN] Eduroam and AUP acceptance? I think the driver's license is an interesting analogy, and it causes me to think differently about the issues eduroam raises in a different light. However, as with most analogies it breaks down quickly (states do have standards coordinated with federal entities on IDs [blustering aside], coordinated training and standards [e.g. car vs truck], integrated license plate databases, user identities on the drivers license when pulled over, etc). I am interested in the service, and like the idea of enabling researchers better network access. But I'm still troubled by a number of issues which I think could be solvable, but solving them doesn't seem to be in the spirit of the European effort. Just a few: My understanding is eduroam doesn't allow the host university to know the identity of the user of the local network resource. The host can request it of the remote university, but the remote may or may not respond. It adds complexity to security investigations and law enforcement actions. Local law enforcement can't compel another country's university to release credentials. What might US CALEA implications be in these cases? I realize different laws/rules apply in different localities/entities regarding network use and identity and interpretation by each entities legal counsel. My understanding is also that eduroam doesn't have standards for who is granted credentials across institutions participating. At one school it may be faculty/students/staff, while at others that may include alumni/visitors/hobos. Related, I don't believe attributes are revealed in cases where the local institution wished to grant different status to, say faculty versus student. How do different access policies and charges (for those of us that charge) map? There may be exposures to user/password credentials utilized. For institution that use a consistent/single sign-on credential for their network access also, this is once again problematic. [lost the argument about the dangers of using SSO for network access -- even back in the web portal days prior to 802.1x] It is the same for everyone. I think it is fair to say that every institution requires faculty, staff, and students to accept an AUP before assigning a user ID and password (typically once a year). Simply apply your AUP rules to the eduroam “visitors”. Do not consider Eduroam users as outsiders/guests of your institution; they are authorized colleagues from neighbouring institutions. They know the rules and more importantly, they are easily traceable. I can drive in your state with my driver’s licence. It is accepted and I am authorized, but I should learn your specific state rules to ensure I am not ticketed. Same idea. Peter -William ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found athttp://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
