SALSA-NetAuth - FWNA conference call August 25, 2005

*Attendees*
Kevin Miller, Duke U. (co-chair)
Philippe Hanset, U. Tennessee (co-chair)
Rich Cropp, Penn State
Mark Linton, Penn State
Dennis Ward, U. Michigan
Chris Misra, U. Mass
Tony Genovese, ESnet
RL “Bob” Morgan, U. Washington
Lisa Hogeboom, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Group} will work to incorporate the calls' points of discussion (requirements, etc) into the 'Goals' document in the FWNA wiki.

[AI] {Group} will follow-up on the question of whether infrastructure servers need any EAP knowledge to effectively pass EAP messages.
 
Carry-over *Action Items*
[AI] {Group} will populate EAP and 802.1X information to the FWNA wiki. (27-Jul-05)
 
[AI] {Philippe} will draft a use case focusing on shared facilities between two institutions. (24-Mar-05)

*Discussion*
{Kevin} discussed the documentation of operational components, including the ‘Goals’ document <http://fwna.oit.duke.edu:2500/fwna> and Experimental Plan. The Group went over the documents listed and discussed improvements to clarify the desired objectives. [AI] {Group} will work to incorporate the calls' points of discussion (requirements, etc) into the 'Goals' document in the FWNA wiki.

The ‘Goals’ document includes common thoughts on standardization of eduroam.us, as well as a common approach for incorporating 802.1x.1X or EAP. The Group discussed what users would be interested in, as well as what is capable of being supported.

Security is a top priority, and presents issues in terms of how an institution passes their user password attributes, etc. What level of encryption must be used to ensure privacy, and is there an associated standard for certificates? Setting a specific requirement for WPA, etc., may present obstacles for those universities who are not readily equipped. 802.1x seems like a good approach, though universities may not have it up and running currently. In terms of SSID selection, would it be feasible to have a standard in place, or might an institution prefer to do as they wish? What is the best balance between maintaining satisfactory security and offering enough options to satisfy the interested users?

{Philippe} suggested that the group consider creating a logo for the eduroam.us, such that anyone visiting the registration site would have a reminder of who they are working with.

At this point, the scope of Eduroam is not certain, and considerations should be made for 2 universities that are within walking distance; a person roaming may have a need to move between campuses. While this situation is not expected to be the norm, and it does explain where a standard would be very functional. Policy issues may present a source of deviation among institutions, yet it is important to reach an agreement that is manageable. Efforts will be made to clearly distinguish between infrastructure requirements and service recommendations, as these parameters are yet to be finalized.

{Kevin} updated the current version listed on the wiki to read as Infrastructure Connection Requirements, and will continue to update the documents as the discussion evolves.

When you proxy to a RADIUS server, which EAP type will be supported? The first point of access will have to serve as a smart proxy, acting across the hierarchy. The last or visited site will then be responsible for passing information back. How can one be sure to pass their credentials without worrying how they will be passed? [AI] {Group} will follow-up on the question of whether infrastructure servers need any EAP knowledge to effectively pass EAP messages. Other questions include items such as SSID and encryption.

{Kevin} suggested that the Group begin to work on a strawman proposal that would detail the ongoing discussion. The next steps will be to thoroughly document any instructions, requirements, recommendations, such that the user will understand the goals and realistic expectations. Also included, should be any “anti-goals” and expected timeline, so that the user is aware of these motivations as well. These documents will remain workable to allow for any growth or changes that will accompany this work as it evolves.

To register with FWNA, visit <http://fwna.ns.utk.edu/> for more information.

The next SALSA-NetAuth – FWNA conference call will be on Thursday, September 8, 2005 at 11am ET.