*Attendees*
Kevin Miller, Duke U. (co-chair)
Chris Misra, U. Mass
Bob Brentrup, Dartmouth College
Rich Cropp, Penn State
Mark Linton, Penn State
Paul Caskey, UT System Administration
Lisa Hogeboom, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Chris}, {Philippe}, and {Kevin} will coordinate offline efforts to reformulate the project plan moving forward, and will bring their thoughts back to the next FWNA call.

Carry-over *Action Items*
[AI] {Chris} will discuss with Bluesocket the integration capabilities of web authentication gateways with 802.1x authentication.

*Discussion*
EuroCAMP 2005 raised some interesting developments for the future of FWNA. {Kevin} relayed information from {Ken Klingenstein} and {Michael Gettes}, who attended EuroCAMP <http://www.terena.nl/tech/eurocamp/>. At {Ken's} request, a mailing list has been created through EduRoam Australia to support discussions that will further FWNA efforts <http://www.eduroam.edu.au/>. An email circulated on this list detailed EduRoam Australia's interest in meeting to define use cases, which is one matter that FWNA should look to participate in. If we do consider joining EduRoam, concerns about technology securities and policies need to be addressed. This move would most likely necessitate a reconsidering of the project plan as it is currently laid out. {Michael} expressed interest in using the Internet2 Spring Member Meeting as a possible spot to work out technical solutions that go beyond the Radius hierarchy. It would be very beneficial to work towards agreement with EduRoam on a long-term wireless federated environment - one where security is assured. In this time before the Member Meeting, we should prepare for issues that might arise there; we need to work with {Ken} to come up with some Action Items that will get us started in the right direction.

The project plan phase 1 is one attempt to really provide a grounded approach for FWNA work. The Group is receiving a lot of feedback as to why we are considering these issues - securities, roaming - and this introduces authorization issues. Questions have risen such as, "Why would I trust someone else's users?", "Why should I give this guest credentials", and "Why am I unable to use my home credentials to authenticate elsewhere?" These are key issues that need solutions, and perhaps the best way to approach this is by seeking long-term solutions, and thus bypassing the immediate issues.

{Paul} provided insight on how the University of Texas, Austin is using Shibboleth as their wireless AuthN structure. They are building a wireless infrastructure - complete with both a private and a public network -were there are two methods of login, depending on if you are Shibilized, or if you go in through the guest management system. If you login through the Shib, you authenticate through their home component. They are using the EduPerson principle name, as opposed to the affiliation, and this allow them to see who exactly is using their network at any given time. The web page sends your Eduperson principal name to a sequel table - in actuality, it grabs your session ID off a cookie created by the web application (i.e. Shib) before sending it to the sequel table, where it becomes your user name and password. Lastly, the client does an http:// post back to the airspace, where a straight Radius login is done with that user name and password. A stored procedure in the sequel table clears out this information after 3 minutes of authentication, ensuring a secure method so people cannot simply go to the web page and do a view source to sign into the network. At this point, the Shib portal provides a near unlimited element of trust, and will not place any restrictions on traffic. However, if you had logged in under the guest management system, you would see a limitation on your bandwidth. You have the ability to specify an access list to certain servers with traffic parameters, where it becomes a straight-Radius override situation. This system seems to be working well for UT, Austin. However, there are some challenges with this wireless system - you need to put everyone's Shib handle server in a pre-authorized access list. Additionally, if you run a pub cookie or web sign-on service, servers also need to have pre-authorization. This creates a huge number of entries (up to 40) in the access list, which presents a problem with the airspace folks. They are working on a bug fix right now, but it is not been a problem yet, as not all UT components are up and running in the federation. So far only 7 different components have accessed the network.

{Kevin} discussed how the Group needs to refocus in a unified effort towards creating a technical plan - roaming - and working towards an engineering plan. Where do we want FWNA to go with this project? [AI] {Chris}, {Philippe}, and {Kevin} will coordinate offline efforts to reformulate the project plan moving forward, and will bring their thoughts back to the next FWNA call.

The next SALSA-NetAuth - FWNA call will be Thursday, March 24, 2005 at 11am ET.