SALSA-NetAuth - FWNA conference call November 3, 2005

*Attendees*
Kevin Miller, Duke U. (co-chair)
Chris Misra, U. Mass
Klaas Weirenga, SURFnet
Mark Linton, Penn State
Rich Cropp, Penn State
Dennis Ward, U. Michigan
Andy Rosenzweig, Merit
Brad Robertson, Merit
Bill Bulley, Merit
Mike Helm, ESnet
Doug Brown, UNC
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Chris} will follow up with Internet2 regarding the budget for setting up the second site.

[AI] {Kevin} will solicit volunteers to document the process of a site’s implementation and participation in the experiment, which can be shared (by way of a cookbook, etc.) with fellow new users.

[AI] {Klaas} will mail the {SALSA-FWNA} list with information on the user tracking tool.

[AI] {Group} will think of local site requirements for security, logging, and access to utilization of information in the context of Eduroam, where non-local users are involved.

Carry-over *Action Items*
[AI] {Philippe and Kevin} will begin a separate implementation document for Lesson Learned as the experiment gets underway. (06-Oct-05)

[AI] {Philippe} will work on updating the FWNA wiki to help capture important issues. (8-Sep-05)

[AI] {Philippe} will draft a use case focusing on shared facilities between two institutions. (24-Mar-05)

*Discussion*
Merit’s proposal to host the second site for the top-level site was approved by {Philippe, Chris, and Kevin}. FWNA is looking forward to working out the logistics of getting this second site to an operational state, and also anticipates the participation of others to add to the success of the experiment.  

A budget request has been submitted to Internet2 for the operational requirements of the second site. The current thinking is that the sites would host the top-level servers, but a set budget would account for expenses related to hardware, software, and subsequent personnel/maintenance time. [AI] {Chris} will follow up with Internet2 regarding the budget for setting up the second site.

It is hoped that both sites will be operational – with connections to other universities – by a proposed target date of late November. The exact plan for how they will be managed and kept in sync is yet to be discussed.

Server software should be fairly straightforward, and {Philippe Hanset} can likely be of help in this area. The handling of router information will need to be addressed, either by means of a manual process, such as Eduroam is doing now with replication of configs, or scripting. As the experiment starts out, a small-scale manual administered process may suffice, but a larger environment will demand more. What can be done now to streamline the overall architecture? Which issues will require ongoing efforts?

Other suggestions included a trademark SSID that was distinct about the service that FWNA would be offering. There is a wiki in place at <http://fwna.oit.duke.edu:2500/fwna/login> with documents that discuss the expectation from the top-level server to those downstream. The connection process should be as simple as possible, while maintaining desired criteria.

The idea of a cookbook or similar deployment guide was discussed – a means of providing information about what sites need to do on the RADIUS side, etc. Those who have already joined could voluntarily document their deployment, based on experience. This information would then be passed on to new sites for their implementation process. At a minimum, a checklist of things to address at a site level should be made available for those participating. [AI] {Kevin} will solicit volunteers to document the process of a site’s implementation and participation in the experiment, which can be shared (by way of a cookbook, etc.) with fellow new users.

Users will need to decide how joining requirements fit into their CA and certificate infrastructure. Logging is another issue to be addressed; {Klaas} provided insight as to Eduroam’s approach for logging systems and components. Eduroam (Dutch) is setting up a monitoring framework, hierarchical in nature, where all RADIUS servers are connected to the top-level server. [AI] {Klaas} will mail the {SALSA-FWNA} list with information on the user tracking tool.

Privacy matters are another issue of concern – how to restrict the visited site from knowing the user ID, while still maintaining logs? Logs might be kept at the top-level server point, or perhaps they need only to be kept by the identity provider. While it may not be important to know who the user is, it is important to know who to ask if need be. [AI] {Group} will think of local site requirements for security, logging, and access to utilization of information in the context of Eduroam, where non-local users are involved.

The next SALSA-NetAuth – FWNA call will be held on Thursday, November 17, 2005 at 11am ET.