Kevin Miller, Duke U. (co-chair)
Philippe Hanset, U. Tennessee (co-chair)
Chris Misra, U. Mass
Deigo Lopez, RedIRIS
Tom Zeller, U. Indiana
Mark Poepping, CMU
Derek Morr, PSU
Mark Linton, PSU
Rich Cropp, PSU
Tom Scavo, NCSA
Rich Cropp, Penn State
John Vollbrecht, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
*Action Items*
[AI] {Tom Z. and Mark} will help to aggregate use cases around guest access.
[AI] The Group decided to work on a few documents to identify and compile trust issues, with examples for clarification.
*Agenda*
- Scope/Problem Statement
- SAML, RADIUS integration
- Steve's Document
- Outstanding issue
- nameIdentifier Privacy
- Solution Document
- Next steps
- Code?
- Guest access
*Discussion*
The SALSA-NetAuth – FWNA Working Group mainly focuses on the wireless network authentication issues surrounding the visiting scientist. The Group also aims to identify compelling reasons to allow network access among federated institution, and furthermore how these details fit into the larger interoperability issues. Currently, Merit and U. Michigan have joined the experiment and connected to the top-level server at U. Tennessee. Additional use cases beyond basic connecting are desired.
The group discussed whether guest access, in its traditional role, is viewed within the scope of the Working Group. {Philippe} pointed out that not just a question of whether or not to do it, but is there another venue [more] appropriate for this discussion.
With respect to federated access, some conceptualize the few schools within a small 30-mi radius. Others are more open to the idea of federated access across the country and even internationally. {Chris} suggested that an aggregation of use cases could help people to decide where there campus falls. The EDUCAUSE Security mailing list or Wireless list might be a good venue to help everyone understand the particular issues of guest access. [AI] {Tom Z. and Mark} will help to aggregate use cases around guest access.
At U. Indiana, {Tom Z.} explained that guest access is addressed by enabling an account within 24 hours of the time of request. They also do batch accounts by the hundreds, and use ADS for these services. A single guest account is valid for three weeks, though the user must re-authenticate every 24 hours. Every account created is sponsored by a faculty member, ensuring some level of trust. However, if their snort box identifies you, you are lead to a box where your outgoing traffic is black-holed, as well as the traffic returning to you.
{Chris} said U. Mass is using a Bluesocket box. Account creation is behind the web layer, and SSO is in place. A guest gains access to their network via account creator. {Diego} mentioned a situation in Bologna, Italy, where a photo ID is necessary on a second attempt to access the network.
It is important for a campus to do necessary due diligence, which may include collecting of the mac address of a user, for authentication. An ISP must maintain logs for five years.
{Mark P.} discussed the use of a sensor enabling many sensors; this sensory information can then be leveraged. Though people are beginning to do so, there is work to be done on the privacy end.
{Kevin} raised a point that the nameIdentifier is being confused with a name, though it is really more of a handle. {Tom S.} disagreed and said it is a name associated with the SAML assertion. TargetedID is an attribute and so does not satisfy the nameIdentifier.
{John} insisted that it will be key to have a high-level document to explain how the RADIUS/SAML will work. There ought to be some explanation about how Shibboleth fits into the picture. Use cases can be fleshed out before writing the code. [AI] The Group decided to work on a few documents to identify and compile trust issues, with examples for clarification. In addition to an abstract concepts, there might be a separate document for the following aspects: 1) sequence of steps and how it works (so IT can analyze it), 2) implementations steps, and 3) who is using it and why.
The Shibboleth example using the NSF Fastlane, as exampled at the Thursday General session, is a convenient jump to other venues for library, journals, and grid access, etc. See <http://events.internet2.edu/2006/fall-mm/sessionDetails.cfm?session=2931&event=258 > for more information on the Fastlane example. Shibboleth attributes can be leveraged, as well as possibly some of the work being done in Middleware.
The next SALSA-NetAuth – FWNA Working Group meeting will be on Thursday, December 14, 2006 at 11am EST.