Summary of December 9 meeting - status reports:

*) review status of:

1) CLIENT DEVELOPMENT DELIVERABLES (H323)

* Jill/Aditya (and I hope Egon) still interested in pursuing openH323 LDAP solution as a demonstration; Egon, did you ever contact the developer & find out if there's an interest in commObject-enabling it? Otherwise, Aditya would be willing to try doing so, even though the code is C++.

* RADVISION next step seems to be on hold until we decide if any client using Annex D for authentication is worth doing. TO review, there are 3 models on the table:

a) the one we came up with at the RADVISION office: overall idea was to use enterprise LDAP directory service to authenticate, then distribute the shared videoconferencing password to client software and gatekeeper for encryption. This approach involves the client software communicating directly with commobject directory and chaining through to the enterprise LDAP directories. We're done that here: if you can chain from enterprise to commobject, keeping track of the users' identity is easy but it is hard to imaging an enterprise LDAP allowing this chaining easily. If you chain from openLDAP back to enterprise directory, enterprise authentication can be done but it is difficult to associate user identity with the commobject in this case. Also, this approach puts authentication-protocol specific code into the endpoint, which is not ideal.

b) use of Backend Gatekeeper services, such as RADIUS - this is a "standard operating procedure" that is not available in most gatekeepers. Here the endpoint communicates via RAS, as usual, and the gatekeeper passes the user's password through to some backend service such as RADIUS, which can frontend for a variety of authentication services. To some extent this approach just moves the "how do we distribute the shared videoconferencing password" problem to a different place. Techically, the gatekeeper either needs to (a) see the users password in clear text in order to pass it through - only when IPSec was for sure in place between client and gatekeeper, with TLS between gatekeeper and authentication service would this even be reasonable to suggest, or (b) have a shared secret with the gatekeeper using some H.235 security annex, and then trust gatekeeper to unpack the secret & forward to the authentication service - that puts us right back where we started.

c) "lunchtime napkin scribble": the approach here is to force use of HTTP since we have an HTTP-based authentication service to use (pubcookie). Use of HTTP by the client to access a "side" service fits nicely with Annex K. The web server would refer authentication to the authentication service; upon successful authentication, the web server would create a database entry associating the userid, endpoint id, and maybe time of authentication in database entry, maybe timeout value, and a randomly generated videoconferencing password. The client would have to use RAS to signal "successful authentication accomplished" and then the gatekeeper would access the database, as a priviliged app, do an endpoint lookup and pull userID and the stored videoconferencing password (check any time policy rules); now we have an authenticated, shared secret to use for Annex D. Use of a database by the gatekeeper also fits under "backend services". I can envision that one could substitute a "junk X.509 certificate" for the randomly generated password, and voila, we are doing Annex E. We are also set up for federated administration. So I personally favor this approach the best and am interested in whether the rest of the group considers this valuable to implement - we can schedule a more in depth discussion on this topic if of interest.

summary - maybe there are some demonstration approaches here worth

doing; mostly upon deeper looking Annex D is unappealing as an

authentication/security approach and Annex E would need a special "federated

profile" developed.

Nadim has volunteered to sketch out a draft Annex E profile – my personal opinion is that we should propose minimally what needs to be done to work in the federated space, unless industry wants to hire us to create a more full-blown version. I am concerned about the danger of spending too much time in design and not enough time in deliverables. Target is something to present at May ITU meeting in Geneva. We agreed this profile should closely parallel the Peterson IETF draft proposing SIP's use of an authentication service as a source for a signed SAML assertion about a user's identity, and passing that assertion securely in a hop-to-hop manner thru SIP servers for any remote authorization policy decisions. Samir said IETF draft was not public yet - jill will follow up with peterson as to its status.

2) CLIENT DEVELOPMENT DELIVERABLES (SIP)

CGU is working on directory enabling their client, and has gotten permission to distribute 100 client licenses to I2 for use in testbed. They are looking at use of LDAP enterprise authentication, but first release (for January 2003) will continue use of digest-MD5 from useragent to proxy. A plan for an alternative needs to be finalized. They are investigating NIST open source code.

Open SAML code can be found here: http://www.opensaml.org/

3) AUTHORIZATION MODIFICATION TO H.350

There are some concerns (Jill, Samir, Nadim, Aditya) about doing authorization inside the application as opposed to use of some policy service. Tyler argues that the commercial developers want this. (peanut gallery notes that commercial developers are consistently drawn to closed-box solutions, which may not make then a "good idea" from the point of view of our grant activities).

4) SIP Identity

good discussions have taken place in the list. Aditya has a web page with the current proposed sipIdentity model. Jill needs to update the project web site with pointers to current discusions.

5)vrvsIdentity

This is seeming less feasible given nature of multicast group addressing. We are in close contact with the VRVS developer, who is currently thinking deeply about what an interface to the internal vrvs directory of users might look like, or an enterprise white pages entry for same. It may help to send sample sipIdentity/H323Identity lookup code to Philippe G. Possible visit of Tyler, Nadim & Jill to Geneva to meet w. PG if he's there at that time.

6) AG identity

AG people not very accessible, although we are in contact. AG is supposed to be a persistent space, so there may be one or more permanent group addresses that could be listed in a directory service.

7) COOKBOOK

* UAB is interviewing this week to hire the full-time testbed manager

* Aditya circulated a proposed table of contents for discussion.

8) ADMINISTRIVIA

* Tyler's working on a new conference dialing setup for us

* Monday afternoons at 2:00 EST every other week remain good time to meet for those of us on the call - for those NOT on the call please confirm that this works for you; whether it matters which Monday afternoon it is; and we'll schedule out 6 more months of meetings.

* Possible face to face meeting in the spring;

9) PUBLICATIONS

Jill asked if there were any preferences as to where to resend our rejected ViDeNet manuscript. If no other suggestions are forthcoming, it will go to EDUCAUSE. Samir & Jill are working on a manuscript for a Spring Middleware developers meeting in Brazil.

10) IP

Tyler explained that the commObject management software was developed under contract to I2 and UNC had agreed to open source, free distribution of the resulting software. We discussed whether a videoconferencing directory service could be either self-sustaining or profitable; it would be good to be able to fund the activities of the ViDe

organization if this were the case.