Network Working Group M. Wahl Internet-Draft Informed Control Inc. Intended status: Standards Track August 30, 2006 Expires: March 3, 2007 LDAP Administrator Address Attribute draft-wahl-ldap-adminaddr-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 3, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Wahl Expires March 3, 2007 [Page 1] Internet-Draft LDAP Administrator Address Attribute August 2006 Abstract Organizations running multiple directory servers need an ability for administrators to determine who is responsible for a particular server. An attribute, conceptually similar to the 'sysContact' object of SNMP, is defined which can retrieved from the directory server using the Lightweight Directory Access Protocol. Wahl Expires March 3, 2007 [Page 2] Internet-Draft LDAP Administrator Address Attribute August 2006 1. Introduction This document defines an optional attribute for use in LDAP [1]. This attribute was originally defined in the mid-1990s for inclusion in the LDAPv3 data model, but was omitted from the LDAPv3 root DSE specification as there was only one implementation of a server supporting that attribute at that time. The words "MUST", "SHOULD" and "MAY" are used as defined in RFC 2119 [2]. Please send comments to the author at mark.wahl@informed-control.com. Wahl Expires March 3, 2007 [Page 3] Internet-Draft LDAP Administrator Address Attribute August 2006 2. The administratorsAddress attribute This attribute allows a server administrator to provide the contact information of the responsible party for an LDAP server or naming context. This can be used by management clients which are, for example, checking the state of a replication or referral topology, to provide a way for the user of the management client to send email to manager of a particular server. The attribute is defined as follows (with lines wrapped for readability): ( 1.3.6.1.4.1.1466.101.120.1 NAME 'administratorsAddress' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE directoryOperation ) This attribute can contain one or more values, and each value is a URI [3]. Each URI is encoded using the IA5 string syntax [5]. Unlike the labeledURI attribute [6], these values do not have a label. This document only specifies how a client can read this attribute. Some servers MAY support updating this attribute over protocol, subject to access control, however for many servers it is anticipated that the values of this attribute would be configured through the server's out-of-band management interface, such as in a configuration file. In existing practice, this URI is commonly of the 'mailto:' form identifying a role mail address, such as "mailto:helpdesk@example.com". To obtain the responsible party for a directory server, the attribute is read from the root DSE, using a baseObject search as described in RFC 4512 [4]. To obtain the responsible party for a naming context, the attribute is read from the entry at the base of the naming context. Note that these addresses need not be the same as that of the directory server administrator, or of a data administrator. Wahl Expires March 3, 2007 [Page 4] Internet-Draft LDAP Administrator Address Attribute August 2006 3. Security Considerations The server's access control policy SHOULD allow this information to be visible to any suitable administrator in the same organization. Since one use of this attribute is to find who is responsible if the server is not making authentication decisions properly, it MAY be visible to all users who are permitted to access the directory server. The administrator SHOULD choose addresses for use in this attribute that are already publically known within the organization, and SHOULD NOT encode passwords or other secret information within the URIs. Wahl Expires March 3, 2007 [Page 5] Internet-Draft LDAP Administrator Address Attribute August 2006 4. IANA Considerations This attribute will be registered as follows: Subject: Request for LDAP Descriptor Registration Descriptor: administratorsAddress Object Identifier: 1.3.6.1.4.1.1466.101.120.1 Person & email address to contact for further information: Mark Wahl Usage: attribute type Specification: (I-D) RFC XXXX Author/Change Controller: Mark Wahl Wahl Expires March 3, 2007 [Page 6] Internet-Draft LDAP Administrator Address Attribute August 2006 5. Acknowledgments The contents of this document is based on earlier work of the ASID Working Group of the IETF. The contributions of its members is greatly appreciated. Wahl Expires March 3, 2007 [Page 7] Internet-Draft LDAP Administrator Address Attribute August 2006 6. References 6.1. Normative References [1] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [3] Berners-Lee, T., "Uniform Resource Identifier (URI): Generic Syntax", RFC 1738, STD 66, January 2005. [4] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. [5] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. 6.2. Informative References [6] Smith, M., "Definition of an X.500 Attribute Type and Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079. Wahl Expires March 3, 2007 [Page 8] Internet-Draft LDAP Administrator Address Attribute August 2006 Appendix A. Copyright Copyright (C) The Internet Society 2006. This document is subject to the rights, licenses and restrictions contained in BCP 78, 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. Wahl Expires March 3, 2007 [Page 9] Internet-Draft LDAP Administrator Address Attribute August 2006 Author's Address Mark Wahl Informed Control Inc. PO Box 90626 Austin, TX 78709 US Email: mark.wahl@informed-control.com Wahl Expires March 3, 2007 [Page 10] Internet-Draft LDAP Administrator Address Attribute August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, 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 procedures with respect to rights in RFC 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wahl Expires March 3, 2007 [Page 11]