*Attendees*
Jill Gemmill, UAB
Jon Peterson, NeuStar
Samir Chatterjee, CGU
Tom Barton, U. Memphis
Jonathan Tyman, Internet2
Steve Olshansky, Internet2
Ken Klingenstein, Internet2
Michael Gettes, Georgetown
Ameet Kulkarni, Doug Sicker, U. Colorado - Boulder
Anand Chavali, Mudassir Fajandar, U. Colorado - Boulder
Jeanette Fielden, Internet2

*Discussion*

In looking at the local domain where a SIP user agent connects to a local proxy, authentication could be performed using a number of methods including WebISO, Kerberos etc. How would these different mechanisms integrate with SAML? With WebISO systems authentication is performed against the back end mechanism. If the mechanism is Kerberos it does an authentication and puts a cookie back into the browser however, the cookie is not SAML based. The next edition of Pubcookie will put a SAML based expression as the cookie. Cookie formats in WebISO systems appear to be moving towards SAML based expression pretty quickly. If the Kerberos and WebISO authentication can be collapsed into the same instance of a cookie in the browser you could create a universal starting point for having and using a credential to put authenticated information into the registry and send authenticated invites. This would imply that the Kerberos case is a sub case of the WebISO case.

Does the use of Digest to authenticate between the initiating user and proxy invalidate the goal of single sign-on? Digest can always be made to invoke a challenge response. How that would spread between applications to create a single sign-on environment is not yet known. Currently SIP only uses Digest. In the enhanced version of SIP there will be the ability to employ other mechanisms, including an existing credential. If, when Digest is invoked, the server is able to generate a SAML assertion this is a positive step since this assertion can be sent across domains. It may enable migrating from Digest to something else to create the assertion.

There was agreement that anonymity/privacy has to be included from the start to ensure that the capability is in the system if later use is desired. One privacy aspect that is immediately relevant in video conferencing is that I may be willing to reveal to you who I am, but I'm not willing to reveal what terminal I'm connecting from. There are mechanisms already in SIP that are adequate for that kind of privacy.

When the target receives an incoming video call there can be one of three conditions can occur, an authenticated user with user information, an anonymous user with the security domain says this an authenticated user, and a call coming in from outside the federation about which nothing is known.

The SIP identity draft covers different degrees of knowledge about callers and how you present it for telephony cases. These cases also cover the above conditions. One example is the case of a server generating an authenticated identity body that you can't inspect, i.e. it's been encrypted. A proxy server as well as an user agent server may want to inspect the authenticated entity body, but based on the security properties of the body it may be possible that only one or the other would be able to inspect it. This is similar the server vouching for an authenticated identity that is anonymous. Jon will update the draft this week, and the document name will change to Draft IETF SIP Identity 00.

Another option could be for the server to privilege requests differently. A server could elect to directly relay only proxy requests it trusts to the user agent, or also elect to redirect the requests it doesn't trust to the user agent server. In one instance it's responsible for delivery, in the other the server says, “here's a request, if you want to talk to this guy you can but you have to work it out” to the user agent.

At what point in the enhanced SIP process do you need running code? There are no running code requirements to become a proposed standard. To become a draft standard there are interoperable implementation reports required. This is a rigorous requirement and quite late in the process. SIP has been around since 1995 and is still a proposed standard not a draft standard.

There is a need to carefully review open source software licenses to make sure that any issues with intellectual property are identified and resolved. Please review licenses carefully and forward to Ken if there are any questions or concerns.

There is a meeting with Radvision in October. Jill is working on a requirements document for them. One issues is there's not a place to stick a SAML assertion in the standard. However, there are some non-standard tweaks that can be done that don't come in via a web-based interface.

The next call is scheduled for Tuesday September 3, 2002.