I plan to follow the guidelines in the UK documents also. Some Service Providers (SP) are also not sending the Calling-Station-Id attribute to the Identity Provider (IdP) for privacy reasons. However, the eduroam agreement signed by eduroam-us requires participants to send this data so that the IdP can track users' identities to track down policy violators and to comply with national regulations.
Also Europe is moving forward with deploying RADSEC, so we need to try to keep up with them. On the eduroam-admins list, I offered assistance in drafting a standard (I was basically going to base it on the UK documents), but never did receive a response from the eduroam-us staff. I think if acceptance of eduroam is to continue to grow, these standards need to be developed soon. Here at Iowa, we have adopted it as our primary 802.1X SSID, so keeping eduroam moving forward is important to us. -Neil -- Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-john...@uiowa.edu On 5/29/13 10:18 AM, "Christopher Wieringa" <cwier...@calvin.edu> wrote: >There is a recently formed netplus-eduroam-admins listserv created by the >eduroam-US organization to discuss technical problems like this, and it >recently has been having a very similar conversation about required RADIUS >attributes, etc. (See >https://lists.internet2.edu/sympa/info/netplus-eduroam-admins ) > >It does seem to me that there aren't a ton of specifics about what >exactly are >the required attributes for eduroam-US proxying to work correctly. You >can >google search to find some recommendations from other top-level >administrators >( like eduroam-UK at >https://community.ja.net/library/janet-services-documentation/eduroamuk-te >chnical-specification >), and this is what I've been basing my deployment off of. This is >probably >just growing pains and standards will probably be worked out over time, >especially now that eduroam-US has a few dedicated employees working on >this. > >So, pasted from the URL above: > >---------- > >13. The following RADIUS attributes MUST be forwarded by participants¹ >ORPSs >if present in RADIUS Access-Request, Access-Challenge, Access-Accept or >Access-Reject messages. > >13.1. User-Name >13.2. Reply-Message >13.3. State >13.4. Class >13.5. Message-Authenticator >13.6. Proxy-State >13.7. EAP-Message >13.8. MS-MPPE-Send-Key >13.9. MS-MPPE-Recv-Key >13.10. Calling-Station-Id >13.11. Operator-Name >13.12. Chargeable-User-Identity > >14. The following RADIUS attributes MUST be forwarded by participants¹ >ORPSs >if present in RADIUS Accounting messages. > >14.1. User-Name >14.2. Acct-Status-Type >14.3. Acct-Session-ID >14.4. Proxy-State >14.5. Class > >----------------- > >If you are using attributes other than these, my guess is that in some >places >the attributes may be filtered out. There also are a few attributes that >should never be passed upstream ( >https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-d >efinition_ver28_26072012.pdf >) like Tunnel-Type., Tunnel-Medium-Type., Tunnel-Private-Group-ID. > >Chris > >>>> On 5/29/2013 at 10:10 AM, Julian Y Koh <kohs...@northwestern.edu> >>>>wrote: >> I will confess to tossing this out to the list without doing my regular >level >> of research since this is officially a vacation week for me. So if >>anyone >> wants to judge, it's fully justified in this case. :) >> >> The basic situation is this - as we move up to a full eduroam >>deployment, we > >> are currently at the stage where our users can visit other eduroam >> institutions and use their NU credentials to log in. The second and >>final >> phase will be to set up the eduroam SSID here on our campus for >>visitors to > >> use. >> >> What we are experiencing with the first phase of testing is that people >>are > >> reporting to us that eduroam works great at some institutions but not >others. >> Luckily for one of these locations, we were having a CIC wireless and >> networking meeting at the time, and it turned out that the host >>institution > >> was not sending the NAS-type RADIUS attribute, and some of the other >>schools > >> were actually using a check for that attribute on their end to route >>the >> authentication requests appropriately. So that got cleared up pretty >> quickly. But we're still getting a trickling of reports from some of >>our >> traveling users who are visiting other places that things worked for >>them at > >> one university but not another. >> >> So we have a couple of questions: >> >> 1.) What are the best practices in terms of validating RADIUS >>connections? >> >> 2.) What are the best practices in terms of setting up proxying >>connections, > >> attributes to send, etc? >> >> 3.) How prevalent of a problem is this? It seems to me that all the >>folks >> in Europe must have solved this a while ago. Are these just growing >>pains >as >> eduroam gains traction in the US? >> >> Thanks in advance!!! >> >> >> -- >> Julian Y. Koh >> Acting Associate Director, Telecommunications and Network Services >> Northwestern University Information Technology (NUIT) >> >> 2001 Sheridan Road #G-166 >> Evanston, IL 60208 >> 847-467-5780 >> NUIT Web Site: <http://www.it.northwestern.edu/> >> PGP Public Key:<http://bt.ittns.northwestern.edu/julian/pgppubkey.html> >> >> ********** >> Participation and subscription information for this EDUCAUSE >>Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. > > > >-- >-- >Chris Wieringa >cwier...@calvin.edu >Sr. Systems Engineer >Calvin Information Technology > >********** >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 at http://www.educause.edu/groups/.
