INTERNET-DRAFT Editor: Kurt D. Zeilenga Intended Category: Standard Track OpenLDAP Foundation Expires in six months 12 August 2002 Obsoletes: RFC 2251, RFC 2252, RFC 2256 LDAP: Directory Information Models 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 published as a Standard Track RFC. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF LDAP Revision 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) is an Internet protocol for accessing distributed directory services which act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. Zeilenga LDAP Models [Page 1] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 Table of Contents Status of this Memo 1 Abstract Table of Contents 2 1. Introduction 4 1.1. Relationship to Other LDAP Specifications 1.2. Conventions 5 1.3. Common ABNF Productions 2. Model of Directory User Information 7 2.1. The Directory Information Tree 2.2. Naming of Entries 8 2.2.1. Relative Distinguished Names 2.2.2. Distinguished Names 2.2.3. Alias Names 2.3. Structure of an Entry 2.4. Object Classes 9 2.4.1. Abstract Object Classes 10 2.4.2. Structural Object Classes 2.4.3. Auxiliary Object Classes 11 2.5. Attribute Descriptions 2.5.1. Attribute Types 12 2.5.2. Attribute Options 13 2.5.2.1. Tagging Options 2.5.3. Attribute Description Hierarchies 14 2.5.4. Attribute Values 15 2.6. Alias Entries 2.6.1. 'alias' 16 2.6.2. 'aliasObjectName' 3. Directory Administrative and Operational Information 3.1. Subtrees 3.2. Subentries 17 3.3. The 'objectClass' attribute 3.4. Operational attributes 18 3.4.1. 'creatorsName' 3.4.2. 'createTimestamp' 19 3.4.3. 'modifiersName' 3.4.4. 'modifyTimestamp' 4. Directory Schema 20 4.1. Schema Definitions 21 4.1.1. Object Class Definitions 22 4.1.2. Attribute Types 23 4.1.3. Matching Rules 24 4.1.4. LDAP Syntaxes 25 4.1.5. DIT Content Rules 26 4.1.6. DIT Structural Rules and Name Forms 27 4.2. Subschema Subentries 29 4.2.1. 'objectClasses' 30 Zeilenga LDAP Models [Page 2] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 4.2.2. 'attributeTypes' 4.2.3. 'matchingRules' 31 4.2.4. 'matchingRuleUse' 4.2.5. 'ldapSyntaxes' 4.2.6. 'dITContentRules' 32 4.2.7. 'dITStructureRules' 4.2.8. 'nameForms' 4.3. 'extensibleObject' 4.4. Subschema Discovery 33 5. DSA (Server) Informational Model 5.1. Server-specific Data Requirements 34 5.1.1. 'altServer' 35 5.1.2. 'namingContexts' 5.1.3. 'supportedControl' 5.1.4. 'supportedExtension' 36 5.1.5. 'supportedLDAPVersion' 5.1.6. 'supportedSASLMechanisms' 6. Other Considerations 37 6.1. Preservation of User Information 6.2. Short Names 6.3. Cache and Shadowing 7. Implementation Guidelines 38 7.1. Server Guidelines 7.2. Client Guidelines 8. Security Considerations 39 9. IANA Considerations 10. Acknowledgments 40 11. Author's Address 12. References 12.1. Normative References 12.2. Informative References 41 Appendix A. Changes 42 A.1 Changes to RFC 2251 A.1.1 Section 3.2 of RFC 2251 A.1.2 Section 3.4 of RFC 2251 43 A.1.2 Section 4 of RFC 2251 A.1.3 Section 6 of RFC 2251 44 A.2 Changes to RFC 2252 A.2.1 Section 4 of RFC 2252 A.2.2 Section 5 of RFC 2252 A.2.3 Section 7 of RFC 2252 45 A.3 Changes to RFC 2256 Copyright Zeilenga LDAP Models [Page 3] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 1. Introduction This document discusses the X.500 Directory Information Models [X.501], as used by the Lightweight Directory Access Protocol (LDAP) [Roadmap]. The Directory is "a collection of open systems cooperating to provide directory services" [X.500]. The information held in the Directory is collectively known as the Directory Information Base (DIB). A Directory user, which may be a human or other entity, accesses the Directory through a client (or Directory User Agent (DUA)). The client, on behalf of the directory user, interacts with one or more servers (or Directory System Agents (DSA)). A server holds a fragment of the DIB. The DIB contains two classes of information: 1) user information (e.g., information provided and administrated by users). Section 2 describes the Model of User Information. 2) administrative and operational information (e.g., information used to administer and/or operate the directory). Section 3 describes the model of Directory Administrative and Operational Information. These two models, referred to as the generic Directory Information Models, describe how information is represented in the Directory. These generic models provide a framework for other information models. Section 4 discusses the subschema information model and subschema discovery. Section 5 discusses the DSA (Server) Informational Model. Other X.500 information models, such as access control, collective attribute, distribution knowledge, and replication knowledge information models, may be adapted for use in LDAP. Specification of how these models are to be used in LDAP is left to future documents. 1.1. Relationship to Other LDAP Specifications This document is a integral part of the LDAP technical specification [Roadmap] which obsoletes entirely the previously defined LDAP technical specification [LDAPTS]. This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as portions of sections 4 and 6. Appendix A.1 summaries changes to these sections. The remainder of RFC 2251 is obsoleted by the [Protocol], [AuthMeth], and [Roadmap] documents. Zeilenga LDAP Models [Page 4] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 summaries changes to these sections. The remainder of RFC 2252 is obsoleted by [Syntaxes] and [Schema]. This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. Appendix A.3 summarizes changes to these sections. The remainder of RFC 2256 is obsoleted by [Schema] and [Syntaxes]. 1.2. Conventions 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]. Schema definitions are provided using LDAP description formats (as defined in Section 4.1). Definitions provided here are formatted (line wrapped) for readability. Matching rules and LDAP syntaxes referenced in these defintions are defined in [Syntaxes]. 1.3. Common ABNF Productions A number of syntaxes in this document are described using ABNF [RFC2234]. These syntaxes (as well as a number of syntaxes defined in other documents) rely on the following common productions: keystring = leadkeychar *keychar leadkeychar = ALPHA keychar = ALPHA / DIGIT / HYPHEN number = DIGIT / ( LDIGIT 1*DIGIT ) ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" DIGIT = %x30 / LDIGIT ; "0"-"9" LDIGIT = %x31-39 ; "1"-"9" HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f SP = 1*SPACE ; one or more " " WSP = 0*SPACE ; zero or more " " NULL = %x00 ; null (0) SPACE = %x20 ; space (" ") DQUOTE = %x22 ; quote (""") SHARP = %x23 ; octothorpe (or sharp sign) ("#") DOLLAR = %x24 ; dollar sign ("$") SQUOTE = %x27 ; single quote ("'") Zeilenga LDAP Models [Page 5] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 LPAREN = %x28 ; left paren ("(") RPAREN = %x29 ; right paren (")") PLUS = %x2B ; plus sign ("+") COMMA = %x2C ; comma (",") HYPHEN = %x2D ; hypen ("-") DOT = %x2E ; period (".") SEMI = %x3B ; semicolon (";") LANGLE = %x3C ; left angle bracket ("<") EQUALS = %x3D ; equals sign ("=") RANGLE = %x3E ; right angle bracket (">") X = %x58 ; uppercase x ("X") ESC = %x5C ; backslash ("\") USCORE = %x5F ; underscore ("_") LCURLY = %x7B ; left curly brace "{" RCURLY = %x7D ; right curly brace "}" ; Any UTF-8 character UTF8 = UTF1 / UTFMB UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6 UTF0 = %x80-BF UTF1 = %x00-7F UTF2 = %xC0-DF 1(UTF0) UTF3 = %xE0-EF 2(UTF0) UTF4 = %xF0-F7 3(UTF0) UTF5 = %xF8-FB 4(UTF0) UTF6 = %xFC-FD 5(UTF0) ; Any octet OCTET = %x00-FF Object identifiers are represented in LDAP using a dot-decimal format conforming to the ABNF: numericoid = number *( DOT number ) Short names, known as descriptors, are used as a more readable aliases for object identifiers. Descriptors are case insensitive and conform to the the ABNF: descr = keystring Where either an object identifier or a short name may be specified, the following production is used: oid = descr / numericoid The form is preferred. When a production is encoded in a value, the encoding option SHOULD be used instead of the Zeilenga LDAP Models [Page 6] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 encoding option. 2. Model of Directory User Information As [X.501] states: The purpose of the Directory is to hold, and provide access to, information about objects of interest (objects) in some 'world'. An object can be anything which is identifiable (can be named). An object class is an identified family of objects, or conceivable objects, which share certain characteristics. Every object belongs to at least one class. An object class may be a subclass of other object classes, in which case the members of the former class, the subclass, are also considered to be members of the latter classes, the superclasses. There may be subclasses of subclasses, etc., to an arbitrary depth. A directory entry, a named collection of information, is the basic unit of information held in the Directory. An object entry represents a particular object. An alias entry provides alternative naming. A subentry holds administrative and/or operational information. The set of entries representing the DIB are organized hierarchically in a tree structure known as the Directory Information Tree (DIT). Section 2.1 describes the Directory Information Tree Section 2.2 discusses naming of entries. Section 2.3 discusses the structure of entries. Section 2.4 discusses object classes. Section 2.5 discusses attributes Section 2.6 discusses alias entries 2.1. The Directory Information Tree As noted above, the DIB is composed of a set of entries organized hierarchically in a tree structure known as the Directory Information Tree (DIT). Specifically, a tree where vertices are the entries. The arcs between vertices define relations between entries. If an arc exists from X to Y, then the entry at X is the immediate superior of Y and Y is the immediate subordinate of X. An entry's superiors is the entry's immediate superior and its superiors. An entry's subordinates is all of its immediate subordinates and their subordinates. Similarly, the superior/subordinate relationship between object Zeilenga LDAP Models [Page 7] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 entries can be used to derive a relation between the objects they represent. DIT structural rules can be used to govern relationships between objects. 2.2. Naming of Entries 2.2.1. Relative Distinguished Names Each entry is named relative to its immediate superior. This relative name, known as its Relative Distinguished Name (RDN) [X.501], is composed of one or more attribute value assertions (AVA) consisting of an attribute description with zero options and an attribute value. An entry's relative distinguished name must be unique among all its siblings. The following are example string representations of RDNs [LDAPDN]: UID=12345 OU=Engineering CN=Kurt Zeilenga+L=Redwood Shores The last is an example of a multi-valued RDN. 2.2.2. Distinguished Names An entry's fully qualified name, known as its Distinguished Name (DN) [X.501], is the concatenation of its RDN and its immediate superior's DN. A Distinguished Name unambiguously refers to an entry in the tree. The following are example string representations of DNs [LDAPDN]: UID=nobody@example.com,DC=example,DC=com CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US 2.2.3. Alias Names An alias, or alias name, is "an name for an object, provided by the use of alias entries" [X.501]. Alias entries are described in Section 2.6. 2.3. Structure of an Entry An entry consist of a set of attributes which hold information about the object which entry represents. Zeilenga LDAP Models [Page 8] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 An attribute is an attribute description, a type and one or more options, with one or more associated values. The attribute type governs whether the attribute can have multiple values, the syntax and matching rules used to construct and compare values of that attribute, and other functions. Options indicate subtypes and other functions. An example of an attribute is 'givenName' [Schema]. There can be one or more values of this attribute, they must be directory strings, and they are case insensitive (e.g. "John" will match "JOHN"). 2.4. Object Classes An object class is "an identified family of objects (or conceivable objects) which share certain characteristics" [X.501]. As defined in [X.501]: Object classes are used in the Directory for a number of purposes: - describing and categorising objects and the entries that correspond to these objects; - where appropriate, controlling the operation of the Directory; - regulating, in conjunction with DIT structure rule specifications, the position of entries in the DIT; - regulating, in conjunction with DIT content rule specifications, the attributes that are contained in entries; - identifying classes of entry that are to be associated with a particular policy by the appropriate administrative authority. An object class (a subclass) may be derived from an object class (its direct superclass) which is itself derived from an even more generic object class. For structural object classes, this process stops at the most generic object class, 'top' (defined in Section 2.4.1). An ordered set of superclasses up to the most superior object class of an object class is its superclass chain. An object class may be derived from two or more direct superclasses (superclasses not part of the same superclass chain). This feature of subclassing is termed multiple inheritance. Each object class identifies the set of attributes required to be Zeilenga LDAP Models [Page 9] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 present in entries belonging to the class and the set of attributes allowed to be present in entries belonging to the class. As an entry of a class must meet the requirements of each class it belongs to, it can be said that an object class inherits the sets of allowed and required attributes from its superclasses. A subclass can identify an attribute allowed by a subclass as being required. If an attribute is a member of both sets, it is required to be present. Each object class is defined to be one of three kinds of object classes: Abstract, Structural, and Auxiliary. Each object is identified by an object identifier (OID) and, optionally, one or more short names known as descriptors. 2.4.1. Abstract Object Classes An Abstract object class, as the name implies, provides a base of characteristics from which other object classes can be defined to inherit from. An entry cannot belong to only abstract object classes. Abstract object classes can not derive from structural nor auxiliary object classes. All structural object classes derive (directly or indirectly) from the 'top' abstract object class. Auxiliary object classes do not necessarily derive from 'top'. ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) All entries belong to the 'top' abstract class. 2.4.2. Structural Object Classes As stated in [X.501]: An object class defined for use in the structural specification of the DIT is termed a structural object class. Structural object classes are used in the definition of the structure of the names of the objects for compliant entries. An object or alias entry is characterised by precisely one structural object class superclass chain which has a single structural object class as the most subordinate object class. This structural object class is referred to as the structural object class of the entry. Zeilenga LDAP Models [Page 10] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 Structural object classes are related to associated entries: - an entry conforming to a structural object class shall represent the real-world object constrained by the object class; - DIT structure rules only refer to structural object classes; the structural object class of an entry is used to specify the position of the entry in the DIT; - the structural object class of an entry is used, along with an associated DIT content rule, to control the content of an entry. The structural object class of an entry shall not be changed. Each structural object class is a (direct or indirect) subclass of the 'top' abstract object class. Structural object classes cannot subclass auxiliary object classes. Each entry is said to belong to its structural object class as well as all classes in its structural object class's superclass chain, which always includes 'top'. 2.4.3. Auxiliary Object Classes Auxiliary object classes are used augment the characteristics of entries. They are commonly used to augment the sets of attributes required and allowed attributes to be present in an entry. They can be used to describe entries or classes of entries. Auxiliary object classes cannot subclass structural object classes. Each entry can belong to any number of auxiliary object classes. The set of auxiliary object classes which an entry belongs to can change over time. 2.5. Attribute Descriptions An attribute description is composed of an attribute type (see Section 2.5.1) and a set of zero or more attribute options (see Section 2.5.2). An attribute description is represented by the ABNF: Zeilenga LDAP Models [Page 11] INTERNET-DRAFT draft-ietf-ldapbis-models-02 12 August 2002 attributedescription = attributetype options attributetype = oid options = *( SEMI option ) option = 1*keychar where identifies the attribute type and each