New *Action Items*
[AI] {Steve C.} will share his draft profile document relating to RADIUS and SAML integration.

Carry-over *Action Items*
[AI] {Kevin} will initiate the documentation of additional requirements for a relay/proxy server. (24-Aug-06)
[AI] {Philippe, Mike, 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. Operations update - successful connections?
2. SAML/Shibboleth & RADIUS integration - resume from last discussion

*Discussion*
{Walt} reported a successful use of the FWNA system at a recent CIC meeting. It was set up so that Penn State attendees could use the system to authenticate. Amongst the details of the successful operation, they used 802.1x, SecureW2, and FreeRADIUS. They then tried to ID a person using a particular IP address. {Rich} commented that the process might have been smoother if there was a way on the FWNA interface to query by MAC address. By not authenticating the outer tunnel, they were limited on what they could tell the other university, which made tracking more difficult.

The Group discussed a situation where a person could attempt to use an <anonymous@foo.edu> ID, and how it would still force an authenticating institution to confirm its identity. Class, being opaque, is stored by the access client; if there is a class identifier, it can be used to return information back to the remote place to ask for identification of the person requesting authentication.

{John} walked the Group through the diagram (cf. email 7-Sep) describing his ideas of SAML integration with RADIUS. Essentially, the diagram shows a user connecting through a RADIUS server to an access point. In particular, there is an additional step once the user receives access accept from the remote server: a SAML session is opened whereby additional decisions are based on attributes returned from the attribute server. Only after this step is successfully completed will an OK be passed to the access point. {Steve C.} has begun to assemble a profile document driving how a RADIUS architecture could be extended to work with SAML. The document will specifically address each entity of {John's} diagram and the procession from one to the next. [AI] {Steve C.} will share his draft profile document relating to RADIUS and SAML integration.

Several questions/issues arose regarding simple RADIUS and also its integration with SAML:

Q - What advantage does Diameter have over RADIUS?
A - Both can use IPsec, though Diameter operates as a more direct one-on-one connection to the home server, without infrastructure in the middle.  Diameter is designed better around routing requests vs. authenticating locally.

Q – How will the Net Provider RADIUS server use SAML to communicate with the User Attribute server?
A – The SAML profile takes a sequence of messages and describes how, e.g., Web SSO might use that particular sequence of messages. Currently, this SAML does not exist. It might be possible to re-purpose existing SAML for this scenario, but this work essentially needs to invent the necessary SAML.

Q – This profile document should discuss which protocols and stages, e.g., the user-client exchange?
A – The basic user-client exchange does not need to be detailed; rather, it is more important to capture the Net Provider to User Authentication database and associated information. The document should  address the simplest situation where the Net Provider RADIUS and user are the same.

Q – Will the integration of RADIUS/SAML be available to just FWNA or also the local institution?A – This will also be of benefit to the local institution. For example, a campus could create a policy saying that undergrads cannot use wireless in the central administration building. 

Q – How will the Net Provider RADIUS server know it is the last entity in the chain, since the RADIUS accept with attributes passes through N number of servers, who are not supposed to look at the message? Isn't the RADIUS accept destined for the AP, not the Net Provider RADIUS server?
A – The Net Provider RADIUS server is configured to know when that it is to forward the RADIUS accept message to the AP, not another RADIUS server. A detailed policy can establish this process.

Q – What are the additional two attributes that the User Org RADIUS server adds to the RADIUS response request message that it is constructing?
A – The first attribute has a value of a URL that can be contacted to dereference the artifact; the second attribute has a value of the artifact itself. Additionally, the SAML specs puts a limit on the size of the artifact.

Q – Will the RADIUS server be able to talk SSL instead of HTTP?
A – Yes, the conversation between the Net Provider RADIUS server and the User Attribute server will be over SSL or TLS. The Net Provisioning RADIUS server will need to contain code to validate the received assertions, which is described in the SAML documents.

There was much interest in the Group for this work to proceed. Once {Steve C.} shares his profile document with the list, the Group will continue this discussion online. Eventually, this discussion will aim to include Europe, to see how collaborative efforts can solve some of the identified problems. The Fall Internet2 Member Meeting (4-7-Nov, Chicago) will provide an opportunity for face-to-face discussion. Program information can be found at <http://events.internet2.edu/2006/fall-mm/index.html>.

The next SALSA-NetAuth - FWNA WG call will be held on Thursday, October 19 at 11am EDT