Requirements for H.ldap
Dear Mr. Johnson and other experts who are interested in H.ldap, One of the action points from the previous SG16 meeting in October 2002 is to make a requirement capture as recorded in the meeting report COM16-R25: "At the WP2 review session, it was suggested to formulate a requirements capture that would serve a check at the final stage of standardization. We can find a good precedent in D.281 for H.248.MCU." I have tried a draft as attached based on the following materials: - AVD-2199 Directory Services Architecture for Multimedia Conferencing (RADVISION, ViDe, Internet2), June 2002, Bruges - D271 Directory Services Architecture for Multimedia Conferencing (Cisco Systems, Inc.) - COM16-R25 Report of WP2/16, October 2002 - TD-61/WP2 Directory Services Work Plan (Q4/16 Rapporteur), October 2002 Your additions, deletions, reorganization, improved wordings etc are very much welcome. -- Best regards, OKUBO Sakae e-mail: okubo@giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* Draft AVD-2279 Source: TBD Title: Requirements for H.ldap "Directory Services Architecture for Multimedia Conferencing" Date: 11 January 2003 Purpose: Proposal H.ldap will be able to support the following requirements as seen from the human user, gatekeeper and terminal configuration. The list will also serve as a checklist to verify that the proposed specification will support listed items. Some of the features are marked as advanced features and will be part of the future extension. 1. General 1/ Service administrators need call servers that are aware of enterprise directories, to avoid duplication of account management processes. Users need directories to locate other users with whom they wish to communicate. All of these processes should pull their information from canonical data sources in order to reduce redundant processes and ensure information accuracy. [AVD-2199] 2/ H.ldap should accommodate H.320, H.324, SIP or other call signaling protocols concurrently with or subsequently to H.323, subject to decision of the group. [COM16-R25] 3/ The fact that recent videoconferencing products are mostly of H.323/H.320 hybrid should be taken into account. [COM16-R25] 4/ Standards should include information to facilitate implementation in addition to normative specifications. [COM16-R25] 5/ It should be possible to create very large-scale distributed directories. These could include white pages "portals" that allow searching for users across multiple institutions. In this application, each enterprise directory would register itself with (or be unknowingly discovered by) a directory of directories that is capable of searching across multiple LDAP directories. [AVD-2199] 2. Object Classes 1/ Enable endpoint information to be associated with people (or resources such as conference rooms). [AVD-2199] 2/ Enable online searchable "white pages" where dialing information (e.g. H.323 URL) can be found, along with other "traditional" directory information about a user, such as name, address, telephone, email, etc. [AVD-2199] 3/ Enable all endpoint information to be stored in a canonical data source (the Directory), rather than local to the gatekeeper, so that endpoints can be managed through manipulations of an enterprise directory, rather than by direct entry into the gatekeeper. [AVD-2199] 4/ Store enough information about endpoint configuration so that correct configuration settings can be documented to end users on a per-endpoint basis, as a support tool. [AVD-2199] 5/ Include H.323 zone information - such as the zone administrators, network identity of the gatekeeper and resources associated with the zone. [AVD-2199] 6/ Be able to support multiple instances of endpoints per user. [AVD-2199] 7/ Enable a "whois" functionality for H.323 zones, so that one may query the network and find contact information for a particular H.323 zone, and published resources associated with the zone. [AVD-2199] 8/ Be extendable as necessary. [AVD-2199] Defining a minimum in the standard with provision of an extension mechanism has been a good practice. [COM16-R25] Careful consideration is needed for what should be in the standard and what should be left for extension. [COM16-R25] 9/ Be able to encompass H.32x, SIP or other related conferencing protocols in the future. [D271] 3. Security, authentication and authorization 1/ It is important that the H.323 LDAP infrastructure support not only H.235 Annex D (hop-by-hop authentication) and Annex E (end-to-end authentication) modes, but that an organization could shift from one mode to the other without reconstructing the schema. [AVD-2199] 2/ Associate authentication information with a user and enable both endpoint and gatekeeper access to that information, in order to support H.235 Annexes D and E. [AVD-2199] 3/ It should allow both endpoint-centric and user-centric authentication. [AVD-2199] Authentication credentials, such as certificate or user ID / password for station and that for user can be separate. This separation allows for flexibility in the implementation of security architectures. [COM16-R25] 4/ It should be possible to use the directory to manage the services that are authorized for each endpoint or user once authentication is achieved. [D271] ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
Dr. OKUBO, Thank you for your efforts. This appears to capture rather completely the sum of comments and interests in this issue. We plan to submit a draft recommendation at the upcoming meeting in San Jose that addresses these issues, along with the normative organization that was suggested by numerous Study Group members. I would like to add that we have discussed items 2-5 and 2-7 at length and have concluded that these attributes that we originally proposed, while useful, should not be included in the standard. The reasons are that in numerous other similar standards this information is ommitted, and that the information may only be relevant to certain implementations. They are quoted here for reference ******** 2-5/ Include H.323 zone information - such as the zone administrators, network identity of the gatekeeper and resources associated with the zone. [AVD-2199] 2-7/ Enable a "whois" functionality for H.323 zones, so that one may query the network and find contact information for a particular H.323 zone, and published resources associated with the zone. [AVD-2199] **************** Also, there has arisen some concern about item 3-4: 3-4/ It should be possible to use the directory to manage the services that are authorized for each endpoint or user once authentication is achieved. [D271] To solve this problem using LDAP, we have created an attribute called h323IdentityAuthorization. However, this attribute does not exist anywhere else in the h.323 protocol. So we are not merely representing an attribute that is already defined, but creating a new functionality. Many of the developers I have spoken to are supportive of this idea, as it gives them a direct place to store information about what services each endpoint is entitled to access. Thus, it has direct commercial value. On the hand, from a more theoritical perspective, in the creation of large scale systems, it may be more appropriate to handle authorization through the use of an external authorization server. In that case, the h323IdentityAuthorization attribute would not be used. The advantage of including this attribute in the standard is that each vendor could refer to it by name, opening up the possibility that multiple gatekeepers could interact with the same LDAP server without change to the LDAP server, by means of a simple mapping. If we do not standardize the name, the LDAP schema would have to be redefined for each gatekeeper. The disadvantage is that the attribute may not always be used. I would like to get feedback from the Study Group 16 members as to whether they feel the h323IdentityAuthorization attribute should be included in the standard. Best Regards, Tyler Johnson OKUBO Sakae wrote:
Dear Mr. Johnson and other experts who are interested in H.ldap,
One of the action points from the previous SG16 meeting in October 2002 is to make a requirement capture as recorded in the meeting report COM16-R25:
"At the WP2 review session, it was suggested to formulate a requirements capture that would serve a check at the final stage of standardization. We can find a good precedent in D.281 for H.248.MCU."
I have tried a draft as attached based on the following materials:
- AVD-2199 Directory Services Architecture for Multimedia Conferencing (RADVISION, ViDe, Internet2), June 2002, Bruges - D271 Directory Services Architecture for Multimedia Conferencing (Cisco Systems, Inc.) - COM16-R25 Report of WP2/16, October 2002 - TD-61/WP2 Directory Services Work Plan (Q4/16 Rapporteur), October 2002
Your additions, deletions, reorganization, improved wordings etc are very much welcome.
-- Best regards,
OKUBO Sakae e-mail: okubo@giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan
GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************
Draft AVD-2279 Source: TBD Title: Requirements for H.ldap "Directory Services Architecture for Multimedia Conferencing" Date: 11 January 2003 Purpose: Proposal
H.ldap will be able to support the following requirements as seen from the human user, gatekeeper and terminal configuration. The list will also serve as a checklist to verify that the proposed specification will support listed items. Some of the features are marked as advanced features and will be part of the future extension.
1. General
1/ Service administrators need call servers that are aware of enterprise directories, to avoid duplication of account management processes. Users need directories to locate other users with whom they wish to communicate. All of these processes should pull their information from canonical data sources in order to reduce redundant processes and ensure information accuracy. [AVD-2199]
2/ H.ldap should accommodate H.320, H.324, SIP or other call signaling protocols concurrently with or subsequently to H.323, subject to decision of the group. [COM16-R25]
3/ The fact that recent videoconferencing products are mostly of H.323/H.320 hybrid should be taken into account. [COM16-R25]
4/ Standards should include information to facilitate implementation in addition to normative specifications. [COM16-R25]
5/ It should be possible to create very large-scale distributed directories. These could include white pages "portals" that allow searching for users across multiple institutions. In this application, each enterprise directory would register itself with (or be unknowingly discovered by) a directory of directories that is capable of searching across multiple LDAP directories. [AVD-2199]
2. Object Classes
1/ Enable endpoint information to be associated with people (or resources such as conference rooms). [AVD-2199]
2/ Enable online searchable "white pages" where dialing information (e.g. H.323 URL) can be found, along with other "traditional" directory information about a user, such as name, address, telephone, email, etc. [AVD-2199]
3/ Enable all endpoint information to be stored in a canonical data source (the Directory), rather than local to the gatekeeper, so that endpoints can be managed through manipulations of an enterprise directory, rather than by direct entry into the gatekeeper. [AVD-2199]
4/ Store enough information about endpoint configuration so that correct configuration settings can be documented to end users on a per-endpoint basis, as a support tool. [AVD-2199]
5/ Include H.323 zone information - such as the zone administrators, network identity of the gatekeeper and resources associated with the zone. [AVD-2199]
6/ Be able to support multiple instances of endpoints per user. [AVD-2199]
7/ Enable a "whois" functionality for H.323 zones, so that one may query the network and find contact information for a particular H.323 zone, and published resources associated with the zone. [AVD-2199]
8/ Be extendable as necessary. [AVD-2199] Defining a minimum in the standard with provision of an extension mechanism has been a good practice. [COM16-R25] Careful consideration is needed for what should be in the standard and what should be left for extension. [COM16-R25]
9/ Be able to encompass H.32x, SIP or other related conferencing protocols in the future. [D271]
3. Security, authentication and authorization
1/ It is important that the H.323 LDAP infrastructure support not only H.235 Annex D (hop-by-hop authentication) and Annex E (end-to-end authentication) modes, but that an organization could shift from one mode to the other without reconstructing the schema. [AVD-2199]
2/ Associate authentication information with a user and enable both endpoint and gatekeeper access to that information, in order to support H.235 Annexes D and E. [AVD-2199]
3/ It should allow both endpoint-centric and user-centric authentication. [AVD-2199] Authentication credentials, such as certificate or user ID / password for station and that for user can be separate. This separation allows for flexibility in the implementation of security architectures. [COM16-R25]
4/ It should be possible to use the directory to manage the services that are authorized for each endpoint or user once authentication is achieved. [D271]
----------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
participants (2)
-
OKUBO Sakae -
Tyler Miller Johnson