*Attendees*
Jill Gemmill, UAB
Jason Lynn, UAB
Aditya Srinivasan, UAB
Tom Barton, Memphis
Doug Sicker, Colorado
Tyler Johnson, UNC
Nadim El-Khoury, UNC
Art Vandenberg, GSU
Victor Bolet, GSU
Ann West, Educause
Bill Doster, U. Michigan
Bob Olsen, Argonne National Labs
Scott Cantor, OSU
Samir Chatterjee, CGU
Tarun Abhichandani, CGU
Ken Klingenstein, Internet2
Egon Verharen, SURFNet
Steve Olshansky, Internet2
Jeanette Fielden, Internet2

*Discussion*
Doug and Jon Peterson have submitted a paper titled Role-based Authorization Requirements for the Session Initiation Protocol to the IETF. It is available at: http://www.ietf.org/internet-drafts/draft-peterson-sipping-role-authz-00.txt
Bill Doster talked about KX.509 Credential Conversion and potential applications. KX.509 is a program that uses your Kerberos tickets to generate a new RSA key pair, and uses the tickets to authenticate you to a certificate authority. It then sends a public key which the certificate authority signs. You get back a certificate with a lifetime limited to that of the Kerberos ticket used to authenticate. This avoids many certificate revocation issues as well as the difficulty of having users carry around private keys. The focus has been on getting it to work with web browsers.
One discovery was that the resulting key pair and certificate could be written to a file. It was realized that could be used for much of the grid work and it's now part of the NMI release. It is used by the grid effort to get a short-term certificate and authenticate downstream. KX.509 itself is unaware of what happens to the certificate afterwards. Its job is to get the certificate and put somewhere so that hopefully it will get taken care of when you log off.
The goal is to have one way to access the certificate regardless of the OS. Along with the KX.509 program there is a PKCS11 library included. The API to the library is the same across platforms and it translates the PKCS11 calls into looking into the right place for the certificate on that platform. The PKCS11 library gives you a way of finding it regardless of the platform you are on. For example, in Microsoft, once you run KX.509 on a windows program you don't have to add special software to the IE browser because it already knows where to look. Another advantage of the library is that it is independent of the authentication you use to get the certificate. Whether you got it via Kerberos authentication, password, etc., the PKCS11 API will be the same since the same interface to get the certificate is always used.

Certificate destruction varies by operating system. The most recent version of KX.509 on windows handles it while previous versions required a separate program. KX.509 gets your certificate and puts in the right place for IE to find it. It then goes into the background and waits for you to log off. When you do, it goes in and removes the certificate. On UNIX the certificate goes into the Kerberos ticket file or is wrapped with the Kerberos ticket license and when you log out it is hopefully removed. Mac OS platforms are currently being worked on with Apple and will access through the PKCS11 library as well.

For a windows Kerberos implementation, what is the certificate authority and what are the implications of using the window login for a Kerberos ticket and the support for that in the library? The ideal scenario is to have the workstation set so it does Kerberos pass root authentication. For example, you log in as user@umich.edu to a workstation configured so that umich.edu is an MIT KDC not a Microsoft KDC. The Microsoft KDC will still allow successful authentication against the MIT KDC to log on. For KX.509 it will take the ticket granting ticket and put it into Microsoft's credential cache. There is a version of KX.509 that is able to use the Kerberos tickets from Microsoft's credential cache to authenticate to the KCA so MIT's software doesn't have to be installed on that workstation in order to run. Brandeis has been largely successful using a Microsoft KDC. Currently the KX.509 protocol is based on top of UDP and that limits the size of Kerberos tickets. Kerberos tickets get authorization data stuffed into it them, so they keep getting bigger till they can't fit into a single UDP packet. So there is a desire to rebase it on TCP or offer it as an option.

Jill asked about associations with bandwidth brokering work. Could it be at the local gatekeeper proxy, server remote gateways, etc. that a bandwidth-brokering approach collects information from those multiple places and puts them together so you can kind of do a logical assembly of all the components and make an overall global policy decision? The desire is to establish something based on the person having the right authorization at many different endpoints. So with the bandwidth broker the first leg setting up is authenticated, it gathers information on you, and passes it down the pipe. There's one single point for a given transaction, the client only talks to one broker for a given call. The main difficulty is coming up with a language that the bandwidth brokers agree on. Bill suggested that Andy Adams would be a good contact for more information.

KX.509 and encryption: KX.509 holds promise of being able to avoid deploying PKI but still have the advantages of the certificate based approach. In H.323 there are two areas where you might encrypt. One is the media streams themselves, the digital audio video flowing over the network needs to be encrypted and decrypted in real-time so sniffers couldn't extract the data. The other is the call signaling itself, who you're calling, if it's busy etc. In H.323 those elements can be encrypted using the certificates or a token generated from a password user id pair. In order to encrypt you need to have shared secret at each end of the stream. How do you get the thing over to the other end? Metric encryption is the most efficient, so you might use something asymmetric to send the secret over. But unless you have a certificate, using digital certificates might be a good way to exchange that initial secret end to end.

For proof of concept in using KX.509 there won't be a stack to try any of this with till Radvision releases theirs sometime this fall. The also have not been talks with Radvision yet about their level of interest in trying to implement something specific with the PKCS11. The API library also needs to be evaluated to determine exactly what's possible.

Bob Olsen is a developer for the Access Grid and talked about directions they're considering for the security issues. They're using the Globus toolkit to provide support for using the Globus identity certificates to identify users in an access grid meeting. The client software grabs Globus proxy certificate and uses that to authenticate with the access grid venue server. This gives a user a good idea of who else is in a meeting. With the old tools the only concept you had of who was in the meeting was the IP addresses or the names that came along with immediate streams in the session. They're using the certificates to secure and authenticate access to the venue server. The secure connections can be leveraged to distribute session keys for encrypted media sessions, etc. It also allows for secure file transfer since access control can be placed on entry to the venue and only authorized people can retrieve files.

They are planning on including a known anonymous certificate with the access grid distribution. That way if people do not have a certificate of their own they have the tagged anonymous one so they can get the benefit of the encrypted session. The user interface will show they're using the anonymous certificate. There are also plans for building something that looks to the user like a standard web based registration but is an online CA that serves up proxies to the user based on the user name and password. Currently that username and password is local to the Access Grid.

Jill raised the issue that certificates are basically only as good as your ability verify them/ trust where they came from. With these models one might only need to validate the certificate issuer but there is still the matter of the certificate authority. Ken had a recent conversation with Jeff Schiller and was optimistic that Internet2 will be able to issue enterprise certificates soon with the same certificate polices used for the CREN certificates. He believes enterprise certificates will be ready to issue by April and it will also be possible to revoke some of them.

Nadim provided a quick overview of the ITU meeting. There was very little discussion H.235 at the meeting. Nadim talked to the Rapporteur for H.235 about the approach we're considering and the ideas Jill circulated in her authorization and authentication slides. The Rapporteur was open to the ideas and us to submitting something along those lines. It was agreed that the KX.509 path should be included if VidMid VC chooses to write up anything.

Jill talked about the SURA/ViDe Digital Video Workshop that will be held in Atlanta March 24, 25, and 26. The keynote speaker is Gordon Castle who manages the all-digital video services for CNN. Bob Olsen will speak at the workshop about new directions in Access Grid. Egon will also be at the meeting. Jill has requested a 20-minute slot to do a general talk on secure video conferencing: why you want to do it, how you do it today and directions it's going in. She is also working to organize a panel to go more in depth on the development directions being proposed so an approach that reflects VidMid VC direction can be included. This will be discussed in more detail on the next VidMid VC conference call.
Then next call is Monday March 10, 2003.