*Attendees*

Jill Gemmill, UAB
Tom Barton, Memphis
Art Vandenberg, Georgia State
Tyler Johnson, UNC- Chapel Hill
Nadim El-Khoury, UNC-Chapel Hill
Jonathon Tyman, Internet2
Steve Olshansky, Internet2
Jeanette Fielden, Internet2

*Discussion*

Jill gave a readout on the VidMid deliverable session where there was an Authn/Z group meeting with the Shibboleth/security experts. It was validated during that discussion that one does not have Kerberos available to issue credentials. There is not a defined mechanism for an application to refer to when requesting a SAML assertion for an application. This is a gap that needs to be filled by a more general credentials translator. This is a general problem for any application, H.323 or SIP. It is recognized that there is a need for a credentials translator and that a decision has been made to add a component for this to the Shibboleth architecture. One can Kereborize these applications but that's changing the application to fit the authentication. As it stands today applications don't know what to do with a Kerberos ticket or a cookie.

There is a need for a super generalized translation service that says: I want to end up with a Kerberos kind of ticket that I can pass through on H.323. Local authentication has to get translated. H.323 already has gatekeepers that should have real server certs so they can sign things and open secure channels. The endpoints would get certificates; the issue is the cost of getting and distributing them. The beauty of a Kerberos like X.509 certificate is that a Kerberos login authority signs it, which is the same as the pub cookie login. The servers associated with application would have to know to check the configured end user ticket authority but that would be part of this trusted architecture. The endpoint doesn't necessarily have to validate the certificate but can make use of it.

VidMid Deliverables panel: Tyler and Nadim provided an update about the commObject directory management tool and an announcement that it was going to be packaged for distribution to zone managers so they would have the software to get the commObject loaded correctly.

Jill provided an update on the H.323 conversations. The commObject work is making the gatekeeper and endpoints LDAP aware which is needed to manage commObject. There's also an idea currently called "lunchtime napkin scribble" that proposes you go off to a website, authenticate yourself and associate that authentication with information about the endpoint. If you can't force the user identity into the application, then take some information about the application endpoint and put it out where the authentication system works. The goal is to at least demonstrate it's an approach worth considering seriously. The diagram for it was heavily influenced Tom Barton's previous work.

Another lesson is that the existing security mechanisms for H.323 are poor to none. It's important to spend time thinking about a better security model to propose since there is a short time window. This approach would succeed better than trying to invent a new one from scratch. One idea is a model that uses certificates. You would need to figure out how temporary certificates can be used and how to make the applications smart about the certificates. It may be possible to use one of the H.323 annexes and make it smart about using different kinds of certificates.

Tyler disclosed that H.235 version 3 has currently been invited to submit some architectures for that to the ITU, due for ratification in May 2003. This presents an opportunity to influence the security standard for H.323. Annex E has what we need, but as currently written it only deals with X.509 certificates. Annex E requires that each entity that deals with this certificate be aware of how to interpret that certificate. So there is a notion of creating profiles for Annex E. There is even the notion that the certificate itself doesn't have to be passed. Expanding these profiles in Annex E by putting in hooks for other things is likely the way to go. What do we need for enabling SAML?

Jill also described a presentation from Jon Peterson, author of several IETF SIP standards. Jon suggested that rather than building it own authentication stuff, SIP should reference an external authoritative authentication service. The user agent sends a special newly invented type of SIP query to an authentication service, receives a reply by some yet to be defined means, and returns a digitally signed SAML assertion that contains a URL that any policy point along the way can refer to get attributes. Whatever this URL should look like is what we would propose that would be used in an H.323 place. Then if you're talking about building a gateway between the architectures you're just talking about repackaging this piece of information. Jon's presentation will be available on the website.

Discussion about Kerberos and PKI.
There's a private key, issued short term, use it immediately don't store it long term. You could do secure video-conferencing using these things. When it all comes down to PKI is that end-entity PKI or server level PKI? This is the key issue. It could be done with Kerberos, a cookie, or a validatable certificate to a server that then does the PKI. The application needs to know how to present it on the end-user's behalf. One other option is the operating system presumably knows which user is associated with application session so it could answer.

There was discussion when future Authn/Z calls should happen, and how they should be structured. The discussion will be continued on the e-mail list and the next VC call. Jill has agreed to help steer the direction of Authn/Z when she returns from vacation.