SALSA-NetAuth - FWNA Working Group conference call
November 2, 2006

*Attendees*
Kevin Miller, Duke U. (co-chair)
Philippe Hanset, U. Tennessee (co-chair)
Klaas Wierenga, SURFnet
Diego Lopez, RedIRIS
Óscar Cánovas Reverte, U. Murcia
Ruth Del Campo, U. Stuttgart
Chris Misra, U. Massachusetts
Richard Conto, Merit
Andy Rosenzweig, Merit
Rich Cropp, Penn State U.
Mark Linton, Penn State U.
Kevin Warren, Howard U.
Steve Carmody, Brown U.
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Chris} will forward a link regarding developments in the NEA working group.
[AI] The Group will review {John’s} document and follow-up on the FWNA mailing list.
[AI] {Diego} forward links to the list regarding GAIN work.

Carry-over *Action Items*
[AI] {John} will forward his thoughts on attribute security. (19-Oct-06)
[AI] {John and Steve} will further discussion of RADIUS-SAML integration offline before the next working group call. (19-Oct-06)
[AI] {Philippe and John} will create a summary of the path that a request makes, for the sake of troubleshooting. (24-Aug-06)
[AI] {Kevin} will connect the local RADIUS administration folks at Duke to the FWNA-Ops list. (23-Feb-06) *Agenda*
1. IETF NEA working group chartered
2. Next gen pieces  
- SAML/Shibboleth <http://stc.cis.brown.edu/~stc/Projects/Projects-using-Shib/eduRoam/Radius-SAML-Profile-v1.html>  
- RADIUS

*Discussion*
{Chris} shared the recent developments of the Network Endpoint Assessment (NEA) working group, which now has a charter with a defined scope. Work in this space may lead to arrangements with the NetAuth group.

[AI] {Chris} will forward a link regarding developments in the NEA working group.

[AI] The Group will review {John’s} document and follow-up on the FWNA mailing list.

{Steve C.} shared an update on recent activity in the RADIUS-SAML space. He made a few changes to the draft proposal, including examples of SAML messages, which can be found at <http://stc.cis.brown.edu/~stc/Projects/Projects-using-Shib/eduRoam/Radius-SAML-Profile-v1.html0>. {Klaas} offered two approaches for the SAML Identity Provider and attribute provider interaction: 1) stick to the existing RADIUS infrastructure and have SAML come out at home institution of user, or 2) the Service Provider or visited RADIUS provider could break out as soon as possible and talk to Identity Provider of user. There are advantages and disadvantages to both, and discussion and experience are necessary to see which works better.

The restraint on length of RADIUS message is a disadvantage of using Diameter, because the SAML message would likely exceed that length. {Oskar} said they are considering an alternative to this problem, and will share their analysis. There are several documents discussing the use of a diameter backbone to transmit the SAML assertions; [AI] {Diego} forward links to the list regarding GAIN work.

{Klaas} mentioned prior discussion with {Diego} regarding existing legacy infrastructure of scenarios dealing with OpenDiameter. Ideally, Europe will one-day have AuthN/AuthZ as a trust fabric that connects institutions across the continent, possibly at a RADIUS/SAML level. At a national level, using the existing RADIUS federation seems to be the easiest way forward. {Steve C.} agreed and said that his draft proposal aims to get the attributes necessary for a more generalized policy mechanism, with minimal impact.

{Klaas} inquired about 802.1x issues with doing SSO for network access (vs. application access). The problem lies in password renewal. With 802.1x, a user ends up disconnected once their stored password expires. This is a challenging problem, and not one that {Steve C.} aims to address right now. He is proposing that the user experience remains the same, so they would authenticate using 802.1x from the home site, as usual. The goal is to minimize impact on protocol and existing implementation, and using the existing Shibboleth software in addition to a new name identifier in inline with this goal.

There may be other elements about the SAML and Shibboleth relationship that go beyond the SAML specifications. How does the trust relationship work? How can messages be combined into different transport mechanisms? How can you specify xml signatures? Which algorithms introduce trust? The idea of federations would simplify scalability issues, and leveraging that trust fabric is good. For example, there would need to be a way for two universities, in the US and Nederland, to have a trust relationship so that a user could be positively identified from the other end.

This also leads to inter-federations that could more easily connect institutions globally, though this model is not significantly different. {Steve C.} mentioned a plan to demo how Brown could enter the NSF federation, even though they belong to different federations. Shibboleth v2.0 will have capabilities for some of the metadata needed for passing, e.g., names and keys. If the US federal government and InCommon federated with the Dutch government, all the participants would need to have knowledge of certain metadata. {Klaas} said he would rather be able to request the metadata if needed, but not have it provided as a default.

These discussions will continue at the Fall Internet2 Member meeting, December 4-7 in Chicago <http://events.internet2.edu/2006/fall-mm/index.html>. The NetAuth/FWNA Working Group Meeting will be held on Wednesday morning at 7:30am. Later, at 10:30am, an 802.1x session will be held. See the online program for more details <http://events.internet2.edu/2006/fall-mm/agenda.cfm>.

The next SALSA-NetAuth - FWNA WG call will be held on Thursday, November 16 at 11am EST.