From 4fff3cc0affae7625c63d08b152bea24f6217811 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Mon, 29 Dec 2003 18:41:46 +0000 Subject: [PATCH] Sync with HEAD --- .../draft-zeilenga-ldap-collective-xx.txt | 507 ------- .../draft-zeilenga-ldap-features-xx.txt | 283 ---- doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt | 283 ---- .../draft-zeilenga-ldap-subentry-xx.txt | 675 ---------- doc/rfc/INDEX | 8 +- doc/rfc/rfc3663.txt | 1179 +++++++++++++++++ doc/rfc/rfc3671.txt | 563 ++++++++ doc/rfc/rfc3672.txt | 675 ++++++++++ doc/rfc/rfc3673.txt | 283 ++++ doc/rfc/rfc3674.txt | 283 ++++ 10 files changed, 2990 insertions(+), 1749 deletions(-) delete mode 100644 doc/drafts/draft-zeilenga-ldap-collective-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-features-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-subentry-xx.txt create mode 100644 doc/rfc/rfc3663.txt create mode 100644 doc/rfc/rfc3671.txt create mode 100644 doc/rfc/rfc3672.txt create mode 100644 doc/rfc/rfc3673.txt create mode 100644 doc/rfc/rfc3674.txt diff --git a/doc/drafts/draft-zeilenga-ldap-collective-xx.txt b/doc/drafts/draft-zeilenga-ldap-collective-xx.txt deleted file mode 100644 index 4b20138d06..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-collective-xx.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -INTERNET-DRAFT Editor: Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 18 August 2002 - - - Collective Attributes in LDAP - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial comments - directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - X.500 collective attributes allow common characteristics to be shared - between collections of entries. This document summarizes the X.500 - information model for collective attributes and describes use of - collective attributes in LDAP (Lightweight Directory Access Protocol). - This document provides schema definitions for collective attributes - for use in LDAP. - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 1] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - -Conventions - - Schema definitions are provided using LDAPv3 description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) for - readability. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - -1. Introduction - - In X.500, a collective attribute is "a user attribute whose values are - the same for each member of an entry collection" [X.501]. This - document details their use in the Lightweight Directory Access - Protocol (LDAP) [LDAPTS]. - - -1.1. Entry Collections - - A collection of entries is a grouping of object and alias entries - based upon common properties or shared relationship between the - corresponding entries which share certain attributes. An entry - collection consists of all entries within scope of a collective - attributes subentry [SUBENTRY]. An entry can belong to several entry - collections. - - -1.2. Collective Attributes - - Attributes shared by the entries comprising an entry collection are - called collective attributes. Values of collective attributes are - visible but not updateable to clients accessing entries within the - collection. Collective attributes are updated (i.e. modified) via - their associated collective attributes subentry. - - When an entry belongs to multiple entry collections, the entry's - values of each collective attribute are combined such that independent - sources of these values are not manifested to clients. - - Entries can specifically exclude a particular collective attribute by - listing the attribute as a value of the collectiveExclusions - attribute. Like other user attributes, collective attributes are - subject to a variety of controls including access, administrative, and - content controls. - - - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 2] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - -2. System Schema for Collective Attributes - - The following operational attributes are used to manage Collective - Attributes. LDAP servers [LDAPTS] MUST act in accordance with the - X.500 Directory Models [X.501] when providing this service. - - -2.1. collectiveAttributeSubentry - - Subentries of this object class are used to administer collective - attributes and are referred to as collective attribute subentries. - - ( 2.5.20.2 NAME 'collectiveAttributeSubentry' AUXILIARY ) - - A collective attribute subentry SHOULD contain at least one collective - attribute. The collective attributes contained within a collective - attribute subentry are available for finding, searching, and - comparison at every entry within the scope of the subentry. The - collective attributes, however, are administered (e.g. modified) via - the subentry. - - Implementations of this specification SHOULD support collective - attribute subentries in both collectiveAttributeSpecificArea - (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative - areas [SUBENTRY][X.501]. - - -2.2. collectiveAttributeSubentries - - The collectiveAttributeSubentries operational attribute identifies all - collective attribute subentries that affect the entry. - - ( 2.5.18.12 NAME 'collectiveAttributeSubentries' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - USAGE directoryOperation NO-USER-MODIFICATION ) - - -2.3. collectiveExclusions - - The collectiveExclusions operational attribute allows particular - collective attributes to be excluded from an entry. It MAY appear in - any entry and MAY have multiple values. - - ( 2.5.18.7 NAME 'collectiveExclusions' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 - USAGE directoryOperation ) - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 3] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - The descriptor excludeAllCollectiveAttributes is associated with the - OID 2.5.18.0. When this descriptor or OID is present as a value of - the collectiveExclusions attribute, all collective attributes are - excluded from an entry. - - -3. Collective Attribute Types - - A userApplications attribute type can be defined to be COLLECTIVE - [RFC2252]. This indicates that the same attribute values will appear - in the entries of an entry collection subject to the use of the - collectiveExclusions attribute and other administrative controls. - These administrative controls MAY include DIT Content Rules, if - implemented. - - Collective attribute types are commonly defined as subtypes of non- - collective attribute types. By convention, collective attributes are - named by prefixing the name of their non-collective supertype with - "c-". For example, the collective telephone attribute is named - c-TelephoneNumber after its non-collective supertype telephoneNumber. - - Non-collective attributes types SHALL NOT subtype collective - attributes. - - Collective attributes SHALL NOT be SINGLE-VALUED. Collective - attribute types SHALL NOT appear in the attribute types of an object - class definition. - - Operational attributes SHALL NOT be defined to be collective. - - The remainder of section provides a summary of collective attributes - derived from those defined in [X.520]. The SUPerior attribute types - are described in [RFC 2256] for use with LDAP. - - Implementations of this specification SHOULD support the following - collective attributes and MAY support additional collective - attributes. - - -3.1. Collective Locality Name - - The c-l attribute type specifies a locality name for a collection of - entries. - - ( 2.5.4.7.1 NAME 'c-l' - SUP l COLLECTIVE ) - - - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 4] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - -3.2. Collective State or Province Name - - The c-st attribute type specifies a state or province name for a - collection of entries. - - ( 2.5.4.8.1 NAME 'c-st' - SUP st COLLECTIVE ) - - -3.3. Collective Street Address - - The c-street attribute type specifies a street address for a - collection of entries. - - ( 2.5.4.9.1 NAME 'c-street' - SUP street COLLECTIVE ) - - -3.4. Collective Organization Name - - The c-o attribute type specifies an organization name for a collection - of entries. - - ( 2.5.4.10.1 NAME 'c-o' - SUP o COLLECTIVE ) - - -3.5. Collective Organizational Unit Name - - The c-ou attribute type specifies an organizational unit name for a - collection of entries. - - ( 2.5.4.11.1 NAME 'c-ou' - SUP ou COLLECTIVE ) - - -3.6. Collective Postal Address - - The c-PostalAddress attribute type specifies a postal address for a - collection of entries. - - ( 2.5.4.16.1 NAME 'c-PostalAddress' - SUP postalAddress COLLECTIVE ) - - -3.7. Collective Postal Code - - The c-PostalCode attribute type specifies a postal code for a - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 5] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - collection of entries. - - ( 2.5.4.17.1 NAME 'c-PostalCode' - SUP postalCode COLLECTIVE ) - - -3.8. Collective Post Office Box - - The c-PostOfficeBox attribute type specifies a post office box for a - collection of entries. - - ( 2.5.4.18.1 NAME 'c-PostOfficeBox' - SUP postOfficeBox COLLECTIVE ) - - -3.9. Collective Physical Delivery Office Name - - The c-PhysicalDeliveryOfficeName attribute type specifies a physical - delivery office name for a collection of entries. - - ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName' - SUP physicalDeliveryOfficeName COLLECTIVE ) - - -3.10. Collective Telephone Number - - The c-TelephoneNumber attribute type specifies a telephone number for - a collection of entries. - - ( 2.5.4.20.1 NAME 'c-TelephoneNumber' - SUP telephoneNumber COLLECTIVE ) - - -3.11. Collective Telex Number - - The c-TelexNumber attribute type specifies a telex number for a - collection of entries. - - ( 2.5.4.21.1 NAME 'c-TelexNumber' - SUP telexNumber COLLECTIVE ) - - -3.13. Collective Facsimile Telephone Number - - The c-FacsimileTelephoneNumber attribute type specifies a facsimile - telephone number for a collection of entries. - - ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber' - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 6] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - SUP facsimileTelephoneNumber COLLECTIVE ) - - -3.14. Collective International ISDN Number - - The c-InternationalISDNNumber attribute type specifies an - international ISDN number for a collection of entries. - - ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber' - SUP internationalISDNNumber COLLECTIVE ) - - -4. Security Considerations - - Collective attributes, like other attributes, are subject to access - control restrictions and other administrative policy. Generally - speaking, collective attributes accessed via an entry in a collection - are governed by rules restricting access to attributes of that entry. - And collective attributes access via a subentry are governed by rules - restricting access to attributes of that subentry. However, as LDAP - does not have a standard access model, the particulars of each - server's access control system may differ. - - General LDAP security considerations [LDAPTS] also apply. - - -5. IANA Considerations - - It is requested that IANA register upon Standards Action the LDAP - descriptors [LDAPIANA] defined in this technical specification. The - following registration template is suggested: - - Subject: Request for LDAP Descriptor Registration - Descriptor see comments - Object Identifier: see comment - Person & email address to contact for further information: - Kurt Zeilenga - Usage: see comment - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: - - NAME Type OID - ------------------------ ---- ----------------- - c-FacsimileTelephoneNumber A 2.5.4.23.1 - c-InternationalISDNNumber A 2.5.4.25.1 - c-PhysicalDeliveryOffice A 2.5.4.19.1 - c-PostOfficeBox A 2.5.4.18.1 - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 7] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - c-PostalAddress A 2.5.4.16.1 - c-PostalCode A 2.5.4.17.1 - c-TelephoneNumber A 2.5.4.20.1 - c-TelexNumber A 2.5.4.21.1 - c-l A 2.5.4.7.1 - c-o A 2.5.4.10.1 - c-ou A 2.5.4.11.1 - c-st A 2.5.4.8.1 - c-street A 2.5.4.9.1 - collectiveAttributeSubentries A 2.5.18.12 - collectiveAttributeSubentry O 2.5.20.2 - collectiveExclusions A 2.5.18.7 - - where Type A is Attribute and Type O is ObjectClass. - - - The Object Identifiers used in this document were assigned by the - ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify - elements of X.500 schema [X.520]. This document make no OID - assignments, it only provides LDAP schema descriptions with existing - elements of X.500 schema. - - -6. Acknowledgments - - This document is based upon the ITU Recommendations for the Directory - [X.501][X.520]. - - -7. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -8. Normative References - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax - Definitions", RFC 2252, December 1997. - - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 8] - -INTERNET-DRAFT LDAP Collective Attributes 18 August 2002 - - - [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use - with LDAPv3", RFC 2256, December 1997. - - [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", - draft-ietf-ldapbis-ldapv3-ts-xx.txt. - - [SUBENTRY] K. Zeilenga, S. Legg, "Subentries in LDAP", - draft-zeilenga-ldap-subentry-xx.txt, a work in progress. - - [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993. - - -9. Informative References - - [X.500] "The Directory: Overview of Concepts, Models", ITU-T - Recommendation X.500, 1993. - - [X.520] "The Directory: Selected Attribute Types", ITU-T - Recommendation X.520, 1993. - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS 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. - - - - - -Zeilenga draft-zeilenga-ldap-collective-08 [Page 9] - diff --git a/doc/drafts/draft-zeilenga-ldap-features-xx.txt b/doc/drafts/draft-zeilenga-ldap-features-xx.txt deleted file mode 100644 index 73b6ae4f6a..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-features-xx.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 26 May 2003 - - - Feature Discovery in LDAP - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as an Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial comments - directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - Please see the Full Copyright section near the end of this document - for more information. - - -Abstract - - The Lightweight Directory Access Protocol (LDAP) is an extensible - protocol with numerous elective features. This document introduces a - general mechanism for discovery of elective features and extensions - which cannot be discovered using existing mechanisms. - - - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 1] - -INTERNET-DRAFT LDAP supportedFeatures 26 May 2003 - - -1. Background and Intended Use - - The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an - extensible protocol with numerous elective features. LDAP provides - mechanisms for a client to discover supported protocol versions, - controls, extended operations, Simple Authentication and Security - Layer (SASL) mechanisms, and subschema information. However, these - mechanisms are not designed to support general feature discovery. - - This document describes a simple, general-purpose mechanism which - clients may use to discover the set of elective features supported by - a server. For example, this mechanism could be used by a client to - discover whether or not the server supports requests for all - operational attributes, e.g. "+" [OPATTRS]. As another example, this - mechanism could be used to discover absolute true, e.g. "(&)" and - false, e.g. "(|)", search filters [T-F] support. - - This document extends the LDAP Protocol Mechanism registry [RFC3383] - to support registration of values of the supportedFeatures attribute. - This registry is managed by the Internet Assigned Numbers Authority - (IANA). - - Schema definitions are provided using LDAP description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) for - readability. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - -2. Discovery of supported features - - Each elective feature whose support may be discovered SHALL be - identified by an Object Identifier (OID). A server advertises its - support for a given feature by providing the OID associated with the - feature as a value of the 'supportedFeatures' attribute held in the - root DSE. A client may examine the values of this attribute to - determine if a particular feature is supported by the server. A - client MUST ignore values it doesn't recognize as they refer to - elective features it doesn't implement. - - Features associated with Standard Track protocol mechanisms MUST be - registered. Features associated with other protocol mechanisms SHOULD - be registered. Procedures for registering protocol mechanisms are are - described in [RFC3383]. "Feature" should be placed in the usage field - of the submitted LDAP Protocol Mechanism template. - - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 2] - -INTERNET-DRAFT LDAP supportedFeatures 26 May 2003 - - - The 'supportedFeatures' attribute type is described as follows: - - ( 1.3.6.1.4.1.4203.1.3.5 - NAME 'supportedFeatures' - DESC 'features supported by the server' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 - USAGE dSAOperation ) - - Servers MUST be capable of recognizing this attribute type by the name - 'supportedFeatures'. Servers MAY recognize the attribute type by - other names. - - -4. Security Considerations - - As rogue clients can discover features of a server by other means - (such as by trial and error), this feature discovery mechanism is not - believed to introduce any new security risk to LDAP. - - -5. IANA Considerations - -5.1. Registration of Features as Protocol Mechanisms - - Future specifications detailing LDAP features are to register each - feature as a LDAP Protocol Mechanism per guidance given in BCP 64 - [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration - template indicates that the value to be registered is associated with - an LDAP feature. - - -5.2. Registration of the supportedFeatures descriptor - - It is requested that IANA register upon Standards Action the LDAP - 'supportedFeatures' descriptor. The following registration template - is suggested: - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): supportedFeatures - Object Identifier: 1.3.6.1.4.1.4203.1.3.5 - Person & email address to contact for further information: - Kurt Zeilenga - Usage: Attribute Type - Specification: RFC XXXX - Author/Change Controller: IESG - - This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 3] - -INTERNET-DRAFT LDAP supportedFeatures 26 May 2003 - - - assigned private enterprise allocation [PRIVATE] for use in this - specification. - - -6. Acknowledgment - - This document is based upon input from the IETF LDAPEXT working group. - - -7. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -8. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille, - "Lightweight Directory Access Protocol (v3): Attribute - Syntax Definitions", RFC 2252, December 1997. - - [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, - September 2002. - - [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64 - (also RFC 3383), September 2002. - - -9. Informative References - - [OPATTRS] Zeilenga, K., "LDAPv3: All Operational Attributes", - draft-zeilenga-ldap-opattrs-xx.txt, a work in progress. - - [T-F] Zeilenga, K., "LDAP True/False Filters", - draft-zeilenga-ldap-t-f-xx.txt, a work in progress. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - - - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 4] - -INTERNET-DRAFT LDAP supportedFeatures 26 May 2003 - - -Intellectual Property Rights - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it has made any - effort to identify any such rights. Information on the IETF's - procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can be obtained - from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - -Full Copyright - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - - - - - - - - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 5] - diff --git a/doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt b/doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt deleted file mode 100644 index 38e0bf1a69..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 1 November 2002 - - - - LDAPv3: All Operational Attributes - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extensions Working Group - mailing list . Please send editorial comments - directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - The Lightweight Directory Access Protocol (LDAP) supports a mechanism - for requesting the return of all user attributes but not all - operational attributes. This document describes an LDAP extension - which clients may use to request the return of all operational - attributes. - - - -Zeilenga LDAP All Op Attrs [Page 1] - -INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002 - - -1. Overview - - X.500 [X.500] provides a mechanism for clients to request all - operational attributes be returned with entries provided in response - to a search operation. This mechanism is often used by clients to - discover which operational attributes are present in an entry. - - This documents extends the Lightweight Directory Access Protocol - (LDAP) [RFC3377] to provide a simple mechanism which clients may use - to request the return of all operational attributes. The mechanism is - designed for use with existing general purpose LDAP clients (including - web browsers which support LDAP URLs) and existing LDAP APIs. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - -2. All Operational Attributes - - The presence of the attribute description "+" (ASCII 43) in the list - of attributes in a Search Request [RFC2251] SHALL signify a request - for the return of all operational attributes. - - As with all search requests, client implementors should note that - results may not include all requested attributes due to access - controls or other restrictions. Client implementors should also note - that certain operational attributes may be returned only if requested - by name even when "+" is present. This is because some operational - attributes are very expensive to return. - - Servers supporting this feature SHOULD publish the Object Identifier - 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures' - [FEATURES] attribute in the root DSE. - - -3. Interoperability Considerations - - This mechanism is specifically designed to allow users to request all - operational attributes using existing LDAP clients. In particular, - the mechanism is designed to be compatible with existing general - purpose LDAP clients including those supporting LDAP URLs [RFC2255]. - - The addition of this mechanism to LDAP is not believed to cause any - significant interoperability issues (this has been confirmed through - testing). Servers which have yet to implement this specification - should ignore the "+" as an unrecognized attribute description per - [RFC2251, Section 4.5.1]. From the client's perspective, a server - - - -Zeilenga LDAP All Op Attrs [Page 2] - -INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002 - - - which does not return all operational attributes when "+" is requested - should be viewed as having other restrictions. - - It is also noted that this mechanism is believed to require no - modification of existing LDAP APIs. - - -4. Security Considerations - - This document provides a general mechanism which clients may use to - discover operational attributes. Prior to the introduction of this - mechanism, operational attributes where only returned when requested - by name. Some might have viewed this as obscurity" feature. However, - this sense of security as the attributes were still transferable. - - Implementations SHOULD implement appropriate access controls - mechanisms to restricts access to operational attributes. - - -5. IANA Considerations - - This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the - feature described above. This OID was assigned [ASSIGN] by OpenLDAP - Foundation, under its IANA-assigned private enterprise allocation - [PRIVATE], for use in this specification. - - Registration of this feature is requested [FEATURES][RFC3383]. - - Subject: Request for LDAP Protocol Mechanism Registration - - Object Identifier: 1.3.6.1.4.1.4203.1.5.1 - - Description: All Op Attrs - - Person & email address to contact for further information: - Kurt Zeilenga - - Usage: Feature - - Specification: RFCxxxx - - Author/Change Controller: IESG - - Comments: none - - -6. Acknowledgment - - - - -Zeilenga LDAP All Op Attrs [Page 3] - -INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002 - - - The "+" mechanism is believed to have been first suggested by Bruce - Greenblatt in a November 1998 post to the IETF LDAPext Working Group - mailing list. - - -7. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -8. Normative References - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol - (v3): Technical Specification", RFC 3377, September 2002. - - [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga- - ldap-features-xx.txt (a work in progress). - - -9. Informative References - - [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255, - December 1997. - - [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also - RFC 3383), September 2002. - - [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, - Models and Service", 1993. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - - - -Zeilenga LDAP All Op Attrs [Page 4] - -INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002 - - - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga LDAP All Op Attrs [Page 5] - diff --git a/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt b/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt deleted file mode 100644 index deca7fd207..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Date: 18 August 2002 Steven Legg -Expires in six months Adacel Technologies - - - Subentries in LDAP - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial comments - directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - In X.500 directories, subentries are special entries used to hold - information associated with a subtree or subtree refinement. This - document adapts X.500 subentries mechanisms for use with Lightweight - Directory Access Protocol (LDAP). - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 1] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - -Conventions - - Schema definitions are provided using LDAP description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) for - readability. - - Protocol elements are described using ASN.1 [X.680]. The term - "BER-encoded" means the element is to be encoded using the Basic - Encoding Rules [X.690] under the restrictions detailed in Section 5.1 - of [RFC2251]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - -1. Overview - - From [X.501]: - A subentry is a special kind of entry immediately subordinate to - an administrative point. It contains attributes that pertain to a - subtree (or subtree refinement) associated with its administrative - point. The subentries and their administrative point are part of - the same naming context. - - A single subentry may serve all or several aspects of - administrative authority. Alternatively, a specific aspect of - administrative authority may be handled through one or more of its - own subentries. - - Subentries in Lightweight Directory Access Protocol (LDAP) [LDAPTS] - SHALL behave in accordance with X.501 unless noted otherwise in this - specification. - - In absence of the subentries control (detailed in Section 3), - subentries SHALL NOT be considered in one-level and subtree scope - search operations. For all other operations, including base scope - search operations, subentries SHALL be considered. - - -2. Subentry Schema - -2.1. Subtree Specification Syntax - - The Subtree Specification syntax provides a general purpose mechanism - for the specification of a subset of entries in a subtree of the - Directory Information Tree (DIT). A subtree begins at some base entry - and includes the subordinates of that entry down to some identified - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 2] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - lower boundary, possibly extending to the leaf entries. A subtree - specification is always used within a context or scope which - implicitly determines the bounds of the subtree. For example, the - scope of a subtree specification for a subschema administrative area - does not include the subtrees of any subordinate administrative point - entries for subschema administration. Where a subtree specification - does not identify a contiguous subset of the entries within a single - subtree the collection is termed a subtree refinement. - - This syntax corresponds to the SubtreeSpecification ASN.1 type - described in [X.501], Section 11.3. This ASN.1 data type definition - is reproduced here for completeness. - - SubtreeSpecification ::= SEQUENCE { - base [0] LocalName DEFAULT { }, - COMPONENTS OF ChopSpecification, - specificationFilter [4] Refinement OPTIONAL } - - - LocalName ::= RDNSequence - - ChopSpecification ::= SEQUENCE { - specificExclusions [1] SET OF CHOICE { - chopBefore [0] LocalName, - chopAfter [1] LocalName } OPTIONAL, - minimum [2] BaseDistance DEFAULT 0, - maximum [3] BaseDistance OPTIONAL} - - BaseDistance ::= INTEGER (0 .. MAX) - - Refinement ::= CHOICE { - item [0] OBJECT-CLASS.&id, - and [1] SET OF Refinement, - or [2] SET OF Refinement, - not [3] Refinement } - - The components of SubtreeSpecification are: base, which identifies the - base entry of the subtree or subtree refinement, and - specificExclusions, minimum, maximum and specificationFilter, which - then reduce the set of subordinate entries of the base entry. The - subtree or subtree refinement contains all the entries within scope - that are not excluded by any of the components of the subtree - specification. When all of the components of SubtreeSpecification are - absent (i.e. when a value of the Subtree Specification syntax is the - empty sequence, {}), the subtree so specified implicitly includes all - the entries within scope. - - Any particular use of this mechanism MAY impose limitations or - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 3] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - constraints on the components of SubtreeSpecification. - - The LDAP syntax specification is: - - ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' ) - - The native LDAP encoding of values of this syntax is defined by the - Generic String Encoding Rules [GSER]. Appendix A provides an - equivalent ABNF for this syntax. - - -2.1.1. Base - - The base component of SubtreeSpecification nominates the base entry of - the subtree or subtree refinement. The base entry may be an entry - which is subordinate to the root entry of the scope in which the - subtree specification is used, in which case the base component - contains a sequence of RDNs relative to the root entry of the scope, - or may be the root entry of the scope itself (the default), in which - case the base component is absent or contains an empty sequence of - RDNs. - - Entries that are not subordinates of the base entry are excluded from - the subtree or subtree refinement. - - -2.1.2. Specific Exclusions - - The specificExclusions component of a ChopSpecification is a list of - exclusions that specify entries and their subordinates to be excluded - from the the subtree or subtree refinement. The entry is specified by - a sequence of RDNs relative to the base entry (i.e. a LocalName). - Each exclusion is of either the chopBefore or chopAfter form. If the - chopBefore form is used then the specified entry and its subordinates - are excluded from the subtree or subtree refinement. If the chopAfter - form is used then only the subordinates of the specified entry are - excluded from the subtree or subtree refinement. - - -2.1.3. Minimum and Maximum - - The minimum and maximum components of a ChopSpecification allow the - exclusion of entries based on their depth in the DIT. - - Entries that are less than the minimum number of RDN arcs below the - base entry are excluded from the subtree or subtree refinement. A - minimum value of zero (the default) corresponds to the base entry. - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 4] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - Entries that are more than the maximum number of RDN arcs below the - base entry are excluded from the subtree or subtree refinement. An - absent maximum component indicates that there is no upper limit on the - number of RDN arcs below the base entry for entries in the subtree or - subtree refinement. - -2.1.4. Specification Filter - - The specificationFilter component is a boolean expression of - assertions about the values of the objectClass attribute of the base - entry and its subordinates. A Refinement assertion item evaluates to - true for an entry if that entry's objectClass attribute contains the - OID nominated in the assertion. Entries for which the overall filter - evaluates to false are excluded from the subtree refinement. If the - specificationFilter is absent then no entries are excluded from the - subtree or subtree refinement because of their objectClass attribute - values. - - -2.2. Administrative Role Attribute Type - - The Administrative Model defined in [X.501], clause 10 requires that - administrative entries contain an administrativeRole attribute to - indicate that the associated administrative area is concerned with one - or more administrative roles. - - The administrativeRole operational attribute is specified as follows: - - ( 2.5.18.5 NAME 'administrativeRole' - EQUALITY objectIdentifierMatch - USAGE directoryOperation - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - - The possible values of this attribute defined in X.501 are: - - OID NAME - -------- ------------------------------- - 2.5.23.1 autonomousArea - 2.5.23.2 accessControlSpecificArea - 2.5.23.3 accessControlInnerArea - 2.5.23.4 subschemaAdminSpecificArea - 2.5.23.5 collectiveAttributeSpecificArea - 2.5.23.6 collectiveAttributeInnerArea - - Other values may be defined in other specifications. Names associated - with each administrative role are Object Identifier Descriptors - [LDAPIANA]. - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 5] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - The administrativeRole operational attribute is also used to regulate - the subentries permitted to be subordinate to an administrative entry. - A subentry not of a class permitted by the administrativeRole - attribute cannot be subordinate to the administrative entry. - - -2.3. Subtree Specification Attribute Type - - The subtreeSpecification operational attribute is defined as follows: - - ( 2.5.18.6 NAME 'subtreeSpecification' - SINGLE-VALUE - USAGE directoryOperation - SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 ) - - This attribute is present in all subentries. See [X.501], clause 10. - Values of the subtreeSpecification attribute nominate collections of - entries within the DIT for one or more aspects of administrative - authority. - - -2.4. Subentry Object Class - - The subentry object class is a structural object class. - - ( 2.5.20.0 NAME 'subentry' - SUP top STRUCTURAL - MUST ( cn $ subtreeSpecification ) ) - - -3. Subentries Control - - The subentries control MAY be sent with a searchRequest to control the - visibility of entries and subentries which are within scope. - Non-visible entries or subentries are not returned in response to the - request. - - The subentries control is an LDAP Control whose controlType is - 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent), - and controlValue contains a BER-encoded BOOLEAN indicating visibility. - A controlValue containing the value TRUE indicates that subentries are - visible and normal entries are not. A controlValue containing the - value FALSE indicates that normal entries are visible and subentries - are not. - - Note that TRUE visibility has the three octet encoding { 01 01 FF } - and FALSE visibility has the three octet encoding { 01 01 00 }. - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 6] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - The controlValue SHALL NOT be absent. - - In absence of this control, subentries are not visible to singleLevel - and wholeSubtree scope Search requests but are visible to baseObject - scope Search requests. - - There is no corresponding response control. - - This control is not appropriate for non-Search operations. - - -4. Security Considerations - - Subentries often hold administrative information or other sensitive - information and should be protected from unauthorized access and - disclosure as described in [RFC2829][RFC2830]. - - General LDAP [LDAPTS] security considerations also apply. - - -5. IANA Considerations - -5.1 Descriptors - - It is requested that IANA register upon Standards Action the LDAP - descriptors detailed in this technical specification. The following - registration template is suggested: - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): see comment - Object Identifier: see comment - Person & email address to contact for further information: - Kurt Zeilenga - Usage: see comment - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: - - NAME Type OID - ------------------------ ---- -------- - accessControlInnerArea R 2.5.23.3 - accessControlSpecificArea R 2.5.23.2 - administrativeRole A 2.5.18.5 - autonomousArea R 2.5.23.1 - collectiveAttributeInnerArea R 2.5.23.6 - collectiveAttributeSpecificArea R 2.5.23.5 - subentry O 2.5.20.0 - subschemaAdminSpecificArea R 2.5.23.4 - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 7] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - subtreeSpecification A 2.5.18.6 - - where Type A is Attribute, Type O is ObjectClass, and Type R is - Administrative Role. - - -5.2 Object Identifiers - - This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an LDAP - protocol element defined herein. This OID was assigned [ASSIGN] by - OpenLDAP Foundation, under its IANA-assigned private enterprise - allocation [PRIVATE], for use in this specification. - - Other OIDs which appear in this document were either assigned by the - ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify - elements of X.500 schema or assigned in RFC 2252 for the use described - here. - - -5.3 Protocol Mechanisms - - Registration of the protocol mechanisms defined in this document is - requested [LDAPIANA]. - - Subject: Request for LDAP Protocol Mechansism Registration - - Object Identifier: 1.3.6.1.4.1.4203.1.10.1 - - Description: Subentries - - Person & email address to contact for further information: - Kurt Zeilenga - - Usage: Control - - Specification: RFCxxxx - - Author/Change Controller: IESG - - Comments: none - - -6. Acknowledgment - - This document is based on engineering done by IETF LDUP and LDAPext - Working Groups including "LDAP Subentry Schema" by Ed Reed. This - document also borrows from a number of ITU documents including X.501. - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 8] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - -7. Authors' Addresses - - Kurt D. Zeilenga - OpenLDAP Foundation - - Email: Kurt@OpenLDAP.org - - Steven Legg - Adacel Technologies Ltd. - 405-409 Ferntree Gully Road - Mount Waverley, Victoria 3149 - AUSTRALIA - - Phone: +61 3 9451 2107 - Fax: +61 3 9541 2121 - EMail: steven.legg@adacel.com.au - - -8. Normative References - - [X.501] ITU-T, "The Directory -- Models," X.501, 1993. - - [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - - Specification of Basic Notation", X.680, 1994. - - [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, - Canonical, and Distinguished Encoding Rules", X.690, 1994. - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (was RFC 2119), March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax - Definitions", RFC 2252, December 1997. - - [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, - "Authentication Methods for LDAP", RFC 2829, May 2000 - - [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory - Access Protocol (v3): Extension for Transport Layer - Security", RFC 2830, May 2000. - - [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", - draft-ietf-ldapbis-ldapv3-ts-xx.txt, a work in progress. - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 9] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - [GSER] S. Legg, "Generic String Encoding Rules for ASN.1 Types", - draft-legg-ldapext-gser--xx.txt, a work in progress. - - [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf- - ldapbis-iana-xx.txt, a work in progress. - - -9. Informative References - - [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [GCE] S. Legg, "Common Elements of GSER Encodings", - draft-legg-ldap-gser-abnf-xx.txt, a work in progress. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - - -A. Subtree Specification ABNF - - This appendix is non-normative. - - The LDAP-specific native string encoding for the Subtree Specification - syntax is specified by the Generic String Encoding Rules [GSER]. The - ABNF [RFC2234] in this appendix for this syntax is provided only as a - convenience and is equivalent to the encoding specified by the - application of [GSER]. Since the SubtreeSpecification ASN.1 type may - be extended in future editions of [X.501], the provided ABNF should be - regarded as a snapshot in time. The native LDAP encoding for any - extension to the SubtreeSpecification ASN.1 type can be determined - from [GSER]. - - In the event that there is a discrepancy between this ABNF and the - encoding determined by [GSER], [GSER] is to be taken as definitive. - - SubtreeSpecification = "{" [ sp ss-base ] - [ sep sp ss-specificExclusions ] - [ sep sp ss-minimum ] - [ sep sp ss-maximum ] - [ sep sp ss-specificationFilter ] - sp "}" - - ss-base = id-base msp LocalName - ss-specificExclusions = id-specificExclusions msp SpecificExclusions - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 10] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - ss-minimum = id-minimum msp BaseDistance - ss-maximum = id-maximum msp BaseDistance - ss-specificationFilter = id-specificationFilter msp Refinement - - id-base = %x62.61.73.65 ; "base" - id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73 - %x69.6F.6E.73 ; "specificExclusions" - id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum" - id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum" - id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46 - %x69.6C.74.65.72 ; "specificationFilter" - - SpecificExclusions = "{" sp SpecificExclusion - *( "," sp SpecificExclusion ) sp "}" - SpecificExclusion = chopBefore / chopAfter - chopBefore = id-chopBefore ":" LocalName - chopAfter = id-chopAfter ":" LocalName - id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore" - id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter" - - Refinement = item / and / or / not - item = id-item ":" OBJECT-IDENTIFIER - and = id-and ":" Refinements - or = id-or ":" Refinements - not = id-not ":" Refinement - Refinements = "{" [ sp Refinement - *( "," sp Refinement ) ] sp "}" - id-item = %x69.74.65.6D ; "item" - id-and = %x61.6E.64 ; "and" - id-or = %x6F.72 ; "or" - id-not = %x6E.6F.74 ; "not" - - BaseDistance = INTEGER-0-MAX - - The , , , , and - rules are defined in [GCE]. - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 11] - -INTERNET-DRAFT Subentries in LDAP 18 August 2002 - - - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga draft-zeilenga-ldap-subentry-07 [Page 12] - diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index 56418ae152..074e295be4 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -32,7 +32,11 @@ rfc3112.txt LDAP Authentication Password Schema (I) rfc3296.txt Named Subordinate References in LDAP (PS) rfc3377.txt LDAP(v3): Technical Specification (PS) rfc3383.txt IANA Considerations for LDAP (BCP) - +rfc3663.txt Domain Administrative Data in LDAP (E) +rfc3671.txt Collective Attributes in LDAP (PS) +rfc3672.txt Subentries in the LDAP (PS) +rfc3673.txt LDAPv3: All Operational Attributes (PS) +rfc3674.txt Feature Discovery in LDAP (PS) Legend: STD Standard @@ -43,4 +47,6 @@ E Experimental FYI For Your Information BCP Best Common Practice +Please see http://www.rfc-editor.org/ for up-to-date status information. + $OpenLDAP$ diff --git a/doc/rfc/rfc3663.txt b/doc/rfc/rfc3663.txt new file mode 100644 index 0000000000..7ae70f61b9 --- /dev/null +++ b/doc/rfc/rfc3663.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group A. Newton +Request for Comments: 3663 VeriSign, Inc. +Category: Experimental December 2003 + + + Domain Administrative Data + in Lightweight Directory Access Protocol (LDAP) + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + Domain registration data has typically been exposed to the general + public via Nicname/Whois for administrative purposes. This document + describes the Referral Lightweight Directory Access Protocol (LDAP) + Service, an experimental service using LDAP and well-known LDAP types + to make domain administrative data available. + + + + + + + + + + + + + + + + + + + + + + + + + +Newton Experimental [Page 1] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Historical Directory Services for Domain Registration + Data . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Motivations. . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Abbreviations Used . . . . . . . . . . . . . . . . . . . 4 + 2. Service Description. . . . . . . . . . . . . . . . . . . . . . 4 + 3. Registry LDAP Service. . . . . . . . . . . . . . . . . . . . . 6 + 3.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 6 + 3.1.2. Allowed Searches . . . . . . . . . . . . . . . . 7 + 3.1.3. Access Control . . . . . . . . . . . . . . . . . 7 + 3.2. Name Server DIT. . . . . . . . . . . . . . . . . . . . . 8 + 3.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 8 + 3.2.2. Allowed Searches . . . . . . . . . . . . . . . . 8 + 3.3. Registrar Referral DIT . . . . . . . . . . . . . . . . . 9 + 3.3.1. DIT Structure. . . . . . . . . . . . . . . . . . 9 + 4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . . 10 + 4.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 10 + 4.1.2. Allowed Searches . . . . . . . . . . . . . . . . 11 + 4.1.3. Access Control . . . . . . . . . . . . . . . . . 11 + 4.2. Name Server and Contact DIT. . . . . . . . . . . . . . . 12 + 4.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 12 + 4.2.2. Allowed Searches . . . . . . . . . . . . . . . . 13 + 5. Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.1. Intra-Server Referrals . . . . . . . . . . . . . . . . . 14 + 6.2. Inter-Server Referrals . . . . . . . . . . . . . . . . . 15 + 6.3. Common DIT . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.4. Universal Client . . . . . . . . . . . . . . . . . . . . 16 + 6.5. Targeting Searches by Tier . . . . . . . . . . . . . . . 16 + 6.6. Data Mining. . . . . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16 + 8. Internationalization Considerations. . . . . . . . . . . . . . 16 + 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17 + 10. Intellectual Property Statement. . . . . . . . . . . . . . . . 17 + 11. Normative References . . . . . . . . . . . . . . . . . . . . . 18 + Appendix A. Other Work. . . . . . . . . . . . . . . . . . . . . . 19 + Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21 + + + + + + + + +Newton Experimental [Page 2] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +1. Introduction + + This document describes the Referral Lightweight Directory Access + Protocol (LDAP) Service, an experimental project launched by + VeriSign, Inc., to explore the use of LDAP and LDAP-related + technologies for use as a directory service of administrative domain + registration information. + +1.1. Historical Directory Services for Domain Registration Data + + The original National Science Foundation contract for the InterNIC + called for the creation of an X.500 directory service for the + administrative needs of the domain registration data and information. + Due to problems with implementations of X.500 server software, a + server based on the Nicname/Whois [1] protocol was temporarily + erected. + + In 1994, the Rwhois [3] protocol was introduced to enhance the + Nicname/Whois protocol. This directory service never gained wide + acceptance for use with domain data. + + Presently, ICANN requires the operation of Nicname/Whois servers by + registries and registrars of generic Top-Level Domains (TLD's). + +1.2. Motivations + + With the recent split in functional responsibilities between + registries and registrars, the constant misuse and data-mining of + domain registration data, and the difficulties with machine- + readability of Nicname/Whois output, the creation of the Referral + LDAP Service had the following motivations: + + o Use a mechanism native to the directory protocol to refer clients + from inquiries about specific domains made at a registry to the + appropriate domain within the appropriate directory service at a + registrar. + + o Limit access to domain data based on authentication of the client. + + o Provide structured queries and well-known and structured results. + + o Use a directory service technology already in general use. + + Given these general criteria, LDAP [5] was selected as the protocol + for this directory service. The decision was also made to restrict + the use of LDAP to features most readily available in common + implementations. Therefore, a goal was set to not define any new + object classes, syntaxes, or matching rules. + + + +Newton Experimental [Page 3] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + + The experiment was successful in exploring how LDAP might be used in + this context and demonstrating the level of customization required + for an operational service. Conclusions and observations about this + experiment are outlined in Section 6. + +1.3. Abbreviations Used + + The following abbreviations are used to describe the nature of this + experiment: + + TLD: Top-Level Domain. Refers to the domain names just beneath + the root in the Domain Name System. This experiment used the + TLD's .com, .net, .org, and .edu. + + SLD: Second-Level Domain. Refers to the domain names just beneath + a TLD in the Domain Name System. An example of such a domain name + would be "example.com". + + DIT: Directory Information Tree. One of many hierarchies of data + entries in an LDAP server. + + DN: Distinguished Name. The unique name of an entry in a DIT. + + cn: common name. See RFC 2256 [7]. + + dc: domain component. See RFC 2247 [4]. + + uid: user id. See RFC 2798 [9]. + +2. Service Description + + The service is composed of three distinct server types: a registry + LDAP server, registrar LDAP servers, and registrant LDAP servers. + + The registry LDAP server contains three Directory Information Trees + (DIT's). + + o The Top-Level Domain DIT's follow the DNS hierarchy for domains + (e.g., dc=foo,dc=com). + + o The name server DIT allows a view of the name servers, many of + which serve multiple domains. + + o The registrar-referral DIT provides referrals from the registry + into the respective TLD DIT of the registrars (on a TLD basis). + + + + + + +Newton Experimental [Page 4] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + + The registrar LDAP server contains two types of DIT's. + + o The TLD DIT follows the DNS hierarchy for domains (e.g., + dc=foo,dc=com) and parallels the TLD DIT of the registry. + + o The name server and contact DIT allow a view of the name servers + and contacts, many of which are associated and serve multiple + domains. + + There is no specification on the DIT or schema for the registrant + LDAP server. Referrals from the registrar server to the registrant + server are provided solely for the purpose of allowing the registrant + direct control over extra administrative information as it relates to + a particular domain. + + Access control for this service is merely a demonstration of using a + Distinguished Name (DN) and password. Should registries and + registrars uniformly adopt LDAP as a means to disseminate domain + registration data, standardization of these DN's would need to be + undertaken based on each type of user base. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton Experimental [Page 5] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +3. Registry LDAP Service + +3.1. TLD DIT + +3.1.1. DIT Structure + + The registry TLD DIT has the following structural hierarchy: + + TLD (e.g., dc=net) + | + | + ------------------------------------- + | | + SLD (e.g., dc=foo,dc=net) SLD (e.g., dc=bar,dc=net) + | | + --------------------- --------------------- + | | | | | | + name server | | name server | | + (e.g., | | (e.g., | | + cn=nameserver1, | | cn=nameserver1, | | + dc=foo,dc=net ) | | dc=bar,dc=net ) | | + | | | | + name server | name server | + (e.g., | (e.g., | + cn=nameserver2, | cn=nameserver2, | + dc=foo,dc=net ) | dc=bar,dc=net ) | + | | + registrar referral registrar referral + (e.g., (e.g., + cn=registrar, cn=registrar, + dc=foo,dc=net ) dc=bar,dc=net ) + + + Figure 1: Registry DIT Overview + + The root of a TLD DIT is an entry of objectclass domain as specified + by RFC 2247 [4] and represents a top-level domain. + + The second tier of the DIT represents second-level domains. Each of + these entries is of objectclass domain as specified by RFC 2247 [4]. + The description attribute on these entries often contains descriptive + text giving the name of the registrar through which these domains + have been registered. + + The third tier contains entries specific to each second-level domain. + Name server entries are of objectclass ipHost as specified by RFC + 2307 [8]. The distinguished names of these name server entries are + algorithmically calculated, where the first component is the word + + + +Newton Experimental [Page 6] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + + "nameserver" concatenated with an index number of the name server + entry and the remaining components are the appropriate domain names. + There is no specification relating the value of the name server entry + to the index it may be assigned other than it is unique and + consistent with respect to the client session. This tier also + contains the referral from the registry to the registrar. This + referral is a direct referral to the entry in the appropriate + registrar LDAP server corresponding to the domain name that the + referral falls beneath in this DIT. + +3.1.2. Allowed Searches + + Because of the vast number of entries contained within this DIT, only + certain types of searches are allowed. Allowing any search + expressible via LDAP would lead to expensive searches that would be + far too costly for a publicly available service. The searches + allowed are as follows: + + o One-level scoped searches based at the root of the DIT. Substring + matching is allowed on dc attributes, but the substring must be at + least be 3 characters in length. + + o Base search based at the root of the DIT. + + o Base, one-level, and sub-tree searches based at any second level + domain name (the second tier) and below. + +3.1.3. Access Control + + The registry TLD DIT only has one access control type. When a client + binds with a DN of "cn=trademark" and password of "attorney", the + second-level domain entries also take on an objectclass of + extensibleObject with the added attributes of "createddate" and + "registrationexpirationdate", which are of type Generalized Time, as + specified by RFC 2252 [6]. + + + + + + + + + + + + + + + + +Newton Experimental [Page 7] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +3.2. Name Server DIT + +3.2.1. DIT Structure + + The registry name server DIT has the following structural hierarchy: + + (o=nsiregistry.com) + | + | + ------------------------------------- + | | | + name server name server name server + (cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org) + + + Figure 2: Registry DIT Overview + + The root of a name server DIT is an entry of objectclass organization + as specified by RFC 1617 [2]. It has no significance other than to + serve as the root of the DIT. + + The second tier of this DIT represents name servers. Each of these + entries is of objectclass ipHost, as specified by RFC 2307 [8]. + +3.2.2. Allowed Searches + + Because of the vast number of entries contained within this DIT, only + certain types of searches are allowed. Allowing any search + expressible via LDAP would lead to searches far too costly for a + publicly available service. The searches allowed are as follows: + + o One-level and sub-tree scoped searches based at the root of the + DIT if a filter on the cn attribute is provided. + + o Base search based at the root of the DIT. + + o Base, one-level, and sub-tree searches based at any name server + entry. + + + + + + + + + + + + + +Newton Experimental [Page 8] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +3.3. Registrar Referral DIT + +3.3.1. DIT Structure + + The registry registrar-referral DIT has the following structural + hierarchy: + + (o=tlds) + | + | + ------------------------------- + | | | | + tld tld tld tld + (dc=net) (dc=com) (dc=org) (dc=edu) + | | | | + : : | : + : : | : + | + --------------------------- + | | | + referral to referral to referral to + registrar 1 registrar 2 registrar n + dc=org DIT dc=org DIT dc=org DIT + + + Figure 3: Registry Referral DIT Overview + + The root of the registrar referral DIT is an entry of objectclass + organization, as specified by RFC 1617 [2]. It has no significance + other than to serve as the root of this DIT. + + The second tier of this DIT represents top-level domains. Each of + these entries is of objectclass domain, as specified by RFC 2247 [4]. + + Underneath each TLD entry, the third tier contains referrals to the + appropriate TLD DIT of each registrar. + + + + + + + + + + + + + + + +Newton Experimental [Page 9] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +4. Registrar LDAP Service + +4.1. TLD DIT + +4.1.1. DIT Structure + + The registrar TLD DIT, which is similar to the registry TLD DIT, has + the following structural hierarchy: + + TLD (e.g., dc=net) + | + | + ------------------------------------------------ + | | | + SLD (e.g., dc=foo,dc=net) : : + | : : + --------------------------------------------- + | | | + | | | + name server contact referral to + (e.g., cn=nameserver1, (e.g., cn=contact1, registrant + dc=foo,dc=net ) dc=foo,dc=net ) + | + | + name server contact + (e.g., cn=contact, + cn=nameserver1, + dc=foo,dc=net ) + + Figure 4: Registrar DIT Overview + + The root of a TLD DIT is an entry of objectclass domain, as specified + by RFC 2247 [4] and represents a top-level domain. + + The second tier of the DIT represents second-level domains. Each of + these entries is of objectclass domain, as specified by RFC 2247 [4]. + + The third tier contains entries specific to each second-level domain. + The entries at this level are as follows: + + o Name server entries are of objectclass ipHost, as specified by RFC + 2307 [8]. The distinguished names of these name server entries + are algorithmically calculated where the first component is the + word "nameserver" concatenated with an index number of the name + server entry and the remaining components are the appropriate + domain names. There is no specification relating the value of the + name server entry to the index it may be assigned other than it is + unique and consistent with respect to the client session. + + + +Newton Experimental [Page 10] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + + o Contact entries are of objectclass inetOrgPerson, as specified by + RFC 2798 [9]. The distinguished names of these contact entries + are algorithmically calculated, where the first component is the + word "contact" concatenated with an index number of the contact + and the remaining components are the appropriate domain names. + There is no specification relating the value of the contact entry + to the index it may be assigned other than it is unique and + consistent with respect to the client session. The description + attribute of the entry contains the role for which a contact is + related to a domain. These roles are identified as "Admin + Contact", "Technical Contact", and "Billing Contact", and may + appear in any order. + + o Finally, this third tier contains the referral from the registrar + to the registrant. + + The fourth tier only contains name server contact entries. These + entries are of objectclass inetOrgPerson, as specified by RFC 2798 + [9]. + +4.1.2. Allowed Searches + + Because of the vast number of entries contained within this DIT, only + certain types of searches are allowed. Allowing any search + expressible via LDAP would lead to searches far too costly for a + publicly available service. The searches allowed are as follows: + + o One-level scoped searches based at the root of the DIT. Substring + matching is allowed on dc and o attributes, but the substring must + be at least 3 characters in length. + + o Base search based at the root of the DIT. + + o Base, one-level, and sub-tree searches based at any second level + domain name (the second tier) and below. + +4.1.3. Access Control + + The registrar TLD DIT has two access control types. When binding + anonymously, a client only sees dc, o, and c attributes of the + second-level domain entries. When a client binds with a DN of + "cn=trademark" and password of "attorney", all of the other + attributes normally available on entries of objectclass domain are + visible if they have values. In addition, if a client binds with the + DN of a contact and password of "password", all attributes for + second-level domain entries for which the bind DN has a relation are + visible. + + + + +Newton Experimental [Page 11] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +4.2. Name Server and Contact DIT + +4.2.1. DIT Structure + + The registrar name server and contact DIT has the following + structural hierarchy: + + (o=nsi.com) + | + | + -------------------------------------- + | | + Contacts Name Servers + (ou=contacts) (ou=name servers) + | | + ----------------- ------------------------ + | | | | | | + Contact : : Name Server : : + (uid=handle) : : (cn=handle) : : + | + Name Server + Contact + (cn=contact1) + + Figure 5: Registrar DIT Overview + + The first tier of the name server and contact DIT is an entry of + objectclass organization, as specified by RFC 1617 [2]. + + The second tier of the DIT contains two entries, each of which is of + objectclass organizationalUnit, as specified by RFC 2256 [7]. One + entry represents the part of the DIT containing contacts and the + other entry represents the part of the DIT containing name servers. + + Entries underneath the contacts organizationalUnit entry are of + objectclass inetOrgPerson and represent contacts registered with the + registrar. Their RDN is composed of the uid attribute. The uid + attribute's value is a unique identifier or handle that is registrar + assigned. + + Entries underneath the name server organizationalUnit entry are of + objectclass ipHost and represent name servers registered with the + registrar. Their RDN is composed of the cn attribute. The cn + attribute's value is a unique identifier or handle that is registrar + assigned. Each name server entry may optionally have children + entries of objectclass inetOrgPerson. These entries represent the + contacts of the name server they fall beneath. + + + + +Newton Experimental [Page 12] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +4.2.2. Allowed Searches + + Because of the vast number of entries contained within this DIT, only + certain types of searches are allowed. Allowing any search + expressible via LDAP would lead to searches far too costly for a + publicly available service. The searches allowed are as follows: + + o One-level and base searches at the root of the DIT. + + o Sub-tree searches at the root of the DIT using cn and uid + attributes as a filter. + + o Base searches at either entry of the second tier. + + o One-level and sub-tree searches at either entry of the second + tier, using cn or uid attributes as a filter. + + o Base, one-level, and sub-tree searches based at any contact or + name server entry and below. + +5. Clients + + Early scoping and analysis of this project were based on the use of + output from command line clients, specifically the "ldapsearch" + command present with many implementations of LDAP servers. Our + survey of this tool, available from many vendors, showed that + referral chasing was difficult to control or predict, and the + behavior between these implementations with respect to referral + chasing was inconsistent. + + Based on the limited nature of the expressive capabilities present + with just command line tools, searches involving nested queries or + advanced referral chasing were deemed the domain of clients making + direct use of LDAP client libraries. Three of these types of clients + were produced: a web-based client, a cross-platform C-based client, + and a Java client. No significant deficiencies or problems were + found with the LDAP client libraries in the construction of these + clients, and the level of control provided by their programming + interfaces was adequate to create the necessary searches. Instead, + most of the problems encountered with these clients were based on + usability concerns. + + It was found that the web-based client caused a great amount of + confusion for users not familiar with LDAP or Nicname/Whois with + respect to the underlying technology and the network model. Thus, + many users believed the web-based client to be the only interface to + the data and were unaware or confused by the intermediate LDAP + protocol. In addition, it was difficult to express to users the + + + +Newton Experimental [Page 13] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + + registry-registrar-registrant service model in adequate terms from + search results where the results could be rendered properly among the + various common web browsers. + + Both the C and Java based clients were built to be both graphical and + cross-platform (in the case of the C-based client, the Linux and + Windows platforms were chosen as targets). The LDAP client libraries + chosen for both clients proved to be quite capable and offered the + necessary levels of control for conducting nested queries and + advanced referral chasing. Expectations at the outset for + construction of both clients, based on past experience, were that the + C-based client would not only perform better than the Java client but + also have a better appearance. In reality, these assumptions were + incorrect as there was no perceivable difference in performance and + the look of the Java client was often considered to be far superior + to its counter-part. In addition, the Java client required much less + time to create. Both clients are available under the terms of an + open source license. Though it is impossible to have accurate + measurements of their popularity, through monitoring and feedback it + was perceived that the web-based client had far greater use. + +6. Lessons Learned + + Based on the experience of piloting this experimental service, + feedback from users of the service, and general comments and + observations of current and common opinions, the following items have + been noted. + +6.1. Intra-Server Referrals + + Original analysis of the data set to be used revealed a high degree + of relationships between name servers, contacts, and domains. + Storing the data in non-normalized form according to the DIT outlined + in this document would make an original relational dataset of roughly + 20 million objects explode to over 115 million objects. + + To combat this problem, the first pass at defining the DIT's made + heavy use of referrals between the TLD DIT's and the name server and + contact DIT's. The use of the 'alias' objectclass was considered but + ruled out in hopes of using referrals for load balancing across + servers (i.e., placing each TLD DIT on a separate server, and + separate servers for the name server and contact DIT's). However, + initial testing with the 'ldapsearch' command found inconsistencies + with the interpretation of the referrals and how they were managed. + Not only were the results inconsistent between implementations, but + many of these clients would easily get caught in referral loops. + + + + + +Newton Experimental [Page 14] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + + The final solution to the problem was to create a customized back-end + data store containing the data in a normalized form. This gave the + client the appearance of having a non-normalized data set which + required no intra-server referrals. Aliases may have been a better + solution, however our interpretation of their output with + implementations of the 'ldapsearch' tool was not satisfactory. It + was also later learned that some LDAP server implementations place + certain restrictions on aliases that would have conflicted with our + overall DIT structure. In the end, it was felt that a customized + back-end would be required by any server with a large data-set, but + smaller data-sets for less populated domains could easily use off- + the-shelf implementations. + +6.2. Inter-Server Referrals + + The modeling of the overall service to provide the split in + operational responsibility between registry and registrar required + the use of referrals (i.e., the two servers would not be operated by + the same organization, therefore would most likely not co-exist on + the same physical machine or network). The chief problem with LDAP + referrals returned for this purpose grew out of the need to limit + data returned to the client and the priority given to referrals. It + was quite easy to cause a sub-tree query at certain levels, for + instance a TLD level, to return nothing but referrals. This was true + because referrals would be returned out of the scope of the supplied + search filter and therefore would fill the result set to its limit, + normally set to 50 entries. + + In certain use cases, a result set with nothing but referrals was + desired (e.g., o=tlds). However, even in these cases it was possible + for some referrals to not be returned due to the size limit. In this + case, it was felt that a result set of 50 referrals, the default for + the size limit in most cases, was too large for any practical use by + a client and was a failing of query distribution in general rather + than a limitation of LDAP. + +6.3. Common DIT + + Because of the nature of software development, the graphical and web + clients were developed after the development of the server software. + The 'ldapsearch' client was used for testing and development during + server software creation. It was not until the creation of more + advanced clients that it was discovered that the design decision of + uniform DIT naming should have been made. Technically, this would + have allowed for slightly better software modularization and re-use. + In addition, the use of a company name in the DIT structure did not + allow the easy integration of another domain registry, as in the + registry-registrar model. Not only would clients have to be + + + +Newton Experimental [Page 15] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + + reconfigured for each new registry operator, but this would most + likely have social implications as well. + +6.4. Universal Client + + The construction of the clients revealed yet another misconception. + Though this project used a generic directory service technology, the + clients required a high-degree of algorithmic knowledge about the DIT + structure and schemas being used. The graphical clients could not be + used against an LDAP service with another DIT or schema. Therefore, + a generic or universal client, one that could be used for all LDAP + applications, would either not be able to make full use of the data + provided by the service or would be far too complex for operation by + the average user. + +6.5. Targeting Searches by Tier + + The network model for this service was divided into three tiers: + registry, registrar, and registrant. Despite this, all searches + needed to start at the registry level causing overhead for searches + that could be targeted at a select tier. This service did not + implement a solution to this problem, such as using SRV and/or NAPTR + records in DNS to allow a client to find a responsible LDAP server. + +6.6. Data Mining + + Section 3.1.2 and Section 4.1.2 describe the searches allowed by this + service. However, the most common question asked by users of the + service revolved around getting around these restrictions. Because + browsing at the TLD level was not permitted, many users asked about + the feasibility of using recursive dictionary queries to circumvent + the search restrictions. + + It should be noted that many operators of Nicname/Whois server + consider this practice to be data mining and often refer to it + specifically as a dictionary attack. + +7. IANA Considerations + + There are no applicable IANA considerations presented in this + document. + +8. Internationalization Considerations + + The domain administrative data in this service did not cover + Internationalized Domain Names (IDN's). + + + + + +Newton Experimental [Page 16] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +9. Security Considerations + + This experiment did not endeavor to use security mechanisms beyond + those readily available in LDAP [5]. Section 3.1.3 and Section 4.1.3 + describe the various access controls used within the scope of the + defined security mechanisms. While these mechanisms were adequate + for this experimental deployment, they would not be adequate for a + production environment, and they should not be taken as a model for + those contemplating deployment on the Internet. + +10. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + +Newton Experimental [Page 17] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +11. Normative References + + [1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC + 954, October 1985. + + [2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and + Structuring Guidelines for X.500 Directory Pilots", RFC 1617, + May 1994. + + [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. + Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, + June 1997. + + [4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, + "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, + January 1998. + + [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, December 1997. + + [6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with + LDAPv3", RFC 2256, December 1997. + + [8] Howard, L., "An Approach for Using LDAP as a Network Information + Service", RFC 2307, March 1998. + + [9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", + RFC 2798, April 2000. + + + + + + + + + + + + + + + + + + + +Newton Experimental [Page 18] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +Appendix A. Other Work + + In addition to the deployment of servers and development of clients, + VeriSign conducted two sub-projects related to this experiment. + + The first project was a Nicname/Whois-to-LDAP gateway. The goal of + the project was to create an LDAP server for use by registrars to + deploy in front of their Nicname/Whois servers. This gateway would + take LDAP requests, translate them to Nicname/Whois requests, issue + the request to a specific Nicname/Whois server deployed on port 43, + interpret the response, and return LDAP result sets. Because of the + unspecified nature of Nicname/Whois result sets, the gateway was + programmed to specifically recognize only the output of three + distinct registrars. While this gateway proved valuable enough to + allow domain lookups and limited searches, it was unable to provide + consistent contact lookups, nameserver lookups, or registrant + referrals. This software was also made publicly available under the + terms of an open source license. + + The second project was an informal survey of registrants with + deployed LDAP servers. This was conducted by using the com, net, + org, and edu zone files and testing for the existence of an LDAP + server on port 389 using the name of the domain, a host named "ldap" + in the domain, and a host named "dir" in the domain (e.g., "foo.com", + "ldap.foo.com", and "dir.foo.com"). This survey did not attempt to + resolve LDAP services using SRV records in DNS. + + The result of this survey found that roughly 0.5% of active domains + had an LDAP server. By profiling a server's root DSA-specific Entry + (DSE), the survey found that about 90% of the servers were + implementations provided by vendor A, 9% of the servers were + implementations provided by vendor B, and 1% of the servers were + implementations provided by other vendors. Of the servers queried + that were determined to be implementations provided by vendor A, it + appeared that about only 10% contained public data (this also led to + the assumption that the other 90% were not intended to be publicly + queried). Of the servers queried that were determined to be + implementations provided by vendor B, it appears that nearly all + contained public data. + +Appendix B. Acknowledgments + + Significant analysis, design, and implementation for this project + were conducted by Brad McMillen, David Blacka, Anna Zhang, and + Michael Schiraldi. Mark Kosters and Leslie Daigle provided guidance + by reviewing this project, the project's goals, and this document. + + + + + +Newton Experimental [Page 19] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +Author's Address + + Andrew Newton + VeriSign, Inc. + 21345 Ridgetop Circle + Sterling, VA 20166 + USA + + Phone: +1 703 948 3382 + EMail: anewton@verisignlabs.com; anewton@ecotroph.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton Experimental [Page 20] + +RFC 3663 Domain Administrative Data in LDAP December 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Newton Experimental [Page 21] + diff --git a/doc/rfc/rfc3671.txt b/doc/rfc/rfc3671.txt new file mode 100644 index 0000000000..7157acc8f1 --- /dev/null +++ b/doc/rfc/rfc3671.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3671 OpenLDAP Foundation +Category: Standards Track December 2003 + + + Collective Attributes in + the Lightweight Directory Access Protocol (LDAP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + X.500 collective attributes allow common characteristics to be shared + between collections of entries. This document summarizes the X.500 + information model for collective attributes and describes use of + collective attributes in LDAP (Lightweight Directory Access + Protocol). This document provides schema definitions for collective + attributes for use in LDAP. + +1. Introduction + + In X.500 [X.500], a collective attribute is "a user attribute whose + values are the same for each member of an entry collection" [X.501]. + This document details their use in the Lightweight Directory Access + Protocol (LDAP) [RFC3377]. + +1.1. Entry Collections + + A collection of entries is a grouping of object and alias entries + based upon common properties or shared relationship between the + corresponding entries which share certain attributes. An entry + collection consists of all entries within scope of a collective + attributes subentry [RFC3672]. An entry can belong to several entry + collections. + + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +1.2. Collective Attributes + + Attributes shared by the entries comprising an entry collection are + called collective attributes. Values of collective attributes are + visible but not updateable to clients accessing entries within the + collection. Collective attributes are updated (i.e., modified) via + their associated collective attributes subentry. + + When an entry belongs to multiple entry collections, the entry's + values of each collective attribute are combined such that + independent sources of these values are not manifested to clients. + + Entries can specifically exclude a particular collective attribute by + listing the attribute as a value of the collectiveExclusions + attribute. Like other user attributes, collective attributes are + subject to a variety of controls including access, administrative, + and content controls. + +1.3. Conventions + + Schema definitions are provided using LDAPv3 [RFC2251] description + formats [RFC2252]. Definitions provided here are formatted (line + wrapped) for readability. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +2. System Schema for Collective Attributes + + The following operational attributes are used to manage Collective + Attributes. LDAP servers [RFC3377] MUST act in accordance with the + X.500 Directory Models [X.501] when providing this service. + +2.1. collectiveAttributeSubentry + + Subentries of this object class are used to administer collective + attributes and are referred to as collective attribute subentries. + + ( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY ) + + A collective attribute subentry SHOULD contain at least one + collective attribute. The collective attributes contained within a + collective attribute subentry are available for finding, searching, + and comparison at every entry within the scope of the subentry. The + collective attributes, however, are administered (e.g., modified) via + the subentry. + + + + +Zeilenga Standards Track [Page 2] + +RFC 3671 Collective Attributes in LDAP December 2003 + + + Implementations of this specification SHOULD support collective + attribute subentries in both collectiveAttributeSpecificArea + (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative + areas [RFC3672][X.501]. + +2.2. collectiveAttributeSubentries + + The collectiveAttributeSubentries operational attribute identifies + all collective attribute subentries that affect the entry. + + ( 2.5.18.12 NAME 'collectiveAttributeSubentries' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + USAGE directoryOperation NO-USER-MODIFICATION ) + +2.3. collectiveExclusions + + The collectiveExclusions operational attribute allows particular + collective attributes to be excluded from an entry. It MAY appear in + any entry and MAY have multiple values. + + ( 2.5.18.7 NAME 'collectiveExclusions' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + USAGE directoryOperation ) + + The descriptor excludeAllCollectiveAttributes is associated with the + OID 2.5.18.0. When this descriptor or OID is present as a value of + the collectiveExclusions attribute, all collective attributes are + excluded from an entry. + +3. Collective Attribute Types + + A userApplications attribute type can be defined to be COLLECTIVE + [RFC2252]. This indicates that the same attribute values will appear + in the entries of an entry collection subject to the use of the + collectiveExclusions attribute and other administrative controls. + These administrative controls MAY include DIT Content Rules, if + implemented. + + Collective attribute types are commonly defined as subtypes of non- + collective attribute types. By convention, collective attributes are + named by prefixing the name of their non-collective supertype with + "c-". For example, the collective telephone attribute is named + c-TelephoneNumber after its non-collective supertype telephoneNumber. + + Non-collective attributes types SHALL NOT subtype collective + attributes. + + + +Zeilenga Standards Track [Page 3] + +RFC 3671 Collective Attributes in LDAP December 2003 + + + Collective attributes SHALL NOT be SINGLE-VALUED. Collective + attribute types SHALL NOT appear in the attribute types of an object + class definition. + + Operational attributes SHALL NOT be defined to be collective. + + The remainder of section provides a summary of collective attributes + derived from those defined in [X.520]. The SUPerior attribute types + are described in [RFC 2256] for use with LDAP. + + Implementations of this specification SHOULD support the following + collective attributes and MAY support additional collective + attributes. + +3.1. Collective Locality Name + + The c-l attribute type specifies a locality name for a collection of + entries. + + ( 2.5.4.7.1 NAME 'c-l' + SUP l COLLECTIVE ) + +3.2. Collective State or Province Name + + The c-st attribute type specifies a state or province name for a + collection of entries. + + ( 2.5.4.8.1 NAME 'c-st' + SUP st COLLECTIVE ) + +3.3. Collective Street Address + + The c-street attribute type specifies a street address for a + collection of entries. + + ( 2.5.4.9.1 NAME 'c-street' + SUP street COLLECTIVE ) + +3.4. Collective Organization Name + + The c-o attribute type specifies an organization name for a + collection of entries. + + ( 2.5.4.10.1 NAME 'c-o' + SUP o COLLECTIVE ) + + + + + + +Zeilenga Standards Track [Page 4] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +3.5. Collective Organizational Unit Name + + The c-ou attribute type specifies an organizational unit name for a + collection of entries. + + ( 2.5.4.11.1 NAME 'c-ou' + SUP ou COLLECTIVE ) + +3.6. Collective Postal Address + + The c-PostalAddress attribute type specifies a postal address for a + collection of entries. + + ( 2.5.4.16.1 NAME 'c-PostalAddress' + SUP postalAddress COLLECTIVE ) + +3.7. Collective Postal Code + + The c-PostalCode attribute type specifies a postal code for a + collection of entries. + + ( 2.5.4.17.1 NAME 'c-PostalCode' + SUP postalCode COLLECTIVE ) + +3.8. Collective Post Office Box + + The c-PostOfficeBox attribute type specifies a post office box for a + collection of entries. + + ( 2.5.4.18.1 NAME 'c-PostOfficeBox' + SUP postOfficeBox COLLECTIVE ) + +3.9. Collective Physical Delivery Office Name + + The c-PhysicalDeliveryOfficeName attribute type specifies a physical + delivery office name for a collection of entries. + + ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName' + SUP physicalDeliveryOfficeName COLLECTIVE ) + +3.10. Collective Telephone Number + + The c-TelephoneNumber attribute type specifies a telephone number for + a collection of entries. + + ( 2.5.4.20.1 NAME 'c-TelephoneNumber' + SUP telephoneNumber COLLECTIVE ) + + + + +Zeilenga Standards Track [Page 5] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +3.11. Collective Telex Number + + The c-TelexNumber attribute type specifies a telex number for a + collection of entries. + + ( 2.5.4.21.1 NAME 'c-TelexNumber' + SUP telexNumber COLLECTIVE ) + +3.13. Collective Facsimile Telephone Number + + The c-FacsimileTelephoneNumber attribute type specifies a facsimile + telephone number for a collection of entries. + + ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber' + + SUP facsimileTelephoneNumber COLLECTIVE ) + +3.14. Collective International ISDN Number + + The c-InternationalISDNNumber attribute type specifies an + international ISDN number for a collection of entries. + + ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber' + SUP internationalISDNNumber COLLECTIVE ) + +4. Security Considerations + + Collective attributes, like other attributes, are subject to access + control restrictions and other administrative policy. Generally + speaking, collective attributes accessed via an entry in a collection + are governed by rules restricting access to attributes of that entry. + And collective attributes access via a subentry are governed by rules + restricting access to attributes of that subentry. However, as LDAP + does not have a standard access model, the particulars of each + server's access control system may differ. + + General LDAP security considerations [RFC3377] also apply. + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +5. IANA Considerations + + The IANA has registered the LDAP descriptors [RFC3383] defined in + this technical specification. The following registration template is + suggested: + + Subject: Request for LDAP Descriptor Registration + Descriptor see comments + Object Identifier: see comment + Person & email address to contact for further information: + Kurt Zeilenga + Usage: see comment + Specification: RFC3671 + Author/Change Controller: IESG + Comments: + + NAME Type OID + ------------------------ ---- ----------------- + c-FacsimileTelephoneNumber A 2.5.4.23.1 + c-InternationalISDNNumber A 2.5.4.25.1 + c-PhysicalDeliveryOffice A 2.5.4.19.1 + c-PostOfficeBox A 2.5.4.18.1 + c-PostalAddress A 2.5.4.16.1 + c-PostalCode A 2.5.4.17.1 + c-TelephoneNumber A 2.5.4.20.1 + c-TelexNumber A 2.5.4.21.1 + c-l A 2.5.4.7.1 + c-o A 2.5.4.10.1 + c-ou A 2.5.4.11.1 + c-st A 2.5.4.8.1 + c-street A 2.5.4.9.1 + collectiveAttributeSubentries A 2.5.18.12 + collectiveAttributeSubentry O 2.5.17.2 + collectiveExclusions A 2.5.18.7 + + where Type A is Attribute and Type O is ObjectClass. + + The Object Identifiers used in this document were assigned by the + ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify + elements of X.500 schema [X.520]. This document make no OID + assignments, it only provides LDAP schema descriptions with existing + elements of X.500 schema. + + + + + + + + + +Zeilenga Standards Track [Page 7] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +6. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +7. Acknowledgments + + This document is based upon the ITU Recommendations for the Directory + [X.501][X.520]. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use + with LDAPv3", RFC 2256, December 1997. + + [RFC3377] Hodges, J. and R. L. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + + + +Zeilenga Standards Track [Page 8] + +RFC 3671 Collective Attributes in LDAP December 2003 + + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 3383, September 2002. + + [RFC3672] Zeilenga, K. and S. Legg, "Subentries in Lightweight + Directory Access Protocol (LDAP)", RFC 3672, December + 2003. + + [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993. + +8.2. Informative References + + [X.500] "The Directory: Overview of Concepts, Models", ITU-T + Recommendation X.500, 1993. + + [X.520] "The Directory: Selected Attribute Types", ITU-T + Recommendation X.520, 1993. + +9. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 9] + +RFC 3671 Collective Attributes in LDAP December 2003 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 10] + diff --git a/doc/rfc/rfc3672.txt b/doc/rfc/rfc3672.txt new file mode 100644 index 0000000000..62097db7fa --- /dev/null +++ b/doc/rfc/rfc3672.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3672 OpenLDAP Foundation +Category: Standards Track S. Legg + Adacel Technologies + December 2003 + + + Subentries in the Lightweight Directory Access Protocol (LDAP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + In X.500 directories, subentries are special entries used to hold + information associated with a subtree or subtree refinement. This + document adapts X.500 subentries mechanisms for use with the + Lightweight Directory Access Protocol (LDAP). + +1. Overview + + From [X.501]: + + A subentry is a special kind of entry immediately subordinate to + an administrative point. It contains attributes that pertain to + a subtree (or subtree refinement) associated with its + administrative point. The subentries and their administrative + point are part of the same naming context. + + A single subentry may serve all or several aspects of + administrative authority. Alternatively, a specific aspect of + administrative authority may be handled through one or more of + its own subentries. + + Subentries in the Lightweight Directory Access Protocol (LDAP) + [RFC3377] SHALL behave in accordance with X.501 unless noted + otherwise in this specification. + + + + + +Zeilenga & Legg Standards Track [Page 1] + +RFC 3672 Subentries in LDAP December 2003 + + + In absence of the subentries control (detailed in Section 3), + subentries SHALL NOT be considered in one-level and subtree scope + search operations. For all other operations, including base scope + search operations, subentries SHALL be considered. + +1.1. Conventions + + Schema definitions are provided using LDAP description formats + [RFC2252]. Definitions provided here are formatted (line wrapped) + for readability. + + Protocol elements are described using ASN.1 [X.680]. The term "BER- + encoded" means the element is to be encoded using the Basic Encoding + Rules [X.690] under the restrictions detailed in Section 5.1 of + [RFC2251]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +2. Subentry Schema + +2.1. Subtree Specification Syntax + + The Subtree Specification syntax provides a general purpose mechanism + for the specification of a subset of entries in a subtree of the + Directory Information Tree (DIT). A subtree begins at some base + entry and includes the subordinates of that entry down to some + identified lower boundary, possibly extending to the leaf entries. A + subtree specification is always used within a context or scope which + implicitly determines the bounds of the subtree. For example, the + scope of a subtree specification for a subschema administrative area + does not include the subtrees of any subordinate administrative point + entries for subschema administration. Where a subtree specification + does not identify a contiguous subset of the entries within a single + subtree the collection is termed a subtree refinement. + + This syntax corresponds to the SubtreeSpecification ASN.1 type + described in [X.501], Section 11.3. This ASN.1 data type definition + is reproduced here for completeness. + + SubtreeSpecification ::= SEQUENCE { + base [0] LocalName DEFAULT { }, + COMPONENTS OF ChopSpecification, + specificationFilter [4] Refinement OPTIONAL } + + LocalName ::= RDNSequence + + + + +Zeilenga & Legg Standards Track [Page 2] + +RFC 3672 Subentries in LDAP December 2003 + + + ChopSpecification ::= SEQUENCE { + specificExclusions [1] SET OF CHOICE { + chopBefore [0] LocalName, + chopAfter [1] LocalName } OPTIONAL, + minimum [2] BaseDistance DEFAULT 0, + maximum [3] BaseDistance OPTIONAL } + + BaseDistance ::= INTEGER (0 .. MAX) + + Refinement ::= CHOICE { + item [0] OBJECT-CLASS.&id, + and [1] SET OF Refinement, + or [2] SET OF Refinement, + not [3] Refinement } + + The components of SubtreeSpecification are: base, which identifies + the base entry of the subtree or subtree refinement, and + specificExclusions, minimum, maximum and specificationFilter, which + then reduce the set of subordinate entries of the base entry. The + subtree or subtree refinement contains all the entries within scope + that are not excluded by any of the components of the subtree + specification. When all of the components of SubtreeSpecification + are absent (i.e., when a value of the Subtree Specification syntax is + the empty sequence, {}), the specified subtree implicitly includes + all the entries within scope. + + Any particular use of this mechanism MAY impose limitations or + constraints on the components of SubtreeSpecification. + + The LDAP syntax specification is: + + ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' ) + + The LDAP-specific encoding of values of this syntax is defined by the + Generic String Encoding Rules [RFC3641]. Appendix A provides an + equivalent Augmented Backus-Naur Form (ABNF) [RFC2234] for this + syntax. + +2.1.1. Base + + The base component of SubtreeSpecification nominates the base entry + of the subtree or subtree refinement. The base entry may be an entry + which is subordinate to the root entry of the scope in which the + subtree specification is used, in which case the base component + contains a sequence of Relative Distinguished Names (RDNs) relative + to the root entry of the scope, or may be the root entry of the scope + itself (the default), in which case the base component is absent or + contains an empty sequence of RDNs. + + + +Zeilenga & Legg Standards Track [Page 3] + +RFC 3672 Subentries in LDAP December 2003 + + + Entries that are not subordinates of the base entry are excluded from + the subtree or subtree refinement. + +2.1.2. Specific Exclusions + + The specificExclusions component of a ChopSpecification is a list of + exclusions that specify entries and their subordinates to be excluded + from the subtree or subtree refinement. The entry is specified by a + sequence of RDNs relative to the base entry (i.e., a LocalName). + Each exclusion is of either the chopBefore or chopAfter form. If the + chopBefore form is used then the specified entry and its subordinates + are excluded from the subtree or subtree refinement. If the + chopAfter form is used then only the subordinates of the specified + entry are excluded from the subtree or subtree refinement. + +2.1.3. Minimum and Maximum + + The minimum and maximum components of a ChopSpecification allow the + exclusion of entries based on their depth in the DIT. + + Entries that are less than the minimum number of RDN arcs below the + base entry are excluded from the subtree or subtree refinement. A + minimum value of zero (the default) corresponds to the base entry. + + Entries that are more than the maximum number of RDN arcs below the + base entry are excluded from the subtree or subtree refinement. An + absent maximum component indicates that there is no upper limit on + the number of RDN arcs below the base entry for entries in the + subtree or subtree refinement. + +2.1.4. Specification Filter + + The specificationFilter component is a boolean expression of + assertions about the values of the objectClass attribute of the base + entry and its subordinates. A Refinement assertion item evaluates to + true for an entry if that entry's objectClass attribute contains the + OID nominated in the assertion. Entries for which the overall filter + evaluates to false are excluded from the subtree refinement. If the + specificationFilter is absent then no entries are excluded from the + subtree or subtree refinement because of their objectClass attribute + values. + + + + + + + + + + +Zeilenga & Legg Standards Track [Page 4] + +RFC 3672 Subentries in LDAP December 2003 + + +2.2. Administrative Role Attribute Type + + The Administrative Model defined in [X.501], clause 10 requires that + administrative entries contain an administrativeRole attribute to + indicate that the associated administrative area is concerned with + one or more administrative roles. + + The administrativeRole operational attribute is specified as follows: + + ( 2.5.18.5 NAME 'administrativeRole' + EQUALITY objectIdentifierMatch + USAGE directoryOperation + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) + + The possible values of this attribute defined in X.501 are: + + OID NAME + -------- ------------------------------- + 2.5.23.1 autonomousArea + 2.5.23.2 accessControlSpecificArea + 2.5.23.3 accessControlInnerArea + 2.5.23.4 subschemaAdminSpecificArea + 2.5.23.5 collectiveAttributeSpecificArea + 2.5.23.6 collectiveAttributeInnerArea + + Other values may be defined in other specifications. Names + associated with each administrative role are Object Identifier + Descriptors [RFC3383]. + + The administrativeRole operational attribute is also used to regulate + the subentries permitted to be subordinate to an administrative + entry. A subentry not of a class permitted by the administrativeRole + attribute cannot be subordinate to the administrative entry. + +2.3. Subtree Specification Attribute Type + + The subtreeSpecification operational attribute is defined as follows: + + ( 2.5.18.6 NAME 'subtreeSpecification' + SINGLE-VALUE + USAGE directoryOperation + SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 ) + + This attribute is present in all subentries. See [X.501], clause 10. + Values of the subtreeSpecification attribute nominate collections of + entries within the DIT for one or more aspects of administrative + authority. + + + + +Zeilenga & Legg Standards Track [Page 5] + +RFC 3672 Subentries in LDAP December 2003 + + +2.4. Subentry Object Class + + The subentry object class is a structural object class. + + ( 2.5.17.0 NAME 'subentry' + SUP top STRUCTURAL + MUST ( cn $ subtreeSpecification ) ) + +3. Subentries Control + + The subentries control MAY be sent with a searchRequest to control + the visibility of entries and subentries which are within scope. + Non-visible entries or subentries are not returned in response to the + request. + + The subentries control is an LDAP Control whose controlType is + 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent), + and controlValue contains a BER-encoded BOOLEAN indicating + visibility. A controlValue containing the value TRUE indicates that + subentries are visible and normal entries are not. A controlValue + containing the value FALSE indicates that normal entries are visible + and subentries are not. + + Note that TRUE visibility has the three octet encoding { 01 01 FF } + and FALSE visibility has the three octet encoding { 01 01 00 }. + + The controlValue SHALL NOT be absent. + + In absence of this control, subentries are not visible to singleLevel + and wholeSubtree scope Search requests but are visible to baseObject + scope Search requests. + + There is no corresponding response control. + + This control is not appropriate for non-Search operations. + +4. Security Considerations + + Subentries often hold administrative information or other sensitive + information and should be protected from unauthorized access and + disclosure as described in [RFC2829][RFC2830]. + + General LDAP [RFC3377] security considerations also apply. + + + + + + + + +Zeilenga & Legg Standards Track [Page 6] + +RFC 3672 Subentries in LDAP December 2003 + + +5. IANA Considerations + +5.1. Descriptors + + The IANA has registered the LDAP descriptors detailed in this + technical specification. The following registration template is + suggested: + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): see comment + Object Identifier: see comment + Person & email address to contact for further information: + Kurt Zeilenga + Usage: see comment + Specification: RFC3672 + Author/Change Controller: IESG + Comments: + + NAME Type OID + ------------------------ ---- -------- + accessControlInnerArea R 2.5.23.3 + accessControlSpecificArea R 2.5.23.2 + administrativeRole A 2.5.18.5 + autonomousArea R 2.5.23.1 + collectiveAttributeInnerArea R 2.5.23.6 + collectiveAttributeSpecificArea R 2.5.23.5 + subentry O 2.5.17.0 + subschemaAdminSpecificArea R 2.5.23.4 + subtreeSpecification A 2.5.18.6 + + where Type A is Attribute, Type O is ObjectClass, and Type R is + Administrative Role. + +5.2. Object Identifiers + + This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an + LDAP protocol element defined herein. This OID was assigned [ASSIGN] + by OpenLDAP Foundation, under its IANA-assigned private enterprise + allocation [PRIVATE], for use in this specification. + + Other OIDs which appear in this document were either assigned by the + ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify + elements of X.500 schema or assigned in RFC 2252 for the use + described here. + + + + + + + +Zeilenga & Legg Standards Track [Page 7] + +RFC 3672 Subentries in LDAP December 2003 + + +5.3. Protocol Mechanisms + + The IANA has registered the LDAP protocol mechanisms [RFC3383] + detailed in this specification. + + Subject: Request for LDAP Protocol Mechanism Registration + + Description: Subentries + + Person & email address to contact for further information: + Kurt Zeilenga + + Usage: Control + + Specification: RFC3672 + + Author/Change Controller: IESG + + Comments: none + +6. Acknowledgment + + This document is based on engineering done by IETF LDUP and LDAPext + Working Groups including "LDAP Subentry Schema" by Ed Reed. This + document also borrows from a number of ITU documents including X.501. + +7. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + +Zeilenga & Legg Standards Track [Page 8] + +RFC 3672 Subentries in LDAP December 2003 + + +A. Subtree Specification ABNF + + This appendix is non-normative. + + The LDAP-specific string encoding for the Subtree Specification + syntax is specified by the Generic String Encoding Rules [RFC3641]. + The ABNF [RFC2234] in this appendix for this syntax is provided only + as a convenience and is equivalent to the encoding specified by the + application of [RFC3641]. Since the SubtreeSpecification ASN.1 type + may be extended in future editions of [X.501], the provided ABNF + should be regarded as a snapshot in time. The LDAP-specific encoding + for any extension to the SubtreeSpecification ASN.1 type can be + determined from [RFC3641]. + + In the event that there is a discrepancy between this ABNF and the + encoding determined by [RFC3641], [RFC3641] is to be taken as + definitive. + + SubtreeSpecification = "{" [ sp ss-base ] + [ sep sp ss-specificExclusions ] + [ sep sp ss-minimum ] + [ sep sp ss-maximum ] + [ sep sp ss-specificationFilter ] + sp "}" + + ss-base = id-base msp LocalName + ss-specificExclusions = id-specificExclusions msp + SpecificExclusions + ss-minimum = id-minimum msp BaseDistance + ss-maximum = id-maximum msp BaseDistance + ss-specificationFilter = id-specificationFilter msp Refinement + + id-base = %x62.61.73.65 ; "base" + id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73 + %x69.6F.6E.73 ; "specificExclusions" + id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum" + id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum" + id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46 + %x69.6C.74.65.72 ; "specificationFilter" + + SpecificExclusions = "{" [ sp SpecificExclusion + *( "," sp SpecificExclusion ) ] sp "}" + SpecificExclusion = chopBefore / chopAfter + chopBefore = id-chopBefore ":" LocalName + chopAfter = id-chopAfter ":" LocalName + id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore" + id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter" + + + + +Zeilenga & Legg Standards Track [Page 9] + +RFC 3672 Subentries in LDAP December 2003 + + + Refinement = item / and / or / not + item = id-item ":" OBJECT-IDENTIFIER + and = id-and ":" Refinements + or = id-or ":" Refinements + not = id-not ":" Refinement + Refinements = "{" [ sp Refinement + *( "," sp Refinement ) ] sp "}" + id-item = %x69.74.65.6D ; "item" + id-and = %x61.6E.64 ; "and" + id-or = %x6F.72 ; "or" + id-not = %x6E.6F.74 ; "not" + + BaseDistance = INTEGER-0-MAX + + The , , , , , and rules are defined in [RFC3642]. + +Normative References + + [X.501] ITU-T, "The Directory -- Models," X.501, 1993. + + [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - + Specification of Basic Notation", X.680, 1994. + + [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, + Canonical, and Distinguished Encoding Rules", X.690, + 1994. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, + "Authentication Methods for LDAP", RFC 2829, May 2000. + + [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight + Directory Access Protocol (v3): Extension for Transport + Layer Security", RFC 2830, May 2000. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + + +Zeilenga & Legg Standards Track [Page 10] + +RFC 3672 Subentries in LDAP December 2003 + + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", RFC 3383, September 2002. + + [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 + Types", RFC 3641, October 2003. + +Informative References + + [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [RFC3642] Legg, S., "Common Elements of Generic String Encoding + Rules (GSER) Encodings", RFC 3642, October 2003. + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers + +Authors' Addresses + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + Steven Legg + Adacel Technologies Ltd. + 250 Bay Street + Brighton, Victoria 3186 + AUSTRALIA + + Phone: +61 3 8530 7710 + Fax: +61 3 8530 7888 + EMail: steven.legg@adacel.com.au + + + + + + + + + + + + + +Zeilenga & Legg Standards Track [Page 11] + +RFC 3672 Subentries in LDAP December 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga & Legg Standards Track [Page 12] + diff --git a/doc/rfc/rfc3673.txt b/doc/rfc/rfc3673.txt new file mode 100644 index 0000000000..97aed74d89 --- /dev/null +++ b/doc/rfc/rfc3673.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3673 OpenLDAP Foundation +Category: Standards Track December 2003 + + + Lightweight Directory Access Protocol version 3 (LDAPv3): + All Operational Attributes + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Lightweight Directory Access Protocol (LDAP) supports a mechanism + for requesting the return of all user attributes but not all + operational attributes. This document describes an LDAP extension + which clients may use to request the return of all operational + attributes. + +1. Overview + + X.500 [X.500] provides a mechanism for clients to request all + operational attributes be returned with entries provided in response + to a search operation. This mechanism is often used by clients to + discover which operational attributes are present in an entry. + + This documents extends the Lightweight Directory Access Protocol + (LDAP) [RFC3377] to provide a simple mechanism which clients may use + to request the return of all operational attributes. The mechanism + is designed for use with existing general purpose LDAP clients + (including web browsers which support LDAP URLs) and existing LDAP + APIs. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 3673 LDAPv3: All Operational Attributes December 2003 + + +2. All Operational Attributes + + The presence of the attribute description "+" (ASCII 43) in the list + of attributes in a Search Request [RFC2251] SHALL signify a request + for the return of all operational attributes. + + As with all search requests, client implementors should note that + results may not include all requested attributes due to access + controls or other restrictions. Client implementors should also note + that certain operational attributes may be returned only if requested + by name even when "+" is present. This is because some operational + attributes are very expensive to return. + + Servers supporting this feature SHOULD publish the Object Identifier + 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures' + [RFC3674] attribute in the root DSE. + +3. Interoperability Considerations + + This mechanism is specifically designed to allow users to request all + operational attributes using existing LDAP clients. In particular, + the mechanism is designed to be compatible with existing general + purpose LDAP clients including those supporting LDAP URLs [RFC2255]. + + The addition of this mechanism to LDAP is not believed to cause any + significant interoperability issues (this has been confirmed through + testing). Servers which have yet to implement this specification + should ignore the "+" as an unrecognized attribute description per + [RFC2251, Section 4.5.1]. From the client's perspective, a server + which does not return all operational attributes when "+" is + requested should be viewed as having other restrictions. + + It is also noted that this mechanism is believed to require no + modification of existing LDAP APIs. + +4. Security Considerations + + This document provides a general mechanism which clients may use to + discover operational attributes. Prior to the introduction of this + mechanism, operational attributes were only returned when requested + by name. Some might have viewed this as obscurity feature. However, + this feature offers a false sense of security as the attributes were + still transferable. + + Implementations SHOULD implement appropriate access controls + mechanisms to restricts access to operational attributes. + + + + + +Zeilenga Standards Track [Page 2] + +RFC 3673 LDAPv3: All Operational Attributes December 2003 + + +5. IANA Considerations + + This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the + feature described above. This OID was assigned [ASSIGN] by OpenLDAP + Foundation, under its IANA-assigned private enterprise allocation + [PRIVATE], for use in this specification. + + Registration of this feature has been completed by IANA [RFC3674], + [RFC3383]. + + Subject: Request for LDAP Protocol Mechanism Registration + + Object Identifier: 1.3.6.1.4.1.4203.1.5.1 + + Description: All Op Attrs + + Person & email address to contact for further information: + Kurt Zeilenga + + Usage: Feature + + Specification: RFC3673 + + Author/Change Controller: IESG + + Comments: none + +6. Acknowledgment + + The "+" mechanism is believed to have been first suggested by Bruce + Greenblatt in a November 1998 post to the IETF LDAPext Working Group + mailing list. + +7. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + + +Zeilenga Standards Track [Page 3] + +RFC 3673 LDAPv3: All Operational Attributes December 2003 + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [RFC3674] Zeilenga, K., "Feature Discovery in Lightweight Directory + Access Protocol (LDAP)", RFC 3674, December 2003. + +8.2. Informative References + + [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, + December 1997. + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 3383, September 2002. + + [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, + Models and Service", 1993. + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt. + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers. + +9. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + +Zeilenga Standards Track [Page 4] + +RFC 3673 LDAPv3: All Operational Attributes December 2003 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 5] + diff --git a/doc/rfc/rfc3674.txt b/doc/rfc/rfc3674.txt new file mode 100644 index 0000000000..396bb010bc --- /dev/null +++ b/doc/rfc/rfc3674.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3674 OpenLDAP Foundation +Category: Standards Track December 2003 + + + Feature Discovery in Lightweight Directory Access Protocol (LDAP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Lightweight Directory Access Protocol (LDAP) is an extensible + protocol with numerous elective features. This document introduces a + general mechanism for discovery of elective features and extensions + which cannot be discovered using existing mechanisms. + +1. Background and Intended Use + + The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an + extensible protocol with numerous elective features. LDAP provides + mechanisms for a client to discover supported protocol versions, + controls, extended operations, Simple Authentication and Security + Layer (SASL) mechanisms, and subschema information. However, these + mechanisms are not designed to support general feature discovery. + + This document describes a simple, general-purpose mechanism which + clients may use to discover the set of elective features supported by + a server. For example, this mechanism could be used by a client to + discover whether or not the server supports requests for all + operational attributes, e.g., "+" [RFC3673]. As another example, + this mechanism could be used to discover absolute true, e.g., "(&)" + and false, e.g., "(|)", search filters [T-F] support. + + This document extends the LDAP Protocol Mechanism registry [RFC3383] + to support registration of values of the supportedFeatures attribute. + This registry is managed by the Internet Assigned Numbers Authority + (IANA). + + + + +Zeilenga Standards Track [Page 1] + +RFC 3674 Feature Discovery in LDAP December 2003 + + + Schema definitions are provided using LDAP description formats + [RFC2252]. Definitions provided here are formatted (line wrapped) + for readability. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +2. Discovery of supported features + + Each elective feature whose support may be discovered SHALL be + identified by an Object Identifier (OID). A server advertises its + support for a given feature by providing the OID associated with the + feature as a value of the 'supportedFeatures' attribute held in the + root DSE. A client may examine the values of this attribute to + determine if a particular feature is supported by the server. A + client MUST ignore values it doesn't recognize as they refer to + elective features it doesn't implement. + + Features associated with Standard Track protocol mechanisms MUST be + registered. Features associated with other protocol mechanisms + SHOULD be registered. Procedures for registering protocol mechanisms + are described in BCP 64 [RFC3383]. The word "Feature" should be + placed in the usage field of the submitted LDAP Protocol Mechanism + template. + + The 'supportedFeatures' attribute type is described as follows: + + ( 1.3.6.1.4.1.4203.1.3.5 + NAME 'supportedFeatures' + DESC 'features supported by the server' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + USAGE dSAOperation ) + + Servers MUST be capable of recognizing this attribute type by the + name 'supportedFeatures'. Servers MAY recognize the attribute type + by other names. + +3. Security Considerations + + As rogue clients can discover features of a server by other means + (such as by trial and error), this feature discovery mechanism is not + believed to introduce any new security risk to LDAP. + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 3674 Feature Discovery in LDAP December 2003 + + +4. IANA Considerations + +4.1. Registration of Features as Protocol Mechanisms + + Future specifications detailing LDAP features are to register each + feature as a LDAP Protocol Mechanism per guidance given in BCP 64 + [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration + template indicates that the value to be registered is associated with + an LDAP feature. + +4.2. Registration of the supportedFeatures descriptor + + The IANA has registered the LDAP 'supportedFeatures' descriptor. The + following registration template is suggested: + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): supportedFeatures + Object Identifier: 1.3.6.1.4.1.4203.1.3.5 + Person & email address to contact for further information: + Kurt Zeilenga + Usage: Attribute Type + Specification: RFC 3674 + Author/Change Controller: IESG + + This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA + assigned private enterprise allocation [PRIVATE] for use in this + specification. + +5. Acknowledgment + + This document is based upon input from the IETF LDAPEXT working + group. + +6. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + + +Zeilenga Standards Track [Page 3] + +RFC 3674 Feature Discovery in LDAP December 2003 + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 3383, September 2002. + +7.2. Informative References + + [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol + version 3 (LDAPv3): All Operational Attributes", RFC + 3673, December 2003. + + [T-F] Zeilenga, K., "LDAP True/False Filters", Work in + Progress. + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt. + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers. + +8. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + +Zeilenga Standards Track [Page 4] + +RFC 3674 Feature Discovery in LDAP December 2003 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 5] + -- 2.39.5