result in search times sufficiently long to render some applications
unusable. Notably, user and alias lookup should be fast. The Annex
A Indexing Profile describes an indexing configuration for
SIPIdentity directories that will be optimized for use in directory
of directories applications. Use of this profile is optional.
SIPIdentitySIPURI: equality
SIPIdentityRegistrarAddress: no recommendation
SIPIdentityProxyAddress: no recommendation
SIPIdentityAddress: equality
SIPIdentityUserName: equality
SIPIdentityPassword: no recommendation
SIPIdentityServiceLevel: equality
6. Acknowledgments
We are grateful to numerous colleagues for reaching across multiple
boundaries of standards bodies, research networks, academia and
private industry in order to produce an architecture that works
toward integrating multimedia conferencing deployments. In
particular, standards from both IETF and ITU-T were drawn from
extensively, and the architecture is meant to serve all communities.
This work developed out of the Video Conferencing Middleware
(VidMid-VC) working group, a joint effort of Internet2
(www.internet2.edu) and the Video Development Initiative
(www.vide.net). The architecture was developed in response to
deployment challenges discovered in the ViDeNet
(https//:videnet.unc.edu) academic test bed providing video and voice
over IP infrastructure across research networks internationally.
This work was supported in part by a grant from the United States
National Science Foundation contract number ANI-0222710.
7. Security Considerations
This section is not present in the ITU-T standard, but gives
information for the IETF community. Its content has the consensus of
the ITU-T Study Group 16.
H.350 does not alter the security architectures of any particular
protocol. However, it does offer a standardized place to store
authentication credentials where appropriate. It should be noted
that both H.323 and SIP support shared secret authentication (H.235
Annex D and HTTP Digest, respectively). These approaches require
that the call server have access to the password. Thus, if the call
server or H.350 directory is compromised, passwords also may become
compromised. These weaknesses may be due to weaknesses in the
systems (H.350 directory or call servers) and their operation rather
than in H.350 per se.
The userSMIMECertificate attribute is defined in RFC 2798 (section
2.8) as a part of inetOrgPerson. The SIP user agent’s X.509
certificate can be stored in this attribute. When the certificate is
present, it can be employed with S/MIME to provide authentication,
integrity, and confidentiality as specified in RFC 3261 [5].
It is strongly encouraged that call servers and an H.350 directory
mutually authenticate each other before sharing information.
Further, it is strongly encouraged that communications between H.350
directories and call servers or endpoints happen over secure
communication channels such as SSL or TLS.
Finally, access control lists on LDAP servers are a matter of policy
and are not a part of the standard. System administrators are
advised to use common sense when setting access control on H.350
attributes. For example, password attributes should only be
accessible by the authenticated user, while address attributes might
be publicly available.
8. References
8.1. Normative References
[1] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
(v3): Technical Specification", RFC 3377, September 2002.
[2] ITU-T Recommendation H.350, "Directory services architecture for
multimedia conferencing", 2003.
[3] ITU-T Recommendation H.350.4, "Directory services architecture
for SIP", 2003.
[4] Franks, J., Hallam-Baker P., Hostetler, J., Lawrence, S., Leach,
P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic
and Digest Access Authentication", RFC 2617, June 1999.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[7] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
RFC 2798, April 2000.
8.2. Informative References
[8] ITU-T Recommendation H.350.1, "Directory services architecture
for H.323", 2003.
[9] ITU-T Recommendation H.350.2, "Directory services architecture
for H.235", 2003.
[10] ITU-T Recommendation H.350.3, "Directory services architecture
for H.320", 2003.
[11] ITU-T Recommendation H.350.5, "Directory services architecture
for Non-Standard Protocols", 2003.
[12] ITU-T Recommendation H.350.6, "Directory services architecture
for Call Forwarding and Preferences", 2004.
[13] Howes T. and M. Smith, "Understanding And Deploying LDAP
Directory Services", New Riders Publishing, ISBN: 1578700701,
1999.
[14] Howes T. and M. Smith, "LDAP Programming Directory-Enabled
Applications with Lightweight Directory Access Protocol", New
Riders Publishing, ISBN: 1578700000, 1997.
9. Relationship to Other Specifications
This specification is an RFC publication of an ITU-T publication [4],
without textual changes within the standard itself (Section 4). The
present section appears in the RFC publication only. In order for
this specification to be implemented properly, a number of standards
pertaining to LDAP [1], [7], H.350 [2],[3], and SIP [4], [5], [6],
[7], need to be implemented in whole or in part by the implementor.
For some background information on the ITU and IETF directory service
protocols, reading [8], [9], [10], [11], and [12] is valuable, and
[13] and [14] are recommended books.
10. Authors’ Addresses
Tyler Johnson
Editor, H.350
University of North Carolina
Chapel Hill, NC 27599
Phone: +1.919.843.7004
EMail: Tyler_Johnson@unc.edu
Sakae Okubo
Rapporteur for Q.4/16, ITU-T SG16
Waseda University
YRP Ichibankan, 3-4 Hikarinooka
Yokosuka-shi, 239-0847 Japan
Phone: +81 46 847 5406
EMail: sokubo@waseda.jp
Simao Ferraz de Campos Neto
Counsellor, ITU-T SG 16
International Telecommunication Union
Place des Nations
Geneva CH1211 - Switzerland
Phone: +41-22-730-6805
EMail: simao.campos@itu.int
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and at www.rfc-editor.org, and except as set
forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC’s procedures with respect to rights in ISOC Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.