Jill Gemmill, UAB
Art Vandenberg, GSU
Ego Verharen, SURFnet
John McNair, Tennessee
Lisa Hogeboom, Internet2
Ken Klingenstein, Internet2
Steve Olshansky, Internet2
Jeanette Fielden, Internet2
Tyler Johnson, UNC – Chapel Hill
The ViDe.net tool is currently the only tool that is commObject enabled. The tool allows people to request video, voice conferencing services, be granted those services by system administrators and takes that data, puts it in a directory and publishes searchable white pages in addition to configuration information. It is not a scheduling tool. There is consideration of packaging it for distribution to multiple sites to implement on their own. The tool is currently designed as a multi-user multi-domain central tool that everyone comes to use. Part of the issue is what pieces to currently distribute since there is concern that it won't be widely implemented due to the complexity of the install. There is also no continuing funding to operate it centrally. Out of the 150 ViDe.net sites there are perhaps six that have the resources to bring this up on their own. The need to figure out the relationship of the distributed vs. centralized service model was emphasized because that helps us shape development and the cookbook that will help people to implement it. Even with documentation how much deployment will we get? Jill has funds to hire an FTE to help with early adopters and test bed for the remaining 18 months of the grant.
A number of questions were raised: If this was cast this as a federated service that provided videoconferencing, white pages and Authn/Z would only one mechanism be needed to service that entire community? Could it be done in a way that would allow campuses that have their own commObject directory to live on their own and those that didn't could use the centralized one until they wanted to move it locally? For schools that have their own enterprise directory and commObject set up and implemented is there a mechanism to integrate that someway with the ViDe.net or point to it?
Jill confirmed that the desired approach is find a way to let schools with their own directory and commObject set up be able to integrate with ViDe.net. How to accomplish the integration is somewhat dependent on the policies of the institution. From the enterprise directory point of view all an institution needs to do is add one or more URI's pointing to commObject directories. However, the institution can have additional procedures for getting that information into the directory.
Tyler pointed out from a technical perspective all you have to do on your enterprise directory is get a link added to the schema for your person attributes. But, you still have lots of authentication decisions to make. You have questions about whether or not your enterprise directory will support non-people resources, which right now represent the bulk of conferencing activity, such as conference rooms etc. Enterprise directories don't support that currently. UNC trying to support and bill for this and it's been very complex.
One of the purposes of putting this huge directory out there and trying to get it populated is to drive the market to implement the already standardized clickable dialing. It's largely the chicken and egg issue. People don't implement clickable dialing because directory not there. The directory is not there because the dialing to use it doesn't exist. What are needed are a few campuses willing to make an early investment knowing that payoff may be down the line.
A possible business model might be: an institution would pay $X per year to be hosted on the server. Individuals at the institution could come and sign up for service at $Y a year, which could be split 50/50 with the institution. The part kept would cover ongoing operations. As long as there are enough users it doesn't cost the institution. People want the new technology but they don't know how to recover costs for it. Is the tool we're providing really a service that allows people to cost recover the technology? Would Internet2 or others organizations view this as a reasonable business model? Is the administration structure in place? Jill emphasized that this needs to be looked at independent of developing a business model as well. Perhaps there are early adopters willing to invest in development. The issue of constrained state budgets also needs to be considered.
A one-page description what's been done and what remains to be done for engaging
in the easy videoconferencing space is needed.
[AI] Steve will spearhead a one-page description of where we are in the easy videoconferencing space.
There is a new version of H.235 that is up for ratification in May. We have been invited to submit a security profile for H.323 and H.320 to that meeting. The good news is we're being offered an opportunity to have a direct influence on producing a security profile, the bad news is the time frame is very tight and there is concern over allocating resources. There is a raconteur meeting in mid-February so we would need a mature draft by then. We need to assess, do we have enough resources to do this in the time available?
Currently, the changes proposed to H.235 are fixing minor issues with Annex E, and D. There is currently no effort to produce an additional profile. We can either write an Annex G or take an existing annex and propose a profile for it. Since Annex E uses certificates a profile that would be Kerberos or *.509 would be reasonable since E is close to being able to support those now. If it were more substantively different it would need to be a different annex. The hard part of this approach, is that most of the intelligence of kx.509 is not in the generation of the certificate but in the processing of the certificate and placing it in a location for H.323 Annex E. This process is not independent of the client and the client's operating system. This suggests not a new annex but a profile with an emphasis on getting the certificate into the right location for a client to use. There was consensus that the preferred approach is to focus on things that work under Annex E. There is a sentence in Annex E that says this is designed for x.509 certificates. Our proposed change is insert generic language there to see profile A, which would describe some more generic types of certificates, where do you find them, what's in them, how do you get them into the client for transport.
Art pointed out that it appears that Cisco is taking a similar approach using the same model of an authentication authorizing H.323 between administrated domains via hop to hop of gatekeepers. Egon and Jill will look at what Cisco is doing since Cisco is proposing things that are not dissimilar to what VidMid is trying to do with Authn/Z. The Cisco links that Egon mailed are all based on existing H.323 and SIP implementations. It is still partly proprietary since Cisco describes their own IZCT protocol. One question is: Since the user agent client software sends the crypto token to the gatekeeper over UDP connections how are they going to secure it?
Jill's concern is that the security issue is a key one that may impede implementation/adoption
and needs to be addressed. In general, if these are supposed to be security
profiles they do not mandate secure sockets between gatekeepers, plus UDP doesn't
support secure sockets. So how is it secured? This may be why it's not yet implemented.
Before we say, "all you need to do is implement Annex E" we need to
consider adjusting the standard since it's not securable as written. One approach
might be don't use UDP. A second approach could be: you must write ipsec (IP
security protocol) in your protocol. They could have the client software open
ipsec to the gatekeeper to secure the connections but it's not part of the security
profile. This would be a proposal that's an easy improvement of the existing
Annex E and doesn't require rewriting the protocol. The contents should look
as much as possible like the contents for the SIP invite message.
[AI] Steve will follow up with Jon Peterson on his SIP proposals to the IETF and what he views as next steps.
The new Internet2 Website is live. If you find dead or missing links please let Steve or Jeanette know. Mockups of the new VidMid VC and VOD pages will be forthcoming as well.
There will be a combined call for VC and Authn/Z on December 16, 2002 at 11:00