Meeting Minutes 2003 11 24

-- Agenda: -- Review / Modify Agenda Accept Minutes of Last Meeting Review Current Action Item List Review Deliverables status: *LDIF conversion to ASN.1 (Nadim) *ECS Beta Testing (Tyler, Nadim, Jason, RADVISION) *HCL Proxy Testing (Tyler, Larry A., Samir) *Simple Web Management Interface (Jason, Jill) *SIP/H.323 Multipoint Call using H.350 with NSF (Everyone) *H.323 Endpoint distribution (Tyler, RADVISION) *Document SSL with LDAP (Jason) *How to register your endpoint with global search (Egon, Henny) *Subtree search discussion summary (Egon) *Cookbook version 0.5 (Jason, Jill) Discuss "Shib vs. Certs" -- Attendees: -- Jason Lynn - U.A.B. Jill Gemmill - U.A.B. Samir Chatterjee - C.G.U. Nadim El-Khoury - U.N.C. Tyler Johnson - U.N.C. -- Action Items: -- Tyler - Send ASN.1 to Study Group Nadim - Fit Aditya's code into ViDe Website Jason - Send Nadim Aditya's code Jason - Send Room and Device Object Class information to Tyler Jason - Test ECS Directory / Security issues -- Meeting: --

The group should plan on having a face-to-face meeting in Indianapolis on March 22nd. There now exists a Java API to an Opensource SIP stack. C.G.U. to work on converting SIP client over to this opensource stack. Estimated two months work. Nadim has created the ASN.1 file from the LDIFs and has sent this file to Tyler. Tyler will send this file to the Study Group.

Tyler and Jason have the ECS gatekeeper running. Tyler says that the gatekeeper looks good, but there doesn't appear to be any SSL support. Tyler and Larry have been testing HCL proxy. They both have run into problems testing the proxy. Northwestern has previously crashed the server, but HCL has recently sent a patch to fix that problem. Tyler mentioned that for the current state of the proxy, one would need an LDAP administrator to run it which is unreasonable. The installation and administration should become much easier before it is suitable for general use. The price for the proxy server, however, is very reasonable. Jason says that he has the 'search' and 'display' aspects of the Simple Web Interface working, but the edit is not yet working. He predicts that it can be completed by sometime in December. Tyler thinks that Kevin Thompson wasn't so much concerned with the H.323/Sip bridging as he was with the project as a whole. Jill believes the group should schedule some meetings that Kevin can join in early 2004. On this note, Tyler asked how important briding was to this project. Jill stated that there are no deliverables and that it wasn't an original goal of the project. Tyler said that we should distribute the RADVISION endpoint by asking those who wish to acquite the endpoint to contact RADVISION. In this way, RADVISION can interface directly with the customer and perhaps spawn off other business relationships from this contact. He also said another option would be to contact U.N.C. and they could get them in touch with RADVISION. Testbed participants could just contact Jason. Jason said that the SSL support for the LDAP directories may be completed for the 0.5 release. If not, it should be completed early December. Egon's report on progress of the indexing for registering a directory for global search didn't sound promising. It has been determined that we will use Aditya's code in the meantime until the indexing is completed. Nadim will take the code and fit it into the ViDe website. Jason to send Nadim the code. Jill said that we can put a link to the existing search in the cookbook and have those who wish to have their directory searched can get in contact with Jason. Nadim reported that the LDAP Analyzer is adding H.350 support. Tyler said that some vendors would like to implement H.350 but they are not user-centric. They are more likely to associate and endpoint with a room, or just by itself. He said we should look into other object classes that can support this. Jason said that there are standard 'Room' and 'Device' objects and they are both listed in the cookbook. Tyler asked if we should subclass the 'Room' and 'Device' objects to distinguish themselves from other non-video objects. Jason and Nadim did not think we should subclass these objects. We do not subclass iNetOrgPerson, so why should we subclass these? Tyler posed the question, what are the authentication issues with using these objects versus using a person object? We should explore this further. Egon was not able to make it to the meeting, but it was determined that the subtree search discussion was brought up by him. It was the fact that we are searching for a user in a directory instead of just using the complete DN to find the user. It was determined that we are following the LDAP cookbook recipe in doing the search.

Added postmeeting:

Egon:

“I'm happy with that now. At the I2 meeting I also checked with Michael Gettes and he explained to me that as long as the indexing is OK for the directory the penalty for doing a subtree search is very low. Only those directories that do not have their indexing in order will be hit harder. But the cookbook describes on which attributes to index (besides the 'normal' person attributes to index, as described in the LDAP recipe).”

Jill:

“I also pointed out that there are many kinds of certificates - 'PKI' is usually used to be synonymous with individual user issued certs, where the end user keeps their private key and the application knows how to find the root issuing authority (from a previously-installed list of trusted authorities). As Egon notes, this is already (maybe not 'common', but certainly not 'unusual') used for encrypting email and some other applications. I believe VC should know what to do with these type of certificates. 'PKI Lite' I will use to refer to applications where a TRUSTED SERVER's PRIVATE KEY is used to proxy for user authentication - that is: using some OTHER authentication method (Kerberos, LDAP, .....) a server will issue a certificate for you. The server keeps its private key, and the same key is used to sign certs issued for each locally authenticated person. The certificate should have the information the application needs - user's name, root CA, expiration date (which will tend to be short - like '24 hours' or 'duration of this call') and probably some indication that it is a proxy. It's still an X.509-style certificate technically; it's a policy matter whether they're accepted or not. What kind of certificates fall into this category? KX.509 - Jon Peterson's SIP Authentication Authority - GRID proxy certificates. We could issue "ViDeNet" certificates. I believe VC should know what to do with these kinds of certificates. 'PGP' - mentioned a couple of times by Samir - this is the "lightest" in that only the two users involved in the call need to recognize each other - no other authorities needed. I believe this is useful and could be a 'most lightweight' type of certificate used, and the application should accept these kinds of certificates. (these don't look like an X.509, do they?) Accepted all these certificates and having a standardized way to negotiate capabilities from most robust to least would be something useful for endpoints to do. Call this Step 1. Now we've got the possibility of a more complex authorization decision (which types of certficates are allow to do what, and under what circumstances?) This is too complex for the application to handle itself - BUT - it is possible for the application to be designed to hand such a decision off to a trusted authorization engine - like David Chadwick's PERMIS, as an example - and then proceed based on an answer. Let's call integration with an authoritization engine Step 2.”

Samir said that MSIQ is coming out with an article on creating standards. Samir contacted them and told them of H.350. They said that they would be interested in speaking with us, but they thought we should have some sort of theory on how the group created the standard. Jill began the discussion on 'Shib vs. Certs' by saying that she believes that the only way to do this reasonably is with certificates. Either PKI style or S-MIME style, it shouldn't matter. The application should only need to know how to find the certificate, validate it, and how to negotiate encryption. Tyler said that he believes that end user certificates are not becoming more popular for two reasons; 1. The security environment hasn't pushed the use of certificates, until recently and 2. Most applications cannot deal with certificates. Therefore, there is no reason to go to PKI.

Added Postmeeting:

Egon:

“Danger conclusion. We're doing research/innovation and should anticipate what will happen in the not to distant future. If you believe that PKI will not happen for some time, we can go with the conclusion above. If we think that PKI will have it's breakthrough within the next 2-3 years, we might as well prepare for it. NB. We're using user certificates for mail and web-access, and VPN tunnels. So most apps I'm using for my work. Only one missing is VC. [OK, maybe I'm not the average Joe Enduser, but don't say certificates aren't here or can't be used] So I agree with Samir on this and to answer Nadim: within 2 years it is used, shouldn't we at least prepare ?”

Tyler:

“I was arguing that this was a reason PI has not taken off, but that is changing. I further argued that if we had a PKI-enabled application (i.e. H.235 Annex E/F of S/MIME) then those obstacles would fall away. I am in favor of pursuing PKI as the preferred method of authenticating and encrypting video calls.”

Samir said that he is seeing PKI in many different places. Healthcare applications are carrying it and government institutions are mandating it. He also said that besides the authentication and authorization aspects of PKI, the encryption is another great benefit. Nadim said that he had nothing against PKI, but asked when would the group implement this. He said that there are many things in the works now (higher education CA, etc.) that would benefit the group at a later date. Tyler said that RADVISION is releasing PKI support in their stack and he proposed that we could pursue this further.